142 lines
10 KiB
HTML
142 lines
10 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="reference" />
|
||
|
|
<meta name="DC.Title" content="Monitoring your queries using memory-resident database monitor" />
|
||
|
|
<meta name="abstract" content="The Memory-Resident Database Monitor is a tool that provides another method for monitoring database performance. This tool is only intended for SQL performance monitoring and is useful for programmers and performance analysts. The monitor, with the help of a set of APIs, takes database monitoring information and manages them for the user in memory. This memory-based monitor reduces CPU overhead as well as resulting table sizes." />
|
||
|
|
<meta name="description" content="The Memory-Resident Database Monitor is a tool that provides another method for monitoring database performance. This tool is only intended for SQL performance monitoring and is useful for programmers and performance analysts. The monitor, with the help of a set of APIs, takes database monitoring information and manages them for the user in memory. This memory-based monitor reduces CPU overhead as well as resulting table sizes." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="queryopt.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="memresapidescription.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="memrestabledesc.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="samplesqlqueries.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="memresrowid.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/qqqssdbm.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/qqqdsdbm.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/qqqcsdbm.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/qqqqsdbm.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/qqqesdbm.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="mbdma" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Monitoring your queries using memory-resident database monitor</title>
|
||
|
|
</head>
|
||
|
|
<body id="mbdma"><a name="mbdma"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Monitoring your queries using memory-resident database monitor</h1>
|
||
|
|
<div><p>The Memory-Resident Database Monitor is a tool that provides another
|
||
|
|
method for monitoring database performance. This tool is only intended for
|
||
|
|
SQL performance monitoring and is useful for programmers and performance analysts.
|
||
|
|
The monitor, with the help of a set of APIs, takes database monitoring information
|
||
|
|
and manages them for the user in memory. This memory-based monitor reduces
|
||
|
|
CPU overhead as well as resulting table sizes.</p>
|
||
|
|
<div class="section"><p>The <span class="apiname">Start Database Monitor (STRDBMON)</span> can constrain
|
||
|
|
server resources when collecting performance information. This overhead is
|
||
|
|
mainly attributed to the fact that performance information is written directly
|
||
|
|
to a database table as the information is collected. The memory-based collection
|
||
|
|
mode reduces the server resources consumed by collecting and managing
|
||
|
|
performance results in memory. This allows the monitor to gather database
|
||
|
|
performance statistics with a minimal impact to the performance of the server
|
||
|
|
as whole (or to the performance of individual SQL statements).</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The monitor collects much of the same information as the STRDBMON
|
||
|
|
monitor, but the performance statistics are kept in memory. At the expense
|
||
|
|
of some detail, information is summarized for identical SQL statements to
|
||
|
|
reduce the amount of information collected. The objective is to get the statistics
|
||
|
|
to memory as fast as possible while deferring any manipulation or conversion
|
||
|
|
of the data until the performance data is dumped to a result table for analysis.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The memory-based monitor is not meant to replace the STRDBMON
|
||
|
|
monitor. There are circumstances where the loss of detail in the monitor will
|
||
|
|
not be sufficient to fully analyze an SQL statement. In these cases, the STRDBMON
|
||
|
|
monitor should still be used.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The memory-based monitor manages the data in memory, combining
|
||
|
|
and accumulating the information into a series of row formats. This means
|
||
|
|
that for each unique SQL statement, information is accumulated from each run
|
||
|
|
of the statement and the detail information is only collected for the most
|
||
|
|
expensive statement execution.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Each SQL statement is identified by the monitor according to the
|
||
|
|
following:</p>
|
||
|
|
<ul><li>statement name</li>
|
||
|
|
<li>package (or program)</li>
|
||
|
|
<li>schema that contains the prepared statement</li>
|
||
|
|
<li>cursor name that is used</li>
|
||
|
|
</ul>
|
||
|
|
<p>For pure dynamic statements, the statement text is kept in a separate
|
||
|
|
space and the statement identification will be handled internally via a pointer.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>While this system avoids the significant overhead of writing each
|
||
|
|
SQL operation to a table, keeping statistics in memory comes at the expense
|
||
|
|
of some detail. Your objective should be to get the statistics to memory as
|
||
|
|
fast as possible, then reserve time for data manipulation or data conversion
|
||
|
|
later when you dump data to a table.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The memory-based monitor manages the data that is in memory by
|
||
|
|
combining and accumulating the information into the new row formats. Therefore,
|
||
|
|
for each unique SQL statement, information accumulates from each running of
|
||
|
|
the statement, and the server only collects detail information for the most
|
||
|
|
expensive statement execution.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Each SQL statement is identified by the monitor by the statement
|
||
|
|
name, the package (or program) and schema that contains the prepared statement
|
||
|
|
and the cursor name that is used. For pure dynamic statements: </p>
|
||
|
|
<ul><li>Statement text is kept in a separate space and</li>
|
||
|
|
<li>Statement identification is handled internally via a pointer.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">API support for the memory-based monitor</h4><p>A set of
|
||
|
|
APIs enable support for the memory-based monitor. An API supports each of
|
||
|
|
the following activities: </p>
|
||
|
|
<ul><li>Start the new monitor</li>
|
||
|
|
<li>Dump statistics to tables</li>
|
||
|
|
<li>Clear the monitor data from memory</li>
|
||
|
|
<li>Query the monitor status</li>
|
||
|
|
<li>End the new monitor</li>
|
||
|
|
</ul>
|
||
|
|
<p>When you start the new monitor, information is stored in the local
|
||
|
|
address space of each job that the system monitors. As each statement completes,
|
||
|
|
the system moves information from the local job space to a common system space.
|
||
|
|
If more statements are executed than can fit in this amount of common system
|
||
|
|
space, the system drops the statements that have not been executed recently.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="memresapidescription.htm">Memory-resident database monitor external API description</a></strong><br />
|
||
|
|
The memory-resident database monitor is controlled by a set of APIs.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="memrestabledesc.htm">Memory-resident database monitor external table description</a></strong><br />
|
||
|
|
The memory resident database monitor uses its own set of tables instead of using the single table with logical files that the STRDBMON monitor uses. The memory resident database monitor tables closely match the suggested logical files of the STRDBMON monitor.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="samplesqlqueries.htm">Sample SQL queries</a></strong><br />
|
||
|
|
As with the STRDBMON monitor, it is up to the user to extract the information from the tables in which all of the monitored data is stored. This can be done through any query interface that the user chooses.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="memresrowid.htm">Memory-resident database monitor row identification</a></strong><br />
|
||
|
|
The join key column QQKEY simplifies the joining of multiple tables together. This column replaces the join field (QQJFLD) and unique query counters (QQCNT) that the database monitor used. The join key column contains a unique identifier that allows all of the information for this query to be received from each of the tables.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="queryopt.htm" title="Query optimization is an iterative process. You can gather performance information about your queries and control the processing of your queries.">Optimizing query performance using query optimization tools</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../apis/qqqssdbm.htm">Start SQL Database Monitor (QQQSSDBM) API</a></div>
|
||
|
|
<div><a href="../apis/qqqdsdbm.htm">Dump SQL Database Monitor (QQQDSDBM) API</a></div>
|
||
|
|
<div><a href="../apis/qqqcsdbm.htm">Clear SQL Database Monitor Statistics (QQQCSDBM) API</a></div>
|
||
|
|
<div><a href="../apis/qqqqsdbm.htm">Query SQL Database Monitor (QQQQSDBM) API</a></div>
|
||
|
|
<div><a href="../apis/qqqesdbm.htm">End SQL Database Monitor (QQQESDBM) API</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|