LifeKeeper for Linux DB2 Recovery Kit v5.2.1 Administration Guide

LifeKeeper for Linux DB2 Recovery Kit v5.2.1 Administration Guide
LifeKeeper® for Linux
DB2 Recovery Kit v5.2.1 Administration
Guide
February 2011
SteelEye and LifeKeeper are registered trademarks.
Adobe Acrobat is a registered trademark of Adobe Systems Incorporation. Apache is a trademark of The
Apache Software Foundation. HP and Compaq are registered trademarks of Hewlett-Packard Company.
IBM, POWER, DB2, Informix, ServeRAID, Rational and ClearCase are registered trademarks or
trademarks of International Business Machines Corporation. Intel, Itanium, Pentium and Xeon are
registered trademarks of Intel Corporation. Java is a registered trademark of Sun Microsystems, Inc.
Linux is a registered trademark of Linus Torvalds. Microsoft Internet Explorer and Windows are
registered trademarks of Microsoft Corporation. MySQL and MaxDB are registered trademarks or
trademarks of MySQL AB. Netscape and Netscape Navigator are registered trademarks of Netscape
Communications Corporation. NFS is a registered trademark of Sun Microsystems, Inc. Opteron is a
trademark of Advanced Micro Devices, Inc. Oracle is a registered trademark of Oracle Corporation
and/or its affiliates. PostgreSQL is a trademark of PostgreSQL Global Development Group. Red Flag is
a registered trademark of Red Flag Software Co.,Ltd. Red Hat is a registered trademark of Red Hat
Software, Inc. SAP is a registered trademark of SAP AG. Sendmail is a registered trademark of
Sendmail, Inc. Sun and Solaris are registered trademarks of Sun Microsystems, Inc. SUSE is a registered
trademark of SUSE LINUX AG, a Novell business. Sybase is a registered trademark of Sybase, Inc.
Other brand and product names used herein are for identification purposes only and may be trademarks
of their respective companies.
It is the policy of SIOS Technology Corp. (previously known as SteelEye Technology, Inc.) to improve products as new technology, components, software, and firmware become available. SIOS Technology Corp., therefore, reserves the right to
change specifications without prior notice.
To maintain the quality of our publications, we need your comments on the accuracy, clarity, organization, and value of this book.
Address correspondence to:
ip@us.sios.com
Copyright © 2011
By SIOS Technology Corp.
San Mateo, CA U.S.A.
All Rights Reserved
Table of Contents
Introduction ................................................................................................................................................................... 3
Document Contents ................................................................................................................................................ 3
LifeKeeper Documentation .................................................................................................................................... 4
DB2 Recovery Kit Requirements .................................................................................................................................. 5
Hardware Requirements ......................................................................................................................................... 5
Software Requirements .......................................................................................................................................... 5
Overview ....................................................................................................................................................................... 6
LifeKeeper for Linux DB2 Recovery Kit ............................................................................................................... 6
Configuring the LifeKeeper for Linux DB2 Recovery Kit ........................................................................................... 7
Using DB2 with Raw I/O ....................................................................................................................................... 7
Running DB2 on the 2.4 Kernel ............................................................................................................................. 7
Running DB2.......................................................................................................................................................... 7
Configuration Considerations for DB2 Single Partition ......................................................................................... 8
Configuration Considerations for DB2 Multiple Partition ..................................................................................... 8
Issues Regarding DB2 EEE or multiple partition ESE and NFS..................................................................... 8
Configuration Requirements ........................................................................................................................... 9
Configuration Considerations for All DB2 configurations................................................................................... 11
Configuration Examples ....................................................................................................................................... 12
LifeKeeper Configuration Tasks ................................................................................................................................. 16
Overview .............................................................................................................................................................. 16
Creating a DB2 Resource Hierarchy .................................................................................................................... 17
Deleting a Resource Hierarchy............................................................................................................................. 18
Extending Your Hierarchy ................................................................................................................................... 20
Unextending Your Hierarchy ............................................................................................................................... 22
Testing Your Resource Hierarchy ........................................................................................................................ 23
Performing a Manual Switchover from the LifeKeeper GUI ........................................................................ 23
Troubleshooting........................................................................................................................................................... 24
Error Messages ..................................................................................................................................................... 25
Common Error Messages .............................................................................................................................. 25
Hierarchy Creation ........................................................................................................................................ 25
Hierarchy Extension ...................................................................................................................................... 26
Restore .......................................................................................................................................................... 26
Resource Monitoring ..................................................................................................................................... 26
DB2 Recovery Kit Error Messages ...................................................................................................................... 27
LifeKeeper GUI Related Errors............................................................................................................................ 29
Appendix: Setting up DB2 to use Raw I/O ................................................................................................................. 31
Requirements ........................................................................................................................................................ 31
Naming Conventions ............................................................................................................................................ 31
Raw I/O Setup Steps ............................................................................................................................................ 31
LifeKeeper for Linux
1
DB2 Recovery Kit
Administration Guide
Introduction
The LifeKeeper for Linux DB2 Recovery Kit provides fault resilient protection for DB2 database
instances. LifeKeeper, together with the DB2 Universal Database product family afford
increased availability to DB2 operating environments by effectively recovering database server
failures without significant down-time or human intervention.
Document Contents
This guide contains the following topics:
•
•
•
•
•
•
•
LifeKeeper Documentation. A list of LifeKeeper for Linux documentation and where to
find them.
Requirements. A description of the hardware and software necessary to properly setup,
install, and operate the DB2 Recovery Kit. Refer to the LifeKeeper for Linux Planning and
Installation Guide for specific instructions on how to install or remove LifeKeeper for Linux
software.
Overview. A description of the DB2 Recovery Kit’s features and functionality.
Configuring the LifeKeeper for Linux DB2 Recovery Kit. A description of the procedures
required to properly configure the DB2 Recovery Kit.
LifeKeeper Configuration Tasks. A description of the tasks for creating and managing your
DB2 resource hierarchies using the LifeKeeper GUI.
Troubleshooting. A list of LifeKeeper for Linux error messages including a description for
each.
Appendix. Steps for setting up DB2 to use raw I/O.
LifeKeeper for Linux
3
Introduction
LifeKeeper Documentation
The following LifeKeeper product documentation is available from SIOS Technology Corp.:
LifeKeeper for Linux Release Notes
LifeKeeper for Linux Online Product Manual (available from the Help menu within the
LifeKeeper GUI)
• LifeKeeper for Linux Planning and Installation Guide
This documentation, along with documentation associated with optional LifeKeeper Recovery
Kits, is available on the SIOS Technology Corp. website at:
•
•
http://us.sios.com/support
4
DB2 Recovery Kit Administration Guide
DB2 Recovery Kit Requirements
DB2 Recovery Kit Requirements
Your LifeKeeper configuration must meet the following requirements prior to the installation of
the LifeKeeper for Linux DB2 Recovery Kit. Please see the LifeKeeper for Linux Planning and
Installation Guide for specific instructions regarding the configuration of your LifeKeeper
hardware and software.
Hardware Requirements
•
•
Servers - LifeKeeper for Linux supported servers configured in accordance with the requirements
described in the LifeKeeper for Linux Planning and Installation Guide and the LifeKeeper
Release Notes.
IP Network Interface Cards - Each server requires at least one Ethernet TCP/IP-supported
network interface card. Remember, however, that a LifeKeeper cluster requires two
communications paths; two separate LAN-based communication paths using dual independent
sub-nets are recommended for heartbeats, and at least one of these should be configured as a
private network. Using a combination of TCP and TTY heartbeats is also supported.
Software Requirements
•
•
•
•
TCP/IP Software - Each server in your LifeKeeper configuration requires TCP/IP software.
IBM Software - Please refer to the LifeKeeper Release Notes for specific DB2 version
requirements on certain Linux distributions and hardware architectures.
LifeKeeper Software - It is imperative that you install the same version of the LifeKeeper
software and apply the same versions of the LifeKeeper software patches to each server in your
cluster.
LifeKeeper for Linux DB2 Recovery Kit - The DB2 Recovery Kit is provided on a CD. It is
packaged, installed and removed via the Red Hat Package Manager, rpm. The following rpm file
is supplied on the LifeKeeper for Linux DB2 Recovery Kit CD:
steeleye-lkDB2
Please see the LifeKeeper for Linux Planning and Installation Guide for specific instructions on
the installation and removal of the LifeKeeper for Linux software.
•
LifeKeeper for Linux NFS Recovery Kit - required for use of DB2 EEE and multiple
partition ESE deployments. This recovery kit is provided on CD in the steeleye-lkNFS
package.
Important: See the section Issues Regarding DB2 EEE or multiple partition ESE and NFS for
important configuration information.
LifeKeeper for Linux
5
Overview
Overview
LifeKeeper for Linux DB2 Recovery Kit
In versions 8 and greater, DB2 UDB Enterprise Edition (EE) and Enterprise-Extended Edition
(EEE) have been combined into a single product named DB2 UDB Enterprise Server Edition
(ESE). Previous versions included two separate enterprise level database servers, the Enterprise
Edition (EE) as a standard relational database management system and the Enterprise-Extended
Edition (EEE) as an extension of the EE database server to support multi-partition databases.
The LifeKeeper for Linux DB2 Recovery Kit provides protection for the database manager in the
EE, WE, and WSE environments, and for the database partition servers in an EEE environment.
In a combined ESE environment, the recovery kit provides protection for both the database
manager and the database partition servers.
Users may elect to define the DB2 Administration Server for each machine within the LifeKeeper
cluster. When the DB2 Administration server is defined, LifeKeeper will attempt to start the
DB2 Administration Server as a function of the DB2 hierarchy create and the DB2 hierarchy
restore operations.
6
DB2 Recovery Kit Administration Guide
Configuring the LifeKeeper for Linux DB2
Recovery Kit
Configuring the LifeKeeper for Linux DB2
Recovery Kit
This section describes the LifeKeeper for Linux DB2 Recovery Kit configuration details. It also
contains information you should consider before you start to configure and administer the DB2
Recovery Kit. Please refer to your LifeKeeper Online Product Manual for instructions on
configuring LifeKeeper Core resource hierarchies.
Using DB2 with Raw I/O
If you plan to use DB2 with Raw I/O devices, you must install the LifeKeeper Raw I/O Recovery
Kit from the LifeKeeper Core CD. You must also properly set up the Raw I/O devices prior to
use. See the Appendix for instructions.
Running DB2 on the 2.4 Kernel
When running DB2 on a system with the 2.4 kernel, you should perform the following on each
server in the cluster:
1. Set the following ipcs limits in /etc/sysctl.conf before configuring LifeKeeper.
# changes for DB2
kernel.sem = 250 128000 32 1024
kernel.shmall = 16777216
kernel.msgmni = 1024
2. Run sysctl -p to set the above changes in the kernel.
3. On certain distributions you may need to add sysctl -p to the system initialization file (i.e.
boot.local or rc.local) so that these kernel changes are set after each reboot.
4. Refer to the IBM documentation for additional information on shared memory requirements.
Running DB2
In some instances the startup times of the DB2 processes can be excessive when using DB2 8.x
under LifeKeeper protection. Making the following change to the kernel network parameters can
improve this situation. As above, add the following line to the /etc/sysctl.conf file on each
LifeKeeper clustered system that will be running DB2 8.x:
net.ipv4.tcp_syn_retries=1
Then running sysctl –p will cause this change to take effect.
LifeKeeper for Linux
7
Configuring the LifeKeeper for Linux DB2
Recovery Kit
Configuration Considerations for DB2 Single Partition
The following should be considered before operating the LifeKeeper for Linux DB2 Recovery
Kit in the single partition or workgroup environment:
1. LifeKeeper requires the location of the DB2 instance home directory as well as associated
databases, tablespaces, and resources be stored on shared drives. The shared drives are
automatically protected at the time the hierarchy is created. During creation of the DB2
resource hierarchy, the DB2 database manager is created as the parent resource while the
shared file systems containing instance home directories and actual databases are created as
dependent resources. Consequently, if after the creation of your DB2 hierarchy you decide
to create a database on a shared file system that is not protected by LifeKeeper, you will need
to create a resource hierarchy for that file system and make it a dependency of your DB2
resource hierarchy.
2. When the database manager becomes inoperable on the primary system, the service fails over
to a previously defined backup system. The database service on the backup system becomes
available immediately after the dependent resources fail over and the database manager is
brought into service. Previously connected DB2 clients are disconnected and must reconnect
to the functioning server. Any uncommitted SQL statements are rolled back and should be
re-entered.
Configuration Considerations for DB2 Multiple Partition
DB2 Multiple Partition RESTRICTIONS: All DB2 multiple database partition servers will be
protected on a particular machine when the LifeKeeper DB2 resource hierarchy is created on that
machine. The nodes to protect are determined by examining the following file:
<instance home>/sqllib/db2nodes.cfg
Future plans for this recovery kit include added functionality to allow for N-way failover.
Issues Regarding DB2 EEE or multiple partition ESE and NFS
If the NFS export point for the DB2 instance home directory becomes unavailable while the DB2
instances are running, the system will hang while waiting for the export point to become available
again. Many system operations will not work correctly, including a system reboot. You should be
aware that the NFS server for the DB2 multiple partitions cluster should be protected by
LifeKeeper and should not be manually taken out of service unless all the partitions in the DB2
cluster are also taken out of service before shutting down the NFS resource. Additionally, the
DB2 partitions cannot be brought into service unless the NFS resource is in service.
To avoid accidentally causing your cluster to hang by inadvertently stopping the NFS server, we
make the following recommendations:
NFS Recommendations
Use additional servers: It is highly recommended that you have a separate cluster for the NFS
export point from which the DB2 instance home is mounted. The NFS export point on this cluster
should be protected with the LifeKeeper NFS Server Recovery Kit.
8
DB2 Recovery Kit Administration Guide
Configuring the LifeKeeper for Linux DB2
Recovery Kit
If you do not have at least two additional servers available, you can reduce the chances of
experiencing the problem described above by adding one additional server to the DB2 cluster.
This additional server would export the NFS hierarchy. One of the other nodes in the cluster
would serve as a backup. In this configuration the symptoms could occur if the NFS
hierarchy were to failover to the backup node. The NFS export point on this cluster should be
protected with the LifeKeeper NFS Server Recovery Kit.
If you cannot use additional servers: This is the least desirable option. However, if you
decide to run your NFS server in the same cluster as your DB2 multiple partitions, the NFS
export point should be protected with the LifeKeeper NFS Server Recovery Kit. You should
note that LifeKeeper currently is not aware of the relationship between the DB2 partitions
and the NFS server managing the DB2 partitions. Therefore, you must follow these manual
procedures before stopping or starting LifeKeeper on any node in the cluster
1. If you wish to stop LifeKeeper on a single server, you must make sure that the NFS
server is active on another server in the cluster. Failure to do this may cause the LifeKeeper
shutdown to hang trying to take the DB2 partitions out of service. Generally, you should
make sure that all DB2 partitions are either switched to another server or manually taken out
of service before you stop LifeKeeper to ensure you don't have problems trying to restart
LifeKeeper.
2. To shut down the entire cluster, you should manually take all DB2 partition resources out
of service. Next, take all the DB2 NFS server resources out of service, and finally shut down
LifeKeeper.
3. If you remembered to take the DB2 resource out of service before shutting down
LifeKeeper, you should be able to restart LifeKeeper normally. Then bring the NFS server
resources into service, followed by any DB2 partitions you wish to restart.
4. If you forgot to take the DB2 partition out of service before shutting down LifeKeeper,
you must make sure that the NFS server resources for that partition are active elsewhere in
the cluster before you restart LifeKeeper.
Configuration Requirements
To ensure proper operation of the DB2 Recovery Kit in a multiple partition environment,
LifeKeeper requires the following:
1. If you cannot use an additional cluster for your NFS hierarchy, be aware that the LifeKeeper
for Linux DB2 Recovery Kit restricts the occurrence of active inodes on an underlying NFSprotected file system. Therefore, to prevent this condition, we recommend that users protect
the top-level directory and export the instance home directory using the fully qualified
directory name. The top-level directory is protected in order to prohibit users from changing
directories directly into it (i.e. cd <top level dir>).
2. Verify the installation of IBM’s latest Fix Pack (for EEE deployments) as described in the
Software Requirements section of this document.
3. Ensure that the hostname value in your db2nodes.cfg file is the same as the value returned
from issuing the hostname command.
Example:
db2nodes.cfg file:
0 server1.sc.steeleye.com 0
LifeKeeper for Linux
9
Configuring the LifeKeeper for Linux DB2
Recovery Kit
Additionally, the hostname value in your server’s /etc/hosts file must be the same as the
hostname value in your db2nodes.cfg file.
You must also verify that your server’s /etc/hosts file contains both the local hostname and
the fully qualified hostname for each server entry included in the file.
Example:
/etc/hosts file
127.0.0.1 localhost localhost.localdomain
9.21.55.53 server1.sc.steeleye.com
server1
4. During execution of the db2setup script, do not opt to create the DB2 Warehouse Control
Database (DWCNTRL) or the DB2 Sample Database at this time. The databases need to be
created on a shared file system to ensure successful creation of the DB2 resource hierarchy.
Electing to create either of these databases during execution of the db2setup script will cause
the database to be created in the home directory and not on a shared file system. Users
wishing to create these databases should do so external to the db2setup script in order to
specify a shared file system.
In versions later than 8.1, the DB2 Tools Catalog should not be created during the setup
script. This database must be placed o a shared file system and should be created after setup
has completed and prior to hierarchy creation, if necessary.
5. In Active/Active or multiple partition server environments, each server in the configuration
must be capable of running all database instances in a failover scenario. Please see the IBM
Getting Started Guide for help determining the maximum number of DB2 instances or
partition servers feasible for a given set of system resources.
6. Select or create a shared file system, then export this file system. (i.e /export/db2home). The
file system will be used as the DB2 instance home.
7. Protect your exported file system by creating a LifeKeeper NFS resource hierarchy. The file
system should be included as a dependent resource in your NFS hierarchy.
8. NFS mount the shared file system on each server in the cluster including the server where it is
being exported. See the DB2 Quickstart Guide for mount options. When creating the DB2
instance, the home directory of the instance must be located on the NFS mounted file system.
Make certain that the file system is mounted using the LifeKeeper protected switchable IP
address used when creating the NFS hierarchy. Additionally, the mount point of the home
directory must be specified in the /etc/fstab file on all servers in your LifeKeeper cluster.
Each server in your configuration must have the file system mounted on identical mount
points (i.e. /db2/home).
NOTE: We recommend that you create and test your NFS hierarchy prior to creating your
DB2 resource hierarchy. Please see the LifeKeeper for Linux NFS Server Recovery Kit
Administration Guide for complete instructions on creating and testing a NFS hierarchy
9. For all servers in your configuration, set the following DB2 environment variable to equal the
total number of partitions in the instance. To set this variable, log on to the server as the
instance owner and issue a db2set command. Adjusting this variable will accommodate all
conceivable failover scenarios.
db2set DB2_NUM_FAILOVER_NODES=<partitions in the instance>
10
DB2 Recovery Kit Administration Guide
Configuring the LifeKeeper for Linux DB2
Recovery Kit
10. Update your existing DB2 instances and your DB2 Administration servers using the
following DB2 utilities:
db2iupdt and dasupdt
11. A LifeKeeper DB2 hierarchy must be created on each server in the cluster that has a database
partition server managing data for the instance. The databases and tablespaces must be on a
shared file system. A separate LUN is required for each database partition server and for the
NFS exported home directory. Dependent resources include the file systems where actual
databases and tablespaces are located.
12. If you create a database on a non-protected LifeKeeper file system after the creation of your
DB2 hierarchy, you will need to create a resource hierarchy for that file system and make it a
dependency of your DB2 resource hierarchy. The hierarchy will protect all of the partition
servers that the db2node.cfg file indicates should run on the server.
13. To ensure proper execution of a failover, it is imperative that the file system of each database
partition server is uniquely numbered.
Example:
The mount point for your database partition server node0 should be:
/<FSROOT>/<db2instancename>/NODE0000
The mount point for your database partition server node1 should be:
/<FSROOT>/<db2instancename>/NODE0001
Note: In this example there are two partition servers, and the file system for each is mounted
on a separate LUN.
14. All database partition servers for a given machine must be running in order to assure the
successful creation of your DB2 hierarchy.
15. When the database partition server becomes inoperable on the primary system, the service
fails over to a previously defined backup system. The database service on the backup system
becomes available immediately after the dependent resources fail over and the database
partition server(s) is brought into service. Previously connected DB2 clients are disconnected
and must reconnect to the functioning server. Any uncommitted SQL statements are rolled
back and should be re-entered.
Configuration Considerations for All DB2 configurations
1. DB2 instance names should contain alphanumeric characters only.
2. DB2 clients should be configured to connect to the database via a LifeKeeper protected IP
address. Users can define:
“DB2SYSTEM=<Floating IP>” in $instancehome/sqllib/profile.env
and catalog the floating IP address on the clients.
3. The /etc/services file for each server in your configuration protecting a DB2 resource
hierarchy must have identical service entries for the protected instance. Additionally, the
User ID, Group ID, and instance home directory for the protected DB2 instance, must be the
same on all servers where the resource will be protected.
LifeKeeper for Linux
11
Configuring the LifeKeeper for Linux DB2
Recovery Kit
4. A recovery is what takes place after DB2 is terminated abruptly, as with a system crash.
Following are tips that will significantly reduce the amount of time it takes for DB2 to
recover from a failure.
•
Limit the log records that DB2 will process. You can accomplish this by properly
configuring the SOFTMAX and LOGFILSIZ configuration parameters. You should
use log files with a size of 4MB (1000 4KB pages) and keep the amount of active log
space at 25% of the size of one log file (1MB):
db2 UPDATE DB CFG FOR <dbname> USING SOFTMAX 25
db2 UPDATE DB CFG FOR <dbname> USING LOGFILSIZ 1000
•
Ensure that there is a sufficient number of page cleaners to accommodate your work load:
db2 UPDATE DB CFG FOR <dbname> USING NUM_IOCLEANERS <num>
Configuration Examples
A few examples of what happens during a failover using LifeKeeper for Linux DB2 Recovery Kit are
provided below. In the following pictures, EE and EEE are used to denote database configurations; ESE
may be substituted wherever appropriate.
Configuration 1: DB2 Single Partition Active/Standby Configuration
Primary Server
Backup Server
Server 1
Server 2
EE
DBMS
Shared
Storage
The DB2 instance is protected on Server 1. Server 2 will assume the DB2 resources when a
failure occurs.
Configuration 2: DB2 Single Partition Active/Active Configuration
Server 1
Server 2
EE
DBMS
EE
DBMS
Shared
Storage
12
DB2 Recovery Kit Administration Guide
Configuring the LifeKeeper for Linux DB2
Recovery Kit
One DB2 instance is protected on Server 1 and another DB2 instance is protected on Server 2.
Each server will assume the other’s resources when a failure occurs.
Configuration 3: DB2 Multiple Partition Active/Standby (1 Cluster)
Server 1
EEE
Server 2
EEE
Partition 1 Partition 2
Shared
Storage
One DB2 instance with two database partition servers is protected on Server 1 with one
LifeKeeper DB2 resource hierarchy. Server 2 will assume ownership of the DB2 resource
hierarchy when a failure occurs.
Note: For all cluster of cluster configurations listed in the following section, users should be
aware that the cluster of cluster configuration is protecting only one DB2 instance with multiple
partitions on multiple physical nodes.
Configuration 4: DB2 Multiple Partition Active/Standby (Cluster of Clusters)
Server 1
EEE
Partition 1
Server 2
EEE
Server 3
EEE
Partition 2
Partition 3
Server 4
EEE
Partition 4
Shared
Shared
Storage
Storage
One DB2 instance with two database partition servers is protected on
Server 1 and two database partition servers protected on Server 3. There is one LifeKeeper DB2
resource hierarchy on Server 1, extended to Server 2, and another DB2 resource hierarchy on
Server 3 extended to Server 4. When a failure occurs on Server 1, Server 2 will assume its
resource. When a failure occurs on Server 3, Server 4 will assume its resource.
If the server that is exporting the DB2 instance home directory and its backup server become
inoperable at once, the DB2 database is inaccessible. In addition, if the NFS hierarchy for the
exported DB2 instance directory (primary and all backups) become inoperable at the same time,
the DB2 database will be inaccessible until the NFS hierarchy can be restored.
LifeKeeper for Linux
13
Configuring the LifeKeeper for Linux DB2
Recovery Kit
Configuration 5: DB2 Multiple Partitions Active/Active (1 Cluster)
Server 1
Server 2
EEE
EEE
Partition 1
Partition 2
Shared
Storage
One DB2 instance with one database partition server is protected on Server 1 and one database
partition server protected on Server 2. There is one LifeKeeper DB2 resource hierarchy on
Server 1 and another DB2 resource hierarchy on Server 2. When a failure occurs each server will
assume the other’s resources.
Configuration 6: DB2 Multiple Partitions Active/Active (Cluster of Clusters)
Server 1
EEE
Partition 1
Server 2
EEE
Partition 2
EEE
Partition 3
Shared
Storage
Server 3
EEE
Partition 4
Server 4
EEE
Partition 5
EEE
Partition 6
Shared
Storage
One DB2 instance with two database partition servers is protected on Server 1, one database
partition server protected on Server 2, one database partition server protected on Server 3 and two
database partition servers protected on Server 4. There is one LifeKeeper DB2 resource
hierarchy on each server in the cluster. Upon failure, Server 1 and Server 2 assume each other’s
resources and Server 3 and Server 4 assume each other’s resources.
If the server that is exporting the DB2 instance home directory and its backup server become
inoperable at once, the DB2 database is inaccessible. In addition, if the NFS hierarchy for the
exported DB2 instance directory (primary and all backups), become inoperable at the same time,
the DB2 database will be inaccessible until the NFS hierarchy can be restored.
14
DB2 Recovery Kit Administration Guide
Configuring the LifeKeeper for Linux DB2
Recovery Kit
Configuration 7: DB2 Multiple Partition (4 Node Fibre Channel Cluster)
Server 1
EEE
Partition 1
Server 2
EEE
Partition 2
EEE
Partition 3
Server 3
EEE
Partition 4
Server 4
EEE
EEE
Partition 5
Partition 6
Shared
Storage
One DB2 instance with two database partition servers is protected on Server 1, one database
partition server protected on Server 2, one database partition server protected on Server 3 and two
database partition servers protected on Server 4. There is one LifeKeeper DB2 resource
hierarchy on each server in the cluster. Each server in the cluster provides backup protection for
the other in the event of failure.
If the server that is exporting the DB2 instance home directory and its backup server become
inoperable at once, the DB2 database is inaccessible. In addition, if the NFS hierarchy for the
exported DB2 instance directory (primary and all backups), become inoperable at the same time,
the DB2 database will be inaccessible until the NFS hierarchy can be restored.
LifeKeeper for Linux
15
LifeKeeper Configuration Tasks
LifeKeeper Configuration Tasks
You can perform all LifeKeeper for Linux DB2 Recovery Kit administrative tasks via the
LifeKeeper Graphical User Interface (GUI). The LifeKeeper GUI provides a guided interface to
configure, administer, and monitor DB2 resources.
Overview
The following tasks are available for configuring the LifeKeeper for Linux DB2 Recovery Kit:
•
•
•
•
•
•
•
•
•
Create a Resource Hierarchy - Creates a DB2 resource hierarchy
Delete a Resource Hierarchy - Deletes a DB2 resource hierarchy
Extend a Resource Hierarchy - Extends a DB2 resource hierarchy from the primary server
to the backup server.
Unextend a Resource Hierarchy - Unextends (removes) a DB2 resource hierarchy from a
single server in the LifeKeeper cluster.
Create Dependency - Creates a child dependency between an existing resource hierarchy
and another resource instance and propagates the dependency changes to all applicable
servers in the cluster.
Delete Dependency - Deletes a resource dependency and propagates the dependency changes
to all applicable servers in the cluster.
In Service - Activates a resource hierarchy.
Out of Service - Deactivates a resource hierarchy.
View/Edit Properties - View or edit the properties of a resource hierarchy.
.
16
DB2 Recovery Kit Administration Guide
LifeKeeper Configuration Tasks
Creating a DB2 Resource Hierarchy
Perform the following on your primary server:
1. Select Edit > Server > Create Resource Hierarchy.
2. The “Select Recovery Kit” dialog appears. Select the DB2 Database option from the drop
down list.
Click Next to continue.
CAUTION: If you click the Cancel button at any time during the sequence of creating your
hierarchy, LifeKeeper will cancel the entire creation process.
3. The “Switchback Type” dialog appears. The switchback type determines how the DB2
resource will be switched back to the primary server when it becomes in-service (active) on
the backup server following a failover. Switchback types are either intelligent or automatic.
Intelligent switchback requires administrative intervention to switch the resource back to the
primary server while automatic switchback occurs as soon as the primary server is back on
line and reestablishes LifeKeeper communication paths.
Click Next to continue.
4. The “Server’’ dialog appears. Select the name of the server where the DB2 resource will be
created (typically this is your primary server). All servers in your cluster are included in the
drop down list box.
Click Next to continue.
5. The “DB2 Instance” dialog appears. Select or enter the name of the DB2 instance that is
being protected.
Click Next to continue.
6. An information box appears displaying information regarding the instance detected.
LifeKeeper for Linux
17
LifeKeeper Configuration Tasks
Click Continue.
7. The “Database Tag” dialog appears. This dialog is populated automatically with a unique
tag name for the new DB2 database resource instance.
Click Create to continue.
8. An information box appears indicating the start of the hierarchy creation.
Click Next to continue.
9. An information box appears announcing the successful creation of your DB2 resource
hierarchy. You must Extend the hierarchy to another server in your cluster in order to place
it under LifeKeeper protection.
Click Continue to extend the resource.
Click Cancel if you wish to extend your resource at another time.
10. Click Done to exit the Create Resource Hierarchy menu selection.
Deleting a Resource Hierarchy
To delete a DB2 resource from all servers in your LifeKeeper configuration, complete the
following steps:
18
DB2 Recovery Kit Administration Guide
LifeKeeper Configuration Tasks
1. From the LifeKeeper GUI menu, select Edit, then Resource. From the drop down menu,
select Delete Resource Hierarchy.
2. Select the name of the Target Server where you will be deleting your DB2 resource
hierarchy.
Note: If you selected the Delete Resource task by right-clicking from either the left pane on
a global resource or the right pane on an individual resource instance, this dialog will not
appear.
Click Next to continue.
3. Select the Hierarchy to Delete. Identify the resource hierarchy you wish to delete, and
highlight it.
Note: If you selected the Delete Resource task by right-clicking from either the left pane on
a global resource or the right pane on an individual resource instance, this dialog will not
appear.
Click Next to continue.
4. An information box appears confirming your selection of the target server and the hierarchy
you have selected to delete.
Click Delete to continue.
5. An information box appears confirming that the DB2 resource instance was deleted
successfully.
LifeKeeper for Linux
19
LifeKeeper Configuration Tasks
6. Click Done to exit the Delete Resource Hierarchy menu selection.
Extending Your Hierarchy
After you have created a hierarchy, you should extend that hierarchy to another server in the
cluster. There are three possible ways to extend your resource instance:
1. When you successfully create your DB2 resource hierarchy you will have an opportunity to
select Continue which will allow you to proceed with extending your resource hierarchy to
your backup server.
2. Right-click on an unextended hierarchy in either the left or right pane on the LifeKeeper GUI.
3. Select the “Extend Resource Hierarchy” task from the LifeKeeper GUI by selecting Edit,
Resource, Extend Resource Hierarchy from the drop down menu. This sequence of
selections will launch the Extend Resource Hierarchy wizard. The Accept Defaults button
that is available for the Extend Resource Hierarchy option is intended for the user who is
familiar with the LifeKeeper Extend Resource Hierarchy defaults and wants to quickly
extend a LifeKeeper resource hierarchy without being prompted for input or confirmation.
Users who prefer to extend a LifeKeeper resource hierarchy using the interactive, step-bystep interface of the GUI dialogs should use the Next button.
a. The first dialog box to appear will ask you to select the Template Server where your
DB2 resource hierarchy is currently in service. Remember that the Template Server you
select now and the Tag to Extend that you select in the next dialog box represent an inservice (activated) resource hierarchy. An error message will appear if you select a
resource tag that is not in service on the template server you have selected. The drop
down box in this dialog provides the names of all the servers in your cluster.
Note: If you are entering the Extend Resource Hierarchy task by continuing from the
creation of a DB2 resource hierarchy, this dialog box will not appear because the wizard
has already identified the template server in the create stage. This is also the case when
you right-click on either the DB2 resource icon in the left pane or right-click on the DB2
resource box in the right pane of the GUI window and choose Extend Resource
Hierarchy.
20
DB2 Recovery Kit Administration Guide
LifeKeeper Configuration Tasks
CAUTION: If you click the Cancel button at any time during the sequence of extending
your hierarchy, LifeKeeper will cancel the extend hierarchy process. However, if you
have already extended the resource to another server, that instance will continue to be in
effect until you specifically unextend it.
Click Next to continue.
b. Select the Tag to Extend. This is the name of the DB2 instance you wish to extend from
the template server to the target server. The wizard will list in the drop down box all of
the resources that you have created on the template server.
Note: Once again, if you are entering the Extend Resource Hierarchy task immediately
following the creation of a DB2 hierarchy, this dialog box will not appear because the
wizard has already identified the tag name of your resource in the create stage. This is
also the case when you right-click on either the DB2 resource icon in the left pane or on
the DB2 resource box in the right pane of the GUI window and choose Extend Resource
Hierarchy.
Click Next to continue.
c. Select the Target Server where you will extend your DB2 resource hierarchy.
Click Next to continue.
d. The Switchback Type dialog appears. The switchback type determines how the DB2
resource will be switched back to the primary server when it becomes in service (active)
on the backup server following a failover. Switchback types are either intelligent or
automatic. Intelligent switchback requires administrative intervention to switch the
resource back to the primary server while automatic switchback occurs as soon as the
primary server is back on line and reestablishes LifeKeeper communication paths.
Click Next to continue.
e. Select or enter a Template Priority. This is the priority for the DB2 hierarchy on the
server where it is currently in service. Any unused priority value from 1 to 999 is valid,
where a lower number means a higher priority (1=highest). The extend process will reject
any priority for this hierarchy that is already in use by another system. The default value
is recommended. Note: This selection will appear only for the initial extend of the
hierarchy.
Click Next to continue.
f.
Select or enter the Target Priority. This is the priority for the new extended DB2
hierarchy relative to equivalent hierarchies on other servers. Any unused priority value
from 1 to 999 is valid, indicating a server’s priority in the cascading failover sequence for
the resource. A lower number means a higher priority (1=highest). Note that LifeKeeper
LifeKeeper for Linux
21
LifeKeeper Configuration Tasks
assigns the number “1” to the server on which the hierarchy is created by default. The
priorities need not be consecutive, but no two servers can have the same priority for a
given resource.
Click Next to continue.
g. An information box appears explaining that LifeKeeper has successfully checked your
environment and that all requirements for extending this resource have been met. If there
are requirements that have not been met, LifeKeeper will disable the Next button, and
enable the Back button.
Click on the Back button to make changes to your resource extension.
Click Cancel to extend your resource another time.
Click Next to launch the Extend Resource Hierarchy configuration task.
Click Finish to confirm the successful extension of your DB2 resource instance.
4. Click Done to exit the Extend Resources Hierarchy menu selection.
Note: Be sure to test the functionality of the new instance on both servers.
Unextending Your Hierarchy
1. From the LifeKeeper GUI menu, select Edit, Resource, and Unextend Resource Hierarchy.
2. Select the Target Server where you want to unextend the DB2 resource. It cannot be the
server where the resource is currently in service (active).
Note: If you selected the Unextend task by right-clicking from either the left pane on a global
resource or the right pane on an individual resource instance, this dialog will not appear.
Click Next to continue.
3. Select the DB2 Hierarchy to Unextend.
Note: If you selected the Unextend task by right-clicking from either the left pane on a
global resource or the right pane on an individual resource instance, this dialog will not
appear.
22
DB2 Recovery Kit Administration Guide
LifeKeeper Configuration Tasks
Click Next to continue.
4. An information box appears confirming the target server and the DB2 resource hierarchy you
have chosen to unextend.
Click Unextend.
5. Another information box appears confirming that the DB2 resource was unextended
successfully.
6. Click Done to exit the Unextend Resource Hierarchy menu selection.
Testing Your Resource Hierarchy
You can test your DB2 resource hierarchy by initiating a manual switchover that will simulate a
failover of the resource instance from the primary server to the backup server.
Performing a Manual Switchover from the LifeKeeper GUI
You can initiate a manual switchover from the LifeKeeper GUI by selecting Edit, Resource, and
In Service. For example, an in-service request executed on a backup server causes the DB2
resource hierarchy to be placed in-service on the backup server and taken out-of-service on the
primary server. At this point, the original backup server is now the primary server and original
primary server has now become the backup server.
If you execute the Out of Service request, the resource hierarchy is taken out-of-service without
bringing it in-service on the other server. The resource can only be brought in-service on the same
server, if it was taken out-of-service during resynchronization.
Important: After bringing your resource hierarchy in service on the backup server, you should
attempt to connect to the databases, especially when using raw devices as tablespace containers.
This is necessary to ensure that all disk partitions are visible on the backup servers and the raw
bindings are being established correctly.
If the raw bindings have not been established on the backup servers, it is most likely caused by
the fact that new partitions were created on the primary server and added to the configuration, but
the partition tables have not yet been updated on the backup servers.
The solution is to reboot the backup servers so that the partition tables are updated correctly.
LifeKeeper for Linux
23
Troubleshooting
Troubleshooting
Symptom
One or more of your
DB2 EEE partition
servers fail to start
LifeKeeper “InService” or “Out-ofService” operation
hangs.
Possible Cause
The db2nodes.cfg file’s port number may have
erroneously outgrown the range set in the
/etc/services file. View the number of ports set in
the db2nodes.cfg file and ensure that the ports range
value in the /etc/services file is large enough to
accommodate.
The DB2 environment variable:
DB2_NUM_FAILOVER_NODES may not have
been properly set. Ensure that for all servers in your
configuration, this environment variable is set to
equal the total number of partitions in the instance.
EXAMPLE:
db2set DB2_NUM_FAILOVER_NODES=<partitions in
instance>
LifeKeeper “InService” operation
hangs.
The dasupdt command may not have been executed
on the DB2 Administration server. Ensure that the
dasupdt command was successfully executed on the
DB2 Administration server.
The DB2 Fenced User may not have been created on
LifeKeeper First
Switch over operation the backup server. Verify the DB2 Fenced User for
the specified instances exists with the same user and
fails
group id for the primary. Ensure that the protected
instance is also a member of the Administration
Server group.
24
You need to add a
new node to your
existing DB2
resource hierarchy
Please see the nodes utility man page for complete
instructions on adding a new node to your currently
existing LifeKeeper DB2 resource hierarchy.
Administration
Server fails to start
Verify another Administration Server is not already
running on specified port.
DB2 Recovery Kit Administration Guide
Troubleshooting
Error Messages
Common Error Messages
Error
Number
Error Message
000002
Usage error
000010
Error getting resource information
000011
Both Tag and ID name not specified
000019
Resource not found on local server
000022
END failed hierarchy <tag name> in service on server
<servername>
000026
END failed ACTION for <tag name> on server <servername>
due to <signal> signal
Hierarchy Creation
Error
Number
Error Message
000012
Switchback type not specified
000013
Usage error
000014
Resource with either matching tag <tag name> or ID exists
000015
ins_create failed on server <server name>
000018
Error creating resource <tag name> on server <server name>
000021
Removing resource instance < tag name> from server <server
name> due to an error during creation
000023
Error bringing resource < tag name> in service on server
<server name>
000024
Failed resource creation of resource < tag name> on server
<server name>
000027
Removing file system dependency from <parent tag> to <child
tag> on server <server name> due to an error during creation
000028
Removing file system hierarchy <filesys tag> created by
<parent tag> on server <server name> due to an error during
creation
000029
000030
Switchback type mismatch between parent <parent tag> and
child <child tag> on server <server name>
Action: Switchback mismatches can lead to unexpected
behavior. You can manually alter switchback types for
resources using the ins_setas command to eliminate this
mismatch.
create: tag name not specified
or
extend: tag name not specified
LifeKeeper for Linux
25
Troubleshooting
Hierarchy Extension
Error
Number
Error Message
000003
Template resource < tag name> on server <server name> does
not exist
000004
Template resource < tag name> cannot be extended to server
<server name> because it already exists there
000005
Cannot access canextend script on server <server name>
000006
Cannot access extend script <path to extend> on server <server
name>
000007
Cannot access depstoextend script <path to depstoexend> on
server <server name>
000008
Cannot extend resource < tag name> to server <server name>
000009
Either <templatesys> or <templatetag> argument missing
000014
Resource with either matching tag < tag name> or ID exists
000015
ins_create failed on server <server name>
000018
Error creating resource < tag name> on server <server name>
000025
END failed resource extension of < tag name> on server
<server name> due to a "<signal>" signal - backing out changes
made to server
000030
create: tag name not specified
or
extend: tag name not specified
Restore
Error
Number
Error Message
000023
Error bringing resource < tag name> in service on server <server
name>
Resource Monitoring
26
Error
Number
Error Message
000001
Calling sendevent for resource < tag name> on server <server
name>
DB2 Recovery Kit Administration Guide
Troubleshooting
DB2 Recovery Kit Error Messages
Error
Number
Error Message
103001
Usage: nodes -t tag -a add_nodenum | nodes -t tag -d
delete_nodenum | nodes –t tag -p
103002
The DB2 instance "%s" is not a EEE or multiple partition
instance
103003
Node "%s" is already protected by this hierarchy
103004
LifeKeeper is unable to get the equivalent instance for resource
"%s"
103006
The argument for the DB2 instance is empty
103007
Unable to determine the DB2 instance home directory
103008
Unable to determine the DB2 instance type
103009
LifeKeeper has detected an error while trying to determine the
node number(s) of the DB partition server(s) for the instance.
Please verify that the "<InstanceHome>/sqllib/db2nodes.cfg" file
is not corrupted
103010
The path "%s" is not on a shared filesystem
103011
An NFS hierarchy does not exist for the tag "%s" on server "%s"
103012
LifeKeeper was unable to create a dependency between the
DB2 hierarchy "%s" and the NFS hierarchy "%s" on server "%s"
103013
DB2 version “%s” is not installed on server "%s"
103014
The instance owner "%s" uids are different on target server "%s"
and template server "%s"
103015
The instance owner "%s" gids are different on target server "%s"
and template server "%s"
103016
The /etc/services entries for the instance "%s" are different on
target server "%s" and template server "%s"
103017
The home directory "%s" for instance "%s" is not mounted on
server "%s". Please mount the DB2 Instance home directory
103018
Unable to get the information for resource "%s" on system "%s"
103019
LifeKeeper successfully started the database server for instance
"%s"
103020
LifeKeeper successfully started database partition server "%s"
for instance "%s"
103021
LifeKeeper successfully stopped the database server for
instance "%s"
103022
LifeKeeper successfully stopped database partition server "%s"
for instance "%s"
103023
Unable to get the instance information for resource "%s" on
server "%s"
LifeKeeper for Linux
27
Troubleshooting
28
Error
Number
Error Message
103024
Unable to get the instance home directory information for
resource "%s" on server "%s"
103025
Unable to get the instance type information for resource "%s" on
server "%s"
103026
Unable to get the instance nodes information for resource "%s"
on server "%s"
103027
LifeKeeper was unable to start the database server for instance
"%s". Please correct the problem then bring the resource in
service manually
103028
LifeKeeper was unable to start database partition server "%s"
for instance "%s". Please correct the problem then bring the
resource in service manually
103029
LifeKeeper was unable to stop the database server for instance
"%s"
103030
LifeKeeper was unable to stop database partition server "%s" for
instance "%s"
103031
The database server is not running for instance "%s"
103032
No databases were located for instance "%s"
103033
LifeKeeper was unable to make a connection to database "%s"
through database partition server "%s"
103034
One or more of the database partition servers for instance "%s"
is down
103035
LifeKeeper was unable to mount the home directory for the DB2
instance "%s"
103036
The file system resource "%s" is not in-service on system "%s"
103037
LifeKeeper was unable to get the tablespace containers for DB2
instance "%s" or the log path for one of its databases
103038
The NFS resource "%s" is not in-service on system "%s"
103039
A LifeKeeper resource does not exist for the DB2 home
directory export point "%s" on system "%s". Please
create the NFS Hierarchy, then try to create the DB2
hierarchy again
103040
LifeKeeper could not disable the automatic startup feature of
DB2 instance "%s". Please manually disable this feature by
executing "db2set DB2AUTOSTART -null" as the instance
owner
103041
The instance owner "%s" home directories are different on
target server "%s" and template server "%s"
103042
LifeKeeper was unable to add instance "%s" and/or its variables
to the DB2 registry on target server "%s". Please add the
instance and its variables manually using "db2iset"
103043
LifeKeeper was unable to start the DB2 Administration Server
on this system"
103044
LifeKeeper has encountered an error while trying to determine
the name of the DB2 Administration Server
DB2 Recovery Kit Administration Guide
Troubleshooting
Error
Number
Error Message
103045
LifeKeeper has encountered an error while trying to get the
database configuration parameters for database "%s"
103046
LifeKeeper was unable to get the DB2 "SVCENAME" parameter
for the DB2 instance
103047
LifeKeeper was unable to get the contents of the "/etc/services"
file on the server "%s"
103049
LifeKeeper was unable to get the version for the requested
instance “%s”
103050
LifeKeeper was unable to set the information for resources “%s”
on system “%s”
103051
DB2 version “%s” software is not properly installed on server
“%s”
103052
An entry for the home directory “%s” of instance “%s” does not
exist in /etc/fstab
103053
Node number “%s” is the last remaining node protected by
resource “%s”. Deleting all nodes is not allowed.
Action: Delete the current hierarchy or add additional nodes
using the nodes utility before attempting to remove the current
node.
103054
LifeKeeper protected nodes for instance “%s” are “%s”
103055
The instance owner “%s” does not exist on target server “%s”
103056
Invalid input provided for "%s" utility operation, characters are
not allowed.
103057
Usage: “%s” instance “%s”
103058
Unable to get the value of the DB2
"SVCENAME" parameter for the DB2 instance
%s.
Action: Verify that the SVCENAME paramater
is set in the dbm cfg for the specified
instance.
103059
Unable to determine the DB2 install path
LifeKeeper GUI Related Errors
Error
Number
Error Message
104901
The mount point %s is mounted
Action: Please specify a mount point that is not mounted
104902
The mount point %s is not an absolute path
Action: Please specify a mount point that begins with a slash
104903
The mount point %s is not empty.
Action: Please specify a mount point that does not exist or is
LifeKeeper for Linux
29
Troubleshooting
Error
Number
Error Message
empty
30
DB2 Recovery Kit Administration Guide
Appendix: Setting up DB2 to use Raw I/O
Appendix: Setting up DB2 to use Raw I/O
There are several requirements for configuring RAW I/O devices for DB2 so that the DB2
instance can be protected by LifeKeeper.
Requirements
•
•
•
The Linux OS must support Raw I/O devices. For most distributions this support was
included in the 2.4 kernel, but there are some distributions that support Raw I/O on a 2.2.
kernel.
All Raw I/O devices must be bound to a shared disk partition. A number of shared SCSI
disk partitions is required. The exact number is determined by the number of tablespaces that
will be located on Raw I/O devices. (Please see to DB2 documentation for guidelines for
writing tablespaces on raw devices).
DB2 Version 7.1 Fix Pack 3 or later OR DB2 Version 8 or higher is required.
Naming Conventions
The naming of the raw device and controller varies by Linux distribution.
•
•
On Red Hat the device name is /dev/raw/raw<number> and the controller is /dev/rawctl.
On SuSE the name of the device is /dev/raw<number> and the controller varies
between/dev/raw, /dev/rawctl, and /dev/raw/rawctl
Raw I/O Setup Steps
The following steps 1-4 were taken from Section 7.3.1.1 (“Using Raw I/O on Linux”) of the IBM
DB2 Universal Database Release Notes Version 7.2/Version 7.1 Fix Pack 3. In this example, the
raw partition to be used is /dev/sda5. It should not contain any valuable data.
Note that step 4 or 5 will vary depending upon whether you are using Multiple Logical Nodes.
1. Calculate the number of 4 096-byte pages in this partition, rounding down if necessary. For
example:
# fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 255 heads, 63 sectors, 1106 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot
/dev/sda1
/dev/sda2
/dev/sda5
Start
1
524
524
End
23
1106
1106
Blocks
4200997
4682947+
4682947
Id
83
5
83
System
Linux
Extended
Linux
Command (m for help): q
#
LifeKeeper for Linux
31
Appendix: Setting up DB2 to use Raw I/O
The number of pages in /dev/sda5 is:
num_pages = floor( ((1106-524+1)*16065*512)/4096 )
num_pages = 11170736
2. Bind an unused raw device node to this partition. Since this needs to be done every time the
machine is rebooted, and requires root access, you may want to add the raw bindings to a
system initialization file (i.e. rc.local or boot.local. These bindings must be removed once
the hierarchy is under LifeKeeper protection. LifeKeeper will re-establish the raw
bindings for Raw I/O devices that are under LifeKeeper protection.
Use raw -qa to see which raw device nodes are already in use:
raw /dev/raw/raw1 /dev/sda5
/dev/raw/raw1: bound to major 8, minor 5
3. Set global read permissions on the raw device controller and the disk partition. Set global
read and write permissions on the raw device:
# chmod a+r /dev/rawctl
# chmod a+r /dev/sdb1
# chmod a+rw /dev/raw/raw1
4. Important: This step only applies if you are using DB2 EE OR your DB2 EEE configuration
will never run Multiple Logical Nodes (MLNs) even after failover. If the configuration may
run MLNs at some point, proceed to step 5.
Create the tablespace in DB2, specifying the raw device, not the disk partition. For example:
CREATE TABLESPACE dms1
MANAGED BY DATABASE
USING (DEVICE '/dev/raw/raw1' 11170736)
Tablespaces on raw devices are also supported for all other page sizes supported by DB2.
5. Important: This step must be followed if the configuration is running MLNs or will run
MLNs at some point after failover.
Create the table space in DB2, specifying the raw device, not the disk partition, and specify a
different raw I/O device node for each DB2 instance partition. For example:
CREATE TABLESPACE dms1
MANAGED BY DATABASE
USING (DEVICE '/dev/raw/raw1' 11170736) on NODE
(NODENUM)
USING (DEVICE ‘/dev/raw/<different raw device node>’
####### ) on NODE (NODENUM)
Note: ON NODE must be used because each DB2 node (database partition server) must use
a different raw I/O device. This must be specified even if the node is running on a different
machine so that the failover will work correctly.
32
DB2 Recovery Kit Administration Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising