Showing posts with label trace. Show all posts
Showing posts with label trace. Show all posts

Tuesday, August 08, 2023

Top 10 Db2 Performance Tips - No. 6 Monitoring and Performance Metrics

Monitoring and measuring performance metrics are essential practices for maintaining and optimizing the performance of an IBM Db2 environment. By regularly monitoring and analyzing performance data, DBAs can identify bottlenecks, proactively address performance issues, and make informed decisions to improve overall system efficiency.

It is important to monitor and measure performance metrics in order to gain insights into the behavior of the applications and databases in use at your site. By examining their behavior and identifying areas for improvement, you can improve the overall satisfaction of your customers and end users. 

Performance metrics provide valuable information about resource utilization, query response times, disk I/O, CPU usage, and other critical aspects of database performance. By tracking these metrics over time, administrators can detect patterns, identify trends, and pinpoint potential performance bottlenecks.

A Strategy

The first part of any Db2 performance management strategy should be to provide a comprehensive approach to the monitoring of the Db2 subsystems operating at your site. This approach involves monitoring not only the threads accessing Db2 and the SQL they issue, but also the Db2 address spaces. You can accomplish this task in three ways:

  • Batch reports run against DB2 trace records. While DB2 is running, you can activate traces that accumulate information, which can be used to monitor both the performance of the DB2 subsystem and the applications being run.
  • Online access to DB2 trace information and DB2 control blocks. This type of monitoring also can provide information on DB2 and its subordinate applications.
  • Sampling DB2 application programs as they run and analyzing which portions of the code use the most resources.
Using all three approaches can be a reasonable approach if you have analyzed the type of workloads in use and which types of monitoring are most effective for each. 
You also need to establish a strategy for your organization's tuning goals. And your tuning goals should be set using the discipline of service level management (SLM). A service level is a measure of operational behavior. SLM ensures applications behave accordingly by applying resources to those applications based on their importance to the organization. Depending on the needs of the organization, SLM can focus on availability, performance, or both. In terms of availability, the service level can be defined as “99.95% up time, during the hours of 9:00 AM to 10:00 PM on weekdays.” Of course, a service level can be more specific, stating “average response time for transactions will be two seconds or less for workloads of strategic external clients.”

For a service level agreement (SLA) to be successful, all of the parties involved must agree upon stated objectives for availability and performance. The end users must be satisfied with the performance of their applications, and the DBAs and technicians must be content with their ability to manage the system to the objectives. Compromise is essential to reach a useful SLA.

Furthermore, the objectives of the SLA must be defined and measurable. For example, in the earlier SLA you must define what a “strategic client” is and differentiate strategic from nonstrategic. Although doing this may be difficult, failing to do so can result in worthless SLAs that cannot be achieved.

In the end, if you do not identify service levels for each transaction, then you will always be managing to an unidentified requirement. Without a predefined and agreed upon SLA, how will the DBA and the end users know whether an application is performing adequately? Without SLAs, business users and DBAs might have different expectations, resulting in unsatisfied business executives and frustrated DBAs. Not a good situation.

Db2 Traces

One of the first types of performance metrics to consider is monitoring based on reading trace information. You can think of a Db2 trace as a window into the performance characteristics of aspects of your Db2 workload. Db2 traces record diagnostic information describing particular events. As Db2 operates, it writes trace information that can be read and analyzed to obtain performance information.

Db2 provides six types of traces, and each describes information about the Db2 environment:

  • Accounting - Records performance information about the execution of DB2 application programs
  • Audit - Provides information about DB2 DDL, security, ­utilities, and data modification
  • Global - Provides information for the servicing of DB2
  • Monitor - Records data useful for online monitoring of the DB2 subsystem and DB2 application programs
  • Performance - Collects detailed data about DB2 events, enabling database and performance analysts to pinpoint the causes of performance problems
  • Statistics - Records information regarding the DB2 subsystem’s use of resources

You can start Db2 traces in two ways: by specifying the appropriate DSNZPARMs at Db2 startup or by using the -START TRACE command to initiate specific traces when Db2 is already running.

Each trace is broken down further into classes, each of which provides information about aspects of that trace. Additional informatiohn about the classes for each type of trace can be found here, here, and here.

You should understand what type of information is traced and the approximate overhead of each trace class before starting any of the Db2 traces. Some traces are better left off until or unless a performance problem is occurring, at which point, the trace can be started to capture details about the situation. Others are better to have turned on before problems occur. Keep in mind that you will have some trace classes (and IFCIDs) that are always started, and other that are only used in emergencies.

