2.5 - DB2 Backup and Recovery

Information Management Ecosystem Partnerships
IBM Canada Lab
Summer/Fall 2010
DB2® Backup and Recovery
Information Management
© 2010 IBM Corporation

Why Backup my Data?

■ Backing up data is vital for businesses
– Lost information can cause a major crisis or
worse, lead to business failure.
■ Common problems:
– System outage
• Power failure
• Hardware failure
– Transaction failure
• Users may inadvertently corrupt the database
– Media failure
• Disk drive becomes unusable
– Disaster
• Database facility damaged by fire, flooding
or other catastrophe
DB2 backup and recovery methods are designed to
help you keeping your information safe!
2 © 2010 IBM Corporation

Basic Concept of Database Backup and Recovery

■ At t1, a database backup operation is performed
■ At t2, a problem that damages the database occurs
■ At t3, all committed data is recovered
After restore, reapply the

transactions committed
between t1 and t2 using the
Database Database log files.
at logs at
t1 Database continues to t1
process transactions.
Transactions are
recorded in log files
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

DB2 Transaction Logs

■ Keep track of changes made to database objects and their data
■ During the recovery process, DB2 examines these logs and decides which
changes to redo or undo
■ Can be stored in files or on raw devices
DB2 Memory (in RAM)
Package cache Log Buffer

■ The transactions in the log Update
Update
buffer are recorded in the transaction
transaction
log device upon one of the Bufferpool

following events: Page indexes
Old
transactions
– Log buffer is full Information to be
updated is retrieved from
– Number of commits disk (if needed)
reach MINCOMMIT value
– One second has lapsed
4
Disk for the Disk for © 2010 IBM Corporation
database logs
Log File States

■ Active logs
– Transactions that have not been committed or rolled back
■ Online archive logs
– Committed and externalized logs in the active log directory
■ Offline archive logs
– Committed and externalized logs in a separate repository
DB2 Memory (in RAM)
Update OFFLINE Archive Logs
transaction Update
transaction
Bufferpool
Old
Page transactions
indexesto be
Information
updated is retrieved
from disk (if needed)
Disk for Active

5 the Log © 2010 IBM Corporation
database Directory
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
Transactions DB2 Server
Active log path

1
2
Primary
logs 1 n
n 3
Active log
file 4 Secondary logs
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
When all preallocated log files are

filled,more log files are allocated
and used.
Filled log files may be moved to a
different storage location
ONLINE ARCHIVE
Contains information for
committed transactions.
Stored in the ACTIVE
log subdirectory.
ACTIVE – Contains information

for non-committed transactions.
Archive Log Directory Active 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

Database Backup – Syntax
db2 backup database <db_name> <online> to <dest_path>
Online backup example

db2 backup database mydb online to /home/db2inst1/backups
Offline backup example

db2 backup database mydb to /home/db2inst1/backups

Database Backup – File Naming Convention
Alias Instance Catalog Node Year Day Minute Sequence
SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001
Type Node Month Hour Second
Backup Type:
0 = Full Backup
3 = Tablespace Backup

Table space Backup

■ Enables user to backup a subset of database
■ Multiple table spaces can be specified
■ Database must be using archival logging
■ Table space backup can run in both online and offline backup
■ Table space can be restored from either a database backup or
table space backup of the given table space
■ Use the keyword TABLESPACE to specify table spaces
db2 backup database mydb1 TABLESPACE (TBSP1) ONLINE to

/home/db2inst1/backup

Incremental Backups
Sunday Mon Tue Wed Thu Fri Sat Sunday
Ful Ful
l l
Cumulative Backups
Ful Delta Backups Ful

l l
■ 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.
Database Backup – Compression

■ DB2 backups can now be automatically compressed
– Significantly reduce backup storage costs
■ Performance characteristics
– CPU costs typically increased (due to compression computation)
– Media I/O time typically decreased (due to decreased image size)
– Overall backup/restore performance can increase or decrease; depending
on whether CPU or media I/O is a bottleneck
Example:
db2 backup database DS2 to /home/db2inst1/backups compress

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
■ To configure automatic backup
–Graphical user interface tools
• Configure Automatic Maintenance
wizard
–Command line interface
• auto_db_backup
• auto_maint
–Stored procedure
• AUTOMAINT_SET_POLICY system stored procedure

Optimizing Backup Performance

