Forensics is a collection of tests and techniques used together to uncover detailed evidence that can be used to help reconstruct an event. This article describes how network-related forensic tools can be useful to DB2 for z/OS.
Victims and Suspects
Network access to DB2 for z/OS is provided by Distributed Data Facility (DDF), a built-in component. Any application server or client, running on z/OS or any platform, can use TCP/IP to access DB2 though DDF. In this environment, there are many potential victims of bad network service and performance (see Figure 1).
DDF runs as a z/OS address space named ssidDIST, which opens TCP ports and listens for connections. Every component in a multi-tier application path can be a suspect when things go wrong. Was it the network, client, application, or DB2 server?
Crime scene investigations use data from sources such as bank account records and interviews to get a broader understanding of victims, other events, and any patterns that might connect them.
When investigating networks, TCP/IP traffic analysis figures for a z/OS Logical Partition (LPAR) indicate who has been active, how, when, and where. Traffic passing through DDF TCP ports can be broken down for insight into the behavior of DB2 for z/OS and its connection partners:
- Which remote node had the most traffic with one or any DB2 DDF task in the last minute, hour, day, or since DB2 started?
- Which DDF task is the busiest by bytes? By connections?
- How long are most TCP/IP connections to a DB2 DDF task—milliseconds for Web transactions and hours for persistent connections? Is this as expected? How does this compare to other DDF tasks?
- Which network interface carries the most traffic to and from this DDF?
A problem is reported with a TCP/IP connection between client A and DB2 B. But what else are client A and DB2 B involved in simultaneously? Knowing that can help you determine where to start investigating. For example: