Performance is critical for OLTP system, asyncdata should have good performance for the data replication, else it may not be able to catch up with the source table. Following is the key points to get the best performance.
Using perl array DML interface with "-A" option. For Oracle database, the latest DBD Oracle v1.19 can support real array DML operation, which also called bulk operation. In a real replication between databases in different data centers (with relative slow network), I found that the speed can be 10 times faster compare to row by row processing.
asyncdata.pl -A -s ... -t ... -c ...
Using the update instead of delete-insert for row update replication with "-U" option. For the update operation, we have two method to process it, one method is delete the row first, then insert the row, another method is use the update operation. Program developer may choose the delete-insert method because it can keep the code simple, however the performance is degraded.
asyncdata.pl -U -s ... -t ... -c ...
Using the proper batch size for replication with "-B" option, asyncdata will process the rows in the log table according to the operation sequence order batch by batch, so the batch size (default is 100 rows) can affect the performance. You should already know how array fetch affect the query performance over network, so does it to the DML operation.
asyncdata.pl -B 1000 -s ... -t ... -c ...
Create an index on the sequence column of the log table, as described in the previous section, asyncdata will find out the minimum sequence from the log table, and the process the rows where the sequence number are between minimum sequence and minimum sequence plus the batch size. So create an index on the sequence column will speedup the the query.
CREATE INDEX MLOG$_ASYNCDATA_SEQ_IDX ON MLOG$_ASYNCDATA (SEQUENCE$$);
If you still need speedup the performance of asyncdata, you can manually parallel it by split the configuration file into multiple configuration file, then run multiple instance of the replication. When there is multiple tables in the configuration file, asyncdata will process it one by one, if 10 batches processed, it will move to next table for overall balance of the tables. So you can create multiple configuration file and start the in parallel to speedup the replication.
Screen 1: asyncdata -s ... -t ... -c test1.cfg
Screen 2: asyncdata -s ... -t ... -c test2.cfg
Using this script can save you a lot of time to coding, if you are using PL/SQL, you must create PL/SQL code for each table, however with this utility, these works will not be needed any more.