■ DB2 automatically configures these parameters for performance
– Parallelism
• Number of table spaces backed up in parallel
– num_buffers
• Number of buffers used
• Use at least twice as many buffers as backup targets (or
sessions) to ensure that the backup target devices do not have to
wait for data.
– Buffer
• Backup buffer size
■ Allocate more memory to backup utility by increasing utility heap size
(UTIL_HEAP_SZ) configuration parameter.
■ Backup subset of data where possible:
– Table space backups
– Incremental backups
■ Use multiple target devices

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
■ Crash recovery and version recovery are enabled in DB2 by default

DB2 Restore Utility

■ Restore utility is the complement of backup utility
■ Restores database or table space from a previously taken
backup
■ TAKEN AT - Specify the time stamp of the database backup
image. Backup image timestamp is displayed after
successful completion of a backup
■ Without prompting – Overrides any warnings.
Example:
RESTORE DATABASE dbalias FROM <db_path> TAKEN AT 20080718131210

Table space Restore Operation

■ Restored table space is in Roll Forward Pending state and can be either
rolled forward to End of Logs or a Point In Time.
– In case of Point in Time roll forward, table space must be rolled forward to
at least the minimum Point in Time
■ Minimum recovery time can be checked using
– db2 list tablespaces show detail
■ User table space must be in line with catalog table space
– e.g if catalog indicates table T1 exists in table space TSP1, table T1 must
exist in the TSP1 table space, otherwise database becomes inconsistent
■ Every time there is a DDL changed, minimum recovery time for the table
space is revised to indicate the last DDL change.
■ Recommended to take a table space backup after a table space has been
restore to a point in time.
■ Transactions that came after the point in time are lost, therefore take a
table space backup as new point of reference for future recoveries.

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;

IBM Canada Lab
Questions? Summer/Fall 2010
E-mail: imschool@us.ibm.com
Subject: “DB2 Academic Workshop”

IBM Canada Lab
Summer/Fall 2010
DB2® Backup and Recovery
1
In this presentation, we'll talk about how you

can use DB2 backup and recovery utilities
to ensure that your database is always
consistent.
Why Backup my Data?

■ Backing up data is vital for businesses
– Lost information can cause a major crisis or
worse, lead to business failure.
■ Common problems:
– System outage
• Power failure
• Hardware failure
– Transaction failure
• Users may inadvertently corrupt the database
– Media failure
• Disk drive becomes unusable
– Disaster
• Database facility damaged by fire, flooding
or other catastrophe
DB2 backup and recovery methods are designed to
help you keeping your information safe!
Why do we need to backup our data? Data

has become a critical asset for all kinds of
businesses. Without it, most businesses
simply cannot operate.
How does data get lost? Some common
causes include system outage, transaction
failure, media failure, or even natural
disaster.
To help safeguard your data, DB2 provides
data backup and recovery utilities so that
your business can operate in a sustainable
way.
Basic Concept of Database Backup and Recovery

■ At t1, a database backup operation is performed
■ At t2, a problem that damages the database occurs
■ At t3, all committed data is recovered
After restore, reapply the

transactions committed
between t1 and t2 using the
Database Database log files.
at logs at
t1 Database continues to t1
process transactions.
Transactions are
recorded in log files
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
The diagram demonstrates a simple data backup

and recovery.
As displayed in the diagram, at point T1, the

database is backed up. Once the backup process
concludes, your database continues its normal
operation. Data access activities are logged as
they occur.
At a later point down the line, at point T2, your

system crashes and your database is damaged.
Now being at T3, the database is not operational.

To bring your database back up and running, we
need to restore the database with the backup
image taken at T1, and re-apply the transactions
committed since T1 with the log files.
DB2 Transaction Logs

■ Keep track of changes made to database objects and their data
■ During the recovery process, DB2 examines these logs and decides which
changes to redo or undo
■ Can be stored in files or on raw devices
DB2 Memory (in RAM)

■ The transactions in the log Update
Update
buffer are recorded in the transaction
transaction
log device upon one of the Bufferpool

following events: Page indexes
Old
transactions
– Log buffer is full Information to be
updated is retrieved from
– Number of commits disk (if needed)
reach MINCOMMIT value
– One second has lapsed
4
Disk for the Disk for © 2010 IBM Corporation
database logs
A transaction is a sequence of one or more SQL

operations grouped together as a single unit.
Transaction logging is a process used to keep track of
changes made to a database as they occur.
When an update or a delete operation is performed, the

page containing the record to be updated/deleted is
retrieved from storage and copied to the appropriate
buffer pool, where it is then modified by the
update/delete operation.
Once the record has been modified or inserted, a record
reflecting the change is written to the log buffer, which
is another storage area in memory.
DB2 constantly checks to see if the log buffer is full, if
MINCOMMIT commits have been performed, or if one
second has lapsed. If any of these factors have
occurred, the information in the log buffers is written to
the log file on disk.
During a data recovery process, DB2 uses the log files to

