An accounting report reads the SMF accounting records to produce the thread or application level information from the accounting trace. These reports typically can summarize information at the level of a plan, package, correlation ID, authorization ID, and so on. In addition, you can also produce one report per thread. This accounting detail report can provide detailed performance information for the execution of a specific application process. If you have accounting classes 1, 2, 3, 7, and 8 turned on, the information will be reported at the plan and the package level.
You can use the accounting report to find specific problems within certain applications, programs, or threads.
Indicates the entire application time, including the time that is spent within DB2. Class 2 is a component of class 1, and represents the amount of time the application spent in DB2. The first question to ask when an application is experiencing a performance problem is, "Where is the time being spent?" The first indication that the performance issue is with DB2 will be a high class 2 time relative to the class 1 time. Within class 2, you could be having a CPU issue (CPU time represents most of the class 2 time), or a wait issue (CPU represents little of the overall class 2 time, but class 3 wait represents most of the time), or maybe your entire system is CPU bound (Class 2 overall elapsed is not reflected in class 2 CPU and class 3 wait time combined).
Displays information about buffer usage at the thread level. This information can be used to determine how a specific application or process is using the buffer pools. If you have situations in which certain buffers have high random getpage counts, look at which applications are causing the high number of random getpages. You can use this thread level information to determine which applications are accessing buffers randomly versus sequentially. Perhaps then you can see which objects the application uses, and can use this information to separate sequentially accessed objects from randomly accessed objects into different buffer pools. The buffer pool information in the accounting report also indicates how well the application is using the buffers. The report can be used during buffer pool tuning to determine the impact of buffer changes on an application.
Displays information about the DB2 processing on a package level, if accounting classes 7 and 8 are turned on. This information is important for performance tuning because it lets you determine which programs in a poorly performing application should be reviewed first.
Indicates the number of deadlocks and timeouts that occurred on a thread level. It also reports the time that the thread spent waiting on locks. This information lets you know whether you have to do additional investigation into applications that are having locking issues.
Indicates if there are many excessive random synchronous I/Os being issued, and how much time the application spends waiting on I/O, if you have a slow running job or online process. The report also indicates exactly what is slow about that job or process. The information in the report can also be used to approximately determine the efficiency of your DASD by simply dividing the number of synchronous I/O's into the total synchronous I/O wait time.
Displays thread level RID pool failure information. This information provides important details to help you determine if you have access path problems in a specific application.
Indicates if your performance problem is related to an inefficient repeat process. If the report shows a high getpage count, or that most of the elapsed time is actually class 2 CPU time, you may have an inefficient repeat process in one of the programs for the plan. Often it is hard to determine if an application is doing repeat processing when there are not many I/Os being issued, so you can use the package level information to determine which program uses the most CPU and you can try to identify any inefficiencies in that program.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|