Oracle Roll-Forward and Oracle-roll Learning Cases

Case study (1)

Let's say I modified a piece of data: Update people set name= ' Fusnow ' where name= ' old Fusnow ';

The things I need to do include:

Generate redo information in redo log buffer (including Redo,undo redo of the table, index or whatever)

Modify Name= ' Fusnow ' in buffer cache, modify undo segment

------------------

Situation 1

If everything is OK, I now commit,commit will trigger LGWR to write the information in redo log buffer to the redo log file of disk, if this operation completes successfully, then my data is safe, now if the system crashes, although may lose the buffer Cache in the dirty data, but can be found in the Redo log redo information, so you can recover, of course, this situation does not rollback.

------------------

Situation 2

If LGWR redo log buffer in the process of writing the information to disk redo log file in the course of the system collapsed, that in fact, the user is not successful commit the error, at this time datafile and redo log do not have the information we want, so just, When the system started, I changed the roll forward/back.

------------------

Situation 3

If a commit before, what causes us to flush buffer cache, such as buffer cache full, Oracle to the buffer cache dirty data written to disk, which will trigger the DBWR, But DBWR must trigger the LGWR before writing, write the data in the redo log buffer to redo log file first. The reason is simple, if the LGWR is not triggered, since the dirty data for my changes include table changes and undo changes, and Dbwr probably didn't write the dirty data to disk in one IO, if that's the case, we wrote the table changes before we could write undo dirty data. The database collapsed, and now our state is datafile inside have changed table data, no undo data, redo inside no redo information, because I was no commit, so to roll back, but this situation is impossible, because undo lost, The redo that can regenerate undo are also lost. Therefore, DBWR must trigger LGWR.

If in the DBWR trigger LGWR, we first wrote the table changes, before the time to write undo dirty data when the database collapsed, we are actually first roll forward, through the redo to generate undo, and then rollback, through the undo rollback transaction.

Of course, some brothers have also mentioned that the order is 1.roll forward, 2.open database, 3.rollback, I think this is mainly Oracle in order to save time, because the design according to 1.roll forward, 2.rollback, 3. The order of open database should also be OK, but this is slower, we can completely open the database at the end of roll forward, then let the user access to other parts of the databases, let Smon slowly rollback, At this point, if the user wants to access the data being rolled back will be blocked. Of course, in fast mode, Oracle prioritizes the blocks that users want to access, allowing users to access the data that is being rollback as quickly as possible. Rollback

Case Study (2)

Suppose you have an action statement:

Update GAOJF set name= ' Exitgogo ' where name= ' Old_exitgogo ';

This statement is executed in this way:

1: First check name= ' Old_exitgogo ' whether recorded in buffer cache, if not, read into the buffer.

This article URL address: http://www.bianceng.cn/database/Oracle/201410/45542.htm

2: The transaction segment is allocated in the corresponding Rollback segment Transaction table in the rollback segment table space, which generates redo information.

3: This operation also generates redo information and records write redo buffer by reading from the rollback segment or by creating a name= ' Old_exitgogo ' in buffer or buffer cache.

4: In the data buffer modifies name= ' Exitgogo ', this operation's log information is also written to redo buffer.

5: It is important to record the submission in redo buffer when the user submits, and to mark the transaction as inactive (inactive) in the rollback segment.

As you can see, redo and undo occur alternately during a transaction, and redo buffer first records the data before the transaction changes and the changed data, then writes the data before the change to the rollback segment before modifying the data in the data buffer.

Following the instance crash, first forward, then open, and then the rollback of the details of the process described below:

When the above statement executes to the fourth step, there is some reason for Oracle to flush buffer cache, such as buffer cache full time and so on, at this point, Oracle to the dirty data to disk, that is, this time triggered the DBWR write process, And because DBWR must trigger LGWR before writing, the first 4 steps of the above statement will be written to the redo file.

At this point, if a database crash occurs, because there is no commit action to occur, that is, there is no fifth step, then the transaction in the database rollback segment will still be activated (active).

During a database reboot, the background process Smon scans the undo segment header, and the execution statement above is found to be active, so the uncommitted activity transactions are marked as dead.

Roll forward may occur in the following two situations:

(1): If the above statement in the implementation of the third step, the database crash, then the undo rollback segment recorded in the transaction before the mirror data will be lost, the database in the start-up process, will first occur rollforward, according to redo file records of information, in the rollback segment to generate name= ' old _exitgogo ' 's Front mirror. This is why Redo records the undo information.

(2): If the above statement is submitted, the DBWR process has not come and will modify the information to write to the data file, the database collapsed, then the database after the restart also to carry out roll forward, at this time according to the Redo log file update data files. That is, the changes to the above statements take effect, so as long as the submitted data is not lost.

The database can then open.

There are two scenarios in which the rollback will occur:

(1): Background process Smon found dead transactions, according to the situation to gradually roll back.

(2): Because the database is open, there may be many user processes accessing these dead transaction blocks. At this point, these foreground processes will go to undo segment to get the mirrored data, such as the value of the name= ' Old_exitgogo ' above, and then modify the data buffer to complete the rollback. The process itself also generates redo, so the rollback operation costs a lot.

At this point, the roll forward of the database startup process and the rollback operation is complete.