Download (direct link):
nodecheck • Provides local, node-level resources values (such as free memory, free swap space, and available AMP worker task information) on the local node. Provides summary data to syscheck for analysis. Data is written to STDOUT. • Use the -L option to log the data to a file in addition to normal output to STDOUT. The path is: /tpi-data/nodecheck.tpacyclenum unless you specify a different file and/or location using the syntax: -L -f pathname • Notifies you of resources which have reached WARN or ALERT levels. You can modify threshold values to make a customized syscheckrc file. • Collected information is reported when you run syscheck. The node-level resource information is located in the nodeonly section of the syscheckrc configuration file.
D - 4
Teradata RDBMS Database Administration D - 11Appendix D: Tools for Monitoring Performance
Resource Check Tools
Tool Description References
syscheckrc configuration file • A file containing user-defined parameters that syscheck and nodecheck employ as criteria to determine when certain statistics of the system have reached alert or warning levels. • Default location for the syscheckrc file is: - /usr/ntos/etc (UNIX) - Program Files\NCR\TDAT\LPDE\etc (Windows 2000) • "Troubleshooting a Slow or Hung Job" on page 12-23 • "Resource Check Tools" in Teradata RDBMS Utilities • From UNIX prompt: man utilityname • From Windows 2000 DOS Command Prompt: pdehelp utilityname
syscheck utility This system-wide tool (as compared to nodecheck, which is node-only tool): - spawns an instance of nodecheck on all live TPA nodes. nodecheck gathers data from live components unless you invoke syscheck with the -t n option. With -t n, nodecheck reads the data from its log file. - compares the nodecheck results from each node against threshold values defined in the local syscheckrc file or files. - displays the current resource values on the local node. - displays current resource status or if they have reached WARN or ALERT levels.
Teradata RDBMS Database Administration
D - 11Appendix D: Tools for Monitoring Performance
PM/API Dynamic Data
PM/API Dynamic Data
Performance Monitor (PM) is an Application Program Interface (API) that allows you to collect dynamic performance data by issuing queries through a logon partition called MONITOR. Using the MONITOR partition, you can collect performance data on:
• Current system configuration
• Resource usage and status of an individual AMP, PE, or node
• Resource consumption and status of individual sessions
Use of the MONITOR queries require the following access rights:
• MONITOR SESSION
• MONITOR RESOURCE
• SET SESSION RATE
• SET RESOURCE RATE
• ABORT SESSION
SET RESOURCE, SET SESSION, and ABORT SESSION tasks are considered major system events and are logged to the DBC.SW_Event_Log table. (The LogonSource column includes additional source information about sessions logged on from an MVS or VM client, including job name and information on the TDP.)
PM/API collects data in memory, not in a spool file on disk. As a result, PM/API queries cannot be blocked, and thus incur low overhead.
Note: The exception to this rule is IDENTIFY, which is used to obtain the ID of a session, database, user, and/or data table. IDENTIFY can cause a block or may be blocked because of its need to access the system tables DBC.SessionTbl, DBC.DBase, DBC.User, and DBC.TVM.
How PM/API Collects Data
PM/API stores node and vproc resource usage data and session-level usage data in separate collection areas. The data stored in memory is updated once during each sampling period. All users share the collected data.
MONITOR updates the samples of processor (node/vproc) usage data differently from session-level usage data. To interpret the information that MONITOR returns, you need to understand the difference.
Collecting and Reporting Processor (node/vproc) Data
PM/API reports node and vproc usage data only for the most recent sampling period. The data from each subsequent sampling period overwrites the data collected during any preceding sampling period.
D - 6
Teradata RDBMS Database AdministrationAppendix D: Tools for Monitoring Performance
PM/API Dynamic Data
Collecting and Reporting Session-level Usage Data
PM/API reports cumulative results of session-level usage data such as counts and time used.
The session data collected during the most recent sampling period is added to the total of the previous sampling periods. The duration of the sampling period dictates how often the data is updated. Thus, session-level data cumulatively reflects all data gathered between the time the MONITOR RESOURCE request was issued and the time the data is retrieved.
Note: Other data, such as locking information and AMP state, is collected at the AMP level and is not stored cumulatively.
For further information on using PM/API, see:
• Teradata RDBMS PM/API Reference