SNAPSHOTS: NOTE: it will records all the changes which was taken in the movement.

DB2 snapshots are point-in-time views into what DB2 is doing and how it is performing. They are used in the performance tuning of instances, databases, and applications running on DB2. The information returned from a snapshot is a combination of cumulative information and data that applies only to a single moment. Each type of snapshot captures a different set of data about DB2. Database Table space Tables Buffer pools Locks Database Manager Applications Snapshot can be taken at two levels : 1 Instance level 2) application level

Method 1:Setting monitor switches at the instance level: Here are the monitor switches DFT_MON_STMT: Statement monitor (used for dynamic SQL) DFT_MON_TABLE: Table monitors DFT_MON_LOCK: Lock monitor DFT_MON_BUFPOOL: Buffer pool monitors DFT_MON_SORT: Sort monitoring DFT_MON_UOW: Unit of work information DFT_MON_TIMESTAMP: Tracks timestamp information

Data Returned by the Snapshot Monitor

Group Information Provided Monitor Switch SORT DBM Parameter

Sorts

Number of heaps used, overflows, sorts performance

DFT_MON_SORT

Locks

Number of locks held, number LOCK of deadlocks Measure activity (rows read, rows written) Number of reads and writes, time taken Start times, end times, completion status Start time, stop time, statement identification TABLE

DFT_MON_LOCK

Tables

DFT_MON_TABLE

Buffer pools

BUFFERPOOL

DFT_MON_BUFPOOL

Unit of work

UOW

DFT_MON_UOW

SQL statements

STATEMENT

DFT_MON_STMT

Data Returned by the Snapshot Monitor

Group Information Provided Monitor Switch TIMESTAMP DBM Parameter

Timestamp

Timestamps for operations

DFT_MON_TIMESTAMP

Method 2: Setting the monitor switches at an application level Here are the switch names: Bufferpool Lock Sort Statement Table Timestamp UOW Use this command to list the switches: db2 get monitor switches And use this command to set the switches: db2 update monitor switches using switchName [ON | OFF]

Levels for Taking Monitoring Snapshots

Level Application Buffer Pool Database Database Manager (Instance) Dynamic SQL Information Captured Applications. Buffer pool activity. Databases. For an active instance.

Point-in-time statement from the SQL statement cache for the database. For locks held by applications against a database. For tables within a database. For table spaces within a database.

Lock Table Table Space

TO DO PRACTICALLY: ==> db2start ==> db2 connect to databasename (ex: sample) To see on which the Snapshot can be applied or taken ==> db2 get monitor switches TO TAKE SNAPSHOT ON BUFFER POOLS: ==> db2 get snapshot for all bufferpolls ==> db2 get dbm cfg ( to see the parameters) TO ON OR OFF THE BUFFERPOOL: INSTANCE LEVEL ==> db2 update dbm cfg using DFT_MON_BUFPOOL ON|OFF note: after ON, stop and start the database. ==> db2stop ==> db2start NOTE: before taking the snapshot connect to database and create the table and insert the values into it. ==> db2 connect to databaseName ( ex: sample) ==> db2 create table test1( sno integer, sname varchar(12)) ==> db2 insert into test1 values(101,'naidu'),(102,'kumar'),(103,'sumanth') TO SEE THE CHANGES IN THE BUFFERPOLLS: ==> db2 get snapshot for all bufferpolls (you can find the changes in it.) TO GET SNAPSHOT ON OTHERS: ==> db2 get snapshot for locks on sample(databasename) ==> db2 get snapshot for tables on sample APPLICATION LEVEL: db2 get monitor switches TO ON : ==> db2 update monitor switches using tables ON|OFF

NOTE: after the table ON, stop and start the database or close terminal. SYN:==> db2 update monitor switches using switchname ON|OFF RESETING THE SWITCHES: The monitor switches can be reset to null or 0 for all values by executing the following commands. ==> db2 reset monitor [ALL | FOR Database DatabaseName] [At dbPartationNum Partition Num] ==> where databaseName is the name of the database and partitionNum is the Node number. EX: ==> db2 reset monitor for database drew_db DATABASE MANAGER SNAPSHOT: ==> db2 get snapshot for database manager TABLE STATEMENT: ==> db2 get snapshot for tables on sample TABLESPACE AND BUFFERPOOLS: ==> db2 get snapshot for tablespaces on sample ==> db2 get snapshot for buffer pools on sample DATABASE SNAPSHOT: ==> db2 get snapshot for database on databaseName. RESETTING THE SWITCHES: ==> db2 reset monitor for database drew_db Database manager snapshots: ==>db2 get snapshot for database manager Table snapshots: ==>db2 get snapshot for tables on drew_db