What are IFCIDs?

Each trace class is associated with specific trace events known as Instrumentation Facility Component Identifier (IFCIDs), pronounced “if-kid.” An IFCID defines a record that represents a trace event. IFCIDs are the single smallest unit of tracing that can be invoked
by Db2.

In some cases, it can make sense to avoid activating trace classes altogether and start traces specifying only the IFCIDs needed. This way, you can reduce the overhead associated with tracing by recording only the trace events needed. 

There are several hundred different IFCIDs. Most IFCIDs contain data fields that describe events pertinent to the event being traced. Some IFCIDs have no data; instead they merely mark a specific time. Certain trace events of extended durations require a pair of IFCIDs: one for the beginning of the event and another for the end. These pairs enable the computation of elapsed times. Other trace events that are not as lengthy require only a single IFCID. 

You can find the IFCIDs associated with each trace class in the IBM Db2Command Reference manual in the section describing the -START TRACE command. But that manual does not describe the purpose of each IFCID. A list describing each IFCID can be found in the data set named  SDSNIVPD(DSNWMSGS), which is part of the Db2 installation

Db2 Performance Monitors

Several popular performance monitoring solutions are available for Db2 for z/OS. IBM’s Omegamon, BMC Software’s MainView, Broadcom’s Sysview, and Rocket Software's TMON are the leading performance monitors. When selecting a performance monitor, be sure to examine the online components as well as the batch reporting capabilities of the monitor. 

An online performance monitor is a tool that provides real-time reporting on Db2 performance statistics as Db2 operates. In contrast, a batch performance monitor reads previously generated trace records from an input data set. Most performance monitors today can be used to serve both purposes.

With online DB2 performance monitors, you can perform proactive performance management tasks. In other words, you can set up the monitor such that when it detects a problem it alerts a DBA and possibly takes actions on its own to resolve the problem.

The most common way to provide online performance monitoring capabilities is by online access to DB2 trace information in the MONITOR trace class. Some online DB2 performance monitors also provide direct access to Db2 performance data by reading the control blocks of the Db2 and application address spaces. This type of monitoring provides a “window” to up-to-the-minute performance statistics while Db2 runs. This information is important if a quick reaction to performance problems is required.

Most online Db2 performance monitors provide a menu-driven interface accessible from TSO or VTAM. It enables online performance monitors to start and stop traces as needed based on the menu options chosen by the user. Consequently, you can reduce overhead and diminish the learning curve involved in understanding Db2 traces and their correspondence to performance reports.

Following are some typical uses of online performance monitors. Many online performance monitors can establish effective exception-based monitoring. When specified performance thresholds are reached, triggers can offer notification and take action. For example, you could set a trigger when the number of lock suspensions for the TXN00002 plan is reached; when the trigger is activated, a message is sent to the console, and a batch report is generated to provide accounting detail information for the plan. You can set any number of triggers for many thresholds. Following are some examples of thresholds you might choose to set:

  • When a buffer pool threshold is reached (PREFETCH DISABLED, DEFERRED WRITE THRESHOLD, or DM CRITICAL THRESHOLD).
  • For critical transactions, when predefined performance objectives are not met. For example, if TXN00001 requires subsecond response time, set a trigger to notify a DBA when the transaction receives a class 1 accounting elapsed time exceeding 1 second by more than 25%.
  • Many types of thresholds can be established. Most online monitors support this capability. As such, you can customize the thresholds for the needs of your DB2 environment.

Most online performance monitors can produce real-time EXPLAINs for long-running SQL statements. If an SQL statement takes a significant amount of time to process, an analyst can display the SQL statement as it executes and dynamically issue an EXPLAIN for the statement. Even as the statement executes, an understanding of why it takes so long to run can be achieved. A complete discussion of the EXPLAIN statement is provided in the next chapter.

Some online performance monitors provide historical trending. These monitors track performance statistics and store them in DB2 tables or in VSAM files with a timestamp. They also provide the capability to query these stores of performance data to assist in the following:

  • Analyzing recent history. Most SQL statements execute quickly, making difficult the job of capturing and displaying information about the SQL statement as it executes. However, you might not want to wait until the SMF data is available to run a batch report. Quick access to recent past-performance data in these external data stores provides a type of online monitoring that is as close to real time as is usually needed.
  • Determining performance trends, such as a transaction steadily increasing in its CPU consumption or elapsed time.
  • Performing capacity planning based on a snapshot of the recent performance of DB2 applications.
