No, this isn't a problem; the behaviour you're seeing is due to the way a replica processes data from the master.
A replica requests data from its master server. The replica will then gather the journal records into batches, sort them, remove duplicates, and only apply the last database action for a given journal record. In other words, the replica is effectively detecting multiple updates to a given row and applying only the last one, the outcome being the same as if they had replayed all of the records.
This approach means that sometimes a replica is applying only a 'delete-value' (or '@dv@') database action from the journal without first applying a 'put value' (or '@pv@') that would have added the record in the first place. In other circumstances (such as replaying a journal manually) this would raise the error mentioned above. However, as part of the replication process, a replica will never complain about a "@dv@" that tries to delete a non-existent row: the equivalent of forcing the replay of a journal ('p4d -f -jr').
So far, we have covered database updates only - but the journal is also updated.
The server will only write records to it's journal for the database operations they actually perform. As the replica may only apply one action of several retrieved from the master server, the replica's journal does not contain all the data found in the master's journal - but it is enough to rebuild the replica to a consistent state. If the replica has applied a 'dv', this 'dv' action is written to the replica's journal, even if there is no record to delete.
When replaying a journal normally, 'dv' actions that attempt to delete records that don't exist will report that "the following row ... could not be deleted" message. However, when replaying a replica journal, you should use always use the '-f' flag when rebuilding the replica from replica journals - this is, after all, how the replication process is working 'inside' the server.
If rebuilding a replica from the master's checkpoint and journals, the '-f' flag should not be required.
The knowledge base articles linked below provide further information about checkpoints and journals and on checking replica integrity. For more general reading, the System Administrator's Guide includes a section on Backup and Recovery
. If you have further questions, please do check the documentation and other resources on the Perforce Software website