I ran compare and the log shows target has more # of rows than source, yet it only shows compare generated insert and update to repair the table.
compare table SAPR3.RESB to SAPR3.RESB target spoux00t@o.PRD key-repair
Source table : SAPR3.RESB
* 18063686 source and 18063748 target rows compared successfully (L381).
* 271 out-of-sync row(s) found and repaired.
*
* Inserts : 131
* Updates : 140
* Deletes : 0
------------------------------------
Row count display may not be consistent due to logic in 5.3 code, repair results still correct.
1. Compare will work from source 4.5.12 to target 5.x.
2. From 5.3.*, compare will get the row count outside the consistent view to improve the performance by cutting down the rollback segment usage while counting the rows.
So, before that, compare (both server & client) will:
1) lock table in session 1
2) get consistent in session 2
3) unlock table in session 1
4) get row count in session 2.
When the row numbers are large, it could take many minutes to get the row count. So, from 5.3.*, we move 4) get row count in session 2 before 1).
We may not get 100% accurate because the inserts (or other txn) can happen while 1) is counting the rows. This is what happened this time.
The discrepancy will NOT affect the compare performance NOR does it affect the repair results. Tables will be compare repair correctly.
However, you may get confused a little bit due to the incorrect display.
STATUS:
This issue will be addressed in a future release of Shareplex 6.xby adding up the fetch count instead.