Some monitors also run when Db2 is down to provide access to the historical data accumulated by the monitor.

A final benefit of online DB2 performance monitors is their capability to interface with other z/OS monitors for IMS/TM, CICS, z/OS, or VTAM. This way, an analyst gets a view of the entire spectrum of system performance. Understanding and analyzing the data from each of these monitors, however, requires a different skill. Quite often, one person cannot master all these monitors

Conclusion 

Although this blog entry was brief, and there are many additional aspects to Db2 performance monitoring, monitoring and measuring performance metrics should be viewed as a vital requirement for all organizations using Db2 databases. By collecting and analyzing performance data, DBAs can detect performance bottlenecks, identify areas for improvement, and make informed decisions to enhance overall system efficiency. 


Friday, June 15, 2018

Db2 for z/OS Performance Traces Part 3 - Trace Destinations and IFCIDs


In parts 1 and 2 of this series we examined each of the six types of Db2 traces that you can start to get Db2 to record information about its activities. Be sure to check out those earlier blog posts to learn about what is available. 

Today we are going to look at a couple of additional details with regard to Db2 traces, starting with where the trace records can be written.

Trace Destinations

When a trace is started, Db2 formats records containing the requested information. After the information is prepared, it must be externalized somewhere. Db2 traces can be written to six destinations:

  • GTF, or Generalized Trace Facility, is a component of z/OS and is used for storing large volumes of trace data.
  • SMF , or System Management Facility, a source of data collection used by MVS to accumulate information and measurements. This destination is the most common for DB2 traces.
  • SRV is a routine used primarily by IBM support personnel for servicing Db2.
  • OPn, where n is a value from 1 to 8, is an output buffer area used by the Db2 Instrumentation Facility Interface (IFI).
  • OPX is a generic output buffer. When used as a destination, OPX signals Db2 to assign the next available OPn buffer (OP1 to OP8).
The Instrumentation Facility Interface, which is a DB2 trace interface, enables Db2 programs to read, write, and create Db2 trace records and issue Db2 commands. Many online Db2 performance monitors are based on the IFI.

But which trace destination should you use? Well, it depends! Consult Table 1 below for a synopsis of the available and recommended destinations for each Db2 trace type. A "Y" indicates that the specified trace destination is valid for the given type of trace; Default indicates that it is the default destination for that trace type.



Note: you can click on the Table to expand its size for easier viewing.

If you use SMF as your Db2 trace destination, consider using the SMFCOMP system parameter (DSNZPARM), which was introduced in Db2 10. This parameter causes the compression of Db2 trace records written to SMF. When SMFCOMP is set ON, the z/OS compression service CSRCESRV is used to compress any Db2 trace records written to SMF.

Use this parameter if your shop is concerned about the volume of SMF records written by Db2.

Using IFCIDs

Sometimes a trace class can be too broad, by which I mean that it generates more information than you need for the probelm at hand. This brings us to the IFCID.

Each trace class is associated with specific trace events known as Instrumentation Facility Component Identifier (IFCIDs), pronounced “if-kid.” An IFCID defines a record that represents a trace event. IFCIDs are the single smallest unit of tracing that can be invoked
by Db2.

In some cases, it can make sense to avoid activating trace classes altogether and start traces specifying only the IFCIDs needed. This way, you can reduce the overhead associated with tracing by recording only the trace events needed.

You can use trace classes 30 through 32 for starting IFCID-only traces. These classes have no predefined IFCIDs and are available for a location to use. Consider the following -START TRACE command, which starts only IFCIDs 1, 2, 42, 43, 107, and 153:

-START TRACE(PERFM) DEST(GTF) CLASS(30) IFCID(1,2,42,43,107,153)

If you do not specify the IFCID option, only those IFCIDs contained in the activated trace classes are started. The maximum number of IFCIDs per trace is 156.

Because this task can be tedious, if you decide to trace only at the IFCID level, it is probably a good idea to use a performance monitor that starts these IFCID-level traces based on menu choices. For example, if you choose to trace the elapsed time of Db2 utility jobs, the monitor or tool would have a menu option for this, initiating the correct IFCID traces (for example, IFCIDs 023 through 025).

