Version 1.18.0 v1
LiveCompare 1.18.0 includes the following new features, enhancements, and bug fixes:
| Type | Description | ID |
|---|---|---|
| Enhancement | Implemented a new QueryBlock data fetch method for Oracle. The algorithm keeps fetching rows from the same socket, which is more efficient as Oracle doesn't allow inequality operators involving Row Value Expressions, which were previously required to fetch rows past the last processed multi-column PK value. This significantly improves performance on Oracle versus Postgres comparisons. As PostgreSQL allows inequality operators involving Row Value Expressions, LiveCompare uses the same algorithm using prepared statements to not cause an impact in terms of bloat and holding back the xmin horizon. So Postgres versus Postgres performance is not affected by this implementation. | LIV-83, RT75644, RT75675, RT75332 |
| Enhancement | Removed the need to reset the buffers when using comparison_algorithm = block_hash. Now when a block with mismatching hashes is found, LiveCompare correctly switches to comparison_algorithm = row_hash until all rows within the mismatching block (already fetched) are compared individually, and then switches back to comparison_algorithm = block_hash to fetch the next buffer. This improves performance on Oracle versus Postgres and also Postgres versus Postgres comparisons. For more information, see Common hash. | LIV-85, LIV-86, RT75644, RT75675, RT75332 |
| Enhancement | Now LiveCompare is able to split large tables even on Oracle versus Postgres comparisons, if comparison_algorithm is set to block_hash or row_hash (currently requires Oracle 12 and newer). Previously it was possible only on Postgres versus Postgres, because the hashing is done on the database side. As Oracle and Postgres don't share a common hashing function, we converted the common row hash that's based on MD5 into an integer hash to be able to split table data into multiple workers. On Oracle, due to performance reasons it was not possible to do on the database side, so we calculate this hash on the Python side. The cost of parallelism for Oracle versus Postgres table splitting is still not the same as on Postgres versus Postgres, so on Oracle versus Postgres we recommend to set parallel_chunk_rows higher than the default of 10 Million. For example, set to 100 Million or even higher, so the algorithm will split only really large tables. For more information, see Common hash. | LIV-87 |
| Enhancement | Support for EDB Extended PostgreSQL 14 and EDB Advanced PostgreSQL 14. | LIV-71, LIV-72 |
| Enhancement | Collecting the Oracle rowid which can be helpful to inspect divergences. | LIV-90, RT75644, RT75675 |
| Enhancement | Improved logging for the LiveRound comparison algorithm, which can be helpful to inspect divergences. | LIV-91, RT75644, RT75675 |
| Bug fix | Fixed the issue where oracle_fetch_fk_metadata was not being honored. | LIV-92 |
| Bug fix | Fixed an issue where, if when using log_level = debug on log-heavy use cases, LiveCompare could die with an unhandled exception because the logging queue was full. On Unix systems, the maximum size of any queue is 32676. The problem happened because the base Python implementation asynchronously enqueued the logging records. The solution was to override the Python implementation to synchronously enqueue the logging records, which can have a performance impact when log_level = debug and log-heavy use cases. | LIV-93 |