Mirroring by RRN slow for large file

I assume that mirroring software (ITERA) that uses journals for replication to another IBM i5 performs updates and deletes on the target system by using the RRN stored in each journal to replicate the update or delete.
This is a reasonable assumption since the mirroring software knows nothing about any index it might use to achieve the update of delete via an access path.

A large file on the source system of 170 million records which may attract several million updates and deletes in a day results in these being queued for long periods on the target system before the actual replication event occurs to keep the file in synch.
I presume that the substantial latency observed between the source and target updates and deletes is because the record be updated or deleted is being located via RRN.
Perhaps this is because DB2 has to do a table scan to find the record which is slower than an update via a unique index.

It's not clear if creating an index whose primary key is RRN would help otherwise the only solution may be to do a custom replication that reads the journal, and extracts the unique index to do an update or delete.

Regards, Peter

############################################################## This correspondence is for the named person's use only. It may contain confidential or legally privileged information, or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Equifax. If you need assistance, please contact Equifax :- Australia www.equifax.com.au/contact New Zealand www.equifax.co.nz/contact ##############################################################