Section 15.6. An Overview of a Page Change

15.6. An Overview of a Page Change

We ask a lot of RDBMSs. We want them to be big and fast but to always ensure that the data is in a consistent state. To accomplish the speed requirement, they've got to keep lots of things in memory, but to ensure the integrity requirement, they've got to be very careful. It's difficult to juggle knives without cutting off a finger or two.

Figure 15-4. Anatomy of a page change

Please refer to Figure 15-4 throughout this section. It shows that there are four main storage areas of an RDBMS. There is the datafile itself, the rollback log, the transaction log, and shared memory. Shared memory is further divided into the data buffer, the rollback log buffer, and the transaction log buffer. (Other elements could be in shared memory as well. Only relevant elements are listed here.) Not all RDBMSs work exactly this way, but they are all similar. What happens when a user enters a transaction? Before anything happens, the transaction and what it's going to change is recorded in the transaction log. Then, for each page that needs to be changed, the following steps are taken (note that the list's numbers relate to the numbers in the figure):

1. The RDBMS reads the page that is to be modified and loads it into the data buffer. Until proper safeguards have been put in place, this is where the page stays for a while.

2. The transaction then wants to change the page, but first it saves a copy of what it looked like prior to changing it. This before image is placed in the rollback log buffer.

3. The after image of the page is recorded in the transaction log buffer.

4. The transaction can now change the actual page that it wants to change. This change is made only to the copy of the page that is stored in the data buffer. Recording the change in the transaction log buffer before actually making the change is a safety measure.

5. Notice that up to this point, no changes have been made to disk. If the system were to crash right now, the disks would have no record of this transaction. Before the system can make any changes on disk, it needs to make sure the before image is safe. This is because it will need that before image to roll back this change if it doesn't complete due to a canceled transaction or a rebooted system. To ensure that the before image will be available, it flushes the rollback log buffer to the physical rollback log (the log on disk).

6. The after image of the page is now flushed to the physical transaction log. This image will be necessary if the transaction needs to be redone.

7. Now that the system has safely preserved the before image and after image of the page to be changed, it can flush the changed page to disk.

At some point, the transaction is committed. This fact is immediately recorded in the transaction log. That way, the system knows that the entire transaction completed, and should redo it in case of a system crash. This process ensures that no matter what time the system crashes (and it will crash), the system will remain in a consistent state.