Improve redolog performance
General
Escalation
General
Escalation
Description
Environment
None
Activity
Show:
Julia Vural 2 days ago
Instead of having 2982 and 2983, we might be doing 2901 instead.
Satya Bodapati January 27, 2025 at 4:32 PM
Redo log parsing cannot be avoided now because we rely on MLOG_FILE_* records in the Server. This is now used for “reduced lock” feature.
Current bottlenecks in redo component in pxb
redo copied is huge because redo copy start is started right from start. ie. during before data files are copied. IF we can start the redo copy after datafile copy is over, the amount of redo copied will be way smaller. (PXB-2901)
Redo catchup phase (the copy_once()) in a loop. The intention of this code is avoid the redo being overwritten. But there are better ways to deal with this and should be avoided.
This creates bottleneck on write intensive servers. (PXB-2982)
Redo parsing during backup. This can be avoided for the new layout design. ie we should just copy redo as chunks/files without worrying about parsing redo. Current users of redo parsing during backup (PXB-2983)
Look for DDL that skipped redo and happened during backup (lock-ddl=false) MLOG_INDEX_LOAD
Encrypted tablespace that were just created before backup. ie Page 0 doesn't have encryption info
The use-memory feature that predicts the amount of redo