Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Unattended Monitoring of Random, Multi-Client DB2* Stress Workload

IP.com Disclosure Number: IPCOM000015188D
Original Publication Date: 2001-Oct-12
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 47K

Publishing Venue

IBM

Abstract

Disclosed is a method to automate the monitoring of a system test workload in an environment where data is randomly generated from testcase to testcase. This method will notify the system tester or developer only in the event of an error condition. This in turn frees up time spent unnecessarily monitoring the testcase in the absence of errors. In most automated environments a scheme to check results without user intervention exists. In most cases that scheme involves maintaining an expected results file. The output of the testcase is then compared to the expected results. If there are any differences, these are reported to the user. This works very well in an environment where the testcases are static. It is impossible to use this method in a multi-client environment where the output/results of testcases the "users" would run is random. This situation arises in most system test environments. Here is a sample situation. The system tester has a suite of C applications with embedded SQL (Structured Query Language). These applications use a random seed. Based on this random seed the application will generate data. Each pass through the application can generate different results depending on the seed. A manual check of the database instance by the user can determine the status of the testcase. In a fully automated environment the system tester should not have to manually intervene if the testcase is still running (i.e. there are no problems). The problem to solve is to provide a series of checks that can be automated such that the user is only notified when there is a problem. In a DB2 environment, the status of a testcase can be verified by looking at a few key items. 1. Monitor timestamp of last client log

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 2

Unattended Monitoring of Random, Multi-Client DB2* Stress Workload

    Disclosed is a method to automate the monitoring of a system test workload in an environment where data is randomly generated from testcase to testcase. This method will notify the system tester or developer only in the event of an error condition. This in turn frees up time spent unnecessarily monitoring the testcase in the absence of errors.

In most automated environments a scheme to check results without user intervention exists. In most cases that scheme involves maintaining an expected results file. The output of the testcase is then compared to the expected results. If there are any differences, these are reported to the user. This works very well in an environment where the testcases are static. It is impossible to use this method in a multi-client environment where the output/results of testcases the "users" would run is random. This situation arises in most system test environments.

Here is a sample situation. The system tester has a suite of C applications with embedded SQL (Structured Query Language). These applications use a random seed. Based on this random seed the application will generate data. Each pass through the application can generate different results depending on the seed. A manual check of the database instance by the user can determine the status of the testcase. In a fully automated environment the system tester should not have to manually intervene if the testcase is still running (i.e. there are no problems). The problem to solve is to provide a series of checks that can be automated such that the user is only notified when there is a problem. In a DB2 environment, the status of a testcase can be verified by looking at a few key items.

1. Monitor timestamp of last client log

If the filesystem timestamp of the client log has not been touched within some user determined threshold then an alert is generated. This could indicate the clients have not completed an operation in some time and may all may be in an unexpected wait state or a problem occurred at the server.

2. Monitor transaction rates

Use an application that collects database statistics via "db2 snapshot" api's. Over a user defined interval it will collect information related to the database activity such as the number of transactions, statements, connections, etc. If this falls below a certain user defined threshold an alert is generated. This would imply there is no database activity.

3. Monitor the number of connections

This can be monitored through "db2 get snapshot" or via the application described in point 2 above. This could imply that some clients have terminated.

4. Check the db2dump directory for stack traces

This is automated by checking for stack traceback files produced in DB2's db2dump directory. The format of the files is t<pid>.<nodenum>. Some times this would imply a DB2 agent has terminated abnormally and may require further investigation.

5. Check for a panic/s...