technical notes · 2020-07-25 · db2 v9 data recovery and high availability guide and reference...

These technical notes describe best practices for high availability anddisaster recovery when using RecoverPoint to replicate DB2 for Linux,UNIX and Windows databases. It contains the following topics:

◆ Introduction........................................................................................... 2◆ DB2 LUW data protection requirements .......................................... 3◆ RecoverPoint overview........................................................................ 4◆ Replication with RecoverPoint ........................................................... 5◆ DB2 types of recovery.......................................................................... 7◆ DB2 and RecoverPoint ......................................................................... 8◆ DB2 data organization ......................................................................... 9◆ DB2 best practices with RecoverPoint............................................... 9◆ DB2 preparation.................................................................................. 10◆ DB2 target initialization steps........................................................... 11◆ DB2 target access steps ...................................................................... 13◆ Failover to the secondary location ................................................... 16◆ Restoring from the secondary location ........................................... 19◆ Appendix A: Bookmark script with write suspend mode ........... 22

EMC® RecoverPointDeploying RecoverPoint with IBM DB2

Technical NotesP/N 300-009-656

Rev A01

August 3, 2009

1

2

Introduction

IntroductionEMC RecoverPoint provides full support for data replication toenable high availability and disaster recovery for DB2 for Linux,UNIX and Windows (DB2 LUW) databases. RecoverPoint replicationsupports both single partition and multi-partition DB2 LUWdatabase configurations.

Combined with RecoverPoint bookmarks, DB2 LUWsuspend-write/resume-write procedures provide consistentpoint-in-time snapshots of DB2 databases that can quickly be used fortesting, backups, or disaster recovery. RecoverPoint supports DB2LUW databases stored on raw devices or on file systems.

This document describes best practices for deploying DB2 LUWdatabases for use with RecoverPoint, including selected use cases andtest scripts. While the examples and scripts provided in thisdocument were generated on the AIX platform, they can easily beadapted to any supported DB2 LUW platform.

This document assumes that:

◆ RecoverPoint has already been installed and configured on thehosts participating in the replication

◆ required splitters have been defined

◆ RecoverPoint appliances have been zoned

◆ RecoverPoint journals have been LUN-masked

In other words, no further configuration of RecoverPoint is necessary.It is also assumed that the reader has a working knowledge ofRecoverPoint.

Terminology CLI — command line interface

CLP — command line processor

Distribution — process of writing the image to the appropriatelocation at the replica site storage

Write Suspend — DB2 LUW procedure to condition database activityto allow a backup to be taken of the database, including all tablespace containers, active logs and archive logs

EMC RecoverPoint Deploying RecoverPoint with IBM DB2

DB2 LUW data protection requirements

RTO (Recovery Time Objective) — maximum acceptable time torestore a system or application to an operational state after a failureor disaster

RPA — RecoverPoint Appliance

RPO (Recovery Point Objective) — maximum acceptable timebetween the last available consistent image and a disaster or failure.RPO is a measure of the maximum allowable data loss.

References The following documents contain additional information onRecoverPoint or DB2:

◆ EMC RecoverPoint CLI Reference Guide

◆ EMC RecoverPoint Release 3.0 Administrator's Guide

◆ DB2 V9 Data Recovery and High Availability Guide and ReferenceSC10-4228-00

DB2 LUW data protection requirementsTo provide safety against data loss, data corruption, hardware error,and disaster, most DB2 database administrators implement a backupprocedure using the DB2 backup utility. The backup utility isscheduled to run at periodic intervals (usually once a day). Theoutput from the utility is stored on sequential media and is oftenremoved from the data center and placed in an external tape bank orsilo for protection.

If the backups are needed, the database can be restored to the point intime of the backup using the tapes and then rolled forward either to aspecific point in time or to the most current point in time to minimizethe data loss.

This process, however, has several undesirable aspects:

◆ The backup utility uses host CPU and I/O resources that arebetter utilized processing production DB2 LUW activities.

◆ The backup utility places locks and latches on DB2 objects duringthe backup that can interfere with application processes.

◆ The time needed to restore and recover the system can be verylong.

◆ Tape restores sometimes fail due to media problems (no RAIDprotection).

EMC RecoverPoint Deploying RecoverPoint with IBM DB2 3

4

RecoverPoint overview

◆ Using the backup utility is mostly a manual process.

In addition, if archive logs from the production system are notavailable for the roll forward step, as much as 24 hours of data can belost (when the backup frequency is daily).

RecoverPoint addresses all of these concerns and provides a simple,efficient process for backup, disaster recovery and roll-forwardrecovery using minimal host resources.

RecoverPoint overviewEMC RecoverPoint replicates data over any distance:

◆ within the same site (continuous data protection, CDP)

◆ to another site over a long distance (continuous remotereplication, CRR)

◆ both (concurrent local and remote data protection, or CLR).

RecoverPoint protects running applications and databases bytransmitting data changes over a network to a secondary location.The secondary location can be very close to the original location (forinstance, the same raised floor) or thousands of miles away. Inaddition, both forms of replication are available at the same time. Thechanges to the protected database are stored in a journal volume atthe secondary location and can be applied to the image on thesecondary storage on request.

RecoverPoint supports replication of data over Fibre Channel to localSAN-attached storage, and over WAN or Fibre Channel to remotesites. RecoverPoint allows you to fail over to a secondary site andresume operations in the event of a disaster at the primary site.

After initially synchronizing the volumes to replicate, a splitterintercepts write activity and transmits the changed data to thesecondary locations(s).

RecoverPoint enables the restart of a DB2 database to any number ofspecific points in time for disaster recovery or to avoid a logicalcorruption that might occur.

In addition, you can use the RecoverPoint bookmark capability tomake a specific point in time to which recovery can be made. Doingthis enables you to guarantee either a known transactional point intime, or a point in time that makes a recoverable DB2 LUW database.


Replication with RecoverPoint

The following figure shows a simple RecoverPoint replicationconfiguration for a DB2 database.

Refer to the RecoverPoint documentation for more details on theoperation and functionality of RecoverPoint.

Replication with RecoverPointA RecoverPoint consistency group is the set of volumes that comprisean atomic unit of replication. Multiple RecoverPoint consistencygroups make up a group set. All consistency groups in the group setcan be bookmarked to the same point in time.

To replicate a DB2 database, one or more consistency groups mustinclude all of the volumes that DB2 requires to bring up the databaseto the required state at the replica site. The set of objects to replicateincludes table space containers, active logs, archived logs, and thedatabase directory. DB2 instances are not replicated by RecoverPoint.The separate instances are defined on each server with their ownDBM and registry settings.

It may not be necessary to replicate certain DB2 components based onthe planned use of the target DB2 system. For instance, if the targetsystem is going to be used for disaster restart only, then it may not benecessary to replicate DB2 archive logs. If the target system is to beused for backup and recovery, it is not necessary to replicate the DB2


6

Replication with RecoverPoint

active logs. The choice of whether or not to replicate some DB2components is usually made to reduce the overall bandwidthrequirements of the solutions.

Table 1 shows RecoverPoint disaster recovery strategies that provideeffective solutions for the indicated use cases. By creating theconsistency groups with the bandwidth priority shown for eachconsistency group, the indicated disaster recovery strategy can beachieved.

a. This strategy may not be applicable in environments with long runningtransactions that need to be backed out using archive log data.

When possible, the crash- and application-consistent recoverystrategy is the recommended strategy, since it provides the highestdegree of safety and flexibility. It does, however, require morebandwidth than the other strategies.

Note: Integration with RecoverPoint does not preclude DB2 backups. Forperformance gains on the production host, these backups can be taken fromthe replicated database. Specific prerequisites for this type of backup aredescribed later in this document.

Table 1 RecoverPoint disaster recovery strategies for DB2 LUW databases

Disaster-recoverystrategy

Bandwidthconstraint?

Consistencygroup contains