decide what changes to redo or undo.
Log File States

■ Active logs
– Transactions that have not been committed or rolled back
■ Online archive logs
– Committed and externalized logs in the active log directory
■ Offline archive logs
– Committed and externalized logs in a separate repository
DB2 Memory (in RAM)
Update OFFLINE Archive Logs
transaction Update
transaction
Bufferpool
Old
Page transactions
indexesto be
Information
updated is retrieved
from disk (if needed)
Disk for Active

5 the Log © 2010 IBM Corporation
database Directory
There are three states for a log file.
A log is considered active if:

● it contains transactions that have not been committed or
rolled back. Or,
● it contains transactions that have been committed but
whose changes have not been externalized to disk. Or.
● it contains transactions that have been rolled back but
whose changes have not been externalized to disk
Active logs are used in crash recovery. Active logs are located
in the database log path directory.
Online archive logs only contain committed and externalized

transactions. In other words, they are no longer active, and
therefore no longer needed for crash recovery. Online
archive logs are still kept in the active log directory.
Offline archive logs are similar to online archive logs,

except they are stored in a separate repository. This is to
save file system and disk drive space. Like the online
archive logs, offline archive logs are used in roll forward
recovery.
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
Transactions DB2 Server
Active log path

1
2
Primary
logs 1 n
n 3
Active log
file 4 Secondary logs
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.
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
When all preallocated log files are

filled,more log files are allocated
and used.
Filled log files may be moved to a
different storage location
ONLINE ARCHIVE
Contains information for
committed transactions.
Stored in the ACTIVE
log subdirectory.
ACTIVE – Contains information

for non-committed transactions.
Archive Log Directory Active Log Directory
Another logging strategy is archival logging.

Archival logging is required for roll forward recovery. Archived logs are logs
that were active but are no longer required for crash recovery. Use the
logarchmeth1 database configuration parameter to enable archival logging.
Taking online backups is only supported if the database is configured for

archival logging. During an online backup operation, all activities against the
database are logged. When an online backup image is restored, the logs must
be rolled forward at least to the point in time at which the backup operation
completed. For this to happen, the logs must have been archived and made
available when the database is restored. After an online backup is complete,
the DB2® database manager forces the currently active log to be closed, and
as a result, it will be archived. This ensures that your online backup has a
complete set of archived logs available for recovery.
The following database configuration parameters allow you to change where

archived logs are stored: The newlogpath parameter, and the logarchmeth1
and logarchmeth2 parameters. Changing the newlogpath parameter also
affects where active logs are stored.
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".
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.
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
Database Backup is a complete copy of your database objects. It

also includes information about the table spaces, containers,
the system catalog, database configuration file, log control file,
and the recovery history file.
DB2 offers two ways of backing up data: offline and online.
When backing up a database in an offline mode, applications

cannot access the database. This is the only option for
database backup if circular logging is used.
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.
Database Backup – Syntax
db2 backup database <db_name> <online> to <dest_path>
Online backup example

db2 backup database mydb online to /home/db2inst1/backups
Offline backup example

db2 backup database mydb to /home/db2inst1/backups
Here we have a few simple examples on how

to issue the backup command at command
line.
The major difference between the online

backup command and the offline backup
command is the keyword “online”.
Database Backup – File Naming Convention
Alias Instance Catalog Node Year Day Minute Sequence
Type Node Month Hour Second
Backup Type:
0 = Full Backup
3 = Tablespace Backup
The following example demonstrates the

naming convention used for backups. As
you can see, the alias of the database,
backup type, instance name, node, catalog
node and current timestamp, help uniquely
identify a particular backup image.
Table space Backup

■ Enables user to backup a subset of database
■ Multiple table spaces can be specified
■ Database must be using archival logging
■ Table space backup can run in both online and offline backup
■ Table space can be restored from either a database backup or
table space backup of the given table space
■ Use the keyword TABLESPACE to specify table spaces
db2 backup database mydb1 TABLESPACE (TBSP1) ONLINE to

/home/db2inst1/backup
In a database where only some of your table

spaces change considerably, you may
choose not to back up the entire
database but only specific table spaces.
Multiple table spaces can be specified at

once. Table space images can be created
only when archival logging is used. If
circular logging is used instead, table space
backup is not supported.
The keyword TABLESPACE in the backup

command indicates this is a table space
backup, not a full database backup.
Incremental Backups
Sunday Mon Tue Wed Thu Fri Sat Sunday
Ful Ful
l l
Cumulative Backups
Ful Delta Backups Ful

