| One or more of your DB2 EEE partition servers fail to start | 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. |
| LifeKeeper “In- Service” or “Out-of- Service” operation hangs | 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 “In- Service” 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. |
| LifeKeeper First Switch over operation fails | The DB2 Fenced User may not have been created on the backup server. Verify the DB2 Fenced User for the specified instances exists with the same user and group id for the primary. Ensure that the protected instance is also a member of the Administration Server group. |
| 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. |
| Creating a DB2 Resource Hierarchy takes a long time | Creating a resource may take long time to protect DB2 instance that has large DB. Activate before creating a resource. Command to activate database: db2 activate db <db_name>. See considerations below. |
| DB2 Database not active after a switchover | The DB2 Kit uses implicit activation for databases after a failover. This means that the kit does not explicitly activate each database during a switchover of failover for performance reasons. Instead, the first connection to the database activates that database. |
Considerations:
Note: This kit was originally designed for implicit activation. This means that the first connection to the database activates that database. If an explicit activation is desired as a part of a switchover or failover, a generic app can be created to activate the database(s) as needed. Using explicit activation prior to resource creation has been shown to reduce the time required to create DB2 resources and associated file system dependencies.
The command to activate a database implicitly is as follows:
- db2 “connect to <dbname>”.
To locate/activate the database within a gen_app, please use the following command:
- su – db2user -c ‘db2 activate db ${dbname}’
This information was pulled from an IBM Support page. Please see IBM Support for further clarification on db2 usage.
Error Messages
Refer to the DB2 Recovery Kit Message Catalog for a list of all messages that may be encountered while utilizing the DB2 kit.
Post your comment on this topic.