Bandwidth allocation/group priority

application-consistent recovery

yes 1. table spacecontainers

high

2. active logs low

3. archive logs high

crash-consistentrecovery

yes 1. table spacecontainers

high

2. active logs high

3. archive logsa low

crash- andapplication-consistent recovery

no 1. table spacecontainers andactive logs

high

2. archive logs high


DB2 types of recovery

RecoverPoint can create a snapshot of all files that DB2 needs to bringup the database at the replica site. Since RecoverPoint guaranteesconsistency and write-order fidelity for each snapshot across allvolumes in the consistency group, DB2 can use this data to recoverfrom a failure in exactly the same way it recovers from a failure at theproduction site. That is, DB2 performs crash recovery on thesnapshot.

Note: IBM recommends using suspend/resume functionality to guaranteesuccessful recovery of the database at the replica site.

DB2 types of recoveryIBM defines three kinds of DB2 LUW recovery: crash recovery, versionrecovery, and point-in-time recovery.

Crash recovery Crash recovery executes on a database if the database is restartedafter it was shut down abnormally. Crash recovery is also executedon a restartable database copy as described above if the copieddatabase is activated. The crash recovery process involves completingcommitted transactions and backing out incomplete transactionchanges. In certain cases involving long-running update transactions,archive logs may be required for the crash recovery.

Version recovery Version recovery is the restoration of a complete backup image.Version recovery and crash recovery are the only recovery methodsallowed for databases in circular logging mode. This method ofrecovery does not allow the application of archive logs to roll forwardthe database to a point in time after the backup was created. Alltransactional data changes since the backup was created are lost.

Point-in-timerecovery

Point-in-time recovery (also called roll-forward recovery) is theexplicit application of archive logs after the restore of a point-in-timecopy of the database. Point-in-time recovery is only possible ondatabases that are in archive log mode. The database administratorcan roll forward to the end of the logs or choose some point in timebefore a specific event that might need to be avoided.


8

DB2 and RecoverPoint

DB2 and RecoverPointRecoverPoint provides protection for a running DB2 LUW databaseby taking consistent periodic snapshots of the database state. Each ofthese snapshots provide a point in time to which the database can bereturned if a recovery is needed.

When RecoverPoint takes a snapshot of DB2, the image created is adependent-write consistent image that honors write-order fidelity.This image, when restarted, goes through crash recovery to resolvein-flight transactions. This image can not be used for point-in-timerecovery.

Note: If point-in-time recovery is required, a different process from theautomatic snapshot capability within RecoverPoint is required.

Complete the following procedure to enable a snapshot image forpoint-in-time recovery:

1. On the source server, flush operating system data (sync for UNIX,kutils flushFS for Windows):

sync;sync;sync

2. Put DB2 in write suspend mode:

db2 connect to <alias>db2 set write suspend for database

3. Create a RecoverPoint bookmark for the DB2 consistencygroup(s). On the RecoverPoint appliance for the source database,execute:

bookmark_image group=<groupname> bookmark=<bmname>

4. Take DB2 out of write suspend mode:

db2 connect to <alias>db2 set write resume for database

WARNING

The suspension and resumption of writes must be from the samedatabase connection. This is because, in rare instances, it might notbe possible to reconnect to the database to resume the writes if theoriginal connection thread is terminated.


DB2 data organization

This procedure creates a snapshot for the consistency group that isidentified by <groupname>. The snapshot created by this bookmark isrecoverable (that is, it can be rolled forward using archive logs).

“Appendix A: Bookmark script with write suspend mode” onpage 22 provides a sample Korn shell script that uses a DB2bookmark to create a recoverable image.

DB2 data organizationWhen using a LUN-based replication tool, the correct organization ofthe file system data, logical volumes and volume groups (volume setsfor Windows) is critical to ensure recoverability of the DB2 databasereplica. Keep all the DB2 data in a single volume group/set ormultiple volume groups/sets. Do not have DB2 reside on a part of avolume manager structure. The smallest unit of replication isessentially a volume group/set.

