Troubleshooting DB2 in a TPM 3.1 Environment

I want to share some general troubleshooting information for DB2 in regards to IBM Tivoli Provisioning Manager 3.1 environments. 90% of the problems I’ve encountered can be solved by these steps and having a general understanding of how ITPM’s handles it’s data.

Starting DB2

When you start ITPM it will fail if DB2 isn’t already running. For whatever reasons, they didn’t include an autostart of DB2 that exists in other products, like ITDS.

Unix
$db2start
You should see the following output if successfully started

11/28/2008 08:32:56     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

Windows
From the services window, start the service “DB2 – <instance_name>”
Default service name in ITIO / ITPM 3.1 is “DB2 – DB2-0”

Once you think DB2 is started, you can verify that it is running using the netstat command.
netstat –an |grep 50000 – verify port is LISTENING

DB2 Processes

When DB2 is up and running, you will notice there are a lot of processes that refer to db2 running.

UNIX

db2fmd
db2dasrrm
db2fmcd
db2wdog
db2sysc
db2ckpwd
db2gds
db2syslog
db2ipccm
db2tcpcm
Db2resync
db2srvlst
db2agent (LDAP)
db2fmp
db2agent (TIOINTER)
db2loggr (TC)
db2loggw (TC)
db2dlock (TC)
db2pfchr
db2pclnr
db2event (DB2DETAILDEADLOCK)

Windows

Db2 running on Windows is thread-based (not process-based), so you will only see one db2syscs for all of the instances.

A useful tool is db2_local_ps. It will list all DB2 processes running on a UNIX system.

ITPM’s Connection to DB2

ITPM uses two mechanisms for connecting to DB2. The first one is a established through java using the connection information found in the $TIO_HOME/config/dcm.xml. This file stores the db2 driver path, db2 alias table name, db username, and the encrypted password. ITPM will decrypt the password as needed to establish a connection to the DB. When experiencing connection errors, verify the information in this file is correct.

<config>
<database>
<type>db2</type>
<driver>COM.ibm.db2.jdbc.app.DB2Driver</driver>
<url>jdbc:db2:TC</url>
<name>TC</name>
<username>db2inst1</username>
<password>QJsdAjUEHi8=</password>
</database>
</config>

The other connection uses the J2C Kula user information stored in the Websphere Application Server. You can reference this information though the WAS admin console, navigate to Security -> JAAS Configuration -> J2C Authentication Data. If for some reason you need to update the userID or password to connect to the database, you need to update both the $TIO_HOME/config/dcm.xml and the Kula user.

To test a connection to the database use the following commands. You can run these commands from the command line on a Linux/UNIX system. On Windows you must run these from a db2 command line.

db2 connect to <db_name> user <db_user> using <db_user_password>
example: db2 connect to TC user db2inst1 using password

Useful commands
db2 list tables – lists all tables under schema name you are logged in as
db2 list tables for all – lists all tables in the database (all schemas)
db2 describe table <table_name> – describes table <table_name>

ITPM’s DB2 Tables

TPM utilizes a series of scripts to build its DB2 tables. The directory $TIO_HOME/sql contains all of the scripts. The script that builds the schema is the $TIO_HOME/sql/db2/dbschema.sql. This script is called on every reinit, and will drop and add every table in the database. Use this script to research what the tables look like in the database as well as researching constraint information.

Useful TPM Tables

DCM_OBJECTS – contains a list of all dcm_objects (ID is same in UI). Important dcm_object is ID=0, name=KANAHA which represents TIO (NOT the server that TIO is running on). Hovering over an object will return the object ID stored in this table

PROPERTIES – contains all properties for all dcm_objects. All system wide variables are stored in this table under id=0 (KANAHA)

DCM_OBJECT_WORKFLOW – lists all workflows associated with an object

WORKFLOW4 – contains all workflows ASCII source code (NOTE: There are several associated tables that contain compiled workflow information)

Order of XML Import

When importing an xml file regardless of the order you place objects in your file, objects are loaded in a predefined order. The tool parses the entire file being loaded and populates a data structure such that objects can be loaded in this order. There are a couple of objects that do require a 2 pass technique to be loaded. This is due to the fact that they may contain references to objects further down the list to be loaded. The second pass picks up these few exceptions.

The order of import:

Device Model Category
Device Model
Discovery
RequireDement Specifications
Resource Type Specifications
Address Space
Subnetwork
vlan
customer
ACL
raid-redundancy
storage-function-type
storage-policy-setting
storage-template
Volume-container-setting
SAN
storage-allocation-pool
storage-subsystem
Event-type-specifications
Custom Event Customer
Event Subscription
Power Unit
Switch
Load Balancer
Boot Server
Software Distribution Applications
Software Module
Software Category
Software
Installable package
Software Patch
Software Stack
Cluster Admin Server
Blade Admin Server
Spare Pool
Virtual IP
Software Applications Module
Objective Analyzer Type
Terminal Server
Servers
Monitoring Application
Monitoring Configuration
Group Monitoring Configuration
Virtual Server Template
Logical Cluster
Image
Deployment Plan Template
Deployment Plan
Module
Third Party Software Packages
File Repository
Report Category
SP Service
SP Subscription
Kanaha Config
Cluster Domain

2nd pass
subnetwork
Switch
Storage-subsystem
Server
Load-Balancer