There are several hundred different IFCIDs. Most IFCIDs contain data fields that describe events pertinent to the event being traced. Some IFCIDs have no data; instead they merely mark a specific time. For example, IFCID 074, which marks the beginning of Terminate Thread, has no data field.

Certain trace events of extended durations require a pair of IFCIDs: one for the beginning of the event and another for the end. These pairs enable the computation of elapsed times. Other trace events that are not as lengthy require only a single IFCID. 

You can find the IFCIDs associated with each trace class in the IBM DB2 Command Reference in the section describing the -START TRACE command. But that manual does not describe the purpose of each IFCID. A list describing each IFCID can be found in the SDSNIVPD(DSNWMSGS) data set. It also contains DDL and LOAD utility statements that can be used to create DB2 tables containing IFCID information that can be easily queried by SQL.

For example, the following query retrieves field descriptions for performance trace records for particular classes:

SELECT DISTINCT NAME, CLASS, DESCRIPTION, A.IFCID, SEQ
FROM   ownerid.TRACE_DESCRIPTIONS  A,
       ownerid.TRACE_TYPES         B
WHERE  A.IFCID = B.IFCID
AND    TYPE =
'PERFORMANCE'
AND    CLASS IN (1,2,3,4,5,6,7)
ORDER BY SEQ;

You can modify the query as needed to retrieve only the specific IFCID information you need.

Synopsis


This series of blog posts has offered up a high-level introduction to Db2 tracing and what type of information is available using traces. A comprehensive strategy for monitoring the performance of your Db2 subsystems and applications is an important part of establishing a best practices approach to database performance management. Use this information to help you on your journey to an efficiently monitored Db2 for z/OS environment.


Of course, this information is just the beginning. Keep checking back on this blog for additional useful information, and/or make sure you have a copy of my book, Db2 Developer's Guide, which contains over 1,600 pages of Db2 guidance and advice.


Wednesday, June 13, 2018

Db2 for z/OS Performance Traces Part 2 - Global, Monitor, Performance, and Statistics

In Part 1 of the series on Db2 performance traces we provided a general overview, as well as a discussion of the Accounting and Audit trace classes. Today, in Part 2, we will discuss the remaining 4 trace classes: Global, Monitor, Performance, and Statistics.

Global Trace


The global trace is one I hope you never have to use. It produces information that is used to service Db2, so you'd only start a global trace at the direction of IBM if you are having some sort of trouble. A global trace records information regarding entries and exits from internal Db2 modules as well as other information about Db2 internals. 

Global trace records are not accessible through normal tools that monitor Db2 performance. Most sites will never need to use the DB2 global trace. You should avoid it unless an IBM representative requests that your shop initiate it.

A global trace can add significant CPU overhead to your Db2 subsystem.

Monitor Trace

Quite a bit of useful performance monitoring information is recorded by the Db2 monitor trace. Most of the information in a monitor trace is also provided by other types of Db2 traces. The primary reason for the existence of the monitor trace type is to enable you to write application programs that provide online monitoring of Db2 performance.

Information provided by the monitor trace includes Db2 statistics and accounting trace information, as well as details of current SQL statements.

There are ten groups of DB2 monitor trace classes:
  • Class 1: Standard accounting data
  • Class 2: Entry or exit from DB2 events
  • Class 3: DB2 wait for I/O or locks
  • Class 4: Installation-defined monitor trace record
  • Class 5: Time spent processing IFI requests
  • Class 6: Changes to tables created with DATA CAPTURE CHANGES
  • Class 7: Entry or exit from event signaling package accounting
  • Class 8: Wait time for a package
  • Class 9: Statement level accounting
  • Class 10: Package detail
  • Class 11 through 28: Reserved
  • Class 29: Dynamic statement detail
  • Class 30 through 32: Local use

The overhead that results from the monitor trace depends on how it is used at your site. If it is used as recommended, class 1 is always active with 2 and 3 started and stopped as required, the overhead will likely be minimal but will depend on the activity of the Db2 system and the number of times that the other classes are started and stopped. If you make use of the reserved classes (30 through 32), or additional classes (as some vendors do), your site will incur additional overhead.

Do not start the monitor trace using DSNZPARMs unless online performance monitors in your shop explicitly require you to do so. It is best to start only monitor trace class 1 and to use a performance monitor that starts and stops the other monitor trace classes as required.

Some online performance monitoring tools do not use the monitor trace; instead, they read the information directly from the Db2 control blocks. Sampling Db2 control blocks requires less overhead than a monitor trace but it can be disruptive if the tools encounters bugs.

Performance Trace


The Db2 performance trace records an abundance of information about all types of Db2 events. You should use it only after you have exhausted all other avenues of monitoring and tuning because it consumes a great deal of system resources. When a difficult problem persists, the performance trace can provide valuable information, including SQL statement text, a complete trace of the execution of SQL statements, including details of all events, all index accesses and all data access due to referential constraints.

There are 22 groups of Db2 performance trace classes:
  • Class 1: Background events
  • Class 2: Subsystem events
  • Class 3: SQL events
  • Class 4: Reads to and writes from buffer pools and the EDM pool
  • Class 5: Writes to log or archive log
  • Class 6: Summary lock information
  • Class 7: Detailed lock information
  • Class 8: Data scanning detail
  • Class 9: Sort detail
  • Class 10: Detail on BIND, commands, and utilities
  • Class 11: Execution unit switch and latch contentions
  • Class 12: Storage manager
  • Class 13: Edit and validation exits
  • Class 14: Entry from, and exit to an application
  • Class 15: Installation-defined performance trace record
  • Class 16: Distributed processing
  • Class 17: Claim and drain information
  • Class 18: Event-based console messages
  • Class 19: Data set open and close activity
  • Class 20: Data sharing coherency summary
  • Class 21: Data sharing coherency detail
  • Class 22: Authorization exit parameters
  • Class 23 through 29: Reserved
  • Class 30 through 32: Local use

When all Db2 performance trace classes are active, you will experience significant overhead, perhaps as much as 100% CPU overhead by each program being traced. The actual overhead might be greater (or lesser) depending on actual system activity. The ­overhead when using only classes 1, 2, and 3, however, typically ranges between 5% and 30%.

Performance traces must be explicitly started with the -START TRACE command. Starting the performance trace only for the plan (or plans) you want to monitor by using the PLAN parameter of the -START TRACE command is wise. Here’s an example:

-START TRACE(PERFM) CLASS(1,2,3) PLAN(PLANNAME) DEST(GTF)

Failure to start the trace at the plan level can result in the trace being started for all plans, which causes undue overhead on all DB2 plans that execute while the trace is active.

Furthermore, due to the large number of trace records cut by the Db2 performance trace, system-wide (Db2 and non-Db2) performance might suffer because of possible SMF or GTF contention. 


Statistics Trace

The final type of Db2 trace is the statistics trace, which contains information pertaining to the entire Db2 subsystem. This type of information is particularly useful for measuring the activity and response of Db2 as a whole. Information on the utilization and status of the buffer pools, DB2 locking, DB2 logging, and DB2 storage is accumulated by the statistics trace.

There are ten groups of DB2 statistics trace classes:
  • Class 1: Statistics data
  • Class 2: Installation-defined statistics record
  • Class 3: Data on deadlocks, lock escalation, group buffers, data set extension, long-running units of recovery, and active log shortage
  • Class 4: Exceptional conditions
  • Class 5: Data sharing statistics
  • Class 6: Storage usage
  • Class 7: DRDA location statistics
  • Class 8: Data set I/O
  • Class 9 through 29: Reserved
  • Class 30 through 32: Local use

The estimated overhead of the statistics trace is low. Approximately 1% to 2% CPU overhead per transaction is incurred by the Statistics trace.

Db2 cuts a statistics trace record periodically based on the setting of the STATIME subsystem parameter (DSNZPARM). STATIME is specified as a time interval, in minutes, and can range from 1 to 60 minutes. It is a good practice to set STATIME to 1, thereby specifying 1,440 statistics intervals per day. The information accumulated by cutting these statistics trace records can provide valuable details for solving complex system problem. 
By analyzing the evolutional trend of statistics, sometimes the cause of problems can become evident that would otherwise be difficult to track down. 


Even though 1,440 records sound large, in reality the amount of data collected is small when compared to the typical volume of accounting trace data collected. An additional thousand or so SMF records should not cause any problems, while at the same time offering valuable system information.

Next time...

This concludes the overview of the types of Db2 tracing that are available. In part 3, we will examine where trace records can be written as well as more narrow tracing using IFCIDs.


Friday, June 08, 2018

Db2 for z/OS Performance Traces Part 1 - Intro, Accounting, and Audit

When it comes to Db2 for z/OS performance management, one of the first things you need to understand is the traces that are available that must be started in order to cause Db2 to track performance metrics. You can think of a Db2 trace as a window into the performance characteristics of aspects of your workload. Db2 traces record diagnostic information describing specific performance events. As Db2 operates, and workload is run against it, Db2 writes trace information based on the traces types that have been started. The information is written out in such a way that it can be read and analyzed by DBAs and performance analysts.

There are six types of Db2 traces available, each one pertaining to a different category of Db2 performance and operations. These six types of traces are:


  • Accounting - performance information about the execution of DB2 application programs 
  • Audit - information about Db2 DDL, security, ­utilities, and data modification activities
  • Global - information for servicing Db2 
  • Monitor - data useful for online monitoring of the Db2 subsystem and application programs 
  • Performance - detailed data about Db2 events, enabling database and performance analysts to pinpoint the causes of performance problems 
  • Statistics - information regarding the Db2 subsystem’s use of resources 

There are two ways to start most Db2 traces: you can specify the appropriate DSNZPARMs to start traces when Db2 starts up or you can issue the -START TRACE command to initiate specific traces when Db2 is already running. 

Each trace is broken down further into classes, each of which provides information about aspects of that trace. 

Accounting Trace


The accounting trace is one of the most important traces for judging the performance of Db2 application programs. Accounting trace records can contain information regarding:
  • CPU and elapsed time of the program
  • Usage of the EDM pools
  • Locks and GETPAGE page requests, by buffer pool, issued by the program
  • Number of synchronous writes
  • Thread wait times
  • Type of SQL issued by the program
  • Number of COMMITs and ABORTs issued by the program
  • Program’s use of sequential prefetch and other DB2 performance features (RLF, distributed processing, and so on)

There are ten groups, or classes, of Db2 accounting traces:
  • Class 1: Standard accounting information
  • Class 2: Entry or exit from DB2 events
  • Class 3: Elapsed wait time in DB2
  • Class 4: Installation-defined accounting record
  • Class 5: Time spent processing IFI requests
  • Class 6: Reserved
  • Class 7: Entry or exit from event signaling package accounting
  • Class 8: Wait time for a package
  • Class 10: Package detail
  • Class 11 through 28: Reserved
  • Class 30 through 32: Local use

Most organizations start Db2 accounting classes 1, 2, and 3 together because they provide a great deal of information with only a low overhead. Furthermore, you cannot run class 2 or 3 without also running class 1.

Accounting trace classes 7 and 8 provide performance trace information at the package level. For class 7 accounting, trace information is gathered for packages executed, and for class 8 information, the amount of time an agent was suspended in Db2 for each executed package is collected. If you have already activated accounting trace classes 2 and 3, adding trace classes 7 and 8 incurs only a minimal additional cost.

Audit Trace

The audit trace is useful for installations that must meticulously track specific types of Db2 events, particularly to support regulatory and compliance requirements. Not every shop needs the audit trace. However, those wanting to audit by AUTHID, specific table accesses, and other Db2 events mayfind the audit trace invaluable. 

Of course, as of Db2 10 for z/OS, an alternate approach to auditing with audit policies is available. This requires use of SECADM, which is not pervasively implemented, though.

There are eight categories of audit information that can be provided using the audit trace:
  • All instances in which an authorization failure occurs, for example, if USER1 attempts to SELECT information from a table for which he or she has not been granted the appropriate authority
  • All executions of the DB2 data control language GRANT and REVOKE statements
  • Every DDL statement issued for specific tables created by specifying AUDIT CHANGES or AUDIT ALL
  • The first DELETE, INSERT, or UPDATE for an audited table
  • The first SELECT for only the tables created specifying AUDIT ALL
  • DML statements encountered by DB2 when binding
  • All AUTHID changes resulting from execution of the SET CURRENT SQLID statement
  • All execution of IBM DB2 utilities

Again, there are groups, or classes of trace information that can be started. In the case of the audit trace, there are eleven trace classes:
  • Class 1: Attempted access denied due to lack of authority
  • Class 2: GRANT and REVOKE 
  • Class 3: CREATE, ALTER, and DROP statements against audited tables
  • Class 4: First change made to an audited object
  • Class 5: First read made against an audited object
  • Class 6: BIND information for SQL statements on audited objects
  • Class 7: Assignment or change of an AUTHID
  • Class 8: Utility execution
  • Class 9: Installation-defined audit trace record
  • Class 10: Trusted Context information
  • Class 11: Audit administrative authorities
  • Class 12 through 29: Reserved
  • Class 30 through 32: Local use