DB2 best practices with RecoverPointTake note of the following best practices for deploying RecoverPointwith DB2:

◆ Record the paths (drive letters or mount points) for the DB2containers, log files and database directory. When accessing orfailing over to a replica, knowing the paths to all componentsprevents missing data and log file errors.

◆ Active logs change frequently. In a CRR configuration, placingactive logs in a separate, lower-priority consistency group andgiving priority to data and archive replication sets may improvereplication performance and slightly decrease time betweensnapshots (point-in-time recovery objective). The actual impactdepends on bandwidth and the volume of writes being sent overthe link to the replica site.

◆ RecoverPoint can replicate DB2 databases using either rawdevices or file systems on any operating system on which DB2runs. There are minor differences in behavior between hostconfigurations and the procedures to use with each type of hostdiffer slightly. The examples shown in this document show DB2running on AIX with the database residing on JFS2 filesystems.


10

DB2 preparation

◆ Do not mix other unrelated data on the LUNs being used for DB2— this causes unnecessary overhead in replication if the data ischanging and can cause problems if the image at the source isrestored by RecoverPoint.

DB2 preparationPerform the following procedure to prepare DB2 for RecoverPointreplication:

1. Install DB2 on the source and target hosts. Ensure that the versionand maintenance levels are identical.

2. Create an identical DB2 instance owner and group on both hosts.Ensure that they have the same UID and GID (UNIX and Linux).

3. Create the DB2 instance on each host separately. Set theappropriate DBM configuration parameters for each host andthen set the appropriate registry variables for the configuration.

4. Create identical mount points on the source and target hosts.Make sure they are owned by the DB2 instance owner and group.

5. Create one or more volume groups/volume sets to contain theDB2 data. When using AIX, do not use the mkfs command. Usethe crfs line command or use smit. Using smit or crfsguarantees that /etc/filesystems will be correctly managed onthe target system when importing and exporting the volumegroup.

6. Create the database on one of the mount points that will bereplicated. Placing the database directory within the replicatedLUNs ensures that any changes made to the databaseconfiguration will also be replicated to the target system.

7. Configure the database attributes using the following command:

db2 update db config using <keyword> <value>

8. Create the tablespaces, tables and indexes.


DB2 target initialization steps

DB2 target initialization stepsPerform the following procedure to initialize DB2 at the targetlocation. Perform this procedure as soon as possible so that you cansubsequently perform a successful failover. Note that the followingprocedure is specific to an AIX host configuration; the steps need tobe modified for other types of hosts.

Perform the following steps on the source host:

1. As the instance owner, shut down the source DB2 database:

db2 deactivate database <alias>

2. As the instance owner, shut down the source DB2 instance:

db2stop

3. As root, unmount the DB2 filesystems:

umount /<db201>umount /<db202>umount /<db203>

4. As root, vary off the DB2 volume groups:

varyoffvg <vg01>varyoffvg <vg02>

5. As root, export the DB2 volume groups:

exportvg <vg01>exportvg <vg02>

6. On the RecoverPoint Appliance or using the GUI, enable imageaccess for the DB2 consistency group using the latest image:

enable_image_access group=<groupname>copy=<copy name> image=<image name>

Perform the following steps on the target host:

7. As root, run the following command for every volume that ispresent in the DB2 volume group(s):

chdev -l hdisk<#> -a pv=yes

Or, if using PowerPath:

chdev -l hdiskpower<#> -a pv=yes


12

DB2 target initialization steps

This step takes the PVID in the VGDA of the volume and uses itto replace the PVID currently in the ODM.

8. As root, import the DB2 volume groups:

importvg -y <vg01> hdisk<#>


importvg -y <vg02> hdiskpower<#>

It is only necessary to specify one of the volumes in the volumegroup because the VGDA contains metadata about the othervolumes and determines which ones need to be included.

9. As root, mount the DB2 filesystems:

mount /<db201>mount /<db202>mount /<db203>

10. As the DB2 instance owner, start the DB2 instance if it is notalready started:

