1098

Teradata Database
Resource Usage Macros and Tables

Release 12.0
B035-1099-067A
September 2007
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce,
SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve Never Seen Your Business Like
This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of GoldenGate Software, Inc.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, DB2, MVS, RACF, Tivoli, and VM are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI and Engenio are registered trademarks of LSI Corporation.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United
States and other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
QLogic and SANbox trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademarks of SPARC International, Inc.
Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other
countries.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States
and other countries.
Unicode is a collective membership mark and a service mark of Unicode, Inc.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are
not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features,
functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions,
products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated
without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any
time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this
document. Please e-mail: teradata-books@lists.teradata.com
Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed non-confidential. Teradata
Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform,
create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata
Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including
developing, manufacturing, or marketing products or services incorporating Feedback.
Copyright © 2000 - 2007 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This book describes, and provides procedures for, Teradata Database resource usage data and
macros.
Audience
This book is intended for system programmers, system administrators, and other database
specialists responsible for administering or managing Teradata Database.
Supported Software Release

This book supports Teradata® Database 12.0.
Prerequisites
You should be familiar with basic computer technology, Teradata Database, and the system
console environment.
It will be helpful to review or reference the following books:
• Introduction to Teradata Warehouse
• Workload Management API: PM/API and Open API
• Performance Management
Resource Usage Macros and Tables 3

Preface
Changes to This Book
Changes to This Book

This book includes the following changes to support the current release:
Date Description
Teradata Database 12.0 Made the following updates:

September 2007
• Added spare columns to the ResUsageSawt and ResUsageSps tables.
• In ResUsageSvpr, added the following fields: FileFcrDeniedKern,
FileFcrDeniedThreshKern, FileFcrBlocksDeniedKern, and
FileFcrBlocksDeniedThreshKern; and to the ResUsageSpma table:
ProcPendFsgLock, ProcBlksFsgLock, ProcWaitFsgLock,
ProcPendQnl, ProcBlksQnl, and ProcWaitQnl.
• In ResUsageSpma, replaced the following fields: ProcPendSegRead,
ProcBlksSegRead, ProcWaitSegRead, ProcPendSegWrite,
ProcBlksSegWrite, and ProcWaitSegWrite, with: ProcPendFsgRead,
ProcBlksFsgRead, ProcWaitFsgRead, ProcPendFsgWrite,
ProcBlksFsgWrite, and ProcWaitFsgWrite.
• In ResUsageSvpr, replaced the following fields: FileFcrDenied,
FileFcrDeniedThresh, FileFcrBlocksDenied, and
FileFcrBlocksDeniedThresh, with: FileFcrDeniedUser,
FileFcrDeniedThreshUser, FileFcrBlocksDeniedUser, and
FileFcrBlocksDeniedThreshUser.
• In ResUsageSpma and ResUsageIpma, added the NodeNormFactor
field.
• Added two Teradata Active System Management tables:
ResUsageSawt and ResUsageSps, and two ResUsage tables:
ResUsageSpdsk (not currently used) and ResUsageSvdsk. Also added
the macros for these tables (except for ResUsageSpdsk) and a
resource usage view for ResUsageSvdsk.
• Added the SET ACTIVELOGTABLE and SET SUMLOGTABLE
database commands to the “Resource Usage Procedures” chapter.
• Added the Depot Columns category and fields to the ResUsageSpma
tables; and the Write Ahead Logging (WAL) Column category and
fields to the ResUsageSvpr and ResUsageIvpr tables.
• In ResUsageSpma, added the CPUIdleNorm, CPUIOWaitNorm,
CPUUServNorm, and CPUExecNorm fields.
• In ResUsageSpdsk, added to the PdiskDeviceId field the DISK pdisk
device ID for MP-RAS, Windows, and Linux.
• In ResUsageSvpr, added the FileWCylFrees field.
• Changed the default of all “OneNode” macros to '001-01' and the
format of NCPUs to 'ZZ9'.
4 Resource Usage Macros and Tables

Preface
Additional Information
Date Description
V2R6.2 • The following systems are supported: Microsoft Windows Server

September 2006 2003, MP-RAS, and Linux SUSE.
• Buddy backup on MP-RAS has been replaced with Write Ahead
Logging.
• When the system becomes busy, it automatically doubles the logging
period which effectively summarizes the data by providing the same
number of values for the temporarily extended logging period.
• Updated “Invalid Platform” for some columns that had been
previously invalid on some operating systems but are now usable on
all operating systems.
• Updated descriptions of Data Block Prefetches Columns in the
ResUsageSvpr chapter.
V2R6.1 • When the system becomes busy, the logging interval will double.
May 2006 When the system returns to normal, the system automatically
returns to the logging rate you set.
• Removed references to the VprType “DM.” This vproc type should
only be described as “RSG.”
Additional Information
Additional information that supports this product and the Teradata Database is available at
the following Web sites.
In the following table, mmyx in the book product ID number B035-xxxx-mmyx represents the
publication date of a manual, where mm is the month, y is the last digit of the year, and x is an
internal publication code.
Type of Information Description Source
Overview of the The Release Definition provides the http://www.info.teradata.com/

release following information:
Click General Search. In the Publication Product ID
Information too late • Overview of all the products in the field, enter 1725 and click Search to bring up the
for the manuals release following Release Definition:
• Information received too late to be • Base System Release Definition
included in the manuals B035-1725-067K
• Operating systems and Teradata
Database versions that are certified to
work with each product
• Version numbers of each product and
the documentation for each product
• Information about available training
and support center

Preface
References to Microsoft Windows and Linux
Type of Information Description Source
Additional Use the Teradata Information Products http://www.info.teradata.com/

information related Publishing Library site to view or download Click General Search, and do one of the following:
to this product the most recent versions of all manuals.
• In the Product Line field, select Software -
Specific manuals that supply related or Teradata Database for a list of all of the
additional information to this manual are
publications for this release,
listed.
• In the Publication Product ID field, enter one of
the following book numbers:
• Introduction to Teradata Warehouse
B035-1091-067A
• Workload Management API: PM/API and
Open API
B035-1090-067A
B035-1097-067A
CD-ROM images This site contains a link to a downloadable http://www.info.teradata.com/

CD-ROM image of all customer Click General Search. In the Title or Keyword field,
documentation for this release. Customers
enter CD-ROM, and Click Search.
are authorized to create CD-ROMs for their
use from this image.
Ordering Use the Teradata Information Products http://www.info.teradata.com/

information for Publishing Library site to order printed
Click How to Order under Print & CD Publications.
manuals versions of manuals.
General information The Teradata home page provides links to Teradata.com

about Teradata numerous sources of information about
Teradata. Links include:
• Executive reports, case studies of
customer experiences with Teradata,
and thought leadership
• Technical information, solutions, and
expert advice
• Press releases, mentions and media
resources

This book refers to “Microsoft Windows” and “Linux.” For Teradata Database 12.0, these
references mean the following:
• “Windows” is Microsoft Windows Server 2003 32-bit and Microsoft Windows Server 2003
64-bit.
• “Linux” is SUSE Linux Enterprise Server 9 and SUSE Linux Enterprise Server 10.
Teradata plans to release Teradata Database support for SUSE Linux Enterprise Server 10
before the next major or minor release of the database. Therefore, information about this
SUSE release is included in this document. The announcement regarding availability of SUSE

Preface
Linux Enterprise Server 10 will be made after Teradata Database 12.0 GCA. Please check with
your account representative regarding SUSE Linux Enterprise Server 10 availability in your
location.

Preface

Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Changes to This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
References to Microsoft Windows and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Benefits of Using Resource Usage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Accessing Resource Usage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Setting Up and Maintaining Resource Usage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
An Overview of Resource Usage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Topics Covered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Types of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Gathering Resource Usage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Data Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Data Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Using Resource Usage Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Programs That Use Resource Usage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 2: Planning Your Resource Usage Data . . . . . . . . . . . . . . 23
Enabling ResUsage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Tables Based on Needed Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ResUsage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Setting Collection and Logging Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Collection Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Logging Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Determining the Type of Logging Rate To Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Table of Contents
Determining the Logging and Collection Rate Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Using Summary Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Using Active Row Filter Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Optimizing Resource Usage Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
The Cost of Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Logging Cost Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Operational Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Chapter 3: Resource Usage Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Enabling RSS Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Using ctl and xctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Using Database Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
General Macro Input Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Parameter Use for One-Node, Multiple-Node, All-Node, and Group Macros . . . . . . . . .38
Using One-Node Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Using ByGroup Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Saving and Analyzing Data From Prior Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Executing Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
EXECUTE MACRO Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Using DISABLE LOGONS To Stop Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Purging Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Chapter 4: Resource Usage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Physical Table Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Working with ResUsage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Relational Primary Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Inserting Rows to Resource Usage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Occasional Event Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Data Content of Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Column Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
About the "Invalid Platform" Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
About the "Gather Method" Column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Column Names Ending In “Sum” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Column Names Ending In “Max” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Column Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Summary Mode in Resource Usage Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Table of Contents
SECTION 1 Node Resource Usage Tables
Chapter 5: ResUsageScpu Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 6: ResUsageSpma Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Obsolete Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Memory Pages Resident Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Backup AMP and Traffic Management Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SECTION 2 Vproc Resource Usage Tables
Chapter 7: ResUsageSawt Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 8: ResUsageShst Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chapter 9: ResUsageSldv Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Concurrent Operations Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Seek Statistics Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Response Time Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Table of Contents
Chapter 10: ResUsageSpdsk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Chapter 11: ResUsageSps Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113

Active Row Filter Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Chapter 12: ResUsageSvdsk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Chapter 13: ResUsageSvpr Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Obsolete Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

Backup AMP Traffic Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
SECTION 3 Views and Macros
Chapter 14: Resource Usage Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
ResGeneralInfoView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
ResCPUUsageByAMPView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
ResCPUUsageByPEView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
ResShstGroupView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
ResSldvGroupView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
ResVdskGroupView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152

Table of Contents
Chapter 15: Resource Usage Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Macro Output Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

ResAWT Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
ResAWT Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
ResAWTByAMP Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
ResAWTByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
ResCPUByAMP Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
ResCPUByAMP Sample Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
ResCPUByAMPOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
ResAmpCpuByGroup Sample Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
“Normalized” Viewing of CPU Usage by AMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
ResCPUByPE Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
ResCPUByPE Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
ResCPUByPEOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
ResPeCpuByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
“Normalized” Viewing of CPU Usage by PE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
ResCPUByNode Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
ResCPUByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
ResCPUOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
ResCPUByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
ResHostByLink Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
ResHostByLink Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ResHostOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ResHostByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
ResLdvByNode Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
ResLdvByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
ResLdvOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
ResLdvByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
ResMemMgmtByNode Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
ResMemMgmtByNode Sample Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
ResMemMgmtOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
ResMemByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
ResNetByNode Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
ResNetByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
ResNetOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
ResNetByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
ResNode Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
ResNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
ResOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
ResNodeByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Table of Contents
ResNodeByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188

ResPs Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
ResPsByNode Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
ResPsByGroup Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
ResPsByNodeWDJoin Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
ResPsWDJoin Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
ResPsCPU Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
ResPsCPUByNodeWDJoin Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
ResPsCPUWDJoin Macro Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
ResVdskByNode Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
ResVdskByNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
ResVdskOneNode Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
ResVdskByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
SECTION 4 Appendixes
Appendix A: How to Read Syntax Diagrams . . . . . . . . . . . . . . . . . . . .205
Syntax Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Appendix B: ResUsageIpma Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Appendix C: ResUsageIvpr Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Appendix D: Partition Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Partition Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Table Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Partition Assignment Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234

Table of Contents
Appendix E: System Activity Reporter. . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Using Sar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Comparing Sar and Resource Usage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Table of Contents

CHAPTER 1 Introduction
Resource usage, or ResUsage, is the collection and reporting of statistical information about
the operation of your operating system and Teradata Database.
Benefits of Using Resource Usage Data

Resource usage data is useful for the following purposes:
• Measuring system benchmarks
• Measuring component performance
• Assisting with on-site job scheduling
• Identifying potential performance impacts
• Planning installation, upgrade, and migration
• Analyzing performance degradation and improvement
• Identifying problems such as bottlenecks, parallel inefficiencies, down components, and
congestion
Accessing Resource Usage Data

Resource usage data is stored in Teradata Database tables and views in the DBC database.
Macros installed with Teradata Database generate reports that display the data.
There are several applications and utilities available for viewing resource usage data. See
Teradata Manager User Guide for more information on viewing resource usage data with
Teradata Manager and using Teradata Performance Monitor (PMON).
You can also write your own queries or macros on resource usage data. As with other database
data, you can access resource usage data using SQL.

Chapter 1: Introduction
Setting Up and Maintaining Resource Usage Data
Setting Up and Maintaining Resource Usage

Data
You need to decide what resource usage data you want to collect and the level of detail you
want it to cover.
This manual documents the resource usage data and settings for a variety of installation
configurations and environments in Chapter 2: “Planning Your Resource Usage Data.” To
implement the settings you decide on, see Chapter 3: “Resource Usage Procedures.”
Once you set up your resource usage data collection the way you want, the only maintenance
required is to purge old data regularly. See “Purging Data” on page 43.
Related Topics
For additional information on performance analysis and system tuning, see the following
books:
• Workload Management API: PM/API and Open API
• Teradata Manager User Guide
An Overview of Resource Usage Data
Topics Covered
The following table lists topics covered by resource usage data:
Resource usage data covers … Which includes …
BYNET traffic on a node point-to-point messaging, broadcast messaging, and merge

activities.
client-to-server traffic data for each communication link.
CPU utilization overhead, user service, and time of session execution.
data tracking positions of sessions in locking queues.
logical device traffic (SCSI) number of reads/writes and amount of data transferred as
seen from the SCSI driver.
vdisk logical device traffic all the cylinders allocated by an AMP (which can come from
any pdisks in the clique).
Priority Scheduler information data by Performance Group (PG) from the Priority
Scheduler and the ability to report resource usage data by
Teradata Active System Management (Teradata ASM)
workloads (WDs).

Gathering Resource Usage Data
Resource usage data covers … Which includes …
AMP Worker Task (AWT) AWT statistics.

information
memory management activity memory allocation, aging, paging, and swapping.
summary information all data collected for a node or vproc.
Types of Data
You can think of resource usage data in the following general categories:
Category Description
aggsam Aggregated sample data tracks the average value of multiple samples of a
countable item, such as average queue length. Given the number of samples
that the aggregated value represents, the value can be divided by that number.
count Counted data tallies the number of times an event occurred, such as the
number of disk reads or writes during a period of time.
countshft Countshift data is similar to count data except that the gathering software
counts in units of some power of two, and the Resource Sampling Subsystem
(RSS) software shifts the data value by the number of bits necessary to
convert it to some other unit. For example, the gathering software
accumulates Spma.MsgPtPReadKB in 16-byte units, and RSS then shifts the
resulting values right by 6 bits, converting the value to kilobytes (KBs).
track Tracked data gauges the current value of a countable item, such as queue
lengths during a period of time.
tmon Time-monitored data reports the time that a resource was in use, such as
processor time. Unless otherwise stated, all times reported in ResUsage tables
are in hundreths of seconds.

Resource usage data gathering is a two-phase process as follows:
• Data collection
• Data logging
Data Collection
During the data collection phase the RSS gathers information from the operating system,
Parallel Database Extensions (PDE), and Teradata Database.
Data collection continues for a user-specified period of time, called the collection interval.

Data Logging
In the logging phase, which occurs at the end of each logging period and consists of one or
more complete collect intervals, the RSS writes all gathered data to ResUsage tables and
reinitializes the shared data collection buffers for the next log interval.
Data Collection Macros

and Gather Buffer
Routines
Collect Interval
Collect Work Summary

Buffer Buffer Work Buffer
Log Interval
Log Buffer Summary Log

(Data to be written to disk) Buffer
ResUsage
Write Queue
ResUsage ResUsage Reports

Tables
1097E005

Using Resource Usage Macros
Using Resource Usage Macros

Resource usage macros produce reports from data collected in the resource usage tables. You
can use the reports to analyze key operational statistics and evaluate the performance of your
system.
Like other macros, resource usage macros consist of one or more Teradata SQL statements
stored in Teradata Database and executed by a single EXECUTE statement.
In addition to the name of the macro, the EXECUTE statement for resource usage macros can
include parameters to specify the following:
• A specific single node
• A group of nodes
• Starting and ending dates and times
• Starting and ending nodes of a range of nodes
Refer to Chapter 3: “Resource Usage Procedures” for more information on the resource usage
macros, and SQL/Data Dictionary Quick Reference for details about how to use the EXECUTE
statement.
Programs That Use Resource Usage Data

The resource usage data are not used by just the resource usage macros. Resource usage data
can also be enabled from any of these programs:
• Teradata Manager
• Teradata Performance Monitor (client application running on Windows)
• Performance Monitor/Application Programing Interface (PM/API)
PM/APIs and Equivalent Teradata Performance Monitor Options

The following table lists the PM/APIs, specifically the System Performance Monitor and
Production Control (PMPC) requests, and the equivalent Teradata Performance Monitor
windows. If an error message is generated for the command, it is listed as well.

Programs That Use Resource Usage Data
Equivalent Teradata
Performance Monitor
Options Selected from the
Request Main Window Possible Error Message Explanation
MONITOR PHYSICAL • Resource Data Unavailable: The user requested Resource

RESOURCE • Monitor Physical Resource Usage Sampling monitoring, but the ResMonitor Rate
Resource is not currently enabled. is zero.
For information on how to resolve
this error message, see Messages.
MONITOR PHYSICAL • Summary

SUMMARY • Monitor Physical
Resource
MONITOR VIRTUAL • Resource Data Unavailable. The RSS The user requested Resource
RESOURCE • Monitor Virtual Collection Rate is not monitoring, but the RSS Collection
Resource currently enabled. Rate is not enabled.
Remedy: Enable the RSS Collection
Rate by setting it to a non-zero value
and resubmit this request. For
information on how to resolve this
error message, see Messages.
MONITOR VIRTUAL • Summary

SUMMARY • Monitor Virtual
Resource
For more information on System PMPC requests and other PM/APIs, see Workload
Management API: PM/API and Open API.

CHAPTER 2 Planning Your Resource Usage
Data
This chapter describes the following items:

• Enabling ResUsage tables
• Setting collection and logging rates
• Using Summary Mode
• Using Active Row Filter Mode
• Optimizing resource usage logging
Enabling ResUsage Tables

The default collection and logging settings provide a good start for basic system monitoring.
The default results in the ResUsageSpma (SPMA) table being logged every 10 minutes
(600 seconds).
The applications that use the collect buffer generally require more frequent data updates;
therefore, the collection rate is typically adjusted to 60 seconds. PMON and other collect
buffer based applications: Teradata Manager or PM/API, do not require the logging rate to be
changed or any of the tables to be enabled (for logging) in order to access the RSS data they
use.
The ResUsageSpma table provides a high level summary of how the system is operating and
contains summarized or key elements from most of the other tables. If you want to record
detailed statistics covered by any of the ResUsage tables, then you should enable them for
logging, along with specifying the largest logging period that will meet your needs. You should
not log data that you do not have a planned need for since this does incur additional database
system overhead and uses up additional database space.
Naturally, the more tables you enable for logging and the shorter the logging period used, the
more overhead the system will use.

Chapter 2: Planning Your Resource Usage Data
Tables Based on Needed Reports

If you are using the report macros provided in Chapter 15: “Resource Usage Macros,” then you
need to enable the associated table.
Related Topics
For ... See ...
a list of resource usage macros and their “Determining the Type of Logging Rate To Set” on
associated tables page 27.
instructions on setting ResUsage tables “Enabling RSS Logging” on page 33.
instructions on using macros “General Macro Input Format” on page 37 and

“Executing Macros” on page 39.
descriptions and examples of the macros Chapter 15: “Resource Usage Macros.”
ResUsage Tables
ResUsage tables are divided into two groups: Node and Vproc.
The following table describes these two groups and the tables within each group. It also
provides guidance about which ones to enable.
Table Name Covers When You Should Enable
Node Resource Usage Tables

The tables in this group are controlled by the RSS Collection Rate and Node logging rate.
ResUsageScpu Statistics on the CPUs within the nodes. When the performance analysis suggests that the
overall performance is limited or to check if a
program is spinning in an infinite loop on an
individual processor.
For example, saturation of a particular CPU on each
node or on a particular node while others are idle
could indicate a task always uses that CPU.
Also, you should enable when the system is first
brought online to verify the following:
• That all CPUs are functioning on all nodes
• There is a good load balance among the CPUs

Table Name Covers When You Should Enable
ResUsageSpma System-wide node information provides a To provide an overall history of the system operation.
summary of overall system utilitization
incorporating the essential information
from most of the other tables.
Use the columns in ResUsageSpma to view
BYNET utilization.
Note: The BYNET can transmit and receive
at the same time, resulting in 100%
transmitting and 100% receiving values
simultaneously.
Another method of determining BYNET
utilization and traffic is to use the blmstat
tool.
ResUsageIpma System-wide node information, intended Generally, this table is not used at customer sites.
primarily for Teradata engineers.
Vproc Resource Usage Tables

The tables in this group are controlled by the RSS Collection Rate and the Vproc logging rate.
ResUsageSawt Data specific to the AMP worker tasks When you want to monitor the utilization of the
(AWTs). AWT and determine if work is backing up because the
AWTs are all being used.
ResUsageShst Statistics on the host channels and LANs To determine details about the traffic over the IBM
that communicate with Teradata Database. Host channels to determine if there is a bottleneck.
ResUsageSldv System-wide, logical device statistics To observe the balance of disk usage. The SCSI disk
collected from the SCSI bus. statistics are often difficult to interpret with disk
arrays attached due to multi-path access to disks.
Note: Use the ResUsageSvdsk table first to observe
general system disk utilization unless specifically
debugging at a low level.
ResUsageSps Data by Performance Group (PG) ID from When you need to track utilization by the query
the Priority Scheduler. Workload Definition (WD) level.
ResUsageSvdsk Statistics collected from the vdisk logical To view the details of the disk usage across the AMPs
device. to look for hot AMPS or other skew issues.
ResUsageSvpr Data specific to each virtual processor and To view details about the resources being used by each
its file system. vproc on the system. This table is useful for looking
for hot AMPS or PEs that may be CPU bound or
throttled on other resources.
ResUsageIvpr System-wide virtual processor information, Generally, this table is not used at customer sites.
intended primarily for Teradata engineers.

Setting Collection and Logging Rates

The default for RSS Collection Rate and Node and Vproc Logging Rate is 600. However, the
typical collection rate setting will be determined by the collect buffer applications, such as
PMON, which normally sets the collection rate to 60 seconds.
When you have decided what rates to set, see Chapter 3: “Resource Usage Procedures” for
details on how to set the rates.
Collection Rate
Collection rate controls the frequency (number of seconds) at which resource usage data is
made available to programs that collect the data. The term collection interval is the same as
collection rate.
The RSS Collection Rate controls the collection of resource usage data from both the virtual
processors and the nodes. That is, the RSS Collection Rate implies the rate for both vproc and
node collection.
Logging Rate
Logging rate controls the frequency (number of seconds) at which resource usage data is
logged to the resource usage tables.
Resource usage logging means the writing of resource data as rows to one or more of the
ResUsage database tables. The tables are named DBC.ResUsagexxxx, where xxxx is the name
of the resource usage table (for example, Spma, Ipma, and so on) as listed in “ResUsage
Tables” on page 24.
The shorter the logging period, the more frequently data is logged, and the more disk space is
used.
There are two types of logging rates.
This logging rate … Controls the logging of resource usage data for …
vproc logging rate virtual processors to the resource usage tables.
node logging rate nodes to the resource usage tables.
The Node and Vproc logging rates must be integer multiples of the RSS Collection Rate.
When the system is so busy that the ResUsage table logging gets backed up, RSS will
automatically double the logging period which effectively summarizes the data by providing
values for a time period twice that provided by the previous logging period.
If you see the resource usage logging rates change without user intervention, this means that
the database is busy. When no longer busy, the system resumes logging as before.

Note: New events that may occur in the event logs during this double logging period do not
represent fatal errors but are informational to indicate that the automatic operations of the
RSS are attempting to maintain data logging.
Determining the Type of Logging Rate To Set

Use the following table to determine which type of logging rate to set.
For this table … And these macros... Use this logging rate...
ResUsageSpma ResCPUByGroup node

ResCPUByNode
ResCPUOneNode
ResMemByGroup
ResMemMgmtByNode
ResMemMgmtOneNode
ResNetByGroup
ResNetByNode
ResNetOneNode
ResNode
ResOneNode
ResNodeByGroup
ResNodeByNode
ResUsageSawt ResAWT vproc

ResAWTByAMP
ResAWTByNode
ResUsageShst ResHostByGroup vproc

ResHostByLink
ResHostOneNode
ResUsageSldv ResLdvByGroup vproc

ResLdvByNode
ResLdvOneNode
ResUsageSps ResPsByNode vproc

ResPsByGroup
ResPsByNodeWDJoin
ResPsCPUByNodeWDJoin
ResPsWDJoin
ResPsCPUWDJoin
ResUsageSvdsk ResVdskOneNode vproc

ResVdskByNode
ResVdskByGroup
ResUsageSvpr ResAmpCPUByGroup vproc

ResCPUByAMP
ResCPUByAMPOneNode
ResCPUByPE
ResCPUByPEOneNode
ResPeCpuByGroup

Determining the Logging and Collection Rate Values

The system imposes two rules on logging and collection rates:
1 Intervals must evenly divide into 3600 (the number of seconds in an hour). The following
table shows valid collection and logging rates.
• The white area of the table shows rates recommended only for short-term use for
debugging a specific issue.
• The highlighted area of the table shows rates recommended for production processing.
1 2 3 4 5 6
8 9 10 12 15 16
18 20 24 25 30 36
40 45 48 50 60 72
75 80 90 100 120 144
150 180 200 225 240 300
360 400 450 600 720 900
1200 1800 3600
A practical log interval minimum during production processing is 60 seconds.

Intermediate log intervals, such as 120 seconds or 300 seconds can also be used. The
default rate is 600 seconds.
For the following tables, the recommended log rate is the default (600 seconds):
• ResUsageSpma table
• ResUsageShst table (preferably in Summary Mode) and depending on your system
• ResUsageSvpr table (only in Summary Mode)
If the system becomes very busy, it will automatically double the logging period. This
effectively summarizes the data by providing values for a time period twice that of the
previous logging period. The system automatically returns to logging back to the rate you
set when it is no longer busy.
2 The collection and logging rates that support the resource usage macro that you want to
run must both be greater than zero.
For example, if you want to set the RSS Collection rate to 100, then the logging rate of the
node/vproc could be 100 or any legal multiple as listed in the previous chart (for example,
the next value in the series not listed is 500, which is not legal).
If the collection and logging rates that you enter do not comply with these rules, the
system displays a diagnostic error message, but does not update the rates. The message
suggests rates that do comply with these rules and are close to those you entered.
Note: Node and Vproc logging rates must be integer multiples of the RSS Collection Rate.
Rates and enabled tables may be changed at any time and the changes take effect
immediately.

Using Summary Mode
Using Summary Mode

Summary Mode is one method for improving system performance. It reduces database I/O by
consolidating and summarizing data on each node on the system. Because Summary Mode
reduces the availability of detail, you can log normally to tables in which greater detail is
needed. Activate Summary Mode individually for the tables in which great detail is not
needed.
To enable Summary Mode, see “Enabling RSS Logging” on page 33.
Note: At the moment when the mode is changed from normal operations to Summary Mode,
one log interval is skipped over, that is, not logged.
For more information on Summary Mode, see “Summary Mode in Resource Usage Tables” on
page 51.
Using Active Row Filter Mode

Active Row Filter Mode is another method for improving system performance. It limits the
data rows that are logged to the database. For the tables for which this option is enabled, only
those rows whose data has been modified during the current logging period will be logged.
To enable Active Row Filter Mode, see “Enabling RSS Logging” on page 33.
When Active Row Filter Mode is enabled on a table, it may appear that rows are missing when
looking at SQL data queries. This is because the index values of the inactive rows varies over
time so that a row with one index may be logged one period but not in another. To determine
if rows are not being logged to the database, you should look in the event logs for messages
indicating that rows have been lost.
For more information about Active Row Filter Mode, see “Using ctl and xctl” on page 33.
Note: The current implementation of active row filtering is available only on the ResUsageSps
table. For details, see the Active field in Chapter 11: “ResUsageSps Table.”
Optimizing Resource Usage Logging
The Cost of Logging

Logging resource usage data to database tables incurs costs:
• Writing to the database adds to the system I/O load. On a heavily loaded system, this could
affect the production workload throughput.
• The rows written to the database take up space. If this space is never reclaimed, it will
eventually grow to consume all available space in user DBC.
• In an extremely loaded system, it is possible that the RSS can fall behind in writing data to
the database. Although it caches such data and will eventually catch up if given a chance,

the RSS will be forced to start discarding rows if the system load persists for many hours
and its cache capacity has been exceeded.
Logging Cost Contributors

Logging costs are difficult to quantify. They depend on a number of interrelated factors:
• How busy is the system
• Which resource usage tables are enabled
• What resource usage logging rates are in effect
• The system configuration (vproc, CPU, host driver, logical devices or device controllers)
Operational Methods
Use the following methods to optimize performance and reduce the cost of resource usage
logging on your system:
1 Use Summary Mode to reduce the number of rows inserted into the resource usage tables
if Summary Mode data provides sufficient information for your needs.
Note: If resource usage logging terminates due to a lack of table space:
a Delete rows from the appropriate table or make more space for it in USER DBC.
b Restart resource usage logging by entering the appropriate SET RESOURCE
command.
2 For tables with a large number of rows (for example, ResUsageSps), use Active Row Filter
Mode to limit the number of rows written to the database each logging period and to
minimize the amount of system resources used.
3 Avoid unnecessarily using or exhausting available disk space by doing the following:
Never enable logging on tables that you do not intend to use.
For example, logging only to the ResUsageSpma table provides a lot of useful information
with a minimal operational load on the system.
4 Use the largest rates that provide enough detail information for your purposes.
Note: Do not use small logging rates.
Generally, you should use a logging rate no smaller than 60. The default rate is 600.
If logging is enabled on all the resource usage tables, use logging rates no smaller than 300.
These values can be adjusted any time, regardless of whether the database system is busy.
New values take effect as soon as the adjustment command is issued. (In the case of xctl,
this is the WRITE command.)
5 Purge old data from the ResUsage tables periodically.

Related Topics
For instructions on ... See ...
enabling resource usage tables, setting “Enabling RSS Logging” on page 33.
collection and logging rates, and
summarizing and/or filtering rows
purging old data from ResUsage tables “Purging Data” on page 43.


CHAPTER 3 Resource Usage Procedures
This chapter describes the following resource usage macro topics:

• Enabling RSS logging
• General macro input format
• Executing macros (syntax)
• Enabling and disabling LOGONS and the affects on resource usage logging
• Purging old data
Enabling RSS Logging

You can enable tables, set collection and logging rates, and optionally summarize and/or filter
rows by using one of the following interfaces:
If running ... You can enable logging by running ... For instructions, see ...
Windows or Linux the ctl utility from the Teradata “Using ctl and xctl” on page 33.
Command Prompt or open the Control
GDO Editor (CTL) window in Teradata
MultiTool.
MP-RAS the xctl utility in non-windowing or “Using ctl and xctl” on page 33.
windowing mode from the command
line.
MP-RAS, Windows, or Linux Database Window (DBW). “Using Database Window” on page 35.
Before you set the ResUsage tables, determine which tables and controlling rates apply to the
resource usage macros you want to run. For more information, see the following topics:
• “Enabling ResUsage Tables” on page 23.
• “Setting Collection and Logging Rates” on page 26.
Using ctl and xctl

The Control GDO Editor utilities (ctl on Windows, and xctl on MP-RAS) are used to set
various Teradata Database configuration settings. The RSS-related settings are presented on
the RSS screen of these utilities. For detailed information on starting these utilities and
modifying the settings, see the ctl and xctl chapters in Utilities.

Chapter 3: Resource Usage Procedures
The following table describes the RSS settings that can be changed with ctl and xctl.
Setting Description
RSS Collection Rate The interval (in seconds) between collecting per-node
and per-vproc statistics.
The default is 600.
Node Logging Rate The interval (in seconds) between writing per-node
statistics to the database. It must be an integer multiple of
the RSS Collection Rate.
The default is 600.
Vproc Logging Rate The interval (in seconds) between writing per-vproc
statistics to the database. It must be an integer multiple of
the RSS Collection Rate.
The default is 600.
RSS Table Logging Enable Controls whether logging is enabled to the various
ResUsage tables.
Note: For logging to occur, the RSS Collection Rate must
be set to a non-zero value, and Node Logging and Vproc
Logging rates must be set to integer multiples of the RSS
Collection Rate.
Only the SPMA table has logging enabled by default.
Because writing rows to the ResUsage tables uses system
resources, Teradata recommends that you leave logging to
the other tables disabled until a specific need requires
these statistics.
RSS Summary Mode Enable When logging is enabled for certain ResUsage tables,
multiple rows of resource usage data are written during
each logging period. Summary mode reduces the amount
of data collected per logging period by causing the RSS to
store a single summary row per type per node, instead of
one row per logging entity.
For example, if regular logging is enabled for the SCPU
table, separate rows storing statistics for every CPU are
written during each logging period. If summary mode is
enabled, only a single row is written for each node,
regardless of the number of CPUs in that node. The single
row includes summary data for all node CPUs.
Similarly, if regular logging is enabled for the SVPR table,
separate rows are written for every individual vproc. If
summary mode is enabled for this table, one row is
written for each vproc type (AMP, PE, and others).
Note: RSS Summary Mode is effective for a table only if
RSS Table Logging is also enabled.

Setting Description
RSS Active Row Filter Mode Enable Active Row Filter Mode limits the data rows that are
logged to the database. For the tables for which this
option is on, only those rows whose data has been
modified during the current logging period will be
logged.
For the SPS table, there are a large number of possible
rows, and most of them are not used at any one time.
Logging the inactive rows would waste a large amount of
resources, so it is highly recommended that Active Row
Filter Mode remain enabled for this table.
For tables that have both active row filter mode and
summary mode enabled, the active row filtering is applied
after the summarization. For data fields that have
persistent data across logging periods, the summarized
rows may combine the data from both active and inactive
rows. In these cases, the active row filtering reports
summarized rows that have at least one active row
contribution.
Note: RSS Active Row Filter Mode is effective for a table
only if RSS Table Logging is also enabled.
Using Database Window

Use the database commands below to enable resource usage tables and set collection and
logging rates from DBW on MP-RAS, Windows, or Linux.
For instructions on starting the Database Window, see Graphical User Interfaces: Database
Window and Teradata MultiTool.
To enable RSS logging from Database Window

1 Open the Supvr window.
2 Set logging on the specified ResUsage table using the following database command:
SET LOGTABLE tablename ON

ALL OFF FE0CA030
where tablename is the name of the table.

3 Set the RSS Collection Rate using the following database command:
SET RESOURCE COLLECTION number

COLL
1099B001
where number is the number of seconds.

4 Set the logging rates using the following database command:

SET RESOURCE LOGGING number
VPROC LOG
1099B002
NODE
where number is the number of seconds.

Note: The Node and Vproc logging rates must be integer multiples of the RSS Collection
Rate. A rate of zero disables the collection or associated logging function.
5 Specify the table you want to enable logging to using the following database command:
SET LOGTABLE tablename ON

ALL OFF FE0CA030
After the table is enabled for logging, you can log rows in Summary Mode, enable active
row filtering, or both.
To determine whether to enable Summary Mode or active row filtering, see the following
topics:
• “Using Summary Mode” on page 29
• “Using Active Row Filter Mode” on page 29
Note: In order to log rows in Summary Mode, the table specified must be enabled in both
the RSS Table Logging Enable group and in the RSS Summary Mode Enable group.
6 (Optional) Issue any of the following commands:
• Enable Summary Mode on the ResUsage table specified using the following database
command:
SET SUMLOGTABLE tablename ON
OFF
1095A010
• Enable active row filtering on the ResUsage table specified by using the following
database command:
SET ACTIVELOGTABLE tablename ON
ALL OFF
1095A008
Note: The current implementation of active row filtering is available only on

ResUsageSps. For more information about this table, see Chapter 11: “ResUsageSps
Table.”
Example
The following example shows you how to enable table logging and set the RSS collection and
logging rates using the database commands in DBW. Suppose you want to enable the
ResUsageShst table and set the collection and logging rates for 15 minutes (900 seconds). You
would enter the following:
set logtable shst on
set resource coll 900 vproc log 900

General Macro Input Format

As shown in the table below, there are four kinds of macros:
• Multiple-node
• One-node
• All-node
• ByGroup
For any given line in the following table, the macros on that line report the same statistics for
either multiple nodes, one node, all nodes, or group nodes as indicated.
Description Multinode Macro One-Node Macro All-Node Macro ByGroup Macro
AWTs in use by ResAWTByAMP ResAWT

node ResAWTByNode
CPU usage by ResCPUByAMP ResCPUByAMPOneNode ResAmpCpuByGroup

AMP Vprocs
CPU usage by ResCPUByPE ResCPUByPEOneNode ResPeCpuByGroup

PE Vprocs
CPU usage by ResCPUByNode ResCPUOneNode ResCpuByGroup

nodes
Host statistics ResHostOneNode ResHostByLink ResHostByGroup
Ldv disk ResLdvByNode ResLdvOneNode ResLdvByGroup

statistics
Memory ResMemMgmtByNode ResMemMgmtOneNode ResMemByGroup

management
General network ResNetByNode ResNetOneNode ResNetByGroup

statistics
General node- ResNodeByNode ResOneNode ResNode ResNodeByGroup

level statistics
Priority ResPsByNode ResPsWDJoin ResPsByGroup

Scheduler and ResPsByNodeWDJoin
Teradata ASM
Workload
statistics
Vdisk statistics ResVdskByNode ResVdskOneNode ResVdskByGroup
Workload CPU ResPsCPUByNodeWDJoin ResPsCPUWDJoin

use versus the
relative weights
of their
associated
Allocation
Groups

Parameter Use for One-Node, Multiple-Node, All-Node, and Group Macros

The following table explains parameter use for one-node, multiple-node, all-node, and group
macros:
Macro Type Number of Parameters Node Parameters Used
Multiple node Six (except ResHostByLink) FromNode, ToNode
One node Five Node
All node Four None; this macro reports system-wide

statistics.
Group Four None; this macro reports statistics for

all nodes in the group.
For instructions on using these macros, see “Executing Macros” on page 39.
Using One-Node Macros

One-node macro versions are primarily used on single-node systems. Alternatively, you can
use the corresponding multiple-node macro to report on just one node by supplying equal
FromNode and ToNode parameters. One-node versions are recommended, however, because
they eliminate redundant report columns on a single-node system. Examples of redundant
columns are the NodeId column and columns that focus on cross-node load balancing.
“OneNode” macros have the same general input format as the other macros. The only
differences are that the single-node version of each macro has both of the following:
• OneNode qualifier in the macro name.
• A single node specification, instead of the FromNode and ToNode parameters to specify a
range of nodes. The default is ‘001-01’.
Using ByGroup Macros

ByGroup macro versions are used on systems with co-existing nodes. In Teradata Database,
co-existing nodes are nodes of different model types in the same configurations. Because of
the differences, the nodes may become bottlenecks in the throughput of the system as a whole.
Therefore, ByGroup macros were developed to provide the system user with a summary of the
performance data based on node groupings.
Note: The Database Administrator must identify the groupings of nodes when the system is
first configured.
ByGroup macros are similar to the other macros. The only difference is that they use the
GroupId column of the views in order to report system usage for a specific set of nodes
grouped by a GroupId. The input format of the ByGroup macros is the same as the other
macros except ByGroup appears as the qualifier in the macro name.

Executing Macros
Saving and Analyzing Data From Prior Releases

If you expect an ongoing need to retain and analyze data from prior releases, ask your System
Administrator to retain two sets of view and macro Data Definition Language (DDL) files in
separate places. Rename the views and macros so that you can use either.
You could, for example, use ResNodeOld as the name of the resource usage macro, and use it
when you want to analyze the data from that release.
Executing Macros
Function
Macro execution is illustrated in the following diagram. For details about each macro and its
resulting report, see Chapter 15: “Resource Usage Macros.”
EXECUTE MACRO Syntax

The execution of each resource usage macro has the following form. For information on
interpreting the syntax diagrams, see Appendix A: “How to Read Syntax Diagrams.”
EXECUTE MacroNameMultiNode ( , , A
EXEC FromDate ToDate
MacroNameAllNode ( , , B
FromDate ToDate
MacroNameOneNode ( , , C
FromDate ToDate
MacroNameByGroup ( , , D
FromDate ToDate
A , , , );
FromTime ToTime FromNode ToNode
B ,
FromTime ToTime
C , ,
FromTime ToTime Node
D , ,
FromTime ToTime
GX02B001
where:

Executing Macros
Syntax element Description
MacroNameMultiNode Name of a multinode resource usage macro:
• ResCPUByAMP • ResNodeByNode
• ResCPUByPE • ResPsByNode
• ResCPUByNode • ResVdskByNode
• ResLdvByNode
• ResMemMgmtByNode
• ResNetByNode
MacroNameAllNode Name of an all-node resource usage macro:
• ResNode • ResHostByLink
The ResHostByLink and ResNode macros do not use the FromNode and
ToNode parameters.
MacroNameByGroup Name of a ByGroup resource usage macro:
• ResAmpCpuByGroup • ResNodeByGroup
• ResCPUByGroup • ResPeCpuByGroup
• ResHostByGroup • ResPsByGroup
• ResLdvByGroup • ResVdskByGroup
• ResMemByGroup
• ResNetByGroup
FromDate Start date to report resource usage data.

The date may be entered either as a character string (for example,
character format for May 31, 2007 would appear as '2007-05-31') or as a
numeric value (for the same date in numeric format, 1070531). The
character string is the recommended format. The default is the current
system date.
See “String Date Validations” in SQL Reference: Data Manipulation
Statements for more detailed information on using numeric dates with
macros.
Note: The character string date format has been changed from yymmdd
to 'yyyy-mm-dd' to accommodate dates in the 21st century.
ToDate End date to report resource usage data.

See the FromDate syntax element column for a further explanation of
date formats.
The character string is the recommended format.
FromTime Start time to report resource usage data. The format is hhmmss. The
default is 000000.
ToTime End time to report resource usage data. The format is hhmmss. The
default is 999999.

Executing Macros
Syntax element Description
FromNode Starting range of nodes to report resource usage data. The format is
'nnn-nn'. A hyphen must be included in the fourth character position.
The default is '000-00'.
Note: To identify the node ID numbers for your system, type
get config in the DBW Supervisor Window (Supvr).
ToNode Ending range of nodes to report resource usage data. The format is 'nnn-
nn'. A hyphen must be included in the fourth character position. The
default is '999-99'.
Note: To identify the node ID numbers for your system, type
get config in the DBW Supervisor Window (Supvr).
Node Single-node ID to report resource usage data. The format is 'nnn-nn',

and hyphen must be included in the forth character position. For
example, 1-01 should be typed out as '001-01'. The default is '001-01'.
Example 1: Executing the ResCPUByAMP Macro

The following statement executes the ResCPUByAMP macro, producing a report for the
period beginning 8:00 a.m. on December 25, 2006 and ending 12:00 p.m., midnight, on
December 31, 2006. It includes data for nodes 123-02 through 125-04.
EXECUTE ResCPUByAmp('2006-12-25','2006-12-31', 080000, 240000,
'123-02','125-04');
where:
Statement Element Description
ResCPUByAMP Name of the resource usage macro
'2006-12-25' Starting date of December 25, 2006
'2006-12-31' Ending date of December 31, 2006
080000 Starting time of 8:00 a.m.
240000 Ending time of 12:00 midnight
'123-02' Starting node of a range of nodes
'125-04' Ending node of a range of nodes
See SQL Reference: Data Types and Literals for information on using numeric values for dates.

Executing Macros
Example 2: Executing the ResCPUByAMPOneNode Macro

The following statement executes the OneNode version of the ResCPUByAMP macro shown
in Example 1. It uses the same starting and ending dates and times (using character string
format), except the report is for a single node, node 123-02.
EXECUTE ResCpuByAmpOneNode ('2006-12-25','2006-12-31',080000,
240000,'123-02');
where:
ResCPUByAMPOneNode Name of the resource usage macro
'123-02' Node
Example 3: Executing the ResAMPCpuByGroup Macro

The following statement executes the ByGroup version of the ResCPUByAmp macro shown in
Example 1. It uses the same starting and ending dates and times (using character string
format), except the report is for a node grouping.
EXECUTE ResAMPCpuByGroup ('2006-12-25','2006-12-31',080000,
240000);
where:
ResCPUByAMPByGroup Name of the resource usage macro

Using DISABLE LOGONS To Stop Logging
Using DISABLE LOGONS To Stop Logging

The DISABLE LOGONS command prevents new sessions from logging on. When logons are
disabled, resource usage data stops logging to the tables even if there are still active sessions
logged on. (DISABLE ALL LOGONS prevents all users, including user DBC, from logging on
and also stops logging to the tables.)
To enable logons, run ENABLE LOGONS or ENABLE ALL LOGONS from:
• Database Window
• xctl windowing or non-windowing mode
• ctl utility or the Control GDO Editor (CTL) window in Teradata MultiTool
For more information on enabling and disabling logons, see “Changing Logon States and
Restarting the System” in Database Administration.
Purging Data
The RSS does not automatically delete data from the resource usage tables. You need to purge
old data regularly, especially when system activity is low.
You can use the System Maintenance application from the Production Control Menu of
Teradata Manager to clean out old resource usage data. For more information on System
Maintenance, see Teradata Manager User Guide.
You can also directly remove old resource usage data by submitting SQL statements. For
example, use the following SQL statement to remove data more than five days old from the
ResUsageSpma table:
DELETE FROM ResUsageSpma WHERE TheDate < CURRENT_DATE - 5;
For more information about the DELETE syntax, see “SQL Data Manipulation Language
Statement Syntax” in SQL Reference: Data Manipulation Statements.

Purging Data

CHAPTER 4 Resource Usage Tables
This chapter describes the following topics:

• Physical table naming conventions
• Working with ResUsage tables
• Data content of tables
• Summary Mode in resource usage tables
Physical Table Naming Conventions

Each physical ResUsage table name follows this general naming convention:
ResUsage Information_type Table_name
where:
Element Is one of the following...
Information_type
Code Description
S System-wide information
I Internal Teradata Database information
Table_name
Code Description
pma Node information
vpr vproc information
cpu CPU-specific information
ldv Logical device statistics
vdsk vdisk logical device statistics
awt AWT statistics

sps data-specific to the Priority Scheduler
hst Channel and LAN host information

Chapter 4: Resource Usage Tables
Working with ResUsage Tables
Working with ResUsage Tables
Relational Primary Index

All ResUsage tables have the same nonunique primary index:
• The nonunique primary index consists of TheDate, TheTime, and NodeID columns. This
allows the rows to be hashed to the same AMPs.
• The primary index is nonunique because of duplicate rows that will appear with the same
timestamp during daylight savings time. Rows that have duplicate timestamps can be
distinguished by the GMT Time column.
• Because the primary index is nonunique, all ResUsage tables are created as MULTISET
tables. This prevents the system from checking for duplicate rows.
For more information on MULTISET tables, see “CREATE TABLE (Table Kind Clause)” in
SQL Reference: Data Definition Statements or “Duplicate Rows in Tables” in SQL Reference:
Fundamentals.
Inserting Rows to Resource Usage Tables

For information on how rows will be inserted into these tables based on the current resource
usage control settings, see Chapter 2: “Planning Your Resource Usage Data.” For information
on the number of rows inserted in a resource usage table for each applicable log period, refer
to “Using Summary Mode” on page 29.
Occasional Event Data

Occasional event data is considered outside the scope of resource usage and is, therefore,
logged in the ERRORLOG and the DBCINFO tables rather than in the resource usage tables.
Data Content of Tables

The following sections contain specifications for all columns of the logical tables. The actual
table definitions are obtainable by executing the SHOW TABLE statement. See SQL Reference:
Data Manipulation Statements for more information about SHOW TABLE.
Column Descriptions
All columns described in the following chapters and appendices are type FLOAT unless
otherwise specified in the description of that column. All nonexistent values are stored with
the NULL value.

Each column listed for each table, includes the:

• Column Name
• Column Description
• Gathering Method
• Invalid Platform
About the "Invalid Platform" Column

The tables in this book that describe the resource usage tables contain an “Invalid Platform”
column. The following table explains the contents of that column:
In the “Invalid Platform” column … Means …
ALL do not use on any platform. The column is not valid on all
the platforms.
WINDOWS column is only valid on MP-RAS and Linux. It is not valid

on Microsoft Windows.
WINDOWS AND LINUX column is only valid on MP-RAS. It is not valid on

Windows or Linux.
MP-RAS column is only valid on Windows and Linux. It is not valid

on MP-RAS.
When the “Invalid Platform” column is blank, the column being described is valid on all
platforms.
About the "Gather Method" Column

Likewise, the “Gather Method” column should be interpreted as follows:
This Gather Method … Means...
track (tracked) current value of countable item, such as queue lengths during
specified logging period.
count (counted) number of times event, such as disk reads that occurred during
specified logging period.
tmon (time-monitored) the time a resource, such as processor time, was in use in units
of centiseconds.
Column Names Ending In “Sum”

Column values ending in “Sum” are useful for calculating the average value for a collection
period. Each sum column accumulates the values measured by the column at the end of every
collection period. Divide the resulting logged value by the value “CollectIntervals” to get the

average value. Since the CollectIntervals is the number of collection periods per logging
period, the resulting number is the average value per logging period.
Column Names Ending In “Max”

The column names ending in “Max,” as in ScntlReadRespMax, report the maximum value
during each logging period.
Column Categories
The following chapters describe the ResUsage tables by detailing the column information in a
table format. These tables contain three categories: main column type, category, and
subcategory.
These columns appear as follows:
Column Name Gather Description Data Type Invalid Platform

Method
MAIN COLUMN TYPE
CATEGORY
Subcategory
Note that the row containing the main column type is shaded and its heading is written in all
uppercase letters. The category heading is not shaded, but is still written in all uppercase
letters.
There are two kinds of main column types:
• Housekeeping columns - contain statistics on timestamp, current logging characteristics,
collection elements and its general characteristics.
• Statistics columns - can be further categorized into subcategories. Categories and
subcategories may vary from table to table.
The following table shows the Statistics columns subdivided into their respective
subcategories. Subcategories are not necessarily applicable to all tables. For example, the Host
Controller category only applies to the ResUsageShst table.

Statistics Column
Category Subcategories Description
File System • Cylinder Management Some of the file system columns can be viewed as a
• Cylinder Management Overhead subset of memory columns by expanding on the
Events operations performed on disk memory segments.
Operations counted are logical memory and
• Data Block Prefetches
physical disk reads and writes (including aging) and
• Data Segment Lock Requests locking control activities. Other columns identify
• Segments Acquired the purpose of operations being performed on disk
• Segments Released segments such as cylinder migration or data
updates; or identify the requests being made by
• Synchronized Full File Scans
database software on the file system. The WAL
• Write Ahead Logging (WAL) columns identify the log-based file system recovery
scheme in which modifications to permanent data
are written to a log file, the WAL log.
General Concurrency Database Locks Identification of concurrency control activities is

Control provided and subdivided into control done for user
level processing, system overhead processing, and
database locks. It does not include control specific
to disk, memory or net concurrency control, which
are included in the disk, memory or net columns.
Host Controller (SHST) • Channel Traffic These columns identify traffic on the host-to-node
• Channel Management channels and LANs. Some also give overhead and
management information on the host channel and
• Controller Overhead
LAN.
• User Commands
• User Command Arrival and
Departure
Memory • Memory Allocations Memory related events, subdivided into memory

• Memory Availability Management types, are collected for memory allocation and
deallocation, logical memory and physical disk
• Memory Pages Resident
reads and writes (including paging and swapping),
• Memory Resident access, deaccess and memory control. Memory
• Paging management columns are also provided to identify
• Swapping events leading up to paging, swapping and aging
activities. Finally, a detailed snapshot of the memory
• Task Context Segment Usage is provided by tracking the current states per
memory types.
Logical Device • Concurrent Operations These columns identify individual logical device
• Input and Output Traffic activities for external storage components
connected through the buses.
• Outstanding Requests
• Response Time The SCSI statistics are calculated only on what can
be derived from statistics collected by the operating
• Seek Statistics system, since the disk array controllers do not
provide us with any useful data for resource usage.

Statistics Column
Category Subcategories Description
Net • Broadcast Net Traffic Traffic over the BYNET is identified through the
• Group Coordination number and direction of messages, subdivided into
the type of transmission, as well as physical
• Merge Services
utilization of the BYNET. Logical messages and
• Net Controller Status and direction are identified through subdivisions of the
Miscellaneous Management message class. Controller overhead, channel
• Net Circuit Management utilization, and Teradata Net contention are
• Network Transport identified as well.
• Per-Bynet Network Transport Data
• Point-to-point Net Traffic
• Work Mailbox Queue
Process Scheduling • ChnSignal Status Tracking These columns provide a CPU-level snapshot of
• CPU Utilization work started, with current characteristics and states.
Expanded detail is provided for work started but
• Cylinder Read
waiting on resources. This helps identify the ability
• Process Allocation or inability of the system to effectively utilize
• Process Block Counts resources. Time allotments are tracked by
• Process Pending Snapshot monitoring the time spent waiting for resources or
processing code. These columns also track the
• Process Pending Wait Time number of times processing was switched to another
• Scheduled CPU Switching process for multitasking purposes or to perform
interrupt services.
User Commands • User command These columns describe the types of commands
• User command Arrival and given to Teradata Database by the user and the
Departure progress of those commands.
Secondary Cache None. These columns identify the secondary cache miss
rate.
Spare None. These columns are for future release or internal

manipulation by developers.
Teradata Active System • AMP Worker Tasks These columns collect and report statistics about the
Management • In use and Max Array Data AMP Worker Tasks (AWTs) and Priority Scheduler.
(Teradata ASM) The columns specific to the ResUsageSawt table also
• Priority Scheduler
report the number of AWTs currently in use and the
maximum number of AWTs for the current vproc
on the node.
Note: The following column category and subcategories are not currently used.
[Unused] • Allocation These columns identify individual pdisk and vdisk

• Input and Output logical device activities.
• Migration
• Node Agent

Summary Mode in Resource Usage Tables

The following table describes Summary Mode for the resource usage tables. Summary Mode is
applicable to all tables except ResUsageSpma and ResUsageIpma. If the information for a row
of a table is in Summary Mode, the SummaryFlag value is set to ‘S’. If the row is being logged
normally, the SummaryFlag value is set to ‘N’.
The Table… contains resource usage data… and the following information when Summary Mode is active…
Node ResUsage Table Group
ResUsageIpma for available system-wide, node Summary Mode not applicable to this table.
information
ResUsageSpma for available system-wide, node Summary Mode not applicable to this table.
information
ResUsageScpu specific to the CPUs within the one row is written to the database for each node in the system,
nodes. summarizing the CPUs on that node, for each log interval.
• The value in CPUId is 0.
• The value in Secs is the sum of the Secs values for all the
CPUs.
For details, see Chapter 5: “ResUsageScpu Table.”
Vproc ResUsage Table Group
ResUsageSawt specific to the AWTs. one row is written to the database for each node in the system,
summarizing all AWTs per node, for each log interval.
For details, see Chapter 7: “ResUsageSawt Table.”
ResUsageShst specific to the host channels and one row is written to the database for each type of host
LANs communicating with (network or channel-connected) on each node in the system,
Teradata Database. summarizing the hosts of that type on that node, for each log
interval.
• The value in HstId is 0.
• The value in HstType ends with the character ‘S’ for
“summary.” This is the indication that a row is a
summarization row.
hosts this row represents.
For details, see Chapter 8: “ResUsageShst Table.”

The Table… contains resource usage data… and the following information when Summary Mode is active…
ResUsageSldv specific to each logical device two rows are written to the database: one summarizing the
interfaced through the SCSI bus. system logical devices and one summarizing the Teradata
Database logical devices.
• The value in LdvId is 0.
• The value in LdvType ends with the character ‘S’ for
summarization row.
ldvs this row represents.
For details, Chapter 9: “ResUsageSldv Table.”
ResUsageSps by Performance Group ID from one row is written to the database for each Performance Group
the Priority Scheduler. ID in the system for each log interval.
For details, see Chapter 11: “ResUsageSps Table.”
ResUsageSvdsk specific to the vdisk logical one row is written to the database for each node in the system,
device. summarizing all AMP vdisk data in each node, for each log
interval.
For details, see Chapter 12: “ResUsageSvdsk Table.”
ResUsageSvpr specific to each virtual processor one row per physical table is written to the database for each
and its file system. type of vproc on each node in the system, summarizing the
vprocs of that type on that node, for each log interval.
• The value in VprId is the vproc type code.
• The value in VprType ends with the character ‘S’ for
summarization row.
vprocs this row represents.
For details, see Chapter 13: “ResUsageSvpr Table.”

SECTION 1 Node Resource Usage Tables

Section 1: Node Resource Usage Tables

CHAPTER 5 ResUsageScpu Table
This resource usage table contains resource usage information specific to the CPUs within the
nodes. Table ResUsageScpu includes resource usage data for available system-wide,
CPU information.
Note: This table is created as a MULTISET table. For more information see “Relational
Primary Index” on page 46.
The Invalid Platform column is a little counterintuitive. If your platform appears in that
column, then resource usage data for that particular column is either not collected or not valid
and should not be used.
The following table describes the ResUsageScpu table columns.
Gather Invalid
Column Name Method Description Data Type Platform
HOUSEKEEPING COLUMNS
RELATIONAL PRIMARY INDEX COLUMNS

These columns taken together form the nonunique primary index.
TheDate n/a Date of the log entry. DATE
TheTime n/a Nominal time of the log entry. FLOAT

Note: Under conditions of heavy system load,
entries may be logged “late” (typically, by no more
than one or two seconds), but this field will still
contain the time value when the entry should have
been logged. See the Secs and NominalSecs
columns.
NodeId n/a Identifies the Node upon which the vproc resides. INTEGER
The Node ID is formatted as CCC-MM, where CCC
denotes the three-digit cabinet number and MM
denotes the two-digit chassis number of the node.
For example, a node in chassis 9 of cabinet 3 has a
node ID of ‘003-09’.
Note: Symmetric Multi-Processing (SMP) nodes
have a chassis and cabinet number of 1. For
example, the node ID of an SMP node is ‘001-01’.

Chapter 5: ResUsageScpu Table
Gather Invalid
MISCELLANEOUS HOUSEKEEPING COLUMNS
Gmt Time n/a Greenwich Mean Time is not affected by the FLOAT
Daylight Savings Time adjustments that occur twice
a year.
NodeType n/a Type of node, representing the per node system CHAR(4)
family type. For example, “5380,” “5400,” “5450,”
etc.
CPUId n/a Identifies the CPU within this node. The values are SMALLINT
0 through NCPUs-1.
Secs n/a Actual number of seconds in the log period SMALLINT

represented by this row. Normally the same as
NominalSecs, but can be different in three cases:
• The first interval after a log rate change
• A sample logged “late” because of load on the
system
• System clock adjustments affect reported “Secs”
Useful for normalizing the “count” statistics
contained in this row, for example, to a
“per-second” measurement.
CentiSecs n/a Number of centiseconds in the logging period. This INTEGER

field is useful when performing data calculations
with small elapsed times where the difference
between centisecond-based data and whole seconds
results in a percentage error.
NominalSecs n/a A specified or nominal number of seconds in the SMALLINT

logging period.
SummaryFlag n/a Identifies the summarization status of this row. CHAR

Possible values are ‘N’ if the row is a non-summary
row, and ‘S if the row is a summary row.

Gather Invalid
Active n/a Controls whether or not the rows will be logged to BYTE
the ResUsage tables if Active Row Filter Mode is
enabled.
If Active is set to:
• a non-zero value, then the row contains
modified data columns.
• a zero value, then none of the data columns in
the row have been updated during the logging
period.
For example, if Active Row Filter Mode is enabled,
then the rows that have a zero Active field value will
not be logged to the ResUsage tables.
Note: For the current release, data collection for the
ResUsageScpu table results in a non-zero value for
all rows under all conditions. Therefore, Active Row
Filter Mode is not in effect for this table.
CollectIntervals n/a Number of collect intervals during each log interval. SMALLINT
In the collect buffer, the value is always 1. In the log
buffer or the database table, the value is the ratio of
log interval to collect interval.
STATISTICS COLUMNS
PROCESS SCHEDULING COLUMNS
CPU Utilization Columns

Count all CPU activities, including activities performed for virtual processors, subdivided into the following columns:
1 CPUIdle - Idle time
2 CPUIoWait - Idle and waiting for I/O completion
3 CPUUServ - User service
4 CPUUExec - User execution
These statistics are aggregates representing all CPUs on the node. To normalize to a per-CPU average, divide by the number
of CPUs (the value in NCPUs column). CPU utilization by user code is further subdivided by the vproc tables.
Note:
• CPU idle time = CPUIdle + CPUIoWait
• CPU busy time = CPUUServ + CPUUExec
Theoretically, the values of these four columns, for any given interval, account for total CPU time on the node. That is, they
should total to 100 * Secs * number of CPUs on the node, since each CPU is always in exactly one of these four states. In
practice, there is occasionally a very small plus or minus difference from this theoretical total.

Summary Mode
Gather Invalid
CPUIdle tmon Time in centiseconds the CPU is idle and not FLOAT
waiting for I/O.
CPUIoWait tmon Time in centiseconds CPU is waiting for I/O FLOAT WINDOWS
completion
Note: This represents another variety of Idle, since
the CPU is only recorded as being in this state if
there are no processes eligible for execution. This is
because if there were any such process, the CPU
would be immediately dispatched for that process.
CPUUServ tmon Time in centiseconds CPU is busy executing user FLOAT

service code, that is, privileged work performing
system services on behalf of user execution
processes which do not have root access.
CPUUExec tmon Time in centiseconds CPU is busy executing user FLOAT

execution code, that is, time spent in a user state on
behalf of a process.
Scheduled CPU Switching Columns

Identify the number of times the CPU was switched by the scheduler from doing one type of work to another type of work.
CPUProcSwitches count Number of times the scheduler switched the CPUs FLOAT WINDOWS
currently active process to a new process. LINUX
CPUProcSameSwitches count Number of CPUProcSwitches where a process FLOAT WINDOWS

replaced itself, that is, the new process was the same LINUX
as the old process.
Summary Mode
When Summary Mode is active for tables in this group, one row is written to the database for
each node, summarizing all CPUs per node, for each log interval.
You can determine if a row is in Summary Mode by checking the SummaryFlag column for
that row:
IF the SummaryFlag column value is… THEN the data for that row is being logged…
‘S’ in Summary Mode.
‘N’ normally.

Spare Columns
Spare Columns
The ResUsageScpu table has six spare columns: two count, two track, and two tmonitored
columns as shown in the following table.
Gather
Column Name Method Description
SpareCount[i] count Spare counted statistic.
SpareTrack[i] track Spare tracked statistic.
SpareTmon[i] tmon Spare tmonitored statistic.
where [i] is expanded to values 00 - 01, for example, SpareCount00 or SpareTrack01.

Spare Columns

CHAPTER 6 ResUsageSpma Table
The ResUsageSpma table includes resource usage data for available system-wide, node
information. Together with the ResUsageIpma table, ResUsageSpma is part of the “Node
ResUsage table group.”
The ResUsageIpma table is described in Appendix B: “ResUsageIpma Table.”
Note: Summary Mode is not applicable to this table.
This table is created as a MULTISET table. For more information see “Relational Primary
Index” on page 46.
The Invalid Platform column is a little counterintuitive. If your platform appears in that
column, then resource usage data for that particular column is either not collected or not valid
and should not be used.
The following table describes the ResUsageSpma table columns.
Gather Invalid


entries may be logged “late” (typically, by no
more than one or two seconds), but this field will
still contain the time when the entry should have
columns.
NodeId n/a Identifies the Node upon which the vproc INTEGER
resides. The Node ID is formatted as CCC-MM,
where CCC denotes the three-digit cabinet
number and MM denotes the two-digit chassis
number of the node. For example, a node in
chassis 9 of cabinet 3 has a node ID of ‘003-09’.
Note: SMP nodes have a chassis and cabinet
number of 1. For example, the node ID of an
SMP node is
‘001-01’.

Chapter 6: ResUsageSpma Table
Gather Invalid

These columns provide a generalized picture of the vprocs running on this node, shown as “Type n virtual processors”
where n = 1 to 7. Under the current implementation, only Type 1 (AMP), Type 2 (PE), Type 3 (GTW), Type 4 (RSG) vprocs
exist; vproc types 6 through 7 are not currently used.
GMT Time n/a Greenwich Mean Time is not affected by the FLOAT
Daylight Savings Time adjustments that occur
twice a year.
etc.
NCPUs n/a Number of CPUs on this node. SMALLINT
Vproc1 n/a Current count of type 1 (AMP) virtual SMALLINT

processors running under the node.
VprocType1 n/a Type of virtual processor for Vproc1. Value is CHAR(4)

always “AMP.”
Vproc2 n/a Current count of type 2 (PE) virtual processors SMALLINT

running under the node.

always “PE.”
Vproc3 n/a Current count of type 3 (GTW) virtual SMALLINT


always “GTW.”
Vproc4 n/a Current count of type 4 (RSG) virtual processors SMALLINT


always “RSG.”
Vproc5 n/a Note: This field is not currently used. SMALLINT ALL
VprocType5 n/a Note: This field is not currently used. CHAR(4) ALL
Vproc6 n/a Current count of type 6 virtual processors SMALLINT ALL

VprocType6 n/a Type of virtual processor for Vproc6. CHAR(4) ALL

MemSize n/a Amount of memory on this node in megabytes. INTEGER

Useful for performing memory usage
calculations.

Gather Invalid
NodeNormFactor n/a A per node normalization factor that is used to INTEGER

normalize the reported CPU values of the
ResUsageSpma table.
This value is scaled by a factor of 100. For
example, if the actual factor is 5.25, then the
value of the NodeNormFactor will be 525.

system
• System clock adjustments affect reported
“Secs”
CentiSecs n/a Number of centiseconds in the logging period. INTEGER

This field is useful when performing data
calculations with small elapsed times where the
difference between centisecond-based data and
whole seconds results in a percentage error.

logging period.
CollectIntervals n/a Number of collect intervals during each log SMALLINT

interval. In the collect buffer, the value is always
1. In the log buffer or the database table, the
value is the ratio of log interval to collect
interval.
You can determine average values per collection
period by dividing a column value ending in
“Sum” by CollectIntervals. For example, to find
the average number of processes running the
CPU for a collect interval, divide
ProcRunningSum by CollectIntervals.
Active n/a Gets set to a non-zero value whenever one of the FLOAT
other data columns in the row is set.
NetSamples n/a Sample count for sampled (tmon and aggsam) FLOAT
statistics for a Bynet.
Note: NetSamples is used to normalize all net
tmon statistics to a percent-of-time basis. For
example, dividing (NetTxIdle/NetSamples)
yields the transmitter-idle time ratio for the net
statistics.

Gather Invalid
STATISTICS COLUMNS
Process Allocation Columns

Represent all currently allocated processes, subdivided into the possible process states of running, ready, blocked or
suspended.
ProcReadySum count Total number of processes ready and able to FLOAT WINDOWS
execute on CPUs when a CPU becomes available LINUX
during each log interval.
Note: To calculate the average number of
processes ready and able to execute, divide this
value by the CollectIntervals value. Since the
CollectIntervals is the number of collect periods
per logging period, the resulting number is the
average value per logging period.
ProcBlockedSum count Total number of processes blocked from FLOAT WINDOWS

execution until some event takes place during
each log interval.
processes blocked, divide this value by the
CollectIntervals value. Since the CollectIntervals
is the number of collect periods per logging
period, the resulting number is the average value
per logging period.
On Linux, the total number of threads blocked
waiting for I/O.
ProcSuspendedSum count Total number of process suspended from FLOAT WINDOWS

execution, awaiting another process to resume LINUX
them (during a log interval).
processes suspended, divide this value by the
per logging period.
ProcRunningSum count Total number of processes running (executing) FLOAT WINDOWS

on CPUs during each log interval.
processes running, divide this value by the
per collection period.
On Linux, the total number of runnable threads.

Gather Invalid
ProcReadyMax track Maximum number of processes ready and able FLOAT WINDOWS
to execute on CPUs when a CPU becomes LINUX
available during each log interval.
Process Pending Snapshot Columns

Identify how many processes are blocked for each possible reason. These columns total (minus ProcPendDBLock)
approximately ProcBlockedSum, since we can only be blocked on one blocking type at a time.
Note: In analyzing resource usage, a distinction should be made between the following two kinds of process blocks:
• Block involves a process that is logically idle, waiting to receive work on its primary mailbox, or for a timer to elapse. This
block does not affect throughput.
• Block involves a process that has work to do but is being prevented from proceeding by some circumstance like a segment
lock or flow control. This kind of block does affect throughput.
The first kind of block is represented by column ProcPendNetRead; the second kind is represented by the remaining
columns described here.
ProcPendMemAlloc track Number of processes blocked pending memory FLOAT ALL

allocations.
ProcPendFsgRead track Number of processes blocked pending a File FLOAT WINDOWS

Segment (FSG) read from disk. LINUX
ProcPendFsgWrite track Number of processes blocked pending an FSG FLOAT WINDOWS

write to disk. LINUX
ProcPendNetThrottle track Number of processes blocked pending delivery of FLOAT WINDOWS

outstanding outgoing messages. LINUX
ProcPendNetRead track Number of processes blocked pending non-step FLOAT

work, that is, the number of processes blocked
on any mailbox other than the ‘work’ mailbox.
Note: Non-step work is “anticipated” work the
process spawned off and is now waiting for some
type of response from the spawned process or
processes. Non-step work is not “unanticipated”
work such as a new work request sent when a
user initiates a request from the host.
ProcPendMonitor track Number of processes blocked pending a user FLOAT ALL

monitor.
ProcPendMonResume track Number of processes blocked pending a user FLOAT ALL

monitor resume from a yield.
ProcPendDBLock track Number of processes blocked pending database FLOAT MP-RAS

locks.
ProcPendSegLock track Number of processes blocked pending a task FLOAT WINDOWS

context (scratch, stack, etc.) segment lock. LINUX
ProcPendFsgLock track Number of processes blocked pending an FSG FLOAT WINDOWS

lock. LINUX

Gather Invalid
ProcPendMisc track Number of processes blocked pending FLOAT WINDOWS

miscellaneous events. LINUX
ProcPendQnl track Number of processes blocked pending a FLOAT WINDOWS

TSKQNL lock. LINUX
Process Block Counts Columns

Identify how many times a process became blocked on which blocking type. Average time blocked can be approximated by
dividing corresponding ProcWaitXxx by ProcBlksXxx.
ProcBlksMemAlloc count Number of process blocks for memory FLOAT WINDOWS

allocations. LINUX
ProcBlksQnl count Number of process blocks for a TSKQNL lock. FLOAT WINDOWS
LINUX
ProcBlksFsgRead count Number of process blocks for an FSG read from FLOAT WINDOWS
disk. LINUX
ProcBlksFsgWrite count Number of process blocks for an FSG write to FLOAT WINDOWS
disk. LINUX
ProcBlksNetThrottle count Number of process blocks for delivery of FLOAT WINDOWS

outstanding outgoing messages. LINUX
ProcBlksMsgRead count Number of process blocks for non-step work. FLOAT
ProcBlksMonitor count Number of process blocks for a user monitor. FLOAT ALL
ProcBlksMonResume count Number of process blocks for a user monitor FLOAT ALL
resume from a yield.
ProcBlksDBLock count Number of process blocks for database locks. FLOAT MP-RAS
The AWT can do other work while the lock is
blocked.
ProcBlksSegLock count Number of process blocks for a disk or task FLOAT WINDOWS
context (scratch, stack, etc.) segment lock. LINUX
ProcBlksFsgLock count Number of process blocks for an FSG lock. FLOAT WINDOWS
LINUX
ProcBlksTime count Number of process blocks waiting only for timer FLOAT WINDOWS
expiration. LINUX
ProcBlksMisc count Number of process blocks for miscellaneous FLOAT WINDOWS

events. LINUX
Process Pending Wait Time Columns

Identify how much time in centiseconds processes were in the blocked state for each possible reason.
Note: Since this time is only accounted for when a blocked process leaves the blocked state, it is possible for this statistic to
be much larger than the amount of time available to all processes in a single log period.
ProcWaitMemAlloc tmon Total time processes were blocked pending FLOAT WINDOWS
memory allocations. LINUX

Gather Invalid
ProcWaitPageRead tmon Total time processes were blocked pending a page FLOAT ALL
read from disk.
ProcWaitFsgRead tmon Total time processes were blocked pending an FLOAT WINDOWS
FSG read from disk. LINUX
ProcWaitFsgWrite tmon Total time processes were blocked pending an FLOAT WINDOWS
FSG write to disk. LINUX
ProcWaitNetThrottle tmon Total time processes were blocked pending FLOAT WINDOWS
delivery of outstanding outgoing messages. LINUX
ProcWaitMsgRead tmon Total time processes were blocked pending non- FLOAT
step work.
ProcWaitMonitor tmon Total time processes were blocked pending a user FLOAT ALL
monitor.
ProcWaitMonResume tmon Total time processes were blocked pending a user FLOAT ALL
monitor resume from a yield.
ProcWaitDBLock tmon Total time processes were blocked pending FLOAT ALL
database locks.
ProcWaitSegLock tmon Total time processes were blocked pending a disk FLOAT WINDOWS
or task context (scratch, stack, etc.) segment LINUX
lock.
ProcWaitFsgLock tmon Total time processes were blocked pending an FLOAT WINDOWS
FSG lock. LINUX
ProcWaitTime tmon Total time processes were blocked pending some FLOAT WINDOWS
amount of elapsed time only. LINUX
ProcWaitQnl tmon Total time processes were blocked pending a FLOAT WINDOWS
TSKQNL lock. LINUX
ProcWaitMisc tmon Total time processes were blocked pending FLOAT WINDOWS
miscellaneous events. LINUX

Gather Invalid

Count all CPU activities, including activities performed for virtual processors, subdivided into the following columns:
1 CPUIdle - Idle time
2 CPUIoWait - Idle and waiting for I/O completion
3 CPUUServ - User service
4 CPUUExec - User execution
5 CPUIdleNorm - Normalized idle time
6 CPUIOWaitNorm - Normalized idle and waiting for I/O completion
7 CPUUServNorm - Normalized user service
8 CPUExecNorm - Normalized user execution
These statistics are aggregates representing all CPUs on the node. To normalize a per-CPU average, divide by the number of
CPUs (the value in the NCPUs column). CPU utilization by user code is further subdivided by the vproc tables. Per-CPU
statistics are found in Chapter 5: “ResUsageScpu Table.”
Note:
• CPU idle time = CPUIdle + CPUIoWait
• CPU busy time = CPUUServ + CPUUExec
• CPUIdleNorm = (CPUIdle * NodeNormFactor)/100
• CPUIOWaitNorm = (CPUIOWait * NodeNormFactor)/100
• CPUUServNorm = (CPUUServ * NodeNormFactor)/ 100
• CPUUExecNorm = (CPUUExec * NodeNormFactor)/100
where the NodeNormFactor is the per node normalization factor. This is related to the NodeType value reported in this
resource usage table. The normalization factor modifies the reported CPU times to the equivalent time of a specified
virtual processor. This does not add up to the reported CPU time. The CPU time is calculated as follows:
CPUIdleNorm + CPUIOWaitNorm + CPUUServNorm + CPUUExecNorm = CentiSecs * NCPUs * NodeNormFactor
Theoretically, the values of these columns above, for any given interval, account for total CPU time on the node. That is,
since each CPU is always in exactly one of these states, they should total either:
• 100 * Secs * NCPUs
Or
• CentiSecs * NCPUs * NodeNormFactor
The CPU time returned in centiseconds is more accurate than those returned in seconds.
CPUIdle tmon Time in centiseconds CPUs are idle and not FLOAT
waiting for I/O.
CPUIoWait tmon Time in centiseconds CPUs are idle and waiting FLOAT WINDOWS
for I/O completion.
On Windows, the default value is always 0.
Note: This time represents another variety of
Idle, since a CPU is only in this state if there are
no processes eligible for execution. If there was a
process available, the CPU would be immediately
dispatched for that process.

Gather Invalid
CPUUServ tmon Time in centiseconds CPUs are busy executing FLOAT

user service code, that is, privileged work
performing system services on behalf of user
execution processes which do not have root
access.
CPUUExec tmon Time in centiseconds CPUs are busy executing FLOAT

user execution code, that is, time spent in a user
state on behalf of a process.
CPUIdleNorm tmon Time in centiseconds CPUs are idle and not FLOAT
waiting on I/O.
CPUIOWaitNorm tmon Time in centiseconds CPUs are idle and waiting FLOAT WINDOWS
for I/O completion.
On Windows, the default value is always 0.
CPUUServNorm tmon Time in centiseconds CPUs are busy executing FLOAT

user service code, that is, privileged work
performing system services on behalf of user
execution processes which do not have root
access.
CPUExecNorm tmon Time in centiseconds CPUs are busy executing FLOAT

user execution code; that is, time spent in a user
state on behalf of a process.
MEMORY COLUMNS
Memory Allocation Columns

Represent the number and amount of memory allocations, subdivided into (the only applicable) generic node memory type
and a summarization of vproc memory types.
MemTextAllocs count Number of successful memory allocations and FLOAT ALL

size-increasing memory alters for non-system
overhead text (code). Amount allocated can be
derived by multiplying the number of allocations
by the fixed page size.
MemVprAllocs count Number of successful memory allocations and FLOAT WINDOWS

size-increasing memory alters for all vproc LINUX
memory types, that is, disk segments and task
context types.
MemVprAllocKB count Total KBs attributed to allocations and size- FLOAT WINDOWS
increasing alters for vproc memory types.
On Linux, the number of KB of increased
nonshared memory.

Gather Invalid
Memory Pages Resident Columns

Represent the amount, in number of pages or KBs, of memory resident subdivided into memory types. Disk segment
memory types are described by the single entries below. Each of these expands into six columns, where [seg] is as follows:
• PDb = Permanent data block disk segments
• PCi =Permanent cylinder index disk segments
• SDb =Regular or restartable spool data block disk segments
• SCi = Regular or restartable spool cylinder index disk segments
• TJt = Transient journal table or WAL data block or WAL cylinder index
• APt = Append table or permanent journal table data block or cylinder index disk segments
MemTSysOhRes track Number of pages resident in memory for system FLOAT ALL
overhead text. System Overhead Text is wired
into memory upon startup and will not change.
MemDSysOhRes track Number of pages resident in memory for system FLOAT WINDOWS
overhead data. System Overhead Data is wired LINUX
into memory upon startup.
MemTextRes track Number of pages resident in memory for text. FLOAT ALL
MemCtxtRes track Number of pages resident in memory for task FLOAT WINDOWS
context segments. LINUX
Mem[seg]KBRes track Current KBs resident in memory for (non- FLOAT ALL
backup) disk segments.
MemFreeKB track KBs of free memory. This value should be equal FLOAT
to the size of memory minus the total amount
resident derived from adding all of the above
memory resident columns and frozen disk
segment resident column from ResUsageSvpr.
On Linux, the value reported is the approximate
amount of memory that is available for use. The
Linux operating system uses most free memory
for buffers and caching to improve performance,
but the operating system can reclaim that
memory if it is needed by programs.
The following formula is used by the RSS to
calculate this value:
MemFreeKB = MemFree + Buffers + Cached +
SwapCached - fsgavailpgs*kbperpage -
(active_slabs*pgsperslab*kbperpage)
where the value(s):
• MemFree, Buffers, Cached, and SwapCached
come from /proc/meminfo.
• fsgavailpgs come from the PDE FSG code.
• active_slabs and pgsperslab come from /proc/
slabinfo.

Gather Invalid
Memory Availability Management Columns

Represent overhead to managing memory when memory availability is a problem.
MemFails count Number of failures performing memory FLOAT WINDOWS

allocations and size-increasing memory alters for LINUX
vproc memory types as well as node memory
types.
MemAgings count Number of times memory was aged. FLOAT ALL
MemTextPageDrops count Number of non-system overhead text pages FLOAT WINDOWS

dropped from memory to make more physical LINUX
memory available.
MemTextPageReads count Number of non-system overhead text pages FLOAT MP-RAS

required to be read from disk when it was
previously paged out.
On Linux, the number of 4KB pages paged
minus the pages swapped in.
MemProcSwapped track Current count of processes whose stack has been FLOAT WINDOWS
written to disk to make available more physical LINUX
memory. This value is less than, or equal to, total
processes allocated.
MemCtxtPageWrites count Number of task context (scratch, stack, etc.) FLOAT MP-RAS
pages that were paged out.
On Linux, the number of 4KB pages swapped
out.
MemCtxtPageReads count Number of task context (scratch, stack, etc.) FLOAT MP-RAS
pages that were paged in.
On Linux, the number of 4KB pages swapped in.
MemSwapDrops count Number of disk segments that were dropped FLOAT ALL
from memory because all its ancestor processes
were swapped out.
MemSwapDropKB count KBs dropped from memory by MemSwapDrops. FLOAT ALL
MemSwapReads count Number of disk segments that were re-read when FLOAT ALL
they were previously dropped from memory
because all its ancestor processes were swapped
out.
MemSwapReadKB count KBs re-read from memory by MemSwapReads. FLOAT ALL

Gather Invalid
NET COLUMNS
Note: Counshft data type is similar to count except that the data is gathered in units of some power of two and then shifted
by the number of bits necessary to convert it to some other unit. For example, data for MsgPtPReadKB is collected in 16-
byte units and then shifted right by 6 bits, converting the value to KBs.
Point-to-Point Net Traffic Columns

Identify the number (Reads, Writes) and amount (ReadKB, WriteKB) of input and output messages passing through the
Teradata Database nets through point-to-point (1:1) methods (PtP). It excludes TCP/IP traffic.
MsgPtPReads count Number of net point-to-point messages input to FLOAT

processes on the node via the message
subsystem.
MsgPtPWrites count Number of net point-to-point messages output FLOAT

from processes on the node via the message
subsystem.
MsgPtPReadKB countshft Total KBs of net point-to-point messages input FLOAT

to processes on the node via the message
subsystem.
MsgPtPWriteKB countshft Total KBs of net point-to-point messages output FLOAT

from processes on the node via the message
subsystem.
Broadcast Net Traffic Columns

Identify the number (Reads, Writes) and amount (ReadKB, WriteKB) of input and output messages passing through the
Teradata Database nets through broadcast (1:many) methods (Brd).
Note: If a single broadcast message is delivered to multiple processes in this node, the NetBrdReads and NetBrdReadKB are
only incremented once.
MsgBrdReads count Number of net broadcast messages input to FLOAT

subsystem.
MsgBrdWrites count Number of net broadcast messages output from FLOAT

subsystem.
MsgBrdReadKB countshft Total KBs of net broadcast messages input to FLOAT

subsystem.
MsgBrdWriteKB countshft Total KBs of net broadcast messages output from FLOAT
subsystem.
Network Transport Data Columns

Identify the number (Reads, Writes) and amount of input and output (PDE messages routed by the message subsystem)
passing through the Teradata Database nets. These statistics are nonspecific, that is, they do not take into consideration
which Bynet performed the transport.

Gather Invalid
NetMsgPtpWriteKB countshft Amount of point-to-point message data in KBs FLOAT

transmitted by both Bynets.
NetMsgBrdWriteKB countshft Amount of broadcast message data in KBs FLOAT

NetMsgPtpReadKB countshft Amount of point-to-point message data in KBs FLOAT

received by both Bynets.
NetMsgBrdReadKB countshft Amount of broadcast message data in KBs FLOAT

received by both Bynets.
NetMsgPtpWrites count The number of point-to-point messages FLOAT MP-RAS

NetMsgBrdWrites count The number of broadcast messages transmitted FLOAT

by both Bynets
NetMsgPtpReads count The number of point-to-point messages received FLOAT MP-RAS

by both Bynets.
NetMsgBrdReads count The number of broadcast messages received by FLOAT

both Bynets.
Per-Bynet Network Transport Data Columns

Identify the amount of input and output passing through the Teradata Database nets. These KB statistics are not countshft,
as might be expected, because the BLM does the conversion to KB before handing them off to RSS.
These statistics are net-specific, that is, they relate to each specific Bynet. On a single-node (virtual network [vnet]) system,
net-specific statistics are not meaningful and are always zero.
NetTxKBPtP count Total point-to-point KBs transmitted over all FLOAT

Bynets.
NetRxKBPtP count Total point-to-point KBs received over all FLOAT

Bynets.
NetTxKBBrd count Total broadcast KBs transmitted over all Bynets. FLOAT
NetRxKBBrd count Total broadcast KBs received over all Bynets. FLOAT
Net Controller Status and Miscellaneous Management

Provide utilization and other status information about the Teradata Database Net controllers.
These statistics are not net-specific since all the Bynet statistics are reported in the Net columns. On a single-node (vnet)
system, net-specific statistics are not meaningful and are always zero.
NetTxRouting tmon Number of samples showing the transmitter FLOAT

routing on a Bynet.
NetTxConnected tmon Number of samples showing the transmitter FLOAT WINDOWS

connected on a Bynet. LINUX
NetRxConnected tmon Number of samples showing the receiver FLOAT WINDOWS

connected on a Bynet. LINUX

Gather Invalid
NetTxIdle tmon Number of samples showing the transmitter idle FLOAT

on a Bynet.
NetRxIdle tmon Number of samples showing the receiver idle on FLOAT

a Bynet.
Net Circuit Management Columns

Identifies the management of Teradata Database net circuits (Circ). Additional detail is found in Appendix B:
“ResUsageIpma Table.”
Note: Circuit attempts for one or both Bynets can be computed as the sum of the applicable NetTxCircPtp and
NetTxCircBrd columns. All of these columns except for NetCircBackoffs are net-specific. On a single-node system, net-
specific statistics are not meaningful and are always zero.
NetTxCircHPBrd count Number of high priority broadcast circuits FLOAT

transmitted on all Bynets.
NetRxCircPtp count Total number (both normal and high priority) of FLOAT
point-to-point circuits received on all Bynets.
NetTxCircHPPtP count Number of high priority point-to-point circuits FLOAT

NetRxCircBrd count Total number (both normal and high priority) of FLOAT
broadcast circuits received on all Bynets.
NetTxCircBrd count Total number (both normal and high priority) of FLOAT
broadcast circuits transmitted on all Bynets.
NetCircBackoffs count “Software” backoffs, defined as BNS service FLOAT

blocked occurrences, without regard for which
net was involved.
NetHWBackoffs count “Hardware” backoffs reported by the BLM for all FLOAT
Bynets.
NetTxCircPtp count Total number (both normal and high priority) of FLOAT
point-to-point circuits transmitted on all Bynets.
Group Coordination Messages Columns

Identify messages that are communicated through the Teradata Database net for coordination of a process among a group of
vprocs. Coordination is handled either through semaphores, groups, or channels.
NetSemInUseSum count Total number of semaphores in use during each FLOAT

log interval.
NetSemInUseMax track Maximum number of semaphores in use during FLOAT

each log interval.
NetChanInUseSum count Total number of channels in use during each log FLOAT
interval.
NetChanInUseMax track Maximum number of channels in use. FLOAT

Gather Invalid
NetGroupInUseSum count Total number of groups in use during each log FLOAT
interval. This number should be same across all
nodes.
NetGroupInUseMax track Maximum number of groups in use during each FLOAT

log interval.
Merge Services Columns

Identify activity occurring through merge (many:1) methods (Mrg) on Teradata Database net.
NetMrgTxKB countshft Number of KBs transmitted, without regard to FLOAT

which net, by merge transmission services for
currently active merge operations.
NetMrgRxKB countshft Number of KBs received, without regard to FLOAT WINDOWS

which net, by merge receive services for currently LINUX
active merge operations.
NetMrgTxRows count Number of data rows transmitted, without FLOAT

regard to which net, by merge transmission
services for currently active merge operations.
NetMrgRxRows count Number of data rows received, without regard to FLOAT

which net, by merge receive services for currently
active merge operations.
HOST CONTROLLER COLUMNS
Channel Traffic Columns

Identify the traffic between the host and the node in three levels of granularity: blocks, messages, and KBs. Blocks are made
up of some amount of variable sized messages. ReadKB and WriteKB identify the KBs involved in the traffic. This will allow
the users to get an overview of their host traffic without turning on the recording for ResUsageShst. These values include the
Channel and LAN connections.
Note: The Host statistics were moved from the now obsolete ResUsageShst table to ResUsageSpma to provide host statistics.
HostBlockReads count Number of blocks read in from the host. FLOAT
HostBlockWrites count Number of blocks written out to the host. FLOAT
HostMessageReads count Number of messages read in from the host. FLOAT
HostMessageWrites count Number of messages written out to the host. FLOAT
HostReadKB count KBs transferred in from the host. FLOAT
HostWriteKB count KBs transferred out to the host. FLOAT

Gather Invalid
MsgChnLastDone count Number of "last done" events that occurred on FLOAT

this node.
Note: The last AMP to finish an operation may
send a "last done" broadcast message indicating
the work is done for this step. This is used in
tracking down the slowest node or AMP in the
system. A node or AMP that has more "last done"
messages than the others could be a bottleneck in
the system performance.
GENERAL CONCURRENCY CONTROL COLUMNS
Database Locks Columns

Identify database locking occurrences.
DBLockBlocks count Number of times a database lock was blocked. FLOAT
DBLockDeadlocks count Number of times a database lock was FLOAT

deadlocked.
FILE SYSTEM COLUMNS
Segments Acquired Columns

Summarize logical and physical segments acquired by the file system. For more detail, see Chapter 13: “ResUsageSvpr Table.”
FileAcqs count Total number of disk segments acquired. FLOAT
FileAcqKB count Total KBs acquired by FileAcqs. FLOAT
FileAcqReads count Total number of disk segment acquires that FLOAT

caused a physical read.
FileAcqReadKB count Total KBs physically read by FileAcqReads. FLOAT
Segments Released Columns

Summarize logical and physical segments released by the file system. For more detail, see Chapter 13: “ResUsageSvpr Table.”
FileRels count Total number of disk segments released by tasks. FLOAT
FileRelKB count Total KBs released by FileRels. FLOAT
FileWrites count Total number of disk segment immediate or FLOAT

delayed physical writes.
FileWriteKB count Total KBs physically written by FileWrites. FLOAT
Data Block Prefetches Columns

Summarize the effects of prefetching data blocks on the file system. For more detail, see Chapter 13: “ResUsageSvpr Table.”
FilePres count Total number of times a cylinder is loaded. FLOAT

Gather Invalid
FilePreKB count Sum of the sizes of data blocks loaded with FLOAT
cylinder reads. This field does not count the disk
sectors in between the loaded data blocks.
FilePreReads count Number of times a cylinder is loaded. FLOAT
FilePreReadKB count The size of the cylinder section being read that is FLOAT
physically loaded from disk. The section contains
the requested data blocks and any sectors that
happen to be in between them.
Data Segment Lock Requests Columns

Summarize the number of lock blocks and deadlocks on a disk segment. For more detail, see Chapter 13: “ResUsageSvpr
Table.”
FileLockBlocks count Number of lock requests that were blocked. FLOAT
FileLockDeadlocks count Number of deadlocks detected on lock requests. FLOAT
FileLockEnters count Number of times a lock was requested. FLOAT
Depot Columns
Summarize the physical writes to the Depot used to protect in-place modifications.
FileSmallDepotWrites count Number of small writes to the depot performed FLOAT

to protect in-place modifications. Each small
Depot write protects a single in-place write of
either a write ahead logging (WAL) data block or
a database data block. The small Depot is
typically used when the in-place writes are
initiated by a foreground task. Small Depot
writes are also counted against FileWrites;
therefore, FileWrites still indicates the total
writes regardless of whether it was a Depot write
or a database write.
FileLargeDepotWrites count Number of large writes to the depot performed FLOAT

to protect in-place modifications. Each large
Depot write protects multiple in-place writes of
either WAL data blocks or database data blocks.
The large Depot is typically used when blocks
age out of memory in the background. Large
Depot writes are also counted against FileWrites;
therefore, FileWrites still indicates the total
writes regardless of whether it was a Depot write
or a database write.

Gather Invalid
FileLargeDepotBlocks count Total number of blocks (either WAL or database) FLOAT

that have been protected by large Depot writes.
Since a large Depot write protects multiple
blocks, the following calculation results in the
average number of blocks protected by each large
Depot write:
FileLargeDepotBlocks / FileLargeDepotWrites
USER COMMANDS COLUMNS
User Command Columns

Summarize the type of statements given to Teradata Database by the user. For more detail, see Chapter 8: “ResUsageShst
Table.”
CmdDDLStmts count Number of alter, modify, drop, create, replace, FLOAT

grant or revoke commands.
CmdDeleteStmts count Number of delete commands. FLOAT
CmdInsertStmts count Number of insert commands. FLOAT
CmdSelectStmts count Number of select commands. FLOAT
CmdUpdateStmts count Number of update commands. FLOAT
CmdUtilityStmts count Number of utility commands. FLOAT
CmdOtherStmts count Number of other commands. FLOAT
User Command Arrival and Departure Columns

Summarize the arrival and departure of user statements. For more detail, see Chapter 8: “ResUsageShst Table.”
CmdStmtsInProgCur track Current count of statements in progress. FLOAT ALL
CmdStmtSuccesses count Number of statements that departed normally. FLOAT
CmdStmtFailures count Number of statements that departed in failure or FLOAT

were aborted.
CmdStmtErrors count Number of statements that departed in error. FLOAT
CmdStmtTime tmon The sums of the resident time of each statement FLOAT ALL
in progress during the log period, including the
successes and failures.
TERADATA ACTIVE SYSTEM MANAGEMENT COLUMNS
AMP Worker Task Columns

Collect and report statistics about the AWTs. For more information about the ResUsageSawt table and columns, see
Chapter 7: “ResUsageSawt Table.”
AwtFlowControlled count Number of AWTs currently in flow control on FLOAT

the work input mailbox.

Obsolete Columns
Gather Invalid
AwtFlowCtlCnt count Number of times this collection/log period that FLOAT

that system entered the flow control state from a
non-flow controlled state.
AwtInuse count Number of AWTs currently in use for this node. FLOAT
AwtInuseMax count Peak number of AWTs (Max) on this node. This FLOAT
is not the Peak or the Max value stored in the
Priority Scheduler (sch) data structure and
reported by the puma utility. The sch peak value
is the Max value since startup is never set and
Max is the maximum allowed value.
Note: This reported Max value is the maximum
reached during each log period.
Priority Scheduler Columns

Provides data specific to the Priority Scheduler. For more information about the ResUsageSps table and columns, see
Chapter 11: “ResUsageSps Table.”
PSNumRequests Number of work requests received for all FLOAT

Performance Groups on this node.
PSQWaitTime Time in centiseconds that work requests waited FLOAT

on an input queue before being serviced.
To get an approximate average QWaitTime per
request during this period, divide QWaitTime by
NumRequests.
PSServiceTime Time in centiseconds that work requests FLOAT

required for service.
To get an approximate average ServiceTime per
request during this period, divide ServiceTime
by NumRequests.
Obsolete Columns
The following columns listed below should not be used because they have been renamed or
made obsolete.
Memory Pages Resident Columns

The Mem[seg]KBResBack column is obsolete.
Backup AMP and Traffic Management Columns

• Mem[seg]BackCReads
• Mem[seg]BackPReads

Spare Columns
• Mem[seg]BackReadKB
• Mem[seg]BackFlushes
• Mem[seg]BackFlushKB
Spare Columns
The ResUsageSpma table has nine spare columns: three count, three track, and three
tmonitored columns as shown in the following table.
Column Name Gather Method Description

SECTION 2 Vproc Resource Usage Tables

Section 2: Vproc Resource Usage Tables

CHAPTER 7 ResUsageSawt Table
The ResUsageSawt table collects and reports statistics about the AWTs. If table logging is
enabled, then data is written to the database once for each Vproc log period.
To consolidate and summarize the total number of rows written to the database, you can
enable Summary Mode. For details, see “Summary Mode” on page 87.
Note: This table is created as a MULTISET table.
The following table describes the ResUsageSawt table columns.
Gather Invalid


columns.
number of 1. For example, the node ID of an SMP
node is ‘001-01’.
twice a year.

Chapter 7: ResUsageSawt Table
Gather Invalid
etc.
VprId n/a Identifies the vproc number. All Vprocs in this table INTEGER
are AMPS so there is no VprType field provided. In
Summary Mode, this field is zero.

system

NominalSecs n/a A specified or nominal number of seconds in the

logging period. SMALLINT
SummaryFlag n/a Identifies the summarization status of this row. If CHAR

the value is ‘N,’ the row is a non-summary row. If
the value is ‘S,’ the row is a summary row. For
details, see “Summary Mode” on page 87.
Active n/a Controls whether or not the rows will be logged to FLOAT
enabled.
period.
Note: For the current release, data collection for
the ResUsageSawt table results in a non-zero value
for all rows under all conditions. Therefore, Active
Row Filter Mode is not in effect for this table.

Gather Invalid

interval. This field is specifically used as the divisor
for calculating the average from some of the "Sum"
columns. For more information, see “Column
Names Ending In “Sum”” on page 47.
Note: This value typically equals the LogRate
divided by the CollectRate even for rows that were
not "active" during the entire log period. This is
because a zero value (or idle time) is included in the
calculations for averages.
STATISTICS COLUMNS
AMP Worker Task Columns

Collect and report statistics about the AWTs.
MailBoxDepth count Current depth of the AMP work mailbox. FLOAT
FlowControlled count Specifies if an AMP is in flow control. FLOAT

If the value is non-zero, then the AMP is in flow
control.
FlowCtlCnt count Number of times during the log period that the FLOAT
system entered the flow control state from a non-
flow controlled state.
InuseMax count Maximum number of AWTs in use at any one time FLOAT
during the log period.
WorkTypeInuse00 - count Current number of AWTs in use during the log FLOAT
WorkTypeInuse15 period for each work type for the VprId vproc.
WorkTypeMax00 - count Maximum number of AWTs in use at one time FLOAT

WorkTypeMax15 during the log period for each work type for the
VprId vproc.
In Summary Mode, the WorkTypeMax field values
are the Max of the values for all the AMPS.
WORKTYPE DESCRIPTIONS
The WorkTypeInuse and WorkTypeMax array data columns above each contain 16 "Work Type" entries that are described here.
For example, WorktypeInuse00 contains the number of in use AWTs that are of Work Type "MSGWORKNEW," and
WorktypeInuse01 contains the values for "MSGWORKONE."
These columns allow the user to monitor the usage of the AWTs of each work type. This can be used to determine if the usage is
close to the maximum values defined and what type of work they are doing. Also, this can be used to determine characteristics
of the system during skew conditions or when there are AWT shortages.
Use the tdntune utility to determine the settings for Flow Control. For information on Expedited Allocation Groups, see
"Priority Scheduler (schmon, xschmon)” chapter of Utilities.

Gather Invalid
MSGWORKNEW n/a Used for new work requests. This work type has the n/a
lowest number, which means it is queued last. It
also has the effect of honoring secondary requests
needed to complete existing work items before any
new ones are started.
A zero value is used for new work items.
MSGWORKONE n/a First level secondary work items. Numbered work n/a
types are used for secondary work items. For
example, work type one (MSGWORKONE) is used
for secondary work requests spawned by new work
items; work type two (MSGWORKTWO) requests
are spawned from work type one requests and
queued for delivery before work type one requests;
and so on. Each numbered work type is queued for
delivery just before the one from which it is
spawned.
MSGWORKTWO n/a Second level secondary work items. n/a
MSGWORKTHREE n/a Third level secondary work items. n/a
MSGWORKFOUR n/a Not used. n/a
MSGWORKFIVE n/a Not used. n/a
MSGWORKSIX n/a Not used. n/a
MSGWORKSEVEN n/a Not used. n/a
MSGWORKEIGHT n/a New work for Expedited Allocation Groups. n/a
MSGWORKNINE n/a First level spawned work for Expedited Allocation n/a
Groups.
MSGWORKTEN n/a Second level spawned work for Expedited n/a

Allocation Groups.
MSGWORKELEVEN n/a Third level spawned work for Expedited Allocation n/a
Groups.
MSGWORKABORT n/a Used for transaction abort requests. This work type n/a
has a higher value than the numbered work types
so that abort requests are honored before beginning
any additional work item for the transactions being
aborted.
The array number for MSGWORKABORT is 12.
MSGWORKSPAWN n/a Used for spawned abort requests and is delivered n/a
before normal aborts.
The array number for MSGWORKSPAWN is 13.

Summary Mode
Gather Invalid
MSGWORKNORMAL n/a Used for messages that do not fall within the n/a
standard work type hierarchy. This work type is
delivered before any of the work items described
above.
The array number for MSGWORKNORMAL is 14.
MSGWORKCONTROL n/a Used for system control messages. These are n/a
delivered before any other kind of message.
The array number for MSGWORKCONTROL is
15.
Summary Mode
When Summary Mode is active for the ResUsageSawt table, one row is written to the database
for each node in the system for each log interval. The AWT data will be combined for all the
AMP vprocs on the node.
that row:
‘N’ normally.
Spare Columns
The ResUsageSawt table has thirty spare columns: ten count, ten track, and ten tmonitored
columns as described below.
where [i] is expanded to be the values 00–09, for example, SpareCount00–SpareCount09,

SpareTrack00–SpareTrack09, or SpareTmon00–SpareTmon09.

Spare Columns

CHAPTER 8 ResUsageShst Table
The ResUsageShst table:

• Contains resource usage information specific to the host channels and LANs
communicating with Teradata Database.
• Includes resource usage data for system-wide, host information.
The following table describes the ResUsageShst table columns.
Gather Invalid


columns.
node is ‘001-01’.
Gmt Time n/a Greenwich Mean Time is not affected by the FLOAT
twice a year.

Chapter 8: ResUsageShst Table
Gather Invalid
etc.
VprId n/a Identifies the Vproc number (non-Summary INTEGER

Mode) or the Vproc type (Summary Mode;
0 = Node, 1 = AMP, 2 = PE, 3=GTW, 4=RSG).
The VprId can be any of the following depending
on the type:
• AMP vprocs: numbered upward from 0.
• PE vprocs: numbered downward from 16383.
• Node vprocs: numbered upward from 16384.
• RSG vprocs: numbered downward from 9215.
• GTW vprocs (Windows and Linux only):
numbered upward from 8192.
The vproc numbers within each type range are
contiguous. Each existing vproc type range should
not overlap into the range of another existing vproc
type on the system.
For LAN-connected hosts, VprId is always 65535.
For channel-connected hosts, VprId should be the
vproc id of the owning PE. If there are multiple PEs
on this node connecting to this channel, then VprId
will be 65534. If, for some reason, no PE on this
node connects to this channel, VprId will be 65535.
HstId n/a Identifies the host. Value is BBMMPPHH (Bus, INTEGER

Module Number [also called chassis], Port, Host
Group ID [HgId]) with each field getting two
decimal digits of the resulting 8 digit value. The
chassis number is always 0 for network-connected
hosts. In Summary Mode, HstId is always 0.
HstType n/a Type of host. Possible values in non-Summary CHAR(8)

Mode are “NETWORK” (LAN-connected host)
and “IBMMUX” (channel-connected host).
Possible values in Summary Mode are
“NETWORKS” and “IBMMUXS”.

represented by this row. This value is useful for
normalizing the statistics contained in this row, for
example, to a “per-second” measurement.


Gather Invalid


the value is ‘S,’ the row is a summary row.
In Summary Mode, the rows are summarized into a
single row. For details, see “Summary Mode” on
page 93.
enabled.
period.
the ResUsageShst table results in a non-zero value

interval. In the collect buffer, the value is always 1.
In the log buffer or the database table, the value is
the ratio of log interval to collect interval.
STATISTICS COLUMNS
HOST CONTROLLER COLUMNS
Channel Traffic Columns

Identify the traffic between the host and the node in three levels of granularity: blocks, messages and KBs. Blocks are made
up of some amount of variable sized messages. ReadKB and WriteKB identify the KBs involved in the traffic.
HostBlockReads count Number of blocks read in from the host. FLOAT
HostBlockWrites count Number of blocks written out to the host. FLOAT
HostMessageReads count Number of messages read in from the host. FLOAT
HostMessageWrites count Number of messages written out to the host. FLOAT
HostReadKB count KBs transferred in from the host. FLOAT
HostWriteKB count KBs transferred out to the host. FLOAT

Gather Invalid
Channel Management Columns

Identify overhead of channel management.
HostQLenSum count Total number of messages queued for output to the FLOAT ALL
host during each log interval.
Note: To calculate the average HostQLen divide the
HostQLenSum by the CollectIntervals value to get
the HostQLen average value during the logging
period. This average is an average of the values
recorded at each of the collection periods that
occur during the logging period.
HostQLenMax count Maximum number of messages queued in each log FLOAT ALL
interval.
HostReadFails count Number of failures transmitting from the host. FLOAT ALL
Note: Teradata Channel software (TCHN) only.
HostWriteFails count Number of failures transmitting to the host. FLOAT ALL

Note: Teradata Channel software (TCHN) only.
User Commands Columns

Identify the type of commands given to Teradata Database by the user. Three levels of granularity are given: transaction,
request, and statement. Transactions consist of one or more requests. Requests consist of one or more statements.
Statements are subdivided into the various statement types.
CmdTransactions count Number of transaction commands. FLOAT
CmdRequests count Number of request commands. FLOAT
CmdAlterStmts count Number of alter, modify, or drop statement FLOAT

commands.
CmdCreateStmts count Number of create or replace statement commands. FLOAT
CmdDeleteStmts count Number of delete commands. FLOAT
CmdGrantStmts count Number of grant or revoke commands. FLOAT
CmdInsertStmts count Number of insert commands. FLOAT
CmdSelectStmts count Number of select commands. FLOAT
CmdUpdateStmts count Number of update commands. FLOAT
CmdArchUtilityStmts count Number of archival utility commands (for FLOAT

example, dump, restore, archive and recovery).
CmdLoadUtilityStmts count Number of FastLoad and MultiLoad utility FLOAT

commands. (Tpump commands cannot be
distinguished, and are therefore counted by the
INSERT, UPDATE and DELETE statements).
CmdMiscUtilityStmts count Number of miscellaneous utility commands. FLOAT ALL

Obsolete Columns
Gather Invalid
CmdOtherStmts count Number of other commands. FLOAT
User Command Arrival and Departure Columns

Help to identify the arrival and departure times and status of user commands.
Note: Statistics described in this section are not yet available.
CmdStmtsInProgMax track Maximum number of statements in progress FLOAT ALL

CmdStmtsInProgSum count Total count of statements in progress during each FLOAT ALL
log interval.
statements in progress, divide this value by the
CollectIntervals value. Since the CollectIntervals is
the number of collect periods per logging period,
the resulting number is the average value per
collection period.
CmdStmtSuccesses count Number of statements that departed normally. FLOAT
CmdStmtFailures count Number of statements that departed in failure or FLOAT

abortion.
CmdStmtErrors count Number of statements that departed in error. FLOAT
CmdStmtTime tmon The sums of the resident time of each statement in FLOAT ALL
progress during the log period, including the
successes and failures.
Obsolete Columns
The columns listed below are obsolete and always contain zero:
• HostChanBusy
• HostCntlBusy
Summary Mode
When Summary Mode is active for the ResUsageShst table, one row is written to the database
for each type of host (network or channel-connected) on each node in the system,
summarizing the hosts of that type on that node, for each log interval as follows:
• The value in HstId will be 0 for the channel-connected host summary and 1 for the
network-connected host summary.
• The value in HstType will end with the character ‘S’ for “summary.”

Spare Columns
that row:
‘N’ normally.
Spare Columns
The ResUsageShst table has 30 spare columns: 10 count, 10 track, and 10 tmonitored columns
as shown in the following table.
where [i] is expanded to be the values 00-09, for example, SpareCount00, SpareTrack14, or
SpareTmon01.

CHAPTER 9 ResUsageSldv Table
The ResUsageSldv table contains resource usage information for system-wide, logical device
information. Statistics from this table are collected from the SCSI bus level.
For more information on how to collect SCSI data for the ResUsageSldv table, see the
“Control GDO Editor (ctl)” or “Xctl (xctl)” chapter in Utilities.
The following table describes the ResUsageSldv table columns.
Gather Invalid


columns.
node is ‘001-01’.
twice a year.

Chapter 9: ResUsageSldv Table
Gather Invalid
etc.
VprId n/a Identifies the vproc that this logical device is owned INTEGER
by. The AMP vproc ID is in the range of 0 to 8191.
If the logical device is not owned by any AMP (that
is, system disk), the VprId has a value of 65535.
In Summary Mode, the VprId has one of the
following values:
• 0 = Database disk
• 1 = System disk
CtlId n/a Represents the controller number. INTEGER

The value is the decimal equivalent of the three hex
digit controller ID in the LdvId. The maximum
controller ID in this case is FFFF hex. This allows
the SCSI devices to be grouped by CtlId for
controller based summarization.
LdvId n/a Represents the logical device in the Bus System BYTE(4)
where it resides. The LdvId value corresponds to
the MP-RAS dev_name of the device, and is to be
interpreted as follows:
• The first two hex digits of the LdvId are always 0.
• The third through fifth digits are the controller
number (‘c’ number).
• The sixth digit is the ‘t’ number,
• The seventh and eighth digits are the ‘d’
number.
• The slice (‘s’) number is always 0, and is not
represented in the LdvId. For example, device
c3t5dbs0 would be represented by an LdvId
value of '0000350b'X.
LdvType n/a Type of logical device. Value in non-Summary CHAR(4)

Mode is either “DISK” for database disk or “SDSK”
for system disk. Value in Summary mod is either
“DISS” or “SDSS.”

Gather Invalid

system


logging period.

single row. For details, see “Summary Mode” on
page 100.
enabled.
• A non-zero value, then the row contains
• A zero value, then none of the data columns in
period.
the ResUsageSldv table results in a non-zero value

interval. In the collect buffer, value is always 1. In
the log buffer or the database table, value is the
ratio of log interval to collect interval.

Gather Invalid
STATISTICS COLUMNS
LOGICAL DEVICE COLUMNS
Input and Output Traffic Columns

Represent the number and amount, in KBs, of data read and written to the logical device.
LdvReads count Number of reads issued. FLOAT
LdvWrites count Number of writes issued. FLOAT
LdvReadKB count Contains the following values: FLOAT

• MP-RAS: Kbytes read from or written to the
logical device.
• Windows and Linux: Kbytes read from the
logical device.
LdvWriteKB count Contains the following values: FLOAT MP-RAS

• MP-RAS: 0.
• Windows and Linux: Kbytes written to the
logical device.
LdvReadRespMax tmon Contains the following values: FLOAT WINDOWS

AND
• MP-RAS: Maximum of the LdvReadRespTot
LINUX
field.
• Windows and Linux: 0.
LdvWriteRespMax tmon Value is always 0. FLOAT ALL
Response Time Columns

Represent the response time to requests given to the logical device.
LdvReadRespTot tmon Contains the following values: FLOAT WINDOWS

• MP-RAS: The totals of individual read and write
response times.
• Windows: 0.
• Linux: The total number of individual read
response times.
LdvWriteRespTot tmon Contains the following values: FLOAT MP-RAS

AND
• MP-RAS: 0.
WINDOWS
• Windows: 0.
• Linux: The total number of individual write
response times.
ReadActiveTotal tmon Note: This field is not currently used. FLOAT ALL
WriteActiveTotal tmon Note: This field is not currently used. FLOAT ALL

Obsolete Columns
Gather Invalid
Concurrent Operations Columns

Represent the number of concurrent operations performed on the logical device at a time.
LdvConcurrentMax count Maximum number of concurrent requests during FLOAT ALL

the collect/log period. Default value is always 0.
Note: Do not use this field for any platform.
Outstanding Requests Columns

Represent the number of outstanding operation requests and the amount of time with outstanding requests for the logical
device.
QReadLength count Note: This field is not currently used. FLOAT ALL
QWriteLength count Note: This field is not currently used. FLOAT ALL
LdvOutReqSum count Average number of queued requests reported. FLOAT
LdvOutReqMax count Maximum value of the LdvOutReqSum field. FLOAT WINDOWS

LINUX
Note: On Windows and Linux, the default value is
always 0.
LdvOutReqTime tmon Total time in centiseconds with (any) outstanding FLOAT

requests. The values in this field should be less than
or equal to the reported logging period.
Obsolete Columns
The following columns should not be used because they have been renamed or made obsolete.
Concurrent Operations Columns

LdvConcurrentSum column is obsolete.
Seek Statistics Columns

• LdvSeekDistance
• Ldv0CylSeeks
Response Time Columns

• LdvReadRespSq
• LdvWriteRespSq

Summary Mode
Summary Mode
When Summary Mode is active for the ResUsageSldv table, the following rows are written to
the database for each node in the system for each log interval:
• One row summarizes the system logical devices
• One row summarizes Teradata Database logical devices
The value in LdvId will be ‘FFFFFFFF’X and the value in VprId will be 0 for database disk and
1 for system disk. The value in LdvType will end with the character ‘S’ for “summary.”
Also, you can determine if a row is in Summary Mode by checking the SummaryFlag column
for that row:
‘N’ normally.
Spare Columns
The ResUsageSldv table has nine spare columns: three count, three track, and three
tmonitored columns:
where [i] is expanded to be the values 00-02, for example, SpareCount00.

CHAPTER 10 ResUsageSpdsk Table
Note: The ResUsageSpdsk table described in this chapter is not currently used and should not
be enabled at this time.
The ResUsageSpdsk table:
• Provides pdisk logical device statistics.
• Includes resource usage logs on cylinder I/O, allocation, and migration.
The following table describes the ResUsageSpdsk table columns.
Gather Invalid

TheDate n/a Date of the log entry. DATE ALL
TheTime n/a Nominal time of the log entry. FLOAT ALL

Note: Under conditions of heavy system
load, entries may be logged “late” (typically,
by no more than one or two seconds), but
this field will still contain the time value
when the entry should have been logged. See
the Secs and NominalSecs columns.
NodeId n/a Identifies the Node upon which the pdisk is INTEGER ALL
connected. The Node ID is formatted as
CCC-MM, where CCC denotes the three-
digit cabinet number and MM denotes the
two-digit chassis number of the node. For
example, a node in chassis 9 of cabinet 3 has
a node ID of ‘003-09’.
SMP node is ‘001-01’.

Chapter 10: ResUsageSpdsk Table
Gather Invalid
GMT Time n/a Greenwich Mean Time is not affected by the FLOAT ALL
Daylight Savings Time adjustments that
occur twice a year.
PdiskGlobalId n/a Identifies the pdisk in the system. Each pdisk INTEGER ALL
in the system has a global ID which uniquely
identifies the pdisk in the system. If a pdisk is
connected to the nodes in a clique, all the
nodes in that clique see the same pdisk
global ID associated with that pdisk.
In Summary Mode, the pdisk global ID is -1.
PdiskType n/a Type of pdisk. The pdisk can be one of the CHAR(4) ALL
following:
• DISK: This type of pdisk is a storage
device.
• FILE: This type of pdisk is a file.
PdiskDeviceId n/a Identifies the local pdisk device. BYTE(4) ALL

For DISK pdisk, the pdisk device ID can be
one of the following:
• MP-RAS: This is the pdisk major/minor
number. The major number is in bits
22-27 and the minor number is in bits
0-21. The format is similar to the one
shown below.
(0000 MMMM MMmm mmmm mmmm
mmmm mmmm mmmm)
• LINUX: This is the disk major/minor
number. The major number is in bits
20-27 and the minor number is in bits
0-19. The format is similar to the one
shown below.
(0000 MMMM MMMM mmmm mmmm
mmmm mmmm mmmm)
• Windows: This is the pdisk physical disk/
partition number. The physical disk
number is in the lower 16 bits and the
partition number is in the upper 16 bits.
The format is similar to the one shown
below.
(0000 0000 0000 PPPP DDDD
DDDD DDDD DDDD)
For FILE pdisk, the pdisk device ID is -1.
In Summary Mode, the pdisk device ID is -1.

Gather Invalid
NodeType n/a Type of node, representing the per node CHAR(4) ALL
system family type. For example, “5380,”
“5400,” “5450,” etc.
Secs n/a Actual number of seconds in the log period SMALLINT ALL
represented by this row. Normally the same
as NominalSecs, but can be different in three
cases:
• A sample logged “late” because of load on
the system
“Secs”
CentiSecs n/a Number of centiseconds in the logging INTEGER ALL

period. This field is useful when performing
data calculations with small elapsed times
where the difference between centisecond-
based data and whole seconds results in a
percentage error.
NominalSecs n/a A specified or nominal number of seconds in SMALLINT ALL

the logging period.
SummaryFlag n/a Identifies the summarization status of this CHAR ALL

row. If the value is ‘N,’ the row is a non-
summary row. If the value is ‘S,’ the row is a
summary row.
In Summary Mode, the rows are summarized
into a single row. For details, see “Summary
Mode” on page 108.
Active n/a Controls whether or not the rows will be FLOAT ALL
logged to the ResUsage tables if Active Row
Filter Mode is enabled.
• a zero value, then none of the data
columns in the row have been updated
during the logging period.

Gather Invalid
Active For example, if Active Row Filter Mode is

(continued) enabled, then the rows that have a zero Active
field value will not be logged to the ResUsage
tables.
Note: For the current release, data collection
for the ResUsageSpdsk table results in a non-
zero value for all rows under all conditions.
Therefore, Active Row Filter Mode is not in
effect for this table.
CollectIntervals n/a Number of collect intervals during each log SMALLINT ALL
interval. In the collect buffer, value is always
1. In the log buffer or the database table,
interval.
STATISTICS COLUMNS
Input and Output Columns

Identify the I/O statistics reported by the Extent Driver.
Note: The following columns are not currently used.
ReadCnt count Number of logical device reads. FLOAT ALL
WriteCnt count Number of logical device writes. FLOAT ALL
ReadKB count Number of KBs (1024 bytes) read from the FLOAT ALL
logical device.
WriteKB count Number of KBs (1024 bytes) written to the FLOAT ALL
logical device.
ReadRespTot count Total of individual read response time in FLOAT ALL

centiseconds.
WriteRespTot count Total of individual write response time in FLOAT ALL

centiseconds.
ReadRespMax count Maximum number of individual read FLOAT ALL

response time in centiseconds.
WriteRespMax count Maximum number of individual write FLOAT ALL

ReadRespSq count Total of squares of the individual read FLOAT ALL

WriteRespSq count Total of squares of the individual write FLOAT ALL

ConcurrentReadMax count Maximum number of concurrent read I/O FLOAT ALL

requests.

Gather Invalid
ConcurrentWriteMax count Maximum number of concurrent write I/O FLOAT ALL

requests.
ConcurrentMax count Maximum number of concurrent I/O FLOAT ALL

requests.
OutReqTime count Time with outstanding requests (busy time), FLOAT ALL
in centiseconds.
MigrationBlockedIos count Number of inputs and outputs that are FLOAT ALL
blocked due to migration request.
Allocation Columns
Identify the allocation statistics reported by the allocator.
ExtAllocHot count Number of hot allocations made in the FLOAT ALL

current log period. A “hot allocation” is an
allocation whose estimated temperature falls
within the pre-defined hot temperature
range. Each allocation is for a cylinder size
worth of data. The cylinder resides in some
disk storage location and holds some data.
Temperature is the frequency of access to the
data by I/O independent of where the data
resides.
ExtAllocWarm count Number of warm allocations made in the FLOAT ALL

current log period. A “warm allocation” is an
within the pre-defined warm temperature
resides.
ExtAllocTotal count Total number of allocations made in the FLOAT ALL

current log period. For example, a number of
computations can be derived from this
attribute:
Cold Allocation = ExtAllocTotal –
ExtAllocHot – ExtAllocWarm
QueryPacing Allocation = ExtAllocTotal –
ExtAllocNonPacing – ExtAllocSystemPacing
Dynamic Allocation = ExtAllocTotal -
ExtAllocStatic

Gather Invalid
ExtAllocNonPacing count Number of non-pacing allocations made in FLOAT ALL

the current log period. A “non-pacing
allocation" is an allocation whose data access
affects neither system performance nor
individual query performance.
ExtAllocSystemPacing count Number of system pacing allocations made FLOAT ALL

in the current log period. A “system pacing
affects system performance.
ExtAllocStatic count Number of static allocations made in the FLOAT ALL

current log period. A “static allocation" is an
allocation whose requested temperature is
used and the measured temperature is
ignored during migration.
Migration Columns
Identify the number of cylinders that migrated to a different location on a device as well as the time, in centiseconds, of all
migration I/Os used, incurred, or saved during the log period.
ExtMigrateFaster count Number of cylinders migrated to a faster FLOAT ALL

location on a device. This count is for
cylinders that were allocated on this device
and migrated to a different location within
the same device or migrated to a completely
different device.
The ExtMigrateSlower, which is the number
of cylinders migrated to slower locations, can
be computed as follows:
ExtMigrateSlower = ExMigrateTotal -
ExMigrateFaster
ExtMigrateTotal count Total number of cylinders migrated to a FLOAT ALL

different physical location. For more
information, see the ExtMigrateFaster field.
ExtMigrateIOTime count Adds the elapsed response time in FLOAT ALL

centiseconds of all I/Os used to migrate data
that completed during the log period.
Note: Response time, not service time, is
used.

Gather Invalid
ExtMigrateIOTimeCost count Estimates the total cost (in centiseconds) FLOAT ALL
incurred by migration I/Os completing
during the log period, where cost is the extra
time waited by all non-migration I/Os as a
result of the migration I/O. The Migrator
estimates migration costs.
Note: This field is for internal use only. Do
not use this field unless directed by Teradata
Support Center.
ExtMigrateIOTimeBenefit count Estimates the total I/O time savings achieved FLOAT ALL
by migrations completing in the log period.
The I/O time savings include the
improvement in response time caused by the
new data arrangement up to the time
horizon. ExtMigrateIOTimeBenefit does not
include the cost of the migration I/Os and is
a gross benefit, not a net benefit. The
Migrator estimates the migration benefit.
Support Center.
ExtMigrateIOTimeImprove count Estimates the percent improvement in FLOAT ALL

average IO response time due to migrations
completing in the log interval. In theory, this
percentage improvement is permanent. For
example, if, right before a particular log
interval, the average IO response time was 10
milliseconds (ms), then the Migration logs
an ExtMigrateIOTimeImprove value of 10%
in this interval. The average IO response time
after the log interval should be (100%-
10%)*10ms = 9ms. Migration then logs an
ExtMigrateIOTimeImprove of 1% in the next
interval. The average I/O response time in
the new log interval is (100%-1%)*9ms =
8.91ms.
ExtMigrateIOTimeImprove is only an
estimate. Its "permanent" improvement
remains in effect as long as the workload
does not change and newer migrations do
not significantly alter the data arrangement.
When the workload changes or new
migrations affect data arrangement, response
time changes in an un-quantified way.

Summary Mode
Gather Invalid
ExtMigrateIOTimeImprove Despite this, ExtMigrateIOTimeImprove is

(continued) useful because it predicts actual system
performance at least for short periods of time
and can be used to understand why the
migration algorithm is doing what it is
doing.
Support Center.
Summary Mode
When Summary Mode is active for the ResUsageSpdsk table, rows are summarized into a
single row for each pdisk type (for example, DISK or FILE) for each node in the system per log
interval.
that row:
‘N’ normally.
Spare Columns
The ResUsageSpdsk table has thirty spare columns: ten count, ten track, and ten tmonitored
SpareTmon00-SpareTmon09.

CHAPTER 11 ResUsageSps Table
The ResUsageSps table contains data by Performance Group from the Priority Scheduler.
For a complete description of the Priority Scheduler and its components, see “Priority
Scheduler (schmon/xschmon)” chapter in Utilities.
If table logging is enabled on ResUsageSps, data is written to the database once for every
triplet (that is, vproc ID [VprId], Performance Group ID [PGId], and Performance Period ID
[PPId]) in the system for each log interval.
To improve system performance, you can enable Summary Mode, Active Row Filter Mode, or
both. For more information on these options, see “Summary Mode” on page 113 or
“Active Row Filter Mode” on page 114.
The following table describes the ResUsageSps table columns.
Gather Invalid


columns.
node is ‘001-01’.

Chapter 11: ResUsageSps Table
Gather Invalid
twice a year.
etc.
VprId n/a Identifies the vproc number. Multiple Vprocs INTEGER

contribute to each Performance Group task. In
Summary Mode, this field is zero.
PPId n/a Identifies the performance period. The PPId is a BYTEINT

mapping of the internal performance period value
(ranges 0 to 7) to a RSS value (ranges 0 to 1). A
PPId of 0 maps to the value 0, and the PPId of 1
maps to the values 1 through 7.
The PPId field allows RSS to log two rows for each
Node, Vproc, and PGId set when a PGId uses more
than one AGId during a logging period. See the
AGId field for more information.
In Summary Mode, the PPid is zero.
VprType n/a Type of vproc (for example, “AMP,” “PE,” “GTW,” CHAR[4]
“RSG,” or “NODE”). In Summary Mode, this field
is blank since all Vproc data is combined for each
Performance Group.
PGId n/a Identifies the Performance Group. There is a one to BYTEINT

one mapping between a Performance Group ID
and a workload definition ID at any point in time.
The Performance Group ID value ranges from 0 to
39, while the value of a workload definition ID is
not in a specific range (that is, the value is
incremented and not reused).
The mapping between Performance Group ID and
workload definition ID can be determined by
looking at the Teradata Dynamic Workload
Manager screen or the
TDWM.WlcPerfGroupMappings table. For more
information on Teradata Dynamic Workload
Manager, see Teradata Dynamic Workload Manager
User Guide.
Note: In Summary Mode, the PGId is the index
value and ranges from 0 to 39.

Gather Invalid

system



single row for each Performance Group ID. For
more information, see “Summary Mode” on
page 113.
Active n/a Controls whether or not the Performance FLOAT

Group ID rows will be logged to the ResUsage
tables when Active Row Filter Mode is enabled.
• A non-zero value, then the Performance Group
ID row contains modified data fields.
• A zero value, then none of the data fields in the
Performance Group ID row have been updated
For more information, see “Active Row Filter
Mode” on page 114.

interval. In the collect buffer, the value is always 1.
In the log buffer or the database table, the value is
the ratio of log interval to collect interval.

Gather Invalid
STATISTICS COLUMNS
Priority Scheduler Columns

Provide a summary of the Priority Scheduler resource usage statistics.
AGId track Identifies the current Allocation Group for the FLOAT
Performance Group ID that is being reported. This
value can be any number from 0 to 200.
Note: A value of 200 is the system Allocation
Group. This value cannot be assigned for user
work.
For more information on the Allocation Group
(AG), see “Priority Scheduler (schmon/xschmon)”
chapter in Utilities.
RelWgt track Weight of the Allocation Group relative to the FLOAT

active Allocation Groups of the Resource Partition
and the active Resource Partitions.
Note: Allocation Groups with higher relative
weights will have quicker access to system
resources. For more information on allocation
group weights, see the “Priority Scheduler
(schmon/xschmon)” chapter in Utilities.
CPUTime count Milliseconds of CPU time consumed by a task FLOAT

associated with or running under the Performance
Group.
IOBlks count Number of logical data blocks read and/or written FLOAT
by Performance Group.
NumProcs track Number of processes assigned to the Performance FLOAT

Group at the end of the collection period.
NumSets track Allocation Group set division type. If the FLOAT

Allocation Group set division type is:
• Session, then one scheduling set per session
exists.
• None, then one scheduling set for the Allocation
Group exists. Or, if query milestones are used
(that is, the Performance Group has two or
more milestones), then multiple sets exist. For
information on Performance Group milestones,
see Utilities.
For a complete description of these set division
types, see Utilities.
NumRequests count Number of requests for the AWT. FLOAT

Summary Mode
Gather Invalid
QWaitTime count Time in milliseconds that work requests waited on FLOAT

an input queue before being serviced.
To calculate an approximate average QWaitTime
for each request during this period, divide
QWaitTime by NumRequests.
QWaitTimeMax count Maximum time in milliseconds that work requests FLOAT

waited on an input queue before being serviced.
QLength track Number of work requests waiting on the input FLOAT

queue for service.
QLengthMax count Maximum number of work requests waiting on the FLOAT

input queue for service.
ServiceTime count Time in milliseconds that work requests required FLOAT

for service.
To calculate an approximate average ServiceTime
for each request during this period, divide
ServiceTime by NumRequests.
ServiceTimeMax count Maximum time in milliseconds that work requests FLOAT

required for service.
Summary Mode
When Summary Mode is active for the ResUsageSps table, one row is written to the database
for each PGId in the system for each log interval.
that row:
‘N’ normally.
For more information on this option, see “Using Summary Mode” on page 29.

Active Row Filter Mode
Active Row Filter Mode

When Active Row Filter Mode is enabled on the ResUsageSps table, only the active
Performance Group ID rows are written to the database for each log interval.
You can determine if a Performance Group ID row is active by looking at the value in the
Active column, for example:
IF the Active column value is… THEN the Performance Group ID row is…
zero inactive and will not be written to the ResUsage table.
non-zero active and will be written to the ResUsage table.
If Active Row Filter Mode and Summary Mode are both enabled, the active row filtering is
applied after the summarization. To determine if you need to enable this option, see “Using
Active Row Filter Mode” on page 29.
Spare Columns
The ResUsageSps table has thirty spare columns: ten count, ten track, and ten tmonitored
columns as described below.
where [i] is expanded to be the values 00–09, for example, SpareCount00–SpareCount09,

SpareTrack00–SpareTrack09, or SpareTmon00–SpareTmon09.

CHAPTER 12 ResUsageSvdsk Table
The ResUsageSvdsk table:

• Provides AMP-level vdisk logical device statistics.
• Includes resource usage logs on cylinder allocation, migration, and I/O statistics.
If table logging is enabled on ResUsageSvdsk, the data is written once for each AMP Vproc log
period. To consolidate and summarize the total number of rows written to the database, you
can enable Summary Mode. For details, see “Summary Mode” on page 121.
The following table describes the ResUsageSvdsk table columns.
Invalid
Column Name Gather Method Description Data Type Platform


Note: Under conditions of heavy system
load, entries may be logged “late” (typically,
by no more than one or two seconds), but
this field will still contain the time value
when the entry should have been logged. See
the Secs and NominalSecs columns.
resides. The Node ID is formatted as CCC-
MM, where CCC denotes the three-digit
cabinet number and MM denotes the two-
digit chassis number of the node. For
example, a node in chassis 9 of cabinet 3 has
a node ID of ‘003-09’.

Chapter 12: ResUsageSvdsk Table
Invalid
Daylight Savings Time adjustments that
occur twice a year.
VprId n/a Identifies the AMP Vproc. The AMP INTEGER

Vproc ID is numbered upward from 0. The
maximum value is 8191.
In Summary Mode, the value of the AMP
Vproc ID is -1.
NodeType n/a Type of node, representing the per node CHAR(4)

“5400,”“5450,” etc.

represented by this row. Normally the same
as NominalSecs, but can be different in three
cases:
• A sample logged “late” because of load
on the system
“Secs”
contained in this row, for example, to a “per-
second” measurement.
CentiSecs n/a Number of centiseconds in the logging INTEGER

percentage error.
NominalSecs n/a A specified or nominal number of seconds SMALLINT

in the logging period.
SummaryFlag n/a Identifies the summarization status of this CHAR

row. If the value is ‘N,’ the row is a non-
summary row. If the value is ‘S,’ the row is a
summary row.
In Summary Mode, the rows are
summarized into a single row. For details,
see “Summary Mode” on page 121.

Invalid
Active n/a Controls whether or not the rows will be FLOAT

modified data fields.
• a zero value, then none of the data fields
in the row have been updated during the
logging period.
For example, if Active Row Filter Mode is
enabled, then the rows that have a zero
Active field value will not be logged to the
ResUsage tables.
Note: For the current release, data
collection for the ResUsageSvdsk table
results in a non-zero value for all rows under
all conditions. Therefore, Active Row Filter
Mode is not in effect for this table.

interval. In the collect buffer, value is always
1. In the log buffer or the database table,
interval.
STATISTICS COLUMNS

Identify the vdisk I/O statistics that are reported from the FSG.
ReadCnt count Number of logical device reads. FLOAT
WriteCnt count Number of logical device writes. FLOAT
ReadKB count Number of KBs (1024 bytes) read from the FLOAT
logical device.
WriteKB count Number of KBs (1024 bytes) written to the FLOAT

logical device.
ReadRespTot count Total of individual read response time in FLOAT

centiseconds.
WriteRespTot count Total of individual write response time in FLOAT

centiseconds.
ReadRespMax count Maximum number of individual read FLOAT

WriteRespMax count Maximum number of individual write FLOAT


Invalid
ReadRespSq count Total of squares of the individual read FLOAT

WriteRespSq count Total of squares of the individual write FLOAT

ConcurrentReadMax count Maximum number of concurrent read I/O FLOAT

requests.
ConcurrentWriteMax count Maximum number of concurrent write I/O FLOAT

requests.
ConcurrentMax count Maximum number of concurrent I/O FLOAT

requests.
OutReqTime count Time with outstanding requests (busy time), FLOAT

in centiseconds.
Allocation Columns
Identify the allocation statistics reported by the Allocator.
ExtAllocHot count Number of hot allocations made in the FLOAT ALL

current log period. A “hot allocation” is an
within the pre-defined hot temperature
resides.
ExtAllocWarm count Number of warm allocations made in the FLOAT ALL

current log period. A “warm allocation” is
an allocation whose estimated temperature
falls within the pre-defined warm
temperature range. Each allocation is for a
cylinder size worth of data. The cylinder
resides in some disk storage location and
holds some data. Temperature is the
frequency of access to the data by I/O
independent of where the data resides.

Invalid
ExtAllocTotal count Total number of allocations made in the FLOAT ALL

current log period. For example, a number
of computations can be derived from this
attribute:
Cold Allocation = ExtAllocTotal –
ExtAllocHot – ExtAllocWarm
QueryPacing Allocation = ExtAllocTotal –
ExtAllocNonPacing – ExtAllocSystemPacing
Dynamic Allocation = ExtAllocTotal -
ExtAllocStatic
ExtAllocNonPacing count Number of non-pacing allocations made in FLOAT ALL

the current log period. A “non-pacing
affects neither system performance nor
individual query performance.
ExtAllocSystemPacing count Number of system pacing allocations made FLOAT ALL

in the current log period. A “system pacing
affects system performance.
ExtAllocStatic count Number of static allocations made in the FLOAT ALL

current log period. A “static allocation" is an
allocation whose requested temperature is
used and the measured temperature is
ignored during migration.
Migration Columns
Identify the number of cylinders that migrated to a different location on a device as well as the time, in centiseconds, of all
migration I/Os used, incurred, or saved during the log period.
ExtMigrateFaster count Number of cylinders migrated to faster FLOAT ALL

locations (that is, migrations whose gross
benefits are positive) for the associated AMP.
ExtMigrateSlower is the number of cylinders
migrated to slower locations. The following
calculation is used:
ExtMigrateTotal - ExtMigrateFaster
Extents are migrated to slower locations to
make room for hotter cylinders to replace
them.
ExtMigrateTotal count Total number of cylinders migrated to a FLOAT ALL

different physical location. For more
information, see the ExtMigrateFaster field.

Invalid
ExtMigrateIOTime count Response time in centiseconds. This field FLOAT ALL

adds the elapsed response time in
centiseconds of all I/Os used to migrate data
that completed during the log period.
Note: Response time, not service time, is
used.
ExtMigrateIOTimeCost count Estimates the total cost (in centiseconds) FLOAT ALL
incurred by migration I/Os completing
during the log period, where cost is the extra
time waited by all non-migration I/Os as a
result of the migration I/O. The Migrator
estimates migration costs.
Support.
ExtMigrateIOTimeBenefit count Estimates the total I/O time savings achieved FLOAT ALL
by migrations completing in the log period.
The I/O time savings include the
improvement in response time caused by the
new data arrangement up to the time
horizon.
This value does not include the cost of the
migration I/Os and is a gross benefit, not a
net benefit. The Migrator estimates the
migration benefit.
Support.
ExtMigrateIOTimeImprove count Estimates the percent improvement in FLOAT ALL

average IO response time due to migrations
completing in the log interval. In theory, this
percentage improvement is permanent. For
example, if, right before a particular log
interval, the average IO response time was
10 milliseconds (ms), then the Migration
logs an ExtMigrateIOTimeImprove value of
10% in this interval. The average IO
response time after the log interval should
be (100%-10%)*10ms = 9ms. Migration
then logs an ExtMigrateIOTimeImprove of
1% in the next interval. The average I/O
response time in the new log interval is
(100%-1%)*9ms = 8.91ms.

Summary Mode
Invalid
ExtMigrateIOTimeImprove ExtMigrateIOTimeImprove is only an

(continued) estimate. Its "permanent" improvement
remains in effect as long as the workload
does not change and newer migrations do
not significantly alter the data arrangement.
When the workload changes or new
migrations affect data arrangement,
response time changes in an un-quantified
way.
Despite this, ExtMigrateIOTimeImprove is
useful because it predicts actual system
performance at least for short periods of
time and can be used to understand why the
migration algorithm is doing what it is
doing.
Support.
Summary Mode
When Summary Mode is active for the ResUsageSvdsk table, one row is written to the database
for each node in the system, summarizing all AMP vdisk data in each node, for each log
interval.
that row:
‘N’ normally.

Spare Columns
Spare Columns
The ResUsageSvdsk table has thirty spare columns: ten count, ten track, and ten tmonitored
SpareTmon00-SpareTmon09.

CHAPTER 13 ResUsageSvpr Table
ResUsageSvpr logical table includes resource usage data for available system-wide, virtual
processor information.
The following table describes the ResUsageSvpr table columns.
Gather Invalid


entries might be logged “late” (typically, by no
more than one or two seconds), but this field
will still contain the time value when the entry
should have been logged. See the Secs and
NominalSecs columns.
cabinet number and MM denotes the two-digit
chassis number of the node. For example, a
node in chassis 9 of cabinet 3 has a node ID of
‘003-09’.
twice a year.
family type. For example, “5380,” “5400,”
“5450,” etc.

Chapter 13: ResUsageSvpr Table
Gather Invalid

Mode) or the Vproc type (Summary Mode; 0 =
NODE, 1 = AMP, 2 = PE, 3=GTW, 4=RSG).
The VprId can be any of the following
depending on the type:
• PE vprocs: numbered downward from
16383.
• NODE vprocs: numbered upward from
16384.
• RSG vprocs: numbered downward from
9215.
contiguous. Each existing vproc type range
should not overlap into the range of another
existing vproc type on the system.
VprType n/a Type of vproc. In non-Summary Mode, the CHAR(4)

values can be “NODE,” “AMP,” “PE,” “GTW,”
“RSG”. In Summary Mode, the values can be
“NODS,” “AMPS,” “PES,” “GTWS,” or “RSGS”.
Note: There is always exactly one Node vproc
per Node, so the row with VprType = ‘NODS’
actually “summarizes” a single vproc.

NominalSecs, but can be different in three
cases:
the system
“Secs”

This column is useful when performing data
NominalSecs n/a A specified or nominal number of seconds in SMALLINT

the logging period.

Gather Invalid

Possible values are ‘N’ if the row is a non-
summary row and ‘S’ if it is a summary row.
Active Controls whether or not the rows will be FLOAT

• a zero value, then none of the data columns
in the row have been updated during the
logging period.
enabled, then the rows that have a zero Active
tables.
for the ResUsageSvpr table results in a non-

interval. In the collect buffer, the value is
always 1. In the log buffer or the database table,
the value is the ratio of log interval to collect
interval.
You can determine average values per
collection period by dividing a column value
ending in “Sum” by CollectIntervals. For
example, to find the average number of work
requests waiting during a collect interval,
divide MsgWorkQLenSum by CollectIntervals.
STATISTICS COLUMNS

Represent CPU activities associated with this virtual processor, subdivided into 48 partitions. Partition 0 is reserved for use by
PDE processes. The other partitions, if used, are defined by the PDE or the TPA. See Attachment D: “Partition Assignments” for
more information.
Each entry below represents 48 columns, where [i] expands to the values 00 - 47, for example, CPUUservPart31.
For definitions of user service and user execution, see “Process Scheduling Columns” in the Chapter 5: “ResUsageScpu Table.”

Gather Invalid
CPUUServPart[i] tmon Time in centiseconds CPUs are busy in FLOAT

partition i doing user service. This is the system
level time spent on a process.
CPUUExecPart[i] tmon Time in centiseconds CPUs are busy in FLOAT

partition i doing user execution. This is the
user level time spent on a process.
Cylinder Read Columns

List the file system resource usage statistics. The Cylinder Read feature uses these statistics for tracking performance and
utilization.
FileFcrRequests count Total number of requests for the File System to FLOAT
use Cylinder Read.
This field is tracked and recorded by the File
System. It records the number of attempts to
use Cylinder Read independent of whether the
request will be issued to FSG or not. A request
can be denied due to insufficient data blocks or
because there is insufficient space in the FSG
cache. Requests can also be denied at both the
user and kernel level. Each of these items is
counted in other FileFcr ResUsage fields.
A number of calculations can be performed
using this field:
• Requests issued to FSG =
FileFcrRequests - FileFcrDeniedUser
• Successful Cylinder Reads =
FileFcrRequests - FileFcrDeniedUser -
FileFcrDeniedKern
FileFcrRequestsAdaptive count Number of adaptive requests from File System. FLOAT ALL
System. It records the number of requests for
adaptive-style Cylinder Reads.
Note: This field is not currently used.
FileFcrBlocksRead count Number of data blocks read in using Cylinder FLOAT

Read.
This field is tracked and recorded by the FSG
subsystem. It records the total number of data
blocks read in by successful Cylinder Read
operations.
The average number of data blocks in a
successful Cylinder read can be calculated as:
Average data blocks/ Cylinder Read =
FileFcrBlocksRead / (FileFcrRequests -
FileFcrDeniedUser - FileFcrDeniedKern)

Gather Invalid
FileFcrDeniedUser count Number of Cylinder Read requests denied by FLOAT

the File System.
System. It records the number of Cylinder Read
attempts that have been denied by the File
System. A request can be denied by the File
System due to insufficient number of data
blocks being requested (for example, the
FileFcrDeniedThreshUser field). For
information on the FileFcrDeniedThreshUser
field, see the following page.
FileFcrBlocksDeniedUser count Number of data blocks contained in the FLOAT

rejected requests for Cylinder Read.
System. It records the number of data blocks
that were part of attempts to use Cylinder Read
that were denied by the File System; therefore,
also incremented the FileFcrDeniedUser field.
FileFcrDeniedKern count Number of Cylinder Read requests denied by FLOAT

the FSG subsystem.
subsystem. It records the number of Cylinder
Read requests issued to the FSG subsystem
which, for any reason, have been denied. A
request can be denied due to insufficient data
blocks (for example, the
FileFcrDeniedThreshKern field) or because
there is insufficient space in the FSG cache (for
example, the FileFcrDeniedCache field). The
FSG subsystem can reject a request containing
insufficient data blocks that the File System
thought had enough blocks because the FSG
subsystem reduces the count by the number of
data blocks that are already resident in the
cache.
FileFcrBlocksDeniedKern count Number of data blocks contained in the FLOAT

rejected requests for Cylinder Read.
subsystem. It records the number of data
blocks that were part of attempts to use
Cylinder Read that were denied by the FSG
subsystem; therefore, also incremented the
FileFcrDeniedKern field.

Gather Invalid
FileFcrDeniedCache count Number of Cylinder Read requests denied by FLOAT

FSG due to insufficient cache.
This field is tracked and recorded by FSG. It
records the number of Cylinder Read requests
which have been denied due to insufficient FSG
cache space for a cylinders worth of data.
FileFcrBlocksDeniedCache count Number of data blocks contained in Cylinder FLOAT

Read requests rejected by the FSG subsystem
due to insufficient cache.
Cylinder read that were denied by the FSG
subsystem due to insufficient cache space;
therefore, also incremented the
FileFcrDeniedCache field.
FileFcrDeniedThreshUser count Number of Cylinder Read requests denied by FLOAT

the File System due to insufficient data blocks.
System. It records the number of Cylinder Read
requests which have been denied due to the
data block threshold criteria. There is a
minimum threshold of data blocks for an
individual Cylinder Read request. If the
number of data blocks is below this threshold,
the overhead of the Cylinder Read operation is
considered too large and issuing individual
data block reads is considered more efficient.
Therefore, the Cylinder Read request is denied.
FileFcrBlocksDeniedThreshUser count Number of data blocks contained in Cylinder FLOAT

Read requests rejected for threshold by the File
System.
System. It records the number of data blocks
that were part of attempts to use Cylinder Read
that were denied by the File System due to the
number of blocks being below the threshold;
therefore, also incremented the
FileFcrDeniedThreshUser field.

Gather Invalid
FileFcrDeniedThreshKern count Number of Cylinder Read requests denied by FLOAT

the FSG subsystem due to insufficient data
blocks.
subsystem. It records the number of Cylinder
Read requests which have been denied due to
the data block threshold criteria. There is a
minimum threshold of data blocks for an
individual Cylinder Read request. If the
number of data blocks is below this threshold,
the overhead of the Cylinder Read operation is
considered too large and issuing individual
data block reads is considered more efficient.
Therefore, the Cylinder Read request is denied.
FSG must reevaluate the threshold for a request
that the File System considered valid since FSG
eliminates any data blocks from the request list
that are already resident in the cache. This
could reduce the count that the File System
thought was above the threshold to one that is
now below.
FileFcrBlocksDeniedThreshKern count Number of data blocks contained in Cylinder FLOAT

Read requests rejected for threshold by the FSG
subsystem.
Cylinder read that were denied by the FSG
subsystem due to the number of blocks being
below the threshold; therefore, also
incremented the FileFcrDeniedThreshKern
field.
ChnSignal Status Tracking Columns

Track the chnsignal last done status (or track slowest vproc on the system for processing AMP steps).
MsgChnLastDone count The number of “last done” events that FLOAT

occurred for this vproc.
Note: The last AMP to finish an operation may
send a "last done" broadcast message indicating
the work is done for this step. This is used in
tracking down the slowest AMP in the system.
An AMP that has more "last done" messages
than the others could be a bottleneck in the
system performance.

Gather Invalid
Process Pending Counts and Wait Time Columns

Identify the number of processes blocked on database locks, and how long they were blocked.
ProcPendDBLock track Number of processes blocked pending database FLOAT

locks.
ProcBlksDBLock count Number of times processes blocked for FLOAT

database locks.
ProcWaitDBLock tmon Total time processes were blocked pending FLOAT ALL
database locks.
MEMORY COLUMNS
Memory Allocations Columns

These columns represent the number and amount of memory allocations specific to virtual processor activities, subdivided into
segment types. The columns do not include any memory allocations specific to the node the vproc is running under. Teradata
Database context amounts are not included since they can be calculated by multiplying the fixed page size by the number of page
allocations. Disk segment memory types are described by single entries below, each of which expands into six actual columns,
where [seg] is replaced as follows:
• PCi = Permanent cylinder index disk segments
• SDb = Regular or restartable spool data block disk segments
Mem[seg]Allocs count Number of successful memory allocations and FLOAT ALL

size-increasing memory alters on disk
segments.
Mem[seg]AllocKB count Total KBs attributed to allocations and size- FLOAT ALL
increasing memory alters for disk segments.
MemCtxtAllocs count Number of successful memory allocations and FLOAT

size-increasing memory alters on task context
pages.
Note: Only scratch pages will get allocated. All
other task context pages will appear resident at
some point soon after component restart.

Gather Invalid
Memory Resident Columns

Represent the amount of memory resident specific to virtual processor activities, subdivided into memory types. The columns do
not include any memory allocations specific to the node the vproc is running under.
Disk memory segments can be in one of four states:
• Clean (unmodified) and Unaccessed by any process (CU)
• Dirty (modified) and Unaccessed (DU)
• Clean and Accessed (CA)
• Dirty and Accessed (DA).
Permanent segments for an entire table can be “user-locked-in” to memory. These are called frozen segments (Frz), and no state
subdivision is necessary because they cannot be aged or forced out of memory.
‘Regular’ disk segment memory types are described by single entries below, each of which expands into six actual columns, where
[seg] is replaced as follows:
• TJt =Transient journal table or WAL data block or WAL cylinder index
• Base = Data block disk segments on individual vproc basis
MemCtxtRes track Current pages resident in memory for task FLOAT ALL
context segments.
MemPKBResFrz track Current KBs resident in memory for frozen FLOAT ALL
segments.
Mem[seg]KBResCU track Current KBs resident in memory for regular FLOAT ALL
disk segments that are currently clean and not
accessed.
Note: MemBaseKBResCU tracks of the sum of
the data block sizes in the FSG cache (for both
general purpose preloads and cylinder read
preloads).
Mem[seg]KBResDU track Current KBs resident in memory for regular FLOAT ALL
disk segments that are currently dirty and
unaccessed.
Mem[seg]KBResCA track Current KBs resident in memory for regular FLOAT ALL
disk segments that are currently clean and
accessed.
Mem[seg]KBResDA track Current KBs resident in memory for regular FLOAT ALL
disk segments that are currently dirty and
accessed.

Gather Invalid
Paging Columns
Identify paging activities on pages containing Teradata Database context pages only.
MemCtxtPageReads count Number of task context pages that were paged FLOAT WINDOWS
in. LINUX
MemCtxtPageWrites count Number of task context pages that were paged FLOAT WINDOWS
out. LINUX
Swapping Columns
Identify the effects on disk segments when all processes accessing them get swapped out.
MemSwapDrops count Number of disk segments that were dropped FLOAT ALL
from memory because all accessor processes
were swapped out.
MemSwapDropKB count KBs dropped from memory by FLOAT ALL

MemSwapDrops.
MemSwapReads count Number of disk segments that were re-read FLOAT ALL
when they were previously dropped from
memory because all accessor processes were
swapped out.
MemSwapReadKB count KBs re-read from memory by MemSwapReads. FLOAT ALL
Task Context Segment Usage Columns

Identify the usage of task context segments and how they leave memory.
MemCtxtAccesses count Number of segments accessed. FLOAT
MemCtxtAccessKB count KBs of segments accessed. FLOAT
MemCtxtDeaccesses count Number of segments deaccessed. (Deaccessed FLOAT

segments remain in memory until paged out
through aging.)
MemCtxtDeaccessKB count KBs of segments deaccessed. FLOAT
MemCtxtDestroys count Number of segments destroyed. (Destroyed FLOAT

segments are immediately dropped from
memory.)
MemCtxtDestroyKB count KBs of segments destroyed. FLOAT
NET COLUMNS
Point-to-Point Net Traffic Columns

Identify the number (Reads, Writes) and amount (ReadKB, WriteKB) of input and output messages passing through either
Teradata Database net through point-to-point (1:1) methods (PtP)
NetPtPReads count Number of point-to-point messages input to FLOAT

the vproc.

Gather Invalid
NetPtPWrites count Number of point-to-point messages output FLOAT

from the vproc.
NetPtPReadKB count Total KBs of point-to-point messages input to FLOAT

the vproc.
NetPtPWriteKB count Total KBs of point-to-point messages output to FLOAT

the vproc.
Broadcast Net Traffic Columns

Identify the number (Reads, Writes) and amount (ReadKB, WriteKB) of input and output messages passing through the Teradata
Database nets through broadcast (1:many) methods (Brd) per net.
NetBrdReads count Number of broadcast messages input to the FLOAT

vproc.
NetBrdWrites count Number of broadcast messages output from FLOAT

the vproc.
NetBrdReadKB count Total KBs of broadcast messages input to the FLOAT

vproc.
NetBrdWriteKB count Total KBs of broadcast messages output from FLOAT

the vproc.
Work Mailbox Queue Columns

Identify the virtual processor work mailbox queue length where requested work awaits the allocation of a process to perform the
work.
MsgWorkQLenSum count Total number of work requests waiting during FLOAT

each log interval.
The Sum count tracks the current count at the
end of each collect period and sums the counts
over the log period.
Note: To calculate the average work requests
waiting, divide this value by the
CollectIntervals value. Since CollectIntervals is
the number of collect periods per logging
period, the resulting number is the average
value per logging period. For more
information, see the CollectIntervals column.
MsgWorkQLenMax track Maximum number of work requests waiting FLOAT

The Max count, unlike the Sum count, tracks
the maximum count over the log period.
Therefore the Sum count can be 0 even though
the Max count can be non-zero over the log
period.

Gather Invalid
Database Locks Columns

Identify database locking activities.
DBLockEnters count Number of times a database lock was entered FLOAT

for holding.
DBLockBlocks count Number of times a database lock was blocked. FLOAT
DBLockDeadlocks count Number of times a database lock was FLOAT

deadlocked.
DBLockBlocksSum count Total number of requests blocked on database FLOAT ALL

locks during each log interval.
To calculate the average number of requests
blocked, divide this value by the
CollectIntervals value. Since the
CollectIntervals is the number of collect
periods per logging period, the resulting
number is the average value per logging period.
DBLockBlocksMax track Maximum number of requests blocked on FLOAT ALL

database locks during each log interval.
DBLocksHeldSum count Total number of database locks held during FLOAT ALL
each log interval.
To calculate the average number of database
locks held, divide this value by the
CollectIntervals value. Since the
CollectIntervals is the number of collect
periods per logging period, the resulting
number is the average value per logging period.
DBLocksHeldMax track Maximum number of database locks held FLOAT ALL

FILE SYSTEM COLUMNS
Segment Acquires Columns

Identify the total disk memory segments acquired by the file system during the log period. Logical acquires (Acqs) and the logical
amount acquired (AcqKB) are identified. Acquires causing physical reads (AcqReads) and the amount read (AcqReadKB) are
identified as a subset of logical acquires. Disk segment memory types are described by single entries below, each of which
expands into six actual columns, where [seg] is replaced as follows:

Gather Invalid
File[seg]Acqs count Total number of disk segments acquired. FLOAT
File[seg]AcqKB count Total KBs acquired by File[seg]Acqs. FLOAT
File[seg]AcqReads count Number of disk segment acquires that caused a FLOAT

physical read.
File[seg]AcqReadKB count KBs physically read by File[seg]AcqReads. FLOAT
Data Block Prefetches Columns

Identify File Segment Prefetch activities. File segment prefetches are described by single entries below, each of which expands into
six actual columns, where [seg] is replaced as follows:
• Base = Data block disk segments on individual vproc basis
File[seg]Pres count Total number of disk segments prefetched. FLOAT
File[seg]PresKB count Total number of KBs prefetched by FLOAT

File[seg]Pres.
File[seg]PreReads count Total number of disk segment prefetches that FLOAT

caused a physical read.
File[seg]PreReadKB count Total number of KBs physically read by FLOAT

File[seg]PreReads.
Segments Released Columns

Identify the total disk memory segments released by the file system, as well as those segments that are dropped from memory
during the log period. When a segment is released, the segment is either:
• Forced out of memory (F)
• Remains resident in memory (R)
• Aged out of memory (A), from segments that remain resident
Both the number of segments (Rels, Writes, Drps) and the size of the segments (RelKB,WriteKB, DrpKB) are counted. When a
segment leaves memory, it must be written to disk only if the segment is dirty, that is, modified (Dy). Otherwise, the clean, that
is, unmodified (Cn) segment is simply dropped.
(Most spool blocks are simply dropped from a task and put on the age queue. This may happen multiple times. Each of these will
be counted as a resident release. If the system is low on memory and the age queue must be processed, this may also result in an
age write or age drop. Forced writes are always also counted as either clean resident releases or forced drops, depending on
whether age normal or age out now was specified.)
Disk segment memory types are described by single entries below, each of which expands into six actual columns, where [seg] is
replaced as follows:

Gather Invalid

File[seg]DyRRels count Number of dirty disk segment resident releases. FLOAT
File[seg]DyRRelKB count KBs released by File[seg]DyRRels. FLOAT
File[seg]FWrites count Number of disk segment forced releases or FLOAT

specific I/O requests causing an immediate
physical write. Includes spool data that is aged
out immediately and permanent data that is
written immediately.
File[seg]FWriteKB count KBs written by File[seg]FWrites. FLOAT
File[seg]DyAWrites count Number of dirty disk segments aged out of FLOAT

memory causing a delayed physical write.
These only apply to segments in the memory
cache. That is, they are no longer accessed by a
task. If memory is needed, these segments are
discarded and depending on whether the
segments are modified or not, they will be
counted as dirty writes or clean drops.
File[seg]DyAWriteKB count KBs written by File[seg]DyAWrites. FLOAT
File[seg]CnRRels count Number of clean disk segment resident FLOAT

releases.
File[seg]CnRRelKB count KBs released by File[seg]CnRRels. FLOAT
File[seg]FDrps count Number of disk segment forced releases FLOAT

causing an immediate memory drop. Segments
that are never to be part of the memory cache
(the age queue) are counted as forced drops.
File[seg]FDrpKB count KBs dropped by File[seg]FDrps. FLOAT
File[seg]CnADrps count Number of clean disk segments aged out of FLOAT

memory. See File[seg]DyAWrites, above.
File[seg]CnADrpKB count KBs dropped by File[seg]CnADrps. FLOAT
Data Segment Lock Requests Columns

Identify the number of lock requests on a disk segment, including those implied for segment acquires.
FileLockEnters count Number of lock requests on disk segments. FLOAT
FileLockBlocks count Number of lock requests that were blocked. FLOAT

(Total locks - locks blocked = locks with
immediate grants.)

Gather Invalid
FileLockDeadlocks count Number of deadlocks detected on lock FLOAT

requests.
Cylinder Management Overhead Events Columns

Identify the number of times the file system software performed a cylinder management event. The table ResUsageIvpr further
breaks down the I/Os associated with these events. See Appendix C: “ResUsageIvpr Table.”
FileCylAllocs count Number of new cylinders allocated. FLOAT

Note: A new cylinder allocation event implies
one logical cylinder index read and one logical
cylinder index write.
FileCylFrees count Note: This field is not currently used. FLOAT ALL
FileCylMigrs count Number of cylinder migrations. FLOAT
FileMCylPacks count Number of mini-cylpacks performed. FLOAT
FileCylDefrags count Number of cylinder defragments performed. FLOAT
Synchronized Full File Scans Columns

Contain statistics relating to synchronized full-file scans.
Note: The following columns have been moved from ResUsageIvpr to ResUsageSvpr to avoid costly joins.
FileSyncScans count Number of attempts to synchronize a full file FLOAT

scan.
FileSyncSubtables track Number of subtables scanned by one or more FLOAT

full file scanners who are willing to synchronize
scans.
FileSyncScanners track Number of tasks involved in full file scans who FLOAT
are willing to synchronize with other scanners.
FileSyncGroups track Number of groups of scanners involved in full FLOAT

file scans. A group consists of scanners who are
able to use the same read I/O to obtain data
from disk.
Write Ahead Logging Columns

Identify the log-based file system recovery scheme in which modifications to permanent data are written to a log file, the WAL
log.
FileWCylAllocs count Number of new WAL cylinders allocated. FLOAT
FileWCylFrees count Number of times the file system frees a WAL FLOAT ALL
cylinder.

Gather Invalid
Allocation Columns
Identify the allocation statistics reported by the Allocator.
AllocatorExtentAllocReqs count Number of cylinder allocation requests FLOAT ALL

received by the allocator.
AllocatorExtentFreeReqs count Number of cylinder free requests received by FLOAT ALL

the allocator.
AllocatorMapIOsStarted count Number of map I/Os initiated by the allocator. FLOAT ALL
AllocatorMapIOsDone count Number of map I/Os completed by the FLOAT ALL

allocator.
Node Agent Columns

Identify the migration and buffer processing statistics reported by the Node Agent.
NodeAgentMigrationsStarted count Number of migration requests started by the FLOAT ALL

Node Agent.
NodeAgentMigrationsDone count Number of migration requests completed by FLOAT ALL

the Node Agent.
NodeAgentStatProcessed count Number of statistics buffers processed by the FLOAT ALL

Node Agent.

Identify the I/O statistics reported by the extent driver.
ReadsHot count Total number of reads issued to all cylinders FLOAT ALL
that are considered HOT.
ReadsWarm count Total number of reads issued to all cylinders FLOAT ALL
that are considered WARM.
ReadsCold count Total number of reads issued to all cylinders FLOAT ALL
that are considered COLD.
WritesHot count Total number of writes issued to all cylinders FLOAT ALL
WritesWarm count Total number of writes issued to all cylinders FLOAT ALL
WritesCold count Total number of writes issued to all cylinders FLOAT ALL
ReadResponseHotTotal count Total read response time of all cylinders that FLOAT ALL
are considered HOT.

Gather Invalid
ReadResponseWarmTotal count Total read response time of all cylinders that FLOAT ALL
are considered WARM.
ReadResponseColdTotal count Total read response time of all cylinders that FLOAT ALL
are considered COLD.
WriteResponseHotTotal count Total write response time of all cylinders that FLOAT ALL
are considered HOT.
WriteResponseWarmTotal count Total write response time of all cylinders that FLOAT ALL
are considered WARM.
WriteResponseColdTotal count Total write response time of all cylinders that FLOAT ALL
are considered COLD.
ReadResponseHotMax count Maximum read response time of all cylinders FLOAT ALL
ReadResponseWarmMax count Maximum read response time of all cylinders FLOAT ALL
ReadResponseColdMax count Maximum read response time of all cylinders FLOAT ALL
ReadResponseHotMin count Minimum read response time of all cylinders FLOAT ALL
ReadResponseWarmMin count Minimum read response time of all cylinders FLOAT ALL
ReadResponseColdMin count Minimum read response time of all cylinders FLOAT ALL
WriteResponseHotMax count Maximum write response time of all cylinders FLOAT ALL
WriteResponseWarmMax count Maximum write response time of all cylinders FLOAT ALL
WriteResponseColdMax count Maximum write response time of all cylinders FLOAT ALL
WriteResponseHotMin count Minimum write response time of all cylinders FLOAT ALL
WriteResponseWarmMin count Minimum write response time of all cylinders FLOAT ALL
WriteResponseColdMin count Minimum write response time of all cylinders FLOAT ALL

Obsolete Columns
Obsolete Columns
In addition to the columns designated as not yet available in the preceding pages, the
following columns should not be used because they have been renamed or made obsolete.
Backup AMP Traffic Columns

• Mem[seg]BackCWrites
• Mem[seg]BackPWrites
• Mem[seg]BackWriteKB
Summary Mode
When Summary Mode is active for the ResUsageSvpr table, one row per physical table is
written to the database for each type of vproc on each node in the system, summarizing the
that row:
‘N’ normally.
Spare Columns
The ResUsageSvpr table has 30 spare columns: 10 count, 10 track, and 10 tmonitored columns
where [i] is expanded to be the values 00-09 for SpareCount, SpareTrack, and SpareTmon. For
example, column names could be SpareCount08, SpareTrack04, or SpareTmon09.

Spare Columns
Note: SpareCount04 is temporarily used to contain the maximum I/O time, in milliseconds,
caused by long I/O (Reads, Writes) operations for each AMP vproc on that node. This field is
valid on Windows and Linux only.

Spare Columns

SECTION 3 Views and Macros

Section 3: Views and Macros

CHAPTER 14 Resource Usage Views
This chapter provides the listings of the following resource usage views:
• ResGeneralInfoView
• ResCPUUsageByAMPView
• ResCPUUsageByPEView
• ResShstGroupView
• ResSldvGroupView
• ResVdskGroupView
To see the view definitions, execute SHOW VIEW viewname, where viewname is the name of
the view whose most recent SQL create text is to be reported.
For details on using the SHOW VIEW statement, see SQL Reference: Data Definition
Statements.
The following views report the new table column, GroupId. A homogenous system requires
no changes to use this macro because all the nodes will be assigned to group "A". For a
coexisting system, however, the values need to be set up when the system is installed or
reconfigured so that each type of node is assigned to a specific group ID. For the easiest setup,
let the group with the fewest nodes be assigned under the "WHEN" clause and the group with
most nodes be assigned via the "ELSE" clause in the case statement.
Caution: Do not change or delete fields in these views. If fields are modified, the resource usage macros
that use these views may not work properly. You can, however, safely add fields.
ResGeneralInfoView
ResGeneralInfoView provides an overview of system operation. The definition is given below.
REPLACE VIEW DBC.ResGeneralInfoView
( TheDate, TheTime, Secs, NodeId, GroupId, NCPUs,
CPUBusy, CPUOpSys, CPUUser, CPUWaitIO, DiskSegmentIO,
LogicalDeviceIO, LogicalDeviceReads, LogicalDeviceWrites,
LogicalDeviceReadKB, LogicalDeviceWriteKB,
MemAgings,
MemCtxtPageReads, MemCtxtPageWrites,
MemFails, MemFreeKB, MemProcSwapped,
MemSize,
MemSwapDropKB,
MemSwapDrops,
MemSwapReadKB,
MemSwapReads,
MemTextAllocs, MemTextPageDrops,
MemTextPageReads,

Chapter 14: Resource Usage Views
ResGeneralInfoView
MemVprAllocs, MemVprAllocKB,
NetAttempts,
NetBackoffs, NetChannelSR, NetMultiIO, NetPtoPIO,
NetReadKB, NetReads, NetWriteKB, NetWrites,
NetRxConnected, NetTxConnected, NetTxRouting,
NetTxIdle, NetRxIdle, NetSamples,
PageOrSwapIO, ProcActiveAvg, ProcBlksDBLock, ProcBlockedAvg,
ProcBlocks, ProcWaits,
UserStmtsArriving, UserStmtsInProgress
)
AS SELECT TheDate, TheTime, Secs,

/* NodeId */
NodeID(FORMAT '999-99'),
/* GroupId */
CASE
WHEN NodeId IN ('001-01', '001-03', '001-05') THEN 'A '
WHEN NodeId IN ('001-02', '001-04', '001-06') THEN 'A'
ELSE 'A'
END,
/* NCPUs */
NCPUs,
/* CPUBusy */
( (CPUUServ + CPUUExec) / NULLIFZERO(NCPUs) ),
/* CPUOpSys */
( CPUUServ / NULLIFZERO(NCPUs) ),
/* CPUUser */
( CPUUExec / NULLIFZERO(NCPUs) ),
/* CPUWaitIO */
( CPUIoWait / NULLIFZERO(NCPUs) ),
/* DiskSegmentIO */
( FileAcqReads + FilePreReads + FileWrites ),
/* LogicalDeviceIO */
( FileAcqReads + FilePreReads + FileWrites +
MemTextPageReads + MemCtxtPageReads + MemCtxtPageWrites +
MemSwapReads ),
/* LogicalDeviceReads */
( FileAcqReads + FilePreReads +
MemTextPageReads + MemCtxtPageReads + MemSwapReads ),
/* LogicalDeviceWrites */
( FileWrites + MemCtxtPageWrites ),
/* LogicalDeviceReadKB */
( FileAcqReadKB + FilePreReadKB +
/* paging or swapping count times pagesize (= 4K) */
(MemTextPageReads + MemCtxtPageReads + MemSwapReads) * 4 ),
/* LogicalDeviceWriteKB */
( FileWriteKB +
/* paging or swapping count times pagesize (= 4K) */
MemCtxtPageWrites*4 ),
/* MemAgings */
MemAgings,
/* MemCtxtPageReads */
MemCtxtPageReads,
/* MemCtxtPageWrites */
MemCtxtPageWrites,
/* MemFails */
MemFails,
/* MemFreeKB */
MemFreeKB,

ResGeneralInfoView
/* MemProcSwapped */
MemProcSwapped,
/* MemSize */
MemSize,
/* MemSwapDropKB */
MemSwapDropKB,
/* MemSwapDrops */
MemSwapDrops,
/* MemSwapReadKB */
MemSwapReadKB,
/* MemSwapReads */
MemSwapReads,
/* MemTextAllocs */
MemTextAllocs,
/* MemTextPageDrops */
MemTextPageDrops,
/* MemTextPageReads */
MemTextPageReads,
/* MemVprAllocs */
MemVprAllocs,
/* MemVprAllocKB */
MemVprAllocKB,
/* NetAttempts */
( NetTxCircPtP + NetTxCircBrd ) (FORMAT 'ZZZZZZ9'),
/* NetBackoffs */
( NetCircBackoffs ) (FORMAT 'ZZZZZZ9'),
/* NetChannelSR */
0,
/* NetMultiIO */
( NetMsgBrdReads + NetMsgBrdWrites ),
/* NetPtoPIO */
( NetMsgPtPReads + NetMsgPtPWrites ),
/* NetReadKB */
( NetMsgBrdReadKB + NetMsgPtPReadKB ),
/* NetReads */
( NetMsgBrdReads + NetMsgPtPReads ),
/* NetWriteKB */
( NetMsgBrdWriteKB + NetMsgPtPWriteKB ),
/* NetWrites */
( NetMsgBrdWrites + NetMsgPtPWrites ),
/*Including these columns to restore Net Chan Busy % column in
reports */
/* NetRxConnected */
NetRxConnected,
/* NetTxConnected */
NetTxConnected,
/* NetTxRouting */
NetTxRouting,
/* NetTxIdle */
NetTxIdle,
/* NetRxIdle */
NetRxIdle,
/* NetSamples */
NetSamples,
/* PageOrSwapIO */
( MemTextPageReads + MemCtxtPageReads + MemCtxtPageWrites +
MemSwapReads ),
/* ProcActiveAvg */

ResCPUUsageByAMPView
( ProcBlockedSum + ProcReadySum + ProcRunningSum )/NULLIFZERO

(CollectInt
ervals),
/* ProcBlksDBLock */
ProcBlksDBLock,
/* ProcBlockedAvg */
ProcBlockedSum/NULLIFZERO(CollectIntervals) (FORMAT 'ZZZZZZ9'),
/* ProcBlocks */
( ProcBlksDBLock + ProcBlksMemAlloc + ProcBlksMisc +
ProcBlksMonitor + ProcBlksMonResume +
ProcBlksSegLock + ProcBlksNetThrottle +
ProcBlksFsgLock + ProcBlksFsgRead + ProcBlksFsgWrite )
(FORMAT 'ZZZZZZ9'),
/* ProcWaits */
( ProcWaitDBLock + ProcWaitMemAlloc + ProcWaitMisc +
ProcWaitMonitor + ProcWaitMonResume +
ProcWaitSegLock + ProcWaitNetThrottle + ProcWaitPageRead +
ProcWaitFsgLock + ProcWaitFsgRead + ProcWaitFsgWrite )
(FORMAT 'ZZZZZZ9'),
/* UserStmtsArriving */
( CmdDDLStmts + CmdDeleteStmts + CmdInsertStmts +
CmdSelectStmts +
CmdUpdateStmts + CmdUtilityStmts + CmdOtherStmts ),
/* UserStmtsInProgress */
CmdStmtsInProgCur
ResCPUUsageByAMPView describes CPU usage per AMP. The definition is given below:
REPLACE VIEW DBC.ResCPUUsageByAMPView
( TheDate, TheTime, Vproc, NodeId, Secs, NCPUs, GroupId,
AMPWorkTaskExec, AMPWorkTaskServ,
AMPMiscUserExec, AMPMiscUserServ,
AMPTotalUserExec, AMPTotalUserServ )
AS SELECT TheDate, TheTime, VprId, NodeID, Secs, NCPUs,

/* GroupId */
CASE
ELSE 'A'
END,
/* AMPWorkTaskExec */
CPUUExecPart11,
/* AMPWorkTaskServ */
CPUUServPart11,
/* AMPMiscUserExec*/
( CPUUExecPart01+CPUUExecPart02+CPUUExecPart03 +
CPUUExecPart04+CPUUExecPart05+CPUUExecPart06+CPUUExecPart07 +
CPUUExecPart08+CPUUExecPart09+CPUUExecPart10 +

CPUUExecPart44+CPUUExecPart45+CPUUExecPart46+CPUUExecPart47),
/* AMPMiscUserServ */
( CPUUServPart01+CPUUServPart02+CPUUServPart03 +
CPUUServPart04+CPUUServPart05+CPUUServPart06+CPUUServPart07 +
CPUUServPart08+CPUUServPart09+CPUUServPart10 +
CPUUServPart44+CPUUServPart45+CPUUServPart46+CPUUServPart47),
/* AMPTotalUserExec */
(CPUUExecPart00+CPUUExecPart01+CPUUExecPart02+CPUUExecPart03 +
/* AMPTotalUserServ */
(CPUUServPart00+CPUUServPart01+CPUUServPart02+CPUUServPart03 +
CPUUServPart44+CPUUServPart45+CPUUServPart46+CPUUServPart47)
FROM ResUsageSvpr WHERE VprType like 'AMP%' WITH CHECK OPTION;

ResCPUUsageByPEView
ResCPUUsageByPEView
ResCPUUsageByPEView describes CPU usage by each PE. The definition is given below:
REPLACE VIEW DBC.ResCPUUsageByPEView
( TheDate, TheTime, Vproc, NodeId, Secs, NCPUs, GroupId,
PEDispExec, PEDispServ, PEParsExec, PEParsServ, PESessExec, PESessServ,
PEMiscUserExec, PEMiscUserServ, PETotalUserExec, PETotalUserServ )
AS SELECT TheDate, TheTime, VprId, NodeID(FORMAT'999-99'), Secs, NCPUs,

/* GroupId */
CASE
ELSE 'A'
END,
/* PEDispExec */
CPUUExecPart13,
/* PEDispServ */
CPUUServPart13,
/* PEParsExec */
CPUUExecPart14,
/* PEParsServ */
CPUUServPart14,
/* PESessExec */
CPUUExecPart12,
/* PESessServ */
CPUUServPart12,
/* PEMiscUserExec */
( CPUUExecPart01+CPUUExecPart02+CPUUExecPart03 +
CPUUExecPart15 +
/* PEMiscUserServ */
( CPUUServPart01+CPUUServPart02+CPUUServPart03 +
CPUUServPart15 +
CPUUServPart44+CPUUServPart45+CPUUServPart46+CPUUServPart47),
/* PETotalUserExec */
(CPUUExecPart00+CPUUExecPart01+CPUUExecPart02+CPUUExecPart03 +

ResShstGroupView
/* PETotalUserServ */
(CPUUServPart00+CPUUServPart01+CPUUServPart02+CPUUServPart03 +
CPUUServPart44+CPUUServPart45+CPUUServPart46+CPUUServPart47)
FROM ResUsageSvpr WHERE VprType like 'PE%' WITH CHECK OPTION;
ResShstGroupView
ResShstGroupView is based on the ResUsageShst table. The definition is given below:
REPLACE VIEW DBC.ResShstGroupView
( TheDate, TheTime, NodeId, VprId, HstId, HstType, Secs, NominalSecs,
GroupId, CollectIntervals,
HostBlockReads, HostBlockWrites,
HostMessageReads, HostMessageWrites,
HostReadKB, HostWriteKB,
HostQLenSum, HostQLenMax,
HostReadFails, HostWriteFails
)
AS SELECT TheDate, TheTime, NodeId, VprId, HstId, HstType, Secs,

NominalSecs,
/* GroupId */
CASE
ELSE 'A'
END,
CollectIntervals,
HostBlockReads, HostBlockWrites,
HostMessageReads, HostMessageWrites,
HostReadKB, HostWriteKB,
HostQLenSum, HostQLenMax,
HostReadFails, HostWriteFails
FROM ResUsageShst WITH CHECK OPTION;

ResSldvGroupView
ResSldvGroupView
ResSldvGroupView is based on the ResUsageSldv table. The definition is given below:
REPLACE VIEW DBC.ResSldvGroupView

( TheDate, TheTime, NodeId, VprId, LdvId, LdvType, Secs, NominalSecs,
GroupId, CollectIntervals,
LdvOutReqSum,
LdvReads, LdvWrites,
LdvReadKB, LdvWriteKB,
LdvReadRespTot, LdvWriteRespTot,
LdvReadRespMax, LdvWriteRespMax,
LdvConcurrentMax, LdvOutReqMax, LdvOutReqTime
)
AS SELECT TheDate, TheTime, NodeId, VprId, LdvId, LdvType, Secs,

NominalSecs,
/* GroupId */
CASE
ELSE 'A'
END,
CollectIntervals,
LdvOutReqSum,
LdvReads,
LdvWrites,
LdvReadKB,
LdvWriteKB,
LdvReadRespTot,
LdvWriteRespTot,
LdvReadRespMax,
LdvWriteRespMax,
LdvConcurrentMax,
LdvOutReqMax,
LdvOutReqTime
FROM ResUsageSldv WITH CHECK OPTION;
ResVdskGroupView
ResVdskGroupView is based on the ResUsageSvdsk table. The definition is given below:
REPLACE MACRO DBC.ResVdskByGroup
( FromDate (DATE, DEFAULT DATE, FORMAT 'YYYY-MM-DD'),
ToDate (DATE, DEFAULT DATE, FORMAT 'YYYY-MM-DD'),
FromTime (FLOAT, DEFAULT 0, FORMAT'99:99:99'),
ToTime (FLOAT, DEFAULT 999999, FORMAT'99:99:99')
)
AS (
echo '.set heading "&DATE||VDISK TRAFFIC BY GROUP||Page&PAGE"';
echo '.set format on';
echo '.set suppress on 1, 2, 3';
echo '.set width 132';

ResVdskGroupView
SELECT TheDate (FORMAT'yy/mm/dd') (TITLE '// // Date'),

NodeType (TITLE '//Node//Type'),
TheTime (FORMAT'99:99:99') (TITLE '// // Time'),
/* Reads per second */

SUM(Reads)/(SUM(CentiSecs)/100)
(FORMAT 'ZZZZ9.99') (TITLE '// Reads// / Sec'),
/* Writes per second */

SUM(Writes)/(SUM(CentiSecs)/100)
(FORMAT 'ZZZZ9.99') (TITLE '// Writes// / Sec'),
/* Read KB per I/O */

SUM(ReadKB)/NULLIFZERO(SUM(Reads))
(FORMAT 'ZZZ9.99') (TITLE '//Rd KB// / I/O'),
/* Write KB per I/O */

SUM(WriteKB)/NULLIFZERO(SUM(Writes))
(FORMAT 'ZZZ9.99') (TITLE '//Wrt KB// / I/O'),
/* Average I/O response time */

SUM(ReadRespTot+WriteRespTot)/100/NULLIFZERO(SUM(Reads+Writes))
(FORMAT 'ZZ9.999') (TITLE ' Avg// I/O// Resp'),
/* Max number of concurrent requests */

AVG(ConcurrentMax)
(FORMAT 'ZZ9.9') (TITLE ' Max//Concur//Rqsts'),
/* Percent of time there was any outstanding request */

(SUM(OutReqTime)/SUM(CentiSecs))*100
(FORMAT 'ZZ9.9%') (TITLE ' Out// Rqst//Time %')
FROM ResUsageSvdsk
WHERE ( ( ( TheDate = :FromDate AND TheTime >= :FromTime ) OR

( TheDate > :FromDate )
) AND
( ( TheDate = :ToDate AND TheTime <= :ToTime ) OR
( TheDate < :ToDate )
)
)
GROUP BY TheDate, NodeType, TheTime
ORDER BY TheDate, NodeType, TheTime;
echo '.set suppress off';

echo '.set format off';
) ; /* end of MACRO ResVdskByGroup */

;

ResVdskGroupView

CHAPTER 15 Resource Usage Macros
This chapter describes the output format of the resource usage macros and each macro.
The resource usage macros consist of the following sets of macros:
• ResAWT macros (summarizes all the AWTs in use for all nodes, by AMP, or by node
during a logging period)
• ResCPUByAMP macros (CPU use by AMPs)
• ResCPUByPE macros (CPU use by PEs)
• ResCPUByNode macros (CPU use by each node)
• ResHostByLink macros (host communications traffic)
• ResLdvByNode macros (raw disk drive traffic)
• ResVdskByNode macros (vdisk logical device traffic)
• ResMemMgmtByNode macros (memory allocation, paging, and swapping)
• ResNetByNode macros (node network traffic)
• ResNode macros (summarizes resource usage for all nodes, a specific node, or node by
node during a logging period)
• ResPs macros (summarizes Priority Scheduler and Teradata ASM resource usage)
• ResPsCPU macros (summarizes Teradata ASM workload CPU use versus the relative
weights of their associated Allocation Groups)
Note: The ResPdskByNode macro is not currently used.
Macro Output Format

Resource usage macros provide output in the following general format:
<Report Date> <Title of Report> Page <num>
---------------
1st 2nd 1st 2nd 3rd
Date Time Type Id Id Stat Stat Stat ...
-------- -------- ---- ------ ------ ------- -------- --------
99/99/99 99:99:99 AAAA 999-99 999-99 999.99% 99999.99 99999.99
999.99% 99999.99 99999.99
...........
AAAA 999-99 999-99 999.99% 99999.99 99999.99
999-99 999-99 999.99% 99999.99 99999.99
99:99:99 AAAA 999-99 999-99 999.99% 99999.99 99999.99
...........

Chapter 15: Resource Usage Macros
Macro Output Format
where:
Column Description
Date The date at the end of a log interval.
Time The time at the end of a log interval. Statistics on each line cover the time
period ending at the indicated time.
Type A virtual processor type, logical device type, host type, or a special type
for certain reports.
1st ID, 2nd ID, etc. The appropriate identifier, which varies, depending on the macro. It is
one or more of the following:
• NodeID
• VprocID
• HostID
• GroupID
1st Stat, 2nd Stat, etc. The appropriate statistics. Details are given with the descriptions of each
macro in this chapter.
Numbers are generally displayed with the appropriate fixed format (for
example, 'zzzz9.99') unless the number represents a percentage or sum of
percentages.
Percentages are displayed with the appropriate format (for example,
'zz9.9%', 'zz9' or 'zz9.99').
Unless otherwise specified, all statistical numbers are expressed as either:

• Percentage
• Milliseconds (ms)
• Kilobytes (KBs)
Columns whose values depend on the logging rate are never reported as raw data. Instead,
they are converted to a normalized value, such as per second.
All reports are ordered by date, time, type, 1st ID, 2nd ID, and so forth. Repeated date, time,
type, and ID column values are suppressed until a new row presents a different value.
Question Marks
Question marks used as values in the output examples are generated when a division by zero is
made. It represents data that is not available. The numbers in the columns are calculated, for
example, by dividing KBs by number of blocks read. When there are no blocks read, KB is
divided by zero. A question mark does not mean there is an error, but indicates that there is no
information to report for this time period.

ResAWT Macros
Usage Notes
The following usage notes apply to all macros:
• To get current data, logging must be enabled on the ResUsage table used by the view or
macro.
• The SPMA and SCPU tables use the Node Logging rate, all other tables use the
Vproc logging rate.
• To avoid confusion, the Node and Vproc logging rates should be the same.
ResAWT Macros
Function
The following table describes the ResAwt macros:
Macro... Collects and reports ...
ResAWT all AWTs for all nodes in the system.
ResAWTByAMP all AWTs in use on each AMP.
ResAWTByNode all AWTs in use on each node.
Input Format Examples

The input form of the ResAWT macro is:
EXEC ResAWT
(FromDate,ToDate,FromTime,ToTime,FromNode,ToNode);
The input form of the ResAWTByAMP macro is:
EXEC ResAWTByAMP
The input form of the ResAWTByNode macro is:
EXEC ResAWTByNode
See “Executing Macros” on page 39 for a description of the FromDate, ToDate, FromTime,
ToTime, FromNode, ToNode and Node parameters.
Usage Notes
For any of these macros the following usage notes apply:
• Logging must be enabled on ResUsageSawt.
• Associated log rate is the vproc log rate.

ResAWT Macros
The ResAWT, ResAWTByAMP, and ResAWTByCPU macros are not currently available in
Teradata Database 12.0, but can be obtained from the Orange Book: Teradata Active Systems
Management Usage Considerations and Best Practices (541-0004755B03).
Output Examples
The reports in the following sections are sample output reports from the ResAWT,
ResAWTByAMP, and ResAWTByNode macros.
In the ResAWT output report, after the Date and Time columns, 22 statistics columns present
a summary of the AWTs resource usage.
In the ResAWTByAMP output report, after the Date and Time columns, 24 statistics columns
present the following information:
Statistics columns Description
1 Node ID.
2 AMP ID.
3 through 24 Summary of AWTs resource usage.
In the ResAWTByNode output report, after the Date and Time columns, 23 statistics columns
1 Node ID.
2 through 23 Summary of AWTs resource usage.
In all output reports (with the exception of ResAWTByNode which has the NodeId column
and ResAWTByAMP which has the Node ID and AMP ID columns) the columns are
described as follows:
Column ... Reports the ...
Mail box Depth current depth of the AMP work mailbox.
In Flow Ctl? AMP that is or is not in flow control.
Flow Ctls Per Sec number of times during the log period that the system entered the
flow control state from a non-flow controlled state.
Work Type In Use current number of AWTs in use during the log period for each
new work type for the VprId vproc.
Work New AWTs current number of AWTs in use during the log period for each
new first-level secondary work type for the VprId vproc.

ResAWT Macros
Work One AWTs current number of AWTs in use during the log period for each
first-level secondary work type for the VprId vproc.
New + One AWTs summary of the previous two columns: Work New AWTs and
Work One AWTs.
Work Two AWTs current number of AWTs in use during the log period for each
second-level secondary work type for the VprId vproc.
Work 3 AWTs current number of AWTs in use during the log period for each
third-level secondary work type for the VprId vproc.
Work Abrt AWTs current number of AWTs in use during the log period for each
transaction abort request for the VprId vproc.
Work Spwn AWTs current number of AWTs in use during the log period for each
spawned abort request for the VprId vproc.
Work Norm AWTs current number of AWTs in use during the log period for each
message that does not fall within the standard work type hierarchy
for the VprId vproc.
Work Ctl AWTs Note: This column is not currently used.
Work Exp AWTs current number of AWTs in use during the log period for each
expedited Allocation Groups for the VprId vproc. (Expedited
Allocation Groups exist when using the reserved AWT pool. See
the “Priority Scheduler (schmon, xschmon) chapter in Utilities for
details.)
Max Work New AWTs the maximum number of AWTs in use at one time during the log
period for each new work type for the VprId vproc.
Max Work One AWTs the maximum number of AWTs in use at one time during the log
period for each first-level secondary work type for the VprId
vproc.
Max Work Two AWTs the maximum number of AWTs in use at one time during the log
period for each second-level secondary work type for the VprId
vproc.
Max Work 3 AWTs the maximum number of AWTs in use at one time during the log
period for each third-level secondary work type for the VprId
vproc.
Max Work Abrt AWTs the maximum number of AWTs in use at one time during the log
period for each transaction abort request for the VprId vproc.
Max Work Spwn AWTs the maximum number of AWTs in use at one time during the log
period for each spawned abort request for the VprId vproc.
Max Work Norm AWTs the maximum number of AWTs in use at one time during the log
period for each message that does not fall within the standard
work type hierarchy for the VprId vproc.

ResAWT Macros
Max Work Ctl AWTs Note: This column is not currently used.
Max Work Exp AWTs the maximum number of AWTs in use at one time during the log
period for each expedited Allocation Groups for the VprId vproc.
(Expedited Allocation Groups exist when using the reserved
AWT pool. See the “Priority Scheduler (schmon, xschmon)”
chapter in Utilities for details.)
For a complete description of these columns, see Chapter 7: “ResUsageSawt Table.”
ResAWT Sample Output

07/08/17 AMP Worker Task Summary Average Usage per AMP Across System
Page 1
Max Max Max Max Max Max Max Max Max

Mail In Flow Work Work New+ Work Work Work Work Work Work Work Work Work Work Work Work Work Work Work Work
Box Flow Ctls New One One Two 3 Abrt Spwn Norm Ctl Exp New One Two 3 Abrt Spwn Norm Ctl Exp
Date Time Depth Ctl? PerSec AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs
-------- -------- ------ ----- ------ ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---
07/08/12 23:00:00 8 1.00 0.01 31 22 54 0 0 0 0 0 0 0 35 25 2 1 1 0 0 0 3
23:01:00 9 0.00 0.02 28 25 54 0 0 0 0 0 0 0 33 27 1 1 1 0 0 0 2
23:02:00 6 0.00 0.00 31 22 54 0 0 0 0 0 0 0 35 26 1 1 1 0 0 0 2
23:03:00 3 0.00 0.00 31 22 53 0 0 0 0 0 0 0 35 26 1 1 1 0 0 0 3
23:04:00 2 0.00 0.00 31 22 52 0 0 0 0 0 0 0 36 27 1 1 1 0 0 0 3
23:05:00 5 0.00 0.00 31 22 53 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 4
23:06:00 3 0.00 0.00 27 24 51 0 0 0 0 0 0 0 34 27 1 1 1 0 0 0 3
23:07:00 1 0.00 0.00 21 19 40 0 0 0 0 0 0 1 35 29 1 1 1 0 0 0 3
23:08:00 1 0.00 0.00 26 20 46 0 0 0 0 0 0 0 35 29 1 1 1 0 0 0 3
23:09:00 2 0.00 0.00 30 20 50 0 0 0 0 0 0 0 37 26 1 1 1 0 0 0 4
23:10:00 1 0.00 0.00 29 16 46 0 0 0 0 0 0 0 38 25 2 1 1 0 0 0 3
23:11:00 2 0.00 0.00 30 19 49 0 0 0 0 0 0 0 38 27 1 1 1 0 0 0 3
23:12:00 2 0.00 0.00 31 21 52 0 0 0 0 0 0 0 37 26 1 1 1 0 0 0 3
23:13:00 1 0.00 0.00 29 19 49 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 4
23:14:00 1 0.00 0.00 29 18 47 0 0 0 0 0 0 0 36 25 1 1 1 0 0 0 3
23:15:00 2 0.00 0.00 29 19 48 0 0 0 0 0 0 0 37 25 2 1 1 0 0 0 3
23:16:00 3 0.00 0.00 34 18 52 0 0 0 0 0 0 0 37 25 1 1 1 0 0 0 4
23:17:00 6 0.00 0.00 35 19 54 0 0 0 0 0 0 0 40 22 1 1 1 0 0 0 4
23:18:00 8 0.00 0.00 30 23 53 0 0 0 0 0 0 0 37 24 1 1 1 0 0 0 4
23:19:00 1 0.00 0.01 25 24 49 0 0 0 0 0 0 0 36 30 1 1 1 0 0 0 3
23:20:00 1 0.00 0.00 28 18 46 0 0 0 0 0 0 0 36 30 2 2 1 0 0 0 4
23:21:00 7 0.00 0.01 34 20 54 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 3
23:22:00 2 0.00 0.01 30 22 53 0 0 0 0 0 0 0 36 27 1 1 1 0 0 0 3
ResAWTByAMP Sample Output

07/08/17 AMP Worker Task Summary Usage per AMP
Page 1

Node AMP Box Flow Ctls New One One Two 3 Abrt Spwn Norm Ctl Exp New One Two 3 Abrt Spwn Norm Ctl Exp
Date Time ID ID Depth Ctl? PerSec AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs
-------- -------- ------ ------- ------ ----- ------ ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
07/08/12 23:00:00 1-04 0 3 0.00 0.00 31 22 53 0 0 1 0 0 0 0 33 24 2 1 1 0 0 0 3
1 1 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
2 12 0.00 0.00 31 23 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
3 14 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
4 4 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 25 1 0 0 0 0 0 3
5 11 0.00 0.00 32 22 54 0 0 0 0 0 0 0 35 23 1 0 0 0 0 0 3
6 12 0.00 0.00 30 24 54 0 0 0 0 0 0 0 35 24 1 0 0 0 0 0 3
7 17 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 23 1 0 0 0 0 0 3
8 5 0.00 0.00 31 23 54 0 0 0 0 0 0 0 34 23 2 0 0 0 0 0 3
9 4 0.00 0.00 32 22 54 0 0 0 0 0 0 0 33 25 0 0 0 0 0 0 3
10 1 0.00 0.00 30 23 53 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
11 15 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
12 7 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 0 0 0 0 0 0 3
13 1 0.00 0.00 29 24 53 0 0 0 0 0 0 0 33 24 0 0 0 0 0 0 3
14 1 0.00 0.00 31 23 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
15 4 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
16 27 1.00 0.22 31 23 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
17 5 0.00 0.00 32 22 54 0 0 0 0 0 0 0 34 24 1 0 0 0 0 0 3
18 1 0.00 0.00 29 23 52 0 0 0 0 0 0 0 33 25 1 0 0 0 0 0 3
19 11 0.00 0.02 32 22 54 0 0 0 0 0 0 0 34 24 0 0 0 0 0 0 3
23:01:00 1-04 0 14 0.00 0.00 28 25 53 0 0 1 0 0 0 0 32 26 0 0 1 0 0 0 2

1 11 0.00 0.00 29 25 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
2 19 0.00 0.00 29 25 54 0 0 0 0 0 0 0 33 25 0 0 0 0 0 0 1
3 12 0.00 0.00 28 26 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
4 3 0.00 0.00 29 25 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
5 13 0.00 0.00 29 25 54 0 0 0 0 0 0 0 32 25 0 0 0 0 0 0 1
6 19 0.00 0.13 28 26 54 0 0 0 0 0 0 0 32 26 1 0 0 0 0 0 1
7 8 0.00 0.00 29 25 54 0 0 0 0 0 0 0 32 26 0 0 0 0 0 0 1

ResCPUByAMP Macros
8 12 0.00 0.00 29 25 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
9 3 0.00 0.00 28 26 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 2
10 4 0.00 0.00 29 25 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
11 13 0.00 0.00 29 25 54 0 0 0 0 0 0 0 32 25 0 0 0 0 0 0 2
12 3 0.00 0.00 30 24 54 0 0 0 0 0 0 0 32 25 0 0 0 0 0 0 2
13 1 0.00 0.00 26 26 52 0 0 0 0 0 0 0 31 26 0 0 0 0 0 0 2
14 1 0.00 0.00 26 25 51 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
15 11 0.00 0.00 28 26 54 0 0 0 0 0 0 0 32 26 0 0 0 0 0 0 1
16 10 0.00 0.17 29 25 54 0 0 0 0 0 0 0 32 27 0 1 0 0 0 0 2
17 12 0.00 0.00 30 24 54 0 0 0 0 0 0 0 33 25 0 0 0 0 0 0 2
18 1 0.00 0.00 28 25 53 0 0 0 0 0 0 0 33 25 0 0 0 0 0 0 2
19 9 0.00 0.03 28 26 54 0 0 0 0 0 0 0 33 26 0 0 0 0 0 0 1
23:02:00 1-04 0 9 0.00 0.00 31 22 53 0 0 1 0 0 0 0 33 25 1 0 1 0 0 0 2

1 6 0.00 0.00 31 23 54 0 0 0 0 0 0 0 32 26 0 0 0 0 0 0 2
2 1 0.00 0.00 31 23 54 0 0 0 0 0 0 0 34 25 0 0 0 0 0 0 2
ResAWTByNode Sample Output

07/08/17 AMP Worker Task Summary Average Usage per AMP By Node Page 1

Node Box Flow Ctls New One One Two 3 Abrt Spwn Norm Ctl Exp New One Two 3 Abrt Spwn Norm Ctl Exp
Date Time ID Depth Ctl? PerSec AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs AWTs
-------- -------- ------ ------ ----- ------ ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
07/08/12 23:00:00 1-04 8 1.00 0.01 31 22 54 0 0 0 0 0 0 0 35 25 2 1 1 0 0 0 3
23:01:00 1-04 9 0.00 0.02 28 25 54 0 0 0 0 0 0 0 33 27 1 1 1 0 0 0 2
23:02:00 1-04 6 0.00 0.00 31 22 54 0 0 0 0 0 0 0 35 26 1 1 1 0 0 0 2
23:03:00 1-04 3 0.00 0.00 31 22 53 0 0 0 0 0 0 0 35 26 1 1 1 0 0 0 3
23:04:00 1-04 2 0.00 0.00 31 22 52 0 0 0 0 0 0 0 36 27 1 1 1 0 0 0 3
23:05:00 1-04 5 0.00 0.00 31 22 53 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 4
23:06:00 1-04 3 0.00 0.00 27 24 51 0 0 0 0 0 0 0 34 27 1 1 1 0 0 0 3
23:07:00 1-04 1 0.00 0.00 21 19 40 0 0 0 0 0 0 1 35 29 1 1 1 0 0 0 3
23:08:00 1-04 1 0.00 0.00 26 20 46 0 0 0 0 0 0 0 35 29 1 1 1 0 0 0 3
23:09:00 1-04 2 0.00 0.00 30 20 50 0 0 0 0 0 0 0 37 26 1 1 1 0 0 0 4
23:10:00 1-04 1 0.00 0.00 29 16 46 0 0 0 0 0 0 0 38 25 2 1 1 0 0 0 3
23:11:00 1-04 2 0.00 0.00 30 19 49 0 0 0 0 0 0 0 38 27 1 1 1 0 0 0 3
23:12:00 1-04 2 0.00 0.00 31 21 52 0 0 0 0 0 0 0 37 26 1 1 1 0 0 0 3
23:13:00 1-04 1 0.00 0.00 29 19 49 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 4
23:14:00 1-04 1 0.00 0.00 29 18 47 0 0 0 0 0 0 0 36 25 1 1 1 0 0 0 3
23:15:00 1-04 2 0.00 0.00 29 19 48 0 0 0 0 0 0 0 37 25 2 1 1 0 0 0 3
23:16:00 1-04 3 0.00 0.00 34 18 52 0 0 0 0 0 0 0 37 25 1 1 1 0 0 0 4
23:17:00 1-04 6 0.00 0.00 35 19 54 0 0 0 0 0 0 0 40 22 1 1 1 0 0 0 4
23:18:00 1-04 8 0.00 0.00 30 23 53 0 0 0 0 0 0 0 37 24 1 1 1 0 0 0 4
23:19:00 1-04 1 0.00 0.01 25 24 49 0 0 0 0 0 0 0 36 30 1 1 1 0 0 0 3
23:20:00 1-04 1 0.00 0.00 28 18 46 0 0 0 0 0 0 0 36 30 2 2 1 0 0 0 4
23:21:00 1-04 7 0.00 0.01 34 20 54 0 0 0 0 0 0 0 36 26 1 1 1 0 0 0 3
23:22:00 1-04 2 0.00 0.01 30 22 53 0 0 0 0 0 0 0 36 27 1 1 1 0 0 0 3
ResCPUByAMP Macros
Function
The following table describes the ResCPUByAMP macros:
Macro... Reports the following...
ResCPUByAMP how each AMP on each node utilizes the CPUs.
ResCPUByAMPOneNode how each AMP on a specific node utilizes the CPUs.
ResAmpCpuByGroup the summary of AMP CPU usage by node grouping.

ResCPUByAMP Macros

The input form of the ResCPUByAMP macro is:
EXECUTE ResCPUByAMP
The input form of the ResCPUByAMPOneNode macro is:
EXECUTE ResCPUByAMPOneNode
(FromDate,ToDate,FromTime,ToTime,Node);
The input form of the ResAmpCpuByGroup macro is:
EXECUTE ResAmpCpuByGroup
(FromDate,ToDate,FromTime,ToTime);
Usage Notes
• Logging must have been enabled on ResUsageSvpr at some time before macro execution.
See Chapter 2: “Planning Your Resource Usage Data” for an explanation of how to enable/
disable logging.
• The associated log rate must have been set to vproc.
Note: It is not necessary that logging for the table and the rate be enabled at the moment
the macro is executed.
For a description of partitions and partition assignments in Teradata Database, see
Appendix D: “Partition Assignments.”
Output Examples
The reports in the following sections are sample output reports from the ResCPUByAMP, the
ResCPUByAMPOneNode, and the ResAmpCpuByGroup macros, respectively, where:
Column... Reports the percent of time AMPs were busy doing user...
Awt User Serv% service for the AMP Worker Task (Awt) partition.
Misc User Serv% service for miscellaneous (all other except Partition 0) AMP partitions.
Awt User Exec% execution within the AMP Worker Task (Awt) partition.
Misc User Exec% execution within miscellaneous (all other except Partition 0) AMP
partitions.
Total User Serv% servicea work. This is the sum of the Awt User Serv%, the Misc User
Serv%, and AMP Partition 0 user service%.a

ResCPUByAMP Macros
Column... Reports the percent of time AMPs were busy doing user...
Total User Exec% executionb work. This is the sum of the Awt User Exec%, Misc User
Exec%, and AMP Partition 0 user execution.b
Total Busy% service and execution work. This is the sum of the Total User Serv% and
the Total User Exec% columns.
a. Service is the time that a CPU is busy executing user service code, which is privileged work
performing system-level services on behalf of user execution processes that do not have root
privileges.
b. Execution is the time a CPU is busy executing user execution code, which is the time spent in a
user state on behalf of a process.
Note: The above CPU statistics represent the aggregate of all time spent in the indicated way
by all CPUs on the node. Because there are multiple CPUs, the “Total Busy %” should be
compared to a theoretical maximum of 100% times the number of CPUs on the node.
The Node CPU column in the following sample outputs reports the number of CPUs
(NCPUs).
For more information on how to monitor busy AMP Worker Tasks (AWTs), see “AWT
Monitor (awtmon)” in Utilities.
ResCPUByAMP Sample Output

01/07/12 CPU USAGE BY AMP Page 1
Awt Misc Awt Misc Total Total Total

Vproc Node Node User User User User User User Busy
Date Time Id Id CPUs Serv% Serv% Exec% Exec% Serv% Exec% %
-------- -------- ----- ------ -------- ------- ------- ------- ------- ------- ------- -------
01/07/12 09:57:00 0 001-01 4 0.36% 0.00% 0.05% 0.00% 0.36% 0.05% 0.41%
1 001-01 4 0.26% 0.00% 0.12% 0.00% 0.30% 0.12% 0.42%
09:57:20 0 001-01 4 0.41% 0.00% 0.12% 0.00% 0.45% 0.12% 0.58%

1 001-01 4 0.34% 0.00% 0.05% 0.00% 0.38% 0.05% 0.42%
09:57:40 0 001-01 4 0.25% 0.00% 0.18% 0.00% 0.28% 0.18% 0.45%

1 001-01 4 0.19% 0.00% 0.06% 0.00% 0.29% 0.06% 0.35%
09:58:00 0 001-01 4 0.38% 0.00% 0.08% 0.00% 0.45% 0.08% 0.52%

1 001-01 4 0.31% 0.00% 0.09% 0.00% 0.34% 0.09% 0.42%
09:58:20 0 001-01 4 0.31% 0.00% 0.08% 0.00% 0.34% 0.08% 0.41%

1 001-01 4 0.36% 0.00% 0.09% 0.00% 0.40% 0.09% 0.49%
09:58:40 0 001-01 4 0.39% 0.00% 0.11% 0.00% 0.41% 0.11% 0.52%

1 001-01 4 0.32% 0.00% 0.12% 0.00% 0.36% 0.12% 0.49%
09:59:00 0 001-01 4 0.29% 0.00% 0.11% 0.00% 0.30% 0.11% 0.41%

1 001-01 4 0.21% 0.00% 0.09% 0.00% 0.22% 0.09% 0.31%
09:59:20 0 001-01 4 0.30% 0.00% 0.06% 0.00% 0.31% 0.06% 0.38%

1 001-01 4 0.30% 0.00% 0.19% 0.00% 0.32% 0.19% 0.51%
09:59:40 0 001-01 4 0.40% 0.00% 0.09% 0.00% 0.46% 0.09% 0.55%

1 001-01 4 0.26% 0.00% 0.08% 0.00% 0.38% 0.08% 0.45%
10:00:00 0 001-01 4 0.32% 0.00% 0.08% 0.00% 0.34% 0.08% 0.41%

1 001-01 4 0.28% 0.00% 0.09% 0.00% 0.31% 0.09% 0.40%
Note: The NodeID column only appears in the ResCPUByAMP output report.

ResCPUByAMP Macros
ResCPUByAMPOneNode Sample Output

01/07/12 CPU Usage by AMP for Node 001-01 (4 CPUs) Page 68

Vproc User User User User User User Busy
Date Time Id NCPUs Serv% Serv% Exec% Exec% Serv% Exec% %
-------- -------- ----- ----- ------- ------- ------- ------- ------- ------- -------
01/07/12 09:57:00 0 4 0.36% 0.00% 0.05% 0.00% 0.36% 0.05% 0.41%
1 4 0.26% 0.00% 0.12% 0.00% 0.30% 0.12% 0.42%
09:57:20 0 4 0.41% 0.00% 0.12% 0.00% 0.45% 0.12% 0.58%

1 4 0.34% 0.00% 0.05% 0.00% 0.38% 0.05% 0.42%
09:57:40 0 4 0.25% 0.00% 0.18% 0.00% 0.28% 0.18% 0.45%

1 4 0.19% 0.00% 0.06% 0.00% 0.29% 0.06% 0.35%
09:58:00 0 4 0.38% 0.00% 0.08% 0.00% 0.45% 0.08% 0.52%

1 4 0.31% 0.00% 0.09% 0.00% 0.34% 0.09% 0.42%
09:58:20 0 4 0.31% 0.00% 0.08% 0.00% 0.34% 0.08% 0.41%

1 4 0.36% 0.00% 0.09% 0.00% 0.40% 0.09% 0.49%
09:58:40 0 4 0.39% 0.00% 0.11% 0.00% 0.41% 0.11% 0.52%

1 4 0.32% 0.00% 0.12% 0.00% 0.36% 0.12% 0.49%
09:59:00 0 4 0.29% 0.00% 0.11% 0.00% 0.30% 0.11% 0.41%

1 4 0.21% 0.00% 0.09% 0.00% 0.22% 0.09% 0.31%
ResAmpCpuByGroup Sample Output

01/07/12 AMP CPU USAGE BY GROUP Page 45

Group Node User User User User User User Busy
Date Time Id CPUs Serv% Serv% Exec% Exec% Serv% Exec% %
-------- -------- ----- -------- ------- ------- ------- ------- ------- ------- -------
01/07/12 09:51:40 A 4 0.32% 0.00% 0.07% 0.00% 0.36% 0.07% 0.43%
09:52:00 A 4 0.33% 0.00% 0.08% 0.00% 0.36% 0.08% 0.44%
09:52:20 A 4 0.35% 0.00% 0.07% 0.00% 0.37% 0.07% 0.44%
09:52:40 A 4 0.36% 0.00% 0.09% 0.00% 0.39% 0.09% 0.48%
09:53:00 A 4 0.27% 0.00% 0.09% 0.00% 0.28% 0.09% 0.37%
09:53:20 A 4 0.29% 0.00% 0.06% 0.00% 0.34% 0.06% 0.40%
09:53:40 A 4 0.36% 0.00% 0.06% 0.00% 0.40% 0.06% 0.46%
09:54:00 A 4 0.35% 0.00% 0.11% 0.00% 0.38% 0.11% 0.49%
09:54:20 A 4 0.34% 0.00% 0.07% 0.00% 0.36% 0.07% 0.43%
09:54:40 A 4 0.41% 0.00% 0.04% 0.00% 0.43% 0.04% 0.47%
09:55:00 A 4 0.28% 0.00% 0.09% 0.00% 0.28% 0.09% 0.37%
09:55:20 A 4 0.35% 0.00% 0.09% 0.00% 0.43% 0.09% 0.53%
09:55:40 A 4 0.34% 0.00% 0.06% 0.00% 0.42% 0.06% 0.48%
09:56:00 A 4 0.26% 0.00% 0.08% 0.00% 0.29% 0.08% 0.37%
Note: The GroupID column only appears in the ResAmpCpuByGroup output report.
“Normalized” Viewing of CPU Usage by AMP

Some users may prefer to view CPU usage by AMP in a “normalized” fashion. Conceptually,
this restates each of the above statistics in terms of “percentage of total CPU capacity of the
node.”

ResCPUByPE Macros
The following SQL example shows how to perform this normalization for the “Total Busy %”
statistic:
SEL TheDate, TheTime, Vproc, NodeId,
(AmpTotalUserExec+AmpTotalUserServ)
/Secs/NCPUs
(FORMAT ‘zz9%’,TITLE ‘Total// Busy// %’)
FROM ResCpuUsageByAMPView
WHERE TheDate = CURRENT_DATE AND TheTime>080000
ORDER BY 1,2,3;
ResCPUByPE Macros
Function
The following table describes the ResCPUByPE macros:
Macro... Reports...
ResCPUByPE how each PE on each node is utilizing the CPUs.
ResCPUByPEOneNode how each PE on a specific node is utilizing the CPUs.
ResPeCpuByGroup the PE CPU utilization summarized by a node grouping.

The input form of the ResCPUByPE macro is:
EXEC ResCPUByPE
The input form of the ResCPUByPEOneNode macro is:
EXEC ResCPUByPEOneNode
The input form of the ResPeCpuByGroup macro is:
EXEC ResPeCpuByGroup
Usage Notes
• Logging must be enabled on ResUsageSvpr.
• Associated log rate is vproc.

ResCPUByPE Macros
Output Examples
The reports in the following sections are sample output reports from the ResCPUByPE,
ResCPUByPEOneNode, and ResPeCPUByGroup macros, respectively, where:
Column... Reports the percent of time PEs are busy doing user...
Pars User Serv% servicea for the Parser partition of the PE.a
Disp User Serv% service for the Dispatcher partition of the PE.
Ses User Serv% service for the Session Control partition of the PE.
Misc User Serv% service for miscellaneous (all other, except Partition 0) PE partitions.
Pars User Exec% execution bwithin the Parser partition of the PE.b
Disp User Exec% execution within the Dispatcher partition of the PE.
Ses User Exec% execution within the Session Control partition of the PE.
Misc User Exec% execution within miscellaneous (all other, except Partition 0) PE partitions.
Total User Serv% service work. This is the sum of the four user service columns above plus PE
Partition 0 user service.
Total User Exec% execution work. This is the sum of the four user execution columns above
plus PE Partition 0 user execution.
Total Busy% service and execution work. This is the sum of the Total User Serv% and the
Total User Exec% columns.
a. Service is the time that a CPU is busy executing user service code, which is privileged work
performing system-level services on behalf of user execution processes that do not have root
privileges.
b. Execution is the time a CPU is busy executing user execution code, which is the time spent in a
user state on behalf of a process.
Note: The above CPU statistics represent the aggregate of all time spent in the indicated way
by all CPUs on the node. Because there are multiple CPUs, the “Total Busy %” should be
compared to a theoretical maximum of 100% times the number of CPUs on the node.
The Node CPU column in the following sample outputs reports the number of CPUs
(NCPUs).

ResCPUByPE Macros
ResCPUByPE Sample Output

01/07/12 CPU USAGE BY PE Page 1
Pars Disp Ses Misc Pars Disp Ses Misc Total Total Total
Vproc Node Node User User User User User User User User User User Busy
Date Time Id Id CPUs Serv% Serv% Serv% Serv% Exec% Exec% Exec% Exec% Serv% Exec% %
-------- -------- ----- ------ ---- ------- ------- ------- ------- ------- ------- ------- ------- ------ ------ -------
01/07/12 09:57:00 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:57:20 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:57:40 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:58:00 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:58:20 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:58:40 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:59:00 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:59:20 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
09:59:40 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
10:00:00 16382 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
16383 001-01 4 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
Note: The NodeId column only appears in the ResCPUByPE output report.
ResCPUByPEOneNode Sample Output
01/09/13 CPU Usage by PE for Node 001-01 (4 CPUs) Page 4
Vproc Node User User User User User User User User User User Busy
Date Time Id CPUs Serv% Serv% Serv% Serv% Exec% Exec% Exec% Exec% Serv% Exec% %
------ ------- ----- ---- ------ ------ ------ ------ ----- ------ ------ ------ ------ ------ ------
01/08/21 15:41:00 2 4 0.02% 0.05% 0.00% 0.00% 0.56% 0.01% 0.00% 0.00% 0.08% 0.58% 0.7%
15:42:00 2 4 0.01% 0.01% 0.00% 0.00% 0.18% 0.00% 0.00% 0.00% 0.02% 0.18% 0.2%
15:43:00 2 4 0.02% 0.02% 0.00% 0.00% 0.20% 0.00% 0.00% 0.00% 0.04% 0.20% 0.2%
15:44:00 2 4 0.03% 0.02% 0.00% 0.00% 0.55% 0.00% 0.00% 0.00% 0.05% 0.56% 0.6%
15:45:00 2 4 0.02% 0.01% 0.00% 0.00% 0.18% 0.00% 0.00% 0.00% 0.02% 0.18% 0.2%
15:46:00 2 4 0.03% 0.02% 0.00% 0.00% 0.58% 0.00% 0.00% 0.00% 0.05% 0.58% 0.6%
01/08/27 16:21:00 2 4 0.05% 0.08% 0.00% 0.00% 0.69% 0.00% 0.00% 0.00% 0.13% 0.70% 0.8%

ResCPUByNode Macros
ResPeCpuByGroup Sample Output

01/07/12 PE CPU USAGE BY GROUP Page 8
Group Node User User User User User User User User User User Busy
Date Time Id CPUs Serv% Serv% Serv% Serv% Exec% Exec% Exec% Exec% Serv% Exec% %
------ ------ ----- ---- ------- ------ ------- ------ ------ ------ ------ ------- ------ ----- -----
01/07/12 04:55:40 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:56:00 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:56:20 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:56:40 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:57:00 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:57:20 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:57:40 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:58:00 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
04:58:20 A 4 0.00% 0.00% 0.00% 0.00% 0.0% 0.00 0.00% 0.00% 0.00% 0.00% 0.00%
Note: The GroupID column only appears in the ResPeCpuByGroup output report.
“Normalized” Viewing of CPU Usage by PE

Some users may prefer to view CPU usage by PEs in a “normalized” fashion. Conceptually,
this restates each of the above statistics in terms of “percentage of total CPU capacity of the
node.”
The following SQL example shows how to perform this normalization for the “Total Busy %”
statistic:
SEL TheDate, TheTime,Vproc,NodeId,
(PETotalUserExec+PETotalUserServ)
/Secs/NCPUs
(FORMAT ‘zz9%’,TITLE ‘Total// Busy// %’)
FROM ResCpuUsageByPEView
WHERE TheDate = CURRENT_DATE AND TheTime>080000
ORDER BY 1,2,3;
ResCPUByNode Macros
Function
The following table describes the ResCPUByNode macros:
Macro... Reports how...
ResCPUByNode each individual node is utilizing its CPUs
ResCPUOneNode a specific node is utilizing its CPUs
ResCPUByGroup a specified Node Group is utilizing the system CPUs.

ResCPUByNode Macros

The input form of the ResCPUByNode macro is:
EXEC ResCPUByNode
The input form of the ResCPUOneNode macro is:
EXEC ResCPUOneNode
The input form of the ResCPUByGroup macro is:
EXEC ResCPUByGroup
Usage Notes
• Logging must be enabled on ResUsageSpma.
• Associated log rate is node.
Output Examples
The reports in the following sections are sample output reports from the ResCPUByNode, the
ResCPUOneNode macro, and the ResCPUByGroup, respectively, where:
Column... Reports the percent of time CPUs are...
I/O Wait % idle and waiting for I/O completion.
Total User Serv % busy doing user service work.
Total User Exec % busy doing user execution work.
Total Busy % busy doing user service and execution work.

This is the sum of Total User Serv % and the Total User Exec %
columns.
Note: User service is the time that a CPU is busy executing user service code, which is
privileged work performing system-level services on behalf of user execution processes that do
not have root privileges. User execution is the time a CPU is busy executing user execution
code, which is the time spent in a user state on behalf of a process. These report columns are
the average for all CPUs on the node.

ResCPUByNode Macros
ResCPUByNode Sample Output
01/07/12 CPU USAGE BY NODE Page 45
I/O Total Total Total

Node Wait User User Busy
Date Time Id % Serv% Exec% %
-------- -------- ------ ------ ------ ------ ------
01/07/12 09:51:40 001-01 16.2% 1.4% 0.1% 1.5%
09:52:00 001-01 17.2% 1.3% 0.2% 1.5%
09:52:20 001-01 15.5% 1.6% 0.2% 1.8%
09:52:40 001-01 16.1% 1.5% 0.2% 1.7%
09:53:00 001-01 15.8% 1.0% 0.2% 1.2%
09:53:20 001-01 15.5% 1.5% 0.2% 1.7%
Note: The NodeId column only appears in the ResCPUByNode output report.
ResCPUOneNode Sample Output

01/07/12 CPU Usage for Node 001-01 Page 01
I/O TotalTotal Total

Wait User User Busy
Date Time % Serv% Exec% %
-------- -------- ------ ------ ------ ------
01/07/12 09:44:20 16.2% 1.6% 0.2% 1.9%
09:44:40 16.9% 1.3% 0.2% 1.5%
09:45:00 16.5% 1.1% 0.1% 1.2%
09:45:20 17.0% 1.7% 0.2% 1.9%
09:45:40 17.4% 1.1% 0.2% 1.3%
09:46:00 16.6% 1.3% 0.2% 1.5%
09:46:20 16.2% 1.6% 0.2% 1.8%
ResCPUByGroup Sample Output

00/10/16 CPU USAGE BY Group Page 2
I/O Total Total Total

Group Wait User User Busy
Date Time Id % Serv% Exec% %
-------- -------- ----- ------ ------ ------ ------
00/10/16 11:25:00 A 0.0% 0.0% 0.0% 0.0%
B 0.0% 0.0% 0.0% 0.0%
11:30:00 A 0.0% 0.0% 0.0% 0.0%

B 0.0% 0.0% 0.0% 0.0%
11:35:00 A 0.0% 0.6% 0.6% 1.1%

B 0.0% 0.3% 0.4% 0.7%
11:40:00 A 0.0% 1.3% 0.9% 2.2%

B 0.0% 1.1% 0.9% 2.0%
11:45:00 A 0.0% 0.6% 0.9% 1.5%

B 0.0% 0.3% 1.0% 1.3%
11:50:00 A 0.0% 0.6% 0.6% 1.2%

B 0.0% 0.6% 0.8% 1.3%
11:55:00 A 0.0% 1.5% 1.1% 2.6%

B 0.0% 1.6% 1.0% 2.6%
12:00:00 A 0.0% 0.5% 0.8% 1.3%

B 0.0% 0.7% 0.9% 1.6%
12:05:00 A 0.0% 1.2% 0.7% 1.8%

B 0.0% 0.6% 0.5% 1.1%
12:10:00 A 0.0% 0.6% 0.9% 1.6%

B 0.0% 1.1% 1.2% 2.2%

ResHostByLink Macros
12:15:00 A 0.0% 0.6% 0.8% 1.4%

B 0.0% 0.5% 0.7% 1.2%
12:20:00 A 0.0% 1.4% 0.8% 2.2%

B 0.0% 1.1% 0.8% 1.9%
12:25:00 A 0.0% 0.9% 1.0% 1.9%

B 0.0% 0.9% 0.9% 1.8%
12:30:00 A 0.0% 0.6% 0.6% 1.2%

B 0.0% 0.6% 0.8% 1.4%
12:35:00 A 0.0% 1.6% 1.1% 2.7%

B 0.0% 1.3% 0.9% 2.2%
Note: The GroupID column only appears in the ResCpuByGroup output report.
Function
The following table describes the ResHostByLink macros:
Macro... Reports the host traffic for...
ResHostByLink every communication link in the system.
ResHostOneNode the communication links of a specific node.
ResHostByGroup the communication links of a node grouping.

The input form of the ResHostByLink macro is:
EXEC ResHostByLink
Note: The ResHostByLink macro syntax does not include the FromNode and ToNode
parameters to specify a range of nodes.
The input form of the ResHostOneNode macro is:
EXEC ResHostOneNode
The input form of the ResHostByGroup macro is:
EXEC ResHostByGroup
See “Executing Macros” on page 39 for a description of the FromDate, FromTime, ToDate,
ToTime, and Node parameters.

Usage Notes
The ResHostByLink macros help you answer the following questions:
• Is my set up correct?
• Am I making good use of the channels? If not, how high are they? If not high, then there
may not be enough host resources.
Study the incoming traffic. Problems with incoming traffic may be simply caused by an
incorrect configuration. Once configured correctly, if there is still a traffic problem, consider
studying the LAN traffic, for example, when doing an export, the ResUsageSpma table may
show 30 million rows/log period.
• Logging must be enabled on ResUsageShst.
Output Examples
The reports in the following sections are sample output reports from the ResHostByLink, the
ResHostOneNode macros, and the ResHostByGroup, respectively, where:
Column... Reports the...
Host Type type of host connection:

• NETWORK, for LAN-connected hosts
• IBMMUX, for channel-connected hosts
KBs Read/ Sec number of KBs read per second.
KBs Write/ Sec number of KBs written per second.
Blks Read/ Sec number of successful blocks read per second.
Blks Write/ Sec number of successful blocks written per second.
Blk Read Fail % percentage of block read attempts that failed.
Blk Write Fail % percentage of block write attempts that failed.
KBs/Blk Read average number of KBs per block read.
KBs/Blk Write average number of KBs per block written.
Msgs/Blk Read average number of messages per block read.
Msgs/Blk Write average number of messages per block written.
Avg ReqQ Len average number of messages queued for output to the host.
Max ReqQ Len maximum number of messages queued for output to the host.

ResHostByLink Sample Output
00/10/16 HOST COMMUNICATIONS BY COMMUNICATION LINK Page 1
KBs KBs Blks Blks Blk Blk KBs KBs Msgs Msgs Avg Max
Node Vproc Host Host Read Write Read Write Read Write /Blk /Blk /Blk /Blk ReqQ ReqQ
Date Time Id Id Type Id /Sec /Sec /Sec /Sec Fail% Fail% Read Write Read Write Len Len
------- ------- ------ ----- ------- ----- ----- ------ ----- ----- ----- ----- ------ ------ ----- ----- ----- ----
00/10/16 11:07:00 105-04 65535 NETWORK 0 24.0 13.3 0.1 0.1 0.0% 0.0% 350.5 186.2 0.8 0.8 0.0 0.0
IBMMUX 101 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
105-05 65535 NETWORK 0 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0

IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
106-04 65535 NETWORK 0 22.6 11.3 0.1 0.1 0.0% 0.0% 398.4 198.8 0.9 0.9 0.0 0.0
106-05 65535 NETWORK 0 7.5 97.0 0.1 0.1 0.0% 0.0% 86.0 1097.7 1.0 1.0 0.0 0.0
11:22:42 105-04 65535 NETWORK 0 81105.0 250605.8 47.1 47.1 0.0% 0.0% 1721.2 5317.6 1.0 1.0 0.0 0.0
IBMMUX 101 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
105-05 65535 NETWORK 0 44.1 22.6 0.1 0.1 0.0% 0.0% 391.8 206.5 0.9 0.9 0.0 0.0
IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
106-04 65535 NETWORK 0 31.9 391.0 0.4 0.4 0.0% 0.0% 85.3 1037.5 1.0 1.0 0.0 0.0
106-05 65535 NETWORK 0 8.3 81.8 0.1 0.1 0.0% 0.0% 97.3 917.2 0.9 0.9 0.0 0.0
11:32:42 105-04 65535 NETWORK 0 80303.8 246270.046.6 46.7 0.0% 0.0% 1722.0 5276.5 1.0 1.0 0.0 0.0
IBMMUX 101 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
105-05 65535 NETWORK 0 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0

IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
106-04 65535 NETWORK 0 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
106-05 65535 NETWORK 0 46.2 23.7 0.1 0.1 0.0% 0.0% 385.4 200.3 0.9 0.9 0.0 0.0
11:42:42 105-04 65535 NETWORK 0 59002.2 176635.3 34.3 34.3 0.0% 0.0% 1720.4 5148.5 1.0 1.0 0.0 0.0
IBMMUX 101 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
105-05 65535 NETWORK 0 0.3 0.4 0.0 0.0 0.0% 0.0% 86.5 84.7 0.5 0.3 0.0 0.0
IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
106-04 65535 NETWORK 0 23.1 11.9 0.1 0.1 0.0% 0.0% 407.6 215.8 0.9 0.9 0.0 0.0
106-05 65535 NETWORK 0 22.5 11.0 0.1 0.1 0.0% 0.0% 408.8 205.9 0.9 0.9 0.0 0.0
Note: The NodeId column only appears in the ResHostByLink output report.
ResHostOneNode Sample Output

00/10/16 Host Communications for Node 105-05 Page 1
Vproc Host Host Read Write Read Write Read Write /Blk /Blk /Blk /Blk ReqQ ReqQ
Date Time Id Type Id /Sec /Sec /Sec /Sec Fail% Fail% Read Write Read Write Len Len
-------- -------- ----- -------- ----- -------- -------- ------ ------ ----- ----- ------ ------- ----- ----- ----- -----
00/10/16 11:07:00 65535 NETWORK 0 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
11:22:42 65535 NETWORK 0 44.1 22.6 0.1 0.1 0.0% 0.0% 391.8 206.5 0.9 0.9 0.0 0.0
IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
11:32:42 65535 NETWORK 0 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0

IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
11:42:42 65535 NETWORK 0 0.3 0.4 0.0 0.0 0.0% 0.0% 86.5 84.7 0.5 0.3 0.0 0.0
IBMMUX 202 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
IBMMUX 304 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0

ResLdvByNode Macros
ResHostByGroup Sample Output

Group Host Read Write Read Write Read Write /Blk /Blk /Blk /Blk ReqQ ReqQ
Date Time Id Type /Sec /Sec /Sec /Sec Fail% Fail% Read Write Read Write Len Len
-------- -------- ------ -------- -------- -------- ----- ----- ----- ----- ------- ------- ----- ----- ----- -----
00/10/16 11:30:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:30:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:35:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:35:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:40:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:40:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:45:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:45:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:50:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:50:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:55:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 11:55:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:00:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:00:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:05:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:05:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:10:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:10:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:15:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:15:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:20:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:20:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:25:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:25:00 B NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
00/10/16 12:30:00 A NETWORK 0.0 0.0 0.0 0.0 ? ? ? ? ? ? 0.0 0.0
Note: The GroupID column only appears in the ResHostByGroup output report.
ResLdvByNode Macros
Function
The following table describes the ResLdvByNode macros:
Macro... Reports the logical device traffic channeled through...
ResLdvByNode each node by totaling its controller links into one summarized node
output line.
ResLdvOneNode a specific node by totaling all its controller links into one summarized
node output line.
ResLdvByGroup a node grouping.

The input form of the ResLdvByNode macro is:
EXEC ResLdvByNode
The input form of the ResLdvOneNode macro is:
EXEC ResLdvOneNode
The input form of the ResLdvByGroup macro is:
EXEC ResLdvByGroup

ResLdvByNode Macros
Usage Notes
• Logging must be enabled on ResUsageSldv.
Output Examples
The reports in the following sections are sample output reports from the ResLdvByNode, the
ResLdvOneNode, and the ResLdvByGroup macros, respectively, where:
Reads / Sec average number of logical device reads per second.
Writes / Sec average number of logical device writes per second.
Rd KB / I/O average number of KBs per logical device read.
Wrt KB / I/O average number of KBs per logical device write.
Avg I/O Resp average response time for a logical device read or write in seconds.
Max Concur Rqsts maximum number of concurrent requests during the collect/log period.
Avg Out Rqsts average number of outstanding requests.
Out Rqst Time % percent of time there are outstanding requests.
ResLdvByNode Sample Output

06/09/26 LOGICAL DEVICE TRAFFIC BY NODE Page 1
Avg Avg Out
Ldv Node Reads Writes KB I/O Out Rqst
Date Type Time Id / Sec / Sec / I/O Resp Rqsts Time %
-------- ---- -------- ------ -------- -------- ------ ------- ----- ------
06/09/26 DISK 10:09:45 001-01 0.00 2.00 4.20 0.000 0.0 1.3%
10:10:00 001-01 0.00 1.27 5.89 0.000 0.0 0.6%
10:10:15 001-01 0.00 2.20 5.88 0.000 0.0 1.3%
10:10:30 001-01 0.00 1.20 6.22 0.000 0.0 0.8%
10:10:45 001-01 0.00 3.53 3.96 0.000 0.0 2.5%
10:11:00 001-01 0.00 1.33 5.85 0.000 0.0 1.0%
10:11:15 001-01 0.00 2.00 4.30 0.000 0.0 1.3%
10:11:30 001-01 0.00 1.33 5.65 0.000 0.0 0.7%
10:11:45 001-01 0.00 1.87 8.71 0.000 0.0 1.0%
10:12:00 001-01 0.00 40.67 31.27 0.000 4.0 100.0%
10:12:15 001-01 0.00 3.40 16.57 0.000 0.0 1.4%
10:12:30 001-01 0.00 5.40 7.44 0.000 0.0 5.2%
10:12:45 001-01 0.00 1.87 14.29 0.000 0.0 0.9%
SDSK 10:09:45 001-01 0.13 1.00 55.42 0.000 0.0 3.2%
10:10:00 001-01 0.07 7.98 109.53 0.000 1.2 9.1%
10:10:15 001-01 0.00 9.21 111.57 0.000 1.3 9.1%
10:10:30 001-01 0.44 8.73 107.32 0.000 1.1 9.1%
10:10:45 001-01 0.50 9.01 98.02 0.000 1.1 11.2%

ResLdvByNode Macros
10:11:00 001-01 0.48 8.45 100.64 0.000 1.0 9.1%

10:11:15 001-01 0.51 8.85 100.83 0.000 1.0 9.1%
10:11:30 001-01 0.88 2.72 410.24 0.000 0.3 9.1%
10:11:45 001-01 0.97 0.34 ****** 0.000 0.1 9.2%
10:12:00 001-01 0.98 0.28 ****** 0.000 0.0 8.6%
Note: The NodeId column only appears in the ResLdvByNode output report.
ResLdvOneNode Sample Output

06/09/26 Logical Device Traffic for Node 001-01
Avg Avg Out

Ldv Reads Writes KB I/O Out Rqst
Date Type Time / Sec / Sec / I/O Resp Rqsts Time %
-------- ---- -------- -------- -------- ------ ------- ----- ------
06/09/26 DISK 10:09:45 0.00 2.00 4.20 0.000 0.0 1.3%
10:10:00 0.00 1.27 5.89 0.000 0.0 0.6%
10:10:15 0.00 2.20 5.88 0.000 0.0 1.3%
10:10:30 0.00 1.20 6.22 0.000 0.0 0.8%
10:10:45 0.00 3.53 3.96 0.000 0.0 2.5%
10:11:00 0.00 1.33 5.85 0.000 0.0 1.0%
10:11:15 0.00 2.00 4.30 0.000 0.0 1.3%
10:11:30 0.00 1.33 5.65 0.000 0.0 0.7%
10:11:45 0.00 1.87 8.71 0.000 0.0 1.0%
10:12:00 0.00 40.67 31.27 0.000 4.0 100.0%
10:12:15 0.00 3.40 16.57 0.000 0.0 1.4%
10:12:30 0.00 5.40 7.44 0.000 0.0 5.2%
10:12:45 0.00 1.87 14.29 0.000 0.0 0.9%
SDSK 10:09:45 0.13 1.00 55.42 0.000 0.0 3.2%

10:10:00 0.07 7.98 109.53 0.000 1.2 9.1%
10:10:15 0.00 9.21 111.57 0.000 1.3 9.1%
10:10:30 0.44 8.73 107.32 0.000 1.1 9.1%
10:10:45 0.50 9.01 98.02 0.000 1.1 11.2%
10:11:00 0.48 8.45 100.64 0.000 1.0 9.1%
10:11:15 0.51 8.85 100.83 0.000 1.0 9.1%
10:11:30 0.88 2.72 410.24 0.000 0.3 9.1%
10:11:45 0.97 0.34 ****** 0.000 0.1 9.2%
10:12:00 0.98 0.28 ****** 0.000 0.0 8.6%
10:12:15 0.59 3.14 285.78 0.000 0.1 9.1%
10:12:30 0.08 4.15 16.99 0.000 0.1 9.2%
10:12:45 0.00 0.39 32.94 0.000 0.0 1.0%
ResLdvByGroup Sample Output

06/09/26 LOGICAL DEVICE TRAFFIC BY GROUP Page 1
Avg Out
Grp Ldv Reads Writes Rd KB Wrt KB I/O Concur Rqst
Date Id Type Time / Sec / Sec / I/O / I/O Resp Rqsts Time %
-------- --- ---- ---------- -------- -------- ------- ------ ------- ----- ------
06/09/26 A DISK 10:09:45 0.00 2.00 ? 4.20 0.000 0.0 1.3%
10:10:00 0.00 1.27 ? 5.89 0.000 0.0 0.6%
10:10:15 0.00 2.20 ? 5.88 0.000 0.0 1.3%
10:10:30 0.00 1.20 ? 6.22 0.000 0.0 0.8%
10:10:45 0.00 3.53 ? 3.96 0.000 0.0 2.5%
10:11:00 0.00 1.33 ? 5.85 0.000 0.0 1.0%
10:11:15 0.00 2.00 ? 4.30 0.000 0.0 1.3%
10:11:30 0.00 1.33 ? 5.65 0.000 0.0 0.7%
10:11:45 0.00 1.87 ? 8.71 0.000 0.0 1.0%
10:12:00 0.00 40.67 ? 31.27 0.000 0.0 100.0%
10:12:15 0.00 3.40 ? 16.57 0.000 0.0 1.4%
10:12:30 0.00 5.40 ? 7.44 0.000 0.0 5.2%
10:12:45 0.00 1.87 ? 14.29 0.000 0.0 0.9%
SDSK 10:09:45 0.13 1.00 121.27 46.64 0.000 0.0 3.2%

10:10:00 0.07 7.98 139.00 109.28 0.000 0.0 9.1%
10:10:15 0.00 9.21 ? 111.57 0.000 0.0 9.1%
10:10:30 0.44 8.73 113.33 107.02 0.000 0.0 9.1%
10:10:45 0.50 9.01 12.12 102.76 0.000 0.0 11.2%
10:11:00 0.48 8.45 12.01 105.72 0.000 0.0 9.1%
10:11:15 0.51 8.85 12.08 105.93 0.000 0.0 9.1%
10:11:30 0.88 2.72 ****** 94.90 0.000 0.0 9.1%

ResMemMgmtByNode Macros
10:11:45 0.97 0.34 ****** 39.43 0.000 0.0 9.2%

10:12:00 0.98 0.28 ****** 50.13 0.000 0.0 8.6%
10:12:15 0.59 3.14 ****** 9.85 0.000 0.0 9.1%
10:12:30 0.08 4.15 295.14 11.29 0.000 0.0 9.2%
10:12:45 0.00 0.39 ? 32.94 0.000 0.0 1.0%
Note: The GroupID column only appears in the ResLdvByGroup output report.
Function
The following table describes the ResMemMgmtByNode macros:
Macro... Reports memory management activity for...
ResMemMgmtByNode each individual node.
ResMemMgmtOneNode a specific node.
ResMemByGroup a node grouping.

The input form of the ResMemMgmtByNode macro is:
EXEC ResMemMgmtByNode
The input form of the ResMemMgmtOneNode macro is:
EXEC ResMemMgmtOneNode
The input form of the ResMemByGroup macro is:
EXEC ResMemByGroup
Usage Notes

Output Examples
The reports in the following sections are sample output reports from the
ResMemMgmtByNode, the ResMemMgmtOneNode macros, and the ResMemByGroup,
respectively, where:
% Mem Free current snapshot of the percent of memory that is unused.
Text Alocs/ Sec average number of text page allocations per second.
text pages are allocations of memory for code that is not associated with
system-level overhead tasks.
VPR Alocs/ Sec average number of vproc-specific page and segment allocations per
second on a node.
KB/ VPR Aloc average KBs per vproc-specific page and segment allocation on a node.
Aloc Fail % percent of memory allocation attempts that failed.
Ages/ Sec average number of times memory pages were aged out per second.
# Proc Swp current number of processes that are swapped out.
Page Drops/ Sec average number of text pages dropped from memory per second.
Page drops are text pages that are dropped from memory to increase the
amount of available memory.
Page Reads/ Sec average number of memory pages read from disk per second.
Page reads include both memory text pages and task context pages, such
as scratch, stack, etc.
Page Writes/ Sec average number of memory pages written to disk per second.
Page writes include only task context pages.
Swap Drops/ Sec average number of disk segments dropped from memory per second.
Swap drops include all disk segments dropped from memory because
their ancestor processes were swapped out.
Swap Reads/ Sec average number of disk segments reread back into memory, after being
swapped, out per second.
Swap reads include all reread disk segments that had been previously
dropped from memory because their ancestor processes were swapped
out.
KB/Swp Drp average size, in KBs, of disk segments dropped from memory because
their ancestor processes were swapped out.
KB/Swp Rd average size, in KBs, of reread disk segments that had been previously
dropped from memory because their ancestor processes were swapped
out.

P+S Drops/ Sec average number of paged, swapped page, or segment drops per second.
This statistic includes both the memory text pages (Pg Drps/ Sec), and the
disk segments (Swp Drps/ Sec), that were dropped.
P+S Reads/ Sec average number of paged, swapped page, or segment reads per second.
Includes both the memory text pages and task context pages (Pg Rds/
Sec), and the disk segments (Swp Rds/ Sec), reread back into memory
after being swapped out.
P+S Writes/ Sec average total number of paged, swapped page, or segment writes per
second.
P+S IO % percent of total logical device inputs and outputs that are paging or
swapping inputs and outputs.
ResMemMgmtByNode Sample Output

00/10/16 MEMORY MANAGEMENT ACTIVITY BY NODE Page 2
% Text VPR KB Aloc # Page Page Page Swap Swap KB KB P+S P+S P+S
Node Mem Alocs Alocs /VPR Fail Ages Proc Drops Reads Wrts Drops Reads /Swp /Swp Drops Reads Writes P+S
Date Time Id Free /Sec /Sec Aloc % /Sec Swap /Sec /Sec /Sec /Sec /Sec Drp Rd /Sec /Sec /Sec IO %
-------- -------- ------ ---- ----- ----- ---- ---- ---- ---- ----- ----- ----- ----- ----- ---- ---- ------ ------ ------ ----
00/10/16 11:20:00 001-03 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:25:00 001-03 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:30:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:35:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 12.6 0.2 0.0 0.0 ? ? 0.0 12.6 0.2 14%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 14.0 0.0 0.0 0.0 ? ? 0.0 14.0 0.0 21%
11:40:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 3.6 0.2 0.0 0.0 ? ? 0.0 3.6 0.2 4%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 2.8 0.0 0.0 0.0 ? ? 0.0 2.8 0.0 3%
11:45:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
11:50:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 0.4 0.0 0.0 0.0 ? ? 0.0 0.4 0.0 0%
11:55:00 001-03 11% 0.0 0.0 ? ? 0.0 0 0.0 1.4 0.2 0.0 0.0 ? ? 0.0 1.4 0.2 2%
001-04 11% 0.0 0.0 ? ? 0.0 0 0.0 1.0 0.0 0.0 0.0 ? ? 0.0 1.0 0.0 1%
Note: The NodeId column only appears in the ResMemMgmtByNode output report.
ResMemMgmtOneNode Sample Output

00/10/16 Memory Management Activity for Node 001-03 Page 1
Mem Alocs Alocs /VPR Fail Ages Proc Drops Reads Wrts Drops Reads /Swp /Swp Drops Reads Writes P+S
Date Time Free /Sec /Sec Aloc % /Sec Swap /Sec /Sec /Sec /Sec /Sec Drp Rd /Sec /Sec /Sec IO %
-------- -------- ---- ----- ----- ---- ---- ---- ---- ----- ----- ----- ----- ----- ---- ---- ------ ------ ------ ----
00/10/16 10:19:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 ?
10:20:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:21:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:22:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:23:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:30:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:35:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:40:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:45:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:50:00 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
10:55:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.8 0.0 0.0 0.0 ? ? 0.0 0.8 0.0 43%
11:00:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 14%
11:05:00 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:10:00 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:15:00 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%

ResNetByNode Macros
ResMemByGroup Sample Output

00/10/16 MEMORY MGMT ACTIVITY BY NODE GROUP Page 2
Group Mem Alocs Alocs /VPR Fail Ages Proc Drops Reads Wrts Drops Reads /Swp /Swp Drops Reads Writes P+S
Date Time Id Free /Sec /Sec Aloc % /Sec Swap /Sec /Sec /Sec /Sec /Sec Drp Rd /Sec /Sec /Sec IO %
------- ----- ----- ---- ----- ----- ---- ---- ---- ---- ----- ----- ----- ----- ----- ---- ---- ------ ------ ------ ----
00/10/16 11:20:00 A 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:25:00 A 10% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:30:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
11:35:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 12.6 0.2 0.0 0.0 ? ? 0.0 12.6 0.2 14%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 14.0 0.0 0.0 0.0 ? ? 0.0 14.0 0.0 21%
11:40:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 3.6 0.2 0.0 0.0 ? ? 0.0 3.6 0.2 4%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 2.8 0.0 0.0 0.0 ? ? 0.0 2.8 0.0 3%
11:45:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
11:50:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.4 0.0 0.0 0.0 ? ? 0.0 0.4 0.0 0%
11:55:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 1.4 0.2 0.0 0.0 ? ? 0.0 1.4 0.2 2%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 1.0 0.0 0.0 0.0 ? ? 0.0 1.0 0.0 1%
12:00:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
12:05:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
12:10:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.2 0.0 0.0 0.0 ? ? 0.0 0.2 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
12:15:00 A 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
B 11% 0.0 0.0 ? ? 0.0 0 0.0 0.0 0.0 0.0 0.0 ? ? 0.0 0.0 0.0 0%
Note: The GroupID column only appears in the ResMemByGroup output report.
ResNetByNode Macros
Function
The following table describes the ResNetByNode macros:
Macro... Reports net traffic for...
ResNetByNode each node.
ResNetOneNode a specific node.
ResNetByGroup nodes summarized by node groups.

ResNetByNode Macros

The input form of the ResNetByNode macro is:
EXEC ResNetByNode
The input form of the ResNetOneNode macro is:
EXEC ResNetOneNode
The input form of the ResNetByGroup macro is:
EXEC ResNetByGroup
Usage Notes
Output Examples
The reports in the following sections are sample output reports from the ResNetByNode, the
ResNetOneNode, and the ResNetByGroup macros, respectively, where: Deleted Net 0 and
Net1 columns.
% Retries percent of total net circuit attempts that caused “software backoffs”
(BNS service-blocked occurrences).
Note: This value reflects how many times the hardware backed off a
connection because the switch nodes could not route to the end
point. That implies that the end point was busy or, in switch node
terms, the routing path was busy. A value over 100% does not imply a
problem, but shows that there were multiple attempts to send new
messages while the Bynet path was busy. On a busy system, this can be
a normal level of activity.
Total Reads/ Sec average number of net reads per second.
Total Writes/ Sec average number of net writes per second.
Total IOs/ Sec average number of net reads and writes per second.
KB/ IO average KBs per net read or write.

ResNetByNode Macros
% PtP percent of total net reads and writes that are point-to-point reads and
writes.
% Brd percent of total net reads and writes that are broadcast reads and
writes.
Note: In the following examples, the NodeId column appears only in the ResNetByNode
output report. The GroupID column only appears in the ResNetByGroup output report. For
all the examples, the values in the Total Reads/ Sec and Total Writes/ Sec are expected to be
equal on SMP (single-node, vnet) systems.
ResNetByNode Sample Output

00/10/16 NET ACTIVITY BY NODE Page 2
Total Total Total

Node % Re- Reads Writes IOs KB % %
Date Time Id tries /Sec /Sec /Sec /IO PtP Brd
---------- -------- ------ ------ ------- ------- ------- ------ --- ---
2000/10/16 11:20:00 001-03 0.0% 0.46 0.39 0.85 0.4 92 8
001-04 0.0% 0.55 0.47 1.02 0.4 93 7
11:25:00 001-03 0.0% 0.39 0.33 0.72 0.4 90 10

001-04 0.0% 0.39 0.32 0.71 0.4 90 10
11:30:00 001-03 0.0% 0.44 0.37 0.81 0.4 91 9

001-04 0.0% 0.55 0.47 1.02 0.4 92 8
11:35:00 001-03 2.5% 20.84 12.53 33.37 1.8 73 27

001-04 2.5% 23.07 15.51 38.58 1.8 74 26
11:40:00 001-03 24.7% 35.44 35.56 71.00 17.4 93 7

001-04 20.6% 37.16 38.87 76.03 13.8 93 7
11:45:00 001-03 15.9% 13.47 10.71 24.18 8.3 76 24

001-04 28.1% 11.79 12.63 24.42 12.8 83 17
11:50:00 001-03 3.3% 18.92 14.18 33.11 1.3 77 23

001-04 4.1% 22.77 20.97 43.74 1.9 75 25
ResNetOneNode Sample Output

00/10/16 Net Activity for Node 001-03 Page 1
Total Total Total

% Re- Reads Writes IOs KB % %
Date Time tries /Sec /Sec /Sec /IO PtP Brd
-------- -------- ------ ------- ------- ------- ------ --- ---
00/10/16 10:19:00 0.0% 0.78 0.07 0.85 1.1 8 92
10:20:00 0.0% 2.87 2.65 5.52 0.5 96 4
10:21:00 0.0% 3.08 2.07 5.15 0.6 80 20
10:22:00 0.0% 2.13 2.07 4.20 0.5 98 2
10:23:00 0.0% 2.23 2.17 4.40 0.5 98 2
10:30:00 0.0% 0.25 0.18 0.43 0.4 84 16
10:35:00 0.0% 0.53 0.47 1.00 0.4 93 7
10:40:00 0.0% 0.51 0.44 0.95 0.5 93 7
10:45:00 0.0% 0.48 0.42 0.90 0.4 92 8
10:50:00 0.0% 0.52 0.45 0.97 0.5 93 7
10:55:00 0.0% 0.46 0.39 0.85 0.4 92 8
11:00:00 0.0% 0.58 0.51 1.09 0.4 94 6
11:05:00 0.0% 0.57 0.38 0.95 0.5 79 21
11:10:00 0.0% 0.54 0.47 1.01 0.4 93 7
11:15:00 0.0% 0.46 0.40 0.86 0.5 92 8
11:20:00 0.0% 0.46 0.39 0.85 0.4 92 8

ResNode Macros
ResNetByGroup Sample Output

00/10/16 NET ACTIVITY BY Group Page 2
Group % Re- Reads Writes IOs KB % %

Date Time Id tries /Sec /Sec /Sec /IO PtP Brd
---------- -------- ------ ------ ------- ------- ------- ------ --- ---
2000/10/16 11:20:00 B 0.0% 0.55 0.47 1.02 0.4 93 7
11:25:00 A 0.0% 0.39 0.33 0.72 0.4 90 10

B 0.0% 0.39 0.32 0.71 0.4 90 10
11:30:00 A 0.0% 0.44 0.37 0.81 0.4 91 9

B 0.0% 0.55 0.47 1.02 0.4 92 8
11:35:00 A 2.5% 20.84 12.53 33.37 1.8 73 27

B 2.5% 23.07 15.51 38.58 1.8 74 26
11:40:00 A 24.7% 35.44 35.56 71.00 17.4 93 7

B 20.6% 37.16 38.87 76.03 13.8 93 7
11:45:00 A 15.9% 13.47 10.71 24.18 8.3 76 24

B 28.1% 11.79 12.63 24.42 12.8 83 17
11:50:00 A 3.3% 18.92 14.18 33.11 1.3 77 23

B 4.1% 22.77 20.97 43.74 1.9 75 25
11:55:00 A 55.8% 40.01 33.45 73.46 22.3 95 5

B 41.1% 44.35 44.37 88.72 17.7 96 4
12:00:00 A 5.1% 19.11 13.16 32.27 2.0 73 27

B 5.8% 22.13 11.03 33.16 1.7 70 30
12:05:00 A 24.2% 33.09 28.57 61.67 14.6 90 10

B 10.6% 26.97 25.97 52.94 5.5 91 9
12:10:00 A 73.8% 17.33 14.01 31.34 23.2 91 9

B 57.4% 28.12 26.65 54.77 23.0 93 7
12:15:00 A 3.9% 21.02 16.10 37.12 2.0 73 27

B 6.3% 22.13 14.70 36.83 1.8 73 27
12:20:00 A 48.7% 36.18 34.65 70.83 18.0 95 5

B 34.9% 38.16 33.70 71.86 13.2 93 7
ResNode Macros
Function
The following table describes the ResNode macros:
Macro... Provides a summary of resource usage...
ResNode averaged across all nodes.
ResOneNode for a specific node.
ResNodeByNode node by node.
ResNodeByGroup for a node grouping.

ResNode Macros

The input form of the ResNode macro is:
EXEC ResNode
Note: The ResNode macro syntax does not include the FromNode and ToNode parameters to
specify a range of nodes.
The input form of the ResOneNode macro is:
EXEC ResOneNode
The input form of the ResNodeByNode macro is:
EXEC ResNodeByNode
The input form of the ResNodeByGroup macro is:
EXEC ResNodeByGroup
ToTime, FromNode, ToNode, and Node parameters.
Usage Notes
Output Examples
The reports in the following sections are sample output reports from the ResNode, the
ResOneNode, the ResNodebyNode, and the ResNodeByGroup macros, respectively.
In the ResNode output report, after the Date and Time columns, 19 statistics columns present
the following information:
1 through 3 CPU usage.
4 through 8 Logical device interface.
9 through 14 Memory interface.
15 through 17 Net interface.
18 and 19 General node process scheduling.

ResNode Macros
In the ResOneNode output report, after the Date and Time columns, 16 statistics columns
1 and 2 CPU usage.
In the ResNodebyNode output report, after the Date and Time columns, 17 statistics columns
1 and 2 CPU usage.
In the ResNodeByGroup output report, after the Date and Time columns, 17 statistics
columns present the following information:
1 GroupId as defined in the associated view as a grouping of one or

more nodes.
2 and 3 CPU usage.

ResNode Macros
In all output reports (with the exception of ResNodeByNode which has a NodeId column and
ResNodeByGroup which has a GroupId column) the columns are described as follows:
CPU Bsy % percent of time the CPUs are busy, based on average CPU usage
per node.
CPU Eff % (ResNode report) parallel efficiency of node CPU usage.

Parallel efficiency is the total percent of time nodes are busy. It is
the average for all nodes of total busy divided by the total busy
time of the busiest node.
WIO % percent of time the CPUs are idle and waiting for completion of an
I/O operation.
Ldv IOs /Sec average number of logical device reads and writes per second for
each node.
Ldv Eff % parallel efficiency of the logical device (disk) I/Os. It is the average
number of I/Os per node divided by the number of I/Os
(ResNode report)
performed by the node with the most I/Os.
P+S % of IOs percent of logical device reads and writes that are for paging or
swapping purposes.
Read % of IOs percent of logical device reads and writes that are reads.
Ldv KB / IO average size of a logical device read or write.
Fre Mem % percent of memory that is unused.
Mem Aloc / Sec average number of memory allocations per second, per node.
Mem Fai % percent of memory allocation attempts that failed.
Mem Age /Sc Average number of times memory pages were aged out per
second, per node.
A+R % of IOs percent of logical device reads and writes that are disk segment
reads and writes.
TPtP IOs /Sec total point-to-point net reads and writes per second, per node.
TMlt IOs /Sec total multicast (broadcast or merge) net reads and writes per
second, per node.
Net Rtry % percent of transmission attempts that resulted in retries.
Prc Blks / Sec number of times per second, per node, that processes other than
message and timer waits are blocked.
ms /Blk average time, in milliseconds, spent waiting for a blocked process

other than message and timer waits.
Net Rx Bsy % percent of time the network was busy either receiving.
Net Tx Bsy % percent of time the network was busy transmitting.

ResNode Macros
ResNode Sample Output

01/07/12 GENERAL RESUSAGE SUMMARY Page 4
Average across all nodes
CPU CPU Ldv Ldv P+S Rd Ldv Fre Mem Mem Mem A+R TPtP TMlt Net Prc ms Net Net
Bsy Eff WIO IOs Eff %of %of KB Mem Aloc Fai Age %of IOs IOs Rty Blks / Rx Tx
Date Time % % % /Sec % IOs IOs /IO % /Sec % /Sec IOs /Sec /Sec % /Sec Blk Bsy% Bsy%
------- -------- --- --- --- ----- --- --- --- --- --- ----- --- ---- --- ----- ----- --- ----- ------ -- ---
01/07/12 04:45:40 2 100 15 16 100 0 0 22 1 1 0 0 100 0 0 0 40 386 ? ?
04:46:00 2 100 16 16 100 0 0 23 1 1 0 0 100 0 0 0 39 561 ? ?
04:46:20 1 100 16 16 100 0 0 19 1 1 0 0 100 0 0 0 39 383 ? ?
04:46:40 2 100 17 16 100 0 0 24 1 1 0 0 100 0 0 0 40 437 ? ?
04:47:00 2 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 39 532 ? ?
04:47:20 1 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 40 383 ? ?
04:47:40 1 100 17 17 100 0 0 22 1 1 0 0 100 0 0 0 41 417 ? ?
04:48:00 2 100 15 16 100 0 0 24 1 1 0 0 100 0 0 0 39 446 ? ?
04:48:20 1 100 14 16 100 0 0 24 1 1 0 0 100 0 0 0 40 426 ? ?
04:48:40 2 100 16 17 100 0 0 23 1 1 0 0 100 0 0 0 41 1173 ? ?
04:49:00 2 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 39 456 ? ?
04:49:20 2 100 17 17 100 0 0 23 1 1 0 0 100 0 0 0 41 416 ? ?
04:49:40 2 100 16 17 100 0 0 22 1 1 0 0 100 0 0 0 41 395 ? ?
04:50:00 2 100 16 16 100 0 0 23 1 3 0 0 100 0 0 0 42 2481 ? ?
04:50:20 1 100 15 16 100 0 0 18 1 1 0 0 100 0 0 0 39 463 ? ?
04:50:40 1 100 16 16 100 0 0 20 1 1 0 0 100 0 0 0 40 353 ? ?
04:51:00 2 100 16 16 100 0 0 21 1 1 0 0 100 0 0 0 39 662 ? ?
04:51:20 1 100 16 16 100 0 0 19 1 1 0 0 100 0 0 0 40 505 ? ?
04:51:40 2 100 16 17 100 0 0 23 1 1 0 0 100 0 0 0 42 341 ? ?
04:52:00 2 100 15 16 100 0 0 19 1 1 0 0 100 0 0 0 39 537 ? ?
04:52:20 1 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 40 480 ? ?
04:52:40 1 100 15 16 100 0 0 19 1 1 0 0 100 0 0 0 40 395 ? ?
04:53:00 2 100 15 16 100 0 0 18 1 1 0 0 100 0 0 0 39 491 ? ?
04:53:20 1 100 15 16 100 0 0 20 1 1 0 0 100 0 0 0 40 461 ? ?
04:53:40 2 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 40 1093 ? ?
04:54:00 2 100 16 16 100 0 0 22 1 1 0 0 100 0 0 0 40 442 ? ?
04:54:20 1 100 16 17 100 0 0 19 1 1 0 0 100 0 0 0 40 450 ? ?
04:54:40 2 100 15 17 100 0 0 22 1 1 0 0 100 0 0 0 41 432 ? ?
ResOneNode Sample Output

01/07/12 General Resource Usage Summary for Node 001-01 Page 01
CPU Ldv P+S Rd Ldv Fre Mem Mem Mem A+R TPtP TMlt Net Prc ms Net Net
Bsy WIO IOs %of %of KB Mem Aloc Fai Age %of IOs IOs Rtry Blks / Rx Tx
Date Time % % /Sec IOs IOs /IO % /Sec % /Sc IOs /Sec /Sec % /Sec Blk Bsy% Bsy%
------- ------- --- --- ----- --- --- --- --- ----- --- --- --- ----- ----- --- --- ---- --- ----
1/07/12 09:44:20 2 16 17 0 0 21 1 1 0 0 100 0 0 0 41 477 ? ?
09:44:40 1 17 16 0 0 20 1 1 0 0 100 0 0 0 41 371 ? ?
09:45:00 1 16 16 0 0 21 1 1 0 0 100 0 0 0 39 2810 ? ?
09:45:20 2 17 16 0 0 22 1 1 0 0 100 0 0 0 40 540 ? ?
09:45:40 1 17 16 0 0 19 1 1 0 0 100 0 0 0 40 362 ? ?
09:46:00 2 17 16 0 0 23 1 1 0 0 100 0 0 0 40 371 ? ?
09:46:20 2 16 17 0 0 22 1 1 0 0 100 0 0 0 40 555 ? ?
09:46:40 1 16 16 0 0 20 1 1 0 0 100 0 0 0 40 390 ? ?
09:47:00 2 16 17 0 0 24 1 1 0 0 100 0 0 0 40 366 ? ?
09:47:20 2 16 16 0 0 21 1 1 0 0 100 0 0 0 40 520 ? ?
09:47:40 2 17 16 0 0 20 1 1 0 0 100 0 0 0 40 439 ? ?
09:48:00 1 15 16 0 0 23 1 1 0 0 100 0 0 0 40 433 ? ?
09:48:20 2 16 16 0 0 21 1 1 0 0 100 0 0 0 40 499 ? ?
09:48:40 2 16 17 0 0 24 1 1 0 0 100 0 0 0 41 1142 ? ?
09:49:00 1 16 16 0 0 22 1 1 0 0 100 0 0 0 39 378 ? ?
09:49:20 2 16 17 0 0 20 1 1 0 0 100 0 0 0 41 543 ? ?
09:49:40 2 17 16 0 0 20 1 1 0 0 100 0 0 0 41 363 ? ?
09:50:00 1 16 16 0 0 19 1 3 0 0 100 0 0 0 40 2598 ? ?
09:50:20 2 17 16 0 0 20 1 1 0 0 100 0 0 0 40 506 ? ?

ResPs Macros
ResNodeByNode Sample Output

01/07/12 Node by Node General Resource Usage Summary Page 8
CPU Ldv P+S Rd Ldv Fre Mem Mem Mem A+R TPtP TMlt Net Prc ms Net Net
Bsy WIO IOs %of %of KB Mem Aloc Fai Age %of IOs IOs Rty Blks / Rx Tx
Date Time NodeId % % /Sec IOs IOs /IO % /Sec % /Sc IOs /Sec /Sec % /Sec Blk Bsy% Bsy%
------ -------- ------ --- --- ----- --- --- --- --- ----- --- ---- --- ----- ----- ---- ----- ------ ---- ----
01/07/12 04:55:40 001-01 2 17 17 0 0 26 1 1 0 0 100 0 0 0 42 442 ? ?
04:56:00 001-01 2 15 16 0 0 22 1 3 0 0 100 0 0 0 41 4887 ? ?
04:56:20 001-01 2 14 16 0 0 22 1 7 0 0 100 0 0 0 41 3844 ? ?
04:56:40 001-01 2 16 17 0 0 23 1 6 0 0 100 0 0 0 43 402 ? ?
04:57:00 001-01 2 16 16 0 0 23 1 1 0 0 100 0 0 0 40 521 ? ?
04:57:20 001-01 1 16 16 0 0 24 1 1 0 0 100 0 0 0 40 529 ? ?
04:57:40 001-01 1 15 16 0 0 22 1 1 0 0 100 0 0 0 40 387 ? ?
04:58:00 001-01 1 16 16 0 0 22 1 1 0 0 100 0 0 0 39 452 ? ?
04:58:20 001-01 1 15 16 0 0 22 1 1 0 0 100 0 0 0 40 381 ? ?
04:58:40 001-01 1 16 16 0 0 22 1 1 0 0 100 0 0 0 40 1281 ? ?
04:59:00 001-01 2 16 16 0 0 21 1 1 0 0 100 0 0 0 39 452 ? ?
ResNodeByGroup Sample Output

01/07/12 GENERAL RESOURCE USAGE SUMMARY BY GROUP Page 8
CPU Ldv P+S Rd Ldv Fre Mem Mem A+R TPtP TMlt Net Prc ms Net Net
Group Bsy WIO IOs %of % of KB Mem Aloc Fai %of IOs IOs Rty Blks / Rx Tx
Date Time Id % % /Sec IOs IOs /IO % /Sec % IOs /Sec /Sec % /Sec Blk Bsy Bsy%
-------- -------- ----- --- --- ----- --- ---- --- --- ----- --- --- ----- ----- ---- ----- ------ ---- ----
01/07/12 04:55:40 A 2 17 17 0 0 26 1 1 0 100 0 0 0 42 442 ? ?
04:56:00 A 2 15 16 0 0 22 1 3 0 100 0 0 0 41 4887 ? ?
04:56:20 A 2 14 16 0 0 22 1 7 0 100 0 0 0 41 3844 ? ?
04:56:40 A 2 16 17 0 0 23 1 6 0 100 0 0 0 43 402 ? ?
04:57:00 A 2 16 16 0 0 23 1 1 0 100 0 0 0 40 521 ? ?
04:57:20 A 1 16 16 0 0 24 1 1 0 100 0 0 0 40 529 ? ?
04:57:40 A 1 15 16 0 0 22 1 1 0 100 0 0 0 40 387 ? ?
04:58:00 A 1 16 16 0 0 22 1 1 0 100 0 0 0 39 452 ? ?
04:58:20 A 1 15 16 0 0 22 1 1 0 100 0 0 0 40 381 ? ?
04:58:40 A 1 16 16 0 0 22 1 1 0 100 0 0 0 40 1281 ? ?
04:59:00 A 2 16 16 0 0 21 1 1 0 100 0 0 0 39 452 ? ?
ResPs Macros
Function
The following table describes the ResPs macros:
Macro... Provides a summary of the Priority Scheduler resource usage...
ResPsByNode by node, produces one row of data for each Performance Group
ID, for each logging period.
ResPsByGroup by coexistence group, produces one row of data for each node type
in the system per logging period.
ResPsByNodeWDJoin aggregated by all AMPs in an individual node and Allocation

Group ID, produces one row of data for each workload and
performance period combination, for each logging period.
ResPsWDJoin aggregated by all AMPs for all nodes in the system.

ResPs Macros

The input form of the ResPsByNode macro is:
EXEC ResPsByNode
The input form of the ResPsByGroup macro is:
EXEC ResPsByGroup
The input form of the ResPsByNodeWDJoin macro is:
EXEC ResPsByNodeWDJoin
The input form of the ResPsWDJoin macro is:
EXEC ResPsWDJoin
ToTime, FromNode, ToNode, and Node parameters.
Note: Coexistence support can be accomplished using the NodeType column to do a “group
by” in SQL directly. Therefore, the GroupId column is not needed and the ResUsageSps table
view is not provided.
Usage Notes
• Logging must be enabled on ResUsageSps.
In order for the ResPsWDJoin and ResPsByNodeWDJoin macros to function, you must have
Teradata DWM Category 3 rule (Workloads) enabled and the workloads defined. Each
defined workload is internally associated with a priority scheduler Performance Group, which
in turn is associated with Allocation Groups. These macros display the critical workloads in
the context of their Allocation Group relationships. For information on working with
Teradata DWM rules, see Teradata Dynamic Workload Manager User Guide.
The ResPsWDJoin and ResPsByNodeWDJoin macros are not currently available in Teradata
Database 12.0, but can be obtained from the Orange Book: Teradata Active Systems
Output Examples
The reports in the following sections are sample output reports from the ResPsByNode,
ResPsByGroup, ResPsByNodeWDJoin, and ResPsWDJoin macros, respectively.

ResPs Macros
In the ResPsByNode output report, after the Date and Time columns, 12 statistics columns
1 Node ID.
2 Performance Group ID.
3 through 12 Summary of the Priority Scheduler statistics.
In the ResPsByGroup output report, after the Date and Time columns, 11 statistics columns
1 Node type.
2 through 11 Summary of the Priority Scheduler statistics.
In the ResPsByNodeWDJoin output report, after the Date and Time columns, 15 statistics
1 Node ID.
2 Allocation Group ID.
3 Relative weight.
4 Workload name.
5 Performance period ID.
6 through 15 Summary of the Priority Scheduler and Teradata ASM workload

statistics.
In the ResPsWDJoin output report, after the Date and Time columns, 14 statistics columns
2 Relative weight.
3 Workload name.

ResPs Macros
5 through 14 Summary of the Priority Scheduler and Teradata ASM workload

statistics.
In all output reports (with the exception of the ResPsWDJoin and ResPsByNodeWDJoin
macros which have the “CPU ms” column) the summary statistics columns are described as
follows:
CPU Bsy % percent of CPU time consumed by a task associated or running

under the Performance Group.
Note: This column is not reported in the ResPsWDJoin and
ResPsByNodeWDJoin macro outputs.
CPU ms amount of CPU time in milliseconds consumed by a task

associated or running under the Allocation Group (AG).
Note: This column is reported in the ResPsWDJoin and
ResPsByNodeWDJoin macro outputs only.
IO Blks / Sec average number of logical data blocks read and (or) written by
Performance Group per second.
Num Procs number of processes assigned to the Performance Group at the

end of the collection period.
Num Requests number of requests of the AWT.
Avg QWait Time average QWaitTime for each request during a specified period.
Max QWait Time maximum time in milliseconds that work requests waited on an
input queue before being serviced.
Q Length number of work requests waiting on the input queue for service.
Q Length Max maximum number of work requests waiting on the input queue
for service.
Avg Svc Time average ServiceTime for each request during a specified period.
Max Svc Time maximum time in milliseconds that work requests required for
service.
For a complete description of these columns, see Chapter 11: “ResUsageSps Table.”

ResPs Macros
ResPsByNode Macro Sample Output
07/05/07 PS by Node Usage Summary Page Page 6

Date Time NodeID PGid CPU IO Num Num Avg Max Q Q Avg Max
Bsy Blks/ Procs Requests QWait QWait Length Len Svc Svc
% Sec Time Time Max Time Time
-------- --------- ------- ---- --- ----- ---- ------- ----- ---- ----- ---- ----- -----
07/05/07 14:40:00 1-05 1 0 0 0 0 ? 0 0 0 ? 0
1-05 40 1 0 50 5 0 0 0 0 62 100
15:00:00 1-04 0 0 0 0 0 ? 0 0 0 ? 0
1-04 40 1 0 54 2 0 0 0 0 215 220
1-05 0 0 0 0 0 ? 10 0 0 ? 0
1-05 40 1 0 50 3 2 0 0 0 162 270
15:20:00 1-04 0 0 0 0 0 ? 0 0 0 ? 0
1-04 40 1 0 54 3 0 0 0 0 97 180
1-05 0 0 0 0 0 ? 0 0 0 ? 0
1-05 40 1 0 50 3 0 0 0 0 93 160
15:40:00 1-04 0 0 0 0 0 ? 0 0 0 ? 0
1-04 40 1 0 54 4 ? 0 0 0 50 80
1-05 0 0 0 0 0 0 0 0 0 ? 0
1-05 40 1 0 50 3 ? 0 0 0 102 150
16:00:00 1-04 0 0 0 0 0 ? 0 0 0 ? 0
1-04 3 1 0 0 0 ? 0 0 0 ? 0
1-04 40 0 0 54 3 0 0 0 0 130 160
1-05 0 1 0 0 0 ? 0 0 0 ? 0
1-05 40 0 0 50 5 0 0 0 0 71 260
17:00:00 1-04 0 0 0 0 0 ? 0 0 0 ? 0
1-04 40 1 0 54 3 0 0 0 0 112 140
1-05 0 0 0 0 0 ? 0 0 0 ? 0
1-05 40 1 0 0 50 3 0 0 0 62 90
ResPsByGroup Macro Sample Output

07/05/04 PS by Group Usage Summary Page 1
CPU IO Avg Max Q Avg Max

Node Bsy Blks Num Num QWait QWait Q Len Svc Svc
Date Time Type % /Sec Procs Requests Time Time Length MaxTime Time
------- -------- ---- --- ------- ------- -------- ------ ------- ------- ------- ------ -------
07/05/04 13:00:00 UNKN 0 0 3 5 1 10 0 0 30 200
13:10:00 UNKN 0 0 5 0 0 0 0 0 102 210
13:20:00 UNKN 0 0 3 3 0 10 0 0 30 160
14:00:00 UNKN 0 0 3 3 0 10 0 0 52 240

ResPsByNodeWDJoin Macro Sample Output
07/08/09 Workload Usage Summary (Average Usage per AMP By Node) Page 1
IO Avg Max Q Avg Max

Node AG Rel Workload (WD) PP CPU Blks Num Num QWait QWait Q Len Svc Svc
Date Time ID ID Wgt Name ID ms /Sec Procs Requests Time Time Length Max Time Time
-------- -------- ------ --- --- ------------------------------ -- ------ ----- ------ -------- ------ ------- ------ ------ ------- -------
07/08/06 17:57:00 1-04 1 1 ? 0 0 0 0 0 ? 0 0 0 ? 0
2 2 ? 0 0 0 0 0 ? 0 0 0 ? 0
3 5 ? 0 0 0 0 0 ? 0 0 0 ? 0
4 10 ? 0 36 0 0 48 4 70 0 0 2 100
5 48 All_Tactical 0 1084 7 0 364 3 220 0 0 18 1160

TDWM 0 0 0 0 0 ? 0 0 0 ? 0
7 11 Continious Load 0 4156 36 0 2679 3 400 0 0 35 4120

LobLoader 0 0 0 0 0 ? 0 0 0 ? 0
Teradata Manger 0 19 0 0 18 2 30 0 0 14 280
WD-ConsoleH 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleR 0 0 0 0 0 ? 0 0 0 ? 0
8 5 ADW_Strategic 0 2506 2 13 110 4 210 0 0 1548 41680

DWD_OLAP 0 0 0 0 0 ? 0 0 0 ? 0
Java Stored Procedures 0 0 0 0 0 ? 0 0 0 ? 0
Mixedsql 0 2848 10 21 124 5 340 0 0 1303 47370
Multiuser Simulation 0 995 9 7 0 ? 0 0 0 ? 1063680
PEstress 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleM 0 0 0 0 0 ? 0 0 0 ? 0
WD-Default 0 10 0 0 12 13 130 0 0 309 3720
9 2 Penalty_box 0 2613 3 4 43 4 30 0 0 7072 67660

WD-ConsoleL 0 0 0 0 0 ? 0 0 0 ? 0
10 12 All_Tactical 1 911 2 0 1 22 220 0 0 3875 500

qmiles 0 3769 4 0 87 9 240 0 0 333 4740
200 100 ? 0 1048 10 6 270 2 50 0 0 24 1980
1-05 1 1 ? 0 0 0 0 0 ? 0 0 0 ? 0
2 2 ? 0 0 0 0 0 ? 0 0 0 ? 0
3 5 ? 0 0 0 0 0 ? 0 0 0 ? 0
4 10 ? 0 64 0 0 64 3 160 0 0 12 830
5 48 All_Tactical 0 957 7 0 340 3 290 0 0 45 2730

TDWM 0 0 0 0 0 ? 0 0 0 ? 0
7 11 Continious Load 0 8223 85 1 3401 2 550 0 0 25 4220

LobLoader 0 0 0 0 0 ? 0 0 0 ? 0
Teradata Manger 0 19 0 0 17 4 80 0 0 23 100
WD-ConsoleH 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleR 0 0 0 0 0 ? 0 0 0 ? 0
8 5 ADW_Strategic 0 1802 4 3 66 6 50 0 0 5564 82900

DWD_OLAP 0 0 0 0 0 ? 0 0 0 ? 0
Mixedsql 0 1573 6 5 427 4 170 0 0 1529 82110
PEstress 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleM 0 0 0 0 0 ? 0 0 0 ? 0
WD-Default 0 9 0 0 12 4 20 0 0 134 960
9 2 Penalty_box 0 1313 2 4 10 5 30 0 0 13160 98350

WD-ConsoleL 0 0 0 0 0 ? 0 0 0 ? 0
193
10 12 All_Tactical 1 670 2 0 3 84 510 0 0 1886 1890
194
qmiles 0 2916 3 0 69 12 530 0 0 345 4710
200 100 ? 0 1062 10 6 226 2 360 0 0 32 3570
Note: Question marks used as values in the Workload (WD) Name column in the output above mean there is no associated
workload to the Performance Group (PG ID)/Performance Period (PP ID). However, if the question mark is used as a value in
any other column, the it indicates there is no information to report for this time period (see “Question Marks” on page 156 for
details).
ResPsWDJoin Macro Sample Output

07/08/09 Workload Usage Summary (Average Usage per AMP) Page 1
IO Avg Max Q Avg Max

AG Rel Workload (WD) PP CPU Blks Num Num QWait QWait Q Len Svc Svc
Date Time ID Wgt Name ID ms /Sec Procs Requests Time Time Length Max Time Time
07/08/06 17:57:00 1 1 ? 0 0 0 0 0 ? 0 0 0 ? 0
2 2 ? 0 0 0 0 0 ? 0 0 0 ? 0
3 5 ? 0 0 0 0 0 ? 0 0 0 ? 0
4 10 ? 0 50 0 0 56 4 160 0 0 7 830
5 48 All_Tactical 0 1020 7 0 352 3 290 0 0 31 2730

TDWM 0 0 0 0 0 ? 0 0 0 ? 0
7 11 Continious Load 0 6190 60 1 3040 2 550 0 0 30 4220

LobLoader 0 0 0 0 0 ? 0 0 0 ? 0
Teradata Manger 0 19 0 0 18 3 80 0 0 19 280
WD-ConsoleH 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleR 0 0 0 0 0 ? 0 0 0 ? 0
8 5 ADW_Strategic 0 2154 3 8 88 5 210 0 0 3556 82900

DWD_OLAP 0 0 0 0 0 ? 0 0 0 ? 0
Mixedsql 0 2210 8 13 276 5 340 0 0 1416 82110
PEstress 0 0 0 0 0 ? 0 0 0 ? 0
WD-ConsoleM 0 0 0 0 0 ? 0 0 0 ? 0
WD-Default 0 10 0 0 12 9 130 0 0 222 3720
9 2 Penalty_box 0 1963 2 4 27 4 30 0 0 10116 98350

WD-ConsoleL 0 0 0 0 0 ? 0 0 0 ? 0
10 12 All_Tactical 1 790 2 0 2 53 510 0 0 2881 1890

qmiles 0 3342 3 0 78 10 530 0 0 339 4740
200 100 ? 0 1055 10 6 248 2 360 0 0 28 3570
Note: Question marks used as values in the Workload (WD) Name column in the output above mean there is no associated
workload to the Performance Group (PG ID)/Performance Period (PP ID). However, if the question mark is used as a value in
any other column, the it indicates there is no information to report for this time period (see “Question Marks” on page 156 for
details).
ResPsCPU Macros
ResPsCPU Macros
Function
The following table describes the ResPsCPU macros:
Macro... Reports ...
ResPsCPUByNodeWDJoin the summary of CPU usage by node, Allocation Group, and

workload as compared to the real-time relative weight of each
Allocation Group.
ResPsCPUWDJoin the summary of CPU usage for all nodes, Allocation Groups,
and workloads in the system as compared to the real-time
relative weight of each Allocation Group.

The input form of the ResPsCPUByNodeWDJoin macro is:
EXEC ResPsCPUByNodeWDJoin
The input form of the ResPsCPUWDJoin macro is:
EXEC ResPsCPUWDJoin
Usage Notes
The following usage notes apply to this macro:
• Logging must be enabled on ResUsageSps.
In order for the ResPsCPUWDJoin and ResPsCPUByNodeWDJoin macros to function, you
must have Teradata DWM Category 3 rule (Workloads) enabled and the workloads defined.
Each defined workload is internally associated with a priority scheduler Performance Group,
which in turn is associated with Allocation Groups. These macros display the critical
workloads in the context of their Allocation Group relationships. For information on working
with Teradata DWM rules, see Teradata Dynamic Workload Manager User Guide.
The ResPsCPUWDJoin and ResPsCPUByNodeWDJoin macros are not currently available in
Teradata Database 12.0, but can be obtained from the Orange Book: Teradata Active Systems

ResPsCPU Macros
Output Examples
The reports in the following sections are sample output reports from the
PsCPUByNodeWDJoin and ResPsCPUWDJoin macros.
In the ResPsCPUByNodeWDJoin output report, after the Date and Time columns, 7 statistics
1 Node ID.
2 Allocation GroupID.
3 Relative weight.
4 Workload name.
6 and 7 Summary of CPU usage and number of processes of the workload

and relative weights. Also, a summary of the current relative
weight of each associated Allocation Group.
In the ResPsCPUWDJoin output report, after the Date and Time columns, 6 statistics
2 Relative weight.
3 Workload name.
5 and 6 Summary of CPU usage and number of processes of the workload

and relative weights. Also, a summary of the current relative
weight of each associated Allocation Group.
In all output reports (with the exception of the ResPsCPUByNodeWDJoin macro which has
the NodeId column) are described as follows:
CPU Bsy % percent of CPU time consumed by a task associated or running

under the Performance Group.
Num Procs number of processes assigned to the Performance Group at the

end of the collection period.

ResPsCPU Macros
For a complete description of these columns, see Chapter 11: “ResUsageSps Table.”
ResPsCPUByNodeWDJoin Macro Sample Output

07/08/09 Workload Usage Summary- CPU Usage vs Relative Weights Page 11
CPU
Node AG Rel Workload (WD) PP Bsy Num
Date Time ID ID Wgt Name ID % Procs
07/08/06 17:57:00 1-04 1 1 ? 0 0.0 1
2 2 ? 0 0.0 4
3 5 ? 0 0.0 0
4 10 ? 0 0.3 2
5 48 All_Tactical 0 4.6 0
TDWM 0 0.0 0
7 11 Continious Load 0 28.6 3
LobLoader 0 0.0 0
Teradata Manger 0 0.1 0
WD-ConsoleH 0 0.0 0
WD-ConsoleR 0 0.0 0
8 5 ADW_Strategic 0 10.5 134

DWD_OLAP 0 0.0 0
Java Stored Procedures 0 0.0 0
Mixedsql 0 11.9 212
Multiuser Simulation 0 4.1 71
PEstress 0 0.0 0
WD-ConsoleM 0 0.0 0
WD-Default 0 0.0 2
9 2 Penalty_box 0 10.9 35
WD-ConsoleL 0 0.0 0
qmiles 0 15.7 0
200 100 ? 0 6.0 92
1-05 1 1 ? 0 0.0 1
2 2 ? 0 0.0 1
3 5 ? 0 0.0 0
4 10 ? 0 0.3 1
TDWM 0 0.0 0

LobLoader 0 0.0 0
WD-ConsoleH 0 0.0 0
WD-ConsoleR 0 0.0 0
DWD_OLAP 0 0.0 0
Mixedsql 0 6.8 53
PeStress 0 0.0 0
WD-ConsoleM 0 0.0 0
WD-Default 0 0.1 0
WD-ConsoleL 0 0.0 0
qmiles 0 12.1 0
200 100 ? 0 6.4 87

ResPsCPU Macros
Note: Question marks used as values in the Workload (WD) Name column in the output
above mean there is no associated workload to the Performance Group ID (PG ID) /
Performance Period ID (PP ID). However, if used as a value in any other column, it indicates
there is no information to report for this time period (see “Question Marks” on page 156 for
details).
ResPsCPUWDJoin Macro Sample Output

07/08/09 Workload Usage Summary- CPU Usage vs Relative Weights Page 6
CPU
AG Rel Workload (WD) PP Bsy Num
Date Time ID Wgt Name ID % Procs
07/08/06 17:57:00 1 1 ? 0 0.0 1
2 2 ? 0 0.0 2
3 5 ? 0 0.0 0
4 10 ? 0 0.3 2
TDWM 0 0.0 0

LobLoader 0 0.0 0
WD-ConsoleH 0 0.0 0
WD-ConsoleR 0 0.0 0
DWD_OLAP 0 0.0 0
Mixedsql 0 9.3 132
PEstress 0 0.0 0
WD-ConsoleM 0 0.0 0
WD-Default 0 0.0 1
WD-ConsoleL 0 0.0 0
qmiles 0 13.9 0
200 100 ? 0 6.2 90
Note: Question marks used as values in the Workload (WD) Name column in the output
above mean there is no associated workload to the Performance Group (PG ID) / Performance
Period (PP ID). However, if used as a value in any other column, it indicates there is no
information to report for this time period (see “Question Marks” on page 156 for details).

ResVdskByNode Macros
Function
The following table describes the ResVdskByNode macros:
Macro... Reports the logical device traffic by...
ResVdskByNode a physical node.
ResVdskOneNode for a specified node.
ResVdskByGroup a node grouping.

The input form of the ResVdskByNode macro is:
EXEC ResVdskByNode
The input form of the ResVdskOneNode macro is:
EXEC ResVdskOneNode
The input form of the ResVdskByGroup macro is:
EXEC ResVdskByGroup
Usage Notes
• Logging must be enabled on ResUsageSvdsk.
Output Examples
In all output reports (with the exception of ResVdiskByNode which has the NodeId column
and ResVdskByGroup which has the NodeType column) the columns are described as follows:
Read Cnt / Sec average number of logical device reads per second.
Write Cnt / Sec average number of logical device writes per second.
Rd KB / I/O average number of KBs per logical device read.

Wrt KB / I/O average number of KBs per logical device write.
Avg I/O Resp average response time for a logical device read or write in seconds.
Out Rqst Time % percent of time there are outstanding requests.
ResVdskByNode Sample Output

06/09/26 VDISK TRAFFIC BY NODE Page 1
Avg Out
Node Read Cnt Write Cnt Rd KB Wrt KBI/O Rqst
Date Time Id / Sec / Sec I/O / I/O Resp Time %
-------- -------- ------ -------- -------- ------- ------- ------- ------
06/09/26 10:09:45 001-01 0.73 5.20 121.27 46.69 0.023 9.7%
10:10:00 001-01 0.40 41.17 127.50 116.34 0.152 85.3%
10:10:15 001-01 0.00 47.40 ? 118.98 0.143 98.8%
10:10:30 001-01 2.43 45.17 111.79 113.54 0.126 98.4%
10:10:45 001-01 2.77 45.90 12.00 109.93 0.118 97.7%
10:11:00 001-01 2.67 43.77 12.00 112.07 0.119 98.0%
10:11:15 001-01 2.83 46.10 12.00 112.32 0.107 97.3%
10:11:30 001-01 4.87 14.13 1374.25 100.01 0.081 54.9%
10:11:45 001-01 5.37 1.77 1785.00 38.15 0.065 41.0%
10:12:00 001-01 5.43 0.30 1785.00 71.56 0.064 36.2%
10:12:15 001-01 3.20 9.70 1759.00 16.76 0.039 45.8%
10:12:30 001-01 0.50 12.60 275.47 18.84 0.038 38.6%
10:12:45 001-01 0.00 2.17 ? 32.94 0.017 3.1%
Note: The NodeId column only appears in the ResVdskByNode output report.
ResVdskOneNode Sample Output

06/09/26 VDISK Traffic for Node 001-01 Page 1
Avg Out
ReadCnt WriteCnt Rd KB Wrt KB I/O Rqst
Date Time / Sec / Sec / I/O / I/O Resp Time %
-------- -------- -------- -------- ------- ------- ------- ------
06/09/26 10:09:45 0.73 5.20 121.27 46.69 0.023 9.7%
10:10:00 0.40 41.17 127.50 116.34 0.152 85.3%
10:10:15 0.00 47.40 ? 118.98 0.143 98.8%
10:10:30 2.43 45.17 111.79 113.54 0.126 98.4%
10:10:45 2.77 45.90 12.00 109.93 0.118 97.7%
10:11:00 2.67 43.77 12.00 112.07 0.119 98.0%
10:11:15 2.83 46.10 12.00 112.32 0.107 97.3%
10:11:30 4.87 14.13 1374.25 100.01 0.081 54.9%
10:11:45 5.37 1.77 1785.00 38.15 0.065 41.0%
10:12:00 5.43 0.30 1785.00 71.56 0.064 36.2%
10:12:15 3.20 9.70 1759.00 16.76 0.039 45.8%
10:12:30 0.50 12.60 275.47 18.84 0.038 38.6%
10:12:45 0.00 2.17 ? 32.94 0.017 3.1%

ResVdskByGroup Sample Output

06/09/26 VDISK TRAFFIC BY GROUP Page 1
Avg Max Out

Node ReadCnt WriteCnt Rd KB Wrt KB I/O Concur Rqst
Date Type Time / Sec / Sec / I/O / I/O Resp Rqsts Time %
-------- ---- -------- -------- -------- ------- ------- ------- ------ ------
06/09/26 4400 10:09:45 0.73 5.20 121.27 46.69 0.023 4.5 9.7%
10:10:00 0.40 41.17 127.50 116.34 0.152 20.5 85.3%
10:10:15 0.00 47.40 ? 118.98 0.143 20.0 98.8%
10:10:30 2.43 45.17 111.79 113.54 0.126 17.5 98.4%
10:10:45 2.77 45.90 12.00 109.93 0.118 13.5 97.7%
10:11:00 2.67 43.77 12.00 112.07 0.119 14.5 98.0%
10:11:15 2.83 46.10 12.00 112.32 0.107 14.0 97.3%
10:11:30 4.87 14.13 1374.25 100.01 0.081 12.5 54.9%
10:11:45 5.37 1.77 1785.00 38.15 0.065 3.0 41.0%
10:12:00 5.43 0.30 1785.00 71.56 0.064 2.0 36.2%
10:12:15 3.20 9.70 1759.00 16.76 0.039 2.0 45.8%
10:12:30 0.50 12.60 275.47 18.84 0.038 3.5 38.6%
10:12:45 0.00 2.17 ? 32.94 0.017 2.0 3.1%
Note: The NodeType column only appears in the ResVdskByGroup output report.


SECTION 4 Appendixes

Section 4: Appendixes

APPENDIX A How to Read Syntax Diagrams
This appendix describes the conventions that apply to reading the syntax diagrams used in
this book.
Syntax Diagram Conventions
Notation Conventions
The following table defines the notation used in this section:
Item Definition / Comments
Letter An uppercase or lowercase alphabetic character ranging from A through Z.
Number A digit ranging from 0 through 9.

Do not use commas when typing a number with more than three digits.
Word Variables and reserved words.
IF a word is shown in . . . THEN it represents . . .
UPPERCASE LETTERS a keyword.

Syntax diagrams show all keywords in
uppercase, unless operating system
restrictions require them to be in lowercase.
If a keyword is shown in uppercase, you can
type it in uppercase or mixed case.
lowercase letters a keyword that you must type in lowercase,

such as a UNIX command.
lowercase italic letters a variable such as a column or table name.

You must substitute a proper value.
lowercase bold letters a variable that is defined immediately

following the diagram that contains the
variable.
UNDERSCORED LETTERS the default value.

This applies both to uppercase and to
lowercase words.

Appendix A: How to Read Syntax Diagrams
Item Definition / Comments
Spaces Use one space between items, such as keywords or variables.
Punctuation Type all punctuation exactly as it appears in the diagram.
Paths
The main path along the syntax diagram begins at the left, and proceeds, left to right, to the
vertical bar, which marks the end of the diagram. Paths that do not have an arrow or a vertical
bar only show portions of the syntax.
The only part of a path that reads from right to left is a loop.
Paths that are too long for one line use continuation links. Continuation links are small circles
with letters indicating the beginning and end of a link:
FE0CA002
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and
continue.
Required Items
Required items appear on the main path:
SHOW
FE0CA003
If you can choose from more than one item, the choices appear vertically, in a stack. The first
item appears on the main path:
SHOW CONTROLS
VERSIONS
FE0CA005

Optional Items
Optional items appear below the main path:
SHOW
CONTROLS FE0CA004
If choosing one of the items is optional, all the choices appear below the main path:
SHOW
CONTROLS
VERSIONS
FE0CA006
You can choose one of the options, or you can disregard all of the options.
Abbreviations
If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always
appears on the main path. The shortest valid abbreviation appears beneath.
SHOW CONTROLS
CONTROL
FE0CA042
In the above syntax, the following formats are valid:

• SHOW CONTROLS
• SHOW CONTROL
Loops
A loop is an entry or a group of entries that you can repeat one or more times. Syntax
diagrams show loops as a return path above the main path, over the item or items that you can
repeat.
, 3
, 4
( cname )
JC01B012

The following rules apply to loops:
IF . . . THEN . . .
there is a maximum number of the number appears in a circle on the return path.
entries allowed
In the example, you may type cname a maximum of 4 times.
there is a minimum number of the number appears in a square on the return path.
entries required In the example, you must type at least three groups of column
names.
a separator character is required the character appears on the return path.

between entries If the diagram does not show a separator character, use one
blank space.
In the example, the separator character is a comma.
a delimiter character is required the beginning and end characters appear outside the return
around entries path.
Generally, a space is not needed between delimiter characters
and entries.
In the example, the delimiter characters are the left and right
parentheses.
Excerpts
Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is
indicated by a break in the path, marked by | terminators on either side of the break. A name
for the excerpted piece appears between the break marks in boldface type.
The named phrase appears immediately after the complete diagram, as illustrated by the
following example.
LOCKING excerpt A
A
HAVING con
excerpt
where_cond
,
cname
,
col_pos
JC01A014

APPENDIX B ResUsageIpma Table
This appendix describes the ResUsageIpma table. This table is for internal use only.
The ResUsageIpma table includes resource usage data for system-wide, node information.
Note: Summary Mode is not applicable to this table.
The following table describes the ResUsageIpma table columns.
Gather Invalid
RELATIONAL PRIMARY KEY COLUMNS


cabinet number and MM denotes the two-
digit chassis number of the node. For
example, a node in chassis 9 of cabinet 3 has a

These columns provide a generalized picture of the vprocs running on this node, shown as “Type n virtual processors”
where n = 1 to 7. Under the current implementation, only Type 1 (AMP), Type 2 (PE), Type 3 (GTW), Type 4 (RSG) vprocs
exist; vproc types 6 through 7 are not currently used.

Appendix B: ResUsageIpma Table
Gather Invalid
twice a year.
NodeType n/a Type of node, representing the per node CHAR(4)

“5400,” “5450,” etc.
Vproc1 n/a Current count of type 1 (AMP) virtual SMALLINT


always “AMP.”
Vproc2 n/a Current count of type 2 (PE) virtual SMALLINT


always “PE.”
Vproc3 n/a Current count of type 3 (GTW) virtual SMALLINT


always “GTW.”
Vproc4 n/a Current count of type 4 (RSG) virtual SMALLINT


always “RSG.”
Vproc5 n/a Note: This field is not currently used. SMALLINT ALL
VprocType5 n/a Note: This field is not currently used. CHAR(4) ALL


MemSize n/a Amount of memory on this node in INTEGER

megabytes. Useful for performing memory
usage calculations.

Gather Invalid
NodeNormFactor n/a A per node normalization factor that is used INTEGER

to normalize the reported CPU values of the
ResUsageSpma table.
This value is scaled by a factor of 100. For
example, if the actual factor is 5.25, then the
value of the NodeNormFactor will be 525.
Note: The normalization factor is related to
the NodeType value reported in the
ResUsageSpma table.
For information on this value, see Chapter 6:
“ResUsageSpma Table.”
Secs n/a Actual number of seconds in the log period INTEGER

NominalSecs, but can be different in three
cases:
the system
“Secs”
CentiSecs n/a Number of centiseconds in the logging INTEGER

percentage error.

the logging period.

Gather Invalid
Active n/a Controls whether or not the rows will be FLOAT

• a zero value, then none of the data
columns in the row have been updated
tables.
for the ResUsageIpma table results in a non-

interval. In the collect buffer, the value is
always 1. In the log buffer or the database
table, the value is the ratio of log interval to
collect interval.
You can determine average values by dividing
a field value ending in “Sum” by
CollectIntervals. For example, to find the
average number of services on the Blockable
Services queue for a collect interval, divide
NetBlockQueueSum by CollectIntervals.
STATISTICS COLUMNS
Scheduled CPU Switching Columns

Identify the number of times CPUs were switched by the scheduler from one type of work to another type of work.
CPUProcSwitches count Number of times the scheduler switched a FLOAT WINDOWS

CPU’s currently active process to a new
process.

Gather Invalid
CPUProcSameSwitches count Number of CPUProcSwitches where a process FLOAT WINDOWS

replaced itself, that is, the new process was the LINUX
same as the old process. This field is a subset
of CPUProcSwitches.
Interrupted CPU Switching Columns

Identify the number of times an interrupt was issued for the node and/or its CPUs.
ProcNetInts count Number of times the node was interrupted for FLOAT ALL
Teradata a net request.
IOPtoCPUInts count Number of times a CPU was interrupted by FLOAT ALL

the IOP.
ProcDiskInts count Number of times the node was interrupted to FLOAT ALL
handle a disk request.
ProcHostInts count Number of times the node was interrupted to FLOAT ALL
handle a host request.
ProcLanInts count Number of times the node was interrupted to FLOAT ALL
handle a LAN request.
ProcGenClockInts count Number of times the node was interrupted to FLOAT MP-RAS
service a general clock event. WINDOWS
On Linux, the number of timer interrupts.
ProcCPUClockInts count Number of times a CPU was interrupted to FLOAT ALL

service a CPU specific clock event.
ProcInterCPUInts count Number of times the a CPU was interrupted FLOAT ALL
to service an inter-CPU request.
MEMORY COLUMNS
Memory Page Deallocation Columns

Represent the number of memory page deallocations specific to generic node activities, subdivided into memory types.
• The amount deallocated can be derived by multiplying the number of deallocations by the fixed page size.
• These columns do not include any memory deallocated specific to a vproc running under the node.
MemTextDestroys count Number of memory deallocations and size- FLOAT WINDOWS

decreasing memory alters for non-system LINUX
overhead text (code).

Gather Invalid
NET COLUMNS
Message Type Columns

Subdivide all messages sent and received into the type of message, where:
• Hash messages (Hash) are data sent to a destination through its primary or fallback hash value
• Processor messages (Proc) are data sent to a destination through a Vproc ID
• Group messages (Group) are broadcasted messages to be received by members of a group
• Local messages (Local) are messages communicated locally within the node
• Channel messages (Chan) are data sent between vprocs through channel IDs for purposes of a private conversation in
order to perform functions such as row redistribution, and so on
• Mailbox messages (Mbox) are data sent between vprocs through mailbox IDs for similar purposes as channel messages.
A duplicated accounting is done with two different perspectives, since Hash + Proc + Group + Local messages = Chan +
MBox messages.
MsgHashReads count Number of hash messages read by this node. FLOAT
MsgHashWrites count Number of hash messages written by this FLOAT

node.
MsgProcReads count Number of processor messages read by this FLOAT

node.
MsgProcWrites count Number of processor messages written by the FLOAT

node.
MsgGroupReads count Number of group messages read by this node. FLOAT
MsgGroupWrites count Number of group messages written by this FLOAT

node.
MsgLocalReads count Number of local messages read by this node. FLOAT
MsgLocalWrites count Number of local messages written by this FLOAT

node.
MsgChanReads count Number of channel messages read by this FLOAT

node.
MsgChanWrites count Number of channel messages written by this FLOAT

node.
MsgMboxReads count Number of mailbox messages read by this FLOAT

node.
MsgMboxWrites count Number of mailbox messages written by this FLOAT

node.
Message Delivery Time Columns

Identify the time it took for hash, processor, group and local messages to reach their destination. Two times are provided:
• Message transmission to mailbox delivery (MDelivery)
• Mailbox delivery to process delivery (PDelivery)

Gather Invalid
MsgHashMDelivery tmon Total amount of time read hash messages took FLOAT
for mailbox delivery.
MsgProcMDelivery tmon Total amount of time read processor messages FLOAT

took for mailbox delivery.
MsgGroupMDelivery tmon Total amount of time read group messages FLOAT

MsgLocalMDelivery tmon Total amount of time read local messages took FLOAT
MsgHashPDelivery tmon Total amount of time read hash messages took FLOAT
for process delivery.
MsgProcPDelivery tmon Total amount of time read processor messages FLOAT

took for process delivery.
MsgGroupPDelivery tmon Total amount of time read group messages FLOAT

MsgLocalPDelivery tmon Total amount of time read local messages took FLOAT
Net Circuit Management Columns

Identify the management of Teradata net circuits (Circ) and raw data traffic on the network (hardware) on all networks.
Note: All of these columns except for NetBackoffs are net-specific. On a single-node system, net-specific statistics are not
meaningful and are always zero.
NetBackoffs count “Software” backoffs, defined as BNS service FLOAT MP-RAS

blocked occurrences without regard for which
net was involved.
NetTxCircPtp count Total number (both normal and high FLOAT

priority) of point-to-point circuits
NetTxCircBrd count Total number (both normal and high FLOAT

priority) of broadcast circuits transmitted on
all Bynets.
NetTxCircHPPtP count Number of high priority point-to-point FLOAT

circuits transmitted on all Bynets.
NetTxCircHPBrd count Number of high priority broadcast circuits FLOAT

NetRxCircPtp count Total number (both normal and high FLOAT

priority) of point-to-point circuits received
on all Bynets.
NetRxCircBrd count Total number (both normal and high FLOAT

priority) of broadcast circuits received on all
Bynets.

Gather Invalid
Bynet Network Transport Data Columns
NetTxKBPtP count Total point-to-point data KBs transmitted FLOAT

over all Bynets.
NetTxKBBrd count Total broadcast data KBs transmitted over all FLOAT
Bynets
NetRxKBPtP count Total point-to-point data KBs received over all FLOAT
Bynets.
NetRxKBBrd count Total broadcast data KBs received over all FLOAT
Bynets.
Net Miscellaneous Contention Management Columns

Identify some additional contention management not addressed in the other contention management areas.
Note: NetBrdWindowOverrun is net-specific, that is, it relates to each specific Bynet. On a single-node system, net-specific
statistics are not meaningful and are always zero.
NetMsgFCSleep count Number of times a transmitter process was FLOAT

put to sleep because it was flow controlled.
NetMsgFCBlock count Number of times the net software was blocked FLOAT
because the receiver was flow controlled.
NetMsgResourceBlock count Number of times the net software was blocked FLOAT
because the receiver could not get the
necessary resources.
NetMsgChannelBlock count Number of times the net software was blocked FLOAT
because the channel was not in RxReady state
on the receiver.
NetMsgGroupBlock count Number of times the net software was blocked FLOAT
because the receiver could not implicitly enter
the group.
NetMsgRxBlock count Number of times the net software could not FLOAT
accept a message and caused a transmitter to
block.
NetMrgBlock count Number of times a merge message was FLOAT

blocked until delivery of outstanding
outgoing messages.
NetBrdWindowOverrun count Broadcast window overruns on all Bynets. FLOAT
NetActiveMrg track The number of concurrent active merges on FLOAT

all Bynets.
NetMrgBufWaits count Number of times an IOP task encountered an FLOAT

empty row-block buffer on all Bynets.

Gather Invalid
NetBackoffExhausted count Number of transmit circuits that were backed- FLOAT ALL
off too many times and had to be converted to
blocking circuits.
NetBrdWindowError count Number of broadcast window errors. FLOAT ALL
NetConfigurations count Number of network configurations and re- FLOAT ALL

configurations.
NetProtocolFilter count Number of protocol filters executed. FLOAT ALL
NetTxSoftBackoffs count Number of soft backoffs transmitted on all FLOAT ALL

Bynets.
NetRxSoftBackoffs count Number of soft backoffs received on all FLOAT ALL

Bynets.
Net Queues Columns

Identify lengths of the various internal queues used by the network controllers.
• NetSamples can be used to normalize all aggsam statistics to an average queue-length basis.
• Example: Dividing (NetPtPQueue/NetSamples) yields the average point-to-point queue length over all samples on all
networks taken during this log interval.
• All of the aggsam columns in the following table are net-specific, that is, they relate to each specific Bynet. On a single-
node system, net-specific statistics are not meaningful and are always zero.
NetPtPQueue aggsam Aggregated sample point-to-point normal FLOAT

priority queue length on all Bynets.
NetPtPQueueMax count For log buffer or ResUsage database row, this FLOAT
is the maximum value of NetPtPQueue over
all collect intervals in this log interval. For
collect buffer, this value is equal to
NetPtPQueue.
NetBrdQueue aggsam Aggregated sample broadcast normal priority FLOAT

queue length on all Bynets.
NetBrdQueueMax count For log buffer or ResUsage database row, this FLOAT
is the maximum value of NetBrdQueue over
all collect intervals in this log interval. For
collect buffer, this value is equal to
NetBrdQueue.
NetHPPtPQueue aggsam Aggregated sample point-to point high FLOAT

priority queue length on all Bynets.
NetHPPtPQueueMax count For log buffer or ResUsage database row, this FLOAT
is the maximum value of NetHPPtPQueue
over all collect intervals in this log interval.
For collect buffer, this value is equal to
NetHPPtpQueue.
NetHPBrdQueue aggsam Aggregated sample broadcast high priority FLOAT

queue length on all networks.

Gather Invalid
NetHPBrdQueueMax count For log buffer or ResUsage database row, this FLOAT
is the maximum value of NetHPBrdQueue
over all collect intervals in this log interval.
For collect buffer, this value is equal to
NetHPBrdQueue.
NetBlockQueueSum count Total number of services on the FLOAT

BlockableService queue, regardless of which
net during each log interval. Services can be
blocked for a variety of reasons including
receiver flow control, receiver resource usage,
daemon services and MP-RAS delays.
NetBlockQueueTotal track Total number of services on the FLOAT

BlockableServices queue.
NetBlockQueueMax count Maximum number of services on the FLOAT

BlockableServices queue in this log interval.
NetPendMrgQueue track The current count of pending merges, FLOAT

regardless of which net. A merge may be
queued for reasons such as:
• the local IOP memory is saturated
• system memory is trashing.
GENERAL CONCURRENCY CONTORL COLUMNS
Operating System Lock Management Columns

Identify database locking activities for internal multiprocessing operating system concurrency control.
LockEnters count Number of times entry into a lockable FLOAT ALL

resource was requested.
LockBlocks count Number of times entry into a lockable FLOAT ALL

resource was blocked, requiring the requestor
to spin until the resource is unblocked.
(requests - blocks = immediate grants.)
Secondary Cache Misses Columns

Identify the percentage of time accesses were not in the cache.
CacheAccess count Total number of accesses. FLOAT ALL
CacheMiss count Number of times accesses were not in the FLOAT ALL
cache.
CacheWrites count Total number of writes to the cache. FLOAT ALL

Spare Columns
Gather Invalid
CacheWriteThrus count Number of cache “write thru” accesses (write FLOAT ALL
bypasses the cache and goes straight to main
memory).
CacheWriteBacks count Number of cache “write back” accesses from FLOAT ALL
cache to main memory, that is, delayed writes
of data previously written to the cache by the
CPU.
Spare Columns
The ResUsageIpma table has nine spare columns: three count, three track, and three
tmonitored columns as shown in the following table.

Spare Columns

APPENDIX C ResUsageIvpr Table
This appendix describes the ResUsageIvpr table. This table is for internal use only.
The ResUsageIvpr table includes resource usage data for system-wide, virtual processor
information.
The following table describes the ResUsageIvpr table columns.
Gather Invalid

These columns taken together form the primary index.

resides. The Node ID is formatted as CCC-MM,
where CCC denotes the three-digit cabinet
number and MM denotes the two-digit chassis
number of the node. For example, a node in
chassis 9 of cabinet 3 has a node ID of ‘003-09’.
twice a year.
family type. For example, “5380,” “5400,”
“5450,” etc.

Appendix C: ResUsageIvpr Table
Gather Invalid

Mode) or the Vproc type (Summary Mode;
0 = NODE, 1 = AMP, 2 = PE, 3=GTW, 4=RSG).
The VprId can be any of the following
depending on the type:
• PE vprocs: numbered downward from
16383.
• NODE vprocs: numbered upward from
16384.
• RSG vprocs: numbered downward from
9215.
contiguous. Each existing vproc type range
should not overlap into the range of another
existing vproc type on the system.
VprType n/a Type of vproc. In non-Summary Mode, the CHAR(4)

values can be “NODE,” “AMP,” “PE,” “GTW,” or
“RSG”. In Summary Mode, the values can be
“NODS,” “AMPS,” “PES,” “GTWS,” or “RSGS.”
Note: There is always exactly one Node vproc
per Node, so the row with VprType = ‘NODS’
actually “summarizes” a single vproc.

the system
“Secs”

This field is useful when performing data

the logging period.

Gather Invalid

Possible values are ‘N’ if the row is a non-
summary row, and ‘S if the row is a summary
row.
Active n/a Controls whether or not the rows will be logged FLOAT
to the ResUsage tables if Active Row Filter Mode
is enabled.
modified data fields.
• a zero value, then none of the data fields in
the row have been updated during the
logging period.
tables.
the ResUsageIvpr table results in a non-zero
value for all rows under all conditions.

interval. In the collect buffer, the value is always
1. In the log buffer or the database table, the
interval.
STATISTICS COLUMNS
Work Type Summary Columns

Identify the distribution of work types among allocated processes. The total of the following “average” columns
approximately equals total Process Allocations in ResUsageSpma table. Each entry below represents 16 columns, where [i]
expands to the values 0-15, for example, ProcWorkType2Sum.
ProcWorkType[i]Sum count Total number of processes of work type i during FLOAT

each log interval.
processes, divide this value by the
period, the resulting number is the average
value per collection period.

Gather Invalid
ProcWorkType[i]Max track Maximum number of processes of work type i FLOAT

NET COLUMNS
Message Type Columns

Subdivide all messages sent and received into the type of message, where:
• hash messages (Hash) are data sent to a destination through its primary or fallback hash value
• processor messages (Proc) are data sent to a destination through a Vproc ID
• group messages (Group) are broadcasted messages to be received by members of a group
• local messages (Local) are messages communicated locally within the node
• channel messages (Chan) are data sent between vprocs through channel IDs for purposes of a private conversation in
order to perform functions such as row redistribution, etc.
• mailbox messages (Mbox) are data sent between vprocs through mailbox IDs for similar purposes as channel messages.
A duplicated accounting is done with two different perspectives, since Hash + Proc + Group + Local messages = Chan +
MBox messages.
MsgHashReads count Number of hash messages read by this vproc. FLOAT
MsgHashWrites count Number of hash messages written by this vproc. FLOAT
MsgProcReads count Number of processor messages read by this FLOAT

vproc.
MsgProcWrites count Number of processor messages written by this FLOAT

Vproc.
MsgGroupReads count Number of group messages read by this vproc. FLOAT
MsgGroupWrites count Number of group messages written by this FLOAT

vproc.
MsgLocalReads count Number of local messages read by this vproc. FLOAT
MsgLocalWrites count Number of local messages written by this vproc. FLOAT
MsgChanReads count Number of channel messages read by this vproc. FLOAT
MsgChanWrites count Number of channel messages written by this FLOAT

vproc.
MsgMboxReads count Number of mailbox messages read by this FLOAT

vproc.
MsgMboxWrites count Number of mailbox messages written by this FLOAT

vproc.
Message Delivery Times Columns

Identify the time it took for hash, processor, group and local messages to reach their destination. Two times are provided:
message transmission to mailbox delivery (MDelivery) and mailbox delivery to process delivery (PDelivery).

Gather Invalid
MsgHashMDelivery tmon Total amount of time read hash messages took

MsgProcMDelivery tmon Total amount of time read processor messages

MsgGroupMDelivery tmon Total amount of time read group messages took

MsgLocalMDelivery tmon Total amount of time read local messages took

MsgHashPDelivery tmon Total amount of time read hash messages took

MsgProcPDelivery tmon Total amount of time read processor messages

MsgGroupPDelivery tmon Total amount of time read group messages took

MsgLocalPDelivery tmon Total amount of time read local messages took

Monitor Management Columns

Identify monitor activities for Teradata Database concurrency control.
MonAllocates count Number of monitors allocated. FLOAT
MonEnters count Number of times entry into a monitor was FLOAT

requested.
MonBlocks count Number of times entry into a monitor was FLOAT

blocked. (requests - blocks = immediate grants.)
MonDeadlocks count Number of times entry into a monitor was FLOAT ALL
deadlocked.
MonYields count Number of times a monitor yield was requested. FLOAT
FILE SYSTEM COLUMNS
Cylinder Overhead Columns

Further identify file system cylinder split/migrate (CylMigr) overhead performed when cylinders can not accommodate new
data. (Event counts are found in ResUsageSvpr.) Only logical I/Os and the amount moved (KBs) for data blocks are
identified. Each cylinder migration event implies 1 logical read and 3 logical writes of the cylinder index. Only permanent
tables (including append and transient journal tables) are migrated.
FileDbCylMigrIO count Number of data block logical I/Os due to FLOAT

cylinder migration.
FileDbCylMigrKB count KBs moved by FileDbCylMigrIOs. FLOAT

Gather Invalid
Cylinder Mini-Cylpack Overhead Columns

Identify file system overhead associated with mini-cylpacks (MCylPack) that get performed in order to make available a free
cylinder when one is needed but not available.
• Event counts are found in ResUsageSvpr.
• Only logical I/Os and the amount moved (KBs) are identified, except the amount moved for cylinder indexes because
they can be calculated by multiplying the current cylinder index fixed size and the I/Os.
• Mini-cylpacks are done on cylinders containing permanent tables (including append and transient journal tables) only.
FilePCiMCylPackIO count Number of permanent cylinder index logical FLOAT

I/Os due to mini-cylpacking.
FilePDbMCylPackIO count Number of permanent data block logical I/Os FLOAT

due to mini-cylpacking.
FilePDbMCylPackKB count KBs moved by FilePDbCylPackIOs. FLOAT
Cylinder Defragmentation Overhead Columns

Identify background file system overhead associated with fragmented free space in order to achieve one large free space
within that cylinder (CylDefrag).
• Event counts are found in ResUsageSvpr.
• Each cylinder defragment event implies 1 logical cylinder index read and 1 logical cylinder index write.
• Only logical I/Os and the amount moved (KBs) are identified. Cylinder defragments are done on cylinders containing
permanent tables (including append and transient journal tables) only.
FileDbCylDefragIO count Number of permanent data block logical I/Os FLOAT

due to cylinder defragmentation.
FileDbCylDefragKB count KBs moved by the FileDbCylDefragIO. FLOAT
Data Block Update Operations Columns

Identify the file system operations required when a data block is being updated (BlkUpd). When a block is updated, it can be
‘in place’ and requires no new data blocks, or it could spill over the current data block and require 1, 2, 3 or more new data
blocks in addition to the current data block. Only logical I/Os and the amount moved (KBs) are identified, except for the
amount moved for cylinder indexes because they can be calculated by multiplying the current fixed cylinder index size by
the I/Os. Data block updates should only be performed on permanent tables (including append and transient journal
tables), so no attempt is made to separate permanent and spool data segments.
FileCiUpd0IO count Number of cylinder index logical I/Os FLOAT

performed for a block update operation
requiring no new data blocks.
FileDbUpd0IO count Number of data block logical I/Os performed FLOAT

for a block update operation requiring no new
data blocks.
FileDbUpd0KB count KBs moved by FileDbUpd0IO. FLOAT

requiring 1 new data blocks.

Gather Invalid

for a block update operation requiring 1 new
data blocks.


data blocks.


data blocks.
FileCiUpdNIO count Number of cylinder index logical I/Os FLOAT

requiring over 3 new data blocks.
FileDbUpdNIO count Number of data block logical I/Os performed FLOAT

for a block update operation requiring over 3
new data blocks.
FileDbUpdNKB count KBs moved by FileDbUpdNIO. FLOAT
Data Block Creations Columns

Identify the file system operations required when a data block is being created (BlkCreate). It does not include data blocks
created due to any of the new data blocks created when a data block was updated (see above).
FilePDbCreates count Number of permanent table (including append FLOAT

and transient journal tables) data blocks
created.
FilePDbCreateKB count KBs created by FilePDbCreates. FLOAT
FileSDbCreates count Number of spool data blocks created. FLOAT
FileSDbCreateKB count KBs created by FileSDbCreates. FLOAT
Transient Journal Overhead Columns

Identify file system overhead associated with maintaining a transient journal (TJ).
FileTJBufUpdates count Number of transient journal buffer updates. FLOAT

Gather Invalid
File System Single-Row Requests Columns

Identify the significant single-row requests made by application software on the file system. Rows are distinguished as
permanent data (P), spool (S) or user append table / permanent journal table (APt).
FilePRowReadInit count Number of requests for an initial permanent FLOAT

row read.
FilePRowReadCont count Number of requests for a continued permanent FLOAT

row read.
FilePRowReplace count Number of requests for a permanent row FLOAT

replace.
FilePRowInsert count Number of requests for a permanent row insert. FLOAT
FilePRowDelete count Number of requests for a permanent row delete. FLOAT
FilePRowAppend count Number of requests for a row append. FLOAT
FileSRowReadInit count Number of requests for an initial spool row FLOAT

read.
FileSRowReadCont count Number of requests for a continued spool row FLOAT

read.
FileSRowReplace count Number of requests for a spool row replace/ FLOAT

update.
FileSRowInsert count Number of requests for a spool row insert. FLOAT
FileSRowDelete count Number of requests for a spool row delete. FLOAT
FileSRowAppend count Number of requests for a row append. FLOAT
FileAPtRowReadInit count Number of requests for an initial append row FLOAT

read.
FileAPtRowReadCont count Number of requests for an continued append FLOAT

row read.
FileAPtRowReplace count Number of requests for an append row replace/ FLOAT

update.
FileAPtRowInsert count Number of requests for an append row insert. FLOAT
FileAPtRowDelete count Number of requests for an append row delete. FLOAT
FileAPtRowAppend count Number of requests for an append row append. FLOAT
File System Multi-Row Requests Columns

Identify the significant multi-row requests made by application software on the file system. Rows are distinguished as
permanent data (P), spool (S) or user append table / permanent journal table (APt).
FilePBlkRead count Number of requests for a permanent data block FLOAT

read.

Gather Invalid
FilePBlkReplace count Number of requests for a permanent data block FLOAT

replace.
FilePRowNDel count Number of requests for a permanent data FLOAT ALL

multi-row delete.
FilePRownins count Number of requests for a permanent data FLOAT

multi-row insert.
FilePRowNUpd count Number of requests for a permanent data FLOAT ALL

multi-row update.
FilePSortable count Number of requests for permanent table sort. FLOAT
FilePTabdelete count Number of requests for a permanent table FLOAT

delete.
FilePTabdelra count Number of requests for a multi-row delete. FLOAT
FilePTabmrows count Number of requests for a permanent table FLOAT

modification.
FilePTabrblocks count Number of requests for a permanent table FLOAT

multi-block read.
FileSBlkRead count Number of requests for a spool data block read. FLOAT
FileSBlkReplace count Number of requests for a spool data block FLOAT

replace.
FileSRowNDel count Number of requests for a spool data multi-row FLOAT ALL
delete.
FileSRownins count Number of requests for a spool data multi-row FLOAT

insert.
FileSRowNUpd count Number of requests for a spool data multi-row FLOAT ALL
update.
FileSSortable count Number of requests for spool table sort. FLOAT
FileSTabdelete count Number of requests for a spool table delete. FLOAT
FileSTabdelra count Number of requests for a spool multi-row FLOAT

delete.
FileSTabmrows count Number of requests for a spool table FLOAT

modification.
FileSTabrblocks count Number of requests for a spool table multi- FLOAT

block read.
FileAPtBlkRead count Number of requests for an append data block FLOAT

read.
FileAPtBlkReplace count Number of requests for an append data block FLOAT

replace.

Gather Invalid
FileAPtRownins count Number of requests for an append data multi- FLOAT

row insert.
FileAPtRowNDel count Number of requests for an append data multi- FLOAT ALL
row delete.
FileAPtRowNUpd count Number of requests for an append data multi- FLOAT ALL
row update.
FileAPtSortable count Number of requests for an append table sort. FLOAT
FileAPtTabdelete count Number of requests for an append table delete. FLOAT
FileAPtTabdelra count Number of requests for an append multi-row FLOAT

delete.
FileAPtTabmrows count Number of requests for an append table FLOAT

modification.
FileAPtTabrblocks count Number of requests for an append table multi- FLOAT

block read.
File System Transient Journal Requests Column

Identifies the significant transient journal requests made by application software on the file system.
FileTJCalls count Number of transient journal calls. FLOAT
TRANSIENT JOURNAL MANAGEMENT COLUMNS
Transient Journal Purge Overhead Columns

Identify the background overhead associated with the occasional transient journal purge operation.
TJPurges count Number of times the transient journal purge

operation was performed.
TJDbPurgeReads count Number of transient journal data blocks read MP-RAS

while purging.
TJDbPurgeDeletes count Number of transient journal data blocks deleted MP-RAS

while purging. (Only data blocks that just
include completed transaction TJ entries are
deleted.)
WRITE AHEAD LOGGING COLUMNS

Identify the log-based file system recovery scheme in which modifications to permanent data are written to a log file, the
WAL log.
FileWAppends count Number of times a record was appended to the INTEGER

WAL log. A single append call can append
multiple rows. Subtracting FileTJAppends from
this counter results in the number of times non-
transient journal rows were appended to the
WAL log.

Summary Mode
Gather Invalid
FileTJAppends count Number of times transient journal records were INTEGER

appended to the WAL log. A single append call
can append multiple transient journal rows. A
transient journal append by itself does not
imply a write of a WAL block, nor a WAL
Cylinder Index (WCI) modification.
FileTJFlush count Number of times a request to force transient INTEGER

journal records within the WAL log to be
written to disk has been issued. An increment of
this counter may or may not result in an I/O
depending on whether the request was to flush
records that were already on disk.
FileWDBCreates count Number of WAL data blocks created. INTEGER
FileWFlush count Number of times a request to force any record INTEGER

in the WAL log to be written to disk has been
issued. An increment of this counter may or
may not result in an I/O depending on whether
the request was to flush records that were
already on disk. Subtracting FileTJFlush from
this counter results in the number of times a
non-transient journal WAL flush was issued.
FileWRowDelete count Number of times rows were deleted from the INTEGER
WAL log.
FileWTabDelRa count Number of requests for a WAL multi-row INTEGER

delete.
Summary Mode
When Summary Mode is active for the ResUsageIvpr table, one row per physical table is
written to the database for each type of vproc on each node in the system, summarizing the
that row:
‘S’ in Summary Mode
‘N’ normally

Spare Columns
Spare Columns
The ResUsageIvpr table has 30 spare columns: 10 count, 10 track, and 10 tmonitored columns
Gather
Column Name Method Description
SpareCount[i] count Spare counted statistic
SpareTrack[i] track Spare tracked statistic
SpareTmon[i] tmon Spare tmonitored statistic
where [i] is expanded to be the values 00-09. For example, column names could be
SpareCount00, SpareTrack05, or SpareTmon09.

APPENDIX D Partition Assignments
With regards to Teradata Database, there is more than one definition of partition. The
partitions here refer to the following PDE/vproc definition:
• A partition is a collection of tasks and associated resources grouped within a virtual
processor according to the function of the tasks. There are multiple partitions within a
single virtual processor. Partitions are the primary mechanism used by Teradata Database
for managing parallel programs.
• Partitions are the subdivision of vproc software processes into 32 semi-isolated domains.
For example, in an AMP vproc, Partition 11 is the AWT Partition. In all other vproc types,
Partition 11 is unused.
Another partition description is only meaningful in a dialog between client programs and
Teradata Database. It has nothing to do with PDE Vproc partitions, but is a way of enforcing
rules about what a client session is allowed to do and of keeping client sessions isolated from
each other. This concept of partitions is centered in the CLIv2 interface, specifically the
CONNECT parcel.
Partition Assignments
Partition reservation is as follows:
• Partitions 0 through 6 are reserved by PDE
• Partitions 7 through 47 are for use by Teradata Database
Partition usage is also discussed under “CPU Utilization Columns” on page 125 in the “Table:
ResUsageSvpr” chapter.
The following reflects theTeradata Database usage of the TPA partitions.
Table Conventions
The following table describes the table symbols used in the partition assignments table below.
The symbol used in the Partition

Assignment Listing… Indicates…
—— partition is unused.
? activity has been observed but not identified.

Appendix D: Partition Assignments
Partition Assignment Listing

The following table lists the Node, AMP, and PE (Parsing Engine), GTW, and RSG usage of
PDE vproc partitions by PDE and Teradata Database.
Partition: Usage in Vprocs of Type:
No. Name Node AMP PE GTW RSG
0 Kernel PDE daemons ——
1 System Debugger System Debugger tasks
2 Console Console ——
Supervisor
3-6 Interactive 1 —— Console ——

through 4 interactive
partition
programs
7 Service Console utilities
8 CnsProc —— Host Utility ——

console
procedures
9 Filesys —— File System ——

processes
10 Gateway tgtw processes ——
11 AWT —— AMP Worker ——

Tasks
12 Session —— Session Control tasks
13 Dispatch —— Dispatcher tasks
14 Parser —— Unused
15 Startup — Startup tasks
16 [unused] ——
17 RSS Startup File system rss ——

startup
18 DDF Server DDF services ——
19 [unused] ——
20 - 22 [unknown]
23 - 28 [unused] Teradata Manager Interactive Partitions
29 [unknown]

Partition: Usage in Vprocs of Type:
No. Name Node AMP PE GTW RSG
30 [unused] ——
31 [unused] ——
32 [unused] ——
33 - 47 [unused] ——


APPENDIX E System Activity Reporter
This appendix discusses the System Activity Reporter (Sar), a generic MP-RAS performance
monitoring tool that provides reports that are applicable to the Teradata Database. Sar is a
node-local tool that gathers data about the operation of the hardware and software on a
system running MP-RAS.
Topics discussed include:
• Using Sar
• Comparing Sar and Resource Usage Data
Using Sar
You can run the Sar utility from an MP-RAS node (using a command line interface) to view
various resources. With Sar reports, you can monitor the system activities, as listed in the
following table, and troubleshoot specific problems.
Note: There is help available on the system detailing each Sar report option (see the manual
pages on MP-RAS and pdehelp on Windows).
Applicable to
Report Displays Teradata Database
CPUs CPU utilization for all CPUs. Contains the same level of detail as displayed by Yes
xperfstate (that is, idle, user, system, and I/O wait).
Note: On MP-RAS, this is referred as processor utilization.
Buffers All buffer activity, including buffer access, transfers between buffers, and cache Yes
hit ratios.
Block device Disk and tape drive activity. Disk activity information is the same as displayed Yes
by xperfstate.
TTY device TTY device activity, including character rates, transmit and receive rates, and No
modem interrupt rate for a serial connection.
System calls All system call information, including specific system calls (for example, reads, No
writes, forks, and execs).
Swapping and Number of transfers and units transferred for swapping in and out. And a report Yes
switching of process switches.
Queue length Average run queue length while occupied and percent of the queue that is Yes
occupied, for processes in memory that can be run.

Appendix E: System Activity Reporter
Comparing Sar and Resource Usage Data
Applicable to
Report Displays Teradata Database
File access system Use of file access system routines, for example, file system path services. No
routines
Process and Number of processes running and open files. These values are relatively constant No
i-node with Teradata Database.
Message and Teradata Database does not use this type of message and semaphores. (Task No
semaphore communications).
Paging All paging activities, including page in and page out requests and allocated Yes, but may be
pages, pages available for use, page faults, and pages per second scanned. misleading
Kernel memory The allocation of the memory pool reserving and allocating space for small Yes
requests, including the number of allocated bytes to satisfy the request.

In general, Sar provides the following:
• Canned report formats and allows you to save the data into a binary flat file.
• Reports that can be generated from real-time data or by referencing a file that was
previously stored by Sar.
Whereas, resource usage provides the following:
• More detailed data specific to Teradata Database, such as BYNET, client, and file system
monitoring.
• Real-time analysis using Performance Monitor.
• Historical analysis using SQL (resource usage macros) to retrieve the data from the
resource usage tables on the Teradata Database.
If you simply want to view CPU utilization, for example, then use Sar to capture a snapshot of
the data. But if you want to do calculations with the Sar data, or if you want to create a longer
historical picture, Sar is less useful than resource usage and Performance Monitor. The
resource usage data is kept in a relational table, and you have all the power of the relational
database to analyze the data.
In general, we recommend using resource usage through Performance Monitor on a regular
basis. Resource usage has far more capability to organize the resulting data in a useful way.
The following table contains categories in which data is collected with Sar and resource usage.

Information
Category Sar Resource Usage
CPUs General CPU usage, i.e., SPMA/SCPU -- CPU and node level (same as xperfstate).
system, user, idle, I/O wait
SVPR -- Breakdown of CPU used for console utilities, session
(same as xperfstate)
control, dispatcher, parser, AWT, and startup.
Buffers Access, transfers, hits IPMA -- Secondary cache access and misses.
Block device LUN information (same as SLDV -- I/O traffic, response time, and outstanding requests for
xperfstate) SCSI devices related to vprocs.
TTY device Available Not available (not applicable for Teradata Database systems).
System calls Available Not available (not applicable for Teradata Database systems).
Swapping and General swapping and ICPU/IPMA -- Interrupted and scheduled switching
switching switching activity
SVPR -- Swapping.
Queue length Run queue length and percent SPMA -- Blocked and pending processes.
of queue used
File access system Available Not available (not applicable for Teradata Database systems).
routines
Process and Available Not available (not applicable for Teradata Database systems.
i-node
Message and Available Not available (not applicable for Teradata Database systems).
semaphore
Paging All paging activity SVPR -- Context pages, paged in/out
Memory Kernel memory SPMA -- Memory allocation in general, specific to vprocs, and
backup node activity. Memory problems, including failures, aging,
dropping, and paging.
SVPR -- Memory allocation and memory resident with respect to
vprocs.
BYNET Not available Various BYNET information is in SPMA, IPMA, SVPR, and IVPR.
Client Not available SHST -- Host & gateway traffic and management.
Teradata Database Not available SPMA/SVPR/IVPR -- General file system information.

File System
Cylinder Not available SVPR -- Cylinder events; migrates, allocations, mini-cylpacks, and
management defrags.
IVPR -- Overhead for the above events
Database locks Not available SPMA/IPMA/SVPR -- Database lock requests, blocks, and
deadlocks.
Note: All data collected in IVPR, SAWT, SHST, SLDV, SVPR, SPS, and SVDSK tables is associated with a vproc, providing
detailed information not available with Sar.


Glossary
AG Allocation Group
AMP Access Module Processor
API Application Programming Interface
AWS Administration Workstation
AWT AMP Worker Task
BYNET Banyan Network (high-speed connection)
DBW Database Window
DDL Data Definition Language
FSG File Segment
I/O Input/Output
LAN Local Area Network

MPP Massively Parallel Processing
NUPI Nonunique Primary Index
PDE Parallel Database Extensions

PE Parsing Engine
PG Performance Group
PM/API Performance Monitor Application Programming Interface

PMA Processor Module Assembly
PMON Performance Monitor
PP Performance Period
RDBMS Relational Database Management System
ResUsage Resource Usage
RSG Relay Services Group

Sar System Activity Reporter
SCSI Small Computer Systems Interface
SMP Symmetric Multi-Processing

Glossary
TCHN Teradata Channel
Teradata ASM Teradata Active System Management

TGTW Teradata Gateway
VNET Virtual Network. Virtual BYNET for a single-node.
vproc Virtual Processor
WCI WAL Cylinder Index

Index
Symbols Total User Serv% 162

CPU use by AMPs macros
?, meaning in macro outputs 156
normalized viewing 164
output column descriptions 162
A ResAmpCpuByGroup 161
Active Row Filter Mode ResCPUByAMP 161
description 34 ResCPUByAMPOneNode 161
enabling a table 36 CPU use by each node macros
Active row filtering. See Active Row Filter Mode function 168
Aggregated samples data. See aggsam input format examples 168
aggsam data, description 19 output examples 169
AMP information ResCPUByGroup 168
macros 157, 161 ResCPUByNode 168
table 123 ResCPUOneNode 168
view 148 usage notes 168
Average values CPU use by nodes macro output columns
determining for collection period 47 I/O Wait % 169
Total Busy % 169
B Total User Exec % 169
Total User Serv % 169
ByGroup CPU use by PEs macro output columns
macros, description of 38 Disp User Exec% 166
Disp User Serv% 166
C Misc User Exec% 166
CD-ROM images 6 Misc User Serv% 166
Clearing old resource usage data 43 Pars User Exec% 166
Co-existing node macros. See ByGroup macros Pars User Serv% 166
Collecting resource usage data 19 Ses User Exec% 166
CollectIntervals Ses User Serv% 166
using to determine average 47 Total Busy% 166
Collection interval. See Collection rates Total User Exec% 166
Collection rates Total User Serv% 166
definition 26 CPU use by PEs macros
minimum 28 normalized viewing 168
recommended values 28 output column descriptions 166
Column categories, ResUsage tables 48 output examples 166
Column descriptions, ResUsage tables 46 ResCPUByPE 165
Count data, description 19, 47 ResCPUByPEOneNode 165
countshft, description 19 ResPeCpuByGroup 165
count-shift data. See countshft
CPU use by AMP macro output columns D
Awt User Exec% 162
Database commands
Awt User Serv% 162
SET ACTIVELOGTABLE 36
Misc User Exec% 162
SET LOGTABLE 35, 36
Misc User Serv% 162
SET RESOURCE 36
Total Busy% 162
SET RESOURCE COLLECTION 35
Total User Exec% 162

Index
SET SUMLOGTABLE 36 ResPsWDJoin macro report 194

Database Window. See DBW ResVdskByGroup macro report 201
DBW ResVdskByNode macro report 200
enabling tables 35 ResVdskOneNode macro report 200
setting collection rates 35 EXECUTE MACRO, syntax elements 39
setting logging rates 36
Deleting old resource usage data 43 F
DISABLE LOGONS
effects on logging 43 format. See Macro input
E G
Gather methods
error message
count 47
returned for MONITOR PHYSICAL RESOURCE request
tmon 47
and option 22
track 47
returned for MONITOR VIRTUAL RESOURCE request
general information about Teradata 6
and option 22
Gmt Time 46
Example
executing ResAmpCpuByGroup macro 42
executing ResCPUByAmp macro 41 H
executing ResCPUByAmpOneNode macro 42 Host communication traffic macro output columns
ResAmpCpuByGroup macro report 163 Avg ReqQ Len 172
ResAWT macro report 160 Blk Read Fail % 172
ResAWTByAMP macro report 160 Blk Write Fail % 172
ResAWTByNode macro report 161 Blks Read/Sec 172
ResCPUByAMP macro report 163 Blks Write/Sec 172
ResCPUByAMPOneNode macro report 163 Host Type 172
ResCPUByGroup macro report 170 KBs Read/Sec 172
ResCPUByNode macro report 170 KBs Write/Sec 172
ResCPUByPE macro report 167 KBs/Blk Read 172
ResCPUByPEOneNode macro report 167 KBs/Blk Write 172
ResCPUOneNode macro report 170 Max ReqQ Len 172
ResHostByGroup macro report 174 Msgs/Blk Read 172
ResHostByLink macro report 173 Msgs/Blk Write 172
ResHostOneNode macro report 173 Host communications traffic information
ResLdvByGroup macro report 176 macros function 171
ResLdvByNode macro report 175 macros input format examples 171
ResLdvOneNode macro report 176 macros usage notes 171
ResMemByGroup macro report 180 view 151
ResMemMgmtByNode macro report 179 Host communications traffic macros
ResMemMgmtOneNode macro report 179 output column descriptions 172
ResNetByGroup macro report 183 ResHostByGroup 171
ResNetByNode macro report 182 ResHostByLink 171
ResNetOneNode macro report 182 ResHostOneNode 171
ResNode macro report 187
ResNodeByGroup macro report 188
ResNodeByNode macro report 188
I
ResOneNode macro report 187 Information Products Publishing Library 6
ResPeCpuByGroup macro report 167 Invalid platform columns, description 47
ResPsByGroup macro report 192
ResPsByNode macro report 192 L
ResPsByNodeWDJoin macro report 193 Logging
ResPsCPUByNodeWDJoin macro report 197 costs 29
ResPsCPUWDJoin macro report 198 rates 26

Index
resource usage data 20 KB/VPR Aloc 178

which tables to enable 24 P+S Drps/Sec 179
Logging rates P+S I/O % 179
definition 26 P+S Rds/Sec 179
minimum 28 P+S Wrts/Sec 179
recommended values 28 Pg Drps/Sec 178
using SET RESOURCE 36 Pg Rds/Sec 178
Logical device information Pg Wrts/Sec 178
macros 174, 199 Swp Drps/Sec 178
table 95 Swp Rds/Sec 178
view 152 Text Alocs/Sec 178
VPR Alocs/Sec 178
M MONITOR PHSYICAL RESOURCE request, PM/API
equivalent Performance Monitor options 22
Macro input 37 error message 22
Macro output format MONITOR PHYSICAL SUMMARY request, PM/API 22
general format 155 MONITOR VIRTUAL RESOURCE request, PM/API
ID 156 equivalent Performance Monitor options 22
statistics 156 error message 22
Macro statistics, datatypes 156 MONITOR VIRTUAL SUMMARY request, PM/API 22
Macro syntax element MULTISET table
for all nodes 40 why resusage tables are created as 46
for co-existing nodes 40
for multinodes 40
FromDate 40 N
FromNode 41 Node information
FromTime 40 macros 157, 168
Node 41 view 145
ToDate 40 Node Logging Rate 34
ToNode 41 Node network traffic macro output columns
ToTime 40 % Brd 182
Macros % PtP 182
logging rates for tables 157 % Retries 181
usage notes 157 KB/IO 181
Macros, types of Total IOs/Sec 181
all-node 37 Total Reads/Sec 181
ByGroup 37 Total Writes/Sec 181
multiple-node 37 Node network traffic macros
one-node 37 function 180
Memory management by node macros input format examples 180
function 177 output column descriptions 181
input format examples 177 ResMemMgmtByNode 180
output column descriptions 178 ResNetByGroup 180
ResMemByGroup 177 ResNetOneNode 180
ResMemMgmtByNode 177 usage notes 180
ResMemMgmtOneNode 177 Nonunique primary index 46
usage notes 177 NUPI. See Nonunique primary index
Memory management macro output columns
# Proc Swp 178 O
% Mem Free 178
Ages/Sec 178 Obsolete columns
Aloc Fail % 178 ResUsageShst 93, 99
KB/Swp Drp 178 ResUsageSldv 99
KB/Swp Rd 178 ResUsageSpma 79
ResUsageSvpr 140

Index
Occasional event data 46 Avg Out Rqsts 175

One-Node KB/ I/O 175
macros, description of 38 Out Rqst Time % 175
One-Node macros, description 38 Reads/Sec 175
ordering publications 6 Writes/Sec 175
Overall resource usage information. See Summary macros Raw disk drive traffic macros
function 174
P input format examples 174
Parameters, macros use of 39 ResLdvByGroup 174
Partition Assignments ResLdvByNode 174
listing 234 ResLdvOneNode 174
table convention 233 usage notes 174
Partitions, definition 233 Relational Primary Index 46
PE information release definition 5
macros 165 ResAmpCpuByGroup macro
table 123 column descriptions 162
view 150 input format example 162
Performance Monitor Application Programming Interface. sample output 164
See PM/API usage notes 162
Performance Monitor, options what it reports 161
and equivalent PM/API 22 ResAWT macro
PM/API column description 158
and equivalent Performance Monitor options 22 input format example 157
error messages returned 22 output column descriptions 158
PM/API requests sample output 160
MONITOR PHYSICAL RESOURCE 22 usage notes 157
MONITOR PHYSICAL SUMMARY 22 what it reports 157
MONITOR VIRTUAL RESOURCE 22 ResAWTByAMP macro
MONITOR VIRTUAL SUMMARY 22 column description 158
Priority Scheduler information input format example 157
macros 188 output column descriptions 158
table 109 sample output 160
Priority Scheduler macros usage notes 157
and Teradata ASM workload 188, 193, 194 what it reports 157
ResPsByGroup 188 ResAWTByNode macro
ResPsByNode 188 column description 158
ResPsByNodeWDJoin 188 input format example 157
ResPsWDJoin 188 output column descriptions 158
product-related information 6 sample output 161
publications related to this release 6 usage notes 157
Purging old resource usage data 43 what it reports 157
ResCPUByAMP macro
Q column descriptions 162
Question marks, meaning in macro outputs 156 input format example 162
sample output 163
R usage notes 162
what it reports 161
Rates ResCPUByAMPOneNode macro
logging rate definition 26 column descriptions 162
recommended values 28 input format example 162
rules for setting 28 sample output 164
Raw disk drive traffic macro output columns usage notes 162
Avg I/O Resp 175, 200 what it reports 161

Index
ResCPUByGroup macro ResLdvByNode macro

column descriptions 169 column descriptions 175
sample output 170 input format example 174
usage notes 169 sample output 175
what it reports 168 usage notes 175
ResCPUByNode macro what it reports 174
column descriptions 169 ResLdvOneNode macro
input format example 169 column descriptions 175
sample output 170 input format example 174
usage notes 169 usage notes 175
what it reports 168 what it reports 174
ResCPUByPE macro ResMemByGroup macro
column descriptions 166 column description 178
input format example 165 sample output 180
sample output 167 usage notes 177
usage notes 165 what it reports 177
what it reports 165 ResMemMgmtByNode macro
ResCPUByPEOneNode macro column description 178
column descriptions 166 input format example 177
what it reports 165 ResMemMgmtOneNode macro
ResCPUOneNode macro column description 178
column descriptions 169 input format example 177
what it reports 168 ResNetByGroup macro
ResCPUUsageByAMPView, definition listing 148 column description 181
ResCPUUsageByPEView, definition listing 150 sample output 183
ResGeneralInfoView, definition listing 145 usage notes 181
ResHostByGroup macro what it reports 180
column descriptions 172 ResNetByNode macro
sample output 174 column description 181
usage notes 172 input format example 181
what it reports 171 sample output 182
ResHostByLink macro usage notes 181
column descriptions 172 what it reports 180
input format example 171 ResNetOneNode macro
ResHostOneNode macro usage notes 181
input format example 171 ResNode macro
ResLdvByGroup macro usage notes 184
sample output 176 ResNodeByGroup macro
usage notes 175 column description 184

Index
usage notes 184 column description 189

what it reports 183 input format example 189
ResNodeByNode macro sample output 193
column description 184 usage notes 189
sample output 188 what it reports 188
usage notes 184 ResPsByNodeWDJoin macro column description 189
ResOneNode macro ResPsCPUByNodeWDJoin macro
column description 184 column description 196
input format example 184 input format example 195
sample output 187 sample output 197
usage notes 184 usage notes 195
what it reports 183 what it reports 195
Resource usage data ResPsCPUByNodeWDJoin macro column description 196
collecting 19 ResPsCPUWDJoin macro
deleting old data 43 column description 196
functions of 17 input format example 195
logging 20 sample output 198
programs that use 21 usage notes 195
saving old data 39 what it reports 195
Resource usage macros ResPsCPUWDJoin macro column description 196
definition 21 ResPsWDJoin macro
example of executing a ByGroup macro 42 column description 189
example of executing a Multinode macro 41 input format example 189
example of executing a One-Node macro 42 sample output 194
executing 39 usage notes 189
syntax for 39 what it reports 188
Resource Usage tables. See ResUsage tables ResPsWDJoin macro column description 189
Resource usage views ResShstGroupView, definition listing 151
ResCPUUsageByAMPView 148 ResSldvGroupView, definition listing 152
ResCPUUsageByPEView 150 ResUsage tables
ResGeneralInfoView 145 column categories 48
ResShstGroupView 151 column descriptions 46
ResSldvGroupView 152 columns ending in "Avg" 47
ResVdskGroupView 152 columns ending in "Max" 48
ResPeCpuByGroup macro gather method columns 47
column descriptions 166 invalid platform columns 47
sample output 168 primary index 46
usage notes 165 reporting Summary Mode 51
what it reports 165 ResUsageIpma 26
ResPsByGroup macro ResUsageIvpr 24
column description 189 ResUsageSawt 26
input format example 189 ResUsageShst 26
sample output 192 ResUsageSldv 26
usage notes 189 ResUsageSpma 26
what it reports 188 ResUsageSps 26
ResPsByGroup macro column description 189 ResUsageSvdsk 26
ResPsByNode macro ResUsageSvpr 24
column description 189 types of statistics reported 48
input format example 189 which to enable 24
sample output 192 ResUsageIpma
usage notes 189 column names 209
what it reports 188 gathering method 209
ResPsByNode macro column description 189 ResUsageIvpr
ResPsByNodeWDJoin macro column names 221

Index
gathering method 221 input format example 199

spare columns 232 sample output 200
Summary Mode 231 usage notes 199
ResUsageSawt what it reports 199
column names 83 ResVdskGroupView, definition listing 152
gathering method 83 ResVdskOneNode macro
Summary Mode 87 column descriptions 199
ResUsageScpu input format example 199
column names 55 sample output 200
gathering method 55 usage notes 199
spare columns 59 what it reports 199
Summary Mode 58 RSS Collection Rate 34
ResUsageShst RSS logging
obsolete columns 93, 99 enabling from ctl and xctl 33
spare columns 94 enabling from DBW 35
Summary Mode 93 RSS table settings
ResUsageSldv Active Row Filter Mode Enable 34
column names 89, 95 enabling from Database Window 35
gathering method 89, 95 Node Logging Rate 34
obsolete columns 99 RSS Collection Rate 34
spare columns 100 Table Logging Enable 34
Summary Mode 100 Vproc Logging Rate 34
ResUsageSpdsk
column names 101 S
gathering method 101
spare columns 108 Sar
Summary Mode 108 compared with resource usage data 238
ResUsageSpma definition 237
column names 61 how it works 237
gathering method 61 Saving old resource usage data 39
obsolete columns 79 SET ACTIVELOGTABLE command 36
ResUsageSps SET LOGTABLE command 35, 36
column names 109 SET RESOURCE COLLECTION command 35
gathering method 109 SET RESOURCE command 36
Summary Mode 113 SET SUMLOGTABLE command 36
ResUsageSvdsk Single-Node. See One-Node
column names 115 Stopped logging
gathering method 115 how to re-enable logging 43
spare columns 87, 114, 122 Summary macro output columns
Summary Mode 121 A+R % of IOs 186
ResUsageSvpr CPU Bsy % 186
column names 123 CPU Eff % 186
gathering method 123 Fre Mem % 186
obsolete columns 140 Ldv Eff % 186
spare columns 140 Ldv IOs/Sec 186
Summary Mode 140 Ldv KB/IO 186
ResVdskByGroup macro Mem Age/Sc 186
column descriptions 199 Mem Aloc/Sec 186
input format example 199 Mem Fai % 186
sample output 201 ms/Blk 186
usage notes 199 Net Rtry % 186
what it reports 199 P+S % of IOs 186
ResVdskByNode macro Prc Blks/Sec 186
column descriptions 199 Read % of IOs 186

Index
TMIt IOs/Sec 186

TPtP IOs/Sec 186
WIO % 186
Summary macros
function 183
input format examples 183
ResNode 183
ResNodeByGroup 183
ResNodeByNode 183
ResOneNode 183
usage notes 183
Summary Mode
description 51
enabling a table 36
Syntax for
deleting old resource usage data 43
executing macros 39
reporting dates in macros 40
Syntax, how to read 205
System Activity Reporter, See Sar
System information
macros 157
T
Table Logging Enable 34
Teradata Active System Management. See Teradata ASM
Teradata ASM
determining workload CPU use versus relative weight 195
workload and Priority Scheduler macros 188, 193, 194
Time-monitored. See tmon data
tmon data, description 19, 47
track data, description 19, 47
V
Vdisk logical device traffic information
macros 199
view 152
Vdisk logical drive traffic macro output columns
Avg I/O Resp 200
Out Rqst Time % 200
Rd KB/ I/O 200
Read Cnt/ Sec 199
Write Cnt/ Sec 199
Wrt KB/ I/O 200
Vdisk logical drive traffic macros
ResVdskByGroup 199
ResVdskByNode 199
ResVdskOneNode 199
Views, resource usage data 145
Vproc Logging Rate 34

1098

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1098

Uploaded by

Copyright:

Available Formats

Teradata Database

Resource Usage Macros and Tables

Supported Software Release

Resource Usage Macros and Tables 3

Changes to This Book

Teradata Database 12.0 Made the following updates:

4 Resource Usage Macros and Tables

V2R6.2 • The following systems are supported: Microsoft Windows Server

Type of Information Description Source

Overview of the The Release Definition provides the http://www.info.teradata.com/

Resource Usage Macros and Tables 5

Type of Information Description Source

Additional Use the Teradata Information Products http://www.info.teradata.com/

CD-ROM images This site contains a link to a downloadable http://www.info.teradata.com/

Ordering Use the Teradata Information Products http://www.info.teradata.com/

General information The Teradata home page provides links to Teradata.com

References to Microsoft Windows and Linux

6 Resource Usage Macros and Tables

Resource Usage Macros and Tables 7

8 Resource Usage Macros and Tables

Benefits of Using Resource Usage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 2: Planning Your Resource Usage Data . . . . . . . . . . . . . . 23

Enabling ResUsage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Resource Usage Macros and Tables 9

Determining the Logging and Collection Rate Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Chapter 3: Resource Usage Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Enabling RSS Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Chapter 4: Resource Usage Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Physical Table Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

10 Resource Usage Macros and Tables

SECTION 1 Node Resource Usage Tables

Chapter 5: ResUsageScpu Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 6: ResUsageSpma Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

SECTION 2 Vproc Resource Usage Tables

Chapter 7: ResUsageSawt Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Chapter 8: ResUsageShst Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 9: ResUsageSldv Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Resource Usage Macros and Tables 11

Chapter 10: ResUsageSpdsk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

Chapter 11: ResUsageSps Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113

Chapter 12: ResUsageSvdsk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115

Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

Chapter 13: ResUsageSvpr Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Obsolete Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

SECTION 3 Views and Macros

Chapter 14: Resource Usage Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

12 Resource Usage Macros and Tables

Chapter 15: Resource Usage Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Macro Output Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Resource Usage Macros and Tables 13

ResNodeByGroup Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188

Appendix A: How to Read Syntax Diagrams . . . . . . . . . . . . . . . . . . . .205

Syntax Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

Appendix B: ResUsageIpma Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209

Appendix C: ResUsageIvpr Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221

Summary Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231

Appendix D: Partition Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Partition Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

14 Resource Usage Macros and Tables

Appendix E: System Activity Reporter. . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Using Sar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Resource Usage Macros and Tables 15