2.5 - DB2 Backup and Recovery

© 2010 IBM Corporation

Information Management

Information Management Ecosystem PartnershipsIBM Canada Lab

Summer/Fall 2010

DB2® Backup and Recovery

2 © 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 tohelp you keeping your information safe!



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

logsDatabase

at

t1

Databaseat

t1

databaseBackup

Image

Perform a database backup

t1

Database continues to process transactions. Transactions are recorded in log files

Disaster strikes, Database is damaged

t2Perform a database restore using the backup image. The restored database is identical to the database at t1

t3

After restore, reapply the transactions committed between t1 and t2 using 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

■ The transactions in the log buffer are recorded in the log device upon one of the following events:

– Log buffer is full– Number of commits

reach MINCOMMIT value– One second has lapsed

Package cache

Bufferpool

Disk for thedatabase

Page indexes

Information to be updated is retrieved from

disk (if needed)

Update transaction

Log Buffer

Update transaction

Old transactions

Disk for logs

DB2 Memory (in RAM)



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

Package cache

Bufferpool

Disk for the

database

Page indexesInformation to be

updated is retrieved from disk (if needed)

Update transaction

Log Buffer

Update transaction

Old transactions

Active Log

Directory

DB2 Memory (in RAM)

OFFLINE Archive Logs

DB2 Memory (in RAM)



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

Primarylogs

Transactions DB2 Server

1

Secondary logs

1

2

3

4

n

n

Active log path

Active log file



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

Archive Log Directory Active Log Directory

ACTIVE – Contains information for non-committed transactions.

When all preallocated log files are filled,more log files are allocated

and used. Filled log files may be moved to a

different storage locationONLINE ARCHIVE

Contains information for committed transactions.

Stored in the ACTIVElog subdirectory.



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 configurationfile

■ 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 exampledb2 backup database mydb online to /home/db2inst1/backups

Offline backup exampledb2 backup database mydb to /home/db2inst1/backups



Database Backup – File Naming Convention

SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001

Alias Instance Catalog Node MinuteYear

Type Node Month

Day

Hour Second

Sequence

Backup Type:0 = Full Backup3 = 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

■ 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.

Delta Backups Full

Full

Full

Full

Cumulative Backups

Sunday SundayMon Tue Wed Thu Fri Sat



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 mediaor storage failure, power interruption, orapplication 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: SAMPLE.0.DB2INST.NODE0000.CATN0000.20080718131210.001

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;




Summer/Fall 2010Questions?

E-mail: [email protected]: “DB2 Academic Workshop”

1




Summer/Fall 2010

DB2® Backup and Recovery

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 tohelp 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

logsDatabase

at

t1

Databaseat

t1

databaseBackup

Image

Perform a database backup

t1

Database continues to process transactions. Transactions are recorded in log files

Disaster strikes, Database is damaged

t2Perform a database restore using the backup image. The restored database is identical to the database at t1

t3

After restore, reapply the transactions committed between t1 and t2 using the log files.

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

■ The transactions in the log buffer are recorded in the log device upon one of the following events:

– Log buffer is full– Number of commits

reach MINCOMMIT value– One second has lapsed

Package cache

Bufferpool

Disk for thedatabase

Page indexes

Information to be updated is retrieved from

disk (if needed)

Update transaction

Log Buffer

Update transaction

Old transactions

Disk for logs

DB2 Memory (in RAM)

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

Package cache

Bufferpool

Disk for the

database

Page indexesInformation to be

updated is retrieved from disk (if needed)

Update transaction

Log Buffer

Update transaction

Old transactions

Active Log

Directory

DB2 Memory (in RAM)

OFFLINE Archive Logs

DB2 Memory (in RAM)

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 diskActive 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

Primarylogs

Transactions DB2 Server

1

Secondary logs

1

2

3

4

n

n

Active log path

Active log file

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

Archive Log Directory Active Log Directory

ACTIVE – Contains information for non-committed transactions.

When all preallocated log files are filled,more log files are allocated

and used. Filled log files may be moved to a

different storage locationONLINE ARCHIVE

Contains information for committed transactions.

Stored in the ACTIVElog subdirectory.

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 configurationfile

■ 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 exampledb2 backup database mydb online to /home/db2inst1/backups

Offline backup exampledb2 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

SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001

Alias Instance Catalog Node MinuteYear

Type Node Month

Day

Hour Second

Sequence

Backup Type:0 = Full Backup3 = 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

■ 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.

Delta Backups Full

Full

Full

Full

Cumulative Backups

Sunday SundayMon Tue Wed Thu Fri Sat

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 parallelUsing 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 buffersThe 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 mediaor storage failure, power interruption, orapplication 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: SAMPLE.0.DB2INST.NODE0000.CATN0000.20080718131210.001

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.

21




Summer/Fall 2010Questions?

E-mail: [email protected]: “DB2 Academic Workshop”

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

Documents

2.5 - DB2 Backup and Recovery