Addressing the Two Questions:
1. Handling the "Dirty Blocks" Scenario in Oracle:
When a user issues an UPDATE statement with a commit:
Redo Logs: The changes are written to redo log files by the redo log writer (LGWR) upon commit.
Dirty Buffers: The updated blocks remain in the Database Buffer Cache as dirty blocks until they are flushed to the data files by the Database Writer (DBWR) process.
If the database is restarted before the dirty blocks are written to the data files:
Redo Logs are Key: Oracle relies on the redo log files to ensure data integrity. Upon restart, the following happens:
During instance recovery, the SMON (System Monitor) background process reads the redo log files.
Any changes in the redo logs that are not reflected in the data files are applied to the data files.
This process is called roll forward.
Undo Tablespace: If the transaction was uncommitted before the crash, Oracle uses the undo tablespace to roll back the changes to maintain consistency.
This process is called roll backward.
Why This Works:
Oracle's architecture ensures that redo logs always have committed changes before they reach data files, allowing recovery from crashes with no data loss for committed transactions.
No comments:
Post a Comment