Outline

• More on Checkpoints
• Quiz
• Archive Logs
• DB2 Start-up and Termination

Introduction

• Last week, we looked at concurrency control in DB2.
• We looked at different kinds of locking.
• We discussed isolation levels.
• We looked at claims and drains and latches.
• We then began to talk about logging and recovery in DB2
• We discussed undo log records, redo log records, and we just started talking about checkpoints.
• Today we are going to finish talking about checkpoints and logging and recovery. Then we will discuss the start and restart process of DB2.

What does a checkpoint look like?

The main components of a checkpoint is as follows:

• A log record that denotes the beginning of the checkpoint. BEGIN CHECKPOINT
• A list of information about each active URs.
• Then one record of information about each open table space and index space. This helps to locate the earliest UR with outstanding writing request for a forward recovery
• Finally, one has an END CHECKPOINT record.

What happens during a checkpoint?

• DB2 checkpoints are taken in a way that it neither stops the normal processing of the URs nor forces I/O.
• It simply summarizes the status of the on-going URs and I/O, and records them down onto DB2 logs.
• This process takes a while, and upon completion DB2 writes an END CHECKPOINT log record.
• The start and end checkpoint log relative byte address (RBA) in the log file are registered in BSDS.
• As the transactions are going on, their logs keep flushing out to the shared log file; so checkpointing and these operations interleave with each other.

Building an Undo List with Checkpoint

• Start from the last complete checkpoint (tc1), get a list of outstanding URs
• Forward scan logs until the end, update the list
• The final list contains all the outstanding URs at system failure

Build Redo List with Checkpoints

• Each checkpoint contains information about
  • Open data set
  • URs that update the data set
• With this information, one can get:
  • The oldest UR that updates an open data set, which is also the oldest UR that has not yet been written out
  • The furthest point that the recovery manager can start for redo

When to Take Checkpoints

Unlike a unit of recovery record, which is specified for transactions and driven by SQL statements, a checkpoint is a system-wide event. It can be scheduled by a system parameter, or triggered by a coordinator like IMS/DC, CICS, DB2's LOGLOAD, or by stopping DB2, etc. Checkpoints are also taken:

