Las cuatro fuerzas del univerzo

The five phases that DB2 goes through during restart are:

򐂰 Phase 1: Log Initialization is the start-up phase.

򐂰 Phase 2: Current Status Rebuild is the analysis phase. DB2 is trying to determine the transaction status when it was last stopped.

򐂰 Phase 3: Forward Log Recovery scans the log in a forward direction and performs a redo operation for all database updates that have not been written to GBP or DASD.

򐂰 Phase 4: Backward Log Recovery backs out database updates for the inflight and in-abort URs. If long running URs exist, this is the phase where DB2 backs out those URs, meaning that this phase can potentially run for a long time.

򐂰 Phase 5: End Restart finishes the processing and makes DB2 ready to start work. DB2 takes a system checkpoint at the end of this phase.

After the End Restart phase is completed, DB2 can accept new work and will perform indoubt resolution with the assistance of the two-phase commit coordinator.

Phase 1: Log Initialization

The first phase of DB2 restart is called the Log Initialization phase. During this phase, DB2 attempts to locate the last log RBA that was written before termination as shown in Figure 7-3 on page 133. Logging continues at the next log relative byte address (RBA) after that.

Note: Indoubt UR is resolved by the coordinating system (CICS, IMS, WebSphere

Application Server, and so on) of the two-phase commit, not by DB2 on its own.

Note: DB2 always goes through these phases, but they can be very short if the system

Figure 7-3 Log Initialization phase

This phase includes processing that starts the DB2 address spaces and loads DB2 load modules into DB2’s MSTR and DBM1 address spaces. It also implicitly starts Internal Resource Lock Manager (IRLM) if IRLM was not explicitly started. The IRLM startup time is typically about one second.

This phase also includes the time spent to open the BSDS and active log data sets. If dual logging is used, both copies of the active log data sets must be opened. After the BSDS and active log data sets are opened, DB2 scans the log to determine the actual endpoint of the log. It uses a pseudo log endpoint stored in the BSDS as the log scan starting point. The pseudo log endpoint value is updated when one of the following situations occur:

򐂰 The log output buffer is ready to wrap.

򐂰 The active log data sets is filled.

򐂰 The system checkpoint is taken.

򐂰 DB2 is terminated normally.

Message DSNJ099I identifies the log RBA at which logging will commence for the current DB2 session. This message DSNJ099I signals the end of the log initialization phase of restart.

Phase 2: Current Status Rebuild

The second phase of restart is called the Current Status Rebuild (CSR) phase. During this phase, DB2 determines the status of objects and units of recovery (UR) at the time of termination. By the end of the phase, DB2 has determined whether any URs were interrupted by the termination.

This phase also includes the forward log scan pass that is used to determine the transaction status and the attributes and the restart REDO log scan points for all the R/W pending Pagesets or Partitions.

DB2 scans the log, starting from the Begin Checkpoint log record for the last completed DB2 system checkpoint. The maximum number of log records that will be scanned is bounded by the DSNZPARM CHKFREQ value.

This phase also rebuilds the database exception status table (known as the DBET). The

X

X

CHKPT BSDS01 BSDS02 Approximate end of LOG READ

LOG

CHKPT SYSTEM FAILURE

environment, DB2 reconstructs the status information and build the list of URs from the log. For example, the DBET records the status if a table space is in Recovery Pending State. In a data sharing environment, DB2 does not use the log to rebuild the status; rather, it gets information from the shared communication area (SCA) structure in a coupling facility. However, DBET log records will be used to rebuild the DBET if the SCA is damaged. At the end of the CSR phase, console message DSNR004I is displayed with all the transaction status information showing how many transactions are inflight, how many are indoubt, and so forth. DB2 can also determine how far it has to go back in the log to start the forward scan, which is the Phase 3 (Forward Log Recovery) of restart.

Phase 3: Forward Log Recovery

Before the Forward Log Recovery (FLR) phase, DB2 will not perform any database updates. The FLR phase is the first phase where the database actually gets modified. During this third restart phase, DB2 completes the processing for all committed changes and database write operations. Figure 7-4 shows how the FLR phase starts processing at the checkpoint preceding the first log records for the oldest indoubt UR, or the oldest redo logpoint for any pageset, and proceeds forward in time from there.

Figure 7-4 Forward Log Recovery phase

Basically, DB2 performs a REDO operation on the pending writes for all transactions. If no indoubt URs exist, DB2 scans the log, starting from the lowest restart REDO log points from all the R/W pagesets. In general, the log scan starting point is the Begin Checkpoint log of the last completed checkpoint.

If indoubt URs exist that are very long-running URs, DB2 has to go back to the oldest indoubt UR to scan the log to reacquire locks. DB2 uses log information to rebuild lock information. During the Forward Log Recovery phase, DB reads the log records and accesses the data pages to see if the changes actually were hardened to the database. This is why DB2 restart can potentially take a long time.

When processing a log record, DB2 has to read the associated data or index page from GBP or DASD into a buffer pool buffer to determine whether the change has been externalized. DB2 uses the log record sequence number (LRSN) stored in the page header and the LRSN value of the log record to determine whether the database update was successfully

externalized to GBP or DASD.

In a non-data-sharing environment, DB2 uses the log data set’s relative byte address (RBA) of the log record as the LRSN value. In a data sharing environment, the LRSN value is derived from the system-generated ascending STCK (Store Clock) value.

