DB2 Version 9.7 for Linux, UNIX, and Windows

appl_id - Application ID monitor element

This identifier is generated when the application connects to the database at the database manager or when DB2 Connect™ receives a request to connect to a DRDA® database.

Table 1. Table Function Monitoring Information
Table Function	Monitor Element Collection Level
MON_GET_CONNECTION table function - Get connection metrics	Always collected
MON_GET_CONNECTION_DETAILS table function - Get detailed connection metrics (reported in DETAILS XML document)	Always collected
MON_GET_UNIT_OF_WORK table function - Get unit of work metrics	Always collected
MON_GET_UNIT_OF_WORK_DETAILS table function - Get detailed unit of work metrics (reported in DETAILS XML document)	Always collected

Table 2. Snapshot Monitoring Information
Snapshot Level	Logical Data Grouping	Monitor Switch
Application	appl_id_info	Basic
DCS Application	dcs_appl_info	Basic
Lock	appl_lock_list	Basic

Table 3. Event Monitoring Information
Event Type	Logical Data Grouping	Monitor Switch
Locking	-	-
Unit of work	-	-
Connection	event_conn	-
Connections	event_connheader	-
Statements	event_stmt	-
Transactions¹	event_xact	-
Deadlocks²	event_dlconn	-
Deadlocks with Details²	event_detailed_dlconn	-
Activities	event_activitystmt	-
Activities	event_activity	-
Activities	event_activityvals	-
Threshold violations	event_thresholdviolations	-

1: This option has been deprecated. Its use is no longer recommended and might be removed in a future release. Use the CREATE EVENT MONITOR FOR UNIT OF WORK statement to monitor transaction events.
2: This option has been deprecated. Its use is no longer recommended and might be removed in a future release. Use the CREATE EVENT MONITOR FOR LOCKING statement to monitor lock-related events, such as lock timeouts, lock waits, and deadlocks.

Usage

This ID is known on both the client and server, so you can use it to correlate the client and server parts of the application. For DB2 Connect applications, you will also need to use outbound_appl_id monitor element to correlate the client and server parts of the application.

This identifier is unique across the network. There are different formats for the application ID, which are dependent on the communication protocol between the client and the server machine on which the database manager, DB2 Connect, or both are running. Each of the formats consists of three parts separated by periods.

TCP/IP
Format

IPAddr.Port.Timestamp

IPv4

Example

9.26.120.63.43538.090924175700

Details

In IPv4, a TCP/IP-generated application ID is composed of three sections. The first section is the IP address. It is represented as four decimal numbers of the form a.b.c.d. The second section is the port number, which is represented as 5 decimal characters. The third section is the approximate timestamp, represented as 12 decimal characters.

IPv6

Example

2002:91a:519:13:20d:60ff:feef:cc64.5309.090924175700

Details

In IPv6, a TCP/IP-generated application ID is composed of three sections. The first section contains the IPv6 address of the form a:b:c:d:e:f:g:h, where each of a-h is up to 4 hexadecimal digits. The second section is the port number. The third section is the approximate timestamp identifier for the instance of this application.
Local Applications
Format

*LOCAL.DB2 instance.Application instance

Example
```
*LOCAL.DB2INST1.930131235945
```
Details

The application ID generated for a local application is made up by concatenating the string *LOCAL, the name of the DB2® instance, and a unique identifier for the instance of this application.
For multiple database partition instances, LOCAL is replaced with Nx, where x is the partition number from which the client connected to the database. For example, *N2.DB2INST1.0B5A12222841.

Use the client_protocol monitor element to determine which communications protocol the connection is using and, as a result, the format of the appl_id monitor element.