Professional Documents
Culture Documents
2.5 - DB2 Backup and Recovery
2.5 - DB2 Backup and Recovery
Summer/Fall 2010
Information Management
t1 t2 t3
Perform a Disaster strikes, Database Perform a database restore
database is damaged using the backup image. The
backup restored database is
identical to the database at
database t1
Backup
Image
4
Disk for the Disk for © 2010 IBM Corporation
database logs
Information Management
Bufferpool
Old
Page transactions
indexesto be
Information
updated is retrieved
from disk (if needed)
Circular Logging
■ Primary log files used to record all transactions; reused when transactions are
committed
■ Secondary log files allocated when next primary log file is not available due to active
transactions
■ If both primary and secondary log limit are full and can not be reused, a log full
condition occurs and SQL0964C error message is returned
■ Only full, offline backups of the database are allowed
■ Cannot have roll-forward recovery
2
Primary
logs 1 n
n 3
Active log
file 4 Secondary logs
6 © 2010 IBM Corporation
Information Management
Archival Logging
■ Enable with LOGARCHMETH1 database configuration parameter
■ History of log files is maintained, in order to allow roll forward recovery
and online backup
■ Logs can be optionally archived to an archive location when no longer
active to avoid exhaustion of log directory
Infinite Logging
■ Infinite logging provides infinite active log space
–Enabled by setting LOGSECOND to -1
■ Secondary log files are allocated until the unit of work commits or
storage is exhausted
■ Archived logs can hinder performance for rollback and crash
recovery
■ Database must be configured to use archival logging
■ Up to 256 log files (primary + secondary)
■ Control parameters
–NUM_LOG_SPAN – number of log files an active transaction can
span
–MAX_LOG – Percentage of active primary log file space that a
single transaction could consume
Database Backup
■ Copy of a database or table space
–User data
–DB2 catalogs
–All control files, e.g. buffer pool files,
table space file, database configuration
file
■ Backup modes:
–Offline Backup
• Does not allow other applications or processes to access
the database
• Only option when using circular logging
–Online Backup
• Allows other applications or processes to access the
database
• Available to users during backup
• Can backup to disk, tape, TSM and other storage vendors
SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001
Backup Type:
0 = Full Backup
3 = Tablespace Backup
Incremental Backups
Sunday Mon Tue Wed Thu Fri Sat Sunday
Ful Ful
l l
Cumulative Backups
■ Incremental (a.k.a. cumulative) - Backup of all database data that has changed since the
most recent, successful, full backup operation
■ Incremental Delta - Backup of all database data that has changed since the last
successful backup (full, incremental, or delta) operation.
■ Need to have TRACKMOD database configuration parameter ON
■ Supports both database and table space backups.
■ Suitable for large databases, considerable savings by only backing up incremental
changes.
13 © 2010 IBM Corporation
Information Management
Example:
db2 backup database DS2 to /home/db2inst1/backups compress
Database Recovery
■ Recovery is the rebuilding of a database or
table space after a problem such as media
or storage failure, power interruption, or
application failure.
Types of Recovery
–Crash or restart recovery
• Protects the database from being left inconsistent (power
failure)
–Version recovery
• Restores a snapshot of the database
–Roll forward recovery
• Extends version recovery by using full database and table
space backup in conjunction with the database log files
Example:
SAMPLE.0.DB2INST.NODE0000.CATN0000.20080718131210.001
Incremental Restore
■ Restore a database with incremental backup images
■ AUTOMATIC (recomended) - All required backup images will be applied
automatically by restore utility
■ MANUAL – User applies the required backups manually
– db2ckrst can provide the sequence for applying backups
■ ABORT - aborts an in-progress manual cumulative restore
■ RESTORE DATABASE sample INCREMENTAL AUTOMATIC FROM /db2backup/dir1;
■ ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE;
E-mail: imschool@us.ibm.com
Subject: “DB2 Academic Workshop”
Information Management
Summer/Fall 2010
Information Management
1
t1 t2 t3
Perform a Disaster strikes, Database Perform a database restore
database is damaged using the backup image. The
backup restored database is
identical to the database at
database t1
Backup
Image
4
Disk for the Disk for © 2010 IBM Corporation
database logs
Bufferpool
Old
Page transactions
indexesto be
Information
updated is retrieved
from disk (if needed)
Circular Logging
■ Primary log files used to record all transactions; reused when transactions are
committed
■ Secondary log files allocated when next primary log file is not available due to active
transactions
■ If both primary and secondary log limit are full and can not be reused, a log full
condition occurs and SQL0964C error message is returned
■ Only full, offline backups of the database are allowed
■ Cannot have roll-forward recovery
2
Primary
logs 1 n
n 3
Active log
file 4 Secondary logs
6 © 2010 IBM Corporation
There are two logging strategies, circular logging and archival logging. We'll take a
look at circular logging first.
Circular logging is the default behavior when a new database is created. (The
logarchmeth1 and logarchmeth2 database configuration parameters are set to OFF.)
With this type of logging, only full, offline backups of the database are allowed.
The database must be offline (inaccessible to users) when a full backup is taken.
Circular logging does not allow rolling a database forward through transactions
performed after the last full backup operation. All changes occurring since the last
backup operation are lost. Since this type of restore operation recovers your data to
the specific point in time at which a full backup was taken, it is called version
recovery.
When circular logging is used, records stored in the log buffer are written to primary log
files in a circular manner. Log records are written to the current active log file, and
when that log file becomes full, it is marked as unavailable. When this happens, DB2
uses the next log file in the sequence as the active log file and begins writing to it.
When that log file becomes full, this process is repeated. As transactions are
completed and their changes are externalized to the database, their corresponding
log records are released. When all records in a log file are released, that file is
marked "reusable," and the next time it becomes the active log file, it is overwritten
with new records.
Although primary log files are not marked reusable in any particular order, they are written
to in sequence. When the logging process cycles back to a primary log file that is
marked unavailable, DB2 will allocate a secondary log file and start writing to it. When
the secondary log file becomes full, DB2 will poll the primary log file again. If it is still
unavailable, another secondary log file is allocated. This process continues until
either the primary log file becomes reusable or the maximum number allowed for
secondary log files is reached. If the primary log file has become available, DB2 will
begin writing to it. Meanwhile, records in the secondary log files are eventually
released, and when all connections to the database have been terminated, secondary
log files are destroyed. On the other hand, if the maximum number of secondary log
files has been reached, and the primary log file is still unavailable, all database
activity will stop, an error message is displayed.
Information Management
Archival Logging
■ Enable with LOGARCHMETH1 database configuration parameter
■ History of log files is maintained, in order to allow roll forward recovery
and online backup
■ Logs can be optionally archived to an archive location when no longer
active to avoid exhaustion of log directory
To determine which log extents in the database log path directory are archived
logs, check the value of the loghead database configuration parameter. This
parameter indicates the lowest numbered log that is active. Those logs with
sequence numbers less than loghead are archived logs and can be moved.
You can check the value of this parameter by using the Control Center; or, by
using the command line processor and the GET DATABASE
CONFIGURATION command to view the "First active log file".
Information Management
Infinite Logging
■ Infinite logging provides infinite active log space
–Enabled by setting LOGSECOND to -1
■ Secondary log files are allocated until the unit of work commits or
storage is exhausted
■ Archived logs can hinder performance for rollback and crash
recovery
■ Database must be configured to use archival logging
■ Up to 256 log files (primary + secondary)
■ Control parameters
–NUM_LOG_SPAN – number of log files an active transaction can
span
–MAX_LOG – Percentage of active primary log file space that a
single transaction could consume
You would think that you could avoid running out of log space by
using a large number of secondary log files. However, the
maximum number of primary and secondary log files allowed
(logprimary + logsecond) is 256, and if the size of your log files
is relatively small, you can still run out of log space quickly
when you have very long running transactions. If you are
concerned about running out of log space, you can configure a
database to use infinite logging.
When archival logging is enabled, a log is marked for archival as
soon as it becomes full. However, DB2 leaves the log in the log
directory until it becomes inactive, then renames the file for
reuse. With infinite logging, DB2 still archives the log as soon
as it is full, but it does not wait for it to become inactive before
it renames the file for reuse. This guarantees that the active log
directory will never fill up, because any logs can be reused
once they are filled and archived.
To enable infinite active logging, archival logging must be enabled
and the LOGSECOND database configuration parameter must
be set to -1.
Note that infinite active logging can hinder performance for
rollback and crash recovery as active logs may need to be
retrieved from the archive site.
Information Management
Database Backup
■ Copy of a database or table space
–User data
–DB2 catalogs
–All control files, e.g. buffer pool files,
table space file, database configuration
file
■ Backup modes:
–Offline Backup
• Does not allow other applications or processes to access
the database
• Only option when using circular logging
–Online Backup
• Allows other applications or processes to access the
database
• Available to users during backup
• Can backup to disk, tape, TSM and other storage vendors
If archival logging was used, you would also have the option to
back up database online. During an online backup,
applications and users can still access the database. Backup
to disk, TSM or repository of other storage vendors is
supported in the online mode.
Information Management
SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001
Backup Type:
0 = Full Backup
3 = Tablespace Backup
Incremental Backups
Sunday Mon Tue Wed Thu Fri Sat Sunday
Ful Ful
l l
Cumulative Backups
■ Incremental (a.k.a. cumulative) - Backup of all database data that has changed since the
most recent, successful, full backup operation
■ Incremental Delta - Backup of all database data that has changed since the last
successful backup (full, incremental, or delta) operation.
■ Need to have TRACKMOD database configuration parameter ON
■ Supports both database and table space backups.
■ Suitable for large databases, considerable savings by only backing up incremental
changes.
13 © 2010 IBM Corporation
* Incremental. An incremental backup image is a copy of all database data that has
changed since the most recent, successful, full backup operation. This is also known
as a cumulative backup image, because a series of incremental backups taken over
time will each have the contents of the previous incremental backup image. The
predecessor of an incremental backup image is always the most recent successful
full backup of the same object.
* Delta. A delta, or incremental delta, backup image is a copy of all database data that
has changed since the last successful backup (full, incremental, or delta) of the table
space in question. This is also known as a differential, or non-cumulative, backup
image. The predecessor of a delta backup image is the most recent successful
backup containing a copy of each of the table spaces in the delta backup image.
Which type of backup to use? It depends on your business needs. Delta backup images
require less storage space compared to incremental backup images, but when
restoring a database, delta backup images must be applied in a specific order
as each of them contains non-cumulative data changes.
To enable the tracking of database updates, DB2 supports a new database configuration
parameter, TRACKMOD, which can have one of two accepted values:
* NO. Incremental backup is not permitted with this configuration. Database page
updates are not tracked or recorded in any way. This is the default value.
* YES. Incremental backup is permitted with this configuration. When update tracking
is enabled, the change becomes effective at the first successful connection to the
database. Before an incremental backup can be taken on a particular table space, a
full backup of that table space is necessary.
Information Management
Example:
db2 backup database DS2 to /home/db2inst1/backups compress
A database may become unusable due to a wide variety of hardware or software failures.
Automatic database backup simplifies database backup management tasks for
the DBA by always ensuring that a recent full backup of the database is
performed as needed. It determines the need to perform a backup operation based
on one or more of the following measures:
* You have never completed a full database backup
* The time elapsed since the last full backup is more than a specified number of hours
* The transaction log space consumed since the last backup is more than a specified
number of 4 KB pages (in archive logging mode only).
If the database is enabled for roll-forward recovery (archive logging), then automatic
database backup can be enabled for either online or offline backup. Otherwise, only
offline backup is available. Automatic database backup supports disk, tape, Tivoli®
Storage Manager (TSM), and vendor DLL media types.
Through the Configure Automatic Maintenance wizard in the Control Center or Health
Center, you can configure:
* The requested time or number of log pages between backups
* The backup media
* Whether it will be an online or offline backup.
The automatic database backup feature can be enabled or disabled by using the
auto_db_backup and auto_maint database configuration parameters. In a partitioned
database environment, the automatic database backup runs on each database
partition if the database configuration parameters are enabled on that database
partition.
You can also configure automatic backup using one of the system stored procedures
called AUTOMAINT_SET_POLICY and AUTOMAINT_SET_POLICYFILE.
Information Management
Database Recovery
■ Recovery is the rebuilding of a database or
table space after a problem such as media
or storage failure, power interruption, or
application failure.
Types of Recovery
–Crash or restart recovery
• Protects the database from being left inconsistent (power
failure)
–Version recovery
• Restores a snapshot of the database
–Roll forward recovery
• Extends version recovery by using full database and table
space backup in conjunction with the database log files
Example:
SAMPLE.0.DB2INST.NODE0000.CATN0000.20080718131210.001
Incremental Restore
■ Restore a database with incremental backup images
■ AUTOMATIC (recomended) - All required backup images will be applied
automatically by restore utility
■ MANUAL – User applies the required backups manually
– db2ckrst can provide the sequence for applying backups
■ ABORT - aborts an in-progress manual cumulative restore
■ RESTORE DATABASE sample INCREMENTAL AUTOMATIC FROM /db2backup/dir1;
■ ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE;
E-mail: imschool@us.ibm.com
Subject: “DB2 Academic Workshop”
Information Management
21
Q&A