As the size of databases, and particularly warehouses, continues
to expand into the terabyte and petabyte range, the time and hardware
resources required to back up and recover these databases is also
growing substantially. Full database and table space backups are not
always the best approach when dealing with large databases, because
the storage requirements for multiple copies of such databases are
enormous. Consider the following issues:
- When a small percentage of the data in a warehouse changes, it
should not be necessary to back up the entire database.
- Appending table spaces to existing databases and then taking only
table space backups is risky, because there is no guarantee that
nothing outside of the backed up table spaces has changed between
table space backups.
To address these issues, DB2® provides incremental backup
and recovery. An
incremental backup is a backup image that
contains only pages that have been updated since the previous backup
was taken. In addition to updated data and index pages, each incremental
backup image also contains all of the initial database metadata (such
as database configuration, table space definitions, database history,
and so on) that is normally stored in full backup images.
Note: - If a table space contains long field or large object data and
an incremental backup is taken, all of the long field or large object
data will be copied into the backup image if any of the pages in that
table space have been modified since the previous backup.
- If you take an incremental backup of a table space that contains
a dirty page (that is, a page that contains data that has been changed
but has not yet been written to disk) then all large object data
is backed up. Normal data is backed up only if it has changed.
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.
The key difference between incremental and delta backup images
is their behavior when successive backups are taken of an object that
is continually changing over time. Each successive incremental image
contains the entire contents of the previous incremental image, plus
any data that has changed, or is new, since the previous full backup
was produced. Delta backup images contain only the pages that have
changed since the previous image of any type was produced.
Combinations of database and table space incremental backups are
permitted, in both online and offline modes of operation. Be careful
when planning your backup strategy, because combining database and
table space incremental backups implies that the predecessor of a
database backup (or a table space backup of multiple table spaces)
is not necessarily a single image, but could be a unique set of previous
database and table space backups taken at different times.
To restore the database or the table space to a consistent state,
the recovery process must begin with a consistent image of the entire
object (database or table space) to be restored, and must then apply
each of the appropriate incremental backup images in the order described
below.
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.
For SMS and DMS table spaces, the granularity of this tracking
is at the table space level. In table space level tracking, a flag
for each table space indicates whether or not there are pages in
that table space that need to be backed up. If no pages in a table
space need to be backed up, the backup operation can skip that table
space altogether.
Although minimal, the tracking of updates to the database can have
an impact on the runtime performance of transactions that update or
insert data.