Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what are the knowledge points of db2 event monitor type". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

You can use the event monitor to capture information related to many different types of events that occur on the system.

The following table lists the types of the following events that occur in the system, which you can monitor using event Monitor. It also describes the type of data collected for different events and the time at which monitoring data is collected. The name of the event monitor shown in the second column corresponds to the keyword used to create this type of event monitor using the CREATE EVENT MONITOR statement.

Table 1. Event type event monitor name event monitor property details locking and deadlock LOCKING the purpose of this event monitor is to determine when a lock or deadlock occurs and the application involved. The advantages of using the LOCKING event monitor instead of the recommended DEADLOCKS event monitor include integrating reported locking and deadlock events and containing information about lock waits and lock timeouts. The collected data contains comprehensive information about the application involved, including the identity of the participating statement (and the statement text) and a list of locks to be suspended. Time 1 when generating event data detects any of the following event types, depending on how you configure the event monitor:

Lock timeout

Deadlock

Lock wait for more than the specified duration

Execute SQL statements or other operations that derive database activities. ACTIVITIES the purpose of this event monitor is to track the execution of individual statements and other activities to see which activities are running in the system. It can also be used to capture activities and study the resource consumption of SQL for diagnostics. Data activity level data collected, usually corresponding to activities involving workload management objects.

If you specify WITH DETAILS as part of the COLLECT ACTIVITY DATA clause of a CREATE or ALTER statement against a workload management object, the collected information includes the statement and compilation environment information with the activity of the object. If WITH SECTION is also specified, statements, compilation environment, fragment environment data, and fragment reality are also captured.

If AND VALUES is also specified on the CREATE or ALTER statement for the workload management object, the information collected will also include the input data value for the activity with that object.

Time to generate event data 1

When an activity performed in a service class, workload, or work class that has the COLLECT ACTIVITY DATA option enabled is completed.

When an activity with the COLLECT ACTIVITY DATA option enabled violates the threshold.

When executing a WLM_CAPTURE_ACTIVITY_IN_PROGRESS stored procedure.

When performing an activity on a connection for which activity collection is enabled using the WLM_SET_CONN_ENV stored procedure.

STATEMENTS execution of SQL statements the purpose of this event monitor is to see what requests are made to the database because of the execution of the SQL statement. The start or stop time of the collected data statement, the CPU used, the text of the dynamic SQL, SQLCA (the return code of the SQL statement), and other measures, such as the memory access count. For partitioned databases: CPU used, execution time, table and table queue information.

Note:

Events are generated when you use the statement event monitor, data manipulation language (DML) statements (for example, INSERT, SELECT, DELETE, and UPDATE) to monitor the execution of SQL procedures. Procedural statements, such as variable assignments and control structures (for example, WHILE or IF), do not generate events in a deterministic manner.

When the timestamp switch is set to OFF, the statement start or stop time is not available.

The end of the SQL statement 2 when the event data was generated; for partitioned databases, the end 2 unit of work (transaction) of the sub-section completes the UNIT OF WORK the purpose of this event monitor is to collect resource usage information and performance metrics for units of work running on the system. This information can be used for everything from generating reports for payment or refund purposes of system resources used by applications to diagnosing performance problems caused by slow-running routines.

Recommendations for the TRANSACTIONS event monitor.

The data collected is information about units of work (transactions), such as start and stop times, and the workloads and service classes that run these units of work. Used to include information about packages or executable identities for statements run in a unit of work, as well as options for requesting metrics. Time 1 to generate event data remove fragments PACKAGE CACHE from the package cache after the unit of work is completed the purpose of this event monitor is to capture the history of statements (and related metrics) that are no longer in the package cache. You can use this information if you need to check the performance metrics of statements that are no longer available in memory. The collected data includes statement text and measures for all execution aggregations for the fragment. Time 1 to generate event data because entries were removed from the package cache. Connection established by the application to the database CONNECTIONS the purpose of this event monitor is to capture metrics and other monitoring elements for each connection established by the application to the database. All application-level counters for collected data. For example, the time an application is connected to or disconnected from the database, or the number of lock upgrades involving the application. End of time connection to generate event data 2 deactivate database DATABASE the purpose of this event monitor is to capture the following metrics and other monitoring elements that reflect information about the entire database after activation. All database-level counters for collected data. For example, the number of connections established with the database since activation, the time spent waiting for a lock, or the number of rows of data inserted. The time database that generated the event data deactivated 2BUFFERPOOLS

TABLESPACES the purpose of this event monitor is to capture data buffer pools, prefetchers, page cleaners, and counters for direct Imax O of metrics collected related to buffer pools and tablespaces. The time database that generated the event data deactivated 2TABLES the purpose of this event monitor is to capture measures related to tables that change after the database is activated. Data table level counters collected, such as the number of rows read or written, or the number of disk pages used by data, LOB, or index objects. The time database that generated the event data deactivates 2 Statistics and measures about workload management objects STATISTICS the purpose of this event monitor is to capture processing metrics related to workload management objects in the database, such as service superclasses or workloads. For example, you can use a statistics event monitor to check the CPU utilization of a given workload over time. The collected data is statistics calculated from activities performed within each service class, workload, or work class in the system. Statistics can be automatically collected at regular intervals when event data is generated. This interval is defined using the wlm_collect_int database configuration parameter.

You can also use WLM_COLLECT_STATS stored procedures to collect data manually.

Note: through any collection mechanism, the value of the statistics monitoring element is reset to 0 after collection occurs.