Prior to DB2 V6, if a page was not in the DASD subsystem cache, it could take many milliseconds to read the page into the bufferpool using a synchronous read I/O. With the V6 Fast Log Apply List Prefetch technique, reading in a page typically takes just a few

milliseconds. However, even with this enhancement, DB2 still has the overhead of waiting for

X

X

X

X

X

CHECKPOINT PRECEDING OLDEST PENDING WRITES

Oldest in-doubt UR

CHKPT

LOG

the I/O to bring the page into the memory, even if it then determines that it does not need to reapply the change.

At the end of the FLR phase, DB2 externalizes all the changed pages either to a GBP or to DASD.

During phase 3 of restart in a data sharing environment, DB2 also purges the retained page p-locks. This is because they are no longer needed to protect the unwritten data. DB2 also writes log records to change each in-commit UR to complete UR status.

Phase 3: FLR Example

As mentioned previously, DB2 records the LRSN value of the log record in the data page header when a page is updated. For example, when a record is inserted into a table, DB2 writes an insert log record and records the LRSN value of the insert log record in the data page header. During phase 3 of restart, DB2 compares the LRSN value of the log record and the page header LRSN value to determine whether or not the changes were saved to DASD. If not, then redo the changes. Figure 7-5 shows the log records and database records related to three transactions.

Figure 7-5 Example for Forward Log Recovery phase

The committed transaction modified page P4, with 300 as the LRSN value of the log record. During the restart, DB2 reads the Commit log record for the transaction that updated page P4. It then reads page P4 from the database. At this point DB2 discovers that the LRSN for the Commit log record and the LRSN in the page on DASD are different. This means that the update to page P4 was committed, but the write back to DASD had not completed before DB2 went down. As a result, DB2 has to write the updated page to the database on DASD. For pages P6 and P9, no changes to the database are needed because the page LRSN values are the same as the log LRSN values. Despite this, DB2 still has the cost of reading the pages from DASD before it can decide whether or not any changes must be applied.

Phase 4: Backward Log Recovery

During the fourth restart phase, Backward Log Recovery (BLR), DB2 changes previously performed for in-flight or in-abort units of recovery are backed out.

The in-flight and in-abort URs are processed during this phase. An in-abort UR is generated when DB2 fails during a transaction rollback. An in-flight UR occurs if a transaction has not

Note: Fast Log Apply also reads and sorts log records before applying them. It also applies

updates in parallel to the pagesets involved.

BEGIN

UR P4 commtd END UR P6 inabort CHKPT P9 indoubt

LOG RBA 200 300 400 500 600 700 800 100

P4

500

P6

700

P9

BEFORE PH 3 AFTER PH 3 300

_P4

500

_P6

700

_P9

BLR phase, DB2 scans the logs for all log records belonging to the in-flight and in-abort transactions, as shown in Figure 7-6. It then backs out any changes that had been applied to the database, and writes another log record to compensate the (uncommitted) change made earlier. For example, in the case of an insert log record, DB2 actually writes a delete log record to compensate the insert. It might take a long time to do backout if there are long running URs that do not issue frequent commits.

Figure 7-6 Backward Log Recovery phase

Phase 4: BLR Example

Figure 7-7 shows the backout process during restart. Basically, DB2 is UNDOing the changes for the inflight and in-abort URs. The in-abort UR that updated page P6 has a log LRSN value of 500. DB2 writes a compensation log record for this in-abort UR at log LRSN value 800 and changes the P6 page LRSN value from 500 to 800. Depending on whether DB2 consistent restart (see “DB2 consistent restart” on page 138) is being used, DB2 restart might end before all UNDOs have been finished.

Figure 7-7 Example of Backward Log Recovery phase

Phase 5: End Restart processing

DB2 uses claims and drains instead of locking to serialize between Utilities and SQL. If there are indoubt transactions associated with a particular table space, DB2 has to make sure the table space or Index is not being recovered or reorganized by a database utility before in-doubt URs are resolved. Therefore, write claims are made for every table space or Index touched by the indoubt transactions to prevent a utility from taking over until the indoubt is resolved. As a result, no utility can be run until indoubt URs are resolved.

Thousands of DB2 data sets might open at the time DB2 ends. During the restart process, DB2 opens only the data sets that have restart pending activities. DB2 does not open the objects for read-only table spaces or R/W table spaces without a log record for that object. For a R/W object without a log record, or an object without inflight URs or outstanding

X

X

X

X

X

Oldest In-Flight UR

Oldest in-abort UR

X

LOG

CHKPT CHKPT BEGIN

UR P4 commtd END UR P6 inabort CHKPT P9 indoubt LOG RBA 200 300 400 500 600 700 800 300

P4

500

P6

700

P9

BEFORE PH 4 AFTER PH 4 300

_P4

800

_P6

700

_P9

CLR WRITE CLR

uncommitted updates, DB2 versions prior to DB2 V9 still tries to close the SYSLGRNG entries during the End Restart phase because there was a SYSLGRNG entry created on behalf of that object. In DB2 V9, this processing was moved to take place at the first system checkpoint after the restart; this approach allows the restart to complete quicker so that DB2 can start accepting work sooner.

DB2 externalizes all the data that was modified during the BLR phase to GBP/DASD. It will also purge all the remaining retained locks and trigger a system checkpoint to record the current status of the DB2 subsystem. After the End Restart phase, DB2 is then available for new work.

In document LISTADO DE TEMAS Revisión 1. Marzo 2009 (página 45-52)