• Periodically during normal operations, with a predefined interval. (This is what we just said; however, we shouldn't set this period too small as checkpoints themselves, as they write to the logs, have an overhead.)
• Active log switch
• End of restart DB2
• Normal termination of DB2

Other DB2 Logs

• Page set control records primarily register the allocation, opening, and closing of every page set (table space or index space).
• This information is stored in the DB2 directory (SYSIBM.SYSLGRNX) for use while DB2 is running.
• It is also registered in the logs so that it is available at restart.

Quiz

Which of the following statements is true?

1. Intent exclusive locks are usually row level locks
2. The default isolation level for applications in DB2 is Cursor Stability
3. One cannot tell from the logs whether or not DB2 crashed during a recovery.

Using Archives to Resolve Media Failures

• Disasters might cause media failures, making data on the disk unavailable
• To protect against media failures, we are thus led to a solution involving archiving -- maintaining a copy of the database separate from the database itself. So when there is a media failure, the database may be restored to the previous state.
• As the archive might not be perfectly up to date, active logs, in addition to archive logs, help to restore to a more recent state.
• Some DB2 customers also continuously set data offsite by using such features as remote data mirroring so that there are current copies of the log (and sometimes tables) at a remote site at all times.

Archiving Approaches

• Offline copy -- Shut down the database and make a copy. Keep the copy in a remote site. Restore the database to the state at which the offline copy was taken
• Online copy -- These are used because we can't typically stop the db for long enough to make an offline copy. So instead, we try to make a copy of the database that has transactions going on, combined with the logs taken down during the archiving process
• For an online copy, when it is necessary to restore the database from the archive, the log entries made before and during the dump can then be used to sort things out and restore the database to a consistent state.

What to Archive?

You can use the new BACKUP SYSTEM utility to back up an entire DB2 subsystem or an entire DB2 data sharing group.

The BACKUP SYSTEM utility provides two options that you can specify:

• Full copy (full system backup) -- contains both logs and databases. One can recover the system to the point-in-time (PIT) at which the copy was taken. After restoring the backups, you can use a normal DB2 restart to bring the system back to the consistent state. The DB2 restart processing will take care of any outstanding units of work, by either completing their commit processing, or rolling back the changes they made so far (in case they did not reach a commit point).
• Data only -- copies only the DB, without the log. For this, you need to use the RESTORE SYSTEM utility to recover the system to an arbitrary point in time

Data Copy : Full or Incremental

• The DB2 recovery concept is based on the assumption that table spaces are regularly backed up by creating image copies using the COPY utility.
• By means of the COPY utility one can create either FULL IMAGE COPIES (FICs) or INCREMENTAL IMAGE COPIES (IICs).
• Full Image Copy -- A full image copy consists of all pages of the table space, regardless of whether they have been changed. This is done by specifying FULL YES on the COPY utility control statement. Note that FULL YES is the default option.
• Incremental Image Copy -- An incremental image copy contains only the pages that have been changed since the previous full or incremental image copy. Incremental image copies require that a previous full copy existed for the table space. This is done by specifying FULL NO on the COPY utility control statement.
• SYSIBM.SYSCOPY -- Image copies are sequential data sets. Each image copy is recorded in the table SYSIBM.SYSCOPY in the DB2 Catalog. Each image copy is a row in this table. Column ICTYPE specifies the type of image copy taken: A full image copy has an ICTYPE of F. An incremental image copy has an ICTYPE of I.

Recovery Process

• Table spaces are recovered by means of the RECOVER utility.
• When recovering a table space, the RECOVER utility performs two major phases, the RESTORE phase and the LOGAPPLY phase.
• By means of the rows in SYSIBM.SYSCOPY, the RECOVER utility determines the full image copy it needs as a basis for the requested recovery.
• RESTORE Phase -- During the RESTORE phase, it merges the full image copy with its incremental image copies to form the basis for the restored table space. Pages in an incremental image copy replace the corresponding pages in either the full image copy or some earlier incremental image copies.
• Note that the restored version of the table space is far from complete, because there are most likely changes to the table space after the latest image copy was taken. These changes are recorded only in the DB2 log.
• LOGAPPLY Phase -- During the LOGAPPLY phase, the appropriate log records are read from the DB2 log and applied to the restored table space.
• This is where SYSIBM.SYSLGRNX comes in handy, because it identifies the range on DB2 logs pertaining to the table space being recovered. DB2 therefore needs to read only these log ranges.

Startup and Restart

• We have now completed what we are going to say about logging and recovery and we are going to start to look at how DB2 startup and restart works.

Getting DB2 Running

• Before starting a DB2, first we need to install each DB2 instance into z/OS. Installation is the process of preparing DB2 to operate as a z/OS subsystem.
• Most basic parameters for DB2 are specified at installation. Some examples include the name of the instance, data sharing groups, command prefix, defining DB2 catalogs, etc.
• After installation, the new DB2 subsystem is registered into the z/OS subsystem name list. We need to request a z/OS IPL (Initial Program Load) to make the installation effective. Once installed, DB2 is ready to be started.
• For each DB2 instance installed, during z/OS IPL, DB2 builds the subsystem installation blocks (ERLY block) and loads a copy of DB2 early code.
• The DB2 system can then be started with a START DB2 command on the z/OS console.
• A DB2 instance can be started and stopped over and over again while the definitions, early block and early code remain the same in the system. Only the system administrator can change these definitions.

Configuring a DB2 Instance

• After installation, DB2 provides some user interfaces called installation panels, through which we can configure the DB2 initial startup settings and execution parameters
• The installation panel has an ISPF panel interface. All the input does not generate commands. Instead, it is only an editing interface that helps you to customize the ZPARM file and job stream that result in starting up the JCL (Job Control Language).
• Those parameters include the buffer pool setting, log file settings, checkpoint intervals, etc.

Start-up Sequence

• The DB2 command START DB2 initializes the DB2 subsystem. When the operation is complete, the DB2 subsystem is active and available to provide services to other subsystems (for example, IMS and CICS).
• The z/OS (or MVS) subsystem interface calls the early code of DB2, which works as an entry point for each subsystem instance. The early code thereafter calls other agents, which coordinate the various managers to perform the initialization work.
• The DB2 startup is primarily hierarchical. There is a 'general commander' -- the early code, which calls a series of 'agents' to perform the initialization of each of the DB2 components. The 'agents' thereafter call other lower level managers to perform the tasks.
• The start up is also a staged process that encompasses of the following stages:
  1. The DB2 components (resource managers) initialize themselves.
  2. The resource managers do some further initialization so as to talk to, and cooperate with each other
  3. The recovery manager is invoked to check up on the system. If DB2 was ended in an error condition, it will do necessary work to rebuild the system.
  4. Now, DB2 is ready to accept work.

Types of Termination and Restarts

• DB2 terminates normally in response to the command STOP DB2. If DB2 stops for any other reason, the termination is considered abnormal.
• In a normal termination, DB2 stops all activity in an orderly way. An abnormal termination, or ABEND (abnormal end of task), is said to happen when DB2 does not terminate in an orderly way.
• An ABEND can leave data in an inconsistent state for any of the following reasons:
  • Units of recovery might be interrupted before reaching a point of consistency.
  • Committed data might not be written to external media.
  • Uncommitted data might be written to external media.
• DB2 uses its recovery log and the bootstrap data set (BSDS) to determine what to recover when restarting. The BSDS identifies the active and archive log data sets, the location of the most recent DB2 checkpoint on the log, and the high-level qualifier of the integrated catalog facility catalog name.

Normal Shutdown

• For the normal shut down of a DB2 subsystem, there is time for a shutdown checkpoint and other cleanup activity (see the next page).
• The updates to the log are sent to log DASD; the images of those updates on the database pages are externalized to page set DASD.
• At this point, the log and the database page sets are perfectly synchronized.

During Normal System Shutdown

• Connections are terminated. DB2 can either terminate connections using quiesce (allow connections to finish their unit of work before closing) or force (close connections immediately). e.g., -STOP DDF MODE(FORCE)
• Buffer pools are emptied
• Data sets are closed
• A shutdown checkpoint is taken
• In-progress archives are completed
• BSDS is updated

This whole process might take a while.

The Restart Process

• We are next going to look at restarting DB2.
• There are a couple of main objectives in performing a restart:
  • To establish a new DB2 connection
  • To restore the database to a transaction-consistent state
    • Committed transactions are made effective
    • Complete transactions are rolled back
    • Back out transactions in progress

System Restart Phases

Restart Phases

• Phase 1: Log initialization
• Phase 2: Current Status Rebuild
• Phase 3: Forward log recovery
• Phase 4: Backward log recovery

Restart Type

• Normal Restart
• Recovery Restart

Normal Restart

We next look at the phases of recovery for a normal restart.

• For phase 1 (log init), DB2 uses the initial parameter file, DSNZPARM, to locate and verify the correct BSDSs for the system being started up. Then DB2 verifies that both copies of the BSDS have the same timestamp, and then uses the BSDS information to go directly to the end of the log.
• For phase 2 (CSR), DB2 reinitializes control blocks that describe the units of recovery and the open page sets. But there should have been no URs (unit of recoveries) or page sets open as we did a normal shutdown, so this is trivial.
• For Phase 3 and Phase 4, for a normal shutdown nothing will need to be done.
• Next day we will look at what happens for an abnormal restart.