Log shipping is the process of copying whole
log files to a standby machine either from an archive device, or through
a user exit program running against the primary database. A scheduled
job on the standby issues the ROLLFORWARD DATABASE command
at a specified interval to keep the standby current in terms of log
replay.
To set up log shipping, you configure the database
with user exit programs and log archiving enabled, initialize the
standby, modify one of the sample user exit files (you can find more
information about them in "Log management user exit samples")
to either archive the logs to a shared device or send the log files
to the standby's log path, and schedule a job so that the standby
processes the log files. For a detailed overview of setting up log
shipping, see this article.
After your log shipping solution is configured, the
standby database is continuously rolling forward through the log files
produced by the production machine. When the production machine fails,
a failover occurs (you either initiate this manually or create a script
to do this) and the following takes place:
- The remaining logs are transferred over to the standby machine.
- The standby database rolls forward to the end of the logs and
stops.
- The clients reconnect to the standby database, which is now the
new primary, and resume operations.
The standby machine has its own resources (for example, disks),
but must have the same physical and logical definitions as the production
database.
When using this approach, create the initial
standby database by using restore utility (from a backup of the primary
database) or by using the split mirror function if that is available.
To ensure that you are able to recover your database in a disaster
recovery situation consider the following:
- The archive location should be geographically separate from the
primary site.
- Remotely mirror the log at the standby database site.
- Use a synchronous mirror for no loss support. You can do this
using modern disk subsystems such as ESS and EMC, or another remote
mirroring technology. NVRAM cache (both local and remote) is also
recommended to minimize the performance impact of a disaster recovery
situation.
If you want to control which log files are to be rolled
forward on the standby machine, you can disable the retrieval of archived
logs by using the
NORETRIEVE option with the
ROLLFORWARD
DATABASE command. The benefits of this are:
- By controlling the log files to be rolled forward, you can ensure
that the standby machine is X hours behind the
production machine, to avoid affecting both the systems.
- If the standby system does not have access to archive (for example,
if Tivoli® Storage Manager is
the archive, it only allows the original machine to retrieve the files).
- It might also be possible that while the production system is
archiving a file, the standby system is retrieving the same file,
and it might then get an incomplete log file. NORETRIEVE would
solve this problem.
Note: - When the standby database processes a log record indicating that
an index rebuild took place on the primary database, the indexes on
the standby server are not automatically rebuilt. The index will be
rebuilt on the standby server either at the first connection to the
database, or at the first attempt to access the index after the standby
server is taken out of rollforward pending state. It is recommended
that the standby server be resynchronized with the primary server
if any indexes on the primary server are rebuilt. You can enable indexes
to be rebuilt during rollforward operations if you set the logindexbuild database
configuration parameter.
- If the load utility is run on the primary database with the COPY
YES option specified, the standby database must have access
to the copy image.
- If the load utility is run on the primary database with the COPY
NO option specified, the standby database should be resynchronized,
otherwise the table space will be placed in restore pending state.
- There are two ways to initialize a standby machine:
- By restoring to it from a backup image.
- By creating a split mirror of the production system and issuing
the db2inidb command with the STANDBY option.
Only after the standby machine has been initialized can you
issue the ROLLFORWARD DATABASE command on the standby
system.
- Operations that are not logged will not be replayed on the standby
database. As a result, it is recommended that you resynchronize the
standby database after such operations. You can do this through online
split mirror and suspended I/O support.