db2start

11. As the DB2 instance owner, catalog the DB2 database into the DB2database directory:

db2 catalog database <alias> on <db_directory>

12. As the DB2 instance owner, verify that the database is intact byconnecting and running SQL to test the database content:

db2 connect to <alias>

13. When the verification is complete and correct, as the DB2 instanceowner stop the database at the target side:


14. As the DB2 instance owner, stop the instance:

db2stop




DB2 target access steps





18. On the RecoverPoint Appliance or using the GUI, disable imageaccess for the DB2 consistency group. Enter:

disable_image_access group=<groupname>

This completes the initialization steps for the target. Some of thesesteps need to be repeated when accessing an image, as described inthe next section.

DB2 target access stepsWhen you need to access an image on the target side (either fortesting, or backup or any other business purpose), you can access itwithout interfering with DB2 LUW database activity on the sourceside and without stopping the replication process. The followingprocedure describes how to access a DB2 image at the target location.The following steps are relevant in an AIX host configuration —similar ones are needed for other host types.

Complete the following procedure to access the target DB2 system:

1. Choose a bookmark to access. Use the RecoverPoint ManagementApplication or the CLI to enable image access. If you are using theCLI, run the following command:


Run the following commands on the target host:


importvg -y <vg01> hdisk<#>importvg -y <vg02> hdiskpower<#>

It is only necessary to specify one of the volumes in each volumegroup because the VGDA contains metadata about the othervolumes which determines the volumes be imported.


14





db2start

The database is now available for access. Exactly how the databaseshould be processed at this point depends on what needs to be doneto the image and whether the image is restartable or recoverable. Thefollowing sections describe the required actions based on the desireduse of the database and the state of the source database when theimage was created.

Backup using DB2backup utility

There are two prerequisites to making a backup from the target imageusing the DB2 backup utility:

◆ The image must have been enabled using a bookmark with thedatabase in write-suspend mode.

◆ All the table spaces must be defined as DMS (not includingtemporary table spaces).

If these two conditions are met, run the following commands tobackup the DB2 database with the DB2 backup utility:

db2inidb <alias> as standbydb2 backup database <alias> to <backup_location>

A DB2 backup copy created in this way can be used in a RESTOREoperation for both the full database and also individual tablespaces.Both kinds of restore can be followed by a ROLLFORWARD if necessary.The backup, however, can not be used in a RECOVER operation. This isbecause the recovery history file on the source database is notupdated by the backup utility when it is run on the copy of thedatabase. Since the RECOVER utility does a single operation that isequivalent to the RESTORE followed by the ROLLFORWARD operation,this is not a real problem.



Back up usingfilesystem backup

No additional steps are required if filesystem backup is the backupmethodology being used. Note that a copy made using filesystembackup only provides for complete DB2 database restore. No tablespace recovery is available with this method.

Test the viability ofthe database

To test the viability of the DB2 database copy, it needs to be activated.If the image being used was created by an automatic RecoverPointsnapshot, the reactivation can be done in three different ways:

◆ db2 restart database <alias>

◆ db2 activate database <alias>

◆ db2 connect to <alias>

When DB2 comes up, it performs its undo and redo processes toresolve all in-flight transactions to reach a point of transactionalconsistency.

If the image was created using a bookmark while the database was inwrite suspend mode, the procedure is slightly different. Twocommands can be used to make the target copy available:

◆ db2 restart database <alias> write resume

◆ db2inidb <alias> as snapshot

Crash-consistentrecovery usingRecoverPointbookmarks

To replicate DB2 using RecoverPoint’s internal periodic bookmarks:

1. Place the database containers, database directory and the activelogs in a single RecoverPoint consistency group.

2. Place the archive logs in a different RecoverPoint consistencygroup.

WARNING

Having the archive logs in a different RecoverPoint consistencygroup may cause the restart of the database to fail if a long-runningtransaction needs to be backed out and an archive log is required toperform the action. If long running transactions exist that do notcommit frequently, place the archive logs be in the same consistencygroup as the other DB2 components.

3. Make sure that all LUNs of both consistency group are attachedto splitters and are ready to be replicated.


16

Failover to the secondary location

4. It is highly recommended to use RecoverPoint’s automaticperiodic bookmarking by creating a group set that contains bothconsistency groups. This will contribute to the integrity betweenthe database files and the log files.

5. Enable replication. Verify that replication is taking place and thatperiodic bookmarks are being created in both consistency groups.

Failover to the secondary locationFailover to the secondary location is sometimes required duringnormal business events. The process involves shutting down serviceson the source database, enabling image access on the target, andredirecting clients to the secondary location. While normal businessprocesses are using the secondary location, maintenance or similaractivities can be performed at the primary location. When suchactivities have finished, the application processes can be returned tothe primary location. This process, called a planned failover to theremote location, maximizes the availability of the application forusers.

Another reason for failover is when the primary database, server, orsite is no longer available for processing. This case, called unplannedfailover, is an abnormal situation and the procedures for unplannedfailover are slightly different from those used for planned failover.

The following sections describe the planned failover and unplannedfailover procedures.

Planned failover to the secondary locationIn planned failover, application services are transferred to thesecondary server and at the secondary location in a controlledmanner. Complete the following steps to perform a planned failoverto a secondary location:




db2stop









6. On the RecoverPoint Appliance or using the GUI, enable imageaccess for the DB2 consistency group using the latest image. Ifthere is any chance the latest image is not usable, select VirtualAccess with Roll Image in background:










db2start

10. As the DB2 instance owner, verify that the database is intact byconnecting and running SQL to test the database content:

db2 connect to <alias>


18


11. Now indicate that the remote copy is the data source for thisgroup by failing over to it. This can be done through the GUI orusing the command line on the RecoverPoint appliance. Enter:

failover group=<groupname> copy=<remote_copy> copy=no

As soon as everything needed to run the application is available,users must be redirected to use this server rather than the primaryserver. There are a number of networking techniques that can be usedto achieve this.

Unplanned failover to secondary locationShould a server, storage, or site fail, it may be necessary to performfailover to the secondary location. Complete the following procedureto fail over to the secondary location:

1. In the RecoverPoint Appliance or using the GUI, enable imageaccess for the DB2 consistency group using the latest image. Ifthere is any chance the latest image is not usable, select VirtualAccess with Roll Image in background:







3. Check the file systems (fsck on Unix or chkdsk on Windows).




db2start


Restoring from the secondary location

6. As the DB2 instance owner, activate the database, wait for it toperform crash recovery and verify that the database is intact byconnecting and running SQL to test the database content.

7. Now indicate that the remote copy is the data source for thisgroup by failing over to it. This can be done through the GUI orusing the command line on the RecoverPoint appliance. Enter:

failover group=<groupname> copy=<remote_copy> copy=no

As soon as everything needed to run the application is available,users must be redirected to use this server rather than the primaryserver. There are a number of networking techniques that can be usedto achieve this.

RecoverPoint failbackIn many instances, after correcting the problems at the productionsite that caused the initial disaster and failover, you may want toreturn the operation of the host application to the production site.This is done in exactly the same way as a planned failover, just in thereverse direction.

Restoring from the secondary locationUse the “Recover Production” functionality to correct logicalcorruption on the source DB2 database by rolling back to a previouspoint in time. In general, the process is to access an image in thereplica, verify that it is not corrupt (that is, that the image pre-datesthe corruption), and then roll back the source database to that point intime.

Complete the following procedure to roll back a DB2 database:




db2stop




20






6. On the RecoverPoint Appliance or using the GUI, enable imageaccess for the DB2 consistency group using an image that(hopefully) is not corrupted:







It is only necessary to specify one of the volumes in the volumegroup because the VGDA contains metadata about the othervolumes and determines which ones need to be included.




db2start

10. As the DB2 instance owner, verify that the database does notcontain the corruption that is on the source production database.If this copy is still corrupted, the database must be deactivated,the database file systems unmounted, and another, earlier imagemust be accessed on the target side.



11. When the verification is complete and a good copy of thedatabase is located, as the DB2 instance owner stop the databaseat the target side:


12. As the DB2 instance owner, stop the instance:

db2stop







16. On the RecoverPoint Appliance or using the GUI, use the“Recover Production” functionality to restore the active image atthe secondary location to the production source:

recover_production group=<groupname> copy=<copy_name>start_transfer=yes

In the Component pane for the selected DB2 consistency group, theimage status of the production source will be DistributingPre-replication image and the role will be Production (beingrestored).

After the transfer status changes to Active, enable image access at theproduction source. Select any image after the Pre-replication imagethat does not include images containing the original corruption.When image access is enabled at the production source, ResumeProduction will be enabled.


22

Appendix A: Bookmark script with write suspend mode


Note: The script in this appendix is provided as an example only. You mustmodify it to work in your particular environment.

Note the following:

◆ The bookmark.sh script contains comments that indicate theparameters that must be set for the operational environment.

◆ All DB2 environment variables must be set correctly. This scriptassumes that it has been invoked using cron and therefore itsources the instance owner .profile as the first action.

◆ The bookmark.sh script is the only script that needs to be run.

◆ To run the script without user interaction, the user running thescript must have a password-free ssh key loaded on the RPA. Forinformation about loading ssh keys on the RPA, refer to the EMCRecoverPoint CLI Reference Guide.

To automate creating bookmarks in RecoverPoint with DB2 databasetables in write suspend mode, use the server’s scheduler applicationto run the script. In Microsoft Windows, use the Windows TaskScheduler or Windows command-line at command to run the scriptsat regular intervals. In UNIX, use cron or at commands (refer toUNIX man pages for details) to run the scripts.

Example: bookmark.sh#!/usr/bin/ksh# Author EMC# Script bookmark.sh# Date July 2009# Function Create recoverable DB2 database with RecoverPoint# Description This script flushes the OS buffers, suspends# writes for a database, creates a bookmark for the# database and then resumes writes again. The bookmark# is given a serial number.# Arguments This script takes two arguments# 1) The database name to suspend# 2) The bookmark text# Notes - SSH must have been setup for the user running# the script for the RPA appliance# Assumes the RecoverPoint Con group is the same# name as the database.# - Do not attempt to embed spaces in the bookmark



# text.#################################################################. /home/db2inst1/.profileARGCOUNT=$#if [ $# -ne 2 ];then

echo "Usage: bookmark.sh <database-alias> <bookmark-text>"exit 1;

fi

ALIAS=$1BMTEXT=$2

sync;sync;sync;db2 connect to $ALIASif [ $? -ne 0 ]; then

echo "Error connecting to database: $ALIAS"echo "Terminating script"exit 1

fi## Determine book mark sequence number#if [ -f /tmp/bmcounter ]; then

SEQ=`cat /tmp/bmcounter`let SEQ=SEQ+1

elseSEQ=1

fiecho $SEQ > /tmp/bmcounter## Determine time for the suspend#TIME1=$SECONDSdb2 set write suspend for databaseif [ $? -ne 0 ]; then

echo "Error suspending writes for database: $ALIAS"echo "Terminating script"exit 1

fi## lrpa = hostname of local recoverpoint appliance#ssh lrpa bookmark_image group=$ALIAS bookmark=${BMTEXT}_$SEQBOOKRC=$?## Always resume the writes regardless of bookmark success#db2 set write resume for databaseif [ $BOOKRC -ne 0 ]; then

echo "Bookmark failure, return code: $BOOKRC"exit 1

fi


24


let TIME2=$SECONDS-$TIME1echo "I/O held for $TIME2 seconds."exit

Copyright © 2009 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. Theinformation is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATIONMAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THEINFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires anapplicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks onEMC.com.

All other trademarks used herein are the property of their respective owners.


technical notes · 2020-07-25 · db2 v9 data recovery and high availability guide and reference...

Documents