|In Chapter 8."Recovering a Database", the following new section on |using the suspended I/O function is to be added:
|db2inidb is a new tool shipped with DB2 that can perform crash recovery |and put a database in rollforward pending state.
|Suspended I/O supports continuous system availability by providing a full |implementation for online split mirror handling, that is, splitting a mirror |without shutting down the database. If a customer cannot afford doing offline |or online backups on a large database, backups or system copies can be done |from a mirror image by using suspended I/O and split mirror.
|Depending on how the storage devices are being mirrored, the uses of db2inidb |will vary. The following uses assume that the entire database is mirrored |consistently through the storage system.
|In a multi-node environment, the db2inidb tool must be run on |every partition before the split image can be used from any of the partitions. |The db2inidb tool can be run on all partitions simultaneously.
|The objective here is to have a clone of the |primary database to be used for read-only purposes. The following procedure |describes how a clone database may be made: |
| db2 set write suspend for database
| db2 set write resume for database
|After running the command, the |database on the primary system should be back to a normal state.
| db2start
|db2inidb database_name AS SNAPSHOT
|
|You can also use this process for an offline backup, |but if restored on the primary system, this backup cannot be used to roll |forward, because the log chain will not match. |
|As the mirrored (standby) |database is continually rolling forward through the logs, new logs that are |being created by the primary database, are constantly fetched from the primary |system. The following procedure describes how the split mirror can be used |as a standby database: |
|
|The following procedure describes |how to use the mirrored system as a backup image to restore over the primary |system: |
| db2start
|db2inidb database_alias AS MIRROR
|In Chapter 8,"Recovering a Database," the following is a new section |about incremental backup and recovery: | | | |
|As the size of databases, and particularly warehouses, continues to expand |into the terabyte and petabyte range, the time and hardware resources required |to back up and recover these databases are also growing substantially. Full |database and table space backups are not always the best approach when dealing |with large databases, because the storage requirements for multiple copies |of such databases are enormous. Consider the following issues: |
|DB2 now supports incremental backup and recovery (but not of long field |or large object data). An incremental backup |is a backup image that contains only pages that have been updated since the |previous backup was taken. In addition to updated data and index pages, each |incremental backup image also contains all of the initial database meta-data |(such as database configuration, table space definitions, database history, |and so on) that is normally stored in full backup images.
|Two types of incremental backup are supported: |
|The key difference between incremental and delta backup images is their |behavior when successive backups are taken of an object that is continually |changing over time. Each successive incremental image contains the entire |contents of the previous incremental image, plus any data that has changed, |or is new, since the previous backup was produced. Delta backup images contain |only the pages that have changed since the previous image was produced.
|Combinations of database and table space incremental backups are permitted, |in both online and offline modes of operation. Be careful when planning |your backup strategy, because combining database and table space incremental |backups implies that the predecessor of a database backup (or a table space |backup of multiple table spaces) is not necessarily a single image, but could |be a unique set of previous database and table space backups taken at different |times.
|To rebuild the database or the table space to a consistent state, the recovery |process must begin with a consistent image of the entire object (database |or table space) to be restored, and must then apply each of the appropriate |incremental backup images in the order described below (see the "Restore |Method" section).
|To enable the tracking of database updates, DB2 supports a new database |configuration parameter, TRACKMOD, which can have one of two accepted values: |
|The default TRACKMOD setting for existing databases is NO; |for new databases, it is YES.
|The granularity of the tracking is at the table space level for both SMS |and DMS table spaces.
|Although minimal, the tracking of updates to the database can have an impact |on the run-time performance of transactions that update or insert data.
|A restore operation from incremental backup images always consists of the |following steps: |
|The target image of the incremental restore operation |must be accessed twice to ensure that the database is initially configured |with the correct history, database configuration, and table space definitions |for the database that will be created during the restore operation. In cases |where a table space has been dropped since the initial full database backup |image was taken, the table space data for that image will be read from the |backup images but ignored during incremental restore processing. |
|For example:
| 1. db2 restore database sample incremental taken at <ts> | | where: | <ts> points to the last incremental backup image to be restored | | 2. db2 restore database sample incremental taken at <ts1> | | where: | <ts1> points to the initial full database (or table space) image | | 3. db2 restore database sample incremental taken at <tsX> | | where: | <tsX> points to each incremental backup image in creation sequence | | 4. Repeat Step 3, restoring each incremental backup image up to and including image <ts>
|In cases where a database restore operation is being attempted, and table |space incremental backup images have been produced, the table space images |must be restored in the chronological order of their backup time stamps.
|DB2 now uses multiple agents to perform both crash recovery and database |rollforward recovery. You can expect better performance during these operations, |particularly on symmetric multi-processor (SMP) machines; using multiple agents |during database recovery takes advantage of the extra CPUs that are available |on SMP machines.
|The new agent type introduced by this enhancement is db2agnsc. DB2 chooses |the number of agents to be used for database recovery based on the number |of CPUs on the machine. For SMP machines, the number of agents used is (number |of CPUs + 1). On a machine with a single CPU, three agents are used for |more efficient reading of logs, processing of log records, and prefetching |of data pages.
|DB2 distributes log records to these agents so that they can be reapplied |concurrently, where appropriate. The processing of log records is parallelized |at the page level (log records on the same data page are processed by the |same agent); therefore, performace is enhanced, even if all the work was done |on one table.
|Support is now available for database backup to (and database restore from) |local named pipes on UNIX based systems. Both the writer and the reader of |the named pipe must be on the same machine. The pipe must exist and be located |on a local file system. Because the named pipe is treated as a local device, |there is no need to specify that the target is a named pipe. Following is |an AIX example:
| 1. Create a named pipe: | mkfifo /u/dbuser/mypipe | | 2. Use this pipe as the target for a database backup operation: | db2 backup db sample to /u/dbuser/mypipe | | 3. Restore the database: | db2 restore db sample into mynewdb from /u/dbuser/mypipe
|DB2 now supports a full offline database backup on the split mirrored copy |of a database. Online backup is not supported and is not necessary because |the database, which is in rollforward pending state, is unavailable. When |a split mirrored backup image is restored, it must be rolled forward because |there may have been active transactions when the split occurred.
|Once a database has been split, the db2inidb |utility must be used to specify one of the following options: |
|Following are some usage scenarios: |
|The objective here is to have a read-only |clone of the primary database that can be used, for example, to create reports. |To do this, follow these steps: |
| db2 set write suspend for database
| db2 set write resume for database
|The database on the primary system should now be back to a normal state.
| db2start
| db2inidb <db_name> as snapshot
|You can also use this process for an offline backup, but if restored |on the primary system, this backup cannot be used to roll forward, because |the log chain will not match. |
|The idea here is that |the mirrored (standby) database is continually rolling forward through the |logs, and even new logs that are being created by the primary database are |continually fetched from the primary system. To use the split mirror as a |standby database, follow these steps: |
| db2 set write suspend for database
| db2 set write resume for database
|The database on the primary system should now be back to a normal state.
| db2inidb <db_name> as standby
| db2 rollforward db <db_name> to end of logs
|The following |procedure describes how to use the mirrored system as a backup image to restore |the primary system: |
| db2start
| db2inidb <dbname> as mirror
|
|Performing an offline |backup on the split mirror without performing crash recovery means that you |can restore this backup image on top of the primary system. To do this, follow |these steps: |
| db2 set write suspend for database
| db2 set write resume for database
|The database on the primary system should now be back to a normal state.
| db2start
| db2inidb <db_name> as standby
| db2 backup database <db_name>
|This results in an implicit database connection, but does not initiate |DB2 crash recovery. |
|DB2 now supports the closing (and, if the user exit option is enabled, |the archiving) of the active log for a recoverable database at any time. |This allows you to collect a complete set of log files up to a known point, |and then to use these log files to update a standby database.
|You can initiate on demand log archiving by invoking the new DB2 ARCHIVE |LOG command, or by calling the new db2ArchiveLog |API.
|In Chapter 8,"Recovering a Database," the following new section on |using the suspended I/O function is to be added:
|DB2 now supports log mirroring at the database level. Mirroring log files |helps protect a database from: |
|If you are concerned that your active logs may be damaged (as a result |of a disk crash), you should consider using a new DB2 registry variable, DB2_NEWLOGPATH2, |to specify a secondary path for the database to manage copies of the active |log, mirroring the volumes on which the logs are stored.
|The DB2_NEWLOGPATH2 registry variable allows the database to write |an identical second copy of log files to a different path. It is recommended |that you place the secondary log path on a physically separate disk (preferably |one that is also on a different disk controller). That way, the disk controller |cannot be a single point of failure.
|DB2_NEWLOGPATH2 can be enabled (set to 1) or disabled (set |to 0). The default value is zero. If this variable is set to 1, the secondary path name is the current value of the LOGPATH variable |concatenated with the character 2. For example, in an SMP environment, |if LOGPATH is /u/dbuser/sqllogdir/logpath, the secondary log path |will be /u/dbuser/sqllogdir/logpath2. In an MPP environment, if |LOGPATH is /u/dbuser/sqllogdir/logpath, DB2 will append the node |indicator to the path and use /u/dbuser/sqllogdir/logpath/NODE0000 |as the primary log path. In this case, the secondary log path will be /u/dbuser/sqllogdir/logpath2/NODE0000.
|When DB2_NEWLOGPATH2 is first enabled, it will not actually be used |until the current log file is completed on the next database startup. This |is similar to how NEWLOGPATH is currently used.
|If there is an error writing to either the primary or secondary log path, |the database will mark the failing path as "bad", write a message to the db2diag.log file, and write subsequent log records |to the remaining "good" log path only. DB2 will not attempt to use the "bad" |path again until the current log file is completed. When DB2 needs to open |the next log file, it will verify that this path is valid, and if so, will |begin to use it. If not, DB2 will not attempt to use the path again until |the next log file is accessed for the first time. There is no attempt to synchronize |the log paths, but DB2 keeps information about access errors that occur, |so that the correct paths are used when log files are archived. If a failure |occurs while writing to the remaining "good" path, the database abends.
|Support is now available for cross platform backup and restore support |between Sun Solaris and HP. When you transfer the backup image between systems, |you must transfer it in binary mode. On the target system, the database must |be created with the same code page/territory as the system on which the original |database was created.
|Replace the second paragraph in this section with:
| When files are linked, the Data Links servers schedule them to be copied | asynchronously to an archive server such as ADSM, or to disk. | When the backup utility runs, DB2 ensures that all files scheduled | for copying have been copied. At the beginning of backup processing, | DB2 contacts all Data Links servers that are specified in the DB2 | configuration file. If a Data Links server has one or more linked files | and is not running, or stops running during the backup operation, the backup | will not contain complete DATALINK information. The backup operation | will complete successfully. Before the Data Links server can be marked | as available to the database again, backup processing for all outstanding | backups must complete successfully. If a backup is initiated when there | are already twice the value of num_db_backups (see below) outstanding | backups waiting to be completed on the Data Links server, the backup | operation will fail. That Data Links server must be restarted | and the outstanding backups completed before additional backups are allowed.
|Replace paragraphs beginning with:
| When you restore a database or table space and do not specify | the WITHOUT DATALINK... | | and | | When you restore a database or table space and you do specify | the WITHOUT DATALINK option...
|with:
| When you restore a database or table space, the following conditions | must be satisfied for the restore operation to succeed: | | o If any Data Links Server recorded in the backup file is not running, | the restore operation will still complete successfully. | | Tables with DATALINK column information that are affected by the missing | Data Links server will be put into datalink reconcile pending state | after the restore operation (or the rollforward operation, if used) completes. | Before the Data Links servers can be marked as available to the database | again, this restore processing must complete successfully. | | o If any Data Links Server recorded in the backup file stops running during | the restore operation, the restore operation will fail. The restore can | be restarted with the Data Links Server down (see above). | | o If a previous database restore operation is still incomplete on any | Data Links server, subsequent database or table space restore operations | will fail until those Data Links servers are restarted, and the incomplete | restore is completed. | | o Information about all DATALINK columns that are recorded in the backup | file must exist in the appropriate Data Links servers' registration tables. | | If all the information about the DATALINK columns is not recorded | in the registration tables, the table with the missing DATALINK column | information is put into datalink reconcile not possible state after | the restore operation (or the roll-forward operation, if used) completes. | | If the backup is not recorded in the registration tables, it may mean | that the backup file that is provided is earlier than the value for | num_db_backups and has already been "garbage collected". This means that | the archived files from this earlier backup have been removed and cannot | be restored. All tables that have DATALINK columns are put into datalink | reconcile pending state. | | If the backup is not recorded in the registration tables, it may mean that | backup processing has not yet been completed because the Data Links server | is not running. All tables that have DATALINK columns are put into datalink | reconcile pending state. When the Data Links server is restarted, | backup processing will be completed before restore processing. | | The table remains available to users, but the values in the DATALINK | columns may not reference the files accurately (for example, a file | may not be found that matches a value for the DATALINK column). If you | do not want this behavior, you can put the table into check pending state | by issuing the "SET CONSTRAINTS for tablename TO DATALINK RECONCILE PENDING" | statement.
|If, after a restore operation, you have a table in datalink reconcile not |possible state, you can fix the DATALINK column data in one of the ways suggested |under "Removing a Table from the Datalink_Reconcile_Not_Possible State".
|The note at the bottom of the first paragraph remains the same.
|Add the following at the end of this section:
| It is strongly recommended that the datalink.cfg file be archived | to cover certain unusual recovery cases, since the datalink.cfg file | in the database backup image only reflects the datalink.cfg as of | the backup time. Having the latest datalink.cfg file is required | to cover all recovery cases. Therefore, the datalink.cfg file must | be backed up after every ADD DATALINKS MANAGER or DROP DATALINKS MANAGER | command invocation. This would help to retrieve the latest | datalink.cfg file, if the latest datalink.cfg file is not available on disk. | | If the latest datalink.cfg file is not available on disk, replace | the existing datalink.cfg file (restored from a backup image) with the latest | datalink.cfg file that was archived before running a rollforward operation. | Do this after the database is restored.
|You can only restore without rolling forward at the database level, not |the table space level. To restore a database without rolling forward, you |can either restore a nonrecoverable database (that is, a database that uses |circular logging), or specify the WITHOUT ROLLING FORWARD parameter on the |RESTORE DATABASE command.
|If you use the restore utility with the WITHOUT DATALINK option, all tables |with DATALINK columns are placed in datalink reconcile pending (DRP) state, |and no reconciliation is performed with the Data Links servers during the |restore operation.
|If you do not use the WITHOUT DATALINK option, and a Data Links server |recorded in the backup file is no longer defined to the database (that is, |it has been dropped using the DROP DATALINKS MANAGER command), tables that |contain DATALINK data referencing the dropped Data Links server are put in |DRP state by the restore utility.
|If you do not use the WITHOUT DATALINK option, all the Data Links servers |are available, and all information about the DATALINK columns is fully recorded |in the registration tables, the following occurs for each Data Links server |recorded in the backup file: |
|
|If you restore, then roll forward the database or table space to the end |of the logs (meaning that all logs are provided), a reconciliation check is |not required unless at least one of the Data Links servers recorded in the |backup file is not running during the restore operation. If you are not sure |whether all the logs were provided for the roll-forward operation, or think |that you may need to reconcile DATALINK values, do the following: |
| SET CONSTRAINTS FOR tablename TO DATALINK RECONCILE PENDING
|This puts the table into datalink reconcile pending state and check
|pending state.
| SET CONSTRAINTS FOR tablename IMMEDIATE CHECKED
|This takes the table out of check pending state, but leaves it in datalink
|reconcile pending state. You must use the reconcile utility to take the table
|out of this state.
||It may happen that the backup file contains DATALINK data that refers to |a DB2 Data Links Manager (that is, a DB2 Data Links Manager was registered |to the database when the backup was taken) that has been dropped from the |database. For each table space being rolled forward that contains at least |one table with DATALINK data referencing the dropped DB2 Data Links Manager, |all tables are put in DRP state by the rollforward utility.
|The following table shows the different types of recovery that you can
|perform, the DB2 Data Links Manager processing that occurs during restore and roll-forward processing,
|and whether you need to run the Reconcile utility after the recovery is complete:
|
Type of Recovery | DB2 Data Links Manager Processing during Restore | DB2 Data Links Manager Processing during Rollforward | Reconcile |
---|---|---|---|
Non-recoverable database (logretain=NO) | |||
Database restore of a complete backup, all Data Links Servers up | Fast reconcile is performed | N/A | Can be optionally run if problem with file links is suspected |
Database restore using WITHOUT DATALINK option | Tables put in Datalink_Reconcile _Pending state | N/A | Required |
Database restore of a complete backup, at least one Data Links server down | Fast reconcile is performed only on those tables in table spaces that do not have links to a Data Links server that is down, other tables put in Datalink_Reconcile_Pending state | NA | Required for tables in table spaces with links to the Data Links server that is down |
Database restore of an incomplete backup, all Data Links servers up | Fast reconcile is not performed, all tables with DATALINK columns put in Datalink_Reconcile_Pending state | NA | Required |
Recoverable database (logretain=YES) | |||
Database restore using WITHOUT ROLLING FORWARD option, using a complete backup, all Data Links servers up | Fast reconcile is performed | N/A | Optional |
Database restore using WITHOUT ROLLING FORWARD and WITHOUT DATALINK options, using a complete or incomplete backup, Data Links servers up or down | Tables put in Datalink_Reconcile _Pending state | N/A | Required |
Database restore using WITHOUT ROLLING FORWARD option, using a complete backup, at least one Data Links server down | Fast reconcile is performed only on those tables in table spaces that do not have links to the Data Links servers that are down, other tables put in Datalink_Reconcile_Pending state | N/A | Required on tables in table spaces with links to the Data Links servers that are down |
Database restore using WITHOUT ROLLING FORWARD option, using an incomplete backup, Data Links servers up or down | Fast reconcile is not performed, all tables with DATALINK columns put into Datalink_Reconcile_Pending state | N/A | Required |
Database restore and roll forward to end of logs, using a complete backup, all Data Links servers up | No action | No action | Optional |
Database restore and roll forward to end of logs, using a complete backup, at least one Data Links server down during roll forward processing | No action | No action | Optional |
Database restore and roll forward to end of logs, using a complete or an incomplete backup, any Data Links server down during restore | No action | All tables with DATALINK columns put into Datalink_Reconcile_Pending state | Required for all tables with DATALINK columns |
Database restore and roll forward to end of logs, using an incomplete backup, all Data Links servers up during restore | No action | No action | Optional |
Database restore and roll forward to end of logs, using a complete or an incomplete backup, all Data Links servers up, backup unknown at any Data Links server | No action | All tables in table spaces with links to a Data Links server where the backup is unknown put in Datalink_Reconcile_Pending state | Required |
Table space restore and roll forward to end of logs, using a complete backup, all Data Links servers up | No action | No action | Optional |
Table space restore and roll forward to end of logs, using a complete backup, at least one Data Links server down during roll forward processing | No action | No action | Optional |
Table space restore and roll forward to end of logs, using a complete or an incomplete backup, any Data Links server down during restore processing | No action | All tables in table spaces with links to any Data Links server that is down put into Datalink_Reconcile_Pending state | Required for tables in table spaces with links to any Data Links server that is down |
Table space restore and roll forward to end of logs, using an incomplete backup, all Data Links servers up | No action | No action | Optional |
Database restore and roll forward to a point in time, using a complete or an incomplete backup, Data Links servers up or down during restore and/or roll forward processing | No action | Tables put in Datalink_Reconcile _Pending state | Required |
Table space restore and roll forward to a point in time, using a complete or an incomplete backup, Data Links servers up or down during restore and/or rollfoward processing | No action | Tables put in Datalink_Reconcile _Pending state | Required |
Database restore to a different database name, alias, hostname, or instance with no roll forward (NOTE1) | Tables put in Datalink_Reconcile _Not_Possible state | N/A | Optional, but tables in Datalink_Reconcile _Not_Possible state must be manually fixed |
Database restore to a different database name, alias, hostname or instance, and roll forward | No action | Tables put in Datalink_Reconcile _Not_Possible state | Optional, but tables in Datalink_Reconcile _Not_Possible state must be manually fixed |
Database restore from an unusable backup (image has been garbage-collected on the Data Links server) with no roll forward (NOTE1), with or without WITHOUT DATALINK option | Tables put in Datalink_Reconcile _Pending state | No action | Required |
Database restore from an unusable backup (image has been garbage-collected on the Data Links server), and roll forward, with or without WITHOUT DATALINK option | No action | Tables put in Datalink_Reconcile _Pending state | Required |
Table space restore from an unusable backup (image has been garbage-collected on the Data Links server), and roll forward | No action | Tables put in Datalink_Reconcile _Pending state | Required |
|Note:
|Following are some situations in which you may need to run the reconcile |utility: |
|In this situation, |tables with DATALINK data will already be in DRP state. You should invoke |the reconcile utility for each of these tables.