ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzajq_5.4.0.1/mbdma.htm

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>