Database (DB2 Instance - Middleware) Test

The Database (DB2® Instance - Middleware) tests the DB2 manager status of the DB2 instance on the data server by running the db2status script.

Resources

The Database (DB2 Instance - Middleware) test uses the following resource:

The DB2 Middleware instance (on the data server)

Problem determination

If the Database (DB2 Instance - Middleware) test fails, do the following to find and resolve the access problem.

Procedure

Use the platform control tool to check the status of the components and to start and stop them as needed. Run the following command with the desired options. For component use dbsdb24mid and specify your topology password for topology_password.
1. To check the status of the component run the following commands:
```
su - ibmadmin

IOCControl -a status -c component -p topology_password
```
2. To start the component run the following commands:
```
su - ibmadmin

IOCControl -a start -c component -p topology_password
```
3. To stop the component run the following commands:
```
su - ibmadmin

IOCControl -a stop -c component -p topology_password
```
Use the platform control tool to check the status of the component and to start and stop it as needed. For component use db24mid and specify your topology password for topology_password.
1. To check the status of the component run the following commands:
```
su - ibmadmin

IOCControl -a status -c component -p topology_password
```
2. To start the component run the following commands:
```
su - ibmadmin

IOCControl -a start -c component -p topology_password
```
3. To stop the component run the following commands:
```
su - ibmadmin

IOCControl -a stop -c component -p topology_password
```
Check that there is network connectivity between the application server where the test was initiated and the data server where the database resides. This can be done by sending ping commands with both the short and fully-qualified host name of the data server from the application server. The results of the ping commands will show if the host name is being correctly resolved by the DNS or /etc/hosts file.
Review the log files for runtime exceptions.
1. On the application server review the following WebSphere® Portal logs:
  - /opt/IBM/WebSphere/wp_profile/logs/WebSphere_Portal/SystemOut.log
  - /opt/IBM/WebSphere/wp_profile/logs/WebSphere_Portal/SystemErr.log
  On the directory server, review the following Tivoli® Directory Server logs:
  - /datahome/dsrdbm01/idsslapd-dsrdbm01/logs/ibmslapd.log
  - /datahome/dsrdbm01/idsslapd-dsrdbm01/logs/db2cli.log
  - /datahome/dsrdbm01/idsslapd-dsrdbm01/logs/audit.log
Verify that the file system on the data server has not reached capacity. This can be determined by running the df -h command. The file system can be considered full even if it less than 100% used. For this reason if the df -h command returns that the file system is 90% or more full, you should consider that the file system has reached capacity.
Verify that the database manager used by the data server is started.
1. On the data server, run the following command from a command window as the Middleware instance user.
```
db2 get snapshot for dbm | grep "Database manager status" 
```
  If the database manager is started for the Middleware instance, the following message is displayed: Database manager status = Active.
If the DB2 processes are not running, start them by running su - db2inst1 from the command window if running as the root user. Otherwise, run db2start to start the Database Manager.
Check the DB2 logs for errors related to the database instance used for this test. The logs are located on the data server in the /datahome/db2inst1/sqllib/db2dump directory.
Check the db2diag.log for errors issued when starting the database used for this test.

What to do next

Resolve any issues or errors found and retry the test.