Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks

Use transaction SM21 to check your SAP system logs for any error situations
that may be causing performance problems. Use the menu path
Systemlog → Choose → All remote system locks.
2. Check application server health.
If there are no obvious errors on the SAP system logs, begin checking the
health of the application servers:
a. Use transaction ST06 to check the CPU consumption. From the menu
path Goto → Current data → Snapshot → Top CPU processes, you
can determine whether a user transaction or report is looping and using all
of the available CPU.
b. Check the health of the SAP buffers using transaction ST02.
3. Check the database connection.
If there are no problems with the servers in question, confirm that the
database connection from the server to the DB2 data sharing member is
performing well:
a. Check the DRDA® network connection by using SAP transaction DB2,
selecting the DB2 Performance Tuning tab, then selecting DB2 ping to
test the network response time.
This should show a response time of 1–2 milliseconds to send 500 bytes
of data. If this response time is longer, then there is a problem with the
link.
You can investigate this further by clicking DB2 connect diagnostics on
the DB2 Performance Tuning tab.
b. Continue the investigation by asking the network support group to
investigate the problem.
4. Check the z/OS database server health.
Performance analysis on OS/390® z/OS is beyond the scope of this book, but
there are some basic checks that you can perform:
– Check the OS/390 z/OS system logs for any error situations that may
cause problems on the LPAR.
– Check the DB2 MSTR job log for any error situations in DB2 that may be
causing performance problems.
– Check the LPAR CPU utilization and look for looping address spaces
consuming CPU.
– Use RMF Monitor III to check your workloads for any delay.
Chapter 8. Query and Load performance 139