l l
■ 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.
Two types of incremental backup are supported:
* 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.
Database Backup – Compression

■ DB2 backups can now be automatically compressed
– Significantly reduce backup storage costs
■ Performance characteristics
– CPU costs typically increased (due to compression computation)
– Media I/O time typically decreased (due to decreased image size)
– Overall backup/restore performance can increase or decrease; depending
on whether CPU or media I/O is a bottleneck
Example:
db2 backup database DS2 to /home/db2inst1/backups compress
DB2 also provides compression for database

backup. To use it, specify the keyword
“compress” in your database backup
command.
One thing to note is that compression saves

storage space for you, but it may add
workload to CPU when compressing the
data during backup and decompressing the
data during recovery
.
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
■ To configure automatic backup
–Graphical user interface tools
• Configure Automatic Maintenance
wizard
–Command line interface
• auto_db_backup
• auto_maint
–Stored procedure
• AUTOMAINT_SET_POLICY system stored procedure
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.
Optimizing Backup Performance

■ DB2 automatically configures these parameters for performance
– Parallelism
• Number of table spaces backed up in parallel
– num_buffers
• Number of buffers used
• Use at least twice as many buffers as backup targets (or
sessions) to ensure that the backup target devices do not have to
wait for data.
– Buffer
• Backup buffer size
■ Allocate more memory to backup utility by increasing utility heap size
(UTIL_HEAP_SZ) configuration parameter.
■ Backup subset of data where possible:
– Table space backups
– Incremental backups
■ Use multiple target devices
To make backups run faster, there are several performance tuning

options on the backup command. For example you can set
PARALLELISM n - the number of table spaces to be backed up in parallel

Using this parameter can reduce the amount of time required to complete the
backup. It defines the number of processes or threads that are started to
read data from the database. Each process or thread is assigned to back
up a specific table space. When it completes backing up the table space,
it requests another. Increasing the value requires additional processor
and memory resources. The default value is one.
WITH num_buffers BUFFERS: number of memory buffers DB2 will use to

store backup data prior to sending it off to the target
BUFFER buffer-size - the size of each of these member buffers

The backup buffer size and number of buffers. If you use multiple buffers
and I/O channels, you should use at least twice as many buffers as
channels to ensure that the channels do not have to wait for data. The
size of the buffers should ideally be a multiple of the table space extent
size. If you have differing extent sizes, choose a multiple of the largest
extent size. If the buffer size if not specified the value is taken from the
database manager configuration parameter BACKBUFSZ, which by
default is 1024 (4 KB) pages.
util_heap_sz - This parameter indicates the maximum amount of memory

that can be used simultaneously by the BACKUP, RESTORE, and LOAD
(including load recovery) utilities.
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
■ Crash recovery and version recovery are enabled in DB2 by default
Recovery is the process of rebuilding a database or a table space after

a system outage, transaction failure, media failure or natural
disaster.
There are 3 types of recovery available in DB2:

- crash recovery
- version recovery
- roll forward recovery
Crash recovery protects a database from being left in an inconsistent

state following an abnormal termination such as a power failure.
Thus, if you have transactions that were interrupted before being
completed and committed, the database will be left in an inconsistent
state. With crash recovery the database is moved back into a
consistent state, whereby incomplete transactions are rolled back,
and completed transactions that were in memory prior to the crash
are committed.
Version recovery allows you to restore a snapshot of the database

taken at a point in time.
Roll forward recovery extends version recovery by using full database

and table space backups in conjunction with the database log files.
By default, crash recovery and version recovery are enabled in DB2

DB2 Restore Utility

■ Restore utility is the complement of backup utility
■ Restores database or table space from a previously taken
backup
■ TAKEN AT - Specify the time stamp of the database backup
image. Backup image timestamp is displayed after
successful completion of a backup
■ Without prompting – Overrides any warnings.
Example:
RESTORE DATABASE dbalias FROM <db_path> TAKEN AT 20080718131210
You can restore a backup image to recover a

database, one table space, or multiple table
spaces.
At the RESTORE DATABASE command, a

timestamp is required to locate the backup
image if TAKEN AT option is specified.
Note that there is no keyword OFFLINE in the

RESTORE DATABASE syntax, as this is
the default mode. In fact, for the RESTORE
utility, this is the only mode allowed if you
are restoring a whole database.
Table space Restore Operation

■ Restored table space is in Roll Forward Pending state and can be either
rolled forward to End of Logs or a Point In Time.
– In case of Point in Time roll forward, table space must be rolled forward to
at least the minimum Point in Time
■ Minimum recovery time can be checked using
– db2 list tablespaces show detail
■ User table space must be in line with catalog table space
– e.g if catalog indicates table T1 exists in table space TSP1, table T1 must
exist in the TSP1 table space, otherwise database becomes inconsistent
■ Every time there is a DDL changed, minimum recovery time for the table
space is revised to indicate the last DDL change.
■ Recommended to take a table space backup after a table space has been
restore to a point in time.
■ Transactions that came after the point in time are lost, therefore take a
table space backup as new point of reference for future recoveries.
Table spaces can be restored in offline or online mode.

While in online mode, connections to the database can be
made. This is advantageous in the case of table space
restoration when other table spaces can still be used
concurrently while the restore is executing.
After a table space is restored, it will always be placed in

roll forward pending state. To make the table space
accessible and reset this state, the table space must be
rolled forward at least to a minimum point in time (PIT).
This minimum PIT ensures that the table space and logs
are consistent with what is in the system catalogs.
A minimum PIT for a table space is updated when DDL

statements are run against the table space or against
tables in the table space
To determine the minimum PIT, do either of the following:

- Execute the LIST TAVBLESPACES SHOW DETAIL
command
- Obtain a table space snapshot: GET SNAPSHOT FOR
TABLESPACES ON <db_name>
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;
Usually an incremental restore involves a series

of restore operations, it requires s a full backup
image, the last incremental backup, all delta
backups since the last incremental backup, and
the logs
The manual process is time consuming and

error-prone. You have to know what images to
restore and in what order they must be restored.
To make this process easier, use the automatic

incremental restore utility. To perform an
automatic incremental restore, all you need to do
is identify the most recent backup image you
want to restore, and issue only one RESTORE
DATABASE command against it, with the
INCREMENTAL AUTOMATIC option. The
restore utility will take care of the rest.
IBM Canada Lab
Questions? Summer/Fall 2010
E-mail: imschool@us.ibm.com
Subject: “DB2 Academic Workshop”
21
In conclusion, DB2 provides a suite of data

backup and recovery utilities to help protect
your database from unexpected events and
to ensure that your database always
operates in a consistent manner.
Q&A

2.5 - DB2 Backup and Recovery

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2.5 - DB2 Backup and Recovery

Uploaded by

Copyright:

Available Formats

Information Management Ecosystem Partnerships

IBM Canada Lab

DB2® Backup and Recovery

© 2010 IBM Corporation

Why Backup my Data?

2 © 2010 IBM Corporation

Basic Concept of Database Backup and Recovery

After restore, reapply the

3 © 2010 IBM Corporation

DB2 Transaction Logs

Package cache Log Buffer

log device upon one of the Bufferpool

Log File States

Disk for Active

Transactions DB2 Server

Active log path

When all preallocated log files are

ACTIVE – Contains information

Archive Log Directory Active Log Directory

7 © 2010 IBM Corporation

8 © 2010 IBM Corporation

9 © 2010 IBM Corporation

Database Backup – Syntax

db2 backup database <db_name> <online> to <dest_path>

Online backup example

Offline backup example

10 © 2010 IBM Corporation

Database Backup – File Naming Convention

Alias Instance Catalog Node Year Day Minute Sequence

Type Node Month Hour Second

11 © 2010 IBM Corporation

Table space Backup

db2 backup database mydb1 TABLESPACE (TBSP1) ONLINE to

12 © 2010 IBM Corporation

Ful Delta Backups Ful

Database Backup – Compression

14 © 2010 IBM Corporation

Automatic Database Backup

15 © 2010 IBM Corporation

Optimizing Backup Performance

16 © 2010 IBM Corporation

■ Crash recovery and version recovery are enabled in DB2 by default

17 © 2010 IBM Corporation

DB2 Restore Utility

RESTORE DATABASE dbalias FROM <db_path> TAKEN AT 20080718131210

18 © 2010 IBM Corporation

Table space Restore Operation

19 © 2010 IBM Corporation

20 © 2010 IBM Corporation

Questions? Summer/Fall 2010

© 2010 IBM Corporation

DB2® Backup and Recovery

© 2010 IBM Corporation

In this presentation, we'll talk about how you

Why Backup my Data?

2 © 2010 IBM Corporation

Why do we need to backup our data? Data

Basic Concept of Database Backup and Recovery

After restore, reapply the

3 © 2010 IBM Corporation

The diagram demonstrates a simple data backup

As displayed in the diagram, at point T1, the

At a later point down the line, at point T2, your