The overhead of the audit trace depends greatly on the amount of data that is being audited. Things like transaction frequency, modification frequency, DDL activity, and so on will dictate the actual amount of overhead required.

Next Time...

So far, we have only looked at two of the six types of Db2 traces. Be sure to check back later for Parts 2 and 3 of this blog series that will introduce the remaining types of traces and additional useful information on dealing with Db2 performance tracing.

Tuesday, October 15, 2013

Using the DISPLAY Command, Part 5

Today’s entry in our series on the DB2 DISPLAY command is the fifth – and final – edition of the series.  We’ll wrap up coverage by briefly discussing the remaining features of DISPLAY. And, just as a reminder:
  • Part 1 of this series focused on using DISPLAY to monitor details about you database objects; 
  • Part 2 focused on using DISPLAY to monitor your DB2 buffer pools;
  • Part 3 covered utility execution and log information;
  • And Part 4 examined using the DISPLAY command to monitor DB2 stored procedures and user-defined functions.


Additional Information that DISPLAY Can Uncover

Distributed Information

The DISPLAY command can be quite useful in distributed DB2 environments. You can use DISPLAY DDF to show DDF configuration and status information, as well as statistical details on distributed connections and threads.  An example of the output from issuing DISPLAY DDF:

DSNL081I STATUS=STOPDQ
DSNL082I LOCATION LUNAME GENERICLU
DSNL083I STLEC1 -NONE.SYEC1DB2 -NONE
DSNL084I TCPPORT=446 SECPORT=0 RESPORT=5001 IPNAME=-NONE
DSNL085I IPADDR=NONE
DSNL086I SQL DOMAIN=-NONE
DSNL090I DT=A CONDBAT= 64 MDBAT= 64
DSNL092I ADBAT= 0 QUEDBAT= 0 INADBAT= 0 CONQUED= 0
DSNL093I DSCDBAT= 0 INACONN= 0
DSNL105I DSNLTDDF CURRENT DDF OPTIONS ARE:
DSNL106I PKGREL = COMMIT
DSNL099I DSNLTDDF DISPLAY DDF REPORT COMPLETE

Additionally, DISPLAY LOCATION can be used to show information about distributed threads.

Data Sharing Information

For data sharing, the DISPLAY GROUP command can be used to display information about the data sharing group (including the version of DB2 for each member); and DISPLAY GROUPBUFFERPOOL can be used to show information about the status of DB2 group buffer pools.

Profile Information

If you have started using PROFILEs in DB2 10 (or later), the DISPLAY PROFILE command allows you to determine if profiling is active or inactive. The status codes that can be returned by this command are as follows:
  •         ON Profiling is active.
  •         OFF Profiling is inactive.
  •         SUSPENDED Profiling was active, but is now suspended due to error conditions.
  •         STARTING Profiling is being started, but has not completed.
  •         STOPPING Profiling has been stopped, but has not completed.


Resource Limit Information

If you use the Resource Limit Facility, the DISPLAY RLIMIT command can be used to show the status of the RLF, including the ID of the active RLST (Resource Limit Specification Table).

Thread Information

To display information about a DB2 thread connection or all connections, use the DISPLAY THREAD command. A DB2 thread can be an allied thread, a database access thread, or a parallel task thread. Threads can be active, inactive, indoubt, or postponed.

There are a number of options for displaying thread information, and you can narrow or expand the type and amount of information you wish to retrieve based on:
  •          Active threads, inactive threads, indoubt threads, postponed threads, procedure threads, system threads, or the set of active, indoubt, postponed, and system threads (see the descriptions under the TYPE option for more information)
  •          Allied threads, including those threads that are associated with the address spaces whose connection names are specified
  •          Distributed threads, including those threads that are associated with a specific remote location
  •          Detailed information about connections with remote locations
  •          A specific logical unit of work ID (LUWID)


Tracing Information

And finally, the DISPLAY TRACE command can be used to list your active trace types and classes along with the specified destinations for each. 

Summary

The DB2 DISPLAY command is indeed a powerful, yet simple tool that can be used to gather a wide variety of details about your DB2 subsystems and databases. Every DBA should know how to use DISPLAY and its many options to simplify their day-to-day duties and job tasks.