Shulou(Shulou.com)06/01 Report--

Redo-- > undo-- > datafile

When insert records, the table and undo information will be put into redo, before commit, redo information will be put on the hard disk. In the event of a failure, redo can recover the data that has been commit.

Redo- > every operation is first recorded in the redo log. When there is an instance failure (such as a power outage), resulting in the data not being updated to the data file, then the database must be restarted by redo to update the data to the data file.

Undo- > record a copy before the change, but when you system rollback, overwrite the copy back to the original data

Redo- > record all actions for recovery (redo records all the database transaction used for recovery)

Undo- > record all previous impressions for undo is used to store uncommited data infor used for rollback

Redo- > transactions that have been submitted must be written to the data file when the instance is resumed

Undo- > uncommitted transactions.

The reason for redo is that every time you commit, changes to the data are immediately written to the online redo, but not necessarily to the data file at the same time. Because the data has been submitted, but only exists in the online log file, so when recovering, you need to find the data from the online log file and reapply it so that the changed data can be changed in the data file!

The reason for undo is that when oracle is running normally, in order to improve efficiency, if the user does not have commit yet, but there is not much free memory, the DBWR process will write dirty blocks to the data file to free up valuable memory for other processes to use. This is why UNDO is needed. Because the commit statement has not been issued yet, the dbwr process of oracle has written the uncommitted data to the data file.

Undo is also datafile. Maybe dirty buffer didn't write back to disk.

Only when the redo apply is successful can we ensure that everything in the undo datafile is correct and then rollback.

The purpose of undo is to restore the system to the state before the system crash (before shutdown), and then redo is to ensure the consistency of the system.

Without undo, the system will not know the previous state, and redo will be out of the question.

So when instance crash recovery, rollforward is always the first, then rollback.

Undo

The data in the fallback segment is stored as a fallback entry.

Fallback entry = block information (number of blocks that changed during the transaction) + data stored in the block before the transaction commits

Oracle maintains a transaction table for each fallback segment.

The transaction number associated with all fallback entries in the fallback segment is recorded in the transaction table (transaction SCN& fallback entry)

Redo

The redo record consists of a set of change vectors.

Each change variable records the changes made by the transaction to a block in the database.

When a user submits a commit statement, the LGWR process immediately writes a commit record to the redo log file, and then starts writing redo information related to the transaction.

After the transaction is successfully committed, Oracle will generate a system change code (SCN) for the standby. The SCN of the transaction will be recorded in both its commit record and its redo record.

Commit

Work done before committing a transaction:

Generate a fallback entry for the transaction in the fallback cache in the SGA area. The original version of the data modified by the transaction is saved in the fallback entry.

Generate a redo record of the transaction in the redo log cache in the SGA area. The redo record records the changes made by the transaction to the data block, as well as the changes made to the data block in the fallback segment. Redo records in the cache may be written to the hard disk before the transaction is committed.

The changes made by the transaction to the database are recorded in the database cache in the SGA area. These changes may also be written to the hard disk before the transaction is committed.

Work done when a transaction is committed:

Record that the transaction has been committed in the internal transaction table in the fallback segment specified for the transaction, and generate a unique SCN record in the internal transaction table to uniquely identify the transaction.

The LGWR backward process writes the redo records in the SGA area redo log cache to the online redo log file. The SCN of the transaction is written as well as the redo log.

The Oracle service process releases all record and table locks used by the transaction.

Oracle notifies the user that the transaction commit is complete.

Oracle marks the transaction as completed.

Rollback

Roll back the work done by the transaction:

Oracle undoes changes made to the database by all SQL statements in the transaction by using the fallback entry in the fallback segment.

The Oracle service process releases all locks used by the transaction

Oracle notifies the transaction that the fallback was successful.

Oracle marks the transaction as completed

For example:

Insert into a (id) values (1); (redo)

This record needs to be rolled back.

The statement for rollback is delete from a where id = 1; (undo)

Think about it. If you do not do insert into a (id) values (1); (redo)

Then the sentence delete from a where id = 1; (undo) is meaningless.

Now take a look at the correct recovery:

First insert into a (id) values (1); (redo)

Then delete from a where id = 1; (undo)

The system is back to its original state, and there is no record of this.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.