IBM Data Server Manager
Total Page：16
File Type：pdf, Size：1020Kb
IBM Data Server Manager SQL Statement Monitoring and Historical Analysis Version 2.0 – August 2018 Peter Kohlmann [email protected] © Copyright IBM Corporation 2018 IBM Route 100 Somers, NY 10589 Produced in the United States of America March 2017 All Rights Reserved DB2, IBM, the IBMlogo, InfoSphere, and Rational are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both. Other company, product or service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. All statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice. The information contained in this document is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this document, it is provided “as is” without warranty of any kind, express or implied. In addition, this information is based on current plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise relating to, this document or any other documents. Nothing in this document is intended to, nor shall have the effect of, creating any warranties or representations from IBM Software. SQL Statement Monitoring and Historical Analysis SQL statements are at the core of a relational database. A history of the when and how those statements were executed can be the key solving problems and improving performance. Understanding which statements were running at any given time can give a broad group of user roles insight into what was driving the behavior of the database. For more technically focused DBA's or Developers, if your users complain that the database was running slowly, you will eventually need to know the work going on at that time. Even if you determine that the problem was due to locking contention, or a sudden spike in CPU usage, or that the DB was running out of free log space, you need to know which statements were running at the same time the problem occurred. For business focused Data Administrators, you can also use a complete statement history to measure data access and resource use by business or application area. You can use that to charge for use. Having insight into the statements the database executing right now, can help you identify runaway queries that are locking up database resources. Understanding which statements use the most system resources, or that run most often, will let you understand which statements to focus on for the biggest impact. Having a detailed history of all the statements that have run on your system lets you: • Identify applications and users based on SQL • See exactly which statements need your attention for tuning or optimization • Allow you to audit actions against the database • Chargeback individual users, departments or application owners for what they use Data Server Manager supports different kinds of statement monitoring. Each has its own purpose and strength. Understanding how each works and how to use Data Server Manager to get the most out of each will help you be more successful in determining the root cause of problems, see opportunities for improvement and even to build custom systems for audit or charge-back. Db2 Warehouse Private and the IBM Integrated Analytics System (IIAS) both use all the capabilities found in Data Server Manager to monitor the history of the SQL statements. The main difference is that these physical and virtual appliance offerings are preconfigured. In-flight Statements Data Server Manager can show you which statements are running right now on your database. Once a statement is finished it will disappear from this list, so the vast majority of statements will complete before you can even ask to see the details of the statement. This view is best to manage statements that take minutes or hours to complete and is especially useful in dealing with runaway statements that never end or that tie up the whole database. Select Monitor->Database and then select Realtime and In-Flight Executions. From the list of currently running statements you can: • See details for the running statement • Create a visual explanation of the access plan the statement will use • Select the query for tuning • Cancel the statement or force the application running the statement if the statement or the application is running out of control • The columns that appear above are only a small subset of the database collected and available. Select the show or hide column icon beside the search magnifying glass to add or remove the columns in the table. You can even export the list of statements to a CSV file. Statements that are in the Package Cache now If you need to analyze statements that were running to help with problem determination or better understand what is generating the work and using resources, a good place to start is by viewing monitoring information in the package cache. The package cache is an area in memory where DB2 stores static and dynamic queries, access plans, and information about the execution of those queries. It is that information that Data Server Manager can help you access and to mine for added insight. Select Monitor->Database and then select Realtime and Package Cache. There are over thirty columns of information available for each statement found in the package cache. However the easiest way to find the statements you want to see is to select Show by Highest. This allows you to zero in on the most expensive statements depending on the system you are investigating. If you have a suspected locking problem, select Show by highest lock wait time. If you are running out of resources, select Show by highest CPU time. If you identify a statement you think needs attention, often the next step is to show the details for that statement. Select the statement and then View Details. Often the most useful part of the details screen is Time Spent and I/O. You will quickly see if the time spent on the statement is on sorting, locking, or retrieving data from disk. If you need to dig deeper you can explain the statement to get a better understand of how the data server will execute the statement and construct a result set. Select the statement and then select Explain. Package Cache History One of the most powerful features of Data Server Manager is its ability to collect historical information in its own history repository database. It acts like a flight recorder for a DB2 database and lets you look back in time and pin point what was happening when a problem occurred. It not only lets you more effectively determine the root cause of problems but helps you to eliminate them in the future. You need to have Data Server Manager Enterprise Edition and you have to set up DSM to use a DB2 database as a repository for the historical information. For more information on setting up the repository refer to the Data Server Manager Knowledge Center. Every few minutes Data Server Manager will connect to the database you are monitoring and take a copy of all the information for the most active SQL statements in the cache. By default DSM collects the top 20 statements for each metric. To see the collected history information, select Monitor->History and Package Cache. The first thing different in the History view, that you will notice, is a time slider across the top of the page. You can use the slider, as well as the drop down beside the History button, to select the timeframe you want to focus on. The values in the list are the total values or the average values for each statement that appears in the package cache during the period you have defined in the time slider. You can narrow down your search to a very narrow window of time for specific problem determination, or you can look at the history over the last month to understand which statements are using the most resources overall. Individual Statement History using the Event Monitor If you need to see a complete history of all the statements that ran on your database and exactly when they ran, you need more information than what you can find in the Package Cache. Less frequently used statements are automatically removed from the package cache to keep the most frequently executed statements in memory. So you cannot rely on the package cache to have a complete picture of everything going on in your database over time. For a complete picture you need monitor each event as it happens. Event monitoring can create an individual historical record in your database each time a statement runs. Select Monitor->Database and then select History and Individual Executions. The first thing you may notice is that unlike Package Cache monitoring there is a record of each time the statement started and when it completed. There are also about 30 pieces of information recorded for each statement. Unlike the Package Cache, you can see things like SQL Error and Warnings for statements that did not complete successfully, the workload the statement was executed in, the estimated query cost for each run and many more. To help you navigate this wealth of data, you can also group statements a number of different ways and see complete totals or average or every statement. The most common grouping is Group by SQL Statement or by application name or client IP address or by WLM workload.