 | Level: Intermediate Kala Dutta (kdutta@us.ibm.com), Advisory Software Engineer, IBM
26 Apr 2007 IBM® Tivoli® Storage Manager for Advanced Copy Services Version 5.3.3 allows you to protect DB2 UDB multi partition databases distributed across one or more hosts, with the data configured on centralized storage systems in a storage area network. This article helps you configure your multi partition databases and storage subsystems for data protection using Tivoli Storage Manager Advanced Copy Services for DB2.
Audience
This article is meant to be used by DB2 UDB database administrators, storage
administrators, system administrators and skilled technical personnel.
This guide assumes technical proficiency with installation, configuration and
use of Tivoli Storage Manager, DB2 UDB multi partition databases and storage
subsystems such as ESS, DS6000, DS8000 or San Volume Controller.
This product is available with Tivoli Storage Manager Version 5.3.3.
Product overview
IBM Tivoli Storage Manager for Advanced Copy Services provides federated backup and restore of DB2 UDB databases in a multi-partition environment. It exploits the Copy Services FlashCopy technology of Storage Subsystems to provide snapshot backup and restore of the databases. This support is available on DB2 ESE version 8.2 or later for AIX® 5.2, AIX 5.3 or later. The databases can be defined on AIX raw logical volumes or on AIX file systems – JFS , JFS2. AIX SDD multipath support is also available.
Please refer to the Advanced Copy Services for DB2 UDB Installation and User's Guide
for detailed information about the product. Also refer to the white paper:
Understanding IBM Tivoli Storage Manager for Advanced Copy Services:
Data Protection for DB2 UDB for a description of some of the basic concepts of
the product and an overview of the backup and restore processes.
Customers will be able to use the product as follows:
- Backup of DB2 UDB Single partition or Multi-partition Databases to disk storage subsystem, to Tivoli Storage Manager Server or both.
- Restore of DB2 UDB Single partition or Multi-partition Databases from disk storage subsystem or Tivoli Storage Manager Server. The restore can be for a single database partition, all the database partitions for a single database host or the entire database.
- In case of loss of an entire database, for a restore from disk storage subsystem, if the disk has not been lost as well.
- In case of the loss of entire database as well as the disk storage system, for a restore from Tivoli Storage Manager Server.
Some of the special features of this product are:
- Zero-impact backups
- Instant recovery
- Federated backup and restore of DB2 UDB Enterprise Server Edition databases
- Optimized backup and recovery by exploiting Incremental FlashCopy
- Support for managing multiple backup versions for instant recovery
- Policy-based management of snapshot-based backups
- Single point of control for backup and restore operations
- Backups off-loaded from the production hosts
- Integrated management of snapshot-based backups and backups stored on the IBM Tivoli Storage Manager Server
- New integrated interfaces for configuration and operations
- Unattended backup of distributed DB2 databases
- Highly scalable to support one or more DB2 UDB (Enterprise Server Edition) hosts
- Supports Storage subsystems : IBM TotalStorage SAN Volume Controller, IBM TotalStorage® DS8000, IBM TotalStorage DS6000, IBM Enterprise Storage Server Model 800
- A single user interface for all user interaction integrated with the Tivoli Storage Manager backup and archive command line client.
- A configuration wizard to guide you through the set up of user preferences for Tivoli Storage Manager options, database options, and storage subsystem options.
- A sophisticated inter-client communication between a backup master node and the DB2 and backup worker nodes to coordinate and synchronize the various activities for federated backup and restore.
- Use of traditional Tivoli Storage Manager Backup-Archive client as a data mover, eliminating the need for a database application instance on the backup node.
- Exploitation of Tivoli Storage Manager multinode facility for authentication and password management for the various nodes participating in the federated operation.
- Support for multiple versions of both local FlashCopy backups and Tivoli Storage Manager snapshot image backups by exploiting Tivoli Storage Manager server policy management.
Configuration
The following sections describe in detail the configuration of the various components database, storage subsystem and Tivoli Storage Manager, shown in the figure above.
Storage subsystem configuration
Please refer to the Advanced Copy Services for DB2 UDB Installation and User's Guide for detailed information about the operating environment for the product.
Storage subsystems
The following storage subsystems are supported:
- IBM TotalStorage Enterprise Storage Server Model 800
- IBM TotalStorage DS6000
- IBM TotalStorage DS8000
- IBM SAN Volume Controller
AIX Operating System
- AIX 5.2 and AIX 5.3 are the levels of AIX operating system supported.
- AIX 5.2 DB2 production system with AIX 5.2 backup system
- AIX 5.3 DB2 production system with AIX 5.3 backup system
- AIX 5.2 DB2 production system with AIX 5.3 backup system
- Pegasus CIM client package should be installed on each AIX host from the AIX service extension pack CD.
- lslpp -l "*cim*" should show 2.3.2.2 (or later)
- SSL package should be installed from "AIX Toolbox for Linux® Applications for POWER Systems" CD (prerequisite for CIM client).
- IBM Subsystem Device Driver (SDD) 1.6.0.2 with Host Attachment Scripts 1.1.0.3 (or later) should be installed on each AIX host. Required for SAN Volume Controller environment. Recommended for ESS Model 800, DS6000 or DS8000 environments.
- If you are using SDD, configure two or more paths from each host to the storage subsystem.
CIM Agent configuration
The figure above shows the CIM Agent, which is the component used to communicate between Tivoli Storage Manager for Advanced Copy Services for DB2 and the storage subsystems. In this figure, the Client Application is Tivoli Storage Manager for Advanced Copy Services for DB2, and the device might be one of the storage subsystems, namely, DS6000, DS8000 or SVC.
CIM Agent for DS6000 and DS8000 Storage Subsystems
- Common Interface Model (CIM) Agent for DS Open API 5.1.0.40 (or later) should be installed either on one of the Backup hosts or on a separate AIX, Linux or Windows® host on your TCP/IP network.
- Make sure that the CIM Agent is configured for non-SSL connectivity to the CIM client (default HTTP port 5988).
- Perform the following steps to configure non-SSL connectivity:
- Go to the CIM Agent installation directory (default is /opt/IBM/cimagent)
- Run the stopcimom command to stop the CIMOM.
- Edit cimom.properties file and set the following properties:
- ServerCommunication=HTTP
- Port=5988
- DigestAuthentication=False
- Run the startcimom command to restart the CIMOM.
- Verify that the CIMOM server is started on port 5988 by checking the cimom.log file.
CIM Agent for SAN Volume Controller storage subsystems
If you are using SVC, the CIM Agent is shipped as part of the San Volume Controller storage subsystem.
- Make sure that the CIM Agent is configured for non-SSL connectivity to the CIM client (default HTTP port 5988).
- Perform the following steps to configure non-SSL connectivity:
- Go to the CIM Agent installation directory (default on Windows is C:\Program Files\IBM\svcconsole\cimom)
- Stop the CIMOM service: IBM CIM Object Manager - SVC
- Stop WebSphere service: IBM WebSphere® Application Server V5 - SVC
- Edit C:\Program Files\IBM\svcconsole\cimom\cimom.properties file and set the following properties:
- ServerCommunication=HTTP
- Port=5988
- DigestAuthentication=False
- Change the following WebSphere files to use the new CIMOM settings:
- C:\Program Files\IBM\svcconsole\console\embeddedWAS\installedApps\DefaultNode\ICAConsole.ear\ICAConsole.war\WEB-INF
- C:\Program Files\IBM\svcconsole\console\embeddedWAS\installedApps\DefaultNode\SVCConsole.ear\SVCConsole.war\WEB-INF
- C:\Program Files\IBM\svcconsole\console\embeddedWAS\config\cells\DefaultNode\applications\ICAConsole.ear\deployments\ICAConsole\ICAConsole.war\WEB-INF
- C:\Program Files\IBM\svcconsole\console\embeddedWAS\config\cells\DefaultNode\applications\SVCConsole.ear\deployments\SVCConsole\SVCConsole.war\WEB-INF
- Add line: Port=5988
- Change line: SslEnabled=false
- Restart the CIMOM service: IBM CIM Object Manager - SVC
- Restart WebSphere service: IBM WebSphere Application Server V5 - SVC
ESS Model 800 Storage Subsystems
If you are using ESS Model 800:
- ESS CopyServices CLI 2.3 or 2.4 should be installed on each AIX host. Only ESS CopyServices CLI version 2.3 and 2.4 (or later), are supported.
- ESS microcode version 2.3 or 2.4 (or later) is also required.
Configuring disk space for backup on storage subsystems
This section describes some of the things to consider when configuring disk space (User LUNs) for backup on the storage subsystems. User LUNs are the set of target storage volumes that are dedicated for performing the flashcopy backup from the database source storage volumes.
- The database can be configured on one or more storage subsystems of a given type. Thus, a database with six database partitions can be configured with storage volumes for three database partitions defined on one DS8000 storage subsystem and the storage volumes for the other three database partitions defined on a second DS8000 storage subsystem.
- The target volumes must match the source volumes in size.
- The source and target volume pairs must physically reside on the same storage subsystem, when the configuration spans multiple storage subsystems.
- A sufficient number of target volumes should be set aside to accommodate the number of backup versions you plan to have. Optionally, add additional target volumes to take into account the future growth of the database.
- Thus, if you have six database partitions, each with four source volumes, set aside 24 (or more) target volumes for one backup version, 48 (or more) target volumes for two backup versions and so on.
- The target volumes are specified as eight digit serial numbers for ESS Model 800, 11-digit serial numbers for DS6000 and DS8000 and virtual disk names (caption) for SVC.
User LUN file
The following is the format for the User LUN file that the user specifies in the Configuration Wizard. The configuration can have one backup master node and zero or more backup worker nodes. When you have multiple backup nodes, you cadistribute the backup workload by assigning a certain number of database partitions to be backed up by each backup node. The target volumes must be visible to the appropriate backup node.
backup master node name:
target lun id
target lun id
.
.
.
backup worker node name:
target lun id
target lun id
.
.
.
backup worker node name:
target lun id
target lun id
.
.
.
|
Sample User LUN files
The following sample files have one backup master node (kaveri) and two backup worker nodes (abhishek and jellicle). The target volumes are sufficient to accommodate a database with six database partitions, each with two source volumes.
Thus each backup node will back up two database partitions. There are a sufficient number of target volumes to have two backup versions.
Sample User LUN file for ESS Model 800
kaveri:
10194025
10294025
10394025
10494025
10594025
10694025
10794025
10894025
abhishek:
20194025
20294025
20394025
20494025
20594025
20694025
20794025
20894025
jellicle:
30194025
30294025
30394025
30494025
30594025
30694025
30794025
30894025
|
Sample User LUN file for DS8000
kaveri:
13019011300
13019011301
13019011302
13019011303
13019011304
13019011305
13019011306
13019011307
abhishek:
13019013400
13019013401
13019013402
13019013403
13019013404
13019013405
13019013406
13019013407
jellicle:
13019015500
13019015501
13019015502
13019015503
13019015504
13019015505
13019015506
13019015507
|
Sample User LUN file for DS6000
kaveri:
13AB1WA1020
13AB1WA1021
13AB1WA1022
13AB1WA1023
13AB1WA1024
13AB1WA1025
13AB1WA1026
13AB1WA1027
abhishek:
13AB1WA3020
13AB1WA3021
13AB1WA3022
13AB1WA3023
13AB1WA3024
13AB1WA3025
13AB1WA3026
13AB1WA3027
jellicle:
13AB1WA5020
13AB1WA5021
13AB1WA5022
13AB1WA5023
13AB1WA5024
13AB1WA5025
13AB1WA5026
13AB1WA5027
|
Sample User LUN file for SVC
kaveri:
kav_db2_svc_000
kav _db2_svc_001
kav _db2_svc_002
kav _db2_svc_003
kav _db2_svc_004
kav _db2_svc_005
kav _db2_svc_006
kav _db2_svc_007
abhishek:
abi_db2_svc_000
abi_db2_svc_001
abi _db2_svc_002
abi _db2_svc_003
abi _db2_svc_004
abi _db2_svc_005
abi _db2_svc_006
abi _db2_svc_007
jellicle:
jel_db2_svc_000
jel _db2_svc_001
jel _db2_svc_002
jel _db2_svc_003
jel _db2_svc_004
jel _db2_svc_005
jel _db2_svc_006
jel _db2_svc_007
|
Database configuration
Planning and designing your DB2 UDB multi partition databases
Perform the following configuration tasks when planning and designing your DB2 UDB databases for use with any of the above storage subsystems:
- All the hosts participating in the DB2 UDB multi partition database must be at the same version of the Database Server.
- Each database partition should have its own set of one or more volume groups configured on the storage subsystem.
- Keep the volume groups for recovery logs separate from the volume groups for user, system and temporary data. This ensures that the recovery logs are not overwritten during local FlashCopy restore processing of the database.
- Place recovery logs in one or more volume groups of storage subsystem volumes. Tivoli Storage Manager for Advanced Copy Services for DB2 UDB does not back up the recovery logs. Please use DB2 facilities for archiving and retrieving recovery logs to and from Tivoli Storage Manager Server.
- Place DB2 User and System tablespace containers in one or more volume groups of storage subsystem volumes. Place the system catalog tablespace container (SYSCATSPACE) on a separate volume group consisting of storage subsystem volumes configured for the catalog database partition.
The User and System tablespaces must be placed on the storage subsystem as they will be copied using FlashCopy processing. It is recommended that the user configure temporary tablespaces also on the storage subsystem.
Recovering DB2 configuration files
Tivoli Storage Manager backs up configuration files, metadata files etc. to Tivoli Storage Manager server during every DB2 UDB backup. One of the files backed up is the db2nodes.cfg file.
If you want to recover this file or any other configuration files backed up, use the following steps:
To query all the files backed up to Tivoli Storage Manager Server as part of a DB2 backup:
dsmadmc -id=adminid -pa=adminpw show version myMultiNode myFilespace
To restore the files:
dsmc restore "/myFilespace/tivoli/tsm/client/ba/bin/*" "/usr" -asnode=myMultinode
Here myMultiNode is the multinode name and myFileSpace is the virtual filespace name
under which the backups are stored on Tivoli Storage Manager Server.
Example:
dsmc -id=admin -pa=admin show version kd_asnode /kddb
dsmc restore "/kddb/tivoli/tsm/client/ba/bin/*" "/usr" -asnode=kd_asnode
|
Database recovery
After performing a local FlashCopy restore or a Tivoli Storage Manager restore,
perform a roll forward recovery before using the database.
Example:
After the LOCAL or Tivoli Storage Manager restore of a database, run roll forward
recovery on the catalog partition:
db2 "rollforward db database name to end of logs and stop"
db2 "rollforward db kddb to end of logs and stop"
After performing a LOCAL or Tivoli Storage Manager restore of a single DB2 partition,
run roll forward recovery on the catalog partition:
db2 "rollforward db database name to end of logs on dbpartitionnum (partition) and stop"
db2 "rollforward db kddb to end of logs on dbpartitionnum (1) and stop"
After performing a LOCAL or Tivoli Storage Manager restore of a single DB2 host,
run roll forward recovery on the catalog partition:
db2 "rollforward db database name to end of logs on dbpartitionnum (partition3,partition4,partition5) and stop"
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
db2 "rollforward db kddb to end of logs on dbpartitionnum (3,4,5) and stop"
Then connect to the database.
db2 connect to database name
db2 connect to kddb
To roll forward to a point in time:
Query the point in time:
db2 rollforward db kddb query status
Perform the roll forward:
db2 rollforward db kddb to 2006-03-15-09.30.51 using local time and stop
NOTE:
You MUST run at least a minor transaction after taking a Advanced Copy Services for
DB2 backup and before performing a restore. Otherwise, your roll forward recovery
will fail with the following error:
SQL4970N - Roll recovery on database dbname cannot reach the specified
stop point (end of log or point-in-time) because of missing log file(s) on node(s) 0.
|
Creating a sample DB2 UDB multi partition database for use with Advanced Copy Services for DB2 UDB
This section is meant for users unfamiliar with creating DB2 databases.
If you are an experienced DB2 user, you can skip this section.
The following are the steps to create a sample multi-partition DB2 database defined on three database partitions per host residing on two AIX hosts.
You can follow the same steps to create additional database partitions on each host. You can create additional database hosts with one or more
database partitions in a similar manner.
Refer to the IBM DB2 Universal Database Enterprise Server Edition for UNIX publications and the IBM Redbooks:
Managing VLDB Using DB2 UDB EEE for more information about creating and managing multi partition DB2 UDB databases.
Creating the DB2 instance
Create the DB2 user
As root, create the DB2 user that will own the instance, and set a password for this
user using the command passwd. Afterwards, confirm the password by running the
passwd command as this new user.
Note:
- Ensure that the name you select for the instance owner (UNIX® user name) does NOT exceed six characters.
- Ensure that root user is part of the DB2 SYSADM group. SYSADM group is the group associated with the DB2 user created above.
Example:
db2 user: kdinst
db2 group: db2adm (db2adm should have root as one of its users)
You can also use the following command to locate the SYSADM group for your
database instance:
db2 get database manager configuration
|
Add an entry to the /etc/hosts file
As root, make sure that there is an entry for the host in the /etc/hosts file.
Use the following syntax:
numerical-IP-address hostname
where hostname is the machine hostname and
numerical-IP-address is its numerical IP address as known to the local network.
Example:
9.43.106.21 bangalore
|
Add an entry to the .rhosts file
As the DB2 user created above, create a .rhosts file in the home directory of that user.
If db2user represents the user created above, go to the /home/db2user
directory and create the .rhosts file.
Use the following syntax:
+
hostname
where hostname represents the hostname of the machine on which the DB2 database is
being created. Thus /home/db2user/.rhosts should have a "+" on the top line and the
hostname of the machine on the next line.
Example:
+
bangalore
If your database is distributed across multiple hosts, /home/db2user/.rhosts
file should have an entry for each host.
Example:
+
bangalore
delhi
Note: The permission on the .rhosts file must be 600.
chmod 600 /home/kdinst/.rhosts
|
Add services names to the /etc/services file
As root, edit the /etc/services file to add services names for use by the DB2 instance to be
created.
For example, if db2user represents the name of the user created above, then add
entries in /etc services as follows:
Note: Port number cannot be higher than (2^16) - 1)
DB2_db2user port#1/tcp
DB2_db2user_END port#2/tcp
DB2_db2user_A port#3/tcp
where port#1, port#2, and port#3 represent distinct tcp port numbers.
Make sure that they do not conflict with existing port numbers.
port#1 and port#2 should be consecutive.
If there are multiple partitions on each host, pick a consecutive set of tcp
port numbers.
Use the same set for each DB2 host participating in the database.
Example: This shows the entries for a database with three partitions on each host.
DB2_kdinst 60000/tcp
DB2_kdinst_1 60001/tcp
DB2_kdinst_END 60002/tcp
DB2_kdinst_A 60003/tcp
|
Create the DB2 instance
As root, create the DB2 instance.
Go to the directory /usr/opt/db2_08_01/instance and run the command:
db2icrt -u db2user db2user
where db2user is the user created above.
Example:
/usr/opt/db2_08_01/instance/db2icrt -u kdinst kdinst
|
Update the DB2 instance
As root, update the DB2 instance.
Go to the directory /usr/opt/db2_08_01/instance and run the command:
db2iupdt db2user
Example:
/usr/opt/db2_08_01/instance/db2iupdt kdinst
|
Modify db2nodes.cfg file
Add information for each database partition to the db2nodes.cfg file.
As the DB2 user created above, go to the directory /home/db2user/sqllib and
edit the file db2nodes.cfg as follows:
Add a line for each additional partition on the database. db2nodes.cfg will
initially have the following as its first line:
0 hostname 0
Add the following line to the db2nodes.cfg file:
1 hostname 1
Example:
/home/kdinst/sqllib/db2nodes.cfg:
0 bangalore 0
1 bangalore 1
2 bangalore 2
3 delhi 0
4 delhi 1
5 delhi 2
|
Export the instance home directory
Make the instance home directory available to all the hosts across which the database is
distributed by NFS exporting it. Allow root access to this directory to all these hosts.
On each of these hosts, NFS mount the instance home directory.
Example:
If you created the database instance on host bangalore, NFS export the instance
home directory.
Run the following command on host delhi to NFS mount the directory:
mount -o soft delhi:/home/kdinst /home/kdinst
|
Catalog the tcpip nodes
Catalog the tcpip nodes, one for each database partition.
As the DB2 user, issue the commands:
db2 catalog tcpip node node0 remote numerical-IP-address server DB2_db2user
db2 catalog tcpip node node1 remote numerical-IP-address server DB2_db2user_END
where numerical-IP-address represents the numerical IP address of the host
Example:
For host Bangalore with IP address 9.43.106.21:
db2 catalog tcpip node node0 remote 9.43.106.21 server DB2_kdinst
db2 catalog tcpip node node1 remote 9.43.106.21 server DB2_kdinst_1
db2 catalog tcpip node node2 remote 9.43.106.21 server DB2_kdinst_END
For host delhi with IP address 9.43.106.43:
db2 catalog tcpip node node3 remote 9.43.106.43 server DB2_kdinst
db2 catalog tcpip node node4 remote 9.43.106.43 server DB2_kdinst_1
db2 catalog tcpip node node5 remote 9.43.106.43 server DB2_kdinst_END
|
Verify the database catalog
As the DB2 user, check the results of the above catalog commands.
Run the following command:
db2 list node directory
The output should look something like this:
$ db2 list node directory
Node Directory
Number of entries in the directory = 6
Node 1 entry:
Node name = NODE0
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.21
Service name = DB2_kdinst
Node 2 entry:
Node name = NODE1
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.21
Service name = DB2_kdinst_1
Node 3 entry:
Node name = NODE2
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.21
Service name = DB2_kdinst_END
Node 4 entry:
Node name = NODE3
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.43
Service name = DB2_kdinst
Node 5 entry:
Node name = NODE4
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.43
Service name = DB2_kdinst_1
Node 6 entry:
Node name = NODE5
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 9.43.106.43
Service name = DB2_kdinst_END
|
Set the communication method and servicename
As the DB2 user, set the communication method to tcpip. Also set the servicename for the new
database instance.
Set the communication method to tcpip, using the following command:
db2set DB2COMM=TCPIP
Set the servicename for the new instance with the following command:
db2 update dbm cfg using SVCENAME DB2_db2user_A
Example:
db2 update dbm cfg using SVCENAME DB2_kdinst_A
|
Start the database instance
As the DB2 user start the DB2 instance on one of the hosts, using the db2start command,
Example: On host bangalore:
su - kdinst
db2start
|
Creating the DB2 database
Create volume groups
As root, create volume groups on the storage subsystem, with a set of non overlapping
volume groups to be used for each partition.
A minimum of two volume groups per partition is advisable, one volume group for user, system
and temporary tablespaces and one volume group for logs.
Create filesystems
As root, create filesystems on the volume groups created above.
Create a filesystem on one of the volume groups assigned to each partition with a
mount point as follows:
/fsname/db2user/NODE000X
where X is the node number from the db2 list database directory.
Example:
/fsname/db2user/NODE0001
|
Note:
-
fsname should be the same name for all the partitions.
- For each database filesystem created, allocate a separate JFS log for its use.
If you allocate a single JFS log per volume group, the JFS logs might wrap, causing errors
on subsequent Advanced Copy Services for DB2 backups.
- Ensure that each JFS log is defined on a single logical volume within the volume group.
Advanced Copy Services for DB2 backups might fail if the JFS log is striped across
multiple logical volumes within the volume group.
- Alternatively, you can use inline JFS logs.
Example:
For host bangalore:
/kdfs/kdinst/NODE0000 on volume group kdvg0 and logical volume kdlv0
/kdfs/kdinst/NODE0001 on volume group kdvg1 and logical volume kdlv1
/kdfs/kdinst/NODE0002 on volume group kdvg2 and logical volume kdlv2
For host delhi:
/kdfs/kdinst/NODE0003 on volume group kdvg3 and logical volume kdlv3
/kdfs/kdinst/NODE0004 on volume group kdvg4 and logical volume kdlv4
/kdfs/kdinst/NODE0005 on volume group kdvg5 and logical volume kdlv5
|
As root, create, on a different volume group assigned to each partition, a filesystem to be
used for the temporary tablespace. You can also create them on the same volume groups as the
ones used above.
Example:
For host bangalore:
/kdtmpfs/kdinst/NODE0000 on volume group kdtmpvg0 and logical volume kdtmplv0
/kdtmpfs/kdinst/NODE0001 on volume group kdtmpvg1 and logical volume kdtmplv1
/kdtmpfs/kdinst/NODE0002 on volume group kdtmpvg2 and logical volume kdtmplv2
For host delhi:
/kdtmpfs/kdinst/NODE0003 on volume group kdtmpvg3 and logical volume kdtmplv3
/kdtmpfs/kdinst/NODE0004 on volume group kdtmpvg4 and logical volume kdtmplv4
/kdtmpfs/kdinst/NODE0005 on volume group kdtmpvg5 and logical volume kdtmplv5
|
Mount the filesystems
As root, on each host, mount the filesystems created for the host.
Example: On bangalore -
mount /kdfs/kdinst/NODE0000 ...
|
Set the ownership
As root, assign ownership of all of the filesystems created above to the DB2 user,
using the chown command.
Example: On bangalore -
chown -R kdinst:db2adm /kdfs/kdinst/NODE0000
|
Create the database
Select one of the hosts to contain the catalog partition. As the DB2 user, create the
database.
Note:
Please make sure that the name you select for the database does not exceed eight characters.
db2 "create db db_name on /fsname catalog tablespace managed by database
using (FILE '/fsname/db2user/NODE0000/mydb/cat.dbf' 30000)"
where fsname is the same name used in the mount points above,
and db_name represents the name of the database and
db2user is the DB2 instance name (which in this case is the same as the DB2 user name)
Example:
On host bangalore, designated as the host containing the catalog partition -
db2 "create db kddb on /kdfs catalog tablespace managed by database
using (file '/kdfs/kdinst/NODE0000/kddb/cat.dbf' 30000)"
|
Connect to database
As the DB2 user, connect to the database as the DB2 user.
Use the command:
db2 connect to db_name
Example:
db2 connect to kddb
|
Create nodegroup
Create a nodegroup. You can create a nodegroup encompassing any subset of nodes you want.
Use the command:
db2 "create nodegroup nodegroup_name on nodes (1)"
Example:
db2 "create nodegroup KD_NODEGROUP on nodes(1)"
db2 "create nodegroup KD1_NODEGROUP on nodes(1,2,3,4,5)"
|
Create tablespaces
Create a tablespace under the nodegroup.
Use the command:
create tablespace tablespace_name in nodegroup nodegroup_name
managed by database
using (FILE '/fsname/db2user/NODE0001/datafile_name' 50000)
on node(1)
where nodegroup_name is the nodegroup created in above and
datafile_name is the name of the tablespace container.
If the nodegroup created above includes more than just one node,
you would specify a container for each of the nodes in the nodegroup.
Example:
db2 "create tablespace KD_TBS in nodegroup KD_NODEGROUP managed by database using
(FILE '/kdfs/kdinst/NODE0000/kdtbs0.dbf' 50000) on node(0)"
db2 "create tablespace KD1_TBS in nodegroup KD_NODEGROUP managed by database
using (FILE '/kdfs/kdinst/NODE0001/kdtbs1.dbf' 50000) on node(1)
using (FILE '/kdfs/kdinst/NODE0002/kdtbs2.dbf' 50000) on node(2)
using (FILE '/kdfs/kdinst/NODE0003/kdtbs3.dbf' 50000) on node(3)
using (FILE '/kdfs/kdinst/NODE0004/kdtbs4.dbf' 50000) on node(4)
using (FILE '/kdfs/kdinst/NODE0005/kdtbs5.dbf' 50000) on node(5)"
|
Create temporary tablespaces
Create temporary tablespace by running the command:
Use the command:
create temporary tablespace tablespace_name in nodegroup IBMTEMPGROUP
managed by database
using (FILE '/temporary fsname/db2user/NODE0000/temporary datafile_name' 10000)
on node(0)
where temporary datafile_name is the name of the temporary tablespace container.
If the nodegroup created above includes more than just one node, you would specify
a container for each of the nodes in the nodegroup.
Example:
db2 "create temporary tablespace TMPTBS_KD in nodegroup IBMTEMPGROUP
managed by database
using (FILE '/kdtmpfs/kdinst/NODE0000/tmp0.dbf' 10000)
on node(0)"
db2 "create temporary tablespace TMPTBS_KD in nodegroup IBMTEMPGROUP
managed by database
using (FILE '/kdtmpfs/kdinst/NODE0001/tmp1.dbf' 10000) on node(1)
using (FILE '/kdtmpfs/kdinst/NODE0002/tmp2.dbf' 10000) on node(2)
using (FILE '/ kdtmpfs/kdinst/NODE0003/tmp3.dbf' 10000) on node(3)
using (FILE '/ kdtmpfs/kdinst/NODE0004/tmp4.dbf' 10000) on node(4)
using (FILE '/ kdtmpfs/kdinst/NODE0005/tmp5.dbf' 10000) on node(5)"
|
Verify connection to second database partition
Connect to the second database partition.
As the DB2 user, export the DB2NODE environment variable to the number of
the database partition you want to connect to - in this case node 1.
Run the command: db2 terminate
Connect to the database using the command: db2 connect to db_name
Example:
export DB2NODE=1
db2 terminate
db2 connect to kddb
When you connect, you should be connected to node 1 and not node 0.
To check this, run the command: db2 list tablespaces
You should NOT see the catalog tablespace SYSCATSPACE listed.
The tablespace created above for node 1 should be listed.
Terminate the connection using the command: db2 terminate
|
Reconnect to catalog database partition
Go back to catalog database partition 0.
Example:
export DB2NODE=0
db2 terminate
db2 connect to kddb
|
Update the database configuration
Enable the database configuration parameters logretain and userexit
to make the database recoverable.
Use the command:
db2 update db cfg
Example:
db2 update db cfg for kddb using LOGRETAIN on
db2 update db cfg for kddb using USEREXIT on
|
Clear the backup-pending flag
Backup the database to make sure that the backup-pending flag is cleared.
Run the backup command:
db2 backup db db_name
Example:
db2 backup db kddb to /dev/null
|
New configuration parameters in DB2 UDB version 8.2
New configuration parameters for log file allocation, removal, and archiving have been
introduced in DB2 UDB version 8.2.Two new database configuration parameters, logarchmeth1
and logarchmeth2, have been added to handle log file allocation and removal.
These two parameters replace the userexit and logretain configuration parameters.
Advanced Copy Services for DB2 is currently using the userexit and logretain
configuration parameters. When you set the logretain configuration parameter to RECOVERY,
the logarchmeth1 configuration parameter is set to LOGRETAIN automatically. When you set
the userexit configuration parameter to ON, the logarchmeth1 configuration parameter is
set to USEREXIT automatically. For Advanced Copy Services for DB2, because you set both
logretain and userexit configuration parameters, the logarchmeth1 configuration parameter
is set to USEREXIT.
Set up the log directory
Create a separate volume group for the log directory (one per database host).
This volume group must not contain any user tablespaces, system tablespaces or
temporary tablespaces. Create a JFS or JFS2 filesystem on this volume group,
mount it and assign ownership of the filesystem to the DB2 user and its group.
Example:
For host bangalore:
/banlogfs on volume group banlogvg and logical volume banloglv
mount /banlogfs
chown -R kdinst:db2adm /banlogfs
For host delhi:
/dellogfs on volume group dellogvg and logical volume delloglv
mount /dellogfs
chown -R kdinst:db2adm /dellogfs
|
Update the log path
By default, when the database is created, the recovery log file is created in the
subdirectory SQLLOGDIR of the directory containing the database. Update the log path
for each database partition.
Run the following commands:
db2 update db config for database using NEWLOGPATH path to log filesystem
db2 force applications all
db2 terminate
Verify that the change has taken effect by:
db2 get db config for database
Example:
export DB2NODE=0
db2 terminate
db2 connect to kddb
db2 update db config for kddb using NEWLOGPATH /banlogfs
db2 force applications all
db2 terminate
db2 connect to kddb
db2 get db config for kddb
|
Update DB2 diagnosis level
Optionally, update the DB2 diagnosis level.
Use the following command:
db2 update dbm cfg using DIAGLEVEL 4
|
Create tables
Connect to catalog database partition and create some tables in the tablespace
created above.
Example:
export DB2NODE=0
db2 terminate
db2 connect to kddb
db2 -tvf crtbs_kddb
Here is the script crtbs_kddb:
create table parts
(partno Char(4) NOT NULL PRIMARY KEY,
description Varchar(20),
qonhand Integer,
qonorder Integer);
create table quotations
(suppno Char(3) NOT NULL,
partno Char(4) NOT NULL,
price Integer,
responsetime Integer,
PRIMARY KEY (suppno, partno));
create table orders
(suppno Char(3) NOT NULL,
partno Char(4) NOT NULL,
quantity Integer,
orderdate Date);
create table suppliers
(suppno Char(3) NOT NULL PRIMARY KEY,
name Varchar(35),
address Varchar(35));
|
Insert data into the tables
Insert data into the tables created above.
Example:
db2 -tvf instb_kddb
Here is the script instb_kddb:
INSERT INTO parts(partno, description, qonhand, qonorder)
VALUES('P207', 'Gear', 75, 20);
INSERT INTO parts(partno, description, qonhand, qonorder)
VALUES('P209', 'Cam', 0, 10);
.
.
.
INSERT INTO quotations(suppno, partno, price, responsetime)
VALUES('S51', 'P207', 950, 45);
INSERT INTO quotations(suppno, partno, price, responsetime)
VALUES('S51', 'P209', 1250, 10);
.
.
.
INSERT INTO suppliers(suppno, name, address)
VALUES('S51', 'ABC Parts Company', '123 Industrial Way, Cleveland OH');
INSERT INTO suppliers(suppno, name, address)
VALUES('S53', 'Parts Are We', '800 River Drive, Yonkers NY');
.
.
.
INSERT INTO orders(suppno, partno, quantity, orderdate)
VALUES('S53', 'P207', 20, 2006-6-15);
INSERT INTO orders(suppno, partno, quantity, orderdate)
VALUES('S51', 'P209', 10, 2006-6-20);
.
.
.
|
Terminate the database connection
Terminate the database connection.
Tivoli Storage Manager configuration
Tivoli Storage Manager 0perating environment
Use the following guidelines to ensure that your Tivoli Storage Manager operating environment
is set up correctly.
- You must execute the Tivoli Storage Manager for Advanced Copy Services for DB2 product
as root.
- All Advanced Copy Services for DB2 commands must be invoked from the Backup Master node.
The exception to this is the configuration wizard which is invoked from the
Tivoli Storage Manager client JAVA GUI launched from the DB2 UDB database host
containing the catalog database partition.
- Enable Tivoli Storage Manager server authentication to allow secure inter-client
communications.
-
dsmadmc -id=servadmin -pa=servpwd set authentication on
- Make sure you have installed 32-bit Tivoli Storage Manager API as Advanced Copy Services
for DB2 UDB requires it, even though the DB2 UDB Server may be operating in a 64-bit
environment.
- Define the environment variables DSM_DIR, DSM_CONFIG, DSM_LOG, DSMI_DIR,
DSMI_CONFIG and DSMI_LOG appropriately if not using the default values.
- Run the command dsmcad on each host (backup master node, all DB2 worker nodes
and all additional backup worker nodes) to enable inter-client communications.
- Ensure that your system options file dsm.sys and user options file
dsm.opt are configured as intended on each host for each process -
dsmcad, dsmagent and dsmc.
- To verify dsmcad settings, check the message ANS3000I in the dsmwebcl.log file.
If these are not set to desired values, change the setting and restart the dsmcad process.
Note that you will also have to restart the dsmcad if values are being changed
for dsmagent process. Make sure all the environment variables have been exported
(if not using default values) so that the dsmagent process gets the updated values.
- Do not change the server stanza name - servername option in the dsm.opt file
after completing a successful local backup. Otherwise, all the local backups on
Tivoli Storage Manager Server will get expired and a subsequent query or
local restore command will fail.
- On each host (backup master node, all DB2 worker nodes and all additional
backup worker nodes) set the passwordaccess to generate and ensure that
password has been cached by running the command dsmc query session.
- Do not specify the asnode option in the dsm.sys file as the multinode information
from the configuration settings is used.
- Run the commands slibclean and dsmc show plugins to ensure that all
the plugins such as DB2, Image, Snapshot and Hardware plug-ins are functioning correctly.
- In the dsmerror.log file, if you see a return code rc=52 and the error
"Unable to start a session from client node myNode multinode myMultiNode to client
at address ....", update the admin password on the Tivoli Storage Manager Server
by running the following command:
-
dsmadmc -id=servadmin -pa=servpwd update admin myNode myNodePassword
- In the dsmerror.log file, if you see error:
"ANS5216E Could not establish a TCP/IP connection ... (errno = 79)",
stop the dsmagent and dsmcad processes and restart dsmcad on all the
client nodes that form this configuration.
Configuring management policy on Tivoli Storage Manager server
Define a backup management policy for managing your DB2 UDB database backups.
- Define a policy domain to hold all your DB2 UDB backups.
-
define domain kddomain -description='Policy domain for Tivoli Storage Manager Advanced Copy Services - DB2 ESE'
- Define a policy set in the policy domain created above.
-
define policyset kddomain kdpolicy -description='Policy set for Tivoli Storage Manager Advanced Copy Services - DB2 ESE'
- Define management class, one for local backups and one for Tivoli Storage Manager backups.
-
define mgmtclass kddomain kdpolicy kdlocalmc -description='Management class for
Advanced Copy Services DB2 local backups'
-
define mgmtclass kddomain kdpolicy kdtsmmc -description='Management class for
Advanced Copy Services DB2 Tivoli Storage Manager backups'
- Define a backup copygroup for each of the management classes defined above.
Specify the number of backup versions the with verexists option.
-
define copygroup kddomain kdpolicy kdlocalmc standard -type=backup destination=BACKUPPOOL verexists=3
-
define copygroup kddomain kdpolicy kdtsmmc standard -type=backup destination=BACKUPPOOL verexists=5
- Make one of the management classes defined above the default.
-
assign defmgmtclass kddomain kdpolicy kdlocalmc
- Make the policyset defined above the active policy.
-
activate policyset kddomain kdpolicy
Multi node configuration on Tivoli Storage Manager Server
- Choose a target node name to represent all your DB2 UDB database federated backups.
The target node name is a user-defined name and does not have to correspond to any particular
machine in your configuration. Allow the target node to have permission to delete backups.
You can use the same target node to perform the federated backup of one or more
multi partition databases.
-
register node kd_asnode kd_pwd domain=kddomain -backdelete=yes
Here kd_asnode is the name of the target node.
It does not correspond to any physical machine.
- Define each database host configured as part of the multi partition database and each
backup host allocated for Advanced Copy Services for DB2 backups as a client node to
the Tivoli Storage Manager Server. Designate one of the backup nodes as the backup master node.
The backup master node will coordinate all the activities between the DB2 worker nodes and
the backup worker nodes for a given Advanced Copy Services for DB2 operation.
-
register node bangalore_db2 ban_pwd domain=kddomain
Here bangalore_db2 is the name of the DB2 Worker node.
This corresponds to a DB2 host.
-
register node delhi_db2 del_pwd domain=kddomain
Here delhi_db2 is the name of the DB2 Worker node.
This corresponds to a DB2 host.
-
register node kaveri_db2 kav_pwd domain=kddomain
Here kaveri_db2 is the name of the Backup Master node.
This corresponds to one of the backup hosts.
-
register node abhishek_db2 abi_pwd domain=kddomain
Here abhishek_db2 is the name of the Backup Worker node.
This corresponds to one of the backup hosts.
- Grant proxy authority to the target node to perform Advanced Copy Services for DB2
operations on behalf of all the client nodes that are part of this configuration.
-
grant proxynode target=kd_asnode agent=bangalore_db2,delhi_db2,kaveri_db2,abhishek_db2
Using the Advanced Copy Services for DB2 configuration wizard
You can use the Advanced Copy Services DB2 configuration wizard to specify Database,
Tivoli Storage Manager and Storage Subsystem user preferences.
Launch the configuration wizard from the DB2 Catalog host using the
Tivoli Storage Manager client Java GUI Utilities drop-down menu. You have the option to create a new configuration, modify or delete an existing configuration.
You are expected to provide the following information:
Database settings
- Database Server installation directory. Default is /usr/opt/db2_08_01
- Database Instance name. Example: kdinst
- Database Instance password. Example: kdpwd
- Database Instance home directory. Example: /home/kdinst
- Database name. Example: kddb
Tivoli Storage Manager settings
- Tivoli Storage Manager Target Node name. Example: kd_asnode
- Hostname - Tivoli Storage Manager Agent Node assignment.
Example:
-
bangalore - bangalore_db2
- Backup Master Node Host. Example: kaveri
- Local Backup Management Class. Example: kdlocalmc
- Tivoli Storage Manager Backup Management Class. Example: kdtsmmc
Storage Subsystem settings
ESS settings
- Copy Services User Name. Example: tdpess
- Copy Services User Password. Example: tdpesspwd
- Copy Services Installation Directory. Example: /opt/IBM/ESScli
- AVA Installation Directory. Example: /usr/java14
- Primary Copy Services Server Name: Example: myEss0.sanjose.ibm.com
- Backup Copy Services Server Name. Example: myEss1.sanjose.ibm.com
- Copy Services Target Volumes. Example: /home/myEss/myEssLuns
DS6000 and DS8000 settings
- CIM Agent Host Name. Example: panda01
- CIM Agent Port Number. Example: 5988
- CIM Agent User ID. Example: tdpds
- CIM Agent User Password. Example: tdpdspw
- CIM Agent Timeout Value. Example: 15
- Copy Services Target Volumes. Example: /home/myDs/myDsLuns
SVC settings
- CIM Agent Host Name. Example: ice
- CIM Agent Port Number. Example: 5988
- CIM Agent User ID. Example: tdpsvc
- CIM Agent User Password. Example: tdpsvcpw
- CIM Agent Timeout Value. Example: 15
- CIM Agent Copy Rate. Example: 100
- Copy Services Target Volumes. Example: /home/mySvc/mySvcLuns
Preview of your backup
After setting user preferences using the configuration wizard, you can verify if the
settings have been specified correctly to ensure a successful backup.
For example, a sufficient number of target LUNs have been specified.
On the Backup Master node, run the backup db2udb command with the preview option
for this purpose. Detailed status information will be written to the log file
$DSM_LOG/kddb.log. The command output will tell you if there are sufficient
resources available to perform a backup operation. You can examine the log file
to obtain additional information.
Example:
$DSM_DIR/dsmc backup db2udb -database=kddb -backupdestination=local -copytype=noincr -preview
Problem determination
Collecting Tivoli Storage Manager diagnostic information for problem determination
Default trace level
All Advanced Copy Services for DB2 functions have a minimum level of trace running
at all times which provides detailed status information for the function in progress.
Often this status log information along with the messages logged in dsmerror.log
should provide enough information about the error encountered.
Example:
$DSM_DIR/dsmc backup db2udb -database=kddb -backupdestination=both -copytype=any
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
Client Version 5, Release 3, Level 3.0
Client date/time: 03/13/06 14:39:20
(c) Copyright by IBM Corporation and other(s) 1990, 2006. All Rights Reserved.
Node Name: KAVERI_DB2
Session established with server TEMPLAR: AIX-RS/6000
Server Version 5, Release 3, Level 2.0
Server date/time: 03/13/06 14:39:56 Last access: 03/13/06 14:36:23
Accessing as node: KD_ASNODE
Detailed status information written to log /home/logs/kddb.log.
...
Here kddb.log is the default log file and /home/logs is the value of
environment variable DSM_LOG. If tracing is not enabled, a minimum level of trace is
logged to this file.
|
Enabling higher level of tracing
For all client nodes (DB2 production hosts and backup hosts), specify a path name for the
trace file on the local system.
Define the following options in dsm.opt configuration file for all the client nodes
involved in your configuration:
Example:
tracefile /home/logs/db2worker.trace (path to the trace file)
traceflags DB2HW (enables first level of tracing from all components)
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
or
traceflags DB2HW_DETAIL (enables full level of trace information, including DB2HW)
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
|
In this example, the trace file db2worker.trace is placed in the directory /home/logs
which is local to each host, thus ensuring a unique trace file for each dsmagent
process, even when dsm.opt is shared.
Stop dsmcad and dsmagent processes on all nodes and restart the dsmcad
so that the new options take effect.
For the dsmc client process which runs on the backup master node, use the
"-tracefile=pathname" option on command line to keep its trace
separate from the dsmagent process running on this node as the backup worker node.
dsmagent on the master node will use the trace file specified in the dsm.opt file.
Example:
dsmc backup db2udb -database=kddb -tracefile=/home/logs/db2master.trace
This will direct all the trace information from the dsmc process to
/home/logs/db2master.trace
Enabling tracing at run-time
Sometimes problems might be hard to recreate or they might show up after some other condition is met. For example, when dsmcad has been running for three days, it fails to start dsmagent. Under these cases, you can turn start, stop and configure client tracing
dynamically at runtime, using the dsmtrace utililty. Please see IBM Tivoli Storage Manager Problem Determination Guide for further information.
Collecting configuration information
Advanced Copy Services for DB2 functions have several application-specific configuration
files along with Tivoli Storage Manager options file dsm.sys and user options file
dsm.opt. It is very important to gather all the configuration information along with
trace information for effective problem determination. Tivoli Storage Manager provides a
simple command to collect all this information in one file, which can then be sent to
IBM for further analysis.
Run the following command on the backup master node:
dsmc query systeminfo db2udb -database=db config name
Example:
$DSM_DIR/dsmc query systeminfo db2udb -database=kddb
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
Client Version 5, Release 3, Level 3.0
Client date/time: 03/13/06 14:39:20
(c) Copyright by IBM Corporation and other(s) 1990, 2006. All Rights Reserved.
Node Name: KAVERI_DB2
Session established with server TEMPLAR: AIX-RS/6000
Server Version 5, Release 3, Level 2.0
Server date/time: 03/13/06 14:39:56 Last access: 03/13/06 14:36:23
QUERY SYSTEMINFO output has been written to file
/usr/tivoli/tsm/client/ba/bin/dsminfo.txt.
|
Diagnosing errors
DB2 UDB SQL errors
In case of DB2 UDB errors, Tivoli Storage Manager client error log file dsmerror.log
will show an SQL error code of the format SQL-xxxx as part of the error message.
Switch to DB2 User and query the SQL error code. You will get a detailed description of the
error.
Example:
su - kdinst
db2 ? SQL-1032
|
SQL-1032
If you get the SQL-1032 error message during backup db2udb, switch to DB2 User and issue the
start database manager command.
SQL-1032 - No start database manager command was issued.
Example:
su - kdinst
db2start
|
If you get the SQL-1032 error message during restore db2udb:
- Make sure that /home/db2user/.rhosts file has permissions 600.
- Run the command:
/DB2 installation directory/instance/db2iupdt db2instance
Example:
/usr/opt/db2_08_01/instance/db2iupdt kdinst
su - kdinst
db2start
|
SQL1116
After creating a new database, DB2 expects you to take a backup.
Otherwise you will see the error:
SQL1116 - A connection or activation of database dbname
cannot be made because of BACKUP PENDING.
Use the following command to clear the BACKUP PENDING flag:
Example:
su - db2user
db2 backup database dbname to /dev/null
|
SQL1005
If, for some reason, the DB2 uncatalog database operation fails during restore processing,
you will see the error:
SQL1005N - The database alias dbname already exists in either the local database
directory or system database directory.
Uncatalog the database using the command and retry the restore:
db2 uncatalog database dbname
TSM RC 5947
Since we are taking online snapshot backup of the database, it is important that
database logs are retained and archived in order to perform roll forward recovery.
Otherwise, we will see the following error:
Tivoli Storage Manager client RC = 5947 - Log Retain has not been enabled for the
database.
Connect to each database partition and issue the command update db config to
enable log retention.
Example:
su - kdinst
export DB2NODE=x where x=DB Partition number
db2 set client
db2 query client (should show that we are attached to DB Partition x)
db2 connect to kddb user kdinst using kdinst
db2 update database config using logretain on
db2 force applications all
db2 terminate
To query the update:
export DB2NODE=x where x=DB Partition number
db2 set client
db2 query client (should show that we are attached to DB Partition x)
db2 connect to kddb user kdinst using kdinst
db2 get database config
db2 terminate
|
TSM RC 5948
In order to perform roll forward recovery, we also need to enable user exits for archiving
logs. Otherwise, we will see the following error:
Tivoli Storage Manager client RC = 5948 - User Exit has not been enabled for the database.
Connect to each database partition and issue the command update db config to
enable user exits for archiving logs.
Example:
su - kdinst
export DB2NODE=x where x=DB Partition number
db2 set client
db2 query client (should show that we are attached to DB Partition x)
db2 connect to kddb user kdinst using kdinst
db2 update database config using userexit on
db2 force applications all
db2 terminate
To query the update:
export DB2NODE=x where x=DB Partition number
db2 set client
db2 query client (should show that we are attached to DB Partition x)
db2 connect to kddb user kdinst using kdinst
db2 get database config
db2 terminate
|
LUN is reserved
There are cases when a local flashcopy restore fails and the error logs for the
storage subsystem indicate the LUN is reserved error.
This can happen due to the following reasons:
- Advanced Copy Services for DB2 fails when trying to unmount and unconfigure the
database filesystems prior to performing the FlashCopy restore. The unmount failure
may be due to the device being busy because a user is using one of the database
filesystem directories. In this case, the user must exit from the database directory
and retry the local restore operation.
- SDD might place a reserve on the LUNs if your SDD configuration has only one path
to the storage subsystem from each host. Ensure that you have two or more paths to the
storage subsystem from each host.
- SDD may also place a reserve on the LUNs for other reasons, in which case FlashCopy
restore will fail. Use the SDD command lquerypr to query the reserved status
and free the LUNs.
Example:
lquerypr -Vh /dev/hdisk - to display reserved status
lquerypr -rh /dev/hdisk - to free reserved status
|
COPY or NOCOPY type of backup failure
COPY or NOCOPY type of backup failure is applicable to ESS, DS6000 and DS8000 only.
If you change the copy type from INCR to COPY or NOCOPY after performing a successful
local restore, the subsequent backup will fail. The reason for this is that the
source and target volumes will have been switched on the storage subsystem during the
local restore with incremental FlashCopy. The database source volumes are now the
target volumes of an incremental relationship and the storage subsystem will not
allow a target volume to be in a FlashCopy relationship with more than one
source volume at a given time. To avoid this problem, make sure that the first backup
after an incremental local restore is always an incremental backup.
Resources
About the author | 
| | Kala Dutta is currently working as a software engineer on
Tivoli Storage Manager at IBM San Jose. She has been the lead developer responsible
for adding support for various storage hardware such as IBM Enterprise Storage Server,
DS6000, DS8000, San Volume Controller, NetApp to IBM Tivoli Storage Manager.
Prior to joining the TSM team, she was involved in IBM OSI Network Management development.
Kala has received a Bachelor of Electrical Engineering degree from India and
a Master of Computer Engineering degree from
North Carolina State University, Raleigh. |
Rate this page
| |
