Have a question about db2Gdba? Send a quick mail to support@db2gdba.com

Tip: db2 Monitor switches

To get the max of information from the db2Gdba interfaces, make sure instances of the monitored databases have the monitor switches set on. For example, if you have a blocking process in your running application list, and you click on the lock chain button to see the blocking processes id and statements, you must have the DFT_MON_LOCK monitor switch ON. Blocking statements will show up if the monitor switch DFT_MON_STMT is also ON. We recommend to set ON the following switches:

DFT_MON_BUFPOOL, DFT_MON_LOCK,  DFT_MON_SORT, DFT_MON_STMT, DFT_MON_STMT, DFT_MON_TABLE, DFT_MON_TIMESTAMP, and DFT_MON_UOW.

To set the monitors switches on/off, run at the instance level the command:

db2 update dbm cfg using monitor_name ON/OFF

Q. How the db2Gdba works? 

A. The db2Gdba is a stand alone windows application provided as one executable file and a few drivers. Since it is a database client designed to connect and manage solely IBM DB2 LUW databases, it requires a DB2 client installed on your workstation. We recommend IBM DB2 9.7 runtime client as minimum.
Any database to be connected using the db2Gdba, must be previously cataloged using the IBM DB2 client. The workstation local DB2 cataloged directory is visible to the db2Gdba in its starting connection window, and it can be used to save database connection parameters for later use.

Q. How can I see running processes and how they are performing? 

A. Using the Application tab or Activity tab.

Using the Application tab Refresh button all connections to the database are displayed. Select the "show only active sessions" box (default) to filter only active connections. Refer to the support page 1 for the active connection definition.

You can see the statements any application is performing by selecting it from the grid  and clicking on the Statements button. This action opens the window showing all the statements involved with the application.

Important to the dba or developer parameter values like total rows read, written; total cost estimated; cardinality estimated, and others, reflect performance of these statements and can hint the dba or developer about issues like index to be created, or index statistics to be updated, or SQL modifications to do among other things.

Since one application can be running statements with different nesting levels, this window shows the total number of statements and it displays their command in order of the nesting level. Parameter values corresponding to the different nesting level are separated by a pipe (|),  unless the total aggregated values is shown.

Activity tab also shows currently running processes with other important metrics like the time spent on waiting.

Q. How can I see locked applications?

A. Locked applications appear on the Application or Activity tabs when their status is Lock Waiting. If you select an application in Lock Waiting state, you can see the lock chain by clicking on the Lock Chain button. The lock chain illustrates the list of applications that are stopping the selected application from doing its statement. This way the dba can follow on the first command blocking everybody else.

Most of the time the first locking application in the chain  is in executing state. The statement flow should resume after it finishes and releases the lock held. However, there are occasions when the locking application hasn't just committed its statements, and even a simple select can cause other processes to get locked. I have seen this before with users using db2 clients like Toad, for example, which does not commit by default and one forgets to explicitly do it.