Workload Manager threshold exceeded THRESHOLD VIOLATIONS the purpose of this event monitor is to determine when the specific threshold you set is exceeded during database operations. You can set thresholds for a variety of objects, ranging from CPU time to the number of database connections to the execution of specific statements. The collected data can be used for a variety of purposes, including monitoring potential problems (for example, reaching limits on temporary tablespaces). Collected data threshold violation information. When a threshold violation is detected at the time the event data is generated. The threshold is defined using the CREATE THRESHOLD statement. Changes to database or database manager configuration CHANGE HISTORY the purpose of this event monitor captures changes to database and database manager configuration, changes to registry settings, execution of DDL statements and execution of utilities data collected changes in database configuration parameters and database manager configuration parameters, registry variable changes, execution of DDL statements, The execution of some DB2 ®utilities and commands and the change history event monitor start.

Note: in general, information about events that occur when the change history event monitor is inactive or the database is offline is not captured. However, changes to registry variables and configuration parameters are recorded.

Time at which event data was generated 1 the time a parameter or variable changed or the completion time of a command, DDL, or utility during the startup of the monitor.

Note:

If the database is deactivated while the activity event monitor is active, the backlog of activity records in the queue is discarded. To ensure that you get all activity event monitor records and that there are no obsolete records, deactivate the activity event monitor before deactivating the database. When the activity event monitor is explicitly deactivated, all backlog activity records in the queue are processed before the event monitor is deactivated.

In addition to the defined time when data collection occurs automatically, you can use FLUSH EVENT MONITOR SQL statements to generate events. Events generated by this method are written using the current database monitor values for all monitor types except DEADLOCKS and DEADLOCKS WITH DETAILS, which are associated with emptied event monitors.

Table 2. Event type of event monitor deprecated event monitor type event monitor name event monitor property details deadlock DEADLOCKS2 the purpose of this event monitor is to determine when deadlocks occur and the applications involved. The collected data involves the application and locks in the contention state. Time deadlock detection DEADLOCKS WITH DETAILS2 when event data was generated the purpose of this event monitor is to determine when the deadlock occurred and the applications involved. The collected data contains comprehensive information about the application involved, including the identity of the participating statement (and the statement text) and a list of locks to be suspended. If you use the DEADLOCKS WITH DETAILS event monitor instead of the DEADLOCKS event monitor, it can cause performance degradation when deadlocks occur because other information is collected. Time deadlock detection DEADLOCKS WITH DETAILS HISTORY2 when event data was generated the purpose of this event monitor is to determine when the deadlock occurred and the applications involved. Collected data all the information reported in the DEADLOCKS WITH DETAILS event monitor and the statement history of the current unit of work for each application that has locks that participate in the deadlock scheme of the database partition that is pending. If you use the DEADLOCKS WITH DETAILS HISTORY event monitor, it results in a slight performance degradation at activation because of the statement history trace. Time deadlock detection DEADLOCKS WITH DETAILS HISTORY VALUES2 for generating event data the purpose of this event monitor

All the information reported in the deadlock history of the collected data with detailed information, as well as the values provided for all parameter markers when the statement is executed. If you use the DEADLOCKS WITH DETAILS HISTORY VALUES event monitor, it can result in a significant performance degradation at activation because of additional replication of data values. The time deadlock detection work unit (transaction) that generates event data completes the purpose of TRANSACTIONS3 this event monitor

Collected data UOW work start or stop time, previous UOW time, consumed CPU, and lock and record metrics. If you run using XA, no transaction records are generated. When the time unit of work for generating event data is completed

Note:

In addition to the defined time when data collection occurs automatically, you can use FLUSH EVENT MONITOR SQL statements to generate events. Events generated by this method are written using the current database monitor values for all monitor types except DEADLOCKS and DEADLOCKS WITH DETAILS, which are associated with emptied event monitors.

It is not recommended to use this event monitor. It is recommended that you no longer use this option, as it may be removed by future releases. Use CREATE EVENT MONITOR FOR LOCKING statements to monitor lock-related events, such as lock timeouts, lock waits, and deadlocks.

It is not recommended to use this event monitor. It is recommended that you no longer use this option, as it may be removed by future releases. Use the CREATE EVENT MONITOR FOR UNIT OF WORK statement to monitor transaction events.

Note: a detailed deadlock event monitor will be created for each newly created database. This event monitor, called DB2DETAILDEADLOCK, starts when the database is activated and is written to a file in the database directory. You can avoid the additional processor time it requires by deleting this event monitor. It is not recommended to use the DB2DETAILDEADLOCK event monitor. It is recommended that you no longer use this option, as it may be removed by future releases. Use CREATE EVENT MONITOR FOR LOCKING statements to monitor lock-related events, such as lock timeouts, lock waits, and deadlocks.

The output of a file or pipe event monitor is a logical data packet binary stream. You can use the db2evmon command to format this data stream from the command line. This efficient tool reads event records from the file or pipe of the event monitor and then writes them to the screen (standard output).

Before we begin

No permissions are required unless you connect to the database, and if you connect to the database, you need to have one of the following permissions:

SYSADM

SYSCTRL

SYSMAINT

DBADM

About this task

You can indicate the event monitor output that you want to format by providing the path to the event file or by providing the database name and event monitor name.

Process

To format the event monitor output:

Specify the directory that contains the event monitor files:

Db2evmon-path'/ tmp/dlevents'

/ tmp/dlevents indicates (UNIX) the path.

Specify the database and event monitor name:

Db2evmon-db 'sample'-evm' dlmon'

Sample represents the database to which the event monitor belongs.

Dlmon stands for event monitor.

This is the end of the content of "what are the knowledge points of db2 event monitor type". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.