What are event monitors? Snapshots are used to examine DB2 at one precise moment and aggregate performance information. Event monitors, on the other hand, are used to monitor the performance of DB2 over a fixed period of time. Event monitors examine transition events in the database and consider each event as an object. This allows a very detailed analysis of DB2's behavior. The information that can be captured by an event monitor is similar to the snapshots. Multiple monitors can be run at once and each monitor can also capture information on more then one type of event. This allows different administrators to monitor different activities independent of one other. The event monitors can capture information on: Databases Tables Deadlocks Table spaces Buffer pools Connections Statements Transactions The information from the event monitors can be written to: SQL tables Files Pipes THROUGH THE WIZARD:

==> db2cc ==> go to database (ex: sample) note: in pop-down menu, you will get the event monitor. ==> select the event monitor and right click on it NAME : ****** click on : tables click on output options note: what are the changes are done it will record in tables. ok ==> create the table and enter the values into it ==> all the changes are recorded in the event monitor.

TO SEE THE OUTPUT: ==> $ db2 select * from table_emon1. (table_emon1 is the name of the event monitor) THROUGH COMMAND LINE: Event monitors are created using the CREATE EVENT MONITOR statement and will collect event information only when they are active. An event monitor is activated and deactivated using the SET EVENT MONITOR STATE statement. The EVENT_MON_STATE function will return the current state of the specified event monitor. Turning monitors on and off Event monitors can be turned on and off at any time. The event monitor state value represents whether or not the event monitor is running. Here's the command to turn a monitor on or off: db2 set event monitor eventMonitorName state [0|1] The eventMonitorName is the name of the created event monitor. 0 will turn the monitor off and 1 will turn it on. SQL command: The SQL function EVENT_MON_STATE returns the state of an event monitor based on the specified name. Here's an example of this SQL command (the table used is an empty table commonly used as a placeholder): SELECT EVENT_MON_STATE('drew Test) FROM SYSIBM.SYSDUMMY1 Catalog tables: There is a table, SYSIBM.SYSEVENTMONITORS, and a view on that table, SYSCAT.EVENTMONITORS, that contain information on the event monitors that have been created. SQL queries can be run against these tables to determine the state of the monitors: SELECT evmonname, target_type, target, FROM syscat.eventmonitors where evmonname LIKE 'drew%' Flushing the event monitors: Event monitor data can also be flushed to disk. This is useful if you would like to

record information such as database events that are only normally written when all connections have been terminated. Here's an example command: db2 flush event monitor eventMonitorName Deadlock monitoring Here's an example deadlock monitor: CREATE EVENT MONITOR DEADLOCK_DB FOR DEADLOCKS WRITE TO FILE 'deadlock_db' MAXFILES 1 MAXFILESIZE NONE AUTOSTART SQL monitoring Here's an example: CREATE EVENT MONITOR BAR FOR STATEMENTS WRITE TO TABLE STMT(TABLE drewkb.stmtTab) includes(rows_read,rows_written_stmt_text)

Event Monitors
While Snapshot Monitors let you "take a picture" of your system at a given time, Event Monitors allow you to collect information based on an event. A typical example is the case of deadlocks. Since it is very difficult to determine when a deadlock is going to happen, taking a snapshot at the right time is almost impossible. Instead, you can use an Event Monitor, which will automatically collect the deadlock information when it occurs. Event Monitors can also be used to collect static and dynamic SQL statements. The following example shows a sequence of statements that illustrate how to collect Event Monitor information using commands. (1) create event monitor mymon1 for database, statements write to file 'e:\temp' (2) set event monitor mymon1 STATE=1 (3) select * from employee (4) set event monitor mymon1 STATE=0 (5) drop event monitor mymon1 (6) db2evmon -path e:\temps In the example, (1) is the statement used to create the Event Monitor mymon1, which specifically collects DATABASE and STATEMENTS events. Other events that can be collected are DEADLOCKS, TABLESPACES, BUFFERPOOLS, CONNECTIONS and TRANSACTIONS. In (2), the Event Monitor is turned on. (3) is used as an example of an SQL statement that should be captured by the Event Monitor. In (4) the Event Monitor is turned off. In (5) the Event Monitor is dropped or deleted, and in (6) the collected information is analyzed with the command db2evmon, the command line version of the Event Analyzer.