1102 V 2 RR

Teradata Database
Utilities: Volume 2 (L-Z)

Release 14.0
B035-1102-111A
January 2012
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, Active Enterprise Intelligence, Applications Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast,
Gridscale, Managing the Business of Marketing, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision
Experts, Teradata Labs Logo, Teradata Raising Intelligence Logo, Teradata Source Experts, WebAnalyst, and Xkoto are trademarks or registered
trademarks of Teradata Corporation or its affiliates in the United States and other countries.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of Oracle.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI is a registered trademark 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.
NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
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 registered trademark of Unicode, Inc. in the United States and other countries.
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 email: [email protected].
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 2012 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This book, Utilities, describes the utility programs that support Teradata Database and
consists of two manuals:
Utilities Volume 1 includes utilities A-K.
Utilities Volume 2 includes utilities L-Z.
Topics covered in this volume include utilities whose names begin with letters L through Z.
Use this book in conjunction with the other volume.
Chapter names reflect the utility common name followed by the name of the executable utility
program enclosed in parentheses, for example, Control GDO Editor (ctl). Use the executable
program name to start the utility from the command line or Database Window.
A third manual, Support Utilities, describes utilities most often used to support Teradata
Database. These utilities are used primarily by Teradata Support and field engineers, and
should be used only under the direction of Teradata Support personnel.
Audience
The utilities described in this book are used primarily by Teradata Support Center field
engineers, Teradata Database developers, System Test and Verification, and Teradata Database
system administrators. For example, these utilities are used to display control parameters,
display DBS control record fields, find and correct problems within the file system, initialize
the Teradata Database, rebuild tables in the database, and manage the virtual processors
(vprocs). These utilities are used to abort transactions and processes; monitor system
performance, resources, and status, perform internal system checking, and perform system
configuration, initialization, recovery, and tuning.
Users should also be familiar with the Teradata Database console running the Database
Window (DBW) and your client (host) system.
For experienced utilities users please see the simplified command descriptions in the Utilities
Quick Reference. This book provides the syntax diagrams and a brief description of the syntax
variables for each Teradata Database utility.
Utilities
Preface
Supported Software Releases and Operating Systems
Supported Software Releases and Operating

Systems
This book supports Teradata Database 14.0.
Teradata Database 14.0 is supported on:
SUSE Linux Enterprise Server (SLES)10
SLES 11
Note that SLES 11 will be supported after the initial release of Teradata Database 14.0.
Teradata Database client applications support other operating systems.
Prerequisites
You should be familiar with using the Database Window (DBW) to run the other utilities.
The following manuals contain related material:
Database Administration
Security Administration
Resource Usage Macros and Tables
SystemFE Macros
Platform-dependent Teradata Database Installation/Upgrade/Migration documents
For detailed information about the Archive and Recovery, FastExport, FastLoad, MultiLoad,
and Teradata Parallel Data Pump utilities, see the following client utilities books:
Teradata Archive/Recovery Utility Reference
Teradata FastExport Reference
Teradata FastLoad Reference
Teradata MultiLoad Reference
Teradata Parallel Data Pump Reference
Changes to This Book
Release
Utility
Description
Teradata Database 14.0

January 2012
Appendix A
Updated Syntax Diagram Conventions to mention mixed-case words in

syntax diagrams.
Vproc Manager
Removed obsolete references to PDE state TPA.
Utilities
Preface
Changes to This Book
Release
Utility
Description
Teradata Database 14.0

November 2011
Lock Logger
(dumplocklog)
Renamed from Locking Logger utility.

Described dumplocklogb, which can be used to add lock logging to
scripts, which can be used, for example, as scheduled cron jobs.
Priority Scheduler
Schmon is available only on SUSE Linux Enterprise Server (SLES) 10

systems.
On SLES 11 systems, Priority Scheduler is managed by Teradata ASM, and
configured by Viewpoint workload portlets.
Utilities
Reonfiguration
Moved chapter to Support Utilities manual.
Reconfiguration
Estimator
Moved chapter to Support Utilities manual.
Table Rebuild
Updated SQL in exampe of running Table Rebuild in the background.
Teradata Locale
Definition Utility
(tdlocaledef)
Renamed from Locale Definition Utility.

Added NUMBER data type to SDF file.
Teradata Network
Statistics (tdnstat)
Renamed from TDN Statistics
Teradata Network
Tuner (tdntune)
Renamed from TDN Tuner
TPA Reset
(tpareset)
Added -stop (-s) option, that keeps initiating node down when system
resets.
Update Space
Added new PSPOOL option.
Vproc Manager
Added description of CLEARMVAMP command.

On new or upgraded and sysinited systems, the range of potential ID
numbers for vprocs has been increased to allow for a total of 30720
(numbered 0 through 30719).
Preface
Additional Information
Additional Information
URL
Description
www.info.teradata.com/
Use the Teradata Information Products Publishing Library site

to:
View or download a manual:
1 Under Online Publications, select General Search.
2 Enter your search criteria and click Search.
Download a documentation CD-ROM:

1 Under Online Publications, select General Search.
2 In the Title or Keyword field, enter CD-ROM, and click
Search.
Order printed manuals:
Under Print & CD Publications, select How to Order.
www.teradata.com
The Teradata home page provides links to 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
www.teradata.com/t/TEN/
Teradata Customer Education designs, develops and delivers

education that builds skills and capabilities for our customers,
enabling them to maximize their Teradata investment.
www.teradataatyourservice.com
Use Teradata @ Your Service to access Orange Books, technical

alerts, and knowledge repositories, view and join forums, and
download software patches.
developer.teradata.com/
Teradata Developer Exchange provides articles on using

Teradata products, technical discussion forums, and code
downloads.
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 email [email protected].
Teradata Database Optional Features

This book may include descriptions of the following optional Teradata Database features and
products:
Teradata Row Level Security
Temporal Table Support
Utilities
Preface
Teradata Columnar
Teradata Virtual Storage (VS)
You may not use these features without the appropriate licenses. The fact that these features
may be included in product media or downloads, or described in documentation that you
receive, does not authorize you to use them without the appropriate licenses.
Contact your Teradata sales representative to purchase and enable optional features.
Utilities
Preface
Utilities
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Software Releases and Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Changes to This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Teradata Database Optional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Chapter 17: Teradata Database Utilities . . . . . . . . . . . . . . . . . . . . . . . . . 17

Alphabetical Listing of Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 18: Lock Display (lokdisp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Lock Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Lock Display Utility Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
BLOCKERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
HELP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
QUIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ROWHASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
ROWRANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
TABLE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
TRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Utilities
Table of Contents
Chapter 19: Lock Logger (dumplocklog) . . . . . . . . . . . . . . . . . . . . . . . . .43

Transaction Lock Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Lock Logger Settings in DBS Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Lock Logger Table Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Lock Log Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Running Lock Logger from Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Producing a Lock Log Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Example Log Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Lock Logger Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Chapter 20: Modify MPP List (modmpplist) . . . . . . . . . . . . . . . . . . . . . .67

Modify MPP List Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
DISPLAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
LIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
OFF id_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
ON id_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
QUIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
WRITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Running External Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Chapter 21: Priority Scheduler (schmon)

(SLES 10 only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Using Priority Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Resource Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Performance Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Performance Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Allocation Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Resource Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
AMP Worker Task (AWT) Reservations and Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Schmon Utility (schmon)
(SLES 10 only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
schmon -a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
schmon -b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
10
Utilities
Table of Contents
schmon -c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
schmon -d. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
schmon -f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
schmon -h. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
schmon -l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
schmon -m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
schmon -M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
schmon -p. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
schmon -s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
schmon -t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
schmon -w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Chapter 22: Query Configuration (qryconfig) . . . . . . . . . . . . . . . . . 155

About Query Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Query Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Chapter 23: Query Session (qrysessn) . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Query Session States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Parent and Child Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Query Session Displays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Session State Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
State Information Displays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Archive and Recovery Sessions State Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
FastLoad Sessions State Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
MultiLoad Sessions State Displays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
FastExport Sessions State Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Utilities
11
Table of Contents
Chapter 24: Reconfiguration Estimator

(reconfig_estimator) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Chapter 25: Reconfiguration Utility (reconfig) . . . . . . . . . . . . . . . . .187
Chapter 26: Recovery Manager (rcvmanager) . . . . . . . . . . . . . . . . .189

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Assigning Priority Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Online Transaction Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Transaction Recovery Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Multiple Recovery Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Deferred Transaction Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Down AMP Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Startup/Restart Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
Restarts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
Cancelling Rollback on Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Recovery Manager Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
CANCEL ROLLBACK ON TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
DEFAULT PRIORITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
HELP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
LIST CANCEL ROLLBACK TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
LIST LOCKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
LIST ROLLBACK TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
LIST STATUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
LIST STATUS proc-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
QUIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
REBUILD/RECOVERY PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
ROLLBACK SESSION...PERFORMANCE GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
12
Utilities
Table of Contents
Chapter 27: Resource Check Tools

(dbschk, nodecheck, syscheck) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Resource Check Tools Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
dbschk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
nodecheck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
syscheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Chapter 28: Show Locks (showlocks) . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Host Utility Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Interpreting the Show Locks Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Chapter 29: Table Rebuild (rebuild) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Rebuilding Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Table Rebuild Utility Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
REBUILD AMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
REBUILD AMP FALLBACK TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
RESTART REBUILD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Chapter 30: Task List (tsklist) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Chapter 31: Teradata Locale Definition Utility

(tdlocaledef) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
SDF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Example SDF Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Utilities
13
Table of Contents
Chapter 32: Teradata Network Statistics (tdnstat) . . . . . . . . . . .297
Chapter 33: Teradata Network Tuner (tdntune) . . . . . . . . . . . . . . .309
Chapter 34: TPA Reset (tpareset) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313
Chapter 35: Two-Phase Commit Console (tpccons) . . . . . . . . . . .317

Two-Phase Commit Console Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
COMMIT (or ROLLBACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
DISPLAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Identifying and Resolving In-Doubt Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Chapter 36: Update DBC (updatedbc) . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
Chapter 37: Update Space (updatespace) . . . . . . . . . . . . . . . . . . . . . . .325
Chapter 38: Verify Pdisks (verify_pdisks). . . . . . . . . . . . . . . . . . . . . . .329
Chapter 39: Vproc Manager (vprocmanager) . . . . . . . . . . . . . . . . . . .333

Definitions of Terms Used in Vproc Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Vproc Manager Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
Vproc Manager Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
BOOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
CLEARMVAMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
HELP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
INITVDISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
QUIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
14
Utilities
Table of Contents
SET RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

SET vproclist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
STATUS DBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
STATUS DBS ORDERBY CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
STATUS DBS ORDERBY HN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
STATUS DBS ORDERBY NODEID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
STATUS NOTONLINE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
STATUS ONLINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
STATUS PDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
STATUS RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
STATUS SYSSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
STATUS vproclist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Appendix A: How to Read Syntax Diagrams . . . . . . . . . . . . . . . . . . . 377

Syntax Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Appendix B: Starting the Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Starting Utilities from Database Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Starting Utilities from the Linux Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Starting Utilities from HUTCNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Utilities
15
Table of Contents
16
Utilities
CHAPTER 17
Teradata Database Utilities
This chapter lists the Teradata Database utilities that are documented in Utilities: Volume 1 (AK), Utilities: Volume 2 (L-Z), and Support Utilities.
Alphabetical Listing of Utilities

Utility
Purpose
Abort Host
(aborthost)
Aborts all outstanding transactions running on a failed host, until the

system restarts the host.
AMP Load
(ampload)
Displays the load on all AMP vprocs in a system, including the number of
AMP worker tasks (AWTs) available to each AMP vproc, and the number of
messages waiting (message queue length) on each AMP vproc.
AWT Monitor
(awtmon)
Collects and displays a user-friendly summary of the AMP Worker Task

(AWT) in-use count snapshots for the local node or all nodes in Teradata
Database.
CheckTable
(checktable)
Checks for inconsistencies between internal data structures such as table

headers, row identifiers, and secondary indexes.
CNS Run
(cnsrun)
Allows running of database utilities from scripts.
Configuration Utility
(config)
Defines AMPs, PEs, and hosts, and describes their interrelationships for
Teradata Database.
Note: Configuration is documented in Support Utilities.
Utilities
Control GDO Editor

(ctl)
Displays the fields of the PDE Control Parameters GDO, and allows
modification of the settings.
Cufconfig Utility
(cufconfig)
Displays configuration settings for the user-defined function and external

stored procedure subsystem, and allows these settings to be modified.
Database
Initialization
Program
(DIP)
Executes one or more of the standard DIP scripts packaged with Teradata
Database. These scripts create a variety of database objects that can extend
the functionality of Teradata Database with additional, optional features.
DBS Control
(dbscontrol)
Displays the DBS Control Record fields, and allows these settings to be
modified.
Dump Unload/Load
(DUL, DULTAPE)
Saves system dump tables to tape, and restores system dump tables from
tape.
17
Chapter 17: Teradata Database Utilities

Utility
Purpose
Ferret Utility
(ferret)
Defines the scope of an action, such as a range of tables or selected vprocs,

displays the parameters and scope of the action, and performs the action,
either moving data to reconfigure data blocks and cylinders, or displaying
disk space and cylinder free space percent in use of the defined scope.
Filer Utility
(filer)
Finds and corrects problems within the file system.
Gateway Control
(gtwcontrol)
Modifies default values in the fields of the Gateway Control Globally

Distributed Object (GDO).
Gateway Global
(gtwglobal)
Monitors and controls the Teradata Database LAN-connected users and

their sessions.
Lock Display
(lokdisp)
Displays a snapshot capture of all real-time database locks and their

associated currently-running sessions.
Lock Logger
(dumplocklog)
Logs transaction identifiers, session identifiers, lock object identifiers, and

the lock levels associated with currently-executing SQL statements.
Modify MPP List

(modmpplist)
Allows modification of the node list file (mpplist).
Priority Scheduler
(schmon)
(SLES 10 only)
Creates, modifies, and monitors Teradata Database process prioritization

parameters.
Note: Filer is documented in Support Utilities.
All processes have an assigned priority based on their Teradata Database

session. This priority is used by Priority Scheduler to allocate CPU and
I/O resources.
Note: On SLES 11 systems, Priority Scheduler is managed by Teradata
Active System Management (ASM), and is configured using the Teradata
Viewpoint workload management portlets. For more information on those
portlets, see Teradata Viewpoint User Guide.
Query Configuration
(qryconfig)
Reports the current Teradata Database configuration, including the Node,

AMP, and PE identification and status.
Query Session
(qrysessn)
Monitors the state of selected Teradata Database sessions on selected logical

host IDs.
Reconfiguration
Utility
(reconfig)
Uses the component definitions created by the Configuration Utility to

establish an operational Teradata Database.
Reconfiguration
Estimator
(reconfig_estimator)
Estimates the elapsed time for reconfiguration based upon the number and
size of tables on the current system, and provides time estimates for the
following phases:
Note: Reconfiguration is documented in Support Utilities.
Redistribution
Deletion
NUSI building
Note: Reconfiguration Estimator is documented in Support Utilities.
Recovery Manager
(rcvmanager)
18
Displays information used to monitor progress of a Teradata Database

recovery.
Utilities

Utility
Purpose
Resource Check
Tools
(dbschk, nodecheck,
syscheck)
Identifies slow down and potential hangs of Teradata Database, and displays
system statistics that help identify the cause of the problem.
Show Locks
(showlocks)
Displays locks placed by Archive and Recovery and Table Rebuild

operations on databases and tables.
For details Archive and Recovery, see Teradata Archive/Recovery Utility
Reference. For details on Table Rebuild, see Utilities Volume 2.
System Initializer
(sysinit)
Initializes Teradata Database. Creates or updates the DBS Control Record

and other Globally Distributed Objects (GDOs), initializes or updates
configuration maps, and sets hash function values in the DBS Control
Record.
Note: System Initializer is documented in Support Utilities.
Utilities
Table Rebuild
(rebuild)
Rebuilds tables that Teradata Database cannot automatically recover,

including the primary or fallback portions of tables, entire tables, all tables
in a database, or all tables in an Access Module Processor (AMP). Table
Rebuild can be run interactively or as a background task.
Teradata Locale
Definition Utility
(tdlocaledef)
Converts a Specification for Data Formatting file (SDF) into an internal,

binary format (a GDO) for use by Teradata Database. The SDF file is a text
file that defines how Teradata Databaseformats numeric, date, time, and
currency output.
Teradata Network
Statistics
(tdnstat)
Performs GetStat/ResetStat operations and displays or clears Teradata

Database Network Services statistics.
Teradata Network
Tuner
(tdntune)
Displays and allows modification of Teradata Network Services tunable

parameters. The utility provides a user interface to view, get, or update the
Teradata Network Services, which are specific to tunable parameters.
Tpareset
(tpareset)
Resets the PDE and database components of Teradata Database.
Two-Phase Commit
Console
(tpccons)
Performs the following two-phase commit (2PC) related functions:
Task List
(tsklist)
Displays information about PDE processes and their tasks.
Update DBC
(updatedbc)
Recalculates the PermSpace and SpoolSpace values in the DBASE table for
the user DBC, and the MaxPermSpace and MaxSpoolSpace values of the
DATABASESPACE table for all databases based on the values in the DBASE
table.
Update Space
(updatespace)
Recalculates the permanent, temporary, or spool space used by a single

database or by all databases in a system.
Displays a list of coordinators that have in-doubt transactions.

Displays a list of sessions that have in-doubt transactions.
Resolves in-doubt transactions.
19

For More Information
Utility
Purpose
Verify _pdisks
(verify_pdisks)
Verifies that the pdisks on Teradata Database are accessible and are mapped
correctly.
Vproc Manager
(vprocmanager)
Manages the virtual processors (vprocs). For example, obtains status of

specified vprocs, initializes vprocs, forces a vproc to restart, and forces a
Teradata Database restart.
For More Information
20
For information on...
See...
starting the utilities
the appendix titled Starting the Utilities
utilities related to Teradata Database security
Security Administration
Archive and Recovery, FastExport, FastLoad,

MultiLoad, and TPump
the following client utility books:
Teradata Archive/Recovery Utility Reference

Teradata FastExport Reference
Teradata FastLoad Reference
Teradata MultiLoad Reference
Teradata Parallel Data Pump Reference
Utilities
CHAPTER 18
Lock Display (lokdisp)
The Lock Display utility, lokdisp, provides a snapshot capture of all real-time database locks.
The database software uses locks for concurrency control. lokdisp displays locks used for
concurrency. A lock can be applied to a database object based on the following lock
granularity:
Database
Table
Rowhash Range
Rowhash
Optionally, you can specify the lock to be applied to a database object using the SQL Locking
Modifier.
lokdisp can obtain lock information from the following:
A specific AMP
A group of AMPs
All AMPs
Note: For a Teradata Database system with many AMPs and a heavy load, be careful when
selecting the number of AMPs from which to obtain information. The fewer the AMPs
selected, the lower the volume of lock information generated, and the more manageable the
output. Teradata recommends obtaining information from all AMPs only when the lock
information for a specific transaction is needed.
For detailed examples of returned data, see DB on page 27 and TABLE on page 37.
Runs From
Database Window or comparable interface to the Teradata Database console subsystem,

such as cnsterm
Linux command line
Teradata Viewpoint Remote Console portlet
For general information on starting the utilities from different interfaces, see Appendix B:
Starting the Utilities. For information on Viewpoint, see Teradata Viewpoint User Guide.
Utilities
21
Chapter 18: Lock Display (lokdisp)

Lock Modes
Lock Modes
You can specify the following lock modes to a database object:
Access
Read
Write
Exclusive
Lock-Mode Contention
The lock-mode contention among all outstanding lock requests determines which lock
requests can be applied concurrently against a database object. This is illustrated by the
contention matrix shown below.
Lock Mode
Implicit
Access
Implicit
Read
Implicit
Write
Implicit
Exclusive
Access
Read
Write
Implicit Access
Implicit Read
Implicit Write
Implicit Exclusive
Access
Read
Write
Exclusive
Exclusive
Explicit and Implicit Lock Modes

Explicit lock modes are the actual locks that secure access to a database object. Usually, they
are acquired at the onset of the actual transaction processing.
Implicit lock modes are pre-emptive locks used by the Lock Manager in the process of
acquiring an explicit lock. Use of pre-emptive locks suggests that an explicit lock is not
acquired in a single step but rather in a sequence of steps.
For example, consider acquiring an explicit table-level lock. Prior to acquiring the explicit
table-level lock, an implicit database-level lock and an implicit table-level lock must be
acquired first. Upon acquiring an explicit lock, any implicit lock acquired in the process is
released.
The lock mode is noted in the mode field of the lokdisp output. An implicit lock is identified
by the appearance of an asterisk (*). An explicit lock is implied when an asterisk is absent.
22
Utilities

Lock Display Utility Commands
Lock Request Status

A lock request against a database object can be granted or blocked depending on the
following:
The lock mode contention of all outstanding lock requests
The success of acquiring all locks implied by the lock granularity of the request
lokdisp output shows separate sections for Granted and Blocked lock requests. In the case of a
blocked request, the level of the database object is shown by marking the associated field in the
output with the hash symbol (#). For example, if the blocked request involves a table, then the
table field is marked with the # symbol.
Lock Display Utility Commands

Lock Display presents a command-line environment that allows the entry of the following
Lock Display commands. The commands are discussed in detail in the sections that follow.
Command
Description
BLOCKERS
Identifies the blocked transactions as well as their blocker transactions.
DB
Identifies the databases that have a database-level lock request.
HELP
Provides general help for the Lock Display utility.
QUIT
Exits lokdisp.
ROWHASH
Identifies a rowhash-level lock request. Rowhash lock information is provided

also.
ROWRANGE
Identifies a rowrange-level lock request. Rowrange lock information is provided

also.
TABLE
Identifies a table-level lock request.
TRAN
Identifies currently running transactions with locks being applied.
Commands are case-insensitive and may be abbreviated.

Lock Display interprets numeric input as hex (the default radix is hex). To enter decimal
format numeric values, follow the number with a period character. For example, ten decimal
must be entered as 10.. An unmodified 10 is interpreted as hex value 0x10, equivalent to
the decimal value sixteen.
Note: lokdisp displays a series of question mark (?) characters if it does not find user,
database, or table names in the cache or, in the case of DDL statements, in the Data
Dictionary. To view output examples, see DB on page 27 and TABLE on page 37.
Utilities
23

BLOCKERS
BLOCKERS
Purpose
The BLOCKERS command identifies blocked transactions and the transactions that are
blocking them.
Syntax
BLOCKERS
TRAN
ProcId
ALL
Uniq1
Uniq2
LIMIT
NUMBER
NONE
KY01A098
Syntax element...
Specifies...
ProcId
the virtual processor number of the parsing engine processor handling the
transaction.
Since virtual processor numbers are designated as integer numbers, the
corresponding value for this option normally is specified in decimal notation.
This number is the first component of a transaction ID.
Uniq1
a value that is normally specified as four hexadecimal digits.

This value is the second component of a transaction ID.
Uniq2

This value is the third component of a transaction ID.
ALL
that all blocked transactions and their corresponding blocker transactions will
be considered.
ALL is the default if you do not specify a transaction ID.
LIMIT
the number of blocker transactions to consider for a blocked transaction.
NUMBER
the desired limiting value.
NONE
that all blocker transactions for a blocked transaction are considered.

Specifying NONE corresponds to specifying zero for Number.
Note: Together, ProcId, Uniq1, and Uniq2 identify a transaction ID.
24
Utilities

BLOCKERS
Usage Notes
A transaction is an internal database concept. A transaction can have more than one blocking
transaction. For example, a transaction can have five lock requests, and five transactions can
block those same lock requests. In other words, if you have five tables, then conceivably, five
other transactions can have the locks on those same five tables.
The following table shows the components of BLOCKERS command output.
Component....
Includes the...
Number of Blocked
Trans displayed
total number of both blocked and blocker transactions.
Blocked Trans
number of the blocked transaction and the following information:

Number of blockers displays
Specifies blocker entry count.
Number of blockers exists
Specifies actual blocker count.
Blocker Trans
number of blocking transactions and the following information:

Lock mode
Specifies a type of lock mode:
Access
Read
Write
Exclusive
Lock status
Specifies a type of status of the lock request.
Granted
Lock objectType
Specifies a type of object that is locked:
Database
Table
Rowrange
Rowhash
Lock objectID
Specifies an ID of the locked object and might include the following:
Utilities
Database ID
Database Name
Table ID
Table Name
RowHashS
RowHashE
25

BLOCKERS
Note: If the lock objectType is Rowhash, only RowHashS is displayed; if the Lock objectType
is RowRange, both RowHashS and RowHashE is displayed. RowHashS and RowHashE are the
lower- and upper-bound levels of the RowHash range, respectively.
Example
The following example shows one lock entry on AMP 0:
> blockers LIMIT 1
blockers LIMIT 1
- The following amps are available:
0
1
2
Which amp(s) do you want to request on
(S=Sampline/A=all/C=cancel/Q=quit):
> 0
0
---------------- AMP 0 REPORTS A LOCK ENTRIES ---------------Number of Blocked Trans displayed :
1
=========================================
Blocked Trans 16383 00001354
Number of blockers displays :
1
Number of blockers exists
:
1
Blocker Trans : 16383 00001324
lock mode
: Exclusive
lock status
: Granted
lock objectType : Table
lock objectID
: DBID
: 00000428
: DBNAME
: STAFF
: TableID
: 00000519,0000
: TableName : EMPLOYEE
: RowHashS
: 00000000
: RowHashE
: 00000000
26
Utilities

DB
DB
Purpose
The DB command identifies the databases that have a database-level lock request.
Syntax
DB
D
DBname
ALL
KY01A096
Syntax element...
Specifies...
DBname
the name of a database.
ALL
that all databases that have a database-level lock request will be

considered.
ALL is the default if you do not specify a database name.
Usage Notes
The following table shows the components of DB command output.
Component...
Specifies...
Tran
currently running transactions with locks being applied.
Host
the logical host ID (the origin of the transaction).
Session
the session number for the transaction.
Mode
the lock mode:
Utilities
Access
Read
Write
Exclusive
User
the logon-ID for whom the lock is being requested.
Database
the name of the database being locked.
27

DB
Example 1
The following example shows locks on a sampling on all AMPs for the RECBDQTAC
database:
>lokdisp
Amp Utility
_______
|
|
___
|
/
|
--|
\___
__
|/
|
|
____
____|
/
|
\____|
|
|
____|
/
|
\____|
____
____|
/
|
\____|
|
__|__
|
|
|__
____
____|
/
|
\____|
Release 14.00.00.00 Version 14.00.00.00

LOCK DISPLAY UTILITY (June 2000)
LOCK DISPLAY UTILITY Command String Syntax:
Help or ?
TRan
[ProcId Uniq1 Uniq2] | [ALL]
Db
[DBname] | [ALL]
TAble
[DBname.Tablename] | [ALL]
ROWRange [DBname.Tablename TypeAndIndex] | [ALL]
ROWHash [DBname.Tablename TypeAndIndex, RowHash1 RowHash2] | [ALL]
Blockers [TRAN [ProcId Uniq1 Uniq2] | [ALL]] | [LIMIT [Number] |
[NONE]]
Quit
-> Please enter your selection from the list: db
0
-> Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/

Q=quit):
a>
a
---------------- AMP 0 REPORTS 1 LOCK ENTRIES ------------GRANTED LOCK REQUEST(S):
Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
0, 1000 Mode: WR*
User: DBC

Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
28
0, 1000 Mode: WR*
User: DBC
Utilities

DB
Example 2
The following example tries to display database-level locks while trying to create database
USER1. The first lock is an Intentional Write Lock on database DBC (user DBC), and the
second lock is an Intentional Exclusive Lock on database USER1 (user DBC).
LOKDISP >>
DB ALL
0
-> Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/Q=quit):
A
---------------- AMP 0 REPORTS 2 LOCK ENTRIES -------------
GRANTED LOCK REQUEST(S):

Tran: 16383 000008B8
Host: 7169 Session:
0, 1010 Mode: WR*
User: ??????????????????????????????
Database: ??????????????????????????????
Host:
7169 Session:
0, 1010 Mode: EX*
User: ??????????????????????????????
Database: ??????????????????????????????
Utilities
29

HELP
HELP
Purpose
The HELP command provides general help for Lock Display.
Syntax
HELP
H
KY01A097
Syntax element...
Specifies...
Help, H, or ?
general help for the Lock Display utility.
Example
The following example shows basic Lock Display Help:
-> Please enter your selection from the list:
HELP
LOCK DISPLAY UTILITY
An optional command string may be used to limit the display to specific
requests; otherwise, all requests are displayed except for BLOCKERS.
Commands are case-insensitive and may be abbreviated. The default radix
for numeric entries is hex, but may be forced to decimal by terminating
with a period. For example, ten decimal must be entered as "10.", since
an unmodified "10" is interpreted in hex as 0x10 or sixteen decimal.
For the TRAN command, a set of lines displayed represents one lock
request.
Only object names relevant to a given lock request are displayed: for
example, only database name is displayed for a database lock, whereas
both database name and table name are displayed for a table lock. A "#"
after an object name means the lock has not yet been granted for that
level. For example, "Databasename Tablename# Rowhash1#" means the lock
has been granted at database level, but not yet at table or rowhash
level.
--more-- Please press <enter> to continue.
30
Utilities

QUIT
QUIT
Purpose
The QUIT command exits lokdisp.
Syntax
QUIT
Q
1102A216
Utilities
Syntax element...
Specifies...
QUIT or Q
that lokdisp should exit.
31

ROWHASH
ROWHASH
Purpose
The ROWHASH command identifies a rowhash-level lock request.
Syntax
ROWHASH
ROWH
DBname .Tablename
TypeAndInde x
RowHash1
RowHash2
ALL
KY01A094
Syntax element...
Specifies...
DBname.Tablename
the name of a database and the name of a table separated by a required

period (.).
TypeAndIndex
a subtable identifier.
A table is composed logically of one or more subtables. TypeAndIndex
specifies one of these subtables. For example:
0 is the table header.
hex 400 (decimal 1024) is a primary subtable.
hex values 404, 408, and 40C (decimal values 1028, 1032, and 1036),
and other +4 incremental values, are secondary index subtables.
hex values 800, C00, and 1000 (decimal values 2048, 3072, and
4096), and other multiples of hex 400 (decimal 1024) are fallback
subtables.
RowHash1
a Teradata Database system-assigned rowhash value used to acquire a

rowhash lock.
Normally, this value is specified in decimal notation.
RowHash2
a Teradata Database system-assigned rowhash value used to acquire a

rowhash lock.
Normally, this value is specified in decimal notation.
ALL
that all tables that have a rowhash-level lock applied are considered.
ALL is the default if you do not specify an object name.
32
Utilities

ROWHASH
Usage Notes
The following table shows the components of ROWHASH command output.
Component...
Specifies...
Tran
currently running transactions with locks being applied.
Host
the logical host ID (origin of the transaction).
Session
Mode
the type of lock mode:
Access
Read
Write
Exclusive
User
Database
Table
the name of the locked table.
Row Hash
the locked row hash.
Note: The rowhash lock information is provided also.
Example
The following example shows locks on AMPs 0 and 2 on Database RECBDQTAC and Table
T1.
rowhash
0

Q=quit):
> a
a

Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
Row Hash Lock
Row Hash1: 62321,15470
Utilities
0, 1000 Mode: WR
User: DBC
Table: T1
Subtable ID: 1536
33

ROWHASH

Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
Row Hash Lock
Row Hash1: 31158,40503
Host: 2049 Session:
Database: RECBDQTAC
Row Hash Lock
Row Hash1: 59106,30941
34
0, 1000 Mode: WR
User: DBC
Table: T1
Subtable ID: 1024
0, 1000 Mode: WR
User: DBC
Table: T1
Subtable ID: 1536
Utilities

ROWRANGE
ROWRANGE
Purpose
The ROWRANGE command identifies a rowrange-level lock request.
Syntax
ROWRANGE
ROWR
DBname .Tablename
TypeAndInde x
ALL
KY01A095
Syntax element...
Specifies...
DBname.Tablename

period (.).
TypeAndIndex
a subtable identifier.
A table is composed logically of one or more subtables. TypeAndIndex
specifies one of these subtables. For example:
0 is the table header.
hex 400 (decimal 1024) is a primary subtable.
hex values 404, 408, and 40C (decimal values 1028, 1032, and 1036),
and other +4 incremental values, are secondary index subtables.
hex values 800, C00, and 1000 (decimal values 2048, 3072, and
4096), and other multiples of hex 400 (decimal 1024) are fallback
subtables.
ALL
that all tables that have a rowrange-level lock request are considered.
ALL is the default if you do not specify the command parameters.
Usage Notes
The following table shows the components of ROWRANGE command output.
Utilities
Component...
Specifies...
Tran
the currently running transactions with locks being applied.
Host
Session
35

ROWRANGE
Component...
Specifies...
Mode
Access
Read
Write
Exclusive
User
Database
Table
the name of the table being locked.
Row Range
the range of rows being locked.
Example
The following example shows locks on AMP 0 on Database STAFF and Table
MANAGEMENT.
> rowrange staff.management 0
rowrange staff.management 0
0

Q=quit):
> a
a
BLOCKED LOCK REQUEST(S):

Tran: 16383 00001354
Host:
0 Session:
Database: STAFF
Row Range Lock
Row Hash1:
0,
1
36
0, 2053
Mode: Ac
User: TD
Table: MANAGEMENT
Subtable ID: 0
Row Hash2: 0,
2
Utilities

TABLE
TABLE
Purpose
The TABLE command identifies a table-level lock request.
Syntax
TABLE
TA
DBname .Tablename
ALL
KY01A093
Syntax element...
Specifies...
DBname.Tablename

period (.).
ALL
that all tables (from all databases) that have a table-level lock request
are considered.
ALL is the default if you do not specify an object name.
Usage Notes
The following table shows the components of TABLE command output.
Component...
Specifies...
Tran
Host
Session
Mode
User
Utilities
Access
Read
Write
Exclusive
37

TABLE
Component...
Specifies...
Database
Table
Example 1
The following example shows the locks on AMP 0 on the database RECBDQTAC and table T1:
table
0

Q=quit):
> a
a
Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
0, 1000 Mode: WR* User: DBC

Table: T1

Tran: 16383 00000114
Host: 2049 Session:
Database: RECBDQTAC
0, 1000 Mode: WR*
User: DBC
Table: T1
Example 2
The following is an example of trying to display table-level locks on a table while trying to
create the table.
table all
0
-> Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/Q=quit):
A
Host:
7169
Session:
Database: STAFF
0, 1441 Mode: EX
User: DBC
Table: ??????????????????????????????
Table name is not printed.
38
Utilities

TRAN
TRAN
Purpose
The TRAN command identifies currently running transactions with locks being applied.
Syntax
TRAN
TR
ProcId
ALL
Uniq1
Uniq2
KY01A092
Syntax element...
Specifies...
ProcId
the virtual processor number of the parsing engine processor handling

the transaction.
Since virtual processor numbers are designated as integer numbers, the
corresponding value for this option normally is specified in decimal
notation.
This number is the first component of a transaction ID.
Uniq1

This value is the second component of a transaction ID.
Uniq2

This value is the third component of a transaction ID.
ALL
that all blocked transactions and their corresponding blocker

transactions that will be considered.
ALL is the default if you do not specify an ProcId.
Note: Together, ProcId, Uniq1, and Uniq2 identify a transaction ID.
Usage Notes
A transaction is an internal database concept. A transaction can have more than one blocking
transaction. For example, a transaction can have five lock requests, and five transactions can
block those same lock requests. In other words, if you have five tables, then conceivably, five
other transactions can have the locks on those same five tables.
Each logically grouped display represents one lock request. Only object names relevant to a
given lock request are displayed.
Utilities
39

TRAN
For example, only the database name is displayed for a database lock, whereas both a database
name and a table name are displayed for a table lock.
The following table shows the components of TRAN command output.
Component...
Specifies...
Tran
Host
Session
Mode
Access
Read
Write
Exclusive
User
Database
Table
DUMMY LOCK
the specific row has lock applied on a distinct pseudo dictionary table when
applicable to facilitate concurrency control. The pseudo dictionary table
does not exist. The table ID is used as the value of the row hash.
Example 1
The following example shows the transactions on all AMPs, with AMP 0 having four lock
entries, and AMP1 having three lock entries.
-> Please enter your selection from the list: tr
0

Q=quit): a
-> Please enter your selection from the list:
tr all
0

Q=quit):
a
40
Utilities

TRAN
Tran: 16383 00001EE0
Host: 1025 Session:
Database: DBC
0, 1001 Mode: Ac
User: DBC
Table: DBASE
Host: 1025 Session:

Database: DBC
0, 1001 Mode: Ac
User: DBC
Table: TVM
Host: 1025 Session:

Database: RKPMED
DUMMY LOCK
0, 1001 Mode: WR
User: DBC
Table: STORES
Host: 1025 Session:

Database: RKPMED
0, 1001 Mode: WR
User: DBC
Table: STORES

Tran: 16383 00001EE0
Host: 1025 Session:
Database: DBC
0, 1001 Mode: Ac
User: DBC
Table: DBASE
Host: 1025 Session:

Database: DBC
0, 1001 Mode: Ac
User: DBC
Table: TVM
Host: 1025 Session:

Database: RKPMED
0, 1001 Mode: WR
User: DBC
Table: STORES
-------------< END OF OUTPUT >-------------
Utilities
41

TRAN
Example 2
This example shows a blocked row hash lock request. Note the hash mark (#) that appears
next to the blocked row hash, indicating that the lock was requested, but has not yet been
granted.
LOCK DISPLAY UTILITY Command String Syntax:
Help or ?
TRan
[ProcId Uniq1 Uniq2] | [ALL]
Db
[DBname] | [ALL]
TAble
[DBname.Tablename] | [ALL]
ROWRange [DBname.Tablename TypeAndIndex] | [ALL]
ROWHash [DBname.Tablename TypeAndIndex, RowHash1 RowHash2] | [ALL]
Blockers [TRAN [ProcId Uniq1 Uniq2] | [ALL]] | [LIMIT [Number] |
[NONE]]
Quit
-> Please enter your selection from the list: tr
0

Q=quit): a

Tran: 16383 006AACE
Host: 1076 Session:
Database: DBASE1
Row Hash1: 31158,40503
0,2013 Mode: EX
User: USER1
Table: TBL_1A
BLOCKED LOCK REQUEST(S):

Tran: 16383 0006AAD2
Host: 1076 Session:
0,2012 Mode: EX
User: USER2
Database: DBASE1
Table: TBL_1A
Row Hash1: 31158,40503#
42
Utilities
CHAPTER 19
Lock Logger (dumplocklog)
The Lock Logger utility, dumplocklog, creates a table of lock information extracted from
Teradata Database transaction logs. The data from this table can be used to analyze lock
contention issues between concurrent SQL statements.
When logging is enabled, Teradata Database logs the following:
Transaction identifiers
Session identifiers
Lock object identifiers
Lock levels associated with executing SQL statements that have been delayed because of
database lock contention
Global deadlocks
Runs From
The Lock Logger utility runs from Database Window or comparable interface to the Teradata
Database console subsystem, such as cnsterm.
Type start dumplocklog to populate the lock log table with lock information.
To run the lock logger from scripts, such as for a scheduled cron job, use the CNS Run utility
to run dumplocklogb, the batch version of the program.
Starting the Utilities. For information about running utilities like dumplocklogb from
scripts, see the CNS Run chapter in Utilities - Volume 1.
Transaction Lock Log Information

To use the Lock Logger, you must first enable lock logging. Use the DBS Control utility,
described in Utilities - Volume 1, to set the LockLogger setting to TRUE.
When lock logging is enabled, each Teradata Database system AMP creates a circular memory
buffer for saving transaction lock log information, including logging information for global
deadlocks. Host Utility (HUT) locks are included in global deadlock detection. When the
buffer is full, new entries overwrite the oldest entries, so the buffers maintain the most recent
lock information.
The default size of the lock log buffers is 64 KB. You can change the size by changing the value
of the LockLogSegmentSize field in DBS Control. This value indicates the size of the locking
Utilities
43
Chapter 19: Lock Logger (dumplocklog)

Lock Logger Settings in DBS Control
logger segments. For more information on the LockLogSegmentSize field and the DBS
Control Utility, see Utilities Volume 1.
When a transaction encounters a lock contention delay, the AMP writes an entry in the lock
log buffer that includes object identifiers containing the following information concerning the
delayed transaction:
The date and time the transaction lock was requested
The length of time the blocked transaction was blocked
The database and table identifiers of the table upon which the lock was requested
The host ID and session number of the transaction request that was locked
The host ID and session number of the transaction that imposed the lock
The processor ID of the AMP where the lock was requested
The lock level (database, table, row, or range of rows), and mode (read, write, exclusive), of
the lock request
The type of executing statement associated with the transaction (INSERT, UPDATE,
SELECT, and so forth)
Whether the lock request caused a deadlock
Issuing the dumplocklog command causes the lock buffers to be dumped to a database table,
where the lock information can be further investigated. As an option, dumplocklog can run in
continuous mode, to provide an ongoing log of transaction locks encountered by each AMP.
Lock Logger Settings in DBS Control

Operating parameters of Lock Logger are determined by the following DBS Control settings:
Setting
Description
LockLogger
Enables or disables Lock Logger. Set LockLogger to TRUE to

enable lock logging. The default setting is FALSE.
LockLogger Delay Filter
Enables or disables log filtering of blocked lock requests based

on delay time. Set LockLoggerDelayFilter to TRUE to enable
filtering. The default setting is FALSE.
LockLogger Delay Filter Time
Specifies a threshold time delay value (in seconds). Lock

requests that are blocked for less than this amount of time are
not logged. This prevents the log table from being filled with
data from insignificantly blocked locks. The default is zero
seconds.
LockLogSegmentSize
specify the size of the lock log segment.
For more information, see DBS Control Utility in Utilities Volume 1.
44
Utilities

Lock Logger Table Requirements
Lock Logger Table Requirements

Lock log tables allow you to define the information that you want to retrieve from the lock log
buffers. When using dumplocklog to create a lock log table, you must provide the following
information.
Required
Information
User name and
password
Description
Since Lock Logger uses standard Teradata SQL statements to create the lock
log table and insert the information from the lock log buffers, you must have
appropriate database access privileges.
If the table is new, you must have CREATE TABLE privileges.
If the table is existing, you must have table or database INSERT privileges.
Number of SQL
sessions
dumplocklog will
use to perform the
INSERT operation
The minimum is one session; the maximum is one session for each online
AMP.
The following restrictions affect the performance and ability of dumplocklog
to run.
If dumplocklog runs in continuous mode, there should be at least one or
more console sessions per PE. If the ratio of AMPs to PEs is at least three to
one, the utility should have no problem running. But if the ratio is six to
one or higher, dumplocklog cannot run in continuous mode.
If dumplocklog runs in snapshot mode, there must be one or more free
console session per PE (no matter what the ratio of AMPs to PEs) for
dumplocklog to run.
Note: The maximum number of sessions is limited by the number of PEs.
Utilities
Type of mode of
dumplocklog
dumplocklog has the following types of modes.
Character set of the

table name
This parameter dictates how the input is to be interpreted internally by

dumplocklog and the Teradata Database system.
Name of the lock

log table to be
created
You can specify either an existing table or a new table.
Time constraints
that you want to
use for selecting
entries from the
lock log buffers
You can select lock log entries that were created for the following:
If the type of mode is single-snapshot, dumplocklog creates lock log table

entries from a single copy of the current contents of the lock log buffer for
each AMP.
If the type of mode is continuous, table entries from the first copy of the
contents of the lock log buffer for each AMP, then gets additional buffer
entries, as they are created, translating them into additional lock log table
rows.
For detailed information on naming a table, see Basic SQL Syntax and
Lexicon in SQL Fundamentals.
Within a specified time range

At or after a specified time
At or before a specified time
The default is no time constraint.
45

Lock Log Tables
Required
Information
Names of any
specific database
objects whose lock
log entries you
want to select.
Description
You can select the following objects:
A specific database and a specific table
A specific database and all of the tables
A specific table under the default database for your user name
You can select up to 10 objects. If you do not specify any objects, the default
specification selects all tables from all databases.
Lock Log Tables

Note: In order to create a lock log table, you must have CREATE TABLE privileges. Also, if
you are updating an existing table, you must have INSERT privileges for the table or database.
To create lock log tables after starting dumplocklog, do the following:
1
Enter your logon string: <username,password> (Q/q to quit)
After entering your logon string, the following message appears.

2
Do you want this utility to run continuously? (Y/N):
IF you answer...
THEN you specify the...
continuous run mode whereby rows are added to your table as additional lock
log buffer entries are created. This continues until you terminate the utility, or
until the size of the table consumes all available Teradata Database system
storage.
If your username and password are validated, you go directly to Step 4.
If the username and password cannot be validated, the utility terminates at
this point.
single-snapshot mode whereby the utility creates or updates your lock log table
from a single copy of the lock log buffer for each Teradata Database system
AMP.
If you answer N, and specify the single-snapshot mode, the number of sessions
prompt appears.
46
Enter number of sessions (? For Help, Q/q to Quit):
Number of
concurrent sessions
Description
Minimum
The minimum number of sessions is equal to the number of AMPs + 1.
Utilities

Lock Log Tables
Number of
concurrent sessions
Description
Maximum
Based on the following:

Because of a limit of four console sessions per PE, the maximum number of
sessions is whichever is lower:
The number of online AMPs
The number of PEs
The default is the maximum: one session per online AMP:
To select the default, type an asterisk (*).
If you type an invalid number, the utility displays an error message and
repeats the number of sessions prompt.
Enter the Character Set (? for Help, Q/q to Quit):
STRING - Interpreted as a CHARACTERSET NAME.
NUMBER - Interpreted as a CHARACTERSET CODE.

Note: The first character of the input dictates this rule. Example: 123ascii is read as
123.
* (asterisk) - The default character set, which is usually ASCII for a network-attached
machine and EBCDIC for a channel-connected Teradata Database system.
? (question mark)- Lists the character sets installed on your Teradata Database system.
Note: Depending on the particular host connection of your machine, you might not be
able to use all of the following available character sets:
Code
Character Set Name
127
ASCII
64
EBCDIC
65 - 126
User-defined
Enter the table name where the lock log entries will be written (?
for Help, Q/q to Quit):
Specify a new table or an existing table. You must have the appropriate database access
privileges.
Note: Table name entries on a Kanji machine must be in hex format, such as
'82eb82ae'XN, an even number of hex characters delimited by apostrophe characters
immediately followed by the letters XN.
Utilities
47

Lock Log Tables
To specify a table...
Type...
for a database other than the default

database of your logon username
both the database name and the table name as follows:

<name1>.<name2>
where:
<name1> specifies the database name.
<name2> specifies the table name.
that is under the default database of your

logon username
only the table name as follows:

<name1>
where:
Do you want this utility to create table <tablename> (Y/N):
Y - If you specified a new table name
N - If you specified an existing table name
Enter the time constraint to control selection of lock log entries

that were generated AT or LATER than this time YYYYMMDD HHMMSS (?
For Help, Q/q to Quit):
Note: This is the first of two time constraint prompts that ask you to specify a time period
for selecting lock log entries.
To specify all entries that were created within a range of times, specify both an AT or
LATER and an AT or PRIOR time constraint.
To select all entries from the lock log buffers, regardless of time, type an asterisk (*).
Time constraints are specified using the following format:

YYYYMMDD HHMMSS
Formatting Characters - Description
Valid Range of Values
YYYY=Year
1901 to 9999
MM = Month
01 to 12
DD = Day
01 to 31
HH = Hour
00 to 23
MM = Minute
00 to 59
SS = Second
00 to 59
Note: If you answered Y at Step 2 to specify the continuous run mode, skip to Step 8 and
specify the database object constraints for selecting lock log entries. If you entered N at
Step 2 to specify the single-snapshot mode, you are prompted to type the latest time of the
range of lock log entries that you want to select.
48
Utilities

Lock Log Tables
8
Enter the time constraint to control selection of lock log entries

that were generated AT or PRIOR TO this time YYYYMMDD HHMMSS (?
For Help, Q/q to quit):
If entries were created for a specified range of times, type the AT or PRIOR time of the
range using the same format as in Step 7.
9
Enter the object constraint to select lock log entries

<database.table> (? For Help, Q/q to quit):
You can specify up to 10 database objects for selecting lock log entries.
If you do not want to specify any database objects, type an asterisk (*) and skip to Step 11.
After you type the first object constraint, the utility prompts you to type another object.
To specify a...
Type...
table for a database other than the default

database of your logon username
both the database name and the table name as follows:

<name1>.<name2>
where:
<name1> specifies the database name.
table that is under the default database of

your logon username
only the table name as follows:

<name1>
where:
database and all of the tables under it
the database name and an asterisk (*) as follows:

<name>.*
where:
<name> specifies the database name.
* specifies all of the tables under the database.
10 more? <database.table> (? For Help, <Ret> for Done):
The utility will redisplay the more? prompt until you have specified ten object constraints,
or until you press the carriage return key without specifying another object.
11 After you specify the database object constraints, the utility initiates the table CREATE and
INSERT tasks and displays the following statement and prompt:

Writing lock log entries to table <tablename>
Press <F2> anytime to stop the utility
Utilities
If you specified the single-snapshot mode in Step 2, or if you entered a prior-to time
constraint in Step 7, the utility stops when it completes the single-snapshot operation.
If you specified the continuous run mode in Step 1 with no prior-to time constraint in
Step 7, the utility runs continuously until you stop it by pressing the F2 function key, or
49

Hexadecimal and Non-Standard Names Support
until the size of your table grows to consume all available Teradata Database system
storage.
12 The final display indicates the total number of rows that were inserted in the table that you
specified in Step 5:
<positive integer> rows have been inserted to table <tablename>
*** DumpLockLog is terminated ***
For a description of the structure of the lock log table that dumplocklog creates and example
procedures for joining your table with the Teradata Database system DBase, TVM, and
EventLog tables to produce a meaningful output report, see Producing a Lock Log Report
on page 51.
Hexadecimal and Non-Standard Names Support

For hexadecimal name support, dumplocklog allows you to type log table names and lock
object names in hexadecimal format and in non-standard format (names are surrounded by
double quotation marks).
Hexadecimal Syntax
The hexadecimal format is as follows:
'...'XN.'...'XN
Syntax element...
Description
...
the string of a hexadecimal number.
Digit
0 - 9.
Char
a - f or A- F.
Delimiters in Object Names

To input an object constraint in dumplocklog, an object name must be delimited by double
quotation marks. Any embedded double quotation marks in the object name must be
preceded by an apostrophe.
Teradata Database Name Examples
The following are examples of acceptable Teradata Database names:
ABC'DB1.cjh'single
JOSE"DB.table 'a
XYZ'S DATA"BASE.tes't"3
"DB " 30' sl' dl' space' chars."Tbl " 30' sl' dl' spce' chars
'employee''"database.'''employee""table
50
Utilities

Running Lock Logger from Scripts
The following are examples of the same database names modified to be accepted as object
constraints by dumplocklog. The names are delimited, and double quotation marks within the
name are preceded by an apostrophe character.
"ABC'DB1"."cjh'single"
"JOSE'"DB"."table 'a"
"XYZ'S DATA'"BASE"."tes't'"3"
"'"DB '" 30' sl' dl' space' chars"."'"Tbl '" 30' sl' dl' spce' chars"
"'employee'''"database"."'''employee'"'"table"
To be accepted by Teradata Database, non-standard names must be delimited, and any

embedded double quotation marks must themselves be immediately preceded by double
quotation mark characters. The following are the same Teradata Database names as above,
modified to be accepted in Teradata SQL statements.
"ABC'DB1"."cjh'single"
"JOSE""DB"."table 'a"
"XYZ'S DATA""BASE"."tes't""3"
"""DB "" 30' sl' dl' space' chars"."""Tbl "" 30' sl' dl' spce' chars"
"'employee''""database"."'''employee""""table"
For detailed information on naming objects, see Basic SQL Syntax and Lexicon in SQL
Fundamentals.
Running Lock Logger from Scripts

To run the Lock Logger utility from from scripts, for example as a scheduled cron job, use the
dumplocklogb program together with the CNS Run utility. Dumplocklogb accepts the same
parameters as dumplocklog, however, it ignores the Run Continuously parameter, and always
runs one time then exits. If dumplocklogb detects an imput error (invalid session number,
tablename exists, excessive input), the program exits.
Producing a Lock Log Report

The lock log table that is created by dumplocklog and dumplocklogb uses the following
structure:
CREATE SET TABLE DHV.LL ,FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL
(
BEGDATE DATE FORMAT 'YY/MM/DD' NOT NULL,
BEGTIME FLOAT FORMAT '99:99:99.999' NOT NULL,
DELAY FLOAT FORMAT '99:99:99.999' NOT NULL,
DBID BYTE(4) NOT NULL,
TID BYTE(6) NOT NULL,
BLKDLOGHOST SMALLINT NOT NULL,
BLKDSESSNO INTEGER NOT NULL,
BLKDLEVEL CHAR(8) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
BLKDMODE CHAR(2) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
BLKINGLOGHOST SMALLINT NOT NULL,
Utilities
51

Producing a Lock Log Report
BLKINGSESSNO INTEGER NOT NULL,
BLKINGLEVEL CHAR(8) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
BLKINGMODE CHAR(2) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
PROCESSOR SMALLINT FORMAT 'ZZZZ9' NOT NULL,
DEADLOCK CHAR(1) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
MULTIPLEBLOCKER CHAR(1) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL,
STMTTYPE VARCHAR(20) CHARACTER SET UNICODE NOT CASESPECIFIC NOT NULL)
PRIMARY INDEX ( BEGDATE ,BEGTIME );
The following table describes the structure.

Column
Description
Format and Data Type
BEGDATE
The date the transaction was blocked.
DATE NOT NULL
BEGTIME
The time that the transaction became blocked.
FLOAT '99:99:99.999' NOT NULL
BLKDLEVEL
The lock level of the transaction that was waiting

for the lockLokDB, LokTable, LokRowRg, or
LokRow.
CHAR(8) NOT NULL
BLKDLOGHOST
The logical host ID of the transaction that was

waiting for the lock.
SMALLINT NOT NULL
BLKDMODE
The lock mode of the transaction that was waiting

for the lockAccess, Read, Write, or Excl.
CHAR(2) NOT NULL
BLKDSESSNO
The session number of the transaction that was

waiting for the lock.
INTEGER NOT NULL
BLKINGLOGHOST
The logical host ID of the transaction that

imposed the lock.
SMALLINT NOT NULL
BLKINGLEVEL
The lock level of the transaction that imposed the

lockLokDB, LokTable, LokRowRg, or LokRow.
CHAR(8) NOT NULL
BLKINGMODE
The lock mode of the transaction that imposed the

lock.
CHAR(2) NOT NULL
BLKINGSESSNO
The session number of the transaction that

imposed the lock.
INTEGER NOT NULL
The following session numbers are used to

indicate DBS internal sessions:
0 - System User
1 - System Accounting
2 - System Recovery
3 - Archive/Recovery
DBID
52
The database ID of the table on which the lock was

requested.
BYTE(4) NOT NULL
Utilities

Example Log Tables
Column
Description
Format and Data Type
DEADLOCK
Indicates whether the lock contentions resulted in

a deadlock.
CHAR(1) NOT NULL
The following values are used to indicate the type

of deadlock:
N - No deadlock
Y - Local deadlock
G - Global deadlock
DELAY
The total time the transaction waited for the

block.
FLOAT '99:99:99.999' NOT NULL
MULTIPLEBLOCKER
Indicates whether more than one transaction

encountered the same lock contention.
CHAR(1) NOT NULL
PROCESSOR
The identifier of the AMP where the lock was

requested.
SMALLINT 'ZZZZ9' NOT NULL)
STMTTYPE
The type of executing statement for the

transaction that produced the lock.
VARCHAR (20) NOT NULL
TID
The table ID of the table on which the lock was

requestedAccess, Read, Write, or Excl.
BYTE(6) NOT NULL
The rows in the table also contain the following information:
Internal identifiers for the object on which the lock was requested
Holder of the lock
Requestor of the lock
Example Log Tables

The example lock log tables are similar in the following respects:
Since the EventLog table usually is very large, the examples first try to reduce the size of
this table to minimize the execution time of the join operation.
Temporary tables are assigned names using non-alphabetic characters to avoid possible
conflicts with existing permanent tables.
MyLog represents the lock log table that was created by dumplocklog.
Reducing the Size of the Tables

When a lock log table is joined with DBC.EventLog, determining the blocked user from the
blocking user can be difficult. Usually, this is because of a large number of rows in
DBC.EventLog with the same session number, since the session number is reused whenever
TDP restarts.
To determine the blocked user from the blocking user, use the following:
Utilities
53

Example Log Tables
The begdate and begtime values from the lock log table
The logondate and logontime values from DBC.EventLog
For example, suppose that your lock log table (MyLog) and the DBC.EventLog table contain
the following rows.
MyLog Table
DBC.EventLog Table
begdatetime
blkdsessno
logondatetime
sessionno
user
T2
S1
T1
S1
T4
S2
T2
S2
T10
S1
T3
S1
T30
S2
T5
S1
T9
S2
T11
S1
T20
S2
To identify the user from DBC.EventLog for each row in MyLog, note the following:
The first row of MyLog is <T2,S1> and there are four rows from DBC.EventLog with
session number S1:
Since S1 was blocked at time T2, S1 must have been logged on before T2. Therefore, user A
was blocked at T2.
<T1,S1,A>
<T3,S1,C>
<T5,S1,D>
<T11,S1,F>
Similarly, the second row of MyLog, <T4,S2>, identifies user B.
The third row of MyLog, <T10,S1>, has four rows from EventLog with session number S1,
and three of them have a logondatetime before T10:
<T1,S1,A>
<T3,S1,C>
<T5,S1,D>
In this case, user D was blocked at T10, since the last logon time for S1 before T10 was
at T5. Using the same process as before, the fourth row of MyLog identifies user G.
Some of the following example SQL queries use three temporary tables:
54
Table MYTEMPLOG_ONE to reduce the size of DBC.EventLog
Table MYTEMPLOG_TWO to reduce the size of MyLog
Utilities

Example Log Tables
Table MYTEMPLOG_THREE to hold a join of MYTEMPLOG_TWO with fields from

MYTEMPLOG_ONE, which identifies the blocked user
Using unusual table names avoids conflicts with permanent tables.
Reducing the Size of the Lock Log Table

The following SQL statements create a temporary table that contains a portion of MyLog.
The temporary table has databasename and tablename instead of internal IDs.
In the following example, begtime is the combination of begdate and begtime from MyLog.
This simplifies the comparison on date/time columns.
drop table "MYTEMPLOG_TWO";
ct "MYTEMPLOG_TWO"
(begdatetime
float format 'zzz,zzz,zzz,zzz.zzz' not null,
begdate
date
not null,
begtime
float format '99:99:99.999' not null,
delay
databasename
char(30) not null,
tablename
char(30) not null,
blkdloghost
smallint not null,
blkdsessno
integer
not null,
blkdlevel
char(8)
not null,
blkdmode
char(2)
not null,
blkingloghost
smallint not null,
blkingsessno
integer
not null,
blkinglevel
char(8)
not null,
blkingmode
char(2)
not null,
processor
smallint format 'zzzz9' not null,
deadlock
char(1)
not null,
multipleblocker char(1)
not null,
stmttype
varchar(20) not null)
primary index (begdate,begtime);
Reducing the Size of the DBC.EventLog Table

Similarly, the following SQL statements create a temporary table that contains a portion of
DBC.EventLog:
drop table "MYTEMPLOG_ONE";
ct "MYTEMPLOG_ONE"
(datefld
date not null,
timefld
logondatetime float format 'z,zzz,zzz,zzz,zzz.zzz' not null,
sessionno
integer not null,
logicalhostid smallint format 'zzz9' not null,
username
char(30) not null,
accountname
char(30) not null,
logonsource
varchar(128))
primary index (datefld,timefld);
Inserting Rows
The following SQL statements define a macro that inserts rows into the temporary tables. The
macro uses four parameters:
Utilities
55

Example Log Tables
t1date, t1time specifies that only the users logged on AFTER this time should be selected
from DBC.EventLog.
t2date, t2time specifies that only the blockages occurring BEFORE this time should be
selected from MyLog. This date and time should always be AFTER the date and time
specified by t1date, t1time.
Limiting the number of rows from DBC.EventLog before performing a join operation is very
important because DBC.EventLog could contain millions of rows if it is not purged frequently.
However, to ensure that you see all the rows from the lock log table, set the t1date, t1time
parameters early enough to catch all the logons of sessions that were active at any time while
dumplocklog was running (up until t2date, t2time). Therefore, if you have very long-lived
sessions, select a t1date, t1time farther back in time from t2date, t2time than you would have
selected if you knew all the sessions running were very short-lived.
Also, you could add other parameters to this macro to further limit the analysis. If, for
example, you are only interested in lock log table rows involving user Joe with account Joe1 in
some time range, you could add the following:
Parameters UserA Char(30) and AccountA Char(30) to the macro.
Conditions (UserName = :UserA) and (AccountName = :AccountA) to the INSERT ...

SELECT statement for table MYTEMPLOG_ONE.
Macro for Inserting Rows into Temporary Tables

replace macro LockBldTmp
(t1date
t1time
t2date
t2time
date,
float,
date,
float) as
(
/*******************************************************/
/* To get all of the rows from MyLog whose blocked
*/
/* begin time is less than t2date/time, join with
*/
/* DBC.TVM to get the table name from the table ID
*/
/* and with DBC.Dbase to get the database name from
*/
/* the database ID. A database level lock row has
*/
/* table name of ALL.
*/
/*******************************************************/
del from "MYTEMPLOG_TWO";
locking MyLog for access
locking dbc.dbase for access
locking dbc.tvm for access
ins into "MYTEMPLOG_TWO"

sel
(begdate*1000000+begtime) As TS,
begdate,
begtime,
delay,
coalesce(dbase.databasename,Unknown),
coalesce(tvm.tvmname,Unknown),
blkdloghost,
56
Utilities

Example Log Tables
blkdsessno,
blkdlevel, blkdmode,
blkingloghost,
blkingsessno,
blkinglevel,
blkingmode,
processor,
deadlock,
multipleblocker,
stmttype
from
MyLog L
Left Join dbc.tvm T
On L.tid = T.tvmid
Left Join dbc.dbase D
On L.dbid = D.databaseid
where
TS >= (:t1date*1000000 + :t1time)
And TS <= (:t2date*1000000 + :t2time)
/********************************************************/
/* Because DBC.EventLog may contain millions of rows, */
/* reduce it by getting only the rows that satisfy
*/
/* these conditions:
*/
/*
*/
/*
1. Event is logon.
*/
/*
2. Logon date/time is greater than t1date/time. */
/*
3. Logon date/time is less than or equal to time */
/*
of last (newest) entry in MyLog.
*/
/*
4. The sessionno and logicalhostid of the logon */
/*
is found in some row of MyLog as either
*/
/*
blkdsessno & blkdloghost or as blkgsessno &
*/
/*
blkingloghost.
*/
/********************************************************/
del from "MYTEMPLOG_ONE";
locking dbc.eventlog for access
ins into "MYTEMPLOG_ONE"
sel
datefld,
timefld,
(logondate*1000000+logontime)As LogonTS,
sessionno,
logicalhostid,
username,
accountname,
logonsource
from
dbc.eventlog
where (event = 'Logon') and
And LogonTS <= (Select max(begdatetime)
From "MYTEMPLOG_TWO")
And LogonTS >= (:t1date*1000000 +:t1time)
And ((sessionno, logicalhostid) in
(Select blkdsessno, blkdloghost
From "MYTEMPLOG_TWO")
Or (sessionno, logicalhostid) in
(Select blkingsessno, blkingloghost
From "MYTEMPLOG_TWO"));
/********************************************************/
/* Insert dummy rows for those sessions that are used */
/* by internal DBC system activities, such as cache
*/
/* management, space accounting, recovery, and so on. */
Utilities
57

Example Log Tables
/********************************************************/
('90/01/01',0,0,0,0,'SystemUser','SystemUser',
'SystemUser');
('90/01/01',0,0,1,0,'SystemAccounting',
'SystemAccounting','SystemAccounting');
('90/01/01',0,0,2,0,'SystemRecovery',
'SystemRecovery','SystemRecovery');
('90/01/01',0,0,3,0,'Archive/Recovery',
'Archive/Recovery','Archive/Recovery');
Determining the Blocked User

At this point, the number of rows in temporary tables MYTEMPLOG_ONE and
MYTEMPLOG_TWO should be small enough for the final statements to complete in a
reasonable time.
The remaining SQL query example uses MYTEMPLOG_ONE to determine the blocked
user for each row in the reduced lock log, MYTEMPLOG_TWO. The resulting joined rows
are placed in a global temporary table, named MYTEMPLOG_THREE which is then used
for a similar final join with MYTEMPLOG_ONE to determine the blocking user for each
row in the reduced lock log.
The following join conditions use a correlated subquery to select the maximum
logondatetime from MYTEMPLOG_ONE for a given begdatetime and logical host/session
number from MYTEMPLOG_TWO:
("MYTEMPLOG_ONE".logicalhostid
= "MYTEMPLOG_TWO".blkdloghost ) AND
("MYTEMPLOG_ONE".sessionno
= "MYTEMPLOG_TWO".blkdsessno ) AND
("MYTEMPLOG_ONE".logondatetime =
(SELECT MAX(ev3.logondatetime)
FROM "MYTEMPLOG_ONE" AS ev3
WHERE (ev3.logicalhostid
= "MYTEMPLOG_TWO".blkdloghost) AND
(ev3.sessionno
(ev3.logondatetime
< "MYTEMPLOG_TWO".begdatetime)
)
)
This results in a unique (possibly null, if no match on logical host/session number exists) row
from MYTEMPLOG_ONE for each row in MYTEMPLOG_TWO.
Using the sample rows described earlier:
= "MYTEMPLOG_TWO".blkdsessno )
returns:
58
Utilities

Example Log Tables
"MYTEMPLOG_TWO"
"MYTEMPLOG_ONE"
<T2,S1> X <T1,S1,A>, <T3,S1,C>, <T5,S1,D>, <T11,S1,F>
^^
^^
^^
^^
^^
<T4,S2> X <T2,S2,B>, <T9,S2,E>, <T20,S2,G>
^^
^^
^^
^^
<T10,S1> X <T1,S1,A>, <T3,S1,C>, <T5,S1,D>, <T11,S1,F>
^^
^^
^^
^^
^^
<T30,S2> X <T2,S2,B>, <T9,S2,E>, <T20,S2,G>
^^
^^
^^
^^
and:
(ev3.sessionno
(ev3.logondatetime
)
)
returns:
<T2,T1>, <T4,T2>, <T10,T5>, <T30,T20>
Hence, using the result from the correlated subquery above, we are able to identify the proper
users (A, B, D and G) for these rows:
<A> : <T2,S1><T1,S1,A> in <T2,T1>
^^
^^
^^ ^^
<B> : <T4,S2><T2,S2,B> in <T4,T2>
^^
^^
^^ ^^
<D> : <T10,S1><T5,S1,D> in <T10,T5>
^^^
^^
^^^ ^^
<G> : <T30,S2><T20,S2,G> in <T30,T20>
^^^
^^^
^^^ ^^^
The following two SQL statements create the global temporary table that contains the reduced
lock log information joined with the blocked user information:
DROP
TABLE "MYTEMPLOG_THREE";
CREATE GLOBAL TEMPORARY TABLE "MYTEMPLOG_THREE"
(
begdatetime
FLOAT
FORMAT 'zzz,zzz,zzz,zzz.zzz' NOT NULL,
begdate
DATE
NOT NULL,
begtime
FLOAT
FORMAT '99:99:99.999' NOT NULL,
delay
FLOAT
FORMAT '99:99:99.999' NOT NULL,
databasename
CHAR(30) NOT NULL,
tablename
CHAR(30) NOT NULL,
blkdlevel
CHAR(8)
NOT NULL,
blkdmode
CHAR(2)
NOT NULL,
blkdloghost
SMALLINT NOT NULL,
blkdusernm
CHAR(30) NOT NULL,
blkdsessno
INTEGER
NOT NULL,
blkdacctnm
CHAR(30) NOT NULL,
Utilities
59

Example Log Tables
blkdlogonsrc
blkinglevel
blkingmode
blkingloghost
blkingsessno
processor
FORMAT
deadlock
multipleblocker
stmttype
VARCHAR(128),
CHAR(8)
NOT NULL,
CHAR(2)
NOT NULL,
SMALLINT NOT NULL,
INTEGER
NOT NULL,
SMALLINT
'zzzz9' NOT NULL,
CHAR(1)
NOT NULL,
CHAR(1)
NOT NULL,
VARCHAR(20)
NOT NULL
)
PRIMARY INDEX (begdate, begtime);
The remainder of the SQL example demonstrates a macro that populates

MYTEMPLOG_THREE and then does a SELECT from it. The SELECT does another join
with MYTEMPLOG_ONE, providing the blocking user information and producing the final
report.
REPLACE MACRO LockDisplay AS
(
DELETE FROM "MYTEMPLOG_THREE";
/*
**
**
**
**
*/
Instantiate a local instance of the

MYTEMPLOG_THREE table template by
populating it with rows from MYTEMPLOG_TWO
joined with blocked user information
from MYTEMPLOG_ONE.
INSERT INTO "MYTEMPLOG_THREE"

SELECT
"MYTEMPLOG_TWO".begdatetime
, "MYTEMPLOG_TWO".begdate
, "MYTEMPLOG_TWO".begtime
, "MYTEMPLOG_TWO".delay
, "MYTEMPLOG_TWO".databasename
, "MYTEMPLOG_TWO".tablename
, "MYTEMPLOG_TWO".blkdlevel
, "MYTEMPLOG_TWO".blkdmode
, "MYTEMPLOG_TWO".blkdloghost
, COALESCE ("MYTEMPLOG_ONE".username, 'Unknown')
, "MYTEMPLOG_TWO".blkdsessno
, COALESCE ("MYTEMPLOG_ONE".accountname, 'Unknown')
, COALESCE ("MYTEMPLOG_ONE".logonsource, 'Unknown')
, "MYTEMPLOG_TWO".blkinglevel
, "MYTEMPLOG_TWO".blkingmode
, "MYTEMPLOG_TWO".blkingloghost
, "MYTEMPLOG_TWO".blkingsessno
, "MYTEMPLOG_TWO".processor
, "MYTEMPLOG_TWO".deadlock
, "MYTEMPLOG_TWO".multipleblocker
, "MYTEMPLOG_TWO".stmttype
FROM
"MYTEMPLOG_TWO"
LEFT OUTER JOIN
"MYTEMPLOG_ONE"
ON
60
Utilities

Example Log Tables
= "MYTEMPLOG_TWO".blkdloghost ) AND
(ev3.sessionno
(ev3.logondatetime
)
);
/*
**
**
**
**
*/
Now do the final select in a similar fashion,

filling in the user info for the blocking session.
But now we select from the global temporary table
instantiation instead of the reduced lock
log "MYTEMPLOG_TWO".
SELECT
"MYTEMPLOG_THREE".begdate
(NAMED RequestedDate)
(FORMAT 'YYYY/MM/DD')
(CHAR(10))
, "MYTEMPLOG_THREE".begtime
(NAMED RequestedTime)
(FORMAT '99:99:99')
(CHAR(8))
, "MYTEMPLOG_THREE".delay
(NAMED Delay)
(FORMAT '99:99:99.999')
(CHAR(12))
, "MYTEMPLOG_THREE".databasename
(NAMED DataBaseName)
, "MYTEMPLOG_THREE".tablename
(NAMED TableName)
, "MYTEMPLOG_THREE".blkdlevel
(NAMED BlockedLockLevel)
, "MYTEMPLOG_THREE".blkdmode
(NAMED BlockedLockMode)
, "MYTEMPLOG_THREE".blkdloghost
(NAMED BlockedHostId)
(FORMAT 'zzz9')
(CHAR(4))
, "MYTEMPLOG_THREE".blkdusernm
(NAMED BlockedUser)
, "MYTEMPLOG_THREE".blkdacctnm
(NAMED BlockedAccount)
, "MYTEMPLOG_THREE".blkdlogonsrc
(NAMED BlockedLogonSource)
, "MYTEMPLOG_THREE".blkinglevel
(NAMED BlockingLockLevel)
, "MYTEMPLOG_THREE".blkingmode
(NAMED BlockingLockMode)
, "MYTEMPLOG_THREE".blkingloghost
Utilities
61

Example Log Tables
(NAMED BlockingHostId)
(FORMAT 'zzz9')
(CHAR(4))
, coalesce("MYTEMPLOG_ONE".username,
'Unknown')
(NAMED BlockingUser)
(CHAR(30))
, coalesce("MYTEMPLOG_ONE".accountname, 'Unknown')
(NAMED BlockingAccount)
(CHAR(30))
, coalesce("MYTEMPLOG_ONE".logonsource, 'Unknown')
(NAMED BlockingLogonSource)
, "MYTEMPLOG_THREE".processor
(NAMED VProc)
(FORMAT 'zz9-9')(CHAR(5))
, "MYTEMPLOG_THREE".deadlock
(NAMED DeadLock)
, "MYTEMPLOG_THREE".multipleblocker
(NAMED MultipleBlockers)
, "MYTEMPLOG_THREE".stmttype
(NAMED StmtType)
FROM
"MYTEMPLOG_THREE"
LEFT OUTER JOIN

"MYTEMPLOG_ONE"
ON
="MYTEMPLOG_THREE".blkingloghost ) AND
= "MYTEMPLOG_THREE".blkingsessno ) AND
(SELECT max(ev4.logondatetime)
= "MYTEMPLOG_THREE".blkingloghost) AND
(ev4.sessionno
= "MYTEMPLOG_THREE".blkingsessno) AND
(ev4.logondatetime
< "MYTEMPLOG_THREE".begdatetime)
)
)
ORDER by 1,2;
);
/********************************************************/
/* To analyze the lock rows for users logged on after
*/
/* 6:30 a.m. on 92/01/02 and delays that occurred
*/
/* before 12:00 p.m. on 92/01/03:
*/
/*
*/
/* > EXEC LockBldTmp(920102,063000,920103,120000);
*/
/*
*/
/* > EXEC LockDisplay;
*/
/*
*/
/* To clean up the temporary tables:
*/
/*
*/
62
Utilities

Example Log Tables
/* > Drop table "MYTEMPLOG_TWO";
*/
/*
*/
/* > Drop table "MYTEMPLOG_ONE";
*/
/*
*/
/* > Drop table "MYTEMPLOG_THREE";
*/
/*
*/
/********************************************************/
Example
The following shows a sample output:
>dumplocklog
_______
|
|
___
|
/
|
--|
\___
__
|/
|
|
____
____|
/
|
\____|
|
|
____|
/
|
\____|
____
____|
/
|
\____|
|
__|__
|
|
|__
____
____|
/
|
\____|
Release 14.00.00.00 Version 14.00.00.00

DUMP LOCK LOG Utility (Dec 98)
This utility writes lock log entries in memory to an user specified table.
Enter your logon string: <username,password> (Q/q to quit)
dbc,dbc
Do you want this utility to run continuously? (Y/N)
n
Enter number of sessions (? For Help, Q/q to Quit):
2
2 sessions will be logged on.
Enter the table name where the lock log entries will be written (? For Help, Q/q to Quit):
dmo.locklog
Do you want this utility to create table DMO.LOCKLOG? (Y/N)
y
Table DMO.LOCKLOG has been created.
Enter the time constraint to control selection of lock log entries that were generated AT
or LATER than this time YYMMDD HHMMSS (? For Help, Q/q to Quit):
970701 130000
Enter the time constraint to control selection of lock log entries that were generated AT
or PRIOR to this time YYMMDD HHMMSS (? For Help, Q/q to Quit):
970701 140000
Utilities
63

Lock Logger Messages
Enter the object constraint for selection of lock log entries (? For Help, Q/q to Quit):
?
Specify the database objects for which lock delay should be selected. Up to 10 objects can
be entered. Input ceases when an empty line or 10 objects have been entered.
- <name1>.<name2> - name1 specifies a database and name2 specifies a table.
- <name>.*
- name specifies a database and all tables under it.
- <name1>
- name specifies a table under the user name specified in the logon.
- *
- All databases and tables.
- <Return>
- Done.
- Q
- Terminate the utility.
Note that if database or table name is specified, it has to exist or an error will be
returned.
Enter the object constraint for selection of lock log entries (? For Help, Q/q to Quit):
dmo.*
more?
(? For Help, <Ret> for Done):
Writing lock log entries to table DMO.LOCKLOG.

Press <F1> to interrupt the utility.
0 row has been inserted to table DMO.LOCKLOG.
*** DumpLockLog is terminated ***
Ready;

The following table contains Lock Logger messages and their descriptions.
64
Message
Description
"x rows have been inserted..."
In CONTINUOUS mode, 1,000 additional rows

have been generated and inserted into the target
table.
"*** Warning - some lock log

entries have been lost from
processor due to buffer
overflow"
In CONTINUOUS mode, some vprocs failed to

insert all rows into the table because the holding
buffer overflowed.
Utilities

Utilities
Message
Description
"No rows inserted"
In SNAPSHOT mode, the user has decided to

terminate before entering all the data that Lock
Logger requires to run, or Lock Logger terminated
abnormally.
"No rows have been inserted to

table"
In SNAPSHOT mode, this means a normal

termination of the Lock Logger in which no rows
were observed, that is, no locking contention
within given parameters of the user.
"1 row has been inserted to

table"
In SNAPSHOT mode, one single row was found

and inserted successfully into the table.
"%s rows have been inserted to

table"
In SNAPSHOT mode, more than one row was

found and inserted successfully to the table.
"*** DumpLockLog is terminated

***"
In SNAPSHOT mode, this appears preceding a

normal termination.
"Utility is about to be
terminated..."
In CONTINUOUS mode, this appears after the

user presses <F2> to terminate Lock Logger.
"Utility resumes..."
In CONTINUOUS mode, this appears after the

user presses any key (usually the CTRL key) other
than F2.
65

66
Utilities
CHAPTER 20
Modify MPP List (modmpplist)
The Modify MPP List utility, modmpplist, is an interactive utility that allows you to modify
the node list file (by default, named mpplist).
Modify MPP List can read the list from the Teradata Configuration directory, and can create
or modify a copy of the list in another location.
When you must shut down a node for hardware maintenance, you can use modmpplist to
place the node into an offline state, and to distribute the revised MPP list file on the Teradata
Database system. If you use modmpplist to take a node offline, you must use modmpplist to
bring the node back online.
Runs From
Modify MPP List runs from the Linux command line.
Starting the Utilities.
Syntax
modmpplist
-h
-m file_path
1102A165
Syntax Element
Description
-h
Displays general help for modmpplist.
-m file_path
Causes modmpplist to read settings from a specified local file in a

location other than the default.
Note: The local file specified with the -m option can be in any
directory and have any name.
Utilities
67
Chapter 20: Modify MPP List (modmpplist)

Usage Notes
Usage Notes
By default, modmpplist reads from and writes to the standard mpplist file: /etc/opt/teradata/
tdconfig/mpplist.
To read from a different file, use the -m option of modmpplist.
To write changed settings to a different file, use the -w option of the write command. For
more information, see WRITE on page 76.
Example 1
The following example shows how to start modmpplist to edit the default mpplist. Note the
minus sign prefacing the offline node in the output from the list command.
>modmpplist
reading default mpplist, /etc/opt/teradata/tdconfig/mpplist...
0:pdetnt5_bynet
3:pdetnt8_bynet
1:pdetnt6_bynet
2:pdetnt7_bynet
all 4 nodes are online.

mpp> off 1
1 node is offline.
(Buffer has been Modified since last read)
mpp> list
0:pdetnt5_bynet
-1:pdetnt6_bynet
2:pdetnt7_bynet
3:pdetnt8_bynet
1 node is offline.
mpp> display
# This file is generated by PUT. Please do not
# edit it manually. Note a # or a space character in
# the first column on a line causes the entire line to
# be ignored. Field delimiter must be space character.
# node
tpa
nodeid
status
#----------------------------------------------------pdetnt5_bynet
yes
43
yes
pdetnt6_bynet
yes
44
no
pdetnt7_bynet
yes
45
yes
pdetnt8_bynet
yes
46
yes
mpp> write
Do you really want to distribute mpplist file (yes|no) ? [no] yes
All 4 node(s) have connected
MODE
SIZE
INODE USER
GROUP
FILE
-rw-r--r-369
14575 <anon>
<anon>
D:\TEMP\2\mpplist
pdetnt5_bynet:1924: send completed: 485 bytes received (1 files/0
directories)
directories)
directories)
68
Utilities

Modify MPP List Commands
directories)
Wrote and distributed mpplist to 4 nodes successfully.
mpp> quit
Example 2
The following example shows how to start modmpplist to edit a user-specified mpplist file
named mympplist. Note that after writing to the local file, modmpplist will still ask if you want
to save the mpplist file. This refers to the default mpplist file. If you are just working with a
local file, with no desire to change the mpplist settings on all nodes, respond no to this
message.
>modmpplist -m mylist
reading users mpplist, mylist ...
0:pdetnt5_bynet
3:pdetnt8_bynet
1:pdetnt6_bynet
2:pdetnt7_bynet

mpp> off 2
1 node is offline.
mpp> list
0:pdetnt5_bynet
1:pdetnt6_bynet
-2:pdetnt7_bynet
3:pdetnt8_bynet
1 node is offline.
mpp> write -w mylist
Do you want to write mpplist to 'mylist' on a local node (yes|no) ? [no]
yes
Wrote mpplist buffer to 'mylist' file
mpp> quit
You have changed a value. Do you wish to save the mpplist file? (yes|no)
[no]
no

The following table lists the commands available from within the modmpplist session (that is,
from the mpp> prompt).
Utilities
Command
Description
DISPLAY
Outputs the current mpplist buffer as it would appear in file format to

the STDOUT file.
69

Command
Description
LIST
Outputs the list of node names, their unique node IDs, and the status
of nodes in the current mpplist buffer to the STDOUT file.
OFF id_list
Changes the status of the IDs in the space-separated list to NO

(offline).
ON id_list
Changes the status of the IDs in the space-separated list to YES

(online).
QUIT
Causes modmpplist to quit the interactive session.
WRITE
Forces the mpplist file to be written out to all nodes in the MPP system.
!COMMAND
Runs a Teradata Database or operating system command from within

the modmpplist session.
The modmpplist commands are discussed in detail in the following sections.
70
Utilities

DISPLAY
DISPLAY
Purpose
The DISPLAY command outputs the current mpplist buffer as it would appear in file format
to the STDOUT file.
Syntax
DISPLAY
D
1102A026
Utilities
71

LIST
LIST
Purpose
The LIST command outputs the list of node names, their unique node IDs, and the status of
nodes in the current mpplist buffer to the STDOUT file.
Syntax
LIST
L
1102A027
Usage Notes
The list shows the nodes in the following format:
IndexId:nodename
nodestatus
Component...
Specifies...
IndexId
an arbitrary index number starting from 0 to N-1, where N is the number

of nodes in the mpplist file.
nodename
the name of a node.
nodestatus
displays the number of nodes currently online.
Note: If a node is offline, the node appears with a dash (or minus sign) in front of the IndexID
in the mpplist as shown below:
-IndexId:nodename
If a node is online, the dash does not appear.
Example
The following example lists the status and ID of the nodes.
mpp> l
0:pdetnt5_bynet
1:pdetnt6_bynet
2:pdetnt7_bynet
3:pdetnt8_bynet
72
Utilities

OFF id_list
OFF id_list
Purpose
The OFF id_list command changes the status of the IDs in the space-separated list to NO
(offline).
Syntax
OFF id_list
1102A028
Syntax element...
Specifies...
id_list
list of node IDs.
Example
The following example changes node 2 to offline.
mpp> off 2
1 node is offline.
Utilities
73

ON id_list
ON id_list
Purpose
The ON id_list command changes the status of the IDs in the space-separated list to YES
(online).
Syntax
ON id_list
1102A029
Syntax element...
Specifies...
id_list
list of node IDs.
Example
The following example changes node 3 to online.
mpp> on 3
74
Utilities

QUIT
QUIT
Purpose
The QUIT command causes modmpplist to quit the interactive session.
Syntax
QUIT
Q
1102A216
Usage Notes
If you modify the mpplist file, but you did not issue a WRITE command, you are asked if you
want to write the current mpplist buffer to all available nodes. The default is NO.
If you just press RETURN, the session exits.
If you type Y (YES) at the prompt, the current mpplist buffer is written, and then the
session exits.
Example 1
The following example quits modmpplist if you just press RETURN.
mpp> quit
You have changed a value. Do you wish to save the mpplist file? (yes|no)
[no]
Example 2
The following example quits modmpplist if you type Y (YES) to the prompt.
mpp> quit
You have changed a value. Do you wish to save the mpplist file? (yes|no) [no]
y
All 1 node(s) have connected
MODE
SIZE
INODE USER
GROUP
FILE
-rw-r--r-375
54206 <anon>
<anon>
/etc/opt/teradata/tdconfig/mpplist
localhost:1043: send completed: 444 bytes received (1 files/0 directories)
Wrote and distributed mpplist to 1 node successfully.
Utilities
75

WRITE
WRITE
Purpose
The WRITE command forces the mpplist file to be written out to all nodes in the MPP system.
Syntax
WRITE
W
-w file_path
-y
1102B030
Syntax element...
Specifies...
-w file_path
to write the modified mpplist settings to a file on the local node only.
This option allows you to save changes to the local node when a remote copy
fails.
If you specify a directory path only, then the file mpplist is written to that
directory.
If you specify a path and file, then the file specified is written to the path
specified.
If you specify a file name alone, then that file is written to the current
working directory.
-y
to skip the confirmation message.
Example
The following example bypasses the prompt and writes the mpplist file to all live nodes.
76
Utilities

Running External Commands

To run a Teradata Database or operating system command from within a modmpplist session,
preface the command with an exclamation mark (!).
Syntax
!COMMAND
1102A031
Syntax element...
Specifies...
COMMAND
a Teradata Database or operating system command.
Example
The following example runs the dir operating system command, which shows a directory
listing.
mpp> !ls /
bin boot dev etc home lib lib64 log lost+found master.src media
mnt opt pkgs proc root sbin srv sys tdsh tmp tms usr var
Utilities
77

78
Utilities
CHAPTER 21
Priority Scheduler (schmon)

(SLES 10 only)
Priority Scheduler is a workload-management facility that controls access to system resources

by the different active jobs in Teradata Database. It allows administrators to define different
priorities for different categories of work, and comes with a number of flexible options.
Note: The information in this chapter applies only to Teradata Database systems running on
SUSE Linux Enterprise Server (SLES) 10. On SLES 11 systems, Priority Scheduler is managed
by Teradata Active System Management (ASM), and is configured and monitored using the
Teradata Viewpoint workload management portlets. For more information on those portlets,
see Teradata Viewpoint User Guide.
Priority Scheduler does the following:
Allows you to define a prioritized weighting system based on user logon characteristics,
and on Workload Definition (Category 3) rules set in the Teradata Viewpoint Workload
Designer portlet.
Prioritizes the workload in your data warehouse based on this weighting system.
Offers utilities to define scheduling parameters and to monitor your current system
activity.
Priority Scheduler includes default parameters that provide four priority levels with all users
assigned to one level. To take advantage of Priority Scheduler capabilities, do the following:
Assign users to more than one of the default priority levels based on your work priority
strategy.
Define additional priority levels and assign users to them to provide a more sophisticated
priority strategy.
Assign very high priority users to a very high priority level to support Active Data
Warehouse applications.
The first part of this chapter generally describes the structure and relationships of the
scheduling components and parameters. The second part describes schmon, a command-line
interface to Priority Scheduler. For detailed information, see Schmon Utility (schmon) (SLES
10 only) on page 103.
Note: If Workload Definitions have been set in the Teradata Viewpoint Workload Designer
portlet, schmon cannot be used to make changes to Priority Scheduler.
Utilities
79
Chapter 21: Priority Scheduler (schmon) (SLES 10 only)

Overview
Overview
Priority Scheduler consists of the following three-tiered control structure to group user
sessions for scheduling purposes:
Resource Partition
Performance Group
Allocation Group
Each of these components includes parameters that relate them to each other. You define and
associate these components to design an environment that favors or inhibits the performance
of individual sessions based on their logon account attributes.
The following figure shows the hierarchical structure of Priority Scheduler.
Hierarchy of Components of One Resource Partition

Resource
Partition
Weight
CPU Limit
Performance
Period
1:M
1:M
Performance
Group
Milestone Limit
Allocation Group
Milestone Type
1:1
Allocation
Group
1:M = one to many

1:1 = one to one
Type
Weight
1102E421
The following table briefly summarizes the components of Priority Scheduler.
80
Utilities

Overview
Component
Descriptions
Resource Partition
A Resource Partition is a collection of prioritized Performance

Groups.
A Resource Partition carries a weight that will be compared to other
Resource Partition weights.
A Resource Partition can limit the total amount of CPU used by
sessions assigned to its Performance Groups.
Priority Scheduler provides Resource Partition zero as the default
partition.
You can define four additional Resource Partitions.
Performance Group
You define Performance Groups within each additional Resource

Partition.
The Performance Group name matches an entry in the account ID
string, which is used for logons and stored in the AccountName
column of the user record in the data dictionary. Each Performance
Group name must be unique.
Performance Period
You must define at least one Performance Period, but you can have
up to eight Performance Periods per Performance Group.
A Performance Period links a Performance Group to an Allocation
Group.
Optionally, a Performance Period allows you to change Allocation
Group assignments based on time-of-day or resource usage.
Allocation Group
An Allocation Group carries a weight that will be compared to other

Allocation Group weights.
An Allocation Group can limit the total amount of CPU used by
sessions under its control.
Several Performance Groups within a single Resource Partition
might share the same Allocation Group.
Every Teradata Database logon session is assigned to a Performance Group. Performance

Groups control the prioritization of jobs started by sessions under their control. When a
Performance Group is defined, it is assigned to a Resource Partition.
Each Resource Partition has a weight that determines the proportion of resources available
to it relative to the other defined Resource Partitions. More resources are made available to
Resource Partitions with higher weights. These weights participate in determining the
priorities of Teradata Database jobs.
Allocation Groups are also associated with Performance Groups. Like Resource Partitions,
Allocation Groups have weights that determine the proportion of resources allocated to jobs
under their control, relative to the other Allocation Groups that are active within the same
Resource Partition.
The combination of Resource Partition and Allocation Group parameters, acting through
their common Performance Groups, determines the precise priorities of jobs running on
Teradata Database.
Utilities
81

Using Priority Scheduler
Each Performance Group is associated with one Allocation Group at any time, however, as an
option, a Performance Group's Allocation Group can change as system conditions change.
Consequently, the jobs controlled by a Performance Group may have different priorities
assigned to them at different times, and their priorities can change as the jobs run.
The association between a Performance Group and an Allocation Group is mediated by the
Performance Group's Performance Periods. Performance Periods link Performance Groups to
Allocation Groups. As an option, the Allocation Group associated with a Performance group
can be dynamically changed based on current resource usage or time of day. A Performance
Group can define from one to eight Performance Periods, however the most common
approach is to define only a single Performance Period per Performance Group.
For more information on Priority Scheduler components, see the following:
Resource Partitions on page 83
Performance Groups on page 85
Performance Periods on page 88
Allocation Groups on page 93
To configure Priority Scheduler, see Schmon Utility (schmon) (SLES 10 only) on page 103.
Using Priority Scheduler

Priority Scheduler can do the following for you:
Provide better service for your more important work
Control resource sharing among different applications
Automate changes in priority by time of day or by amount of CPU used
Place a ceiling on Teradata Database system resources for specific applications
When using Priority Scheduler, keep the following in mind:
82
Start out simple, monitor, and build from there.
You can change parameters at any time using the schmon utility.
Any changes you make to any parameter, including weight, take place immediately across
all nodes in the configuration.
You can delete the definitions of unused Resource Partitions, Performance Groups, and
Allocation Groups using a Teradata Database system utility like schmon. The element that
you want to delete cannot be in use when you perform the deletion. This means that an
Allocation Group or Resource Partition must not be referenced by a Performance Group,
and a Performance Group must not be referenced by a currently logged on user.
You can change the name of a defined but unused Resource Partition or Performance
Group to make it obvious it is unused. For example, you might name the unused Resource
Partition or Performance Group UNUSED or NULL.
Utilities

Resource Partitions
Resource Partitions
Resource Partitions divide the Teradata Database users into groups based on some use or
priority strategy, such as by subject area or type of work.
Priority Scheduler provides you with a default Resource Partition named Default. You can
create up to four more Resource Partitions. The default Resource Partition has a default
partition weight of 100 and has four Performance Groups accessible by users. You can define
additional Performance Groups in the default Resource Partition.
The following table presents a logical view of Resource Partition 0.
Performance group...
has a weight of...
L (low)
5.
M (medium)
10.
H (high)
20.
R (rush)
40.
Resources are distributed to the Teradata Database system sessions that specify a Performance
Group within a Resource Partition. The parameters associated with the Performance Groups
and Allocations Groups of a Resource Partition control this resource allocation.
For detailed information, see the following:
Performance Groups on page 85
Allocation Groups on page 93
Resource Partition Parameters

You can define up to a maximum of four additional Resource Partitions. The following table
briefly describes the parameters of a Resource Partition.
Utilities
Parameter
Description
ID
An integer from 0 through 4 that identifies the Resource Partition.

Priority Scheduler provides resource partition 0 as the default
partition.
Resource Partition Name
A unique name for the Resource Partition. The name can contain no
more than 16 characters.
Weight
An integer value that is converted into a relative weight at execution

time. The relative weight determines the proportion of Teradata
Database system resources the Resource Partition will receive.
83

Resource Partitions
Parameter
Description
Limit
An optional number from one through 100 that specifies a percentage

limit on the total CPU usage. This limit will be applied to sessions
assigned to the Performance Groups associated with the Resource
Partition.
Determining the Relative Weight of a Resource Partition

Assigned Resource Partition weights are transformed into relative weights, based on the
weights of the currently active resource partitions. Dividing the weight of a Resource Partition
by the sum of the weights of all active resource partitions gives the percentage of total Teradata
Database system resources that will be made available to that Resource Partition. This
percentage is neither a guarantee or a limit on the amount of Resource a Partition will receive.
This percentage is the proportion of resource the Resource Partition will be offered relative to
other partitions.
Suppose three Resource Partitions are active. Their respective weights are shown in the
following table.
Resource Partition...
Has a weight of...
10.
20.
30.
To determine the relative weight of each Resource Partition, do the following:

1
Add the individual respective weights of the active Resource Partitions (10 + 20 + 30) for a
sum of 60.
Divide each respective weight (10, 20, and 30) by the sum of 60.
The relative weight for each partition is as follows:
Partition 1 = 16%
Partition 2 = 33%
Partition 3 = 50%
Note: The relative weight for Resource Partition 1 is 16%, rather than 17%, because
Teradata Database truncates fractional values when doing relative weight calculations.
Limiting Resource Partition CPU Usage

Optionally, you can limit a Resource Partition to a specified percentage of CPU resource
usage. This CPU limit has no affect on the scheduling strategy defined by other Priority
Scheduler parameters. The relative weights of Allocation Groups and Resource Partitions are
observed.
84
Utilities

Performance Groups
The normal distribution of resources prevails within the specified amount of CPU usage. Any
other CPU resource limits defined by a Teradata Database system CPU limit are observed.
Suggested Resource Partition Setup

The following list shows a simple approach to Resource Partition setup.
1
Leave the default Resource Partition for internal work.
Assign user work to other Resource Partitions.
Group applications by the importance of the work.
The following table shows a simple example of this approach.

Resource Partition...
Has a weight of...
And is used for...
20
internal work and tools
60
tactical queries.
These are short, highly-tuned queries that facilitate
decision-making in a time-sensitive environment.
20
everything else.
Performance Groups
Every request is assigned to a Performance Group (PG) based on the session logon process and
by Teradata Active System Management (ASM), if enabled. PGs determine the priorities of
Teradata Database jobs (mostly database queries) that are run from the session. Each PG is
associated with a Resource Partition and one or more Allocation Groups. It is the interaction
of Resource Partition and Allocation Group weights that determines the priority of jobs that
are run from a particular Teradata Database session.
Allocation Groups are dynamically assigned to Performance Groups according to
relationships defined by Performance Periods. The specific Allocation Group associated with a
Performance Group can change based on the time of day or the resource usage of running
jobs. Performance Periods define which Allocation Group is assigned to a Performance Group
at any moment based on these conditions.
For more information on Performance Periods, see Performance Periods on page 88. For
more information on Allocation Groups, see Allocation Groups on page 93.
The Resource Partition and Performance Periods of a Performance Group are specified when
the PG is created using the schmon -p command. The following table briefly describes the
parameters used to define a Performance Group. For more information on the schmon -p
command, seeschmon -p on page 140.
Utilities
85

Performance Groups
Parameter
Description
Performance Group ID
An integer from 0 through 249.

Note: Priority Scheduler provides four predefined Performance
Groups, having IDs 0 through 3. These Performance Groups are
associated with Resource Partition 0.
Performance Group Name
The name of the Performance Group that allows it to be assigned

to a session. For more information, see Performance Group
Names on page 86.
Resource Partition ID
An integer from 0 through 4 that identifies the Resource Partition

owning the Performance Group. For more information, see
Resource Partitions on page 83.
Performance Period Type
A code that indicates the type of milestone limits used to define

Performance Periods. All Performance Periods of a Performance
Group will be the same type. For more information, see
Performance Period Types and Limits on page 89.
Performance Periods
Specifications for one to eight Performance Periods. Each period is

defined by a milestone limit and an Allocation Group identifier.
You can express milestone limits in the following units:
Time-of-day
Session resource usage
Query resource usage
Performance Group Names

Performance Group names must be unique and not longer than 16 characters. Use names that
represent the type of work performed in each group, or that relate the groups to their
associated Resource Partitions.
Priority Scheduler provides four predefined Performance Groups, L, M, H, and R, within
default Resource Partition 0. These groups correspond to low, medium, high, and rush, and
determine the priorities given to jobs started under the control of sessions associated with
these PGs.
The following table lists the predefined Performance Groups for default Resource Partition 0.
The weights listed are those of the Allocation Group associated with each Performance Group.
Each predefined Performance Group doubles the weight assigned to the previous lowervalued Performance Group. These weights are used when assigning priorities to jobs running
under each Performance Group. For more information on Allocation Groups, see Allocation
Groups on page 93.
86
Utilities

Performance Groups
Default Performance Group
Default Weight
10
20
40
Assigning Performance Groups to Users

When a user logs on to the system, the session is assigned to a Performance Group that
determines the priority of session jobs. Generally, each user has access to a limited subset of
Performance Groups. This subset is listed in the users account ID string, which is specified as
part of the CREATE USER and MODIFY USER statements. The entire account ID string is
limited to 30 characters, and stored in the Teradata DatabaseData Dictionary.
The following rules apply to formatting Performance Group names in account ID strings:
Use apostrophes to delimit each PG name.
Immediately preface each name with a dollar sign ($).
Names longer than a single character require terminating dollar signs. Single-character
names do not require the terminal $, but may include it.
Because the entire account ID string is limited to 30 characters, try to keep PG names
brief.
Note: The Teradata Database enforces other rules for the length and format of account ID
strings, which may influence the choice of Performance Group names. For more information
on CREATE USER, MODIFY USER, and the Data Dictionary, see the books SQL Data
Definition Language and Data Dictionary.
The following are examples of valid Performance Group names that might appear in an
account ID string for a user granted access to five Performance Groups:
$L,'$L1$',$M$,$M2$',$tac1$
Assigning Performance Groups to Logon Sessions

Every logon session is assigned to a Performance Group, which determines the priority of jobs
started during that session. Users can specify one of their assigned Performance Groups when
they log on to Teradata Database. If no Performance Groups are specified during logon, the
session defaults to the pre-defined Performance Group M in Resource Partition 0.
The following example shows a user logging on to Teradata Database and specifying the M2
Performance Group:
.logon testdb/itbatch, cab,'$M2$'
The following table describes how Teradata Database assigns Performance Groups to sessions
during the logon process.
Utilities
87

Performance Periods
IF...
THEN...
the logon command includes a Performance

Group name matching one of the PGs assigned
to the user
the session is assigned to the specified PG.
the logon command does not include a

Performance Group name
the session is assigned to the first Performance

Group specified in the users account ID string.
If no PG is specified in the account ID string, the
session defaults to Performance Group M.

Group name that is not specified in the account
ID string portion of the user record)
logon fails.

Group that is specified in the users account ID
string, but that has not yet been created using
the schmon -p command
the session defaults to Performance Group M.
Performance Periods
Performance Periods associate Performance Groups with Allocation Groups. A Performance
Period is a value pair that specifies a limit condition (milestone) and an Allocation Group.
Performance Periods are specified when Performance Groups are defined. Each Performance
Group can specify from one to eight Performance Periods. For more information on defining
Performance Groups, see schmon -p on page 140.
Every request is assigned to a Performance Group based on the logon process and by Teradata
ASM, if enabled. The Performance Group controls how resources are allocated to session
tasks, by means of Performance Periods. Performance Periods determine which Allocation
Groups govern tasks, based on time and resource criteria. A task assigned to a particular
Performance Group can be switched among different Allocation Groups based on the criteria
defined in the Performance Group's Performance Periods
Performance Groups typically have only a single Performance Period. This is the case for the
default Performance Groups in the default Resource Partition. Sessions controlled by these
Performance Groups will have their resource allocation determined by a single Allocation
Group.
Optionally, Performance Groups can have more than one Performance Period. When this is
the case, sessions controlled by these Performance Groups can have their Allocation Group
dynamically changed as system conditions change. Consequently, tasks running in those
sessions may be assigned different priorities as those tasks run.
88
Utilities

Performance Periods
Performance Period Components

The following table describes the components of a Performance Period.
Component...
Defines the...
Milestone Type
type of threshold used to define each Performance Period for a

Performance Group. You can express types in the following units:
Time-of-day (T)
Session resource usage (S or R)
Query resource usage (Q)
For more information, see Performance Period Types and Limits on
page 89.
Milestone Limit
value of the threshold used to change Performance Periods for a

Performance Group. You can express this value in the following units:
A valid time-of-day, such as 0800 for 8:00 a.m.
A number of seconds of CPU usage.
For more information, see Performance Period Types and Limits on
page 89.
Allocation Group
number of the Allocation Group used to control sessions during this

Performance Period.
For more information, see Allocation Groups on page 93.
The following sections describe milestone limits and Allocation Groups.
Performance Period Types and Limits

A Performance Group definition specifies the type of Performance Periods the group will use.
If a Performance Group has multiple Performance Periods, they must all be the same type.
There are three types of Performance Periods, based on the types of milestones they monitor:
Query resource Performance Periods monitor the accumulated CPU time used by each
query. When the threshold for the Performance Period is exceeded, the query is transferred
to the next Performance Period and so placed under the control of a different Allocation
Group. Typically, long-running queries are switched to progressively lower priority
Allocation Groups. This prevents these queries from competing against the shorterrunning queries in higher priority Allocation Groups.
Note: Teradata recommends that query resource Performance Periods not be used with
online components of Teradata Applications, such as Demand Change Management
(DCM) and Customer Relationship Management (CRM). This prevents tactical online
queries, which require quick responses, from being demoted.
Utilities
89

Performance Periods
Session resource Performance Periods monitor the accumulated CPU time used by each
session. When the threshold for the Performance Period is exceeded, the session is
transferred to the next Performance Period, and the tasks belonging to that session are
placed under the control of a different Allocation Group. Typically, the change is to a
lower- priority Allocation Group. Consequently access to resources will be progressively
reduced for longer-running sessions.
Time-of-day Performance Periods monitor the clock time, and optionally the day of the
week. These types of Performance Periods are used to dynamically switch the Allocation
Group of a session based on changes in business priority of different work at different
times of day. For example, a session can be switched to a higher-priority Allocation Group
after business hours or on weekends, when competition for database resources is not high.
All Performance Period monitoring occurs on a per-node basis.

Note: Each Performance Group can specify only a single Performance Period type. All
Performance Periods defined for a Performance Group must use the same milestone units.
If a Performance Group uses only one Performance Period, the type is irrelevant because
sessions assigned to that Performance Group will remain under the control of the single
Allocation Group specified by the Performance Period.
The following table shows the relationship between Performance Period types and milestone
limit units.
Performance Period Type
Milestone Limit Units
Query resource usage
Seconds to hundredths of seconds, representing an amount of

query CPU resource consumption per node. For example, .02.
Session resource usage
Seconds to hundredths of seconds, representing an amount of

session CPU resource consumption per node. For example, 300.
Time-of-day
Minutes of military time, representing time periods during a 24hour day. For example, 0800 is 8:00 A.M.
Resource Usage Milestones

When milestone limits are expressed in units of query or session resource usage, these limits
apply to the total resource usage of all tasks working on behalf of a query or session on a node.
If multiple Performance Periods are defined for a Performance Group, the specified resource
usage milestone value is an upper limit. When a query or session under the control of a
Performance Group exceeds the limit defined for the current Performance Period, the
Performance Period with the next-higher limit and its associated Allocation Group take
control.
The following command defines a Performance Group with two Performance Periods. For
more information on defining Performance Groups, see schmon -p on page 140.
schmon -p 10 H1 1 Q 15 9 0 33
90
Utilities

Performance Periods
When a query under that control of Performance Group10 begins executing, all of its tasks
will be under the control of Allocation Group 9 until 15 seconds of CPU time are used by the
query on the node. At that time, Allocation Group 33 assumes control of the query until the
query completes.
Note: The time to accumulate 10 seconds of CPU time might be different from 10 seconds of
wall clock time.
Time-of-Day Milestones
When you express milestone limits in units of time-of-day, the respective Performance Period
and its associated Allocation Group control every task assigned to the Performance Group, up
until the time specified in that Performance Period.
The actual time-of-day selected for the Performance Periods represents an upper limit of time.
When this threshold is passed, the Performance Period with the next higher time-of-day and
its associated Allocation Group take control. This Performance Period will change as the day
proceeds through the 24-hour cycle. When the last-specified Performance Period expires, the
first Performance Period and its Allocation Group take control of the tasks assigned to the
Performance Group.
Suppose you rely on a window of time at night to perform batch work. To keep your query
users from interfering with night work without shutting them out completely, do the
following:
1
Between 8:00 a.m. and 5:00 p.m., give the query users an assigned weight of 20.
Between 5:00 p.m. and 11:00 p.m., reduce the assigned weight to 10.
Between 11:00 p.m. and 8:00 a.m., further reduce the assigned weight to 5.
At the same time, you can increase the weighting of any batch work. Suppose you raise the
assigned weight of the batch work Performance Group from 5 to 30 between 11:00 p.m. and
8:00 a.m. In doing so, you have helped the important batch work to finish, even if users issue
queries after hours.
Day-of-Week
Optionally, you can use a day-of-week specification with a time-of-day milestone for a
Performance Period to indicate days when the Performance Period is to be active. This
specification might indicate one or more individual days, or a range of days, but not both.
Days are numbered sequentially from 0 to 6, Sunday through Saturday. A range of days is
indicated by two day numbers separated by a hyphen.
If a day-of-week specification is present for one Performance Period, then day-of-week must
be present for all.
A time-of-day milestone for a Performance Period defines the end of a time period during
which the associated Allocation Group is to control tasks. The beginning of each period is the
end of the preceding period. This might be on a previous day if day of week has been specified.
Utilities
91

Performance Periods
If you do not use a day-of-week specification, then the specified periods apply to all days. In
this case, the beginning of the first period is the end of the last period of the day. You might
specify one period to define the Allocation Group to be used for the entire day. The milestone
time given for this period is immaterial but must be a valid time.
Suppose you want to provide different levels of service on weekdays, Saturday, and Sunday.
On weekdays, one Performance Period is in effect between 0800 and 1800, another beginning
at 1800 and continuing until 0800 the next morning.
On Saturday the Performance Period from 1800 on Friday continues until 1400 and then
switches to another Performance Period that continues through Sunday and on until 0800
Monday morning. The Performance Period specification is as follows, where day of the week is
denoted by enclosing / characters:
/1/ 0800 5 Monday, use AG 5 until 0800
/2-5/ 0900 7 Tuesday through Friday, use AG 7 until 0900
/1-5/ 1800 2 Monday through Friday, use AG 2 until 1800. After 1800, use the next higher
period.
/6/ 1400 7 Saturday, use AG 7 until 1400. After 1400, use the next Performance Period,
which is the one specified for 0800 Monday that uses AG 5.
Note: If the Time Zone (TZ) is not set correctly, Priority Scheduler will not work as expected.
To view the TZ see the files in the /user/lib64 directory and the man pages for zic and environ.
If the Time Zone is changed, the current Priority Scheduler settings should be dumped (using
the schmon -c command) and re-executed after PDE comes up so that the limit values in the
system gdo are correct.
Using cron With Priority Scheduler

Using cron or a similar scheduler program to issue schmon commands at specific times adds
flexibility in controlling how work is prioritized by Teradata Database.
Time-of-day milestones allow you to change priorities at specific times of day and on specific
days of the week. However, if a Performance Group uses time-of-day milestones, CPU
resource utilization (query milestones) cannot also be considered when adjusting the priority
of work controlled by that Performance Group. Using a scheduling program to run schmon at
specific times allows both time and CPU resources to be considered when work is prioritized.
One strategy is to define all Performance Groups to use only CPU resource usage (session or
query) milestone types, and use cron jobs to additionally adjust priorities based on times of
day, irrespective of CPU resources.
An additional benefit of using cron with Priority Scheduler is that this technique allows you to
change any of the Priority Scheduler settings on a regular basis. For example, you might run
schmon -b regularly to adjust the relative weights or CPU limits of different Resource
Partitions to match the typical usage patterns of your database. Whereas Performance Groups
determine the prioritization of individual jobs, changes to a Resource Partition affect all jobs
assigned to its Performance Groups. In some situations, this type of broad, time-based
prioritization control is useful.
92
Utilities

Allocation Groups
For more information on schmon options, see Schmon Utility (schmon) (SLES 10 only) on
page 103.
Allocation Groups
An Allocation Group establishes how resources are allocated to tasks (threads). It defines the
following:
A method for disbursing resources among sessions active within that Allocation Group
An attribute that optionally expedites work requests for sessions controlled by the
Allocation Group
A weight
Optionally, a CPU limit
In a single Resource Partition, multiple Performance Periods belonging to different

Performance Groups can reference the same Allocation Group, as shown in the following
figure.
One Resource Partition
Performance
Group P2
Performance
Period
Allocation
Group 7
Performance
Period
Performance
Group B
Performance
Period
Allocation
Group 6
1102F423
An Allocation Group cannot be referenced by Performance Groups from more than one
Resource Partition.
Utilities
93

Allocation Groups
Allocation Group Parameters

The following table describes the parameters of an Allocation Group.
Parameter
Description
Allocation Group ID
Any number from 0 to 199 inclusive.
Expedite Attribute
Optional parameter that indicates that work requests are to be

expedited through the AWT invocation procedures. If present, it
appears as X.
For more information, see Expedite Attribute on page 94.
Allocation Group Weight
A positive integer value used to compute the proportion of resources

each task should receive. This weight is converted to a relative weight,
taking into account all other active allocation groups within the same
Resource Partition.
For more information, see Allocation Group Weight on page 95
Limit
Optional parameter that is an integer from1 through 100. Specifies

the limit on the total CPU usage by sessions controlled by the
Allocation Group.
Associating Allocation Groups to Performance Groups

Recommendations:
Start simple with a one-to-one relationship between Performance Groups and

Performance Periods/Allocation Groups.
Establish reasonable contrast between weights of Allocation Groups in the same Resource
Partition, but avoid extreme differences. For example, use 2:1, 3:1, and 4:1 ratios between
weights, rather than 12:1 or 20:1.
If strong priority differences are required, establish relative weights for different priority
Allocation Groups so that the contrast between them is a factor of two or more. For
example, consider relative weights of 5%, 20% and 50%, rather than 15%, 18% and 20%.
Expedite Attribute
You can specify an Expedite Attribute for an Allocation Group to indicate that work requests
for sessions controlled by the Allocation Group are to be expedited through the AMP worker
task (AWT) invocation procedures. Work requests controlled by the Allocation Group are
favored over non-expedited work requests controlled by other Allocation Groups during the
invocation procedure in two ways:
94
Expedited work requests receive increased priority in the work request input queue when
all AMP worker tasks are in use. They bypass normal work requests in the input queue and
have quicker access to an AWT.
Expedited work requests have access to a special pool of reserved AWTs that have been
dedicated for this expedited work by the Teradata Database system administrator.
Utilities

Allocation Groups
Caution:
Teradata recommends that only Allocation Groups supporting short, response-sensitive work,
such as single-AMP operations, be expedited. Work performed in this mode will have some
impact on resources available to non-expedited work. Use this option judiciously.
For more information on reserved AWT pool, see AMP Worker Task (AWT) Reservations
and Limits on page 98.

Allocation group weights are values used to compute the proportion of resources each task
will be offered. The relative weight of an Allocation Group is the ratio of its weight divided by
the sum of the weights of all active Allocation Groups within the same Resource Partition
multiplied by the relative weight of the Resource Partition.
Determining Allocation Group Relative Weight
Suppose each Performance Group of a Resource Partition is linked to one Allocation Group.
The weights of these Allocation Groups are as follows:
Allocation Group 1 = 5
Suppose that only Allocation Groups 1, 2, and 3 are active.

To determine the weight for each of these active Allocation Groups, do the following:
1
Add the individual respective weights of the three active Performance Groups (5 + 10 +
20) for a sum of 35.
Divide the weight (5, 10, and 20) of each Performance Group by the sum of 35.
The relative weight for each Allocation Group, relative to its Resource Partition, is as
follows:
Allocation Group 1 = 14% (5/35)
If the relative weight of the Resource Partition is 50%, multiply the relative weight for each
Allocation Group by .50 to determine the relative weight for each Allocation Group.
The final Allocation Group weights are as follows:
If the relative weight of the Resource Partition is 50%, multiply the relative weight for each
Allocation Group by .50 to determine the relative weight for each Allocation Group.
Utilities
Allocation Group 1 = 7% (.14 x .50)
95

Allocation Groups
The following example shows how Priority Scheduler handles Resource Partitions and
associated Performance Groups.
Suppose you have three active Resource Partitions with the following weightings:
Default = 20
Tactical = 60
Standard = 20
The Standard Resource Partition consists of the following:

Performance Group
Type of Work
For demotions
P2
10
Med/low priorities
P1
40
High priorities
20
Batch loads and reports
To determine the resources allocated to med/low priority users, do the following:

1
Add the assigned weights of all active Resource Partitions:

20 + 60 + 20 = 100
Find the percentage of resources allocated to the Standard Resource Partition by dividing
the weight of the Standard Resource Partition (20) by the sum of the active Resource
Partitions (100):
20/100 = 20%
Add the assigned weights (5, 10, 40, and 20) of the active Allocation Groups within the
Standard Resource Partition:
5 + 10 + 40 + 20 = 75
Find the percentage of the Standard Resource Partition allocation that the med/low
priority users can expect by dividing the P2 group weight (10) by the sum of the active
Performance Groups (75):
10/75 = 13%
Multiply the percentage of resources (20%) allocated to the Standard Resource Partition
by the percentage (13%) of the Standard Resource Partition allocation that the med/low
priority users can expect:
20% x 13% = 2%
With all Resource Partitions and all Performance Groups in the Teradata Database system
active, the relative weight of the Allocation Group for med/low priority users is 2%. The
relative weight of the Allocation Group for batch load and report users is 5%. In this
example, the batch load and report users will have more than twice as much access to
resources than the med/low priorities.
96
Utilities

Resource Accounting
Query Response Time and Allocation Groups

The consistency of response times within a given Allocation Group depends on the following:
The number of users active at the same time within the Allocation Group
The nature of the queries (such as data skew, complexity of the work submitted, and how
long the queries take to complete)
The average query response time grows as active users in the same Allocation Group increase.
The following table shows how the number of users in Performance Group H (and its
associated Allocation Group) affects query response time of all queries in that Allocation
Group.
IF the number of active users in a Performance Group/
Allocation Group pair is...
THEN the average query response time

might be...
7 seconds.
11 seconds.
10
19 seconds.
20
38 seconds.
Resource Accounting
Priority Scheduler resource accounting employs three user-settable parameters:
Age Time is the period of time over which Priority Scheduler measures the resource
consumption of Allocation Groups in order to balance usage and priority.
Active Time is the period of time over which Priority Scheduler monitors the activity level
of Allocation Groups. Groups with no tasks running for the length of time represented by
the Active Time are removed from Priority Scheduler resource accounting for the period.
CPU Usage Limit is the total amount of CPU resource that can be used at any point in
time by all Teradata Database sessions that are under the control of Priority Scheduler.
Resource use is tracked by means of a Scheduling Set data structure. There is one Scheduling
Set allocated for every session.
Age Time
Age Time tells Priority Scheduler how many seconds constitute recent in evaluating recent
resource consumption. The default value for Age Time is 60 seconds. Decreasing this Age
Time makes Priority Scheduler respond more quickly to changes in resource usage. This
responsiveness affects the frequency and degree of changes in task (thread) priorities, and how
Priority Scheduler manages resource allocation.
Utilities
97

AMP Worker Task (AWT) Reservations and Limits
Note: In this case, responsiveness is not the same as query response time. Modifying Age Time
does not necessarily affect query response time. You should monitor adjustments in Age Time
carefully to judge their effects on Teradata Database system performance.
Active Time
The default value for Active Time is 61 seconds. During this period, an Allocation Group
continues to participate in relative weight calculations and resource allocations, even when no
tasks are active, in anticipation of a new task being associated with the Allocation Group.
This period causes a smoothing effect in the scheduling algorithms when a few tasks are
associated with an Allocation Group at interrupted intervals.
Note: If no task controlled by an Allocation Group has consumed resources within the
preceding Active Time period, the Allocation Group is considered inactive. An Allocation
Group and Scheduling Set are inactive when they have no active tasks during the active time
interval. A Resource Partition is inactive when it has no active Allocation Group within the
active time. Priority Scheduler considers only active Resource Partitions and Allocation
Groups when computing the total weight used to calculate the relative weight of Resource
Partitions and Allocation Groups. You should monitor adjustments to Active Time carefully
to judge their effect onTeradata Database system performance.
Age Time and Active Time should be kept similar to each other. For example, if Age Time is
reduced from the default of 60 to 30 seconds, change the Active Time from the default of 61 to
31.
Teradata Database System CPU Usage Limit

You can use an optional Priority Scheduler parameter to limit the total amount of CPU
resources used by the Teradata Database sessions under its control. This limit does the
following:
Limits the total CPU resources consumed to a specified percentage value
Has no affect on the scheduling strategy defined by other Priority Scheduler parameters
Is enforced separately on each individual node of the Teradata Database system
AMP Worker Task (AWT) Reservations

and Limits
AWTs are threads dedicated to servicing Teradata Database work requests. A fixed number of
AWTs are pre-allocated for each AMP vproc during Teradata Database system initialization.
Each AWT waits for a work request to arrive from the Dispatcher, services the request, and
then waits for another request.
Each Teradata Database query is composed of a series of individual work requests that are
performed by AWTs. Each request is assigned a work type that indicates when the request
98
Utilities

should be executed relative to other work requests that are waiting to execute. Examples of
work types include the following:
New work (assigned work type WorkNew).
Spawned work, sub-tasks that are required to accomplish a task (WorkOne and
WorkTwo).
Expedited new and spawned work (WorkEight, WorkNine, and WorkTen).
End and abort transaction processing (WorkAbort)
Urgent internal requests (WorkNormal and WorkControl)
An AWT can process requests of any work type. Queued requests are prioritized by work type,
and AWTs pick up the requests according to those priorities. New work has the lowest priority.
AWTs process spawned work requests before new work requests. Expedited work, whether
new or spawned, has a higher priority than non-expedited work.
AWT Resource Allocation

Since the number of AWTs is fixed, when all AWTs are busy and none are available to service
new arriving requests, these are placed in an input queue. When an AWT completes a request
for service and is available to service another, the first queued work request is removed from
the input queue and serviced.
An AWT resource manager controls the number of active requests for each AMP based on
work type of the requests. The resource manager reserves some number of tasks for each work
type to ensure that requests from each work type can be processed when necessary. For
example, an ongoing query might spawn additional tasks of a different work type part way to
completion. If reserve tasks of the new work type are unavailable, a deadlock condition can
result.
The resource manager allows a task to process a request of a particular work type if one of the
following conditions is met:
The total number of active tasks is less than a Current Limit, where Current Limit = # of
AWTs - (Total Reserved - Active Reserved).
The number of active tasks of that type is below its reserved number.
The default Teradata Database system provides 80 AWTs for each AMP. Out of these 80, three
tasks are reserved for each of eight work types, yielding 24 reserved tasks. That leaves 56
unreserved tasks that can be used for any work type.
If only two work types are active, for example WorkNew and WorkOne, they can use up to 62
AWTs in combination. This includes the 56 unreserved tasks in addition to the three tasks that
are reserved for each of the active work types (56 + 3 + 3 = 62). The 56 unreserved tasks can be
divided in any way between the two work types.
Besides reserving work tasks, the AWT resource manager also enforces an upper limit of 50 on
requests of work type WorkNew. Since many queries rely on multiple work types to reach
completion, the limit on WorkNew insures that requests that start up new work do not use too
many unreserved AWTs. Other work types have no limit on the number of tasks they can
Utilities
99

request from the unassigned pool of 56, and are limited only by the availability of unassigned
tasks.
AWTs Reserved for Expedited Allocation Groups

Priority Scheduler allows administrators to define special expedited Allocation Groups which
can be used to reserve and limit additional AWTs for short, tactical queries. Defining
expedited AGs can aid response time consistency for these types of work requests. Three work
types are used exclusively to process work requests controlled by expedited AGs: WorkEight,
WorkNine, and WorkTen.
The number of reserved tasks for the three work types used by expedited requests is added to
the 24 reserved tasks defined for normal work, and deducted from the pool of 56 unreserved
tasks that can be used for any work type. Use the Priority Scheduler schmon w command to
set the number of AWTs that is reserved for new expedited work. More than this number will
be reserved, because an equal number is reserved for the work that is spawned from the
expedited task, and an additional two are reserved for work that may be spawned from the
initially spawned tasks.
For example, if the number of AWTs that is explicitly reserved for expedited AGs per AMP is
three, a total of eight AWTs will be reserved for expedited work: three for the new expedited
work, three for work spawned directly from the expedited work, and two more for work
spawned from the already spawned tasks.
These eight AWTs reserved for expedited work will reduce the number of AWTs that are
reserved for any type of work from 56 to 48.
Note that AWTs are only reserved for expedited tasks if the following conditions are met:
One or more expedited AGs has been defined (see schmon -a on page 105)
One or more PGs use expedited AGs in Performance Period definitions (see schmon -p
on page 140)
One or more AWTs is reserved for expedited AGs (see schmon -w on page 152)
It is possible to expedite an Allocation Group, yet set or leave its reserve number at zero. If the
number of reserved AWTs for expedited work types is zero, no AWTs will be reserved. Under
those conditions, expedited requests will be serviced before normal work but are not
guaranteed immediate access to an AWT.
If expedited work consists of short, single, or few AMP queries, the amount of time a reserved
work task is held by any such query might be very short, such that a single AMP worker task
could service hundreds of queries per second. Under these conditions, a reservation of one or
two tasks might be adequate, depending on the expected arrival and service rate of the queries.
If any queries running within an expedited Allocation Group are all-AMP queries, a
minimum reserve number of two should be selected. Teradata recommends that the reserve
limit be set the same as the limit for WorkNew, 50. (The reserve number cannot exceed 20 for
expedited work.)
100
Utilities

Note: The work request for a single-AMP query is processed by just one task of the AMP
vprocs of an MPP system. Each AMP in the Teradata Database system could be performing a
similar single-AMP request simultaneously.
The schmon -m display includes data indicating the queue length, queue wait time, and
service time for all Allocation Groups. This data might be useful for adjusting the Expedited
work type reservation and limit values. If the queue wait time is between zero and five
milliseconds for a non-expedited Allocation Group, then it might not benefit from being
expedited, because no shortage of AWTs is being experienced.
The optional Expedite attribute of an Allocation Group is intended to provide quicker and
more consistent response time for queries than might be experienced with a non-expedited
Allocation Group. This Allocation Group option is intended for use by sessions submitting
short, simple queries where quick response time is critical. This type of work is sometimes
referred to as tactical query work.
AMP Worker Task Examples

The AWT Monitor (awtmon) utility collects and displays a summary of AWT in-use count
snapshots for the local node or for all nodes in the Teradata Database system. The following
examples show how AWTs might be allocated under a heavy load of normal data warehouse
work and various expedited work loads and settings. For more information on AWT Monitor,
Utilities Volume 1.
Example 1
awtmon default output
> awtmon
====> Thu Feb 15 10:02:34 2005 <====
Amp 0: Inuse: 22: FOUR: 1 NEW: 13 ONE: 8
Amp 2: Inuse: 20: NEW: 12 ONE: 8
Example 2
This example shows awtmon run in summary mode, displaying information only if 8 or more
AMPs have a combined total of 50 or more AWTs in use. The final two numbers in the
command specify that awtmon will automatically run 3 times, with a 2-second delay between
runs.
> awtmon -S 8 -t 50 2 3
====> Tue Feb 16 08:53:44 2003 <====
LOOP_0: Inuse: 55: Amps: 5,6,11,12,17,18,23,29,30,35,36,41,42
LOOP_0: Inuse: 56: Amps: 0,47
LOOP_0: Inuse: 57: Amps: 24
====> Tue Feb 16 08:53:47 2003 <====
LOOP_1: Inuse: 54: Amps: 5,6,11,12,17,18,23,29,30,35,36,41,42
Utilities
101

LOOP_1: Inuse: 55: Amps: 0,47
====> Tue Feb 16 08:53:49 2003 <====
LOOP_2: Inuse: 54: Amps: 5,11,12,17,18,23,29,30,35,36,41,42
LOOP_2: Inuse: 55: Amps: 0,6,47
102
Utilities

Schmon Utility (schmon) (SLES 10 only)
Schmon Utility (schmon)

(SLES 10 only)
Function
The Schmon utility, schmon, provides a command line interface that allows you to display and
alter Priority Scheduler parameters.
Note: On SLES 11 systems, Priority Scheduler is managed by Teradata Active System
Management (ASM), and is configured using the Teradata Viewpoint workload management
portlets. For more information on those portlets, see Teradata Viewpoint User Guide. The
information in this chapter applies only to Teradata Database systems running on SLES 10.
Note:
If Workload Definition (Category 3) rules have been set in the Teradata Viewpoint
Workload Designer portlet, schmon cannot be used to make changes to Priority Scheduler.
Teradata Data Warehouse Appliance supports only a subset of schmon commands, and
does not support changing any Priority Scheduler settings. Run schmon -h to see the
available commands.
Certain output data, such as priority and resource usage, may differ from the examples
shown in this chapter, depending on the operating system under which Teradata Database
is running.

such as cnsterm
Linux command line
Runs From
Utilities
103

Schmon Utility (schmon) (SLES 10 only)
Syntax
schmon
-a
AG#
weight
div
-s
-S
limit
none
-T
-d
delay
reps
-x
-b
RP#
RPNAME
weight
limit
none
-s
-S
-T
-d
delay
reps
-x
-c
-a
-b
-p
-t
-w
-f path
-d
-f
path
-h
specific option(s)
-l
limit
none
-m
-S
-P
-b
-d
delay
reps
-L
-M
-n
-p
-s
-P
-b
-d
-V
delay
reps
-p
PG#
PGNAME
-s
-S
-T
PP
-d
delay
reps
-x
-s
all
-S
-T
-d
delay
reps
id
-t
age
active
disp
-w
reserve
maximum
1102G005
Note: Some internal and rarely-needed options have been omitted from the following
discussion. Those options are described in the online help for schmon.
104
Utilities

schmon -a
schmon -a
Purpose
The schmon -a option displays or sets Allocation Group parameters.
Syntax
schmon
-a
AG#
div
-s
-S
weight
X
limit
none
-T
-d
delay
reps
-x
1102F006
Syntax element
Description
-a
Sets or displays Allocation Group parameters. If no additional options are

specified, schmon -a displays the parameters for Allocation Groups currently in
use (those with defined parameters).
AG#
An integer from 0 through 199 that identifies the Allocation Group for which
parameters will be set or displayed.
To set parameters for a Allocation Group, follow AG# with the div and weight
specifications.
To view information about a specific Allocation Group, follow AG# with the -s
or -S options, or with no options.
To clear all parameters for a specific Allocation Group, follow AG# with the -x
option.
div
This option is obsolete, but remains for backward compatibility. div must have a
value of N or S when creating or modifying an AG. (That is, div must be specified
any time weight is specified.) N and S values are equivalent. The N and S values
must be entered as upper case letters.
The Allocation Group is expected to process expedited work. Work requests

controlled by the Allocation Group receive special treatment in the request input
queue and AWT allocation phase. Requests receive superior priority in the input
queue, bypassing normal requests, and are assigned to work tasks from a pool
reserved for the purpose.
You can use this option with more than one Allocation Group. When multiple
Allocation Groups have the expedited attribute, work requests for all of the
Allocation Groups are satisfied from a single reserved work task pool.
Note: You can use the schmon -w command to define the reserved work pool.
Utilities
105

schmon -a
Syntax element
Description
weight
A numeric value used to compute a relative weight to determine the proportion of

resources the tasks of the Allocation Group are to receive.
Note: To use the weight option, an N or S value for div must also be used on the
command line.
limit
A percentage limit on total CPU usage by all tasks controlled by the Allocation
Group.
The value range is from 1 through 100.
A value of 100 indicates that no limit is to be enforced.
If limit is not specified, no limit is enforced, and any previously defined limit for
the AG is removed.
none
Specifies that no limit is to be enforced. This is the default value for limit. It is the
same as specifying 100.
-s
Displays Priority Scheduler data for all sessions controlled by the specified
Allocation Group on the current node.
-S
Displays Priority Scheduler data for all sessions controlled by the specified
Allocation Group on all Teradata Database nodes.
-T
Displays tasks (threads) for the specified Allocation Groups on the current node
(the node from which schmon was invoked). Even when used in conjunction with
the -S option, -T will display only task data for the current node.
Note: The -T option should not be used for prolonged periods of time, because it
can interfere with the normal operation of Priority Scheduler.
The -T output includes the following columns:
106
Procqueue Tsk Addr: Kernel Task Context Block address

Tskid: Thread ID
Prio: OS priority
Session: Task session number
Request: Task request number
Tskuse: Task CPU resource usage
Tskterm: Session resource usage to weight ratio
# Delay: Task delay count due to CPU limits
Delay Time: Task total delay time due to CPU limits
Utilities

schmon -a
Syntax element
Description
-d
Displays the differences in data between sequential runs of schmon. Use the delay
[reps] option to control timing of automatic schmon runs.
The following symbols precede numbers that appear in the output from the -d
option.
For decimal numbers:
- (a minus sign) indicates the value has decreased by the indicated amount
since the previous schmon run.
An unsigned decimal number indicates the value has increased by the
indicated amount since the previous schmon run.
For task data (displayed if the -T option is used with the -d option):
n-> indicates a task has been moved from the control of AG n to the
control of the displayed AG since the previous schmon run.
+ indicates a task is new, started since the previous schmon run.
- indicates a task that ended since the previous schmon run.
* indicates a task that has changed sessions or requests since the previous
schmon run.
For examples of the -d option output, see schmon -m on page 123, and
schmon -s on page 145.
Note: The output of the -d option shows only those items for which data has
changed since the previous schmon run.
delay [reps]
Causes schmon -a to run again automatically after a specified delay using the
current session options. delay is a positive integer that specifies the number of
seconds between schmon executions.
Use the optional reps argument, a positive integer, to specify the number of times
schmon should run. If reps is not specified, schmon runs indefinitely with delay
seconds between executions. In this case, schmon can be stopped by pressing CtrlC or otherwise killing the schmon process.
Note: The difference between time stamps of successive information displays may
not precisely match the specified delay value due to the time required for the
collection activity itself.
-x
Clears the parameters that define the specified Allocation Group, effectively
deleting it from the system (though an empty group will still appear in the output
of schmon -a all).
The Allocation Group must not be referenced by any Performance Period defined
by any Performance Group.
Usage Notes
A sessions tasks are assigned to Allocation Groups based on the sessions Performance Group.
Each Performance Group may have from one to eight Performance Periods defined, each of
which specifies an Allocation Group. As a task runs, its Performance Period changes according
to limit criteria (milestones) that are defined along with the Performance Group.
Consequently, the Allocation Group that controls a task can change over time. For more
information, see Performance Periods on page 88.
Utilities
107

schmon -a
The following apply to MPP configurations:
For the -S option:
The count of nodes is displayed.
Time information is displayed.
If a node is offline, it is not included in the output, and the node count reflects this;
however, information about this node being excluded is not displayed.
The following apply to SMP configurations:
Node count is not shown.
A status message that includes time of day is displayed.
No transient status messages are displayed.
Example 1
To display parameters for all in-use Allocation Groups, type:
schmon -a
The following appears:

Allocation Groups (0 - 199)
Id Type Wght Lim Id Type Wght Lim Id Type Wght Lim Id Type Wght Lim
1 N
5
none 2 N
10
none 3 N
20
none 4 N
40
none
30 S
30
none
Example 2
The following example shows a four-node MPP system.
To display session data for Allocation Group 1 on the current node, type:
schmon -a 1 -s

Stats: Mon Mar
8 14:47:16 2008
Session Usage
Query Usage
AG HostID
Session
Request
#tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========= ========= ======== == =================
1
0
0
0
9
60
10250
60
10250 0 L[0]
Example 3
The following example shows a four-node system.
Note: PDE was not up on one of the nodes.
To display session data for Allocation Group 1 on all nodes, type:
schmon -a 1 -S

Stats: 3 node(s)
AG HostID
108
Mon Mar
Session
8 14:50:32 2008
Request
#tsk
Session Usage
Query Usage
CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP]
Utilities

schmon -a
=== ====== ========== ========== ==== ========== ========= ========= ======== == =================
1
0
0
0
19
70
20500
70
20500 0 L[0]
Example 4
To set the expedite attribute on an Allocation Group 1, type:
schmon -a 1 N X 30

Id Type Weight
1 N
5
>>>>> Changed to:
1 NX
30
Example 5
To change the weight of Allocation Group 5 from 1 to 10, type:
schmon -a 5 S 10

Id Type Weight
5 S
1
>>>>> Changed to:
5
Utilities
10
109

schmon -b
schmon -b
Purpose
The schmon -b option displays or sets Resource Partition parameters.
Syntax
schmon
-b
RP#
RPNAME
-s
-S
weight
limit
none
-T
-d
delay
reps
-x
1102F004
Syntax element
Description
-b
Sets or displays Resource Partition parameters. If no additional options are

specified, schmon -b displays the parameters for Resource Partitions currently
in use (those with defined parameters).
RP#
An integer from 0 through 4 that identifies the Resource Partition for which
To set parameters for a Resource Partition, follow RP# with the RPNAME
and weight specifications.
To view information about a specific Resource Partition, follow RP# with
the -s or -S options, or with no options.
To clear all parameters for a specific Resource Partition, follow RP# with the
-x option.
RPNAME
The name of the Resource Partition.

Resource Partition names that contain spaces must be within double quotation
marks. For example, RP ONE.
weight
110
A numeric value used to compute a relative weight to determine the

proportion of resources that the tasks controlled by the Resource Partition are
to receive.
Utilities

schmon -b
Syntax element
Description
limit
A percentage limit on total CPU usage by all tasks controlled by the Resource
Partition.
The value ranges from 1 through 100.
If limit is not specified, no limit is enforced, and any previously defined limit
for the RP is removed.
none
Specifies that no limit is to be enforced. This is the default value for limit. It is
the same as specifying 100.
-s
Displays Priority Scheduler data for all sessions controlled by the Resource
Partition on the current node.
-S
Displays Priority Scheduler data for all sessions controlled by the Resource
Partition on all nodes of the Teradata Database system.
-T
Displays tasks (threads) for the specified Resource Partition on the current
node (the node from which schmon was invoked). Even when used in
conjunction with the -S option, -T will display only task data for the current
node.
Note: The -T option should not be used for prolonged periods of time,
because it can interfere with the normal operation of Priority Scheduler.
Utilities

Tskid: Thread ID
Prio: OS priority
111

schmon -b
Syntax element
Description
-d
Displays the differences in data between sequential runs of schmon. Use the
delay [reps] option to control timing of automatic schmon runs.
option.
- (a minus sign) indicates the value has decreased by the indicated
amount since the previous schmon run.
* indicates a task that has changed sessions or requests since the
previous schmon run.
delay [reps]
Causes schmon -b to run again automatically after a specified delay using the
Use the optional reps argument, a positive integer, to specify the number of
times schmon should run. If reps is not specified, schmon runs indefinitely
with delay seconds between executions. In this case, schmon can be stopped by
pressing Ctrl-C or otherwise killing the schmon process.
Note: The difference between time stamps of successive information displays
may not precisely match the specified delay value due to the time required for
the collection activity itself.
-x
Clears the parameters that define the specified Resource Partition, effectively
deleting it from the system (though an empty group will still appear in the
output of schmon -b all).
The Resource Partition must not be referenced by any Performance Group.
112
Utilities

schmon -b
Usage Notes
For information on the settings displayed using the -b option, see schmon -d on page 117.
For the -S option:
The count of nodes is displayed.
If a node is offline, it is not be included in the output, and the node count reflects this;
A status message that includes time of day is displayed.
Example 1
To display session data for Resource Partition 0 on the current node, type:
schmon -b 0 -s

Stats: 3 node(s)
Mon Mar
8 15:02:06 2008
Session Usage
Query Usage
AG HostID
Session
Request #tsk CPU(msec)
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
1
0
0
0
9
60
10250
60
10250
0 L[0]
2
0
0
0
2
640
0
640
0
0 M[0]
4
0
0
0
1
1
0
1
0
0 R[0]
Example 2
To display session data for Resource Partition 0 on all nodes, type:
schmon -b 0 -S

Stats: 3 node(s)
Mon Mar
8 15:02:06 2008
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
1
0
0
0
19
80
20500
80
20500
0 L[0]
2
0
0
0
6
790
5836
790
58360
0 M[0]
4
0
0
0
3
5
0
5
0
0 R[0]
Utilities
113

schmon -b
Example 3
To limit CPU usage by tasks controlled by Resource Partition 1 to 40 percent of the total CPU
available, type:
schmon -b 1 RP1 50 40

Id
1
Partition Name
RP1
Resource Partitions (0 - 4)
Weight Limit
50
none
>>>>> Changed to:

1 RP1
50
40
Example 4
To reset the limit to none on Resource Partition 1, type:
schmon -b 1 RP1 50 none

Id
1
Partition Name
RP1
>>>>> Changed to:

1 RP1
Weight Limit
50
40
50
none
Example 5
To change the Resource Partition name, the relative weight, and the total CPU limit for
Resource Partition 1, type:
schmon -b
1 "RP NO 1" 100 none

Id Partition Name
Weight
1 rp1
30
>>>>> Changed to:
1 RP NO 1
100
114
Limit
40
none
Utilities

schmon -c
schmon -c
Purpose
The schmon -c option displays the current Priority Scheduler settings as schmon commands.
The output can also be sent to a specified file, which can be used as input to the schmon -f
command to reapply the current schmon settings.
Syntax
schmon
-c
-a
-b
-p
-t
-w
-f path
1102B022
Utilities
Syntax element
Description
-c
Displays current Priority Scheduler settings as schmon commands. If no

additional options are specified, schmon -c displays all of the current settings.
-p
Displays settings for the current Performance Group as schmon commands.

Displays schmon commands that can be used to re-create the current
Performance Groups.
-b
Displays schmon commands that can be used to re-create the current Resource
Partitions.
-a
Displays schmon commands that can be used to re-create the current

Allocation Groups.
-w
Displays schmon commands that can be used to re-create the current AWT
expedite parameters.
-t
Displays schmon commands that can be used to re-create the current Times
and Attributes parameters.
-f path
Saves the output of schmon -c to a specified file. The file can be used in
conjunction with the schmon -f command to reapply some or all of the
current schmon settings. This option can be used with any combination of the
other schmon -c options.
115

schmon -c
Usage Notes
If you do not specify any options with the schmon-c command, then all commands, including
those for setting system times and attributes, are displayed.
Example 1
To dump all settings, type:
schmon -c

#
Priority Scheduler Times & Attributes
# Age_Time Active_Time Dispatch_Age
schmon -t
60
61
0
# System Limit
schmon -l 100
#
Resource Partitions
schmon -b 0 Default
#
schmon
schmon
schmon
schmon
Allocation Groups
-a
1 N
5 none
-a
2 N
10 none
-a
3 N
20 none
-a
4 N
40 none
#
schmon
schmon
schmon
schmon
Performance Groups
-p 0 L 0 S
-p 1 M 0 S
-p 2 H 0 S
-p 3 R 0 S
100
0.00
0.00
0.00
0.00
none
1
2
3
4
#
AWT Expedited work type limits (reserve maximum)
schmon -w
0
999
Example 2
To dump only Allocation Group parameters, type:
schmon -c -a

#
schmon
schmon
schmon
schmon
116
Allocation Groups
-a
1 N
5 none
-a
2 N
10 none
-a
3 N
20 none
-a
4 N
40 none
Utilities

schmon -d
schmon -d
Purpose
The schmon -d option displays the current Priority Scheduler settings in multi-line format.
Syntax
schmon
-d
1102A024
Usage Notes
The following table describes the Priority Scheduler settings.
Setting category
Description
Scheduler Times &

Attributes
Displays scheduler times and attributes.
Resource Partitions
Displays Resource Partition parameters.
Age Time specifies the time period over which recent resource usage
by a Scheduling Set is measured. The default is 60 seconds.
Active Time specifies the time period during which an Allocation
Group is considered active if any task assigned to the Allocation Group
has been scheduled. Inactive Allocation Groups are not included in
resource consumption calculations. The default is 61 seconds.
Limit specifies the Teradata Database system CPU limit or None if not
specified.
ID specifies the identifier number of the Resource Partition.

Partition Name specifies the name of the Resource Partition.
Weight specifies the numeric value used to compute the relative
weight of this Resource Partition.
Limit specifies a number between 1 and 100, inclusive, that specifies a
percentage limit on the total CPU usage by sessions assigned to the
Performance Groups associated with the Resource Partition or the
string none to indicate no limit is present.
Utilities
117

schmon -d
Setting category
Description
Performance Groups
Displays Performance Group parameters.

ID specifies the Teradata Database system-wide, unique identifier of
the Performance Group.
Group Name specifies the name of the Performance Group.
RP specifies the Resource Partition to which this Performance Group
is to be assigned.
Type specifies the single character that specifies the type of units used
in these Performance Period definitions:
The character Q indicates that milestone limits are seconds (186400) of query resource usage.
The character S indicates that milestone limits are seconds (186400) of session resource usage.
The character T indicates that milestone units are time-of-day, in
military time (0 to 2359). You must define at least two periods.
Milestones & Allocation Groups specifies that each milestone defines
a period milestone (in units defined by Type above), and that the
corresponding Allocation Group defines the Allocation Group in
effect during that period.
If you are defining only one Performance Period for the Performance
Group, use S or Q as the default milestone type and 0 (zero) as the
default milestone limit.
Allocation Groups
Displays Allocation Group parameters.

ID specifies the Teradata Database system-wide, unique identifier of
the Allocation Group.
X specifies that an Allocation Group has the Expedite attribute.
Wght specifies a numeric value used to compute the relative weight of
the Allocation Group.
Lim specifies a percentage limit on total CPU usage by all tasks
controlled by this Resource Partition or the character string none.
The value ranges from 1 through 100.
The character string none indicates that no limit is to be enforced.
If Lim is not present, any previously defined limit is removed.
118
Utilities

schmon -d
Example
The following example shows the current Priority Scheduler settings in multi-line format.
> schmon -d
Scheduler Times & Attributes
Age Time(sec):
60
Active Time(sec):
61
Limit(%):
none
Id Partition Name
Weight Limit
0 Default
100
none
Performance Groups (0 - 249)
Id Group Name
RP Type Milestones & Allocation Groups[0-7]
0 L
0 S
0.00
1
1 M
0 S
0.00
2
2 H
0 S
0.00
3
3 R
0 S
0.00
4
Id Type Wght Lim Id Type Wght Lim Id Type Wght Lim Id Type Wght Lim
1 N
5 none
2 N
10 none
3 N
20 none
4 N
40 none
AWT Expedited work type limits
res
max
0
999
Utilities
119

schmon -f
schmon -f
Purpose
The schmon -f option reads schmon commands from a file or standard input device. This
command is most often used in conjunction with the schmon -c command to reapply Priority
Scheduler settings that were in effect at the time schmon -c was run.
Syntax
schmon
-f
path
1102A061
Syntax element
Description
path
Specifies a path from which input is to be read. If path is not specified, data
is read from standard input (STDIN).
Usage Notes
Input data is assumed to be a single file of schmon commands separated by new line
characters. A command that begins with the # character is treated as a comment. Each input
command is written to the standard error device when the command is read. Changes to
Priority Scheduler parameters are accumulated until the end of file is encountered and then
applied to the Teradata Database system.
An error in a command will terminate reading, and no changes will be applied. Errors are
reported on the standard output device.
To simplify creation of a suitable input file, see schmon -c on page 115.
Example
Assume that file sample contains the following lines:
schmon -t
schmon -a
The command schmon -f sample results in the following output:

schmon -t
Age Time(sec):
60 Active Time(sec):
61 Disp Age(sec):
schmon -a
Id Wght Lim Id Wght Lim Id Wght Lim Id Wght Lim
1
5 none
2
10 none
3
20 none
4
40 none
120
10
Utilities

schmon -h
schmon -h
Purpose
The schmon -h option displays help for schmon.
Syntax
schmon
-h
specific option(s)
1102A063
Utilities
Syntax element
Description
specific option(s)
Specifies one or more schmon top-level options on which to display

extended help.
121

schmon -l
schmon -l
Purpose
The schmon -l option displays or sets the Teradata Database system CPU usage limit.
Syntax
schmon
-I
limit
none
1102A066
Syntax element
Description
-l
Displays or sets the system CPU usage limit. If no additional options are
specified, schmon -l displays the current CPU usage limit.
limit
A percentage limit on total CPU usage by the Teradata Database sessions.

This limit does not apply to non-Teradata work.
The value range is from 1 through 100.
none
Specifies that no limit is to be enforced. It is the same as specifying 100.
Example 1
This sets the Teradata Database system per-node CPU resource limit from 60 percent to none.
>schmon -l none
System CPU Limit(%)
60
>>>>> Changed to:
none
Example 2
This sets the Teradata Database system per-node CPU resource limit from none to 90 percent.
>schmon -l 90
System CPU Limit(%)
none
>>>>> Changed to:
90
122
Utilities

schmon -m
schmon -m
Purpose
The schmon -m option displays or monitors Priority Scheduler resource usage statistics.
Syntax
schmon
-m
-S
-P
-b
-d
delay
reps
-L
1102D067
Syntax element
Description
-m
Displays or monitors Priority Scheduler resource usage statistics. If no

additional options are specified, schmon -m displays current statistics for
the current node.
-S
Displays or monitors statistics for all nodes in an MPP system.
-L
Includes information related to the CPU usage limits imposed on

Allocation Groups.
CPU usage limits can be set at the AG, RP, or Teradata Database system
level using schmon -a, -b, and -l options, respectively. AG tasks can be
delayed by the system, if necessary, to keep the CPU usage within those
limits.
-P
Displays a separate line of information for each Performance Group.

Note: Performance Groups with no CPU usage are not shown.
-b
Displays resource usage over the last second. Without the -b option,
schmon shows resource usage information for the last age time period. The
age time period is defined by the schmon -t command.
-d
Displays the differences in data between sequential runs of schmon. Use

the delay [reps] option to control timing of automatic schmon runs.
The following symbols precede numbers that appear in the output from
the -d option.
An unsigned number indicates the value has increased by the indicated
Note: The output of the -d option shows only those items for which data
has changed since the previous schmon run.
Utilities
123

schmon -m
Syntax element
Description
delay [reps]
Monitors resource usage over time by causing schmon to run again

automatically after a specified delay using the current -m options. delay is a
positive integer that specifies the number of seconds between schmon
executions.
times schmon should run. If reps is not specified, schmon runs indefinitely,
with delay seconds between executions to continually monitor resource
usage.
Note: The difference between time stamps of successive information
displays may not precisely match the specified delay value due to the time
required for the collection activity itself.
Usage Notes
The statistics are described in the following table.
Statistics category
Description
Stats Collection
The date and time of the statistics displayed, as well as repetition number, if you specify multiple
repetitions.
Resource Partitions
The statistics for each active Resource Partition, including the following:
RP specifies the Resource Partition ID Number.
Rel Wgt specifies the weight of the Resource Partition relative to the active Resource Partitions.
Note: The sum of relative weights might be greater or less than 100 due to the following
considerations:
124
Fractions are truncated as the final step in relative weight calculations.

Any relative weight calculated to be less than one is converted to one.
Avg CPU specifies the resource usage during the preceding age period for a single CPU. The CPU
data is shown in two columns.
The % column is the percentage of CPU consumed by the Resource Partition. When statistics
are collected from all nodes in an MPP system, this is the average percentage per Resource
Partition for all nodes.
The msec column is the milliseconds of CPU time consumed by the Resource Partition.
Avg I/O specifies a normalized number of data blocks transferred by the Resource Partition.
When statistics are collected from all nodes in an MPP system, this is the average normalized
resource use per Resource Partition for all nodes on the Teradata Database system. I/O data is
shown in two columns.
The % column is the percentage of disk consumed by the Resource Partition. When statistics
The sblks column is the number of blocks read and written by the Resource Partition.
# of Tasks specifies the number of tasks assigned to the Resource Partition at the end of the
preceding collection period. When statistics are collected from all nodes in an MPP system, this is
the average per Resource Partition for all nodes.
# of Sets specifies the number of Scheduling Sets associated with the Resource Partition at the
end of the preceding collection period. There is one Scheduling Set per session.
Utilities

schmon -m
Statistics category
Description
Allocation Groups
The statistics for each active Allocation Group, including the following:
AG specifies the Allocation Group ID number.
Rel Wgt specifies the weight of the Allocation Group relative to the active Allocation Groups of
the Resource Partition and the active Resource Partitions.
considerations:
Avg CPU specifies resource usage by the Allocation Group during the preceding age period for a
single CPU. The CPU data is shown in two columns.
The % column is the percentage of total available CPU on the node consumed by the
Allocation Group. When statistics are collected from all nodes in an MPP system, this is the
average percentage for all nodes.
The msec column is the milliseconds of CPU usage consumed by the group.
Avg I/O specifies a normalized number of data blocks transferred by the Allocation Group. When
statistics are collected from all nodes in an MPP system, this is the average normalized resource
use per Allocation Group for all nodes on the Teradata Database system. I/O data is shown in two
columns.
The % column is the percentage of total I/O blocks transferred by the Allocation Group. When
statistics are collected from all nodes in an MPP system, this is the average percentage for all
nodes.
The sblks column is the number of blocks read and written by the group.
# of Tasks specifies a number of tasks assigned to the Allocation Group at the end of the
proceeding collection period. When statistics are collected from all nodes in an MPP system, this
is the average per Allocation Group for all nodes.
# of Sets specifies a number of Scheduling Sets associated with the Allocation Group at the end of
the preceding collection period. When statistics are collected from all nodes in an MPP system,
this is the total per Allocation Group for all nodes. There is one Scheduling Set per session.
Performance Groups Affected specifies all Performance Groups by name that reference the
Allocation Group at that time. Since Allocation Groups can be shared among Performance
Groups, this information is useful for resource usage traceback. (This information is not
displayed when statistics are collected from all nodes in an MPP system, unless you use the -p
option.)
Note: System information is listed under AG 200. This AG has Rel Wgt set to MAX, which indicates
that system work receives the maximum priority, but is not in any Rel Wgt calculations.
Work Requests
Displays work request statistics for each active Allocation Group. This data refers to the preceding age
period and is the average for all nodes on a multi-node Teradata Database system. The data includes
the following:
AG specifies the Allocation Group number.
# of requests specifies the number of work requests received.
Avg queue wait specifies the average time, in milliseconds, that a work request waited on an input
queue before being serviced.
Avg queue length specifies the average number of work requests waiting on the input queue for
service.
Avg service time specifies average time, in milliseconds, that a work request required for service.
Utilities
125

schmon -m
For the -S option:
The count of nodes for a single repetition or for multiple repetitions is displayed.
A status message that includes time of day regardless of the number of repetitions is
displayed.
Example 1
To monitor current Priority Scheduler statistics for the current node, type:
schmon -m

Stats: Tue Jan 20 07:48:23 2004
Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
% (sblks) Tasks Sets
=== === === ======= === ======= ===== ===== ==============================
0 100
0
58
0
0
13
3
Rel
Avg CPU
Avg I/O
# of # of
AG Wgt % (msec)
=== === === ======= === ======= ===== =====
1
9
0
33
0
0
10
1
2 18
0
5
0
0
1
1
4 72
0
20
0
0
2
1
200 MAX
0
217
0
15
27
1
Performance Groups Affected

==============================
L
M
R, PGFive
System
Avg queue Avg queue Avg service

AG #requests wait(msec) length
time(msec)
=== ========== ========== ========== ===========
2
16
0
0
76
4
6
0
0
0
Example 2
To monitor Priority Scheduler statistics for all nodes with a monitoring interval with a fivesecond delay between repetitions of the display, type:
schmon -m -S 5 1

Stats: 3 node(s)
Rel
RP Wgt
126
Avg CPU
% (msec)
Mon Mar
8 15:32:33 2004
Avg
Avg
Avg I/O
# of # of
Node Resource Usage

Minimum
Maximum
CPU
I/O Tasks
CPU
I/O Tasks
Utilities

schmon -m
=== === === ======= === ======= ===== ===== =================== ===================
0 100
0
11
0
0
2
0
22
0
4
22
0
4
Avg
Rel
Avg CPU
Avg I/O
# of
AG Wgt % (msec)
% (sblks) Tasks
=== === === ======= === ======= =====
2 18
0
11
0
0
2
Avg
Node Resource Usage
# of
Minimum
Maximum
Sets
CPU
I/O Tasks
CPU
I/O Tasks
===== =================== ===================
0
22
0
4
22
0
4
Example 3
The following output is from an SMP configuration. The L option shows information on
CPU usage limits placed AGs by the System/RP/AG limit feature. This information includes a
count of delays imposed on each AG to keep CPU usage within the limits.
To monitor current Priority Scheduler statistics for the current node with information related
to System/RP/AG limits, type:
schmon -m -L

Stats: Wed Jan 13 10:53:20 2010
Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
=== ==== === ======= === ======= ===== ===== ==============================
0 100 24
14950
0
0
22
2
Rel
Avg CPU
Avg I/O
# of # of
Delay
Delay
Total
AG Wgt % (msec)
Count Skipped
Delay
=== ==== === ======= === ======= ===== ===== ======= ======= ==========
10
33
8
5202
0
0
12
1
599
0
447628
11
66 16
9748
0
0
10
1
596
0
445184
200 MAX
0
62
0
0
74
1
0
0
0
time(msec)
=== ========== ========== ========== ===========
10
20
28.80
0.01
24975.40
11
42
11.90
0.01
14268.19
The following table explains the additional columns related to CPU limits and delays.
Utilities
Column
Explanation
Delay Count
The number of delays imposed on tasks in the AG over the Age Period. The
Age Period can be viewed and set using schmon -t.
Delay Skipped
The number of delays skipped due to tasks being in non-delayable states.
Total Delay
The total number of milliseconds that all tasks in the AG have been delayed
over the Age Period. The Age Period can be viewed and set using
schmon -t.
127

schmon -m
Example 4
The following output is from an SMP configuration.
To monitor current Priority Scheduler statistics for the current node with a monitoring
interval of five seconds and two repetitions, type:
schmon -m 5 2

Stats Collection #1: Mon Mar 20 18:02:31 2006
Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
0 100
0
8
0
0
1
1
Rel
Avg CPU
Avg I/O
# of # of
AG Wgt % (msec)
% (sblks) Tasks Sets Performance Groups Affected
=== === === ======= === ======= ===== ===== ==============================
2 18
0
8
0
0
1
1 M
Stats Collection #2: Mon Mar 20 18:02:36 2006

Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
0 100
0
38
0
0
1
1
Rel
Avg CPU
Avg I/O
# of # of
AG Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
2 18
0
38
0
0
1
1 M
Example 5
The -P option shows a separate line of information for each Performance Group. The
following example compares the output from schmon -m and schmon -m -P.
>schmon -m
Stats: Mon Oct 30 14:33:19 2006
Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
0 66
0
95
0
0
2
1
1 33 24
14911 95
701
144
201
Rel
Avg CPU
Avg I/O
# of # of
AG Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
4 53
0
95
0
0
2
1 H, R
11 11 11
7180 70
519
49
1 PG10, PG11, PG12
12 22 12
7731 24
182
95
200 PG11, PG12, PG13
200 MAX
2
1709
4
31
140
1 System
time(msec)
=== ========== ========== ========== ===========
4
157
1.82
0.00
43.15
11
2375
346.68
13.72
259.41
12
4136
206.94
14.27
155.91
>schmon -m -P
Stats: Mon Oct 30 14:33:19 2006
Avg CPU
Avg I/O
# of # of
RP PG % (msec)
=== === === ======= === ======= ===== ===== ==============================
128
Utilities

schmon -m
0
1
1
1
1
3
10
11
12
13
0
9
10
3
1
95
5623
6256
2020
1012
0
51
24
19
0
0
379
182
140
0
1
19
51
30
22
1
36
61
98
111
Avg CPU
Avg I/O
# of # of
AG PG % (msec)
=== === === ======= === ======= ===== ===== ==============================
4
3
0
95
0
0
1
1 R
11 10
9
5623 51
379
19
36 PG10
11 11
0
487
0
0
19
47 PG11
11 12
1
1070 19
140
0
43 PG12
12 11
9
5769 24
182
32
14 PG11
12 12
1
950
0
0
30
55 PG12
12 13
1
1012
0
0
22
111 PG13
200 40
2
1709
4
31
140
1 System
AG PG #requests wait(msec) length
time(msec)
=== === ========== ========== ========== ===========
4
3
157
1.82
0.00
43.15
11 10
1205
266.38
5.35
818.12
11 11
1158
433.82
8.37
525.99
12 11
63
31.75
0.03
5313.52
12 12
1946
216.07
7.01
262.16
12 13
2113
205.12
7.22
300.01
Example 6
The following example displays changes in data over time using the default delay time of five
seconds.
> schmon -m -d
Using default 5 second delay.
Stats: Thu Feb 08 18:24:13 2007
Rel
Avg CPU
Avg I/O
# of # of
RP Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
0
0
0
-3
0
0
4
0
1
0
1
652
1
123 -143
0
Rel
Avg CPU
Avg I/O
# of # of
AG Wgt % (msec)
=== === === ======= === ======= ===== ===== ==============================
2
0
0
-1
0
0
0
0 M
4
0
0
-2
0
0
4
0 R
10
0 -2
-1006 -4
-125
21
0 PG10, PG11, PG12
11
0
3
1781
6
296 -230
0 PG10, PG11, PG12
12
0
1
661 -1
15
36
0 PG10, PG11, PG12
13
0 -1
-784 -2
-63
30
0 PG10, PG11, PG12
200 MAX -1
-232 -1
-13
0
0 System
time(msec)
=== ========== ========== ========== ===========
4
-1
-17.71
-0.09
-5.79
10
-809
3.56
0.14
11.41
11
-14
0.03
-0.00
1668.90
12
-624
3.17
-0.03
8.24
13
-418
21.21
1.20
2.81
Utilities
129

schmon -M
schmon -M
Purpose
The schmon -M option displays or monitors Priority Scheduler resource usage statistics for all
nodes of an MPP Teradata Database.
Syntax
schmon
-M
-n
-p
-P
-s
-V
-b
-d
delay
reps
1102D068
Syntax element
Description
-M
Displays or monitors Priority Scheduler resource usage statistics for all

nodes of Teradata Database. If no additional options are specified,
schmon -M displays the current statistics one time.
-n
Show names for nodes that have the minimum and maximum resource
usage and work requests. The displayed names come from the mpplist file.
Due to space limitations, names longer than nine characters may be
truncated.
-p
Specifies to display Performance Group names associated with the

Allocation Groups that are displayed with the -M command.
-s
Show Resource Partition and allocation group node resource usage

statistics. Displays median and standard deviation values. Also displays a
frequency table that shows the number of nodes falling within each of ten
usage ranges. If no nodes fall within a range, that range is not included in
the table.
-V
Verbose mode includes inactive nodes in statistical calculations and in the

display. Inactive nodes are nodes that report zero usage, which can change
the values calculated for median and standard deviations.
-P
Shows a separate line of information for each Performance Group.

Note: Performance Groups with no CPU usage are not shown.
-b
130
Displays resource usage over the last second. Without the -b option,
schmon shows resource usage information for the last age time period. The
age time period is defined by the schmon -t command.
Utilities

schmon -M
Syntax element
Description
-d
The following symbols precede numbers that appear in the output from the
-d option.
An unsigned number indicates the value has increased by the indicated
For examples of the -d option output, see schmon -m on page 123.
delay [reps]
Monitors resource usage over time by causing schmon to run again

automatically after a specified delay using the current -M options. delay is a
positive integer that specifies the number of seconds between schmon
executions.
times schmon should run. If reps is not specified, schmon runs indefinitely,
with delay seconds between executions.
Note: The difference between time stamps of successive information
displays may not precisely match the specified delay value due to the time
required for the collection activity itself.
Usage Notes
You can type this command from any node in an MPP system. The statistics are described in
the following table.
Statistics category
Description
Stats
The date and time of the statistics displayed, as well as repetition number, if you specify multiple
repetitions.
Utilities
131

schmon -M
Statistics category
Description
Resource Partitions
The statistics for each active Resource Partition, including the following:
RP specifies the Resource Partition ID Number.
Rel Wgt specifies the weight of the Resource Partition relative to the active Resource Partitions.
considerations:
132

Avg CPU specifies the resource usage during the preceding age period for a single CPU. The CPU
data is shown in two columns.
The % column is the percentage of CPU consumed by the Resource Partition. When statistics
The msec column is the milliseconds of CPU time consumed by the Resource Partition.
Avg I/O specifies a normalized number of data blocks transferred by the Resource Partition.
When statistics are collected from all nodes in an MPP system, this is the average normalized
resource use per Resource Partition for all nodes on the Teradata Database system. I/O data is
shown in two columns.
The % column is the percentage of disk consumed by the Resource Partition. When statistics
The sblks column is the number of blocks read and written by the Resource Partition.
Avg # of Tasks specifies the number of tasks assigned to the Resource Partition at the end of the
the average per Resource Partition for all nodes.
Avg # of Sets specifies the number of Scheduling Sets associated with the Resource Partition at
the end of the preceding collection period. There is one Scheduling Set per session.
Minimum CPU specifies the lowest value in milliseconds of CPU resource usages from all nodes.
Minimum I/O specifies the lowest value of I/O data blocks transferred from all nodes in sblks.
Minimum Tasks specifies the lowest number of tasks from all nodes.
Maximum CPU specifies the highest value in milliseconds of CPU resource usages from all
nodes.
Maximum I/O specifies the highest value of I/O data blocks transferred from all nodes in sblks.
Maximum Tasks specifies the highest number of tasks from all nodes.
Utilities

schmon -M
Statistics category
Description
Allocation Groups
The statistics for each active Allocation Group, including the following:
AG specifies the Allocation Group ID Number.
Rel Wgt specifies the weight of the Allocation Group relative to the active Allocation Groups of
the Resource Partition and the active Resource Partitions.
considerations:
Avg CPU specifies the resource usage by the Allocation Group during the preceding age period
for a single CPU. The CPU data is shown in two columns.
The % column is the percentage of total available CPU on the node consumed by the
Allocation Group. When statistics are collected from all nodes in an MPP system, this is the
average percentage for all nodes.
The msec column is the milliseconds of CPU usage consumed by the Allocation Group.
Avg I/O specifies a normalized number of data blocks transferred by the Allocation Group. When
statistics are collected from all nodes in an MPP system, this is the average normalized resource
use per Allocation Group for all nodes on the Teradata Database system. I/O data is shown in two
columns.
The % column is the percentage of total I/O blocks transferred by the Allocation Group.
When statistics are collected from all nodes in an MPP system, this is the average percentage
for all nodes.
The sblks column is the number of blocks read and written by the Allocation Group.
Avg # of Tasks specifies the number of tasks assigned to the Allocation Group at the end of the
the average per Allocation Group for all nodes.
Avg # of Sets specifies number of Scheduling Sets associated with the Allocation Group at the end
of the preceding collection period. When statistics are collected from all nodes in an MPP system,
this is the average per Allocation Group for all nodes. There is one Scheduling Set per session.
When you submit the -M command on an MPP system, the following minimum and maximum
values are displayed:
Minimum CPU specifies the lowest value in milliseconds of CPU resource usages from all nodes.
Minimum I/O specifies lowest value of I/O data blocks transferred from all nodes in sblks.
Minimum Tasks specifies the lowest number of tasks from all nodes.
Maximum CPU specifies the highest value in milliseconds of CPU resource usage from all nodes.
Maximum I/O highest value of I/O data blocks transferred from all nodes in sblks.
Maximum Tasks highest number of tasks from all nodes.
When you submit the -M command or specify the -p option on an SMP system, the affected
Performance Groups are displayed instead of the minimum and maximum values:
Performance Groups Affected specifies all Performance Groups by name that reference the
Allocation Group at that time. Since Allocation Groups can be shared among Performance
Groups, this information is useful for resource usage traceback. (This information is not
displayed when statistics are collected from all nodes in an MPP system unless you use the -p
option.)
Note: System information is listed under AG 200. This AG has Rel Wgt set to MAX, which indicates
that system work receives the maximum priority, but is not in any Rel Wgt calculations.
Utilities
133

schmon -M
Statistics category
Description
Work Requests
Displays work request statistics for each active Allocation Group. This data refers to the preceding
age period and is the average for all nodes on a multi-node Teradata Database system. The data
includes the following:
AG specifies the Allocation Group number.
# of requests specifies the number of work requests received.
Avg queue wait specifies the average time, in milliseconds, that a work request waited on an
input queue before being serviced.
Avg service time specifies average time, in milliseconds, that a work request required for service.
For the -M option:
displayed.
Example 1
schmon -M
Stats: 4 node(s)
Tue Oct 25 14:10:18 2005
Avg
Rel
Avg CPU
Avg I/O
# of
RP Wgt % (msec)
% (sblks) Tasks
== === === ======= === ======= =====
0 100
8
5059 94
1362
10
Avg
Node Resource Usage
# of
Minimum
Maximum
Sets
CPU
I/O Tasks
CPU
I/O Tasks
===== ====== ===== ===== =============== ======
1 997
1224
9
17120
1611
11
Avg
Rel
Avg CPU
Avg I/O
# of
Wgt % (msec)
% (sblks) Tasks
=== === ======= === ======= =====
13
8
5059 94
1362
10
MAX
2
1577
5
73
83
Avg
Node Resource Usage
# of
Minimum
Maximum
Sets
CPU
I/O Tasks
CPU
I/O Tasks
===== ====== ===== ===== =============== ======
1 997
1224
9
17120
1611
11
1 211
63
82
5569
87
85
AG
==
2
200

time(msec)
=== ========== ========== ========== ===========
2
1147
1.04
0.02
59.15
200
7
5.03
0.00
195.83
Minimum
time(msec)
=== ========== ========== ========== ===========
2
1129
0.76
0.01
48.16
200
14
0.00
0.00
186.07
134
Utilities

schmon -M
Maximum
time(msec)
=== ========== ========== ========== ===========
2
1160
1.34
0.03
81.36
200
16
9.44
0.00
204.38
Example 2
The following example shows a four-node MPP system with one node where PDE is NULL.
To monitor Priority Scheduler statistics for all nodes with a five-second delay between two
repetitions of the display, type:
schmon -M 5 2

Stats Collection #1: 3 node(s)
Sat Aug 30 08:44:31 2003
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
RP Wgt % (msec)
% (sblks) Tasks Sets CPU
I/O Tasks CPU
I/O Tasks
=== === === ======= === ======= ===== ===== ================= ==================
0 100
0
29
0
0
20
1
4
0
1 85
0
57
AG
===
2
4
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
Wgt % (msec)
I/O Tasks CPU
I/O Tasks
=== === ======= === ======= ===== ===== ================= ==================
18
0
29
0
0
1
0
4
0
1 83
0
3
72
0
0
0
0
19
0
2
0
57
2
0
57
Stats Collection #2: 3 node(s)
Sat Aug 30 08:44:36 2003
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
RP Wgt % (msec)
I/O Tasks CPU
I/O Tasks
=== === === ======= === ======= ===== ===== ================= ==================
0 100
0
54
0
0
20
1
1
0
1 154
0
57
AG
===
2
4
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
Wgt % (msec)
I/O Tasks CPU
I/O Tasks
=== === ======= === ======= ===== ===== ================= ==================
18
0
54
0
0
1
1
1
0
1 152
0
3
72
0
0
0
0
19
0
2
0
57
2
0
57
Example 3
The following example shows a four-node MPP system with one node where PDE is NULL.
This display also appears if you execute the -M command (with or without the -p option) on
an SMP system.
To display Performance Group names associated with the Allocation Groups that are
displayed with the -M command on an MPP system, type:
schmon -M -p
Utilities
135

schmon -M
Stats: 3 node(s)
Sat Aug 30 08:45:35 2003
Avg
Rel
Avg CPU
Avg I/O
# of
RP Wgt % (msec)
% (sblks) Tasks
=== === === ======= === ======= =====
0 100
0
44
0
0
1
Avg
# of
Sets
===== ==============================
1
Avg
Rel
Avg CPU
Avg I/O
# of
AG Wgt % (msec
% (sblks) Tasks
=== === === ======= === ======= =====
2 18
0
44
0
0
1
Avg
# of
Sets Performance Groups Affected
===== ==============================
1 M
Example 4
To display the names of the nodes that have the minimum and maximum resource usage,
type:
schmon -M -n

Stats: 4 node(s)
Tue Oct 25 14:10:18 2005
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
RP Wgt % (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== === === ======= === ======= ===== ===== ===================== ===================
0 100
8
5059 94
1362
10
1
997
1224
9
17120
1611
11
AG
===
2
200
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
Wgt % (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== === ======= === ======= ===== ===== ===================== ===================
13
8
5059 94
1362
10
1
997
1224
9
17120
1611
11
MAX
2
1577
5
73
83
1
211
63
82
5569
87
85
Node Names:
RP/AG CPU_min
===== ==========
RP0
tnt45_byne
AG2
tnt45_byne
AG200 tnt44_byne
CPU_max
==========
tnt47_byne
tnt47_byne
tnt47_byne
I/O_min
==========
tnt47_byne
tnt47_byne
tnt45_byne
I/O_max
==========
tnt46_byne
tnt46_byne
tnt47_byne
Tasks_min
==========
tnt45_byne
tnt45_byne
tnt45_byne
Tasks_max
==========
tnt44_byne
tnt44_byne
tnt44_byne

time(msec)
=== ========== ========== ========== ===========
2
1147
1.04
0.02
59.15
200
7
5.03
0.00
195.83
Minimum
time(msec)
=== ========== ========== ========== ===========
2
1129
0.76
0.01
48.16
200
14
0.00
0.00
186.07
Maximum
time(msec)
=== ========== ========== ========== ===========
2
1160
1.34
0.03
81.36
200
16
9.44
0.00
204.38
Node
RP/AG
=====
AG2
AG200
136
Names:
Rqsts_min
=========
tnt44_byn
tnt46_byn
Rqsts_max
=========
tnt47_byn
tnt47_byn
QWait_min
=========
tnt46_byn
tnt46_byn
QWait_max
=========
tnt47_byn
tnt47_byn
QLen_min
=========
tnt46_byn
tnt46_byn
QLen_max
=========
tnt47_byn
tnt47_byn
STime_min
=========
tnt44_byn
tnt46_byn
STime_max
========
tnt47_byn
tnt47_byn
Utilities

schmon -M
Example 5
To show RP and AG resource usage statistics, type:
schmon -M -s

Stats: 4 node(s)
Tue Oct 25 14:11:30 2005
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
RP Wgt % (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== === === ======= === ======= ===== ===== ===================== ===================
0 100
7
4637 95
1425
9
1
850
1203
9
15811
1608
11
AG
===
2
200
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
Wgt % (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== === ======= === ======= ===== ===== ===================== ===================
15
7
4637 95
1425
9
1
850
1203
9
15811
1608
11
MAX
2
1778
4
68
83
1
88
57
82
6652
81
85
Statistics:
RP 0 (4 Active Nodes):
CPU Median: 943.50
StdDev: 6451.43
Range
Freq
======================
850-2346
3
14323-15819
1
AG 2 (4 Active Nodes):
CPU Median: 943.50
StdDev: 6451.43
Range
Freq
======================
850-2346
3
14323-15819
1
CPU Median: 187.00
StdDev: 2814.08
Range
Freq
======================
88-744
3
6001-6657
1
I/O Median: 1444.50

StdDev: 171.08
Range
Freq
======================
1203-1243
1
1285-1325
1
1572-1612
2
I/O Median: 1444.50
StdDev: 171.08
Range
Freq
======================
1203-1243
1
1285-1325
1
1572-1612
2
I/O Median: 68.50
StdDev: 10.01
Range
Freq
======================
57-59
1
60-62
1
75-77
1
81-83
1
Tasks Median: 9.50

StdDev: 0.83
Range
Freq
======================
9-9
2
10-10
1
11-11
1
Tasks Median: 9.50
StdDev: 0.83
Range
Freq
======================
9-9
2
10-10
1
11-11
1
Tasks Median: 82.50
StdDev: 1.22
Range
Freq
======================
82-82
2
83-83
1
85-85
1

time(msec)
=== ========== ========== ========== ===========
2
1157
1.13
0.02
58.27
200
1
22.33
0.00
651.83
Minimum
time(msec)
=== ========== ========== ========== ===========
2
1152
0.78
0.01
49.87
200
1
0.00
0.00
372.20
Maximum
time(msec)
=== ========== ========== ========== ===========
2
1172
1.76
0.03
77.50
200
5
134.00
0.00
2050.00
Utilities
137

schmon -M
Statistics:
Requests Median: 1152.00
StdDev: 8.66
Range
Freq
======================
1152-1154
3
1170-1172
1
Que Wait Median: 1.00
StdDev: 0.38
Range
Freq
======================
0-0
2
1-1
2
Requests Median: 3.00
StdDev: 2.83
Range
Freq
======================
1-1
1
5-5
1
Que Wait Median: 67.00
StdDev: 94.75
Range
Freq
======================
0-13
1
126-139
1
Q Length Median: 0.00

StdDev: 0.00
Range
Freq
======================
0-0
4
Srv Time Median: 52.90
StdDev: 11.16
Range
Freq
======================
49-51
1
52-54
2
76-78
1
Q Length Median: 0.00
StdDev: 0.00
Range
Freq
======================
0-0
2
Srv Time Median: 1211.10
StdDev: 1186.38
Range
Freq
======================
372-539
1
1884-2051
1
Example 6
To show statistics in verbose mode, which includes inactive nodes, type:
schmon -M -s -V

Stats: 4 node(s)
Rel
RP Wgt
=== ===
0 100
AG
===
2
3
4
200
Tue Oct 25 14:13:53 2005

Avg
Avg
Node Resource Usage
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
% (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== ======= === ======= ===== ===== ===================== ===================
11
6999 93
2422
11
1
2559
2273
9
19741
2602
12
Avg
Avg
Node Resource Usage
Rel
Avg CPU
Avg I/O
# of # of
Minimum
Maximum
Wgt % (msec)
CPU
I/O Tasks
CPU
I/O Tasks
=== === ======= === ======= ===== ===== ===================== ===================
13 11
6973 93
2422
10
1
2559
2273
9
19638
2602
12
26
0
92
0
0
2
1
92
0
2
92
0
2
53
0
11
0
0
0
1
11
0
0
11
0
0
MAX
3
2196
6
174
83
1
428
160
82
7351
189
85
Statistics:
RP 0 (4 Active Nodes):
CPU Median: 2849.00
StdDev: 7359.65
Range
Freq
======================
2559-4277
3
18030-19748
1
CPU Median: 2849.00
StdDev: 7315.07
138
I/O Median: 2406.50

StdDev: 142.57
Range
Freq
======================
2273-2305
2
2504-2536
1
2570-2602
1
I/O Median: 2406.50
StdDev: 142.57
Tasks Median: 11.50

StdDev: 1.22
Range
Freq
======================
9-9
1
11-11
1
12-12
2
Tasks Median: 10.50
StdDev: 1.12
Utilities

schmon -M
Range
Freq
======================
2559-4266
3
17931-19638
1
AG 3 (1 Active Node):
CPU Median: 92.00
StdDev: 0.00
Range
Freq
======================
92-92
1
I/O Median: 0.00

StdDev: 0.00
Range
Freq
======================
0-0
1
Range
Freq
======================
9-9
1
10-10
1
11-11
1
12-12
1
Tasks Median: 2.00
StdDev: 0.00
Range
Freq
======================
2-2
1
AG 3 (All Nodes):
CPU Median: 0.00
StdDev: 39.84
I/O Median: 0.00

StdDev: 0.00
Tasks Median: 0.00

StdDev: 0.87
AG 4 (1 Active Node):
CPU Median: 11.00
StdDev: 0.00
I/O Median: 0.00

StdDev: 0.00
Tasks Median: 0.00

StdDev: 0.00
Range
Freq
======================
11-11
1
Range
Freq
======================
0-0
1
Range
Freq
======================
0-0
1
AG 4 (All Nodes):
CPU Median: 0.00
StdDev: 4.76
I/O Median: 0.00

StdDev: 0.00
Tasks Median: 0.00

StdDev: 0.00

CPU Median: 503.50
StdDev: 2976.18
I/O Median: 173.50

StdDev: 12.67
Tasks Median: 82.50

StdDev: 1.22
Range
Freq
======================
428-1120
3
6665-7357
1
Utilities
Range
Freq
======================
2273-2305
2
2504-2536
1
2570-2602
1
Range
Freq
======================
160-162
1
163-165
1
184-186
1
Range
Freq
======================
82-82
2
83-83
1
85-85
1
139

schmon -p
schmon -p
Purpose
The schmon -p option sets or displays Performance Group parameters.
Syntax
schmon
-p
PG#
PGNAME
-s
-S
R
-T
PP
-d
delay
reps
-x
1102G010
Syntax Element
Description
-p
Sets or displays Performance Group parameters. If no additional options are

specified, schmon -p displays the parameters for all Performance Groups
currently in use (those with defined parameters).
PG#
An integer from 0 through 249 that identifies the Performance Group for which
To set parameters for a Performance Group, follow PG# with the PGName, R,
T, and PP specifications.
To view information about a specific Performance Group, follow PG# with
the -s or -S options, or with no options.
To clear all parameters for a specific Performance Group, follow PG# with the
-x option.
140
PGNAME
Specifies the name of the Performance Group with the Resource Partition.
Names with spaces must be enclosed in apostrophes.
Specifies the Resource Partition to which this Performance Group is to be

assigned.
Utilities

schmon -p
Syntax Element
Description
Specifies a single character that indicates the milestone type used in the
Performance Period definitions for that Performance Group, where:
Q indicates that milestone units are seconds (1 - 86400) of query resource
usage. Each query submitted by a session begins a new resource usage
accumulation at the first Performance Period defined for the Performance
Group.
R or S indicates that milestone units are seconds (1 - 86400) of session
resource usage. These two characters are equivalent.
T indicates that milestone units are time-of-day, in military time (0-2359).
Time-of- day units can be optionally preceded by a day-of-week indicator.
Day-of-week format is:
'/d1-d2/ or /d1,d2,...dn/'. Valid values for day are 0(Sun)-6(Sat). For
example, '/3-5/' indicates that the associated Performance Period would be
active Wednesday through Friday.
PP
A Performance Period pair consisting of a milestone limit value and Allocation

Group number for each of up to eight Performance Periods.
Allocation groups can be referenced by multiple Performance Groups, which
must belong to the same Resource Partition.
When the milestone type is Q, R, or S, the lower bound for the first Performance
Period is assumed to be zero. Also, the milestone of the last Performance Period
must be zero. After a session or query enters the last Performance Period, that
period remains in control for the remainder of the session or query.
When the milestone type is Q, R, or S, the milestone limit is a real number
greater than 0 and less than 86400. You can enter this number with an optional
decimal point and fractional value. The given number is rounded to the nearest
1/100 second value. The following examples are valid milestone limit CPU usage
times:
Utilities
.01
2.5
3.1415
200
-s
Displays Priority Scheduler data for all sessions controlled by the Performance
Group on the current node.
-S
Displays Priority Scheduler data for all sessions controlled by the Performance
Group on all nodes of the Teradata Database system.
141

schmon -p
Syntax Element
Description
-T
Displays tasks (threads) for the specified Performance Group on the current
node (the node from which schmon was invoked). Even when used in
conjunction with the -S option, -T will display only task data for the current
node.
Note: The -T option should not be used for prolonged periods of time, because
it can interfere with the normal operation of Priority Scheduler.
-d

Tskid: Thread ID
Prio: OS priority
option.
142
Utilities

schmon -p
Syntax Element
Description
delay [reps]
Causes schmon -p to run again automatically after a specified delay using the
times schmon should run. If reps is not specified, schmon runs indefinitely with
delay seconds between executions. In this case, schmon can be stopped by
pressing Ctrl-C or otherwise killing the schmon process.
Note: The difference between time stamps of successive information displays
may not precisely match the specified delay value due to the time required for
the collection activity itself.
-x
Clears the parameters that define the specified Performance Group, effectively
deleting it from the system (though an empty group will still appear in the
output of schmon -p all).
The Teradata Database must be in the logons enabled state to delete a
Performance Group. The Performance Group must not be referenced by any
system user.
Under certain circumstances, the deletion process of a Performance Group
within schmon may be rejected and the cleanup process may not be executed
successfully. In this situation, any subsequent attempts to delete the
Performance Group will fail and the following error message is reported:
schmon -p 4 -x
schmon: Performance Group is in remove state
If this occurs, do the following:

1 Recreate the Performance Group by executing the proper schmon -p
command.
Recreating the Performance Group clears the remove status.
2 Delete the Performance Group created in step one by executing the proper
schmon - p command using the format below.

schmon -p PG# -x
For example, to delete Performance Group 4, type:
schmon -p 4 -x
Usage Notes
If a Performance Group has only a single Performance Period, the milestone limit must be
zero.
If a Performance Group has multiple Performance Periods, the milestone limit of the final
Performance Period must be zero.
Utilities
143

schmon -p
For the -S option:
displayed.
Example 1
To display session data for sessions assigned to Performance Group 1, type:
schmon -p 1 -s

Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
2
0
0
0
26
500310
16607
500310
16607
0 M[0]
Example 2
Suppose you want to provide different levels of service on weekdays, Saturday, and Sunday.
On weekdays, one Performance Period is in effect between 0800 and 1800, another beginning
at 1800 and continuing until 0800 the next morning.
On Saturday the Performance Period from 1800 on Friday continues until 1400 and then
switches to another Performance Period that continues through Sunday and on until 0800
Monday morning. The Performance Period specification is as follows, where day of the week is
denoted by enclosing / characters, as shown below:
/1/ 0800 5 Monday, use AG 5 until 0800
/2-5/ 0900 7 Tuesday through Friday, use AG 7 until 0900
/1-5/ 1800 2 Monday through Friday, use AG 2 until 1800. After 1800, use the next higher
period.
/6/ 1400 7 Saturday, use AG 7 until 1400. After 1400, use the next Performance Period,
which is the one specified for 0800 Monday that uses AG 5.
To provide the above levels of service, type:

schmon -p 2 M 0 T /1/ 0800 5 /2-5/ 0900 7 /1-5/ 1400 2
/6/ 1800 7

Id
2
144
Group Name
M
Performance Groups (0 - 249)

RP Type Milestones & Allocation Groups[0-7]
0 T /1/ 0800
5 /2-5/ 0900
7 /1-5/ 1400
2 /6/ 1800
Utilities

schmon -s
schmon -s
Purpose
The schmon -s option displays Priority Scheduler data for the specified sessions from the
current node or all nodes in the Teradata Database system.
Syntax
schmon
-s
all
-S
-T
-d
delay
reps
id
1102E071
Syntax Element
Description
-s
Displays Priority Scheduler data for the current sessions. If no additional

options are specified, schmon -s displays session information for the current
node.
all
Shows information for all sessions. This is the default.
id
A positive integer that identifies a session for which Priority Scheduler data
will be displayed.
-S
Shows session information from all nodes in Teradata Database.
-T
Displays tasks (threads) for the specified sessions on the current node (the
node from which schmon was invoked). Even when used in conjunction
with the -S option, -T will display only task data for the current node.
Note: The -T option should not be used for prolonged periods of time,
because it can interfere with the normal operation of Priority Scheduler.
Utilities

Tskid: Thread ID
Prio: OS priority
145

schmon -s
Syntax Element
Description
-d
The following symbols precede numbers that appear in the output from the
-d option.
delay [reps]
Causes schmon -s to run again automatically after a specified delay using the
current options. delay is a positive integer that specifies the number of
times schmon should run. If reps is not specified, schmon runs indefinitely
with delay seconds between executions. In this case, schmon can be stopped
by pressing Ctrl-C or otherwise killing the schmon process.
The difference between time stamps of successive information displays may
not precisely match the specified delay value due to the time required for the
collection activity itself.
Note: The delay option cannot be used alone with schmon -s. It must be
preceded by one or more of the id, all, -S, -T, or -P options.
Usage Notes
schmon -s displays the following columns:
146
Column
Description
AG
Allocation Group ID.
Host ID
Host system of an active session.
Session
Session number of an active session.
Request
Request number of an active session.
#tsk
Number of tasks working on behalf of the session.
Utilities

schmon -s
Column
Description
CPU(msec)
Number of milliseconds of CPU time accumulated by the session or request

during the previous age period.
DSK(blk)
Number of disk blocks transferred by the session or request during the previous
age period.
RP
Resource Partition to which the lines allocation group belongs.
PG
Performance Group to which the session is assigned.
[PP]
Performance Period currently controlling the session. Each Performance Group

defines one or more Performance Periods. A PGs PPs determine the resource
allocation to tasks run by sessions controlled by the PG. For more information
on PGs and PPs, see Performance Groups on page 85
Example 1
In this example and the following examples, session 0 indicates a session performing system
utility functions that might have tasks running in several allocation groups.
To display Priority Scheduler data for the specified sessions from the current node or all nodes
in the Teradata Database system, type:
schmon -s

Stats: Mon Mar
8 15:49:57 2008
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
1
0
0
0
9
70
10250
70
10250
0 L[0]
2
0
0
0
2
2640
0
2640
0
0 M[0]
4
0
0
0
1
1
0
1
0
0 R[0]
Utilities
147

schmon -s
Example 2
The -T option displays per-AG task (thread) information for the specified sessions. This
example shows a portion of the output from a Linux system.
schmon -s all -T
Stats: Fri Feb
5 13:50:32 2010
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
5
1025
1000
4
9
245516
165488
245488
165488
1 PG5[0]
5
1025
1001
3
9
164620
103089
164600
103089
1 PG5[0]
Tsk Addr
Tskid Prio Session Request
Tskuse Setterm # Delay Delay Time
==================== ====== ==== ======= ======= ========== ======= ======= ==========
0xffffc20013310c20
8004 126
1000
4
28
78
0
0
0xffffc20011f6e420
8485 126
1000
4
30172
78
0
0
0xffffc20011fee620
8467 126
1000
4
29576
78
0
0
0xffffc20018484e20
8457 126
1000
4
30240
78
0
0
0xffffc20011f6f220
8492 129
1001
3
19460
100
0
0
0xffffc20013332720
8522 129
1001
3
23316
100
0
0
0xffffc20018486320
8473 129
1001
3
19872
100
0
0
0xffffc200135c6020
8520 129
1001
3
24208
100
0
0
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
200
0
0
0 554
32912
3795
3532
211
0 System[0]
200
0
6146
11
0
0
0
0
0
0 System[0]
200
0
6147
9
0
0
0
0
0
0 System[0]
200
0
6280
1002
0
0
0
0
0
0 System[0]
200
0
6284
1003
0
0
0
0
0
0 System[0]
200
0
6285
1003
0
0
0
0
0
0 System[0]
Tsk Addr
==================== ====== ==== ======= ======= ========== ======= ======= ==========
0xffffc20011be0020
7015 116
0
0
0
0
0
0
0xffffc20011be0720
7136 116
0
0
0
0
0
0
0xffffc20011be0e20
7137 116
0
0
0
0
0
0
0xffffc20011be1520
7138 116
0
0
0
0
0
0
0xffffc20011be1c20
7139 116
0
0
124
0
0
0
0xffffc20011e74720
7144
1
0
0
0
0
0
0
0xffffc20011f2a020
7142
1
0
0
0
0
0
0
Example 3
This example displays differences in session data over three automatic runs of schmon spaced
five seconds apart.
> schmon -s -d 5 3
Stats Collection #1: Mon Aug 04 17:53:14 2008
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
200
0
0
0
0
1710
12
1710
12
0 System[0]
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
200
0
0
0
0
1545
0
1545
0
0 System[0]
No difference in data this period
148
Utilities

schmon -s
Example 4
This example shows a portion of the output that displays differences in session data over three
automatic runs of schmon spaced five seconds apart, and includes information on tasks for
the current node.
schmon -s -T -d 5 3
Stats Collection #1: Fri Feb
5 14:13:22 2010
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
5
1025
1000
5
-2
2796
1724
2796
1724
1 PG5[0]
5
1025
1001
4
0
7396
5288
7396
5288
1 PG5[0]
Tsk Addr
==================== ====== ==== ======= ======= ========== ======= ======= ==========
0xffffc20013a4b320
10425
0
1000
5
640
0
5
3724
0xffffc20013a49720
10428
2
1001
4
1064
11
5
3724
5 14:13:27 2010
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
5
1025
1000
5
0
176
116
176
116
1 PG5[0]
5
1025
1001
4
0
220
148
220
148
1 PG5[0]
Tsk Addr
==================== ====== ==== ======= ======= ========== ======= ======= ==========
0xffffc20013a4b320
10425
-1
1000
5
44
-5
5
4956
0xffffc20013a49720
10428
1
1001
4
28
11
5
4956
5 14:13:32 2010
Session Usage
Query Usage
AG HostID
Session
DSK(blk) CPU(msec)
DSK(blk) RP PG [PP]
=== ====== ========== ========== ==== ========== ========== ========== ========== === ===============
5
1025
1000
5
-1
2648
1738
2648
1738
1 PG5[0]
5
1025
1001
4
0
3920
2758
3920
2758
1 PG5[0]
Tsk Addr
==================== ====== ==== ======= ======= ========== ======= ======= ==========
- 0xffffc20013a4b320
10425 -128
1000
5
-35856
-95
-44
-33800
0xffffc20013a49720
10428
0
1001
4
380
0
5
4376
Utilities
149

schmon -t
schmon -t
Purpose
The schmon -t option sets or displays Age Time, Active Time, and Dispatch Wait Time.
Syntax
schmon
-t
age
active
disp
1102C072
Syntax element
Description
-t
Sets or displays Age Time, Active Time, and Dispatch Wait Time.
If no additional options are specified, schmon -t displays the current settings. If
any options are specified, all three options must be specified, regardless of
operating system.
age
Age Time. The time period, in seconds, over which recent Allocation Group
resource usage is measured.
The range is 1 to 60 seconds. The default is 60 seconds.
active
Active Time. The time period, in seconds, during which an Allocation Group is
considered active if any task assigned to the Allocation Group has been scheduled.
Inactive Allocation Groups are not included in resource consumption
calculations.
The range is 1 to 1800 seconds. The default is 61 seconds.
disp
Note: This option is meaningful only on Linux. The Dispatcher Wait Timer is
also known as the anti-starvation mechanism.
Dispatch Wait Time. The maximum period of time, in seconds, that a task can
wait in a ready-for-execution state in a dispatch queue without receiving access to
a CPU. After this time, the task priority is increased and its wait period is reinitialized.
The range is -1 through 127. The default is 4 seconds.
The following values apply:
0 specifies that the Dispatch Wait Time be set to the factory default of four
seconds.
-1 specifies that the Dispatch Wait Timer be disabled.
Note: The Dispatch Wait Timer is enabled by default.
Caution:
Teradata recommends that you do not use this setting unless absolutely
necessary.
1 -127 specifies a wait period in seconds.
150
Utilities

schmon -t
Example
To view the current settings, type:
schmon -t

Age Time(sec):
60
Active Time(sec):
61
Disp Age(sec):
To change the settings, type:

schmon -t 30 31 5

Age Time(sec):
60
>>>>> Changed to:
Age Time(sec):
30
Utilities
Active Time(sec):
61
Disp Age(sec):
Active Time(sec):
31
Disp Age(sec):
151

schmon -w
schmon -w
Purpose
The schmon -w option sets or displays the number of tasks available on each vproc for use by
work requests assigned to Allocation Groups having the Expedite attribute.
Syntax
schmon
-w
reserve
maximum
HH01A011
Syntax element
Description
-w
Sets or displays the number of tasks available on each vproc for use by work requests assigned to
Allocation Groups having the Expedite attribute.
Without options, schmon -w displays the current settings.
reserve
A number from 0 through 20, that indicates the number of AWTs reserved within each AMP for work
requests assigned to Allocation Groups having the EXPEDITE attribute.
This reserve ensures that at least this specified number of AWTs will be ready to service a work request
when it arrives. When the number of expedited work requests exceeds this reserve, arriving expedited
work requests might be forced to wait in an input queue, depending on overall work load conditions.
This reserve determines the minimum number of expedited work requests that will run concurrently.
This reserve, multiplied by three, is deducted from the general pool of AWTs and will impact the
number of tasks available for normal non-expedited work requests.
Teradata recommends the following:
Initially select a low number for reserve (1-3).
Expedite only Allocation Groups supporting short, response-sensitive queries.
maximum
A number between 1 and 999, inclusive, that indicates the maximum number of AWTs that can run at
any time.
The number of tasks that run might be less than this maximum, depending on the current limit. Since
the special reserve work type supports new work, similar to MSGWORKNEW, one reasonable setting
for the parameter is the same as the MSGWORKNEW maximum(50).
Note: Since most systems have a practical limit of 80 AMP worker tasks per AMP that can be supported
at any one time, the 999 value has no real function.
152
Utilities

schmon -w
Usage Notes
The Expedite attribute is defined by an Allocation Group. For more information see Expedite
Attribute on page 94 and AMP Worker Task (AWT) Reservations and Limits on page 98.
Consider scripting a set of schmon commands for each restoration and maintenance.
Example 1
To display the number AWTs reserved within each AMP vproc for work requests assigned to
Allocation Groups having the EXPEDITE attribute and the maximum number of AWTs that
can run at any time, type:
schmon -w

res
0
max
999
Example 2
To set the number AWTs reserved within each AMP vproc for work requests assigned to
Allocation Groups having the EXPEDITE attribute and the maximum number of AWTs that
can run at any time, type:
schmon -w 5 10

res
0
max
999
>>>>> Changed to:

5
10
Utilities
153

schmon -w
154
Utilities
CHAPTER 22
Query Configuration (qryconfig)
The Query Configuration utility, qryconfig, reports the current Teradata Database system
configuration from a Teradata Database system console running the Database Window or
from a host terminal. This configuration is defined using the Configuration and
Reconfiguration utilities. For more information on the Configuration utility, see Utilities
Volume 1. For more information on the Reconfiguration Utility, see Chapter 25:
Reconfiguration Utility (reconfig).
The Query Configuration utility is also referred to as Configuration Display.
Runs From

such as cnsterm
Teradata Viwpoint Remote Console portlet
Host Utility Console
About Query Configuration

Vprocs and Physical Processors
The Query Configuration utility displays configuration information about the nodes in a
Teradata Database system. This utility supplies information about the PEs associated with the
node and the AMPs.
While physical processor identifiers are presented where appropriate in the configuration
displays, the focus of the Query Configuration utility is on the vprocs managed by the node.
These vprocs exist within a previously defined physical configuration. Use the Parallel
Upgrade Tool (PUT) to configure parts of the physical configuration, such as creating Logical
Units (LUNs) on disk arrays. See your Parallel Upgrade Tool (PUT) Reference.
Display Options
The Query Configuration utility can display a variety of status and configuration information
for the entire Teradata Database system or portions of the system including the following:
Utilities
155
Chapter 22: Query Configuration (qryconfig)

Query Configuration Options
Complete configuration
Node, online or offline
AMPs, online or offline
PEs, online or offline

You can display all or parts of the current Teradata Database system configuration by entering
various Query Configuration options.
The following sections describe the options and their use:
ALL
Processors
Online processors
Offline processors
AMPs
Online AMPS
Offline AMPs
PEs
Online PEs
Offline PEs
In a large Teradata Database system configuration, use discretion when selecting the All,
AMPs, and Online AMPs options, because of the potentially large numbers of output lines
that may be produced.
Instead of the All, AMPs, and Online AMPs options, consider Processor level options or the
Offline AMPs and Offline PEs options when the configuration is large, to avoid having to deal
with large numbers of Query Configuration output lines consuming valuable space and time
resources.
ALL Option
To produce a display of all the components in the Teradata Database system and their current
status, use the ALL option. The following is an example of an ALL display.
Enter display option,
all
QUIT or END to terminate.
DBS Configuration Status Report: 00/06/13 18:31:23

Vproc
Node Config Config Cluster/
Number
ID
Type Status Host No.
------ ------- ---- -------- -------0
1-01 AMP Online
0
2
1-01 AMP Online
1
156
Vproc
Number
ID
------ ------- ---- -------- -------1
1-01 AMP Online
0
3
1-01 AMP Online
1
Utilities

4
6
8
10
12
14
16
18
16380
16382
1-01
1-01
1-01
1-01
1-01
1-01
1-01
1-01
1-01
1-01
AMP
AMP
AMP
AMP
AMP
AMP
AMP
AMP
PE
PE
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
2
3
4
5
6
7
8
9
1
5
7
9
11
13
15
17
19
16381
1-01
1-01
1-01
1-01
1-01
1-01
1-01
1-01
1-01
AMP
AMP
AMP
AMP
AMP
AMP
AMP
AMP
PE
Online
Online
Online
Online
Online
Online
Online
Online
Online
2
3
4
5
6
7
8
9
1
The information in the ALL display is ordered by vproc number. The display shows the
following for each vproc:
The identifier (Node ID) of the Node associated with each vproc (virtual processor).
The type (AMP or PE) of each vproc.
The status (online or offline) of each vproc. A status of Online means that the associated
Node is available and online to the operating system.
The cluster (for an AMP) or host number (for a PE) associated with each vproc.
Processors Option
To obtain configuration information for all processors in the Teradata Database system, use
the Processors option. This option produces a display identical to that produced by the ALL
Option on page 156.
Online Processors or Offline Processors Options

Configuration information for all online or all offline processors that is similar to that of all
processors is also available.
To obtain configuration information for online processors, use the Online Processors option.
This option includes the same information as the all processors display option with the
exception of the Status column. The following is an example of an Online Processors display.
online processors

Vproc
Number
-----0
2
4
6
8
10
12
14
16
18
16380
Utilities
Node
Config Cluster/
ID
Type HostId
------- ---- -------1-01
AMP
0
1-01
AMP
1
1-01
AMP
2
1-01
AMP
3
1-01
AMP
4
1-01
AMP
5
1-01
AMP
6
1-01
AMP
7
1-01
AMP
8
1-01
AMP
9
1-01
PE
1
Vproc
Number
-----1
3
5
7
9
11
13
15
17
19
16381
Node
Config Cluster/
ID
Type Host No.
------- ---- -------1-01
AMP
0
1-01
AMP
1
1-01
AMP
2
1-01
AMP
3
1-01
AMP
4
1-01
AMP
5
1-01
AMP
6
1-01
AMP
7
1-01
AMP
8
1-01
AMP
9
1-01
PE
1
157

16382
1-01
PE
16383
1-01
PE
To obtain configuration information for offline processors, use the Offline Processors option.
The information displayed is similar to that for all processors, but the Status column does not
appear, since only offline processors are displayed.
AMPs Option
To obtain configuration information for all AMPs in the Teradata Database system, use the
AMPs option. It produces a display containing AMP numbers, node identifiers, status (online
or offline), and cluster numbers. The following is an example of an AMPs configuration
display.
amps

Vproc
Number
ID
------ ------- ---- -------- -------0
1-01 AMP Online
0
2
1-01 AMP Online
1
4
1-01 AMP Online
2
6
1-01 AMP Online
3
8
1-01 AMP Online
4
10
1-01 AMP Online
5
12
1-01 AMP Online
6
14
1-01 AMP Online
7
16
1-01 AMP Online
8
18
1-01 AMP Online
9
Vproc
Number
ID
------ ------- ---- -------- -------1
1-01 AMP Online
0
3
1-01 AMP Online
1
5
1-01 AMP Online
2
7
1-01 AMP Online
3
9
1-01 AMP Online
4
11
1-01 AMP Online
5
13
1-01 AMP Online
6
15
1-01 AMP Online
7
17
1-01 AMP Online
8
19
1-01 AMP Online
9
Online AMPS or Offline AMPs Options

The same type of configuration information previously described for all AMPs is also available
for all online or all offline AMPs.
To obtain configuration information for online AMPs, use the Online AMPs option. The
information displayed is similar to that for all AMPs, but the Status column does not appear,
since only online AMPs are displayed.
To obtain configuration information for offline AMPs, use the Offline AMPs option. The
information displayed is similar to that for all AMPs, but the Status column does not appear,
since only offline AMPs are displayed.
PEs Option
To obtain configuration information for all PEs in the Teradata Database system, use the PEs
option. It produces a display containing PE numbers, node identifiers, status (online or
offline), and host numbers. The following is an example of a PEs configuration display.
158
Utilities

pes

Vproc
Number
ID
------ ------- ---- -------- -------16380
1-01 PE
Online
1
16382
1-01 PE
Online
1
Vproc
Number
ID
------ ------- ---- -------- -------16381
1-01 PE
Online
1
16383
1-01 PE
Online
1
Online PEs and Offline PEs Options

The same type of configuration information available as described above for all PEs is also
available for all online or all offline PEs.
To obtain configuration information for online PEs, use the Online PEs option. The
information displayed is similar to that for all PEs, but the status is Online for each PE listed.
To obtain configuration information for offline PEs, use the Offline PEs option. The
information displayed is similar to that for all PEs, but the status is Offline for each PE listed.
Getting HELP
To produce a list of all of the Query Configuration options, type HELP or question mark (?).
The list of options appears as follows:
help
The following key words return the indicated display.

All;
- complete configuration.
Processors;
- processor status.
Online Processors;
- online processors.
Offline Processors;
- offline processors.
AMPs;
- AMP status.
Online AMPs;
- online AMPs.
Offline AMPs;
- offline AMPs.
PEs;
- PE status.
Online PEs;
- online PEs.
Offline PEs;
- offline PEs.
As indicated in the HELP option list, type a keyword to produce the desired display.
Utilities
159

160
Utilities
CHAPTER 23
Query Session (qrysessn)
The Query Session utility, qrysessn, provides information about active Teradata Database
sessions. It allows you to monitor the state of all or selected database sessions on all or selected
logical host IDs attached to the Teradata Database. Query Session is also known as Session
States.
This chapter provides an overview of the information Query Session reports as well as several
sample Query Session displays.
Because the Query Session displays for sessions involved in Archive and Recovery, FastLoad,
MultiLoad (MLOAD), and FastExport operations are different from other session displays,
these displays are described at the end of this chapter.
Runs From

such as cnsterm
Query Session States

Query Session provides information on the following possible states of a session.
Utilities
The Session State...
Indicates that...
ABORTING
the session is aborting its latest request.
ACTIVE
the session has sent steps to the dispatcher and possibly to one or
more AMP vprocs.
BLOCKED
an active session is waiting for a database lock to be released.
DELAYED
the session is being delayed because query limit, imposed by a

Teradata Active System Management (ASM) throttle rule, has been
met.
161
Chapter 23: Query Session (qrysessn)

Parent and Child Sessions
The Session State...
Indicates that...
IDLE
the Teradata Database system recognizes a session, but no

processing is taking place.
INDOUBT
a two-phase commit session is in doubt.
INDOUBT PARSING
a two-phase commit session is in doubt and is parsing a vote or

commit request.
PARSING
the session is active in the Teradata SQL parser phase, before the
steps are dispatched to the AMP vprocs.
QTDELAYED
the session is waiting for rows to be inserted into a queue table.
QUIESCED ABORT
the session is blocked from executing further requests because

transactions associated with this session are being aborted.
QUIESCED ABORT WITH

LOGOFF
the session is quiesced because the transactions or requests

associated with this session are being aborted, after which this
session will be logged off the machine.
QUIESCED INDOUBT
the session is blocked from exercising further requests because the

outstanding transaction/request will be terminated.
RESPONSE
a response to a session request is in process.
SESDELAYED
the session is being delayed because a utility limit, imposed by a

Teradata ASM throttle rule, has been met.
Parent and Child Sessions

When a connected session is part of either a FastLoad, MultiLoad, FastExport, or Archive and
Recovery operation, that session establishes subordinate sessions to accomplish the task more
quickly. The originating session is then called a Parent session; the subordinate sessions are
called Child sessions that belong to that Parent.
A Child session is not recognized as such, and its activity is not reported until it has
transmitted at least one request to the AMPs in the current transaction.
Information about the activity of Child sessions is available to Query Session when the Parent
session is in the Active state or when one of several inactive states described later in this
chapter.
In FastLoad operations, Child sessions exist and are reported only while the Parent session is
in the loading phase. In MultiLoad operations, Child sessions exist and are reported only
while the Parent session is in the acquisition phase. Query Session reports the status of Child
sessions when you request detail information.
162
Utilities

Query Session Displays
Query Session Displays

The following sections describe the Query Session displays that provide information on what
you can input. General Help displays are described first, followed by displays for sessions
involved in Archive and Recovery, FastLoad, FastExport, and MultiLoad operations.
After you have started Query Session, it prompts for the following:
Please Enter A Logical Host ID (? For Help)
You can type any of the following responses when you are prompted for the logical host ID.
IF you type...
THEN...
an integer
Query Session provides information only for the sessions

associated with the specified logical host ID.
an asterisk (*)
Query Session provides information on sessions for every

logical host.
a question mark (?)
you will get Help for this entry.
a carriage return (Enter)
you will exit from the Query Session utility.
If you type an integer or an asterisk, the following prompt displays:

Please Enter Session Ids (? For Help):
You can input any of the following when you are prompted for the Session ID.
IF you type...
THEN you see...
an integer to indicate a specific session ID
the following prompt:
Note: You can input up to five session Ids

in integer format. You can type them on
one line separated by spaces or on
multiple lines.
Is detail information needed if the

session is involved in HUT/FastLoad/
MLoad/Export?
y-yes, n-no
an asterisk (*)
the following prompt:
To view the Child session, type y.

If the session is not part of a FastLoad, MultiLoad,
FastExport, or an Archive and Recovery operation,
type n.
Is detail information needed if the

session is involved in HUT/FastLoad/
MLoad/Export?
y-yes, n-no
To view the Child session states, type y.

If the session is not part of a FastLoad, MultiLoad,
FastExport, or an Archive and Recovery operation,
type n.
a question mark
Utilities
help concerning input information.
163

Session State Display
Note: If an unsuccessful attempt was made to obtain temporary table information for the
given session, the following query session message could appear:
WARNING: Session may contain incomplete temporary table information due
to deadlock!
If temporary table information is important to you, then you should retry querying the
session at a later time.
Session State Display

The session state display consists of session identifier information and session state details.
Displays for sessions involved in FastLoad, MultiLoad, FastExport, or Archive and Recovery
operations provide additional information described later in this chapter.
If a session is idle, only the session identifier information is displayed, as shown below.
Host Session PE DBC User ID
---- ------- -- ----------110 1006
11 DBC
The columns for the Session Identifier display the following information.
The column named...
Contains the...
Host
logical host identifier.
Session
session identifier.
PE
PE number of the PE to which the session is assigned.
DBC User ID
user assigned to the session.
If a session is active, and not part of a FastLoad, MultiLoad, FastExport, or Archive and
Recovery operation, the following session state detail information displays.
Session State Query Results : 00/06/15 14:14:13
---- ------- -- ----------110 1006
11 DBC
State Details : ACTIVE
Statements Dispatched Time
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 14:22:09
2
22
164
Utilities

State Information Displays
Session State Details During Stored Procedure Execution

If a stored procedure is being executed, the following session state information is displayed.
---- ------- -- ----------110 1006
11 DBC
State Details : ACTIVE (Stored Procedure is executing)
The State Details correspond to the latest SQL request that the stored procedure executed.
Session State Details Pertaining to the Teradata Index Wizard

Query Session reports the index analysis state pertaining to the Teradata Index Wizard. If a
workload is being analyzed for indexes, the following session state information is displayed.
Host
---52
Session
------1893
PE
----16383
DBC User ID
----------USER1
State Details: <status>

Analyzing a workload for index recommendations.

This following sections provide session information for each possible state:
Utilities
ABORTING
ACTIVE
BLOCKED
DELAYED
IDLE
INDOUBT
INDOUBT PARSING
PARSING
QTDELAYED
QUIESCED ABORT
QUIESCED ABORT WITH LOGOFF
QUIESCED INDOUBT
RESPONSE
SESDELAYED
165

ABORTING State
The ABORTING state indicates that the session is aborting its latest request.
The ABORTING state display is shown below.
State Details : ABORTING
Statements Code Time
CPU Usage Accesses
---------- ---- -------- --------- -------1 1043 14:22:09
2
22
The columns on the ABORTING state display provide the following information.
The column named...
Contains the...
Statements
statements, up to the number displayed, that are aborting.
Code
error that caused the abort.
Time
time that the abort step was sent to the AMP.
CPU Usage
accumulated time in thousandths of a second that all AMPs spent

processing the current request.
Accesses
total number of segment access calls executed on all AMPs for the
session request.
ACTIVE State
The ACTIVE state indicates that the session has sent steps to the dispatcher and possibly to
one or more AMP vprocs.
The ACTIVE state display for a session not part of a FastLoad, MultiLoad, FastExport or
Archive and Recovery operation is shown below.
State Details : ACTIVE
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 14:22:09
2
22
The columns on the ACTIVE state display provide the following information.
166
The column named...
Contains the...
Statements
total number of statements in the current session request.
Dispatched
highest statement number dispatched to the AMPs.
Time
time that the last step in the highest statement number was sent to
the AMPs.
CPU Usage

Utilities

The column named...
Contains the...
Accesses
session request.
BLOCKED State
The BLOCKED state indicates that an active session is waiting for a database lock to be
released.
The BLOCKED state display for a session is shown below.
State Details : BLOCKED
Resource
------------------------------------------------------X.T
Statement AMPs Mode AMP Vproc HUT
--------- ---- ---- --------- --1
1 READ
19 NO
The columns on the BLOCKED state display provide the following information.
The column named...
Contains the...
Resource
database or table for which the lock is requested.

If the lock is requested for a database, the column displays the
information:
X.*
where:
X is the database name.
If the lock is requested for a table or row, the column displays the
information:
X.T
where:
X is the database name, and T is the table name.
Utilities
Statement
highest statement number for which steps have been dispatched to the
AMPs.
AMPs
number of AMPs for which the session is waiting to acquire a lock.
Mode
type of lock requested by the session.
AMP Vproc
number of the AMP with the blocked session.
HUT
host utility lock (if encountered).
167

DELAYED State
The DELAYED state indicates that an SQL request is delayed because a query limit has been
exceeded. When the limit is no longer exceeded, the delayed requests are processed.
Teradata Viewpoint Workload Designer portlet allows you to define and manage throttle
rules, which restrict the number of requests that can be simultaneously executed against
Teradata Database. These rules delay or reject database requests based on specified conditions,
such as the number of concurrent queries or the duration of queries. A delayed request is
allowed to proceed when the rules limit is no longer exceeded.
The DELAYED state display for a session is shown below.
State Details : DELAYED
IDLE State
The IDLE state indicates that the Teradata Database system recognizes a session, but no
processing is taking place.
The IDLE state display for a session is shown below.
State Details : IDLE
INDOUBT State
The INDOUBT state indicates that a two-phase commit session is in doubt. This state
continues until an abort or commit is received from the host application.
The INDOUBT state display for a session is shown below.
State Details : INDOUBT
INDOUBT PARSING State

The INDOUBT PARSING state indicates that a two-phase commit session is in doubt and is
parsing a vote or commit request.
The INDOUBT PARSING state display for a session is shown below.
State Details : INDOUBT PARSING
PARSING State
The PARSING state indicates that the session is active in the Teradata SQL parser phase, before
the steps are dispatched to the AMP vprocs. The PARSING state displays no column
information and only the word PARSING.
The PARSING state for a session display is shown below.
State Details : PARSING
168
Utilities

QTDELAYED State
The QTDELAYED state indicates that a session is waiting for rows to be inserted into a queue
table. The QTDELAYED state is limited to 20% of the total possible sessions, which is 120 x
the number of PEs. If the 20% limit is exceeded, then error message 3128 appears:
3128 Transaction aborted due to exceeding the maximum consume statement
limit.
You must decrease the number of sessions consuming queue table rows. For detailed
information on error message 3128, refer to Messages.
The QTDELAYED state display for a session is shown below.
State Details : QTDELAYED
QUIESCED ABORT State

The QUIESCED ABORT state indicates that the session is blocked from executing further
requests because transactions associated with this session are being aborted. The outstanding
transaction or request will be aborted.
The QUIESCED ABORT state for a session display is shown below.
State Details : QUIESCED ABORT
QUIESCED ABORT WITH LOGOFF State

The QUIESCED ABORT WITH LOGOFF state indicates that the session is quiesced because
the transactions or requests associated with this session are being aborted. The session is
logged off.
The QUIESCED ABORT WITH LOGOFF state for a session display is shown below.
State Details : QUIESCED ABORT WITH LOGOFF
QUIESCED INDOUBT State

The QUIESCED INDOUBT state indicates that the session is blocked from exercising further
requests because the outstanding transaction/request will be terminated by the resolver base
module.
The QUIESCED INDOUBT state for a session display is shown below.
State Details : QUIESCED INDOUBT
RESPONSE State
The RESPONSE state indicates a response to a session request is in process.
The RESPONSE state for a session display is shown below.
State Details : RESPONSE
Statements
---------1
Utilities
169

Archive and Recovery Sessions State Displays
This column for the RESPONSE display contains the following information.
The column named...
Contains the...
Statements
highest statement number for which a response has been returned

to the host or the stored procedure in execution.
SESDELAYED State
The SESDELAYED state indicates that a session is delayed because a utility limit has been
exceeded. The utilities that can be limited are FastLoad, MultiLoad, FastExport, and ARC.
When the limit is no longer exceeded, the delayed requests are processed.
Teradata Viewpoint Workload Designer portlet allows you to define and manage throttle
rules, which restrict the type and number of utilities that are allowed to run concurrently.
The SESDELAYED state display for a session is shown below.
State Details : SESDELAYED

Several displays for sessions are part of the Archive and Recovery operations. If you request
detail information, Query Session reports child sessions and the parent information.
The following sections describe these displays:
Active Parent Session with Regular Request
Active Parent Session with Directed Request
Inactive Parent Session
Child Session
Active Parent Session with Regular Request Display

The following shows an example display for a parent session involved in an Archive and
Recovery operation.
State Details : Active Parent Session with regular request involved in
HUT.
Operation: Restore
CPU Usage Accesses Byte Count
---------- ---------- -------- --------- -------- ---------1
1 14:22:09
2
22
2,367
The Active State Display for a parent session involved in processing an Archive and Recovery
request contains the following information.
170
Utilities

The column named...
Contains the...
Statements
Dispatched
Time
time that the last step for the highest statement number was sent to
the AMPs.
CPU Usage

Accesses
session request.
Byte Count
total number of bytes accessed by the Archive and Recovery

operation.
Active Parent Session with Directed Request Display

The following shows an example display for a parent session involved in an Archive and
Recovery operation processing a directed request.
State Details : Active Parent Session with directed request involved in
HUT.
Request # Operation Time
CPU Usage Accesses Byte Count
--------- --------- -------- --------- -------- ---------1 Restore
14:22:09
2
22
6,234
The directed request active state display for a parent session involved in processing an Archive
and Recovery request contains the following information.
Utilities
The column named...
Contains the...
Request #
number of the request.
Operation
type of operation being performed.
Time
time that the last step for the highest statement was sent to the
AMPs.
CPU Usage

Accesses
session request.
Byte Count

operation.
171

Inactive Parent Session Display

The following shows an example display for an inactive parent session involved in an Archive
and Recovery operation.
State Details : Inactive Parent Session involved in HUT.
Operation CPU Usage Accesses Byte Count
--------- --------- -------- ---------Restore
1,234
9,543 1,259,234
The inactive state display for a parent session involved in processing an Archive and Recovery
request contains the following information.
The column named...
Contains the...
Operation
type of operation being performed.
CPU Usage

Accesses
session request.
Byte Count

operation.
Child Session Display

The following shows an example display for child sessions involved in an Archive and
Recovery operation.
Session # Request #
--------- --------1063
1759
1064
1755
1065
1754
State
-------Inactive
Active
Inactive
TimeStamp Byte Count

--------- ---------17:57:21
1,023
17:57:30
69
17:57:41
3,024
Child sessions involved in Archive and Recovery operations display these columns.
172
The column named...
Contains the...
Session #
session identifier.
Request #
State
state of the session, indicating whether the session is active or inactive.
TimeStamp
time that is updated whenever a request is received from the host, a

request is re-initiated to another AMP, or a response is sent to the host.
Byte Count
total number of bytes accessed by the session.
Utilities

FastLoad Sessions State Displays

Several displays for sessions are part of FastLoad operations.
The following sections describe those displays:
Active Parent Session in a Loading Phase
Active Parent Session in a Nonloading Phase
Inactive Parent Session in a Loading Phase
Inactive Parent Session in a Nonloading Phase
Child Sessions
If you request detail information, Query Session reports child sessions as well. These displays
are identified after the phrase State Details by two lines describing the current phase.
Information for a FastLoad session in the loading phase is different from information for a
non-loading phase of FastLoad.
Active Parent Session in a Loading Phase Display

The following example shows a display of an active parent session for a FastLoad operation in
the loading phase.
State Details : Active Parent Session involved in FASTLOAD utility
FastLoad Phase : Loading
CPU Usage Accesses Row Count
---------- ---------- -------- --------- -------- --------1
1 14:22:09
15,110
6,462
2,060
The display for an active parent session in the loading phase of a FastLoad operation contains
the following information.
Utilities
The column named...
Contains the...
Statements
Dispatched
Time
time that the last step for the highest statement number was sent to the
AMPs.
CPU Usage

Accesses
total number of segment access calls executed on all AMPs for the session
request.
Row Count
total number of rows loaded by the FastLoad utility.
173

Active Parent Session in a Nonloading Phase Display

The following shows an example display of an active parent session of a FastLoad operation in
any phase other than the loading phase.
State Details : Active Parent Session involved in FASTLOAD utility
FastLoad Phase : LoadPending
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 14:22:09
2
22
The display for an active parent session in any phase other than the loading phase of a
FastLoad operation contains the following information.
The column named...
Contains the...
Statements
Dispatched
Time
AMPs.
CPU Usage

Accesses
request.
Inactive Parent Session in a Loading Phase Display

The following shows an example display of an inactive parent session of a FastLoad operation
in the loading phase.
State Details : Inactive Parent Session involved in FASTLOAD utility
FastLoad Phase : Loading
--------- -------- --------234
567
456,321
The display for an inactive parent session in the loading phase of a FastLoad operation
contains the following information.
174
Utilities

The column named...
Contains the...
CPU Usage

Accesses
request.
Row Count
total number of rows loaded by the FastLoad utility.
Inactive Parent Session in a Nonloading Phase Display

The following shows an example display of an inactive parent session involved in a FastLoad
operation in any phase other than the loading phase.
State Details : Inactive Parent Session involved in FASTLOAD utility.
FastLoad Phase : Load Pending
CPU Usage Accesses
--------- -------65
870
The inactive parent session display for sessions involved in any phase other than the loading
phase contains the following information.
The column named...
Contains the...
CPU Usage

Accesses
session request.
Child Sessions Display

A FastLoad operation only involves child sessions when in the loading phase.
If the parent of the queried child session is not in the loading phase, the child session
information is not available. The following shows an example display for child sessions
involved in a FastLoad operation when the long form of the display is requested in response to
the Detail Information Needed prompt.
Session # Request #
--------- --------1055
1632
1056
1635
Utilities
State
-------Inactive
Active
TimeStamp Byte Count

--------- ---------15:57:10
5,286
15:57:23
372
175

MultiLoad Sessions State Displays
The display for Child sessions involved in FastLoad operations contain the following
information.
The column named...
Contains the...
Sessions#
session identifier.
Request #
State
TimeStamp
time that is updated whenever a request is received from the host, a

request is reinitiated to another AMP, or a response is sent to a host.
Row Count
total number of rows loaded by the session.

Several displays are defined for the sessions that are part of MultiLoad operations.
The following sections describe those displays:
Preliminary Phase Sessions
Application Phase Session for Apply Task
Application Phase Session for Delete Task
Active Parent Session in an Acquisition Phase
Inactive Parent Session in an Acquisition Phase
Child Session in an Acquisition Phase
In addition to the phase State Detail line, a line describing the current phase is displayed.
If the session is in the Preliminary or Application phase, the current task type (Delete or
Apply) is displayed. The information displayed is different for each phase: Preliminary,
Application, and Acquisition. In the Application phase, each of the two task types is displayed.
When the action involves more than one AMP, row count summaries are meaningless and are
not reported.
Preliminary Phase Session Display

The following shows an example display session, that is part of a MultiLoad operation, in the
Preliminary phase.
State Details : Session involved in MLOAD utility
MLoad Phase : Preliminary - Received all DML Steps.
Task Running : Apply Task
CPU Usage Accesses DMLCount
---------- ---------- -------- --------- -------- -------10
2 12:09:09
7
15
5
176
Utilities

The possible tasks include Apply Task and Delete Task. These are the Subphases:
No MLOAD step has been received.
Receiving MLOAD step.
Received all MLOAD steps.
Received all DML (Data Manipulation Language) steps.
The state display for the preliminary phase of a MultiLoad operation contains the following
information.
The column named...
Contains the...
Statements
Dispatched
Time
AMPs.
CPU Usage

Accesses
request.
DML Count
number of DML steps received if the current phase is Received all DML
Steps.
Application Phase Session for Apply Task Display

The Query Session display for each table during an Apply Task includes the name of the
database and table, the current action, the number of workrows applied, and the total number
of workrows. The following shows an example display session involved in a MultiLoad
operation during an Apply Task.
MLoad Phase : Application.
Task Running : Apply Task
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 11:09:37
811751 349,637
DataBase.Table
Action
# of WorkRows applied
Total # of WorkRows
# of NUSI change rows applied
Total # of NUSI change rows
= SPOOL_RES.WT_TDEM_PAIMT_MED
= Process Data and Secondary index
= 1,210,838
= 51,639,908
=
0
=
0
The display for active parent sessions involved in the Apply Task of a MultiLoad operation
provides the following information.
Utilities
177

The column named...
Contains the...
Statements
Dispatched
Time
AMPs.
CPU Usage

Accesses
request.
In addition, the display provides the following information.

Field
Description
DataBase.Table
Identifies the table on which the MultiLoad operation is running.
Action
Describes the action being performed in the MultiLoad session.
# of WorkRows applied
Displays the number of work rows processed in the apply phase.
Total # of WorkRows
Displays the total number of rows processed.
# of NUSI change rows

applied
Number of nonunique secondary index rows processed in the apply

phase.
Total # of NUSI change rows
Total number of nonunique secondary index rows processed.
Application Phase Session for Delete Task Display

The following shows an example of the Query Session display for each table during a Delete
Task, which includes the name of the database and table, the current action, the number of
rows scanned, and the number of rows deleted.
MLoad Phase : Application.
Task Running : Delete Task
CPU Usage Accesses
---------- ---------- -------- --------- -------3
3 11:24:32
844679 310,987
DataBase.Table
Action
# of rows scanned
# of rows deleted
= SPOOL_RES.WT_TDEM_PAIMT_MED
= Process Data
= 22,357
= 245,349
Note: The values shown include both the primary and the fallback count.
178
Utilities

The Delete Task display for a MultiLoad operation contains the same information as described
for the Apply Task display except that it reports the number of rows processed and deleted
rather than the rows processed by the apply phase.
Active Parent Session in an Acquisition Phase Display

The following shows an example display of an active parent session which is part of a
MultiLoad operation.
State Details : Active Parent Session involved in MLOAD utility
MLoad Phase : Acquisition - Data Loading is in progress.
---------- ---------- -------- --------- -------- --------1
1 09:23:45
8
166
9,854
If you request detail information, Query Session reports child sessions as well. These are the
descriptions of the phase:
Data Loading is in progress.
Data Loading is complete.
The display for active parent sessions involved in MultiLoad operations provides the following
information.
The column named...
Contains the...
Statements
Dispatched
Time
AMPs.
CPU Usage

Accesses
request.
Row Count
total number of rows processed by the MultiLoad task.
Inactive Parent Session in an Acquisition Phase Display

The following shows an example display of an inactive parent session that is part of a
MultiLoad operation.
State Details: InActive Parent Session involved in MLOAD Utility
MLoad Phase : Acquisition - Data Loading is complete.
--------- -------- --------130
654
45,673
These are the possible descriptions of the phase:
Utilities
179

Data Loading is in progress.
Data Loading is complete.
The display for inactive parent sessions involved in a MultiLoad operation contains the
following information.
The column named...
Contains the...
CPU Usage

Accesses
request.
Row Count
total number of rows processed by the MultiLoad task.
Child Session in an Acquisition Phase Display

The following shows an example display for child sessions involved in a MultiLoad operation
when the long form of the display is requested in response to the Detail Information Needed
prompt.
State Details: CHILD session involved in MLOAD Acquisition Phase
Session # Request #
--------- --------1055
1632
1056
1635
State
-------Inactive
Active
TimeStamp Row Count

--------- --------15:57:10
5,286
15:57:23
372
Child sessions involved in MultiLoad operations display these columns.
180
The column named...
Contains the...
Session #
session identifier.
Request #
State
TimeStamp
time that is updated whenever a request is received from the host, a request
is reinitiated to another AMP, or a response is sent to the host.
Row Count
total number of rows loaded by the session.
Utilities

FastExport Sessions State Displays

FastExport of data includes sessions under which Teradata SQL statements are executed, as
well as sessions used to transfer response data to the host.
The Teradata SQL session assumes one of five sequential states:
Executing the select
Releasing resource locks
Vertical data redistribution
Horizontal data redistribution
Inactive
Vertical data redistribution and horizontal data redistribution are processes executed to
prepare the response data from a SELECT request for transfer back to the host. Vertical
redistribution occurs only if the SELECT contains an ORDER BY clause. The idle state occurs
before the select request is transmitted to the Teradata Database system, or while the
FastExport sessions are transmitting data to the host.
FastExport sessions are children of the Teradata SQL session that executes the select request. A
child session exists in one of two states. A child session in the inactive state means that either
the select has not completed, or that the host utility has not yet issued a request for this child
session in returning response data. A child session in the active state is currently transmitting
response data.
Like FastLoad and MultiLoad, the FastExport utility executes bulk activities. The Teradata
Database system limits the maximum number of load operations (that is, FastExport,
FastLoad, or MultiLoad) to the number specified in DBS Control field MaxLoadTasks.
Examples of Teradata SQL sessions involved in FastExport activity and examples of the output
for a FastExport session are shown in the following sections.
Teradata SQL Session - Releasing Locks

The following shows an example display of a single FastExport Teradata SQL session in release
locks state.
---- ------- --- ----------114 1090
1-4 DBC
State Details : Active PARENT session involved in FastExport
FastExport Phase : Vertical redistribution.
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 18:35:54
6174
2,922
Detail information for CHILDREN sessions in FastExport Util.
Utilities
181

Session # Request # State

--------- --------- -------1091
0 Inactive
1092
0 Inactive
1093
0 Inactive
1094
0 Inactive
Teradata SQL Session - Vertical Redistribution

The following shows an example display of the Teradata SQL session in the vertical
redistribution state. The select request consists of a single SELECT statement.
---- ------- --- ----------114 1090
1-4 DBC
FastExport Phase : Vertical redistribution.
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 18:37:54
6603
3,314
--------- --------- -------1091
0 Inactive
1092
0 Inactive
1093
0 Inactive
1094
0 Inactive
The following example shows that the Teradata Database system continues to process the
vertical redistribution phase.
---- ------- --- ----------114 1090
1-4 DBC
FastExport Phase : Horizontal redistribution.
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 18:42:35
6603
3,314
--------- --------- -------1091
0 Inactive
1092
0 Inactive
182
Utilities

1093
1094
0 Inactive
0 Inactive
The CPU Usage and the Accesses counts have increased, indicating the Teradata Database
system is in operation.
Teradata SQL Session - Horizontal Redistribution

With the Teradata SQL session in the horizontal redistribution state, the display might take
the form shown in the following example.
---- ------- --- ----------114 1090
1-4 DBC
FastExport Phase : Horizontal redistribution.
CPU Usage Accesses
---------- ---------- -------- --------- -------1
1 18:42:35
7893
5,305
--------- --------- -------1091
0 Inactive
1092
0 Inactive
1093
0 Inactive
1094
0 Inactive
FastExport Session - Inactive

The following example shows that the FastExport session is inactive, waiting for the select to
complete.
---- ------- --- ----------114 1091
N/A DBC
State Details : Child Session involved in FastExport Utility
FastExport Phase : Returning data.
Request # State
Parent Session
--------- -------- -------------0 Inactive
1069
Utilities
183

FastExport Session - Data Transmission

The following example shows FastExport returning data. This child session has returned one
data block to the host for the first SELECT statement, where the response data contains 69
blocks.
---- ------- --- ----------114 1091
N/A DBC
Request # State
Statement Blocks Returned Total Block
--------- -------- --------- --------------- ----------1000 Active
1
4
69
FastExport transmission continues. As shown in the following example, the session has
returned four data blocks to the host. In this way, the user is able to monitor the progress of
the data transmission phase.
---- ------- --- ----------114 1091
1-5 DBC
Request # State
Statement Blocks Returned Total Block
--------- -------- --------- --------------- ----------1000 Active
1
4
69
184
Utilities
CHAPTER 24
Reconfiguration Estimator
(reconfig_estimator)
The Reconfiguration Estimator utility chapter has been moved to the Support Utilities manual.
Utilities
185
Chapter 24: Reconfiguration Estimator (reconfig_estimator)
186
Utilities
CHAPTER 25
Reconfiguration Utility (reconfig)
The Reconfiguration utility chapter has been moved to the Support Utilities manual.
Utilities
187
Chapter 25: Reconfiguration Utility (reconfig)
188
Utilities
CHAPTER 26
Recovery Manager (rcvmanager)
The Recovery Manager utility, rcvmanager, monitors and provides information about the
progress of a Teradata Database system in recovery, including transaction rollbacks, because of
a Teradata Database system crash or user abort.
The recovery process might include one or more of the following:
Online Transaction recovery
Down AMP recovery of changed data rows
Down AMP recovery of Teradata Database system level changes
Also, rcvmanager allows you to do the following:
Cancel the rollback of one or more specified host and session IDs
Set the priority level of rollbacks in progress for a specified host and session ID
Set priority levels to optimize Teradata Database system recovery
Runs From

such as cnsterm. Type start rcvmanager at the DBW command prompt.
Prerequisites
You can run rcvmanager only while the Teradata Database is in one of the following states:
Logon
Logon/quiet
Logoff
Logoff/quiet
Startup (if the Teradata Database system has completed voting for transaction recovery)
If you attempt to start rcvmanager while the Teradata Database system is not in one of the
allowable states, the utility displays the following error information and terminates:
Utilities
189
Chapter 26: Recovery Manager (rcvmanager)

Assigning Priority Levels
RCVMANAGER can only be run when the system is in the LOGON or LOGOFF
state or if the system is in the STARTUP state and has completed voting
for transaction recovery. The current system is not in one of these
allowable states thus preventing RCVMANAGER from operating.
RCVMANAGER terminated.
Assigning Priority Levels

You can assign priority levels to Teradata Database system recovery or table rebuild by using
the PRIORITY command feature of rcvmanager. Control over job priority is assigned by
selecting one of three priority levels:
HIGH
MEDIUM
LOW
For information about these priority levels, see REBUILD/RECOVERY PRIORITY on

page 225.
Teradata Database system recovery and disk rebuild are primarily I/O intensive tasks. The
major portion of the time taken by a given task is involved in setting up for or waiting for
completions of a disk or a BYNET message traffic operation. Very little manipulation or
computation is required on the data once it is available.
If the competing work load of the Teradata Database system can be reasonably characterized,
then you can gauge the impact of the priority changes to recovery and rebuild operations. In
general, use the following guidelines when assigning priorities:
Guideline
Description
No work load
competition
If there is no competition for resources as in a COLDWAIT restart for recovery,

the priority setting of the recovery and rebuild jobs will have no practical effect.
Computeintensive work
load
If the online Teradata Database system work load is heavily compute intensive,
raising the priority of the I/O intensive recovery operations can dramatically
improve the recovery (including rebuild).
The high recovery will have a relatively minor impact on the online Teradata
Database system operations. However, it will provide a better resource
utilization and result in better Teradata Database system throughput. Similarly,
a low priority of recovery in this work load will dramatically slow down
recovery with only a moderate gain in online throughput.
Moderate or
heavy disk work
load
190
If a moderate or heavy amount of disk and/or BYNET usage occurs by the

online system, then recovery will show moderate throughput changes by
controlling the priority setting but with a larger impact against the Teradata
Database system throughput. Memory contention becomes a major component
of operation in these cases.
Utilities

Online Transaction Recovery
Guideline
Description
I/O saturation
As the I/O utilization approaches saturation, there are fewer opportunities to

improve throughput or execution time of either the online Teradata Database
system or the recovery job. In this case, we are competing for the same resource
and that resource is not amenable to manipulation by control over the
scheduling priority.
Changing Priority Levels for Rollback

rcvmanager also allows you to change the priority levels for rollback. To display or set the
current Performance Group of the rollback for a particular session, use the ROLLBACK
SESSION... PERFORMANCE GROUP command.
The priority associated with the specified Performance Group determines the priority of
rollback for the specified host and session IDs. For more information, see ROLLBACK
SESSION...PERFORMANCE GROUP on page 226.
Online Transaction Recovery

Online transaction recovery is automatically invoked by a Teradata Database system restart
and includes the following processes:
Rolling back transactions that were not completed at the time of the crash or restart
Completing transactions that were committed
Changes made to underlying data by transactions are recorded in the Transient Journal (TJ).
AMPs keep track of transactions in progress using the TJ which is stored on each AMPs disk.
IF...
THEN...
all the modification operations successfully

complete on all the AMPs working on behalf of
the transaction
that transaction is successful and there is no

further concern for recovery of that transaction.
a transaction does not complete due to a

Teradata Database system crash or forced restart
those transactions are backed out as part of the

Teradata Database system recovery process when
the Teradata Database system restarts.
Transaction Recovery Sequence

The general sequence of a Teradata Database system recovery is as follows:
Utilities
191

Multiple Recovery Sessions
1
The status of each transaction on each online AMP is determined by the Teradata
Database system.
All of the online AMPs at the time of the restart work together to determine which
transactions were complete, and which ones were not completed. Completed transactions
are ignored and incomplete ones are backed out. The process of rolling back incomplete
transactions might take some time.
Write and exclusive locks are set against all data modified by incomplete transaction.
All locks needed for the recovery are set, and the Teradata Database system begins roll back
or completion of the transactions.
The Teradata Database system accepts work and is operational.

Note: If new transactions reference the inconsistent data of to-be-rolled-back
transactions, they are blocked until the recovery process restores the data and releases the
lock.
Down AMP recovery begins.
Multiple Recovery Sessions

A recovery session is the set of actions to be taken as a result of the Teradata Database system
restart for all transactions that were in progress at the time the Teradata Database system
restarted.
All of the online AMPs at the time of the restart work together to determine which
transactions were complete, and which ones were not completed. Completed transactions are
ignored and incomplete ones are backed out.
If new work or transactions are allowed in during recovery, and another restart occurs, an
additional recovery session is created. Then there will be two recovery sessions:
The first one that was created for the previous restart
The new one that was created for the current work
Since there is a sequential relationship between these two recovery sets and they are inherently
mutually exclusive, they are kept as separate operations.
Therefore, if a system crash or user abort occurs and the amount of work to be done in each
recovery session is large, then three, four or more recovery sessions may be created. Each
session exists until all the incomplete transactions of the session are rolled back.
The issue of multiple recovery sessions may be avoided by having all the restarts be
COLDWAIT, since the WAIT means to wait for recovery to complete before allowing the
Teradata Database system to accept new work from the hosts. Although the recovery proceeds
faster, since it is not competing with any other new work for computing resources, the
Teradata Database system remains totally unavailable to the database users.
192
Utilities

Deferred Transaction Recovery
Deferred Transaction Recovery

If the Teradata Database system crashes, a COLD restart is activated and an online transaction
recovery or deferred recovery is started. The only time a deferred recovery is not done is when
the operator enters a COLDWAIT restart.
Deferred transaction recovery allows new transactions to come in from the connected hosts.
The process of bringing the Teradata Database system up after a crash causes the locks to be
set. If new transactions should attempt to reference the inconsistent data of the to-be-rolledback transactions, they are blocked until the recovery process restores the data and releases the
lock.
Down AMP Recovery

Down AMP Recovery is a process that handles all changes to entire tables or rows, either
fallback and primary, while the AMP is down or offline. Down AMP Recovery updates a
recovering AMP with data that the Teradata Database system processed while the AMP was
down. The down AMP is considered to be in offline catchup mode. Catchup mode indicates
that the AMP is logically offline and in the process of updating its tables so that they are
synchronized with the online AMPs in the cluster.
In a crash or restart condition, it is possible to lose an AMP from, for example, a CPU board
failure without losing its underlying disk data. The remainder of the Teradata Database system
can then restart and recover the transactions without the failed AMP.
After the down AMP is ready to rejoin the Teradata Database system, the down AMP recovers
the lost data by performing the following steps:
1
Restoring the data to a consistent state, relative to the transactions the down AMP was
working on at the time of the failure.
The down AMP applies the information in its Transient Journal against its underlying
data. Moreover, the down AMP must concur with the choice of the rest of the Teradata
Database system whether to rollback or commit each transaction.
Updating the restored data to match all changes made to the online Teradata Database
system while the AMP was down (Down AMP Recovery).
Down AMP Recovery Operations Display

The following display indicates the fields that are referenced in the down AMP recovery
operations explanation on the next page. This display is printed out by rcvmanager. For a
description of the fields in the following display, see Down/Catchup AMP Recovery Status
on page 216.
DOWN AMP RECOVERY STATUS at HH:MM:SS MM/DD/YY
AMP to be
caught up
---------0001
Utilities
Pass
---0
Current Pass
OJ
CJ
----------0
0
Next
OJ
--1
Pass
CJ
-------1,081
193

Down AMP Recovery
- AMP Status: Online Catchup
- Not currently executing recovery
0002
1
5
145,822
1
- AMP Status: Offline Catchup
- Transaction Recovery: 25,488 TJ Rows
25,081
0003
1
0
2,142
0
0
- AMP Status: Online Catchup
- Change Row Recovery: 26% complete in this pass
0004
2
2
201,558
0
4,228
- Rebuilding Database1.Table1: 45% complete
0005*
4
0
0
0
2,888
- Between passes
* - would probably be placed in online catch up if a restart occurred
Recovering Down AMPs

Note: Perform steps one through four only when offline catchup AMPs exist. If an AMP is still
physically down, do not perform these steps.
To recover a down AMP, do the following:
1
Previously down AMPs that are now available begin their local transaction recovery
(referred to as offline catchup AMPs). This step must be completed before going to step 2.
The extracted Ordered System Change Journal (OJ) is processed, rebuilding various
subtables.
The extracted Changed Row Journal (CJ) rows are then processed by sending the changed
rows (or notification that the rows were deleted) to the catchup AMP.
The OJ entries are applied. Ones which take a significant amount of time are the build
operations.
Current CJ entries are applied. Each CJ entry represents one row to be updated (insert,
delete, update).
Online AMPs in the down AMP cluster extract all the current build records from the OJ
and CJ, and sort them to eliminate duplicates. Any CJ entries referring to rows in a table
which will be rebuilt are deleted. Other OJ operations are sent to the catchup AMP for
execution.
The Next Pass OJ and CJ entries become the Current Pass entries.
Repeat steps 2 through 7 indefinitely.
After the AMP is sufficiently caught up, it becomes eligible to become an online catchup
AMP on the next restart. This is denoted by displaying an asterisk (*) under the column
entitled, AMP to be caught up, in the DOWN AMP RECOVERY STATUS screen of the
rcvmanager status display. See the previous display screen.
Recovery Journal
When an AMP in a cluster goes down, and the fallback option is specified for a table, the
Down AMP Recovery Journal (RJ) records changes made to the fallback tables that are
applicable to the down AMP. The journal is active only during an AMP failure and is only used
for fallback tables.
194
Utilities

Down AMP Recovery
The Recovery Journal process for a down AMP is as follows:

1
Operational AMPs in the cluster begin logging entries into the Down AMP RJ.
The Down AMP RJ records the changes that should have been made to fallback-protected
rows of the inoperative AMP.
The changes are applied when the down AMP recovers.
The Recovery Journal maintains the following two sets of records:

Record
Function
Changed Row Journal

(CJ)
Logs changed rows in an AMP cluster by logging pointers to the rows

that have been changed, but does not log the actual rows.
Ordered System Change

Journal (OJ)
Logs events such as, building the index, creating a permanent journal,
and performing a table rebuild.
These types of changes may be termed Teradata Database system-level
changes and involve Data Definition Language (DDL) operations, since
they affect all AMPs, not only a single row update.
Changed Row Journal

The CJ recovery needs to match its data against all changes made to the online Teradata
Database system while the AMP was down. The most common type of changes includes
modifications made to individual rows by Data Manipulation Language (DML) operations of
inserting, deleting, and updating rows in pre-existing tables.
Each modified row is remembered in the Teradata Database system CJ, which is local to each
AMP on which the modification takes place. Since the modification is done only while an
AMP is down, the CJ is only populated on AMPs in a cluster while an AMP is down. AMPs are
arranged into a group called clusters so that each AMP provides fallback protection to other
members within that same group.
Entries stored in the CJ include only the table ID and row ID of the row which was modified.
When the down AMP recovers, the actual row is extracted from the fallback or primary
subtable; the row image is not stored redundantly in the CJ.
Ordered System Change Journal
Teradata Database system-level changes are data changes that are applied to the online
Teradata Database system while an AMP is down. These changes are called system level
because they affect all AMPs, as opposed to a single row update.
These changes cover DDL operations such as, DROP TABLE, CREATE TABLE, and CREATE/
DROP INDEX. Other operations include a change to every single row within a table, for
Utilities
195

Down AMP Recovery
example, drop a column. For these types of operations, recovery involves copying every single
row of the table, for those rows the AMP owns, over to that down AMP (a table rebuild).
Therefore, the majority of the rows found in the OJ are build records that identify tables that
need to be built for created tables, or rebuilt when the AMP is recovered. Other OJ records are
HUT Lock set and release records, and in-doubt two-phase commit transaction.
Deferred Down AMP Recovery

The process of Deferred Down AMP Recovery means that while a down AMP remains down
and recovering, the rest of the Teradata Database system continues its operations with the
connected hosts.
The following sections describe the modes:
Offline catchup
Online catchup
Offline Catchup Mode

In offline catchup mode, the new transactions for the down AMP are performed by other
AMPs in the cluster. Therefore, new change row and Teradata Database system change entries
are made while the down AMP is processing the old ones. While the AMP is in catchup mode,
the AMP is considered logically offline.
To set a down AMP to offline catchup mode, do the following:
1
Start the Vproc Manager utility.
To list the Teradata Database system logical configuration, type:

status;
A screen similar to the following appears:

DBS LOGICAL CONFIGURATION
Vproc
Rel.
Node
Crash
Vproc
Config
Config Cluster/
RvcJrnl/
Number Vproc# ID
Movable Count
State
Status
Type
Host No.
Host Type
0*
1
0-0
No
0
Online Online
AMP
0
On
1
2
0-0
No
0
Offline Down
AMP
0
On
16383
3
0-0
No
0
Online Online
PE
52
COP
__________________________________________________________________________________
* DBS Control AMP
DBS State: Logons are enabled - Users are logged on
DBS RestartKind: COLD
The disable list is empty
To bring up the downed AMP, type:

set 1 = online;
If vproc 1 goes into catchup mode, the following message appears:

Vproc 1 will begin recovery in the background via the Recovery Control
Task
To verify that the AMP is in Utility Catchup mode, type:

status:
While in the offline mode, the AMP has OJ build records to process and/or a large number
of CJ rows. This reduces the amount of data that is locked, but any new transactions on the
online Teradata Database system creates additional OJ and CJ rows. Since you cannot place
196
Utilities

Down AMP Recovery
an offline AMP into the online Teradata Database system, these passes could continue
forever or until the Teradata Database system restarts.
A screen similar to the following appears:
Vproc
Rel.
Node
Crash
Vproc
Config
Config Cluster/
RvcJrnl/
Number Vproc# ID
Movable Count
State
Status
Type
Host No.
Host Type
0*
1
0-0
No
0
Online Online
AMP
0
On
1
2
0-0
No
0
Utility Catchup AMP
0
On
16383
3
0-0
No
0
Online Online
PE
52
COP
__________________________________________________________________________________
* DBS Control AMP
DBS State: Logons are enabled - The system is quiescent
The disable list is empty
To verify if an offline AMP, for example, is almost in catchup, do the following:

1
Start rcvmanager.
To check the offline AMP status, type:

list status;
One of the following messages appears:

Message...
Means that the...
- AMP Status: Not in recovery

- Down
AMP is still down.

- Executing miscellaneous Recovery
actions
AMP is in catchup mode.

- Between Passes
* - would probably be placed in
online catchup if a restart occurs.
AMP is in catchup mode, and if a restart occurs,

the AMP is placed in online catchup mode.
Note: Sufficiently recovered refers to the third message in the table above.
If a COLDWAIT restart is performed, the operations are similar to those of Transaction
Recovery. In COLDWAIT, the Teradata Database system remains offline with no incoming
transactions until all recovering AMPs have fully recovered. After recovery, the AMPs are all
set to online status, and the Teradata Database system completes start-up.
In offline catchup, catchup tries to run faster than the new update transactions coming in
online. The other AMPs handle the fallback responsibility for the down AMP, as well as the
additional work involved in writing CJ or OJ records.
If an AMP is designated to be in offline catchup mode, then you must initiate a COLD restart,
but only after the AMP has sufficiently recovered, to bring the offline AMP back online.
Online Catchup Mode
In online catchup mode, the previously down AMP will also accept transactions, as will the
rest of the Teradata Database system. In this mode, all the data that needs updating is locked,
so that new data does not operate on the obsolete data.
Utilities
197

Startup/Restart Messages
When the down AMP has a small amount to recover, it can be placed into online catchup. To
begin online catchup mode, see Offline Catchup Mode on page 196.
Since the AMP is online and participating in the new transaction coming into the Teradata
Database system, no new CJ or OJ entries are being created for it. After all of the residual CJ
processing is completed, the Teradata Database system becomes online. Start the
VprocManager utility and check the status of the Teradata Database. The Vproc State and
Config Status should appear as Online. At this point, the AMP rejoins the other online AMPs
automatically without the need of a Teradata Database system restart.
Startup/Restart Messages
At startup, messages are displayed to report the startup progress and the Teradata Database
system status. This report includes some recovery process messages as shown below:
H005 Control AMP 001-2
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
98/02/06
11:35:31
11:35:31
11:35:32
11:35:32
11:35:32
11:35:33
11:35:36
11:35:36
11:35:40
11:36:02
11:36:05
11:36:16
11:36:18
11:36:18
11:37:03
11:37:05
11:37:05
Running DBS Version: 14.00.00.00

Running PDE Version: 14.00.00.00
Current DBS config maps are synchronized (Version: 11)
New DBS config maps are synchronized (Version: 11)
AMP 0000 has been selected as the Control AMP
Initializing DBS Vprocs
Configuration is operational
Starting AMP partitions
Connection accepted
Voting for transaction recovery
Recovery session 1 contains 77 rows on AMP 0000
Starting transaction recovery
Completed transaction recovery
Starting PE partitions
System is operational
Users are logged on
Logons are enabled
The following table lists and explains these and other messages.
198
Message #...
Means...
1 - AMP mmmm in cluster nnn is

back online
the specified AMP which was offline is now back

online.
2 - AMP mmmm is in offline

catchup
the AMP is in offline catchup mode.
3 - AMP mmmm is in online

catchup
the AMP is in online catchup mode.
4 - AMP mmmm not brought online

for the following reason(s):
one of the following:

Changed row journal count of ZZ,ZZZ,ZZ9
exceeds 3000 rows.
At least one long running ordered journal
record remains.
At least one HUT lock might exist in the cluster.
At least one two-phase-commit transaction is in
doubt.
Utilities

Restarts
Message #...
Means...
5 - Completed transaction
recovery
Transaction Recovery for online AMPs is compete.
6 - Recovering down AMPs
the recovery process is updating tables on AMPs that

are in offline catchup.
Note: If there was no down AMP in catchup recovery
mode, this message is not displayed.
7 - Recovery session 1 contains

103 rows on AMP 0001
that AMP 0001 has the largest number of rows in the

transient journal for the given recovery session. Other
AMPs probably have a similar or less rows for the
same recovery session. The count reflects how many
rows were in the transient journal at the time of the
Teradata Database system restart. It does not
necessarily mean a rollback action has to be
performed for each row.
8 - Starting transaction
recovery
transaction recovery has started on online AMPs.
9 - Startup will wait for

recovery to complete
the user initiated a COLDWAIT restart.
10 - Voting for transaction

recovery
the application software is determining if there were

any incomplete transactions left from the previous
operation. Voting is a process by which each AMP
examines the transactions that were in process. Any
uncompleted transaction will have to be rolled back.
Restarts
Two types of restarts exist:
Automatic
User-initiated
Automatic Restarts
When a software or hardware failure occurs, the Teradata Database system automatically
attempts to bring itself back up into an operational state. This type of restart results in an
automatic execution of a Teradata Database system-recovery operation. As part of the restart
processing, the Teradata Database system saves the error codes that were generated, reloads
Teradata Database system software, and enables logons.
User-Initiated Restarts
Manual restarts are activated by the user. Users can initiate a restart from any of the hardware
switches or by one of the following methods:
Utilities
199

Cancelling Rollback on Tables
Issue the RESTART command. For information on the RESTART command, see
Chapter 39: Vproc Manager (vprocmanager).
At the system command line, type the following command:

tpareset comment-string
where comment-string briefly describes the reason for the restart.

rcvmanager provides a mechanism to cancel or skip the rollback of specified tables during a
Teradata Database system restart or an aborted, online transaction. Cancelling the rollback of
long-running transactions and unwanted tables improves the availability of Teradata Database
system resources and reduces the Teradata Database system startup time after a crash.
When the CANCEL ROLLBACK ON TABLE command is executed for a table, the Teradata
Database marks the related table header invalid. Only the rollback pertaining to the specified
table in the transaction is cancelled. The rollback processing for the rest of the transaction is
not impacted.
Note: You cannot cancel rollback on a table that is not in the rollback list. Before issuing the
CANCEL ROLLBACK ON TABLE command, you should use the LIST ROLLBACK TABLES
command to see which tables are undergoing rollback. You can cancel rollback only on tables
that appear in this list.
Use the CANCEL ROLLBACK ON TABLE command when one of the following occurs:
Caution:
The rollback of a table is likely to take longer than its restoration.
The table, such as a temporary table, is unimportant.
Teradata recommends that you use the CANCEL ROLLBACK ON TABLE command with
caution because the target table becomes invalid and unusable after executing this command.
Teradata highly recommends that you perform a DELETE ALL operation on the table after
cancelling rollback on it.
The typical process of cancelling rollback on a table is as follows:
1
The rollback is taking too long.
You identify a large table(s) that can be restored faster than the rollback will take.
You perform a LIST ROLLBACK TABLES to see which tables are undergoing rollback.
You perform a CANCEL ROLLBACK ON TABLE.
You perform a DELETE ALL and restore the table(s).
The only time that you would not restore the table(s) immediately is if you do not need the
table(s). You still should perform a DELETE ALL immediately. You have to know what you are
going to do about the invalid table prior to performing the CANCEL ROLLBACK ON TABLE.
And you will have to do it immediately to get the Teradata Database system back online.
200
Utilities

You can reuse the table only when one of the following occurs:
You drop the table and create it again.
You restore the table from an archived backup.
You perform a DELETE ALL operation on that table if you do not want to lose the DDL
associated with the table. When you issue a DELETE ALL, the partially rolled back rows
can be removed, and the table is made usable.
Before cancelling rollback on tables, see Usage Rules on page 204.

To cancel the rollback on tables, do the following:
1
Start rcvmanager.
At the command prompt, type:

LIST ROLLBACK TABLES;
rcvmanager displays the names and details of the tables undergoing rollback.
3
At the command prompt, type:

CANCEL ROLLBACK ON TABLE nnnn:mmmm, nnnn:mmmm, ...;
The table IDs specified must appear on the rollback list from step 2.
rcvmanager displays the following:
Type the password for user DBC or press the Enter key to return:
Note: You need to specify the DBC password only for the first use of the CANCEL
ROLLBACK ON TABLE command in a rcvmanager session. For subsequent use of the
command, rcvmanager does not ask for the DBC password.
4
Type the password for user DBC or press the Enter key.
If logon fails due to an incorrect password or for some other reason, the following message
appears:
*** Logon failed ***
Teradata Database returns to the RcvManager command prompt. Repeat step 2 if this
occurs.
If you successfully logon to the Teradata Database system, the following message appears:
Rollback will be cancelled for:
mmmm:nnnn "DBname"."TableName"
Confirm y/n ?
For other possible messages, see CANCEL ROLLBACK Messages on page 206.
5
Type Y to confirm.
For more information on rollbacks, see the following commands:
Utilities
CANCEL ROLLBACK ON TABLE on page 203
LIST CANCEL ROLLBACK TABLES on page 210
LIST ROLLBACK TABLES on page 212
201

Recovery Manager Commands
Retrieving Tables
You can perform a single table retrieve operation on tables whose rollback was cancelled. To
do so, use the LOCKING request modifier with the READ OVERRIDE option. You cannot
perform update operations (UPDATE, INSERT, DELETE, and MERGE requests) on such
tables. For more information, see LOCKING Modifier in SQL Data Manipulation Language.
Recovery Manager Commands

Recovery Manager presents a command-line environment that allows the entry of Recovery
Manager commands. Commands must be terminated with a semicolon.
The following table summarizes the commands.
Command
Description
CANCEL ROLLBACK ON
TABLE
Cancels rollback processing on tables currently undergoing rollback

as part of a Teradata Database system recovery or an online, usertransaction abort.
DEFAULT PRIORITY
Sets the priorities to the default values.
HELP
Displays the syntax for the commands supported by rcvmanager.
LIST CANCEL ROLLBACK

TABLES
Displays a report containing the table-id, database name, and table

name of the tables whose rollback processing during an online,
user-requested abort or during Teradata Database system recovery
is cancelled.
LIST LOCKS
Displays all locks currently held by transaction recovery.
LIST ROLLBACK TABLES
Displays a report with the names and details of the tables

undergoing rollback in the Teradata Database system.
LIST STATUS
Displays transaction recovery information and AMP recovery

information for unavailable AMPs or detailed information about
the recovery process of a specific AMP.
QUIT
Exits rcvmanager.
REBUILD/RECOVERY
PRIORITY
Sets or displays a priority level for use by the Table Rebuild utility
and a Teradata Database system recovery operation.
ROLLBACK SESSION...
PERFORMANCE GROUP
Sets or displays the Performance Group of rollbacks for a specified

session.
The following sections describe each of the Recovery Manger commands in more detail.
202
Utilities

CANCEL ROLLBACK ON TABLE
Purpose
The CANCEL ROLLBACK ON TABLE command allows you to cancel rollback processing on
tables currently undergoing rollback as part of a Teradata Database system recovery or an
online, user-transaction abort.
Note: Before using CANCLE ROLLBACK ON TABLE, you should use the LIST ROLLBACK
TABLES command to obtain the table IDs of tables undergoing rollback. CANCLE
ROLLBACK ON TABLE will fail for tables that do not appear on this list.
Syntax
CANCEL ROLLBACK
ON
TABLE
,
table_id
;
YsRcv006
Syntax element...
Specifies...
table_id
the identifier for the table whose rollback is to be cancelled. This is specified
in hexadecimal format.
You can specify any number of table_ids by separating them with commas.
The table_id must be in the rollback tables list, meaning the table specified
must be undergoing rollback. For other rules, see Usage Rules on page 204.
Usage Notes
When the CANCEL ROLLBACK ON TABLE command is executed for a table, the Teradata
Database marks the related table header invalid. Only the rollback pertaining to the specified
table in the transaction is cancelled. The rollback processing for the rest of the transaction is
not impacted.
Use the CANCEL ROLLBACK ON TABLE command when one of the following occurs:
Caution:
The rollback of a table is likely to take longer than its restoration.
The table, such as a temporary table, is unimportant.
Teradata recommends that you use the CANCEL ROLLBACK ON TABLE command with
caution because the target table becomes invalid and unusable after executing this command.
Teradata highly recommends that you perform a DELETE ALL operation on the table after
cancelling rollback on it.
Utilities
203

The typical process of cancelling rollback on a table is as follows:

1
The rollback is taking too long.
You identify a large table(s) that can be restored faster than the rollback will take.
You perform a LIST ROLLBACK TABLES to see which tables are undergoing rollback.
You perform a CANCEL ROLLBACK ON TABLE.

Note: You can cancel rollbacks only on tables whose IDs appear on the rollback list from
step 3.
You perform a DELETE ALL and restore the table(s).
The only time that you would not restore the table(s) immediately is if you do not need the
table(s). You still should perform a DELETE ALL immediately. You have to know what you are
going to do about the invalid table prior to performing the CANCEL ROLLBACK ON TABLE.
And you will have to do it immediately to get the Teradata Database system back online.
You can reuse the table only when one of the following occurs:
You drop the table and create it again.
You restore the table from an archived backup.
You perform a DELETE ALL operation on that table if you do not want to lose the DDL
associated with the table. When you issue a DELETE ALL, the partially rolled back rows
can be removed, and the table is made usable.
Upon specifying the CANCEL ROLLBACK ON TABLE command for the first time in a
rcvmanager session, you are prompted to type the password for user DBC. Although any user
can execute this command, the DBC password is required. This is a built-in safeguard to
restrict the use of the feature.
This command is not instantaneous. It takes effect after reading the Transient Journal (TJ)
rows for all the tables specified with the command.
You can cancel the rollback on a table even after a part of the transaction rollback is complete
on that table.
The priority level in effect during a rollback also applies to the aborting of rollback.
Usage Rules
The following usage rules apply to the CANCEL ROLLBACK ON TABLE command:
The table-id specified with the CANCEL ROLLBACK ON TABLE command must exist in
the rollback tables list, meaning the table must have been marked for rollback.
You can specify any number of tables for cancelling rollback. rcvmanager verifies each
table-id. If some of these tables do not exist in the rollback list, rcvmanager reports error
messages for the non-existing tables and asks for a single confirmation for cancelling
rollback on all the valid tables.
Example 1: Valid Command
Assume that the table with table-id 6712 exists.
> CANCEL ROLLBACK ON TABLE 0:6712;
Type the password for user DBC or press the Enter key to return:
204
Utilities

> dbc
0000:6712 "EmployeeDB"."LogTable"
Confirm y/n ?
> y
rcvmanager cancels rollback on LogTable.

Example 2: Invalid Command
Assume that the table with table-id 6708 does not exist in the rollback list.
Table 0:6708 does not exist in rollback list.
Enter command, "QUIT;" or "HELP;" :
rcvmanager has ignored the command because the table does not exist.
You cannot cancel rollback on tables that have any referential integrity constraints.
Note: An exception to this rule is the self-referencing table.
The table-ids of all referenced and referencing tables are marked with an asterisk (*) in the
rollback list generated by the LIST ROLLBACK TABLES command.
When you specify multiple tables in the CANCEL ROLLBACK ON TABLE command,
rcvmanager verifies each table for referential integrity constraints.
Assume three tables T1 (table-id 6710), T2 (table-id 6711) and T3 (table-id 6712) exist in a
rollback list, and T2 has a foreign key referencing T1. Assume that T3 has only a selfreference and no constraints that reference other tables.
Entry ignored as table 0:6710 has referential integrity constraint.
Entry ignored as table 0:6711 has referential integrity constraint.
0000:6712 "SG"."T3"
Confirm y/n ?
> y
rcvmanager cancels rollback only on table T3.
If the tables specified for cancelling rollback are associated with join or hash indexes, then
rcvmanager lists all such tables and asks for a single confirmation.
Upon confirmation (y), the tables, as well as the associated join and hash indexes, are
marked as invalid.
When you specify multiple tables with the CANCEL ROLLBACK ON TABLE command,
and some tables have join or hash indexes and some have errors, then rcvmanager asks for
a single confirmation for all the valid tables.
Assume that Temp_Table with table-id 6707 is associated with a join index.
0000:6707 "EmployeeDB"."Temp_Table"
The following join and/or hash indexes will be invalidated:
"EmployeeDB"."Sal_Join"
Confirm y/n ?
> y
Utilities
205

If the table-id specified with the CANCEL ROLLBACK ON TABLE command was
specified previously or more than once in the same command, then rcvmanager reports a
message indicating a duplicate entry.
Assume that a rollback was cancelled previously on table-id 6712.
The following message appears:

Table 0:6712 already on the cancel rollback list, input ignored.
Enter command, "QUIT;" or "HELP;"
When you cancel rollback on a table, it becomes invalid and unavailable for any
subsequent transactions.
If any user attempts an update on such tables, then the following message appears:
"Invalid operation on table table-name."
In the following example, the INSERT into LogTable fails because rollback on the table was
cancelled earlier, and the table is invalid.
BTEQ -- Enter your DBC/SQL request or BTEQ command:
INSERT INTO EmployeeDB.LogTable;
*** Failure 5792 Invalid operation on table 'LogTable'.
Statement# 1, Info =0
*** Total elapsed time was 1 second.
CANCEL ROLLBACK Messages

One or more of the following messages can appear for each table specified with the CANCEL
ROLLBACK ON TABLE command, depending on the nature and status of the table:

nnnn:mmmm "DBname"."Tablename"
Confirm y/n ?
Table nnnn:mmmm does not exist in rollback list.
Table nnnn:mmmm already on the cancel rollback list, input

ignored.
The following join and/or hash indexes will be invalidated:

"DBName"."Join_IndexName"
Entry ignored as table nnnn:mmmm has referential integrity

constraint.
Valid Operations on Rollback-Cancelled Tables

Cancelling rollback on a table makes data in the table invalid and unusable. Only the following
operations are valid on the tables on which CANCEL ROLLBACK ON TABLE is performed.
206
Utilities

To...
Use the...
delete all the rows in the table and make it valid again
DELETE statement with the ALL option.
drop the table so that you can create it again
DROP TABLE statement.
retrieve a single table for SELECT operations
LOCKING request modifier with the READ

OVERRIDE option.
restore the table from an archive using ARC utility
RESTORE command.
take a dump of the table using ARC utility
DUMP command.
rebuild the table headers
Table Rebuild utility.
Note: CheckTable utility skips checking on tables whose rollback you cancel.
Utilities
207

DEFAULT PRIORITY
DEFAULT PRIORITY
Purpose
The DEFAULT PRIORITY command sets the priorities to the default values (that is,
REBUILD will be set to MEDIUM and RECOVERY to LOW).
Syntax
DEFAULT
PRIORITY
;
GS04A035
Usage Notes
If the PRIORITY command has never been executed or a SYSINIT has been performed on the
Teradata Database system, the priorities are set to the default values. The priority remains the
same until an initial or subsequent PRIORITY command changes it again. When the priority
command is entered during a rebuild or recovery operation, several minutes may elapse
before the new priorities take effect.
When you type the DEFAULT PRIORITY command, the event is logged in the /var/adm/
streams/error.mm-dd file in the Teradata Database system you are working on, and the
following messages are displayed.
YY/MM/DD HH:MM:SS RECOVERY priority changed to LOW; it was
<old priority>
YY/MM/DD HH:MM:SS REBUILD priority changed to MEDIUM; it
was <old priority>
When the default priority command is entered, both messages are generated.
208
Utilities

HELP
HELP
Purpose
The HELP command displays the syntax for the commands supported by rcvmanager.
Syntax
HELP
GT11A001
Example
The HELP command displays information for all the rcvmanager commands:
RCVMANAGER provides a means for the user to interact with the recovery sub-system.
The syntax of an RCVMANAGER command is:
HELP;
QUIT;
{
{
LIST {
{
STATUS [<proc-id>]
LOCKS
ROLLBACK TABLES
CANCEL ROLLBACK TABLES
{ REBUILD }
{
}
{ RECOVERY }
DEFAULT
PRIORITY
}
}
}
};
[ Low
]
[ Medium ] ;
[ High
]
PRIORITY;
CANCEL ROLLBACK ON TABLE <table-id> [{,<table-id>} ...] ;

ROLLBACK SESSION <host>, <session>
PERFORMANCE GROUP [<Perf Group Name>] ;
Where <Perf Group Name> is the name of a Performance Group.
The HELP command displays this help message text.
The QUIT command will terminate the RcvManager Utility.
.
.
.
Utilities
209

LIST CANCEL ROLLBACK TABLES
LIST CANCEL ROLLBACK TABLES
Purpose
The LIST CANCEL ROLLBACK TABLES command displays a report containing the table-id,
database name, and table name of the tables whose rollback processing during an online, userrequested abort or during Teradata Database system recovery is cancelled.
Syntax
LIST
CANCEL ROLLBACK TABLES
;
1102A046
Syntax element...
Specifies...
CANCEL ROLLBACK
TABLES
to display the list of tables upon which rollback is cancelled.
Usage Notes
This report lists all the tables for which rollback is being cancelled, as the process of
cancellation of rollback is not instantaneous. The report is in alphabetical order, by the
database name and table name.
Note: The LIST ROLLBACK TABLES command report does not include invalid tables, that is,
tables on which rollback is being cancelled. Therefore, if all the tables in a session have been
specified for rollback cancellation, they appear only in the output of the LIST CANCEL
ROLLBACK TABLES command.
If no tables on which rollback is cancelled exist, then only the column headings are displayed.
Example
The following is sample output of the LIST CANCEL ROLLBACK TABLES command.
PENDING CANCEL ROLLBACK TABLES AT 03:02:25 01/11/15
Table ID
Name
----------- ---------------------------------------------0000:6707
"Department"."Dept_Details"
0000:6712
"Department"."Temp_Table"
210
Utilities

LIST LOCKS
LIST LOCKS
Purpose
The LIST LOCKS command displays all locks currently held by transaction recovery.
Syntax
LIST
LOCKS
;
1102A047
Syntax element...
Specifies...
LOCKS
to displays locks held by online transaction recovery.
Usage Notes
The report displays the mode of the lock held (write or exclusive), the object type locked
(database, table, row range, or row hash) and the name of the object. The report is sorted
alphabetically by object name.
For row range and row hash locks, the row information does not display. Only the table within
which the row resides is displayed.
If rcvmanager is unable to determine the database name associated with an object,
rcvmanager displays the database ID in decimal and hex. The same is true if the table name
cannot be determined.
LIST LOCKS displays only those locks currently held by transaction recovery. You cannot
display locks held by online catchup or offline catchup.
Example
Only a single report is generated by the LIST LOCKS command. An example of this report is
shown below:
LOCKS HELD BY ONLINE TRANSACTION RECOVERY at
02:29:16 04/06/16
Lock
Mode
---Write
Write
Write
Exclusive
Exclusive
Utilities
Lock
Object
-----Database
Row hash
Row hash
Row hash
Table
Object
Name
---"AssetsDB"
"Clients"."TurnOver"
"EmployeeInfo"."NewHires"
"SampleDB"."pseudo table"
"SampleDB"."SampleTable"
211

Purpose
The LIST ROLLBACK TABLES command displays a report with the names and details of the
tables undergoing rollback in the Teradata Database system.
Syntax
LIST
ROLLBACK TABLES
;
1102A048
Syntax element...
Specifies...
ROLLBACK TABLES
to display the list of tables undergoing rollback in the Teradata

Database system.
Usage Notes
The tables undergoing rollback must satisfy the following criteria:
The table in a transaction must have more than 10000 rows yet to rollback on at least one
AMP.
The transaction must be in abort status.
The report displays only the headings if no rollback is in progress in the Teradata Database
system, or if no table satisfies these criteria.
The list is in descending order of the Host and Session, and then in alphabetical order by the
database name and table name.
The list excludes DBC tables and Permanent Journal (PJ) tables.
An asterisk (*) appears after the table name if the table has any Referential Integrity
constraints. You cannot cancel rollback on such tables.
Table names having non-printable characters are displayed in hexadecimal.
The list is in two parts, as shown in the following table.
Note: Global Temporary tables and Volatile tables are not listed.
212
This part...
Displays a list of tables in the sessions that are undergoing

rollback as part of...
online user rollback tables
user-requested abort.
Utilities

This part...
Displays a list of tables in the sessions that are undergoing

rollback as part of...
system recovery rollback tables
Teradata Database system recovery.
The following table explains what information the report columns provide:
Column...
Specifies the...
Host
ID of the host machine.
Session
session number in which rollback is in progress.
User ID
ID of the user who has initiated the session.
Performance Group
Performance Group associated with the session.

This determines the priority at which all transactions in the session
perform. See also ROLLBACK SESSION...PERFORMANCE GROUP
on page 226.
AMP W/Count
AMP on which the maximum number of Transient Journal rows are left
to be processed.
TJ Rows Left
maximum number of rows left to be processed in the Transient Journal

for the specific session on any AMP.
TJ Row Count
TJ Rows Done
number of rows processed in the Transient Journal for the specific

session.
Time Est.
estimated time (in hours and minutes) left for the rollback to complete
for that session.
Example
The following is a sample output of the LIST ROLLBACK TABLES command.
TABLES BEING ROLLED BACK AT 14:25:34
02/11/15
ONLINE USER ROLLBACK TABLE LIST

Host
---110
Session
-------23857
TJ Rows Left
------------30,478
Utilities
User ID
---------0000:0481
Performance Group
-------------------M
TJ Rows Done
------------1,098
AMP W/Count
----------1
Time Est.
-----------01:37
213

Table ID
--------0000:3883
0000:388B
0000:3884
0000:3889
Name
---------------------------------------------"rcv_user1"."cr_in001"
"rcv_user1"."cr_in002"
"rcv_user1"."cr_ri001"*
"rcv_user1"."cr_ri002"*
SYSTEM RECOVERY ROLLBACK TABLE LIST

Host
---0
Session
-------0
Table ID
--------0005:045A
0005:045B
TJ Row Count
-----------30,032
Name
---------------------------------------------"EmployeeDB"."Parent_Table"*
"EmployeeDB"."Temp_Table"
* - Referential Integrity table, cannot be used in CANCEL ROLLBACK ON

TABLE command.
214
Utilities

LIST STATUS
LIST STATUS
Purpose
The LIST STATUS command generates two reports:
Online Transaction Recovery Journal Counts
Down/Catchup AMP Recovery Status
The first reports transaction recovery information, and the second reports AMP recovery
information for unavailable AMPs.
Syntax
LIST
STATUS
;
1102A049
Syntax element...
Provides...
STATUS
transaction recovery information and AMP recovery information for

unavailable AMPS.
The displayed row count of a large sized table will be rounded to the
nearest thousand.
The recovery build records specify rebuild operations separately for each
index of a table, which causes a rebuild of both the primary and fallback
data for that index. Hence, the displayed sector count is not the total size
for the table as derived from other methods.
The sector count that is displayed is the sum of the estimated number of
sectors for both primary and fallback rows to be copied over from the
other AMPs in the cluster or recreated Non Unique Secondary Index
(NUSI) indexes for all index subtables of the table which have an OJ build
record. This includes the OJ build records of both the current pass and the
next pass.
Online Transaction Recovery Journal Counts

The Online Transaction Recovery Journal Counts allows the user to monitor transaction
recovery processing. It displays information on the transient journal and transactions that
were in progress during transaction recovery processing.
Utilities
215

LIST STATUS
Report Information
This report displays a list of all active recovery sessions and the maximum number of
transaction journal rows remaining to be processed for the AMP that has this maximum
count.
Since all AMPs must complete processing of a given recovery session before the processing of
the next session begins, this information is sufficient to calculate the worst-case count of
transaction journal entries to be scanned. You can use this count as a rough guide to recovery
processing time.
However, because this is only a rough guide, you must also take into consideration the
following variables when estimating the time involved in the recovery process:
The amount of work required by recovery to process a given transaction journal row can
vary by orders of magnitude; that is, some rows can be processed in a fraction of a second,
whereas others can take hours to process.
The transaction journal may contain many rows which require no recovery processing.
The online transaction recovery journal counts are updated by each AMP every time a
checkpoint is taken.
Thus, every time an AMP performs checkpoint, its online transaction recovery journal count
is decreased by 1000, and a later LIST STATUS command may display different results.
If no recovery sessions are active, the report title is printed without any contents.
Example
ONLINE TRANSACTION RECOVERY JOURNAL COUNTS at 13:49:28 98/02/06
Recovery
AMP
Session
Count
W/Count
------- ---------- ------1
765
12
2
38,432
1,388
20
Note: A new recovery session is created for each restart that is not a COLDWAIT restart.
Down/Catchup AMP Recovery Status

The example report contains three sets of data lines (together with a column header) for each
AMP participating in the down AMP recovery process. The first data line is explained by the
column headers. The second and third data lines indicate the status.
216
Utilities

LIST STATUS
The following table describes the Header and first-line data.

Data
Description
AMP to be
caught up
Indicates the AMP number to be caught up.

In addition to the processor number, this column might contain one of the
following notations:
* (asterisk)
Indicates that this AMP may be placed in online catchup if the Teradata Database
system restarts. If the displayed information is no longer valid by the time the
Teradata Database system restarts, the AMP might remain in offline catchup.
[1]
Indicates that one or more host utility locks are held in the cluster of the
recovering AMP and that the data on the AMP cannot be recovered because
there is a conflict between the host utility lock and the recovery locking
requirements.
[2]
Indicates that one or more 2 Phase Commit (2PC) in-doubt sessions exist within
the cluster of the recovering AMP.
Pass
Indicates the number of the recovery pass. At the beginning of a recovery pass all
rows in the OJ and CJ are extracted. This is the total number of rows to be processed
during that pass. If additional changes are sent to the AMP during the processing of
the current pass, they are queued up for the next pass. When the processing of rows
of the current pass is complete, the pass number is incremented and the rows for the
next pass are extracted from the OJ and CJ and processed.
Current Pass
The OJ column contains the number of rows in the ordered Teradata Database
system change journal to be processed during the current recovery pass. The CJ
column contains the number of rows in the changed row journal to be processed
during the current recovery pass.
Next Pass
The OJ column contains the number of rows in the ordered Teradata Database
system change journal to be processed during the next recovery pass. The CJ
column contains the number of rows in the changed row journal to be processed
during the next recovery pass.
If there are transactions that are updating user tables, these counts will go up as a
result of those updated transactions. Subsequent displays could show an increase in
the count.
Utilities
217

LIST STATUS
The following table describes the second data line (AMP Status).
Data
Description
Online Catchup
This AMP is online during recovery processing and accepts new work. Locks
are applied against all objects that need to be updated before new work is
accepted. In this status, the OJ count is usually zero and no new OJ or CJ
entries are created.
Offline Catchup
This AMP is logically (not physically) offline during recovery processing. No

new work is accepted by this AMP. Read locks are applied on the online AMPs
in the cluster only against the specific data of an object that has to be updated.
Not In Recovery
This AMP is not running down AMP recovery; it is physically offline.
The following table describes the third data line (AMP Recovery Status Line).
218
Data
Description
Transaction Recovery:
ZZZ,ZZZ,ZZ9 TJ Rows
Specifies the number of rows in the transaction recovery journal

to be processed in this recovery pass. The transaction recovery
journal contains the before images of all change objects affected
by every transaction. Transaction recovery is the first step of the
first recovery pass only. Each Z represents a digit and 9
represents any non-zero value.
Rebuilding Table [DBase.Table]:

Z9% complete in this pass
Specifies the name of the table being rebuilt and the percentage
of completion. Tables are rebuilt as a result of DDL changes
(that is, drop or add a column) to a table, or a MultiLoad
operation has affected a table while an AMP was down.
Change Row Recovery: Z9%

complete in this pass
This is caused by DML changes to the tables. This step of

recovery is entered when DML (for example insert update, or
delete) changes have been made to tables in a down AMP. While
an AMP is down, the other AMPs in the cluster modify their
fallback rows for the down AMP, and also modify their own
rows for which the down AMP has fallback responsibility.
Between Passes
The state of between passes arises since there is a five minute

pause between passes. Primarily, this is intended to allow
current operations, including any new work creating CJ and OJ
entries, to finish and release their locks, so that recovery will not
compete with online operations.
Miscellaneous OJ Processing
Indicates that time is spent processing the various short

running OJ entries, for example, releasing host utility locks.
Down
Indicates that this AMP is not involved in the recovery process.

However, statistics are maintained to indicate how much
accumulated work remains to be recovered before the AMP can
become operational.
Utilities

LIST STATUS
Data
Description
Not currently executing recovery
Indicates that the AMP has not yet reached the point of starting
Transaction Recovery or extracting OJ logs. The AMP is neither
at the very early stage in recovery or has not yet started it. (The
AMP might be down.)
Example
The Down AMP Recovery Status report generates the information shown in the following
screen example.
DOWN AMP RECOVERY STATUS AT 12:27:25 99/10/13
AMP to be
Current Pass
caught up
Pass
OJ
CJ
---------------------- ----------00001
0
0
0
- Down
Utilities
Next Pass
OJ
CJ
----------- ----------107
16,531
219

LIST STATUS proc-id
LIST STATUS proc-id
Purpose
The LIST STATUS command with the proc-id option specified as mmmm provides additional
detailed information about the recovery process of a specific AMP.
Syntax
LIST
STATUS
;
proc-id
1102A060
Syntax element...
Provides...
STATUS
transaction recovery information and AMP recovery information for

unavailable AMPs.
The displayed row count of a large sized table will be rounded to the nearest
thousand.
The recovery build records specify rebuild operations separately for each
index of a table, which causes a rebuild of both the primary and fallback
data for that index. Hence, the displayed sector count is not the total size
for the table as derived from other methods.
The sector count that is displayed is the sum of the estimated number of
sectors for both primary and fallback rows to be copied over from the other
AMPs in the cluster or recreated Non Unique Secondary Index (NUSI)
indexes for all index subtables of the table which have an OJ build record.
This includes the OJ build records of both the current pass and the next
pass.
proc-id
additional detailed information about the recovery process of a specific AMP

including the list of tables needing to be rebuilt.
The LIST STATUS proc-id option is only allowed for processors that are in
down AMP recovery (offline catchup) or the AMPs listed in the LIST STATUS
display. No additional detail information is provided for AMPs that are in
online catchup, since no build records exist for these AMPs.
220
Utilities

LIST STATUS proc-id
Usage Notes
The following additional information is reported:
Status
Pass number
Current pass count
Next pass count
A list of tables that need to be rebuilt, which also includes the following information:
Total rows
Total bytes
Rebuild speed in bytes per second
Estimated rebuild time
Note: All tables that need to be rebuilt will display in the list.
The tables for which an OJ build record exists
An estimated sector count of that table
The LIST STATUS proc-id command is only allowed for processors that are in down AMP
recovery (offline catchup), or the AMPs listed in the LIST STATUS display. No additional
detail information is provided for AMPs that are in online catchup since no build records exist
for these AMPs.
The following table shows the information contained in the columns under the TABLES TO
BE REBUILT report.
Utilities
Data
Description
Row Count
The number of rows in the table to be rebuilt.
221

LIST STATUS proc-id
Data
Description
Status
Displays up to six possible states where the recovery process may be when LIST
STATUS proc-id is executed.
Blank
Indicates that the table might be or will be rebuilt.
MultiLoad Target Table in Apply
Indicates that the table is a target table of a MultiLoad job. In this case the OJ build
record is discarded since the likelihood is that the AMP will be online before the
MultiLoad job finishes. If this is the case, MultiLoad will force a rebuild of the table
while the AMP is online. If the MultiLoad job completes before the AMP is online,
a new OJ build record is generated, meaning the rebuild will occur in a later pass.
Locked
Indicates that the table is currently locked by an EXCLUSIVE lock and that a valid
sector count cannot be taken. Unless the lock is part of a drop table operation, the
table will eventually be rebuilt in the next pass.
Non-Fallbacked
Indicates that a non-fallback table has been marked for a rebuild operation. Since
all non-fallback tables are deleted during rebuild operation, the sector count
associated with this table is meaningless.
Table Rebuild
Indicates that this OJ build record is for a table that is currently being rebuilt. This
OJ build record will be discarded.
Restore
Indicates that a table may have an OJ build record for it, but it is currently the
target of a (not necessarily active) restore operation. In this case, the OJ build
record is discarded.
Name
The name of the table to be rebuilt.
Note: If the LIST STATUS proc-id command is executed while creating an index on a table
that is to be rebuilt, then the time to rebuild the index is not added to the estimated rebuild
time for that table.
Example 1
This example shows a typical down AMP recovery status report, which displays the total rows,
total bytes, and the rebuild speed in bytes per second.
DOWN AMP RECOVERY STATUS AT 12:27:25 99/10/13
AMP to be
Current Pass
caught up
Pass
OJ
CJ
---------------------- ----------00001
0
0
0
- Down
222
Next Pass
OJ
CJ
----------- ----------107
16,531
Utilities

LIST STATUS proc-id
TABLES TO BE REBUILT
Row Count
Status
Name
-----------------------------------------------------------897,598
"RESCRIBE"."Rescribe11"
897,598
897,598
897,598
-------------------------------------------------------------------3,590,392
total rows.
2,582,240KB total bytes.
7,680KB is the rebuild speed in bytes per second.
The estimated rebuild time is 5.60 minutes.
Example 2
This example shows the output returned when the first table rebuild has not completed and an
estimate rebuild time cannot be given due to insufficient data.
TABLES TO BE REBUILT
Row Count
Status
Name
-----------------------------------------------------------161,216
161,216
161,216
161,216
161,216
161,216
161,216
-------------------------------------------------------------------1,128,512
total rows.
There is insufficient data to estimate the rebuild time.
Utilities
223

QUIT
QUIT
Purpose
The QUIT command exits rcvmanager.
Syntax
QUIT
GT11A004
Usage Notes
You can only type this command when rcvmanager is prompting for a command.
You cannot abort a rcvmanager command in progress.
224
Utilities

REBUILD/RECOVERY PRIORITY
REBUILD/RECOVERY PRIORITY
Purpose
The REBUILD/RECOVERY PRIORITY command sets or displays a priority level for use by
the Table Rebuild utility and a Teradata Database system recovery operation.
Syntax
REBUILD
RECOVERY
PRIORITY
HIGH
MEDIUM
LOW
GT11A005
Usage Notes
Setting a priority will apply to future and currently running operations. The PRIORITY
command takes the following forms.
Both priorities are independent of each other and can hold different values at any period of
time. That is, recovery initiated rebuilds will use recovery priority and not rebuild priority. If
you type the command without specifying high, medium, or low, the current priority setting
is displayed.
The REBUILD PRIORITY command applies to any Table Rebuild started from the console,
automatic table rebuild due to disk error recovery, and MLOAD rebuild of target tables for
non-participant online AMPs.
The REBUILD PRIORITY command sets a priority for the rebuild utility. You can select
HIGH, MEDIUM, or LOW level priority. If you do not explicitly set a priority, default rates
exist and will be used. If you do not type a new priority, the current priority setting is
displayed.
The RECOVERY PRIORITY command sets a priority for the Teradata Database system
recovery operation. You can select HIGH, MEDIUM, OR LOW level priority. If you do not
explicitly set a priority, the current priority setting is displayed. The priority settings are saved
in the Recovery Status system table.
Utilities
225

ROLLBACK SESSION...PERFORMANCE GROUP
Purpose
The ROLLBACK SESSION... PERFORMANCE GROUP command sets or displays the
Performance Group of rollbacks for a specified session.
Syntax
ROLLBACK SESSION
A
host_id,session_id
;
PERFORMANCE GROUP
Perf_Group_Name
1102A140
Syntax element...
Specifies the...
host_id
identifiers for the host and session whose Performance Group you
want to see or set.
session _id
You must specify both these identifiers in the order mentioned:

host_id followed by a comma and session _id.
The session _id maximum is 4294967296.
The session _id must be in the rollback list, that is, at least one of the
tables in the LIST ROLLBACK TABLES list must be from the session
specified. For other rules, see Usage Notes on page 227.
Perf_Group_Name
name of a Performance Group whose priority level you want to apply

to rollback operations in the specified session. (Optional)
The Teradata Database system will execute rollbacks in the specified
session at the priority level associated with this Performance Group.
You can specify one of the pre-defined Performance Groups: L (low),
M (medium), H (high) or R (rush). The default priority is R. Any
Performance Group other than these has to be explicitly defined for
usage.
If you do not specify a Perf_Group_Name, then the current
Performance Group of the session is displayed.
For details on Performance Groups, see Chapter 21: Priority
Scheduler (schmon) (SLES 10 only).
226
Utilities

Usage Notes
Rollback processing runs at the priority defined for the session, that is, the priority associated
with the Performance Group for the session. If no priority is specified, rollback runs at R
priority by default.
The ROLLBACK SESSION... PERFORMANCE GROUP command allows you to change the
priority. By reducing the priority of less important rollbacks, you can increase the Teradata
Database system resource availability for other processes in the Teradata Database system.
The ROLLBACK SESSION... PERFORMANCE GROUP command affects the Performance
Group and priority only for the rollback process, not for the user session.
If the DBS Control General field RollbackPriority is set to TRUE, the rollback process runs
with the priority with which the recent request of the transaction was submitted. Here the
ROLLBACK SESSION... PERFORMANCE GROUP command can override the DBS Control
Rollback Priority field setting and change the priority of the rollback at any point of time.
The following usage rules apply to the ROLLBACK SESSION... PERFORMANCE GROUP
command:
The host-id and the session-id specified with the ROLLBACK SESSION...PERFORMANCE
GROUP command must be in the rollback tables list generated by the LIST ROLLBACK
TABLES command from rcvmanager. This indicates that rollback is in progress in that
session. You either can display or change the Performance Group.
If you specify a host-id or a session-id that does not exist in the rollback list, rcvmanager
displays a message, and the command is ignored.
Example 1: Valid Command
The Performance Group H specified in the following command takes effect for the named
host-id and session-id.
> ROLLBACK SESSION 52, 1664 PERFORMANCE GROUP H;
ROLLBACK SESSION PERFORMANCE GROUP command completed successfully.
Example 2: Non-valid Command

The following command does not take effect because the host-id and session-id are not in
the rollback list and are not valid.
> ROLLBACK SESSION 1, 1005 PERFORMANCE GROUP;
No rollback in progress in host 1, session 1005.
Enter command, "QUIT;" or "HELP;"
If you do not specify a Performance Group with the ROLLBACK SESSION...

PERFORMANCE GROUP command, then the output displays the current Performance
Group setting for the specified host-id and session-id.
In this example, no new Performance Group name is specified. rcvmanager displays the
current Performance Group for the session.
> ROLLBACK SESSION 52, 1664 PERFORMANCE GROUP;
Current rollback Performance Group for host 52 session 1664 is M.
Utilities
When you execute the ROLLBACK SESSION... PERFORMANCE GROUP command, an

event is logged in the Teradata Database system, even if the specified Performance Group is
the same as the current Performance Group.
227

If you specify an invalid Performance Group name, no event is logged.

The following example displays the event log entry after successful execution of the
rcvmanager command.
> ROLLBACK SESSION 52, 1664 PERFORMANCE GROUP H;
ROLLBACK SESSION PERFORMANCE GROUP command completed successfully.
02/01/31 15:34:28 Rollback Performance Group for 52, 1664 changed to
H;
it was M.
When you specify a user-defined Performance Group name, the equivalent priority for
that Performance Group is obtained to change the priority of the rollback for the specified
host-id and session-id.
If the specified Performance Group is not valid, rcvmanager reports a message, and the
command is ignored.
In this example, the Performance Group name is not valid.
> ROLLBACK SESSION 52, 1664 Performance Group InvPrfGrp;
The specified Performance Group name is invalid.
228
Utilities
Resource Check Tools

(dbschk, nodecheck, syscheck)
CHAPTER 27
Resource Check Tools are designed to assist in the following:
Identifying a slowdown or hang of Teradata Database
Providing Teradata Database system statistics to help you determine the cause of the slow
down or hang
Resource Check Tools Utilities

Resource Check Tools include several components, as shown in the following table.
Component
Description
dbschk
A standalone tool that monitors the Teradata Database response time.
nodecheck
A standalone tool that displays local, node-level resources only. Provides

summary data to syscheck for analysis or provides detailed output to the
nodecheck log file, which is used later for analysis when called from syscheck.
syscheck
A standalone tool that analyzes relevant Teradata Database system data from the
local node.
syscheckrc
A file containing user-defined parameters for syscheck and nodecheck. These

parameters specify alert and warn threshold levels for evaluating system
performance.
Runs From
The resource check tools run from the Linux command line.
Utilities
229
Chapter 27: Resource Check Tools (dbschk, nodecheck, syscheck)

dbschk
dbschk
Purpose
dbschk monitors Teradata Database response time. If the response time indicates the database
is slow or unresponsive, dbschk runs a specified program or script, and logs an event.
The factory default settings for dbschk options can be changed using command-line options.
Settings specified on the command line can be optionally saved as new default settings for
dbschk. New defaults persist across sessions, and are propagated to all nodes of MPP systems.
The -reset option restores the factory default settings.
Syntax
dbschk
-h
-l
-reset
-delay sleep_seconds
-job job_program
-logfile file
-logflush flush_seconds
-n iterations
-power switch
-rate attempts
-save
-timeout wait_seconds
-trigger trigger_program
1102C141
Syntax Element
Description
-delay sleep_seconds
Sets the time that dbschk waits between successful executions of the
all-AMP requests to Teradata Database.
sleep_seconds in a positive integer that specifies the number of seconds
dbschk waits. The factory default is 1200 seconds.
Note: Setting a very low value for -delay can adversely affect system
performance.
-h
230
Displays a short description of dbschk and the command-line options.
Utilities

dbschk
Syntax Element
Description
-job job_program
Specifies the program or script dbschk runs to check Teradata Database

response time. The specified program or script should generate an all-AMP
request.
Note: job_program should specify the complete path to the program or
script, and any optional command-line parameters you wish to use to start
the program. If job_options includes any space characters, enclose the entire
job_options specification within double quotation marks.
Default dbschk settings are used by all nodes of MPP systems. If you use the
-save option to store the current -job setting as a custom default, ensure that
the specified program or script exists on all nodes.
-l
Displays the current default and factory default dbschk settings. The current
default settings are used when dbschk is run with no command-line
options.
-logfile file
Specifies log file dbschk will use. All dbschk program output is directed to
this file. If the file does not exist, dbschk will create it.
Note: file should specify the complete path to the log file. If the path
includes any space characters (for example, Program Files), enclose the
entire file specification within double quotation marks.
To have dbschk output displayed on screen, specify file as stdout.
If you do not specify a -logfile on the command line, dbschk will use the file
specified as the current default logfile. Use the -l option to see the current
dbschk default values.
The factory default log file is:
/var/opt/teradata/tdtemp/dbschk.log.
Note: Instances of dbschk log to the logfile that is in effect when they are
started. Multiple instances of dbschk can share the same log, or use different
logs. For example, an instance of dbschk can be started automatically when
Teradata Database starts and set to log to a file, while other instances of
dbschk can be run from the command-line using the -logfile option to have
the dbschk output directed to the screen (stdout).
-logflush
flush_seconds
Specifies the time after which the log file is flushed and overwritten with
new output from dbschk.
flush_time is a positive integer that specifies the number of seconds between
log flushes. The factory default is 3600 seconds.
Note: Setting a very low a value for -logflush can adversely affect system
performance. Setting a very high value can result in a very large log file.
-n iterations
Specifies the number of times dbschk runs. If -n is not specified, dbschk

runs continuously until stopped by the user.
iterations is a positive integer greater than zero.
Utilities
231

dbschk
Syntax Element
Description
-power switch
Determines whether dbschk can run.

switch can be OFF or ON.
OFF prevents dbschk from running both from the command line and
automatically the next time Teradata Database starts.
This is the default.
ON allows dbschk to run from the command-line. If the -save option is
used to make ON the new default -power setting, dbschk will be started
automatically whenever Teradata Database starts.
OFF and ON can be entered in upper, lower, or mixed case. 0 can be used as
a substitute for OFF, and 1 can be used as a synonym for ON.
-rate attempts
Specifies the number of times that dbschk executes an all-AMP request and
waits for a response before running the program specified by the -trigger
parameter.
attempts is a positive integer. The factory default is 5.
-reset
Restores the dbschk factory default settings. To see the factory default
settings, use the -l option.
Note: The default dbschk settings are global to the system. They are used
when dbschk is run from any node of MPP system.
-save
Saves the settings that are specified on the command line as new default
values for subsequent runs of dbschk from any node of the system. If the save parameter is not specified on the command line, other command-line
parameters are only in effect for the current run of dbschk.
When -save is included on the command-line, dbschk does not check
database responsiveness, but instead only saves the current command-line
settings as new dbschk default values.
Note: The default dbschk settings are global to the system. They are used
when dbschk is run from any node of MPP system. If you use the -save
option to store current -job or -trigger settings as defaults, ensure the
specified programs or scripts exist on all nodes of the system.
-timeout
wait_seconds
Specifies how long dbschk waits for a response from Teradata Database after
running the program specified by the -job option. Once the time specified
by -timeout has elapsed with no response from the database, dbschk runs job again. As long as there is no response from the database, dbschk
continues trying -job the number of times specified by the -rate parameter
before running the program specified by the -trigger parameter.
wait_seconds is a positive integer. The factory default is 300 seconds.
Note: Setting a very low a value for -timeout is impractical, and can
adversely affect system performance.
232
Utilities

dbschk
Syntax Element
Description
-trigger
trigger_program
Specifies a program or script to run if there is no response from Teradata

Database after dbschk has tried the number of times specified by -rate, and,
for each attempt, has waited the time period specified by the -timeout
parameter.
Note: Default dbschk settings are used by all nodes of MPP systems. If you
use the -save option to store the current -trigger setting as a custom default,
ensure that the specified program or script exists on all nodes.
Usage Notes
Parameters set on the dbschk command line are valid only for the current session unless the
-save parameter is used.
To see the current and factory default settings, use dbschk -l.
When dbschk starts, if the log file is 5MB or larger, dbschk flushes the current log entries to a
new file that has .old appended to the original log file name. Logging continues to the
original log file. For example, when an original log file named myfile.log grows to 5MB, the
entries are moved from myfile.log to myfile.log.old, and logging continues to myfile.log. The
next time myfile.log reaches 5MB, the information is flushed again to myfile.log.old,
overwriting the information that was in the .old file.
Example 1
The following example uses the -l option to display the current dbschk default settings.
> dbschk -l
Current default values :
power
: ON
timeout : 120 seconds
rate
: 3 trials
delay
: 600 seconds
logflush : 1200 seconds
job
: csp -mode list -source table
logfile : /var/opt/teradata/tdtemp/dbschk.log
trigger : pdestate -a
Factory default values :
power
: OFF
rate
: 5 trials
delay
: 1200 seconds
job
Utilities
233

dbschk
Example 2
The following example runs dbschk with the -save option, setting the default values to allow
dbschk to run and to send dbschk output to the computer screen.
>dbschk -save -power ON -logfile stdout
Current default values :
power
: ON
rate
: 5 trials
delay
: 1200 seconds
job
logfile : stdout
Factory default values :
power
: OFF
rate
: 5 trials
delay
: 1200 seconds
job
logfile : D:\Program Files\Teradata\Tdat\TdTemp\dbschk.log
Do you want to save the new settings as dbschk default values? (y/n): y
New settings saved...
(dbschk): Normal termination - OK
234
Utilities

dbschk
Example 3
The following example runs dbschk to check database responsiveness. The command-line
settings cause dbschk to run two times, waiting five seconds between runs.
>dbschk -n 2 -delay 5
(dbschk): current default values :
power
: ON
rate
: 5 trials
delay
: 5 seconds
job
logfile : stdout
Factory default values:
power
: OFF
rate
: 5 trials
delay
: 1200 seconds
job
csp:
csp:
csp:
csp:
csp:
csp:
csp:
Searching for dumps in Teradata database Crashdumps on the local system

3 dumps found, 3 dumps to process
Sel
ID (date-time-token)
Nodes Event Instigator
--- ---------------------- ----- ----- -----------------------*
2007/05/24-09:23:57-04
1 10416 16383/13/(12351)
*
2007/05/24-09:23:41-03
1 10416 16383/13/(12191)
*
2007/05/24-09:15:30-01
1 10196 16384/0/(11215)
(dbschk): retstatus = 1010, status = 0, childpid = 1010

(dbschk): Sample Query finished normally, response time=3 seconds,
(dbschk): sleep 5 seconds before restart.
csp: Searching for dumps in Teradata database Crashdumps on the local system
csp: 3 dumps found, 3 dumps to process
csp: Sel
ID (date-time-token)
Nodes Event Instigator
csp: --- ---------------------- ----- ----- -----------------------csp: *
2007/05/24-09:23:57-04
1 10416 16383/13/(12351)
csp: *
2007/05/24-09:23:41-03
1 10416 16383/13/(12191)
csp: *
2007/05/24-09:15:30-01
1 10196 16384/0/(11215)
(dbschk): retstatus = 1020, status = 0, childpid = 1020
(dbschk): Sample Query finished normally, response time=2 seconds,
(dbschk): Normal termination - OK
Utilities
235

nodecheck
nodecheck
Purpose
nodecheck is a command-line diagnostic tool that finds node-level resource values on the
local node. nodecheck provides summary data by node to syscheck for analyses or provides
detailed output to the nodecheck log file, which is used later for analysis by syscheck.
Syntax
nodecheck
-D
-f log
-h
-I
-L
-r rscfile
-t
n
log
-v
FF07D399
Syntax Element
Description
-D
Displays threshold values for -nodeonly and -timercontrol tunables in

syscheckrc format.
Use this option to redirect the output to quickly create a syscheckrc file that you
can customize. Then use the -r rscfile option to read from that customized
syscheckrc file.
-f log
Overrides the default log file location as specified in the -L option.

The -f option must be used with the -L option.
The directory path must previously exist. If you specify a file, that file is written.
If you specify a directory, then the default filename specified in the -L option is
written to that directory.
236
-h
Provides basic help on command line options.
-I
Lists threshold values for -nodeonly and -timercontrol tunables.
Utilities

nodecheck
Syntax Element
Description
-L
Logs the output to a file in the /tpi-data directory on the node where nodecheck
is run.
The default log filename is nodecheck with an extension indicating the TPA
cyclecount at the time of the run (for example, nodecheck.2).
You can specify a specific log filename or location using the -f log option.
Additional tools are executed during logging mode, but their output is sent only
to the resulting file.
-r rscfile
Specifies an additional resource file whose values will override those in the
default syscheckrc file (and optional syscheckrc file, if one exists). For
information on the syscheckrc file, see syscheckrc File on page 248.
-t
Directs nodecheck to read node-level resource data from one of the following
previously created log files.
If you use n, nodecheck reads data from the /tpi-data/nodecheck.n file,
where n indicates the TPA cyclecount at the time of the run.
If you use log, nodecheck reads data from a user-defined path or filename
that contains the log information.
-v
Displays the current resource values on the local node, evaluates the resource
values, and notifies you of the status of all tunable resources, regardless of level.
Usage Notes
If you invoke nodecheck without any options, then nodecheck does the following:
Displays the current resource values on the local node
Evaluates the resource values
Notifies you of resources which have reached WARN or ALERT levels
The defined node-level resource names and values are located in the -nodeonly section of the
syscheckrc configuration file. The syscheckrc file is read and processed at the following
locations:
/usr/pde/etc directory (default)
/pde directory (optional)
Note: When executed through syscheck, nodecheck will only read and process the local
syscheckrc file. This means that changes to the -timercontrol section must be propagated to all
nodes in order for nodecheck to run similarly on each node.
Creating a Log File

To run a single instance of nodecheck, creating a log file for later analysis, do the following:
type:
nodecheck -L -f log
where log is the eventual location (a user-defined path or filename) that contains the log
information. nodecheck will still print and evaluate the current resources.
Utilities
237

nodecheck
Example 1
The following is an example of running nodecheck with no options.
nodecheck
Reading Node Resources... please wait...
Which Linux are we: SuSE
FreeMemory(Pages) and FreeSwap(Blocks)
/usr/bin/sar -r 2 5
FREEMEM
13648.5
FREESWAP
65396880
PDE Msg Daemon Queue length
/usr/pde/bin/pdeglobal msg -knode
MSGEVCOUNT
0
BNS Block Queue
/usr/pde/bin/puma -D BlockStats/d
BNSBLKQ
0
Available AMP Worker Tasks
/usr/pde/bin/puma -c
Count
Vproc
55
0
56
1
56
2
56
3
56
4
56
5
BNS reject% for different Message types
/usr/pde/bin/tdnstat -a 5 2
SBR_FCount%
Message Type
0
RXGRPREC
0
RXGRPSEG
0
RXP2PREC
0
RXP2PSEG
SegTblFull%
Message Type
0
RXGRPSEG
0
RXP2PSEG
Evaluating results... please wait...
No tunables show status of WARN or ALERT
Example 2
The following is an example of running syscheck with the -D option to display -nodeonly and
-timercontrol tunables in syscheckrc format.
nodecheck -D
-nodeonly
AMPWT
BNSBLKQ
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
238
WARN
WARN
WARN
WARN
WARN
WARN
-0
500
-1000
-2000
100
90
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
-0
100
-500
-1000
300
100
Utilities

nodecheck
SEGTBLFULL
WARN
80
ALERT
100
-timercontrol
SARSAMPLE
SARSLEEP
TDNSTATSAMPLE
TDNSTATSLEEP
5
2
2
5
Example 3
The following is an example of running syscheck with the -I option to display -nodeonly and
-timercontrol tunables.
nodecheck -I
Tunable
AMPWT
BNSBLKQ
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
SEGTBLFULL
WARN
<=0
>=500
<=1000
<=2000
>=100
>=90
>=80
Tunable
SARSAMPLE
SARSLEEP
TDNSTATSAMPLE
TDNSTATSLEEP
Value
5
2
2
5
ALERT
<=0
>=100
<=500
<=1000
>=300
>=100
>=100
Example 4
The following is an example of running nodecheck with the -L option.
nodecheck -L
Writing to log file: /tpi-data/nodecheck.8
/usr/bin/sar -r 2 5
FREEMEM
13591.25
FREESWAP
65396880
MSGEVCOUNT
0
BNS Block Queue
BNSBLKQ
0
Count
Vproc
55
0
56
1
56
2
Utilities
239

nodecheck
56
56
56
3
4
5

SBR_FCount%
Message Type
0
RXGRPREC
0
RXGRPSEG
0
RXP2PREC
0
RXP2PSEG
SegTblFull%
Message Type
0
RXGRPSEG
0
RXP2PSEG
Example 5
The following is an example of running nodecheck with the -v option.
nodecheck -v
/usr/bin/sar -r 2 5
FREEMEM
13319.5
FREESWAP
65396880
MSGEVCOUNT
0
BNS Block Queue
BNSBLKQ
0
Count
Vproc
55
0
56
1
56
2
56
3
56
4
56
5
SBR_FCount%
Message Type
0
RXGRPREC
0
RXGRPSEG
0
RXP2PREC
0
RXP2PSEG
SegTblFull%
Message Type
240
Utilities

nodecheck
0
0
RXGRPSEG
RXP2PSEG

Resource
Description
Current
Level
Current
Value
FreeMemory(Pages)
FreeSwap(Blocks)
PDE Msg Daemon Queue Length
BNS Block Queue Length
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(SEGTBLFULL)
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
13319.5
65396880
0
0
55
56
56
56
56
56
0
0
0
0
0
0
Threshold
Value
Vproc Number/
Message Type
0
1
2
3
4
5
RXGRPREC
RXGRPSEG
RXP2PREC
RXP2PSEG
RXGRPSEG
RXP2PSEG
Example 6
The following is an example of running nodecheck with the -v option and reading output
from a previously generated log file. The TPA cyclecount is specified to gain access to the
recently created default log file.
nodecheck -t 8 -v
Reading from log file: /tpi-data/nodecheck.8
/usr/bin/sar -r 2 5
FREEMEM
13591.25
FREESWAP
65396880
MSGEVCOUNT
0
BNS Block Queue
BNSBLKQ
0
Count
Vproc
55
0
56
1
56
2
56
3
56
4
56
5
Utilities
241

nodecheck
SBR_FCount%
Message Type
0
RXGRPREC
0
RXGRPSEG
0
RXP2PREC
0
RXP2PSEG
SegTblFull%
Message Type
0
RXGRPSEG
0
RXP2PSEG
Resource
Description
Current
Level
FreeMemory(Pages)
FreeSwap(Blocks)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
Current
Value
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Threshold
Value
13591.25
65396880
0
0
55
56
56
56
56
56
0
0
0
0
0
0
Vproc Number/
Message Type
0
1
2
3
4
5
RXGRPREC
RXGRPSEG
RXP2PREC
RXP2PSEG
RXGRPSEG
RXP2PSEG
Messages
nodecheck displays the following types of messages.
The message...
Appears...
Error
nodecheck encounters any error to extract the resource value.

An Error message could occur if nodecheck cannot find or execute the related
PDE tool to extract the resource value. If STDERR output exists, it displays.
Warning
242
invalid information is found during processing of the syscheckrc file or for other
reasons.
Utilities

syscheck
syscheck
Purpose
syscheck monitors the system for signs of congestion that might lead to system slowdowns or
perceived hangs and notifies you when Warning or Alert thresholds are reached.
Syntax
syscheck
-D
-h
-I
-L
-n nl
-r rscfile
-t n
-v
FF07D398
Syntax Element.
Description
-D
Displays threshold values for -nodeonly and -timercontrol tunables in

syscheckrc format.
Use this option to redirect the output to quickly create a copy of the
syscheckrc file you can customize. Then use the -r rscfile option to read from
your customized syscheckrc file.
syscheck will not take into account the -timercontrol section of the custom
syscheckrc file you indicate with the -r rscfile option. Because syscheck
executes nodecheck locally and on each remote node, modifications to the
default and custom syscheckrc files on the local node will be considered for
that local spawn of nodecheck. That is, where syscheck is concerned, timercontrol changes are local, and -nodeonly changes global. Where
nodecheck is concerned, all changes take effect locally.
Utilities
-h
Provides basic help on command line options.
-I
Lists threshold values for -nodeonly and -timercontrol tunables.
243

syscheck
Syntax Element.
Description
-L
Logs the output to a file in the /tpi-data directory on each node where
nodecheck is run.
The default log filename is nodecheck with an extension indicating the TPA
cyclecount at the time of the run (for example, nodecheck.2).
You can specify a specific log filename or location using the -f log option.
Additional tools are executed during logging mode, but their output is sent
only to the resulting file. For more information, see nodecheck on
page 236.
-n nl
Specifies the list of nodes on which nodecheck is invoked.

By default, nodecheck is invoked on all live TPA nodes.
Note: Separate the nodes in the list by commas.
-r rscfile
Specifies an additional resource file whose values will override those in the
default syscheckrc file (and optional syscheckrc file, if one exists).
Note: syscheck will not take into account the -timercontrol section of the
custom resource file you indicate with the -r rscfile option. Since syscheck
executes nodecheck locally as well as on each remote node, modifications to
the default and optional syscheckrc file on the local nodes will be considered
for that local spawn of nodecheck. That is, where syscheck is concerned,
-timercontrol changes are local, and nodeonly changes are global. Where
nodecheck is concerned, all changes take effect locally.
-t n
Directs nodecheck to read node-level resource data from a previously created

log file (with a default name) on each node.
nodecheck reads the data from the /tpi-data/nodecheck.n file, where n
indicates the TPA cyclecount at the time of the run.
-v
Displays all the resource values for each node, evaluates the resource values,
and notifies you of the status of all tunable resources, regardless of level.
Usage Notes
syscheck does not automatically reset the system when any threshold is reached. The DBA or
operator decides when to reset the system if the congestion persists.
syscheck is a system-wide tool (as compared to nodecheck, which is node-only tool) and does
the following in this order:
244
Utilities

syscheck
IF you invoke syscheck...
THEN syscheck...
without any options
spawns an instance of nodecheck on all live TPA nodes.

compares the nodecheck results from each node against threshold
values indicated in the local syscheckrc file, which are located on the
machine where you run syscheck.
displays the current resource values on the local node.
evaluates the resource values.
notifies you of resources which have reached WARN or ALERT
levels.
with the -v option
spawns an instance of nodecheck on all live TPA nodes.

compares the nodecheck results from each node against threshold
values indicated in the local syscheckrc file, which are located on the
machine where you run syscheck.
displays the current resource values on the local node.
evaluates the resource values.
notifies you of the status of all tunable resources, regardless of level.
syscheck also checks the Teradata PDE and Database states on the node on which you execute
syscheck, informing you if either is not in a fully functional state.
The defined node-level resource names and threshold values for alerts and warnings are
located in the -nodeonly section of the syscheckrc configuration file. For more information,
see syscheckrc File on page 248.
Example 1
The following is an example of running syscheck with no options.
syscheck
Processing resource values for WARN/ALERT status... please wait...
NODE ID: localhost
Resource
Description
FreeMemory(Pages)
Utilities
Current
Level
WARN
Current
Value
992
Threshold
Value
<=1000
Vproc Number
Message Type
245

syscheck
Example 2
The following is an example of running syscheck with the -D option to display -nodeonly and
-timercontrol tunables in syscheckrc format.
syscheck -D
-nodeonly
AMPWT
BNSBLKQ
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
SEGTBLFULL
VPRPAGES
-timercontrol
SARSAMPLE
SARSLEEP
TDNSTATSAMPLE
TDNSTATSLEEP
WARN
WARN
WARN
WARN
WARN
WARN
WARN
WARN
-0
500
-1000
-2000
100
90
80
-2
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
-0
100
-500
-1000
300
100
100
-0
1
1
1
1
Example 3
The following is an example of running syscheck with the -I option to display -nodeonly and
-timercontrol tunables.
syscheck -I
Tunable
AMPWT
BNSBLKQ
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
SEGTBLFULL
VPRPAGES
Tunable
SARSAMPLE
SARSLEEP
TDNSTATSAMPLE
TDNSTATSLEEP
WARN
<=0
>=500
<=1000
<=2000
>=100
>=90
>=80
<=2
Value
1
1
1
1
ALERT
<=0
>=100
<=500
<=1000
>=300
>=100
>=100
<=0
Example 4
The following is an example of running syscheck with the -L option.
syscheck -L
Processing resource values for WARN/ALERT status... please wait...
NODE ID: localhost
246
Utilities

syscheck
Example 5
syscheck -v
Processing resource values for any status... please wait...
NODE ID: localhost
Resource
Description
FreeMemory(Pages)
FreeSwap(Blocks)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
Current
Level
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Current
Value
Threshold
Value
3158
620128
0
0
55
56
0
0
0
0
0
0
Vproc Number/
Message Type
0
1
RXGRPREC
RXGRPSEG
RXP2PREC
RXP2PSEG
RXGRPSEG
RXP2PSEG
Example 6 - Windows
syscheck -t 22 -v
Logfile to be processed: e:\PROGRA~1\Teradata\tdat\tdconfig\tmp\tpidata\nodecheck.22
Processing resource values for any status... please wait...
NODE ID: localhost
Resource
Description
FreeMemory(Pages)
FreeSwap(Blocks)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
BNS Msg Reject%(FC)
Utilities
Current
Level
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
OK
Current
Value
3207
620128
0
0
55
56
0
0
0
0
0
0
Threshold
Value
Vproc Number/
Message Type
0
1
RXGRPREC
RXGRPSEG
RXP2PREC
RXP2PSEG
RXGRPSEG
RXP2PSEG
247

syscheck
syscheckrc File
syscheckrc is a text file that contains system, kernel, and Teradata Database-specific
parameters. When these parameters are exceeded, your system resources may run low,
resulting in poor performance.
Although not mandatory, all copies of syscheckrc should be identical on all nodes. However,
each copy of syscheckrc must correspond to the specific node on which syscheckrc resides.
Caution:
Do NOT modify the default syscheckrc file. To create a custom syscheckrc file, see Creating a
syscheckrc File on page 250.
The default syscheckrc file is read and processed at the following locations.
On...
The default syscheckrc file is located in the...
Linux
/usr/pde/etc directory.
Windows
Program Files\Teradata\TDAT\LPDE\etc directory.
Default syscheckrc File Example

syscheck reads and parses the resource files at startup. Resource files have a line-oriented
syntax:
A line starting with a # is a comment.
A line containing only comments or white space (spaces or tabs) is ignored.
Each line can have a single resource entry that has name and value strings separated by
white space.
The following is an example of the default syscheckrc file.

#-testdriver:
## This section is provided as a tool for GSC to provide test input
## to syscheck and nodecheck. This section is not meant for
## modification by the customer. NOTE: Modification of this
## section can yield unexpected errors or results. To override a
## tool that is used in nodecheck or syscheck, uncomment the
## appropriate line and provide a different path or executable for
## the tool.
# SAR
%PDE_BIN\sar.exe
# PUMA
%PDE_BIN\puma.exe
# TDNSTAT
%PDE_BIN\tdnstat.exe
# BLMSTAT
blmstat.exe
# VPROCMANAGER %PDE_BIN\vprocmanager.exe
# PDESTATE
%PDE_BIN\pdestate.exe
# PCL
%PDE_BIN\pcl.exe
# MPPLIST
%PDE_CFG\mpplist
# NETECHO
%PDE_BIN\tdinfo.exe
# NODECHECK
%PDE_BIN\nodecheck.bat
# CONTROLGDO
%PDE_BIN\controlgdo.exe
# PDEGLOBAL
%PDE_BIN\pdeglobal.exe
-nodeonly: This section defines node-only parameters
AMPWT
WARN -0
ALERT -0
BNSBLKQ
WARN 500
ALERT 100
248
Utilities

syscheck
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
SEGTBLFULL
VPRPAGES
WARN -1000
WARN -2000
WARN 100
WARN 90
WARN 80
WARN -2
ALERT -500
ALERT -1000
ALERT 300
ALERT 100
ALERT 100
ALERT -0
-timercontrol
# used to override behavior of sar and tdnstat in nodecheck
# i.e. sar.exe -r SARSLEEP SARSAMPLE
# values need to be integers >= 1
SARSLEEP
SARSAMPLE
TDNSTATSLEEP
TDNSTATSAMPLE
Caution:
2
5
5
2
The -testdriver section maps to the executables of each node and is different, depending on
the platform.
Do NOT modify the -testdriver section. If you modify the -testdriver section, nodecheck and
syscheck might fail.
The -nodeonly section allows you to define the WARN and ALERT threshold levels for
each system resource.
If the threshold value is negative, then the condition (either WARN or ALERT) will be
triggered when that system resource attribute falls below that value. Otherwise, the
condition is triggered when the attribute rises above that value.
The default syscheckrc file contains default values. You should never edit the default
syscheckrc file itself. You can customize the warning and alert levels in a custom syscheckrc
file. For more information on creating your own customized syscheckrc file, see Creating
a syscheckrc File on page 250.
The following table describes each system resource attribute.
Utilities
System Resource Attribute
Description
AMPWT
Warning and alert threshold level for available (or running out) of
AMP work tasks (AWTs).
BNSBLKQ
Warning and alert threshold level for BNS services in BNS block
queue.
FREEMEM
Warning and alert threshold levels for freemem pages.
FREESWAP
Warning and alert threshold levels for freeswap blocks.
MSGEVCOUNT
Warning and alert threshold levels for message count in PDE message
event queue.
RXMSGFC
Warning and alert threshold for percentage of message count being

flow controlled at the receiver side.
249

syscheck
System Resource Attribute
Description
SEGTBLFULL
Warning and alert threshold for percentage occupation of multisegment table entries. 100% indicates that the multi-packet messages
are naked or all the multi-packet segment table slots are currently
occupied.
The -timercontrol section allows you to adjust the sample number and sleep time.
Currently, only two tools use these parameters:
System Activity Reporter (SAR)
TDNSTAT utility
The value must be an integer greater than or equal to one.

For the -timercontrol section to work on all nodes, you must provide a modified optional
syscheckrc file on each node.
Creating a syscheckrc File

A custom (modified) syscheckrc file provides a permanent way to override the default
syscheckrc resource file settings. Teradata recommends that you use a naming convention for
resources, such as an uppercase name.
You can create an optional syscheckrc file whose values will override those in the default
syscheckrc file. The file must be placed in a specific location to be read by syscheck and
nodecheck. If a syscheckrc file exists at the specified location, it will be read automatically by
syscheck and nodecheck.
The default and optional syscheckrc files are read from the following locations:
On...
syscheckrc is stored in the...
Linux
/usr/pde/etc directory (default).

/pde directory (optional).
Windows
Program Files\Teradata\TDAT\LPDE\etc (default).

Program Files\Teradata\TDAT\tdConfig (optional).
To create an optional syscheckrc file:
250
Copy the default syscheckrc file to the appropriate optional location noted above. (You can
also use the -D option of nodecheck or syscheck and redirect the output to capture the
default settings.)
Use a text editor to modify your new file.
Utilities

syscheck
Custom syscheckrc File Example

The following is an example of a custom-modified syscheckrc file.
nodecheck -D
-nodeonly
AMPWT
BNSBLKQ
FREEMEM
FREESWAP
MSGEVCOUNT
RXMSGFC
SEGTBLFULL
WARN
WARN
WARN
WARN
WARN
WARN
WARN
-timercontrol
SARSAMPLE
SARSLEEP
TDNSTATSAMPLE
TDNSTATSLEEP
1
1
1
1
-3
300
-500
-1000
200
75
75
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
-0
600
-250
-500
400
100
100
You can also specify a customized resource configuration file for syscheck and nodecheck to
use by specifying the -r option with the configuration files path and filename when you start
syscheck or nodecheck. The values in this file will override the values in the default and
optional syscheckrc files. You should follow the same basic copy-and-edit steps to create this
file as noted above for creating an optional syscheckrc file.
Utilities
251

syscheck
252
Utilities
CHAPTER 28
Show Locks (showlocks)
The Show Locks utility, showlocks, provides information about Host Utility (HUT) locks
placed on databases and tables by the Archive/Recovery (ARC) utility during database
operations.
These locks might interfere with application processing and should be released after utility
processing is complete. Show Locks also displays information about locks placed during a
Teradata Database system failure.
Runs From

such as cnsterm
Host Utility Locks

You can release HUT locks either by submitting a separate RELEASE LOCK SQL command,
or by using the RELEASE LOCK option of the appropriate command. For example,
ARCHIVE, ROLLBACK, RESTORE, BUILD, and ROLLFORWARD.
HUT locks placed by the Archive/Recovery utility differ from locks placed by other operations
or transactions.
HUT locks have the following characteristics:
Utilities
Archive/Recovery locks are associated with the currently logged-on user who entered the
command, rather than with a batch job or transaction.
Only the AMPs that are participating in the Archive/Recovery operation are locked.
Archive/Recovery locks placed at one level of an object never conflict with a utility lock at
another level that was placed on the same object for the same user. The locking modes and
levels are applied as follows:
A Read lock is placed on an object being dumped.
Locks are placed at the cluster level during a CLUSTER dump.
253
Chapter 28: Show Locks (showlocks)

Interpreting the Show Locks Display
If a table being dumped is defined for an after-image permanent journal (and the
appropriate option was selected on the DUMP command), a group Read lock is placed
on the table rows.
A Write lock is placed on all tables involved in ROLLFORWARD and

ROLLBACKWARD recovery operations.
A Write lock is placed on a journal table that is being deleted.
A Write lock is placed on a permanent journal table that is being restored.
An Exclusive lock is placed on any object being restored that is not a journal table.
Archive/Recovery locks remain active until you release them.
Note: If Archive/Recovery locks are not specifically released, they are automatically reinstated
following a Teradata Database or client system restart.

The Show Locks utility display provides this information:
Summary of the showlocks function
Name of the databases and tables on which locks are placed
Username that placed each lock
Lock mode: read, write, exclusive, or access
Number of the AMPs on which the locked database or table resides
Show Locks reports All AMPs rather than individual AMP numbers when the locked database
or table resides on all AMPs. Information is provided for only the most restrictive lock a user
has placed on an object. An example of a complete Show Locks display is shown below.
_______
|
|
___
| /
| --| \___
__
|/
|
|
|
|
____
| ____ __|__ ____
\ ____| ____| ____|
|
____|
/
| /
| /
|
|
/
|
\____| \____| \____|
|__ \____|
Release 14.00.00.00 Version 14.00.00.00

Show Locks Utility (May 95)
This program queries all AMPs and reports all Host Utility locks.
which currently exist at both the data base level and the table level.
For each lock which is found, an entry will appear on your console
which includes the following information:
- Data Base Name
- Table Name (if applicable)
- User Name of user who placed lock
- Lock Mode
- AMP Number
accounting.invoice
USER ADMIN
MODE Read
AMP All AMPs
254
Utilities

parts
USER PETERS
MODE Read
AMP
personnel.employee
USER ACCMGR
MODE Excl
AMP
service
USER DBC
MODE Excel
AMP
--ShowLocks Processing Complete--
24
27
3
In the previous example, exclusive locks are placed on the employee table in the personnel
database and on the entire service database. One read lock is placed on the parts database, and
another read lock on the invoice table in the accounting database. Also, the following locks are
applied.
Username...
Placed the lock on the...
ADMIN
invoice table that resides on all AMPs.
PETERS
parts database which resides on AMP 24.
ACCMGR
portion of the employee table that resides on AMP 27.
DBC
portion of the service database that resides on AMP 3.
When no locks are found, Showlocks reports this message:

There are currently no host utility locks in the DBS.
Utilities
255

Conflicts
Conflicts
If a host utility lock that conflicts with Show Locks is in place when showlocks is executed, the
Teradata Database system displays this message:
Unable to proceed due to xxxx lock on yyyy
Syntax element...
Is...
xxxx
either a Write or Exclusive lock.
yyyy
DBC, DBC.TVM, or DBC.DBase.
After reporting a conflict, Show Locks terminates.
256
Utilities
CHAPTER 29
Table Rebuild (rebuild)
The Table Rebuild utility, rebuild, recovers data tables (primary, fallback, or both) on specified
AMPs.
Normally, Teradata Database utilizes fallback data, if available, to recover offline AMPs
automatically during startup. However, occasionally, primary or fallback data can be
corrupted by software errors or other abnormal conditions. Table Rebuild allows on-demand
recovery of data that is suspected of being corrupt.
Runs From
Table Rebulid runs from Database Window or comparable interface to the Teradata Database
console subsystem, such as cnsterm.
Rebuilding Tables
Table Rebuild can recover primary data, fallback data, or both primary and fallback data that
is stored on an AMP. A single table, all tables in a specified database, or all tables on the AMP
can be rebuilt. As an option, the rebuild process can be limited to only those tables that have
fallback protection.
The rebuild process uses fallback data to recover primary data, and primary data to recover
fallback data on a specified AMP. The current, presumably corrupted contents of the table
being rebuilt are deleted and replaced with the fallback or primary data, as appropriate. For
tables with no fallback protection, Table Rebuild restores an empty table that retains only the
table header information. Using the FALLBACK TABLES option ensures that only tables with
fallback protection are rebuilt. See REBUILD AMP FALLBACK TABLES on page 267.
Note: Tables that are marked down at the time they are rebuilt will remain down after the
rebuild. To clear the down status, use the ALTER TABLE ... RESET DOWN statement after the
table is rebuilt.
Global temporary tables, volatile tables, join indexes, and hash indexes cannot be rebuilt. For
indexes that may be corrupted, drop the index and recreate it as needed.
Certain non-fallback system tables, such as DBC.DataBaseSpace and DBC.Acctg, store
information that is unique to each AMP. These tables maintain information such as the
current database space utilization, CPU utilization, and I/O statistics for the AMP. Instead
Utilities
257
Chapter 29: Table Rebuild (rebuild)

Rebuilding Tables
these tables are updated by the system automatically after the rebuilt AMP is placed back on
line.
If a database restart interrupts an ALL TABLES rebuild process, it can be restarted again, and
will continue from where the rebuild process was interrupted. For more information, see
RESTART REBUILD on page 270.
Locking During Rebuilds

Table Rebuild can apply one of three types of read locks while it is rebuilding tables:
Database-level read locks are placed on the database on the AMP used as the source of data
for rebuilding the corrupted tables. This is the default type of lock that Table Rebuild
applies.
Table-level read locks are place on the individual tables that are the sources of data for
rebuilding the corrupted tables.
Rowrange-level read locks consist of selected groups of row-only locks. This type of lock
allows concurrent updates of the tables being used as the sources of data for rebuilding the
corrupted tables.
In the case of rebuilding primary data, these locks are placed on the AMPs containing the
corresponding fallback data. In the case of rebuilding fallback data, the locks are placed on the
AMPs containing the corresponding primary data.
Whether the database, table, or rowrange option is specified, Table Rebuild requests a read
lock on all online AMPs which belong to the same cluster for the database or table being
rebuilt. These AMPs contain the valid data that will be copied back to the AMPs being rebuilt.
Rowrange-level locks are applied locally to the AMP that is being rebuilt, so that the valid data
can be copied back to the rebuilt AMP.
For database and table rebuilds, processing begins after the lock is acquired. For rowrange
rebuilds, the table-level lock is changed to a rowrange lock before processing begins.
If an AMP is online while a database or table is being rebuilt, an exclusive lock is placed on the
database or table. If the AMP is offline, a read lock is used.
If all tables on an AMP are being rebuilt, Table Rebuild attempts to set database-level read
locks. If a database lock fails because of a conflict with another lock, that database is bypassed.
Table Rebuild attempts to rebuild the database again after all accessible databases and tables
are processed. Table Rebuild successively runs through the list of bypassed databases to
attempt to get a lock. If the bypass list contains a single database, or Table Rebuild has tried the
list of bypassed databases ten times, rebuild processing stops and waits until a lock can be
acquired.
If Table Rebuild is running in the background, a message is displayed on the system console
identifying the database and stating that the utility is waiting for a lock.
258
Utilities

Table Rebuild Utility Commands

Table Rebuild presents a command-line environment that allows the entry of the following
commands.
Command
Description
REBUILD AMP
Rebuilds all tables, a selected table, or all tables in a

selected database for a specified AMP.
REBUILD AMP FALLBACK TABLES
Rebuilds only tables with fallback protection.
RESTART REBUILD
Restarts an all-table rebuild operation (REBUILD

command with the ALL TABLES options specified).
The commands are discussed in detail in the sections that follow.
Usage Notes
Normally, Table Rebuild is run interactively, as a foreground process started from a Database
Window application window. Output from the program is directed to the window.
Optionally, Table Rebuild can be run as a background process. Output from the program is
logged to a special table, rather than being displayed on screen. All background rebuild
operations continue to run to completion, even after Table Rebuild is quit. For more
information, see the LOG INTO option described for REBUILD AMP on page 261 and
REBUILD AMP FALLBACK TABLES on page 267.
Several rebuild operations, both foreground and background rebuilds, can be run
simultaneously. Up to four interactive foreground sessions can utilize the four application
windows available in Database Window. Each session must rebuild tables on AMPs in
different clusters.
Any number of background process rebuilds can run simultaneously, and can be launched
from the same application window. Each rebuild process must rebuild tables on an AMP in
different clusters.
Error Handling
Table Rebuild issues messages interactively.
The following message might be returned by Table Rebuild after processing is complete:
Bad table header on AMP ccc-p for table tablename
This message can be caused by one of the following conditions:
Utilities
The table header does not exist. This might be because the table was dropped after Table
Rebuild was started.
A header was found, but the table was rebuilt unsuccessfully on the identified AMP.
259

To recover the table, restore it from the latest archive. If restoring from an archive is not an
option, contact the Teradata Support Center.
For more information on error messages involving AMP operations, see Messages.
Getting Help
To get help information about the Table Rebuild utility, press the F7 key while in the Database
Window application window. A set of second-level function keys will display as shown below:
Help
The Table Rebuild utility allows you to recover the data tables on a
specified AMPs disk(s) by copying the fallback copy maintained by the
other AMPs in the cluster. You may rebuild all or part of the tables on
an AMP via the options listed below.>
<F2>
<F3>
<F4>
<F5>
<F6>
<F7>
Rebuild
Rebuild
Rebuild
Rebuild
Rebuild
General
all tables on an AMP

all data tables in a database
a single table
fallback protected tables only
a previous rebuild after a system restart
syntax
For information on the subjects listed on the screen, press the corresponding function key. To
return to the next-higher menu level, press the F8 key. To exit the help system and return to
the Table Rebuild command prompt, press F8 from the top-level menu.
260
Utilities

REBUILD AMP
REBUILD AMP
Purpose
Rebuilds entire databases, all tables, stored procedures (fallback), UDMs, UDFs, entire tables
(primary and fallback), portions of tables (primary or fallback) in a selected database, an
entire table (primary and fallback) or a portion of a table (primary or fallback) for a specified
AMP.
Syntax
REBUILD AMP
nnnn
ALL TABLES
ALL DATA
dbase
ALL DATA
dbase.tbl
PRIMARY DATA
FALLBACK DATA
3
;
A
, LOG INTO logdbase.logtbl
, NO LOCK
ON NO FALLBACK TABLES
, WITH DATABASE LOCK

, WITH TABLE LOCK
, WITH ROWRANGE LOCK
,
IN PARALLEL
n TABLES
1102D135
Syntax element
Specifies
nnnn
the number of the AMP that is to be rebuilt.
ALL TABLES
that all table data stored on the AMP, whether primary or fallback data,
is to be rebuilt.
Tables with fallback protection are fully recovered. Tables without
fallback protection are left empty on the AMP. All the data in the
permanent journals will be recovered, except for journal rows for nonfallback tables without the dual journaling option.
The AMP to be rebuilt must be in the UTILITY vproc state and
running DBS partitions. All the other AMPs in the cluster must be online.
For more information, see Before Rebuilding All Tables on page 264.
Utilities
261

REBUILD AMP
Syntax element
Specifies
dbase
the name of a database. All tables (including stored procedures) in this

database will be rebuilt on the specified AMP. Tables with fallback
protection are fully recovered. Tables without fallback protection are
left empty on the AMP. If the database contains a permanent journal,
the journal is left unchanged.
If the DBC database is specified, the specified AMP must be off line.
For other databases, the AMP may be on line or off line during the
rebuild.
Note: Join indexes and hash indexes are skipped and not rebuilt. This is
true whether or not the join index has fallback.
dbase.tbl
the name of a table, stored procedure, UDF, or UDM that is to be

rebuilt. The AMP on which the table or stored procedure will be rebuilt
can be either online or offline.
If the specified table is fallback protected, the appropriate data is
recovered. If the table is not fallback protected, the table is left empty if
ALL or PRIMARY DATA rebuild was selected. You cannot rebuild
fallback data for a table that has no fallback protection.
ALL DATA
that both primary data and fallback data tables stored on the AMP
should be rebuilt. recommended, unless you are certain that only
primary or only fallback data on the AMP has been corrupted.
PRIMARY DATA
that only the primary data tables stored on the AMP should be rebuilt.
Use the ALL DATA option unless you are certain that only primary data
on the AMP has been corrupted.
FALLBACK DATA
that only the fallback data tables stored on the AMP should be rebuilt.
Use the ALL DATA option unless you are certain that only fallback data
on the AMP has been corrupted.
LOG INTO logdbase.logtbl
262
that Table Rebuild is to run in the quiet mode or background mode. All
messages will be written to the system console and to a user-defined
table. The table is specified by database name and table name. For more
information, see Running Table Rebuild in the Background on
page 265.
Utilities

REBUILD AMP
Syntax element
Specifies
NO LOCK [ON NO
FALLBACK TABLES]
that no lock should be applied to any non-fallback tables being rebuilt.

(non-fallback tables are tables that were created without fallback
protection.)
By default, tables that do not have fallback protection are flagged in
their table headers as being in the process of being rebuilt. (Field 4 of
the table header row contains rebuild in progress.) This causes locks to
be applied which limit the operations that are allowed on these tables.
As long as these tables are flagged, they cannot be dropped or restored,
and the rebuild cannot be rerun on them.
The only ways to remove the flag is by one of the following:
rebuild the table with the NO LOCK option
drop the table
restore the table
The NO LOCK option prevents the flagging and locking of these
tables,. It should be used when access to the tables is no longer
important. Rebuilding non-fallback tables causes their contents to be
deleted.
Note: ON NO FALLBACK TABLES has no effect on this option, but
optionally may be entered for additional console clarity.
WITH DATABASE LOCK
that a database-level read lock will be placed on the source AMP

database data used to rebuild each corrupted table. This is the default
lock setting.
Note: This option is valid only with the ALL TABLES option.
WITH TABLE LOCK
that a table-level read lock will be placed on the source AMP table to be
used to rebuild the corrupted table.
WITH ROWRANGE
LOCK
that a rolling-read lock (selected groups of row-only locks) will be

placed on the source AMP table used to rebuild the corrupted table.
This lock allows concurrent updates of the tables being used on the
source AMP for the rebuild.
For a partitioned table, a rowrange lock is not used. A table-level lock is
used instead.
Utilities
263

REBUILD AMP
Syntax element
Specifies
[n TABLES]
IN PARALLEL
that during all-table rebuilds (rebuilds using ALL TABLES), or during

fallback table rebuilds (using FALLBACK TABLES), or during database
rebuilds (using the dbase options described above) multiple tables per
database should be rebuilt in parallel. This can make the rebuild
operations complete more quickly. From two to six tables can be rebuilt
simultaneously.
n is an integer from 2 to 6 that specifies how many tables will be rebuilt
in parallel. If n TABLES is not specified, the default number of tables
that will be rebuilt in parallel is six.
If Teradata Database is reset during an ALL TABLES ALL DATA
rebuild, when the rebuild process is restarted (see RESTART
REBUILD on page 270), the rebuild preserves the IN PARALLEL
setting, and continues rebuilding tables in parallel.
Note: If the IN PARALLEL option is used together with the ALL
TABLES, FALLBACK TABLES, or dbase options, the database will be
locked during the entire duration of the parallel rebuild.
Usage Notes
Regardless of whether the AMP to be rebuilt is offline or online during Table Rebuild, all other
AMPs in the same cluster must be online. AMPs in other clusters may be offline.
In addition to text, hex format values are accepted for the dbase and dbase.tbl variables. Use
the following format:
'HHHH...HH'xn
Where the HH is the hexadecimal representation of a character byte whose ASCII value is
known to the database software. For example: DBC.TVMID could be input as
'444243'xn.'54564D4944'xn.
Teradata Database can isolate some file system errors to a specific data or index subtable, or to
a contiguous range of rows (region) in a data or index subtable. In these cases, Teradata
Database marks only the affected subtable or region down. This improves system performance
and availability by allowing transactions that do not require access to the down subtable or
rows to proceed, without causing a database crash that would require a system restart.
The normal rebuild process removes down-region information from the table header. For
more information on down regions, see the CheckTable and DBS Control chapters in Volume
One of Utilities.
Before Rebuilding All Tables
Before rebuilding all tables, do the following:
1
Use the Vproc Manager utility to set the VprocState of the AMP that will be rebuilt to
FATAL.
Restart the Teradata Database.

Note: This step is not necessary if the rebuilding AMP state was FATAL before the last
Teradata Database restart.
264
Utilities

REBUILD AMP
3
Use the Vproc Manager utility to boot the AMP that will be rebuilt.
Messages will be displayed on the system console to indicate the status of the boot. If the
boot is successful, this AMP is ready for an ALL TABLES rebuild.
Note: The BOOT command will re-initialize the disk of the AMP in anticipation of alltables table rebuild and start the DBS partitions on the specified AMP. This applies only to
vprocs with a VprocState of FATAL and a ConfigStatus of Down. A confirmation input is
necessary to process the initialization.
Valid VprocIds are decimal numbers in the range of 0 through either 30719 or 16383,
depending on the system.
Note: Hex numbers can also be specified by appending a trailing x (for example, 0x,
3FFx).
Start Table Rebuild and run an ALL TABLES rebuild on this AMP.
When the rebuild is done, use the Vproc Manager utility to set the VprocState of this AMP
to ONLINE.
Note: Table Rebuild automatically sets the VprocState of this AMP from UTILITY to
OFFLINE when complete.
Restart the Teradata Database.
Rebuilding One or All Tables

When all data on an AMP has been lost and needs to be rebuilt or the database DBC on that
AMP needs to be rebuilt, Table Rebuild can recover this information. While database DBC is
being rebuilt, the AMP whose data needs to be rebuilt must be offline. By contrast, when any
other database on the AMP or a single table is being rebuilt, the AMP can be either online or
offline.
After all databases are rebuilt, Teradata Database must be restarted to update the rebuilt tables
and to return the AMP whose data has been rebuilt to online operation.
Running Table Rebuild in the Background
When you specify the LOG INTO logdbase.logtbl option, Table Rebuild runs as a background
task. You can run multiple Table Rebuild operations both in the background and foreground
(interactive mode) at the same time. Completion messages for background rebuilds are sent to
the system console and to the user-defined table specified in the LOG INTO option.
The table specified in the LOG INTO option must have been created previously as follows:
CREATE TABLE LogDB.LogTable, FALLBACK
( MsgDate (CHAR (8)),
/* format = yy/mm/dd */
MsgTime (CHAR (8)),
/* format = hh/mm/ss */
MsgAMP
(CHAR (6)),
/* format = nnnn */
MsgCode (CHAR (1)),
/* see below */
MsgText (VARCHAR (80)), /* message text */
PRIMARY INDEX (MsgDate, MsgTime) ;
The table must have been defined previously as shown above, with the table characteristics
matching the example. The names of the database, table, and columns are customizable.
The MsgAMP (third column) contains a four-digit AMP number.
Utilities
265

REBUILD AMP
The MsgCode (fourth column) has one of the following values:

Value
Meaning
A normal message
Rebuilding database message
Error message
Rebuilding table message for a journal
Rebuilding table message for a no-fallback table
Rebuilding table message for tables used by recovery
Start/Restart rebuild operation
Then you can use the log table to create reports.

Note: The table-level messages do not include the database names. The reports should include
all the D class messages and be ordered by date and time for proper identification.
266
Utilities

Purpose
Rebuilds only tables with fallback protection, including stored procedure tables. Because Table
Rebuild deletes all tables selected for rebuild before the start of the rebuild process, this
command prevents tables without fallback protection from being deleted.
This command performs most of the work which is done by normal down AMP recovery,
making the actual restart to bring a down AMP back on line as fast as possible, while
guaranteeing data integrity. The AMP to be rebuilt must be off line and all of the other AMPs
in the cluster must be on line.
Syntax
nnnn
REBUILD AMP
FALLBACK TABLES
A
3
;
A
, LOG INTO logdbase.logtbl
, WITH DATABASE LOCK

, WITH TABLE LOCK
, WITH ROWRANGE LOCK
,
IN PARALLEL
n TABLES
Utilities
1102B221
Syntax element
Specifies
nnnn
the number of the AMP vproc to be rebuilt.
FALLBACK TABLES
that only tables with fallback protection will be rebuilt. This prevents
tables without fallback protection from being deleted. The first step
that Table Rebuild usually performs is to delete the contents of the table
that Table Rebuild is rebuilding.
LOG INTO logdbase.logtbl
that Table Rebuild is to run in the quiet mode or background mode. All
messages will be written to the system console and to a user-defined
table. The table is specified by database name and table name. For more
information, see Running Table Rebuild in the Background on
page 268.
267

Syntax element
Specifies
WITH DATABASE LOCK
that a database-level read lock will be placed on the source AMP

database data used to rebuild the corrupted table. This is the default
lock setting.
WITH TABLE LOCK
that a table-level read lock will be placed on the source AMP table to be
used to rebuild the corrupted table.
WITH ROWRANGE
LOCK
that a rolling-read lock (selected groups of row-only locks) will be

placed on the source AMP table used to rebuild the corrupted table.
This lock allows concurrent updates of the tables being used on the
source AMP for the rebuild.
Note: For a partitioned primary index (PPI) table, a rowrange lock is
not used. A table-level lock is used instead.
[n TABLES]
IN PARALLEL
that multiple tables per database should be rebuilt in parallel. This can
make the rebuild operations complete more quickly. From two to six
tables can be rebuilt simultaneously.
n is an integer from 2 to 6 that specifies how many tables will be rebuilt
in parallel. If n TABLES is not specified, the default number of tables
that will be rebuilt in parallel is six.
Usage Notes
Regardless of whether the AMP to be rebuilt is offline or online during Table Rebuild, all other
AMPs in the same cluster must be online. AMPs in other clusters may be offline.
Teradata Database can isolate some file system errors to a specific data or index subtable, or to
a contiguous range of rows (region) in a data or index subtable. In these cases, Teradata
Database marks only the affected subtable or region down. This improves system performance
and availability by allowing transactions that do not require access to the down subtable or
rows to proceed, without causing a database crash that would require a system restart.
The normal rebuild process removes down-region information from the table header. For
more information on down regions, see the CheckTable and DBS Control chapters in Volume
One of Utilities.
Running Table Rebuild in the Background
When you specify the LOG INTO logdbase.logtbl option, Table Rebuild runs as a background
task. You can run multiple Table Rebuild operations both in the background and foreground
(interactive mode) at the same time. Completion messages for background rebuilds are sent to
the system console and to the user-defined table specified in the LOG INTO option.
The table specified in the LOG INTO option must have been created previously as follows:
CREATE SET TABLE LogDB.LogTable ,FALLBACK ,NO BEFORE JOURNAL,
NO AFTER JOURNAL,CHECKSUM = DEFAULT
( MsgDate CHAR(8) CHARACTER SET LATIN NOT CASESPECIFIC,
MsgTime CHAR(8) CHARACTER SET LATIN NOT CASESPECIFIC,
MsgAMP CHAR(6) CHARACTER SET LATIN NOT CASESPECIFIC,
MsgCode CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC,
268
Utilities

MsgText VARCHAR(80) CHARACTER SET LATIN NOT CASESPECIFIC )
PRIMARY INDEX ( msgdate ,msgtime );
The table must have been defined previously as shown above, with the table characteristics
matching the example. The names of the database, table, and columns are customizable.
The MsgAMP (third column) contains a four-digit AMP number.
The MsgCode (fourth column) has one of the following values:
Value
Meaning
A normal message
Rebuilding database message
Error message
Rebuilding table message for a journal
Rebuilding table message for a no-fallback table
Rebuilding table message for tables used by recovery
Start/Restart rebuild operation
You can use the log table to create reports.

Note: The table-level messages do not include the database names. The reports should include
all the D class messages and be ordered by date and time for proper identification.
Utilities
269

RESTART REBUILD
RESTART REBUILD
Purpose
Restarts an all-table rebuild operation (REBUILD command with the ALL TABLES options
specified).
If a Teradata Database failure occurs while a Table Rebuild is running for all tables, this
command restarts the rebuild process, bypassing databases and tables already rebuilt, and
continuing from the table that was being rebuilt when the system failed.
Syntax
RESTART REBUILD ON AMP
nnnn
GS06A011
Syntax element
Specifies
nnnn
the vproc number of the AMP which was previously running the ALL
TABLES rebuild.
Usage Notes
The RESTART REBUILD command restarts an all-table rebuild that was terminated by a
system restart or failure. After RESTART REBUILD is executed, no intervention is required.
Table Rebuild automatically determines where the rebuild terminated and restarts at the
appropriate place. Table Rebuild determines where to restart by using the spool files that
contain the database names and table names to be rebuilt (in order by database ID and by
table ID within the database). Before each subtable (primary or fallback) is rebuilt, Table
Rebuild writes a restart record to the current DBC table SysRcvStatJournal.
When you start a RESTART REBUILD, the program reads the restart record and positions
itself in the spool file accordingly. After completion of the Table Rebuild, the restart row is
deleted from the journal table.
270
Utilities
CHAPTER 30
Task List (tsklist)
Task List utility, tsklist, displays information about PDE processes and their tasks. This is
useful for identifying which programs and tasks are running.
Runs From
Task List runs from the Linux command line.
Syntax
tsklist
-a
-b
-i
-l
- p partition
- r relvpr
-s
-S
- v vprid
prgname
1102A166
Syntax element
Description
-a
Includes all programs, including PDE system programs, which are those in the
node vproc and in partition 0.
By default, only TPA programs are shown.
Utilities
271
Chapter 30: Task List (tsklist)

Syntax
Syntax element
Description
-b
Shows only busy tasks.

As a diagnostic aid, the database identifies tasks that are doing work with a flag
indicating that they are busy. Usually only busy tasks are of interest when
debugging database tasks. Generally, idle tasks are waiting to receive a message
giving them work to do.
By default, all selected programs and tasks are listed, whether or not they are busy.
-i
Disables the resolving of task addresses to their corresponding function names.

By default, tsklist resolves tasks addresses.
-l
Shows traces in long form, with nearly all available fields for each program and
task being displayed on multiple lines.
The default is to show a one-line display of the most important fields.
-p partition
Shows only programs in the specified partition number.

The default is to show programs in all partitions.
-r relvpr
Shows only programs in the specified node-relative vproc number.

The node vproc is always relvpr 0; other vprocs running on the node have
ascending numbers in the order in which they were started.
Although -r and -v are not mutually exclusive in a strict sense, only programs that
match all criteria specified are selected. So if -r and -v specify different vprocs, no
programs will be selected.
-s
Shows only a summary of the programs that are running, without any details on
the tasks they contain.
The default is to show all tasks in the programs selected in addition to the
program-level information.
-S
Shows Priority Scheduler information for each task.
-v vprid
Shows only programs in the specified vproc.

Although -r and -v are not mutually exclusive in a strict sense, only programs that
match all criteria specified are selected. So if -r and -v specify different vprocs, no
programs will be selected.
prgname
Shows only program(s) where the program name starts with the provided
characters.
For example, if prgname is pde, then pdemain and pdevproc information would
display.
The comparison is case insensitive. The -a option is implied.
272
Utilities

Examples
Examples
The following examples are from a test system with two AMPS and one PE.
Example 1
Task List running in summary mode to show only non-PDE process information.
> tsklist -s
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
7
8
9
11
15
17
7
8
9
11
7
8
12
13
10
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
3edd
3edf
3ecf
3ed7
3ec4
3ecb
3ede
3ee0
3ed5
3ed8
3ee1
3ee4
3ee3
3ee2
3ebf
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
0(1)
0(1)
0(1)
0(1)
0(1)
0(1)
1(2)
1(2)
1(2)
1(2)
16383(3)
16383(3)
16383(3)
16383(3)
8192(4)
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
4100
scpstart
utadvtsk
fsustart
actmain
sssmain
sssrss
scpstart
utadvtsk
fsustart
actmain
scpstart
rtsmain
sestsk
disstart
gtwgateway
880
4184
4184
4184
4104
4104
4104
4104
4104
4104
4100
4100
4000
4100
4100
4100
4100
4100
4100
4000
4100
4100
4100
4100
pdemain
segmain
cfgmain
dmp
dbgsrvr
csp
udfsrvtsk
udfsrvtsk
udfsrvtsk
udfsrvtsk
cnscim
cspslave
pdevproc
scpstart
utadvtsk
fsustart
actmain
sssmain
sssrss
pdevproc
scpstart
utadvtsk
fsustart
actmain
Example 2
Task List running in summary mode to show all processes.
> tsklist -as
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Part:
Utilities
0
0
0
0
0
0
0
0
0
0
2
7
0
7
8
9
11
15
17
0
7
8
9
11
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
3e85
3eb5
3eb6
3ec1
3ec0
3ec2
3ed9
3eda
3edb
3edc
3ebd
3ec3
3ebb
3edd
3edf
3ecf
3ed7
3ec4
3ecb
3ebc
3ede
3ee0
3ed5
3ed8
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
16384(0)
0(1)
0(1)
0(1)
0(1)
0(1)
0(1)
0(1)
1(2)
1(2)
1(2)
1(2)
1(2)
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
273

Examples
Part: 7
Part: 8
Part: 12
Part: 13
Part: 10
ProcessID:
ProcessID:
ProcessID:
ProcessID:
ProcessID:
3ee1
3ee4
3ee3
3ee2
3ebf
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
VprocID(RelVpr):
16383(3)
16383(3)
16383(3)
16383(3)
8192(4)
Flags:
Flags:
Flags:
Flags:
Flags:
4100
4100
4100
4100
4100
scpstart
rtsmain
sestsk
disstart
gtwgateway
Example 3
Task List running to show task information on programs running in partition 15.
> tsklist -p 15
Part:
Pid:
Pid:
Pid:
15 ProcessID: 3ec4 VprocID(RelVpr): 0(1) Flags: 4100 sssmain

01000490 TaskID: 0001 Flags: 1000 main is paused
01000610 TaskID: 0002 Flags: 0
(admin) is in adminwait
01007210 TaskID: 0006 Flags: 0
sssacctg is in msgwait
Example 4
Task List running to show task information on programs running in partition 15 in long
format.
> tsklist -l -p 15
Part: 15 ProcessID: 3ec4 VprocID(RelVpr): 0(1) Flags: 4100 sssmain
KPart: e0000001173c8bc0 Seq: 0 Tasks: 3
Admin: KTCB: e000000114a67600 ReqKTCB: e000000114a66058 Args:
Pid: 01000490 TaskID: 0001 Flags: 1000 main is paused
KTCB: e000000114a67398 Handle: 0000000000007d98 Dbg: 0 Prio: 0
WakeReason: 0 WakeCode: 10193 WorkType: 254 WorkEst: 0
FSG: nios=0 preios=0 logios=2 nsegs=0
SEG: nsegs=2
Pid: 01000610 TaskID: 0002 Flags: 0 (admin) is in adminwait
KTCB: e000000114a67600 Handle: 0000000000007da6 Dbg: 0 Prio: 0
SEG: nsegs=0
Pid: 01007210 TaskID: 0006 Flags: 0 sssacctg is in msgwait
KTCB: e0000001162a5920 Handle: 0000000000007f26 Dbg: 0 Prio: 0
SEG: nsegs=0
Example 5
Task List running in summary mode to show only programs, the names of which start with
pde. This shows that a case-insensitive comparison is performed.
> tsklist -s pDe
Part:
Part:
Part:
0
0
0
ProcessID: 3e85
ProcessID: 3ebb
ProcessID: 3ebc
VprocID(RelVpr): 16384(0)
Flags: 880
Flags: 4000
Flags: 4000
pdemain
pdevproc
pdevproc
Example 6
Task List running to show only pdemain task information.
> tsklist pdemain
Part:
274
ProcessID: 3e85
Flags: 880
pdemain
Utilities

Examples
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
00000190
00000310
00000610
00001210
00001390
00001810
00003790
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
0001
0002
0006
0007
0008
000b
0010
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
Flags:
0
0
0
0
0
0
0
main is busy running

logd is busy in syscall
tparesetd is busy in tdnio
msgkevd_start is busy in msgevd
msgkmsg_main is busy in msgwait
trad_mainloop is busy in traread
rssd is busy in syswait
Example 7
Task List running to show only pdemain task information.
The -i option is used here to disable the resolving of task addresses to their corresponding
names.
tsklist -i pdemain
Part:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
0 ProcessID: 3e85 VprocID(RelVpr): 16384(0) Flags: 880 pdemain

00000190 TaskID: 0001 Flags: 0 main is busy running
00000310 TaskID: 0002 Flags: 0 0x40000000000a0fa0 is busy in syscall
00000610 TaskID: 0006 Flags: 0 0x400000000004e750 is busy in tdnio
00001210 TaskID: 0007 Flags: 0 0xc000000000e154d0 is busy in msgevd
00001390 TaskID: 0008 Flags: 0 0x400000000009b3f0 is busy in msgwait
00001810 TaskID: 000b Flags: 0 0x400000000002f260 is busy in traread
00003790 TaskID: 0010 Flags: 0 0x400000000007e000 is busy in syswait
Example 8
Example 8 shows tsklist running to show Priority Scheduler task information on an SLES 10
system.
Note: The output is truncated.
tsklist -S
Part: 7
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Part: 8
Pid:
Pid:
Part: 9
Pid:
Pid:
Pid:
msgwait
Pid:
monyield
Pid:
Pid:
monyield
Pid:
Part: 11
Pid:
Pid:
Utilities
ProcessID: 0f04
01004ae4 TaskID:
01004b94 TaskID:
01004c44 TaskID:
01004cf4 TaskID:
01004da4 TaskID:
01004e54 TaskID:
ProcessID: 0c7c
01004f04 TaskID:
01004fb4 TaskID:
ProcessID: 0da8
01000624 TaskID:
010006d4 TaskID:
01000784 TaskID:
VprocID(RelVpr):
0878 PG: 40 AG:
0d08 PG: 0 AG:
0ee8 PG: 40 AG:
0ee0 PG: 40 AG:
0ed8 PG: 40 AG:
0ed0 PG: 40 AG:
VprocID(RelVpr):
0944 PG: 40 AG:
0ec0 PG: 0 AG:
VprocID(RelVpr):
0db4 PG: 40 AG:
0e58 PG: 0 AG:
0e44 PG: 40 AG:
0(1)
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
0(1)
200 Pri:
1 Pri:
0(1)
200 Pri:
1 Pri:
200 Pri:
200
1
200
200
200
200
Flags: 4100 scpstart

13 main is in msgwait
14 (admin) is in adminwait
13 tblserve is in msgwait
13 scpread is in msgwait
13 scpwrite is in msgwait
13 scprun is in msgwait
Flags: 4100 utadvtsk
13 main is in msgwait
Flags: 4100 fsustart
13 main is sleeping
13 fsubackgrndmainentry is in
01000834
TaskID: 0e3c
PG: 40
AG: 200
Pri: 13
fsubackgrndmainentry is in
010008e4
01000994
TaskID: 0e34
TaskID: 0e2c
PG: 40
PG: 40
AG: 200
AG: 200
Pri: 13
Pri: 13
fsudefrag is in msgwait
fsubackgrndmainentry is in
01000a44 TaskID:
ProcessID: 0e04
01000af4 TaskID:
01000ba4 TaskID:
0630 PG: 40 AG: 200 Pri:

VprocID(RelVpr):
0(1)
0e08 PG: 40 AG: 200 Pri:
0d64 PG: 0 AG:
1 Pri:
13 fsuminicylpack is in msgwait
Flags: 4100 actmain
13 main is sleeping
275

Examples
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
Pid:
...
276
01000c54
01000d04
01000db4
01000e64
01000f14
01000fc4
01001074
01001124
010011d4
01001284
01001334
010013e4
01001494
01001544
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
TaskID:
0b34
08ac
0c70
0874
0824
0f1c
0cac
0dbc
0db0
0dac
0da4
0d9c
08f4
0c4c
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
PG:
40
40
40
40
40
40
40
40
40
40
40
40
40
40
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
AG:
200
200
200
200
200
200
200
200
200
200
200
200
200
200
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
Pri:
13
13
13
13
13
13
13
13
13
13
13
13
13
13
udfmanage is in msgwait
awtmain is in msgwait
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
awtmain is idle
Utilities
CHAPTER 31
Teradata Locale Definition Utility

(tdlocaledef)
The Teradata Locale Definition utility, tdlocaledef, is a command-line utility that allows you to
define or change how Teradata Database formats numeric, date, time, and currency output.
Tdlocaledef converts a specification for data formatting (SDF) text file into a Teradata
Database globally distributed object (GDO), an internal binary format file that stores
configuration information. The GDO is made available simultaneously to all nodes of an MPP
system. The utility can also convert the text file to a local, non-distributed, binary file, that can
be converted back to text in order to ensure the formatting syntax is valid.
Note: Format changes take effect only after Teradata Database is restarted, and do not affect
columns that were created prior to the restart.
Runs From
Tdlocaledef runs from the Linux command line.
Syntax
tdlocaledef
-input filename
-output
filename
new
Gt15b004
tdlocaledef
-reverse
current
filename
-source filename
1102A145
Utilities
277
Chapter 31: Teradata Locale Definition Utility (tdlocaledef)

Syntax
Syntax element ...
Is ...
-input filename
Specifies the text file containing the SDF settings.

If filename does not include the full path to the SDF file, tdlocaledef assumes
the named file is in the current directory.
If the -input option is not specified, tdlocaledef looks for a tdlocaledef.txt SDF
file located in
/etc/opt/teradata/tdconfig.
By default there is no tdlocaledef.txt file in those locations. Teradata provides a
sample file in
/usr/tdbms/etc.
Teradata recommends that you never modify the sample tdlocaledef.txt file
directly, but instead copy the file to another location and make changes to the
copy.
For more information on customizing Teradata Database output formatting
settings, see SDF File on page 279.
-output filename
-output new
Specifies what happens to the compiled, binary version of the SDF formatting
settings that is produced by tdlocaledef.
filename specifies that the compiled settings be stored only in a local file.
This file is suitable for use with the -reverse option to verify that the syntax
used in the SDF text file is correct. If no path is specified, the binary file is
placed in the current directory.
new specifies that the settings become effective at the next Teradata
Database restart. The settings are compiled into a GDO, and used by all
nodes of the system. A copy of the SDF text file is stored on every node in /
etc/opt/teradata/tdconfig.
If the -output option is not specified, tdlocaledef creates a local binary file
named tdlocaledef.loc in
/etc/opt/teradata/tdconfig.
-reverse current
-reverse filename
Specifies that the compiled output format settings currently in effect or stored
in a local binary file be written to a text file suitable for viewing and editing.
This option is primarily used for creating an editable text file of the current
output formatting settings that can be used to customize or change the output
formatting that Teradata Database uses for dates, times, numbers, and
currency.
-reverse can also be used to verify correct syntax in an edited SDF text file.
current specifies that the output formatting settings currently in effect be
written to a text file.
filename specifies that the SDF settings in a local compiled binary file be
converted to a text file. Use this option to ensure that a previously compiled
SDF text file uses proper syntax. If the original text file does not match the
file produced using the -reverse filename option, there is a syntax error in
the original SDF file.
-source filename
278
Specifies the SDF text file tdlocaledef should create based on the specified reverse options. If -source is not specified, tdlocaledef creates an SDF
file named tdlocaledef.txt in the current directory.
Utilities

SDF File
SDF File
The SDF file is a text file that defines how Teradata Database formats numeric, date, time, and
currency output. The formatting strings it contains are used in conjunction with special
formatting characters used in SQL FORMAT output phrases.
Teradata Database includes a default SDF file that contains a viewable and editable text version
of the default output formatting settings. The default SDF file is located in /usr/tdbms/etc.
The SDF file controls how the following kinds of information are formatted in the output of
Teradata Database.
Day names
Month names
AM and PM names
Numeric and currency separators
Numeric and currency digit grouping rules
Currency symbols
Default display formats for data types
The SDF file also controls the default display formats for the following data types:
BYTEINT
SMALLINT
BIGINT
INTEGER
NUMERIC (includes DECIMAL)
REAL (includes DOUBLE PRECISION and FLOAT)
DATE
TIME and TIME WITH TIME ZONE
TIMESTAMP and TIMESTAMP WITH TIME ZONE
NUMBER
Note: You cannot use the SDF file to control output formatting for the INTERVAL data type.
The formatting characters permitted in the format strings of the SDF file are the same
formatting characters permitted in an SQL FORMAT for the data types listed above. You can
override the default display format for a data type in the SDF file by using the FORMAT
output phrase in a CREATE TABLE, ALTER TABLE, or SELECT statement.
For example, you can set the value of the currency string in the SDF file to the currency
symbol native to your locale. To include that currency symbol when you display numeric
monetary information in an SQL SELECT statement, use the L formatting character in the
FORMAT output phrase. For more information on display formats and SQL output format
phrases, see SQL Data Types and Literals.
Utilities
279

SDF File
Additionally, the SDF file can be used to specify a time zone string, which allows Teradata
Database to automatically adjust the system time for locales that use Daylight Savings Time.
SDF Elements
The following table describes the SDF elements. All elements must be specified once in the
SDF file. Keywords are case insensitive, but the data strings are case sensitive, unless stated
otherwise. The SDF format strings consist of printable characters from 7-bit ASCII, unless an
element is restricted further by the type of data. For out-of-range characters, use the \u
Unicode hex notation. The SDF can contain single-line comments that start with //.
Syntax element ...
Description
short_day_name is one of seven abbreviated names
for the days of the week in the native language.
;
ShortDays
"short_day_name"
These names can vary in length. You must have

seven.
Gt15b007
Example:
ShortDays
{"Sun";"Mon";"Tue";"Wed";"Thu";
"Fri";"Sat"}
long_day_name is one of seven full names for the

days of the week in the native language.
;
LongDays
"long_day_name"
The order of the names must match the order of the

names of the ShortDays. These names can vary in
length. You must have seven.
Gt15b008
Example:
LongDays {"Sunday";"Monday";"Tuesday";
"Wednesday";"Thursday";"Friday";
"Saturday"}
;
ShortMonths
"short_month_name"
Gt15b009
short_month_name is one of 12 abbreviated names

for the months of the year in the native language.
These names can vary in length.You must have 12.
Example:
ShortMonths {"Jan";"Feb";"Mar";"Apr";
"May";"Jun";"Jul";"Aug";"Sep";"Oct";"N
ov";
"Dec"}
280
Utilities

SDF File
Syntax element ...
Description
long_month_name is one of 12 full names for the
months of the year in the native language.
;
LongMonths
"long_month_name"
}
Gt15b010
The order of the names must match the order of the

names of the ShortMonths. These names can vary in
length. You must have 12.
Example:
LongMonths
{"January";"February";"March";
"April";"May";"June";"July";"August";
"September";"October";"November";
"December"}
AMPM
"am_name"
"pm_name"
}
Gt15b011
am_name is the abbreviated name for AM (ante

meridiem), and pm_name is the abbreviated name
for PM (post meridiem) in the native language.
These names can vary in length. You must have
both.
Example:
AMPM {"AM";"PM"}
RadixSeparator
"radix_separator_character"
}
Gt15b012
radix_separator_character is a character that

separates the integer and fractional part of nonmonetary strings. Separators cannot contain the
following:
plus sign (+)
minus sign (-)
digits (0 through 9)
E
e
V
v
The radix_separator_character must be different
than the group_separator_character. However, the
radix_separator_character can be the same as the
currency_radix_separator_character.
Example:
RadixSeparator {"."}
Utilities
281

SDF File
Syntax element ...

GroupSeparator
Description
{
"group_separator_character"
}
Gt15b013
group_separator_character is a character that

separates groups of digits in the integer part of nonmonetary strings.
Separators cannot contain the following:
plus sign (+)
minus sign (-)
digits (0 through 9)
E
e
The group_separator_character can be the same as
the currency_group_separator_character.
Example:
GroupSeparator {","}
282
Utilities

SDF File
Syntax element ...

GroupingRule
Description
{
"grouping_rule_number"
}
Gt15b014
grouping_rule_number is a group of numbers that

defines the size of each group of digits in nonmonetary strings.
The size of each group can vary. Each number
specifies how many digits are in each group with the
initial integer defining the size of the group
immediately preceding the radix separator, and the
following integers defining groups preceding that.
If the last integer is -1, no further groupin gshall
be performed.
If the last integer is not -1, the size of the
previous group (if any) shall be repeatedly used
for the remainder of the digits.
Examples:
GroupingRule {"3"}
For GroupingRule {3}, the numeric value
123456789.00 is formatted as 123,456,789.00.
GroupingRule {"3,2,-1"}
For GroupingRule {3,2,-1}, the numeric value
123456789.00 is formatted as 1234,56,789.00.
Currency
"currency_symbol"
}
Gt15b015
currency_symbol is string representing the local

currency.
Currencies cannot contain the following:
plus sign (+)
minus sign (-)
digits
CurrencyRadixSeparator
CurrencyGroupSeparator
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
Currency {"$"}
Utilities
283

SDF File
Syntax element ...

ISOCurrency
Description
{
"iso_currency_abbrev"
}
Gt15b016
iso_currency_abbrev is a string representing the local

currency as an uppercase three-character code from
ISO 4217.
You are responsible for verifying that the string is
specified in ISO 4217.
plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
ISOCurrency {"USD"}
CurrencyName
"currency_name"
}
Gt15b017
currency_name is a string representing the local

currency as a completely spelled out currency name.
plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
CurrencyName {"US Dollars"}
284
Utilities

SDF File
Syntax element ...

Description
{
"currency_radix_separator_character"
}
Gt15b018
currency_radix_separator_character is a character
that separates the integer and fractional part of
monetary strings.
plus sign (+)
minus sign (-)
digits
E
e
V
v
The currency_radix_separator_character must be
different that the
currency_group_separator_character.
Example:
CurrencyRadixSeparator {"."}
"currency_group_separator_character"
}
Gt15b019
currency_group_separator_character is a character
that separates groups of digits in the integer part of
monetary strings.
plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
Example:
CurrencyGroupSeparator {","}
CurrencyGroupingRule
"currency_grouping_rule_number"
}
Gt15b020
currency_grouping_rule_number is a string of
comma-separated numbers defining the size of each
group of digits in monetary strings.
The size of each group can vary. Each number
specifies how many digits are in each group with the
initial integer defining the size of the group
immediately preceding the radix separator, and the
following integers defining groups preceding that.
Example:
CurrencyGroupingRule {"3"}
Utilities
285

SDF File
Syntax element ...

DualCurrency
Description
{
"dual_currency_symbol"
dual_currency_symbol is a string representing the

dual currency.
}
Gt15b021

plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
DualCurrency {"$"}
DualISOCurrency
"dual_iso_currency_abbrev"
}
Gt15b022
dual_iso_currency_abbrev is a string representing the

dual currency as a three-character code from ISO
4217.
You are responsible for verifying that the string is
specified in ISO 4217.
plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
DualISOCurrency {"USD"}
286
Utilities

SDF File
Syntax element ...
Description
DualCurrencyName
"dual_currency_name"
}
Gt15b023
dual_currency_name is a string representing the dual

currency as a completely spelled out currency name.
plus sign (+)
minus sign (-)
digits
E (by itself)
e (by itself)
percent sign (%)
comma (,)
dot (.)
slash (/)
colon (:)
Example:
DualCurrencyName {"US Dollars"}
BYTEINT
"byteint_default_format"
byteint_default_format is a string representing the

default format applied to BYTEINT data types.
}
Gt15b024
Example:
BYTEINT {"-(3)9"}
INTEGER
"integer_default_format"
integer_default_format is a string representing the

default format applied to INTEGER data types.
Example:
Gt15b026
INTEGER {"-(10)9"}
SMALLINT
"small_integer_default_format"
}
Gt15b025
small_integer_default_format is a string representing

the default format applied to SMALLINT data types.
Example:
SMALLINT {"-(5)9"}
BIGINT
"big_integer_default_format"
}
1102A144
big_integer_default_format is a string representing

the default format applied to BIGINT data types.
Example:
BIGINT {"-(19)9"}
Utilities
287

SDF File
Syntax element ...

NUMERIC
Description
"numeric_decimal_default_format"
}
Gt15b027
numeric_decimal_default_format is a string
representing the default format applied to
NUMERIC and DECIMAL data types.
Example:
NUMERIC {"--(I).9(F)"}
I represents the number of characters needed to

display the integer portion of NUMERIC and
INTEGER data. For example:
With INTEGER type, I is 10.
With DECIMAL type (10,2), I is 8
F represents the number of characters required to
display the fractional portion of NUMERIC data.
For example, with DECIMAL type (10,2), F is 2.
REAL
"real_default_format"
}
Gt15b028
real_default_format is a string representing the

default format applied to REAL, DOUBLE
PRECISION, and FLOAT data types.
Example:
REAL {"-9.99999999999999E-999"}
288
Utilities

SDF File
Syntax element ...
DATE
Description
"date_default_format"
}
Gt15b029
date_default_format is a string representing the

default format applied to DATE and
PERIOD(DATE) data types.
Example:
DATE {"YY/MM/DD"}
In addition, the following Unicode characters can

appear in the format string for DATE.
The character:
\u5e74 ( ) specifies the Kanji year date marker
NEN be used as a separator. YYYY, Y4, or YY
must precede the NEN character.
\u6708 ( ) specifies that the Kanji month date
marker GATSU be used as a separator. MM
must precede the GATSU character.
\u65e5 ( ) specifies that the Kanji day date
marker NICHI be used as a separator. DD must
precede the NICHI character.
\u548c ( ) and \u66a6 ( ) specify that the
Japanese Imperial Era (WA REKI) date
formatting be used. The year designator
YY. must be used in the format clause.

\uhexnumber specifies Unicode characters above
0x009F.
Utilities
289

SDF File
Syntax element ...
TIME
Description
"time_default_format"
}
Gt15b030
time_default_format is a string representing the

default format applied to TIME, TIME WITH TIME
ZONE, and PERIOD(TIME) data types.
Example:
TIME {"HH:MI:SS.S(F)Z"}

appear in the format string for TIME.
The character:
\u6642 ( ) specifies that the Kanji hour time
marker JI be used as a separator. HH must
precede the JI character.
\u5206 ( ) specifies that the Kanji minute time
marker FUN be used as a separator. MI must
precede the FUN character.
\u79d2 ( ) specifies that the Kanji second time
marker BYOU be used in as separator. SS must
precede the BYOU character.
\uhexnumber specifies Unicode characters above
0x009F.
290
Utilities

SDF File
Syntax element ...

TIMESTAMP
Description
{
"timestamp_default_format"
timestamp_default_format is a string representing

the default format applied to TIMESTAMP,
TIMESTAMP WITH TIME ZONE, and
PERIOD(TIMESTAMP) data types.
}
Gt15b031
Example:
TIMESTAMP {"YYYY-MMDDBHH:MI:SS.S(F)Z"}

appear in the format string for TIMESTAMP.
The character:
\u6642 ( ) specifies that the Kanji hour time
marker JI be used as a separator. HH must
precede the JI character.
\u5206 ( ) specifies that the Kanji minute time
marker FUN be used as a separator. MI must
precede the FUN character.
\u79d2 ( ) specifies that the Kanji second time
marker BYOU be used in as separator. SS must
precede the BYOU character.
\uhexnumber specifies that Unicode characters
above 0x009F.
time_zone_string names a time zone or GMT offset.
TimeZoneString
"time_zone_string"; time_zone_rules
}
1102A248
time_zone_rules is a sequence of strings that

represents the time offset for the time zone.
Example 1:
{"GMT-8"; "-8"; "0"}
Example 2:
For locations that observe Daylight Savings Time
(DST), the time_zone_rules can define when in the
calendar year the system time zone offset should
change. The system will automatically adjust for
DST according to this code. For example:
{"America Pacific"; "-8"; "0"; "1";
"4"; "3"; "8"; "0"; "0"; "02:00:00";
"4"; "11"; "1"; "0"; "0"; "02:00:00";
"2009"; "2010"; "-8"; "0"; "-7"; "0"}
For more information on time zone strings and time

zone rules, see SQL Functions, Operators,
Expressions, and Predicates.
Also refer to the sample time zone strings and rules
in the file tdlocaledef_tzrules.txt, which is in /usr/
tdbms/etc.
Utilities
291

Example SDF Files
Syntax element ...
NUMBER
Description
"number_default_format"
number_default_format is a string representing the

default format applied to NUMBER data types.
Example:
1102A253
NUMBER {"FN9"}
Example SDF Files

Example 1
This example shows the Teradata Database default formatting settings.
//
//
//
//
//
//
//
//
//
//
File name
Purpose
: tdlocaledef.txt
: This file contains the specifications for data formatting(SDF)
defined by the user.
Scope
: Project - subsystems
Required files: None
History
: 05-21-2001 - Created
10-27-2005 - Added BIGINT
05-24-2010 - Added TimeZoneString
Description
: This data is compatible with pre-V2R5 releases.
DBS System Formatting Data
// Day and month names

ShortDays {
"Sun";
"Mon";
"Tue";
"Wed";
"Thu";
"Fri";
"Sat"
}
LongDays {
"Sunday";
"Monday";
"Tuesday";
"Wednesday";
"Thursday";
"Friday";
"Saturday"
}
ShortMonths {
"Jan";
"Feb";
"Mar";
"Apr";
"May";
"Jun";
"Jul";
"Aug";
"Sep";
292
Utilities

Example SDF Files
"Oct";
"Nov";
"Dec"
}
LongMonths {
"January";
"February";
"March";
"April";
"May";
"June";
"July";
"August";
"September";
"October";
"November";
"December"
}
AMPM {
"AM";
"PM"
}
// Parsing Elements
RadixSeparator {"."}
GroupSeparator {","}
GroupingRule
{"3"}
Currency
{"$"}
ISOCurrency
{"USD"}
CurrencyName
{"US Dollars"}
CurrencyRadixSeparator {"."}
CurrencyGroupSeparator {","}
{"3"}
DualCurrency
{"$"}
DualISOCurrency {"USD"}
DualCurrencyName {"US Dollars"}
// Data type default formats
BYTEINT
INTEGER
SMALLINT
BIGINT
NUMERIC
REAL
DATE
TIME
TIMESTAMP
NUMBER
{"-(3)9"}
{"-(10)9"}
{"-(5)9"}
{"-(19)9"}
{"--(I).9(F)"}
{"-9.99999999999999E-999"}
{"YY/MM/DD"}
{"HH:MI:SS.S(F)Z"}
{"YYYY-MM-DDBHH:MI:SS.S(F)Z"}
{"FN9"}
// System Time Zone string

TimeZoneString {""}
Utilities
293

Example SDF Files
Example 2 Customized SDF for Japanese Data Formatting

This example shows how an SDF file might be customized for a Japanese location. The file
contains Japanese date and time default formatting and the Unicode hex notation for Kanji
characters. Also, Unicode characters in the default format strings are specified with \u.
// DBS System Formatting Data
// Day and month names
ShortDays {
"\u65E5";
"\u6708";
"\u706B";
"\u6C34";
"\u6728";
"\u91D1";
"\u571F"
}
LongDays {
"\u65E5\u66DC\u65E5";
"\u6708\u66DC\u65E5";
"\u706B\u66DC\u65E5";
"\u6C34\u66DC\u65E5";
"\u6728\u66DC\u65E5";
"\u91D1\u66DC\u65E5";
"\u571F\u66DC\u65E5"
}
ShortMonths {
"1\u6708";
"2\u6708";
"3\u6708";
"4\u6708";
"5\u6708";
"6\u6708";
"7\u6708";
"8\u6708";
"9\u6708";
"10\u6708";
"11\u6708";
"12\u6708"
}
LongMonths {
"1\u6708";
"2\u6708";
"3\u6708";
"4\u6708";
"5\u6708";
"6\u6708";
"7\u6708";
"8\u6708";
"9\u6708";
"10\u6708";
"11\u6708";
"12\u6708"
}
AMPM {
"\u5348\u524D";
294
Utilities

Example SDF Files
"\u5348\u5F8C";
}
// Parsing Elements
RadixSeparator
GroupSeparator
GroupingRule
Currency
ISOCurrency
CurrencyName
DualCurrency
DualISOCurrency
DualCurrencyName
{"."}
{","}
{"3"}
{"\u00A5"}
{"JPY"}
{"Yen"}
{"."}
{","}
{"3"}
{"\u00A5"}
{"JPY"}
{"Yen"}
// Data type default formats

BYTEINT
INTEGER
SMALLINT
BIGINT
NUMERIC
REAL
DATE
TIME
TIMESTAMP
NUMBER
{"-(3)9"}
{"G-(I)9"}
{"G-(I)9"}
{"G-(I)9"}
{"G--(I)D9(F)"}
{"G-9D99999999999999E-999"}
{"YYYY\u5E74MM\u6708DD\u65E5"}
{"HH\u6642MI\u5206SSDS(F)\u79D2Z"}
{"YYYY\u5E74MM\u6708DD\u65E5BHH\u6642MI\u5206SSDS(F)\u79D2Z"}
{"FN9"}
// System Time Zone string

TimeZoneString {""}
Utilities
295

Example SDF Files
296
Utilities
CHAPTER 32
Teradata Network Statistics

(tdnstat)
The Teradata Network Statistics utility, tdnstat, provides a user interface to view, get, or clear
the Teradata Database Network Services-specific statistics. TDN is a PDE subsystem that
provides Teradata Database Network Services.
Runs From

such as cnsterm
Linux command line
Syntax
tdnstat
-a
-q
-v
-d
-C
-F
-G
t
n
-M
-R
-t
-c min
-z
-Z
Utilities
1102A250
Syntax element
Description
-a
Displays all TDN statistics, including Flow Control table statistics.
-C
Displays TDN message-class-specific statistics.
-F
Displays a snapshot of the BNS Message Service Statistics and the Reservation
Flow Control Statistics.
-G
Displays TDN global work sorting statistics.
297
Chapter 32: Teradata Network Statistics (tdnstat)

Teradata Network Statistics Displays
Syntax element
Description
-M
Displays TDN message-specific statistics.
-R
Displays last 31 TDN merges completed.
-t
Displays message Flow Control table statistics.
-c min
Specifies a minimum value for filtering out normal message Flow Control table
statistics. The default minimum value is 0. See the -t option above.
-q
Quiet mode. Shows less information than in default display in a reduced number
of output columns.
-q
Displays TDN service statistics in quiet mode.
-v
Verbose mode. Shows more information than default display in an increased

number of output columns.
-d
Debug mode.
Specifies the statistics display iteration interval in seconds.
Specifies the statistics display iteration number.
-z
Resets TDN statistics in local node.
-Z
Resets TDN statistics in all TPA nodes.

The tdnstat utility displays statistics on the following items:
TDN-specific statistics, which include the following:
Reservation Flow Control (RFC)
PagePool
Blockable service queue
Array table objects (for example, channel, group, and global semaphores)
TDN services invoked/blocked counts
Tx/Rx messages
PDE message subsystem Flow Control (FC), which includes the following:
Snapshot of in-bound PDE kernel FC tables
Snapshot of out-bound PDE kernel FC tables
Note: The PDE message subsystem uses the in-bound and out-bound FC tables for
controlling the receiving and the sending of messages.
Example 3
To view statistics, type the following:
298
Utilities

tdnstat
Depending on your system, output similar to the following appears:

STATS SNAPSHOT DISPLAY : Sun Feb 29 09:19:13 2004
-----------------------BNS PagePool Statistics :
PAGE
PAGE
PAGE
COUNT
REQUESTS
REQ_LONGEST
214
184
1
BNS BlockQueue Statistics :

BLKQ
BLKQ
BLK_CNT
UBLK_CNT
452
452
BNS ArrayTable Statistics :

OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
CHN_INUSE
CHN_PAGES
CHN_GET
CHN_PUT
GRP_INUSE
GRP_PAGES
GRP_GET
GRP_PUT
GSM_INUSE
GSM_PAGES
GSM_GET
GSM_PUT
BNS Service Statistics :

<OP>
<SUBOP>
TXCNT
-------------CHN
GET
41
CHN
PUT
35
CHN
FIRST
4
CHN
SIGNAL
665
CHN
READ
10
CHN
SET
255
CHN
UNASS
14
CHN
COUNT
4
CHN
SIGINIT
1
CHN
GRPCNT
38
GRP
GET
14
GRP
PUT
13
GRP
ENTER
105
GRP
LEAVE
10
GRP
INVALID
2
GRP
TEST
82
GRP
VALID
183
GRP
COUNT
70
GRP
IMPLENTR
51
GRP
TPASYNC
21
GSM
GET
152
GSM
PUT
93
GSM
DECR
227
Utilities
191
7
193
2
129
2
197
68
5
1
152
147
BLK
--0
0
0
16
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
782
0
0
0
LOCAL
----37
35
2
527
0
255
14
4
0
0
0
0
0
0
0
0
0
5
51
21
0
27
108
BLKQ
---0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
TXAVG
----2
1
1
2
3
0
0
0
0
1
2
2
1
1
2
0
0
1
0
21
0
1
1
TXMAX
----2
3
1
6
4
0
0
0
0
1
3
3
2
2
3
0
0
2
0
243
0
1
2
RXCNT
----13
17
6
258
76
0
0
0
0
0
69
68
0
0
38
0
0
0
0
0
0
120
324
299

GSM
GSM
GSM
GSM
MRG
MRG
MRG
MRG
MRG
MSG
MSG
MSG
MSG
MSG
MSG
MSG
MSG
NET
CFG
CFG
INCR
READ
WRITE
ATOMIC
CLEAR
INIX
MOVE
SENDREQ
SENDROW
TXGRPSEG
TXP2PSEG
TXGRPREC
TXP2PREC
RXGRPSEG
RXP2PSEG
RXGRPREC
RXP2PREC
CHKBYDEST
SELCOORD
SELTPA
55
5267
98
12
61
5
69
13
31
36
4461
178
6758
89
1928
1767
5338
34
1
1
0
0
0
0
0
0
0
0
0
0
0
28
3
0
0
0
0
11
0
3
RX MSG Service Statistics :

RXGRPSEG
MultiPackets
=
9
GlobalWork
=
2642
Received_Data =
1808 KB
RXP2PSEG
MultiPackets
=
45
Received_Data =
16678 KB
RXGRPREC
GlobalWork
=
6179
ChnNotReady
=
1
SBR_FCount
=
84
BitBucket_Num =
85
BitBucket_Data =
19 KB
Received_Data =
195 KB
RXP2PREC
ChnNotReady
=
3
InBandMsgs
=
4659
Received_Data =
529 KB
TX MSG Service Statistics :
TXGRPSEG
MultiPackets
=
5
GlobalWork
=
329
TXP2PSEG
MsgToLocal
=
117
MultiPackets
=
49
TXGRPREC
ChnNotReady
=
1
COR_FCount
=
27
MsgToLocal
=
1
ProcGroup
=
1
GlobalWork
=
299
TXP2PREC
MsgToLocal
=
1332
InBandMsgs
=
4673
300
8
5267
98
0
61
3
52
5
5
0
117
1
1273
0
0
0
0
29
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
1
1
1
2
456
3
1
4
1
0
0
0
0
17
0
35
2
0
0
0
1
1
2
5
790
16
2
35
5
0
0
0
0
42
0
64
29
0
0
12
0
17
8
3
8
110
1973
1876
5338
0
0
0
0
0
19
2
10 %
98 %
100 %
2 %
100 %
87
0
4
4
8
91
%
%
%
%
%
%
0 %
87 %
100 %
13 %
94 %
2 %
1 %
0
13
0
0
57
%
%
%
%
%
19 %
69 %
Utilities

Example 4
To view all TDN statistics, including Reservation Flow Control (RFC) Statistics, type the
following:
tdnstat -a

STATS SNAPSHOT DISPLAY : Tue Feb 24 17:10:55 2004
-----------------------BNS PagePool Statistics :
PAGE
PAGE
PAGE
COUNT
REQUESTS
REQ_LONGEST
189
15351
1
BNS BlockQueue Statistics :

BLKQ
BLKQ
BLK_CNT
UBLK_CNT
652
652
BNS ArrayTable Statistics :
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
OBJ
CHN_INUSE
CHN_PAGES
CHN_GET
GRP_INUSE
GRP_PAGES
GRP_GET
GRP_PUT
GSM_PAGES
GSM_GET
GSM_PUT

<OP>
<SUBOP>
TXCNT
-------------CHN
GET
45371
CHN
PUT
45369
CHN
FIRST
167
CHN
SIGNAL
338137
CHN
READ
160
CHN
SET
56210
CHN
UNASS
1381
CHN
COUNT
200
CHN
SIGINIT
1
CHN
GRPCNT
170
GRP
GET
116
GRP
PUT
115
GRP
ENTER
477
GRP
LEAVE
3697
GRP
INVALID
60
GRP
TEST
484
GRP
VALID
19715
GRP
COUNT
4016
GRP
IMPLENTR
10075
Utilities
163
6
163
129
2
131
2
1
78
78
BLK
--0
0
0
69
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
LOCAL
----45349
45365
84
251489
0
56225
1381
195
1
0
0
0
164
3475
0
0
0
3803
10070
BLKQ
---0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
TXAVG
----2
2
1
1
1
1
1
1
0
1
2
2
1
1
2
1
1
1
0
TXMAX
----5
8
2
5
4
1
1
1
0
2
4
4
2
2
4
1
1
2
0
RXCNT
----39
18167
5
83998
168
0
0
5
0
0
198
188
2
1408
145
0
0
0
1237
301

GRP
TPASYNC
80 4474
GSM
GET
37239
0
GSM
PUT 1233857
0
GSM
DECR 4764017
0
GSM
INCR
78795
0
GSM
READ
77697
0
GSM
WRITE
587
0
MRG
CLEAR
54
0
MRG
INIX
97
0
MRG
MOVE
256
0
MRG
SENDREQ
106
0
MRG
SENDROW
109
0
MSG
TXGRPSEG
714
0
MSG
TXP2PSEG
209781
19
MSG
TXGRPREC
120180
4
MSG
TXP2PREC
674041
46
MSG
RXGRPSEG
1424
0
MSG
RXP2PSEG
277622
0
MSG
RXGRPREC
563660
0
MSG
RXP2PREC
551029
0
NET FSHBYDEST
56
0
NET
FSHBYSRC
160
0
NET CHKBYDEST
2385
97
NET
CHKBYSRC
1
0
CFG
SELCOORD
4
20
CFG
SELTPA
4
10
RX MSG Service Statistics :
RXGRPSEG
MultiPackets
=
33
GlobalWork
=
2642
Received_Data =
10651 KB
RXP2PSEG
ChnNotReady
=
19
MultiPackets
=
10096
Received_Data = 3904905 KB
RXGRPREC
GlobalWork
=
6179
ChnNotReady
=
17
BitBucket_Num =
17
BitBucket_Data =
1 KB
Received_Data =
32247 KB
RXP2PREC
ChnNotReady
=
40
InBandMsgs
=
483248
Received_Data =
71580 KB
TX MSG Service Statistics :
TXGRPSEG
MsgToLocal
=
2
MultiPackets
=
11
GlobalWork
=
329
ProcGroup
=
4
TXP2PSEG
MsgToLocal
=
82321
MultiPackets
=
10402
TXGRPREC
ChnNotReady
=
4
MsgToLocal
=
1
ProcGroup
=
1
302
80
0
36620
668
32145
77697
587
54
20
161
82
95
2
82298
1
67067
0
0
0
0
56
160
2287
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
34
1
1
1
1
1
0
0
2
1
3
2
2
1
2
1
0
0
0
0
0
0
4
0
508
33
317
1
2
12
2
1
0
0
4
1
8
23
17
5
1944
6
0
0
0
0
0
0
6
0
1621
62
0
0
558
403
5757
0
0
0
109
143
21
24
1538
287718
571884
551029
0
0
0
0
0
0
0
0
38
13
2 %
98 %
100 %
0 %
3 %
100 %
87
0
0
0
99
%
%
%
%
%
0 %
87 %
100 %
0
1
94
0
%
%
%
%
39 %
4 %
0 %
0 %
0 %
Utilities

GlobalWork
TXP2PREC
ChnNotReady
MsgToLocal
InBandMsgs
299
57 %
=
=
=
6
68330
481134
0 %
10 %
71 %

<OP>
<SUBOP>
TXCNT
BLK
---------------MSG
TXGRPSEG
47091 24916
MSG
TXP2PSEG
282
2
MSG
TXGRPREC
62
0
MSG
TXP2PREC
391
0
MSG
RXGRPSEG
24644
0
MSG
RXP2PSEG
156
0
MSG
RXGRPREC
163
0
MSG
RXP2PREC
164
0
MSG
FCNOTIFY
18090
0
LOCAL
----24105
161
0
198
0
0
0
0
12322
BLKQ
---260
0
0
0
0
0
0
0
0
Reservation Flow Control Statistics :

Date
Start
End Chn
PtPs
Brds
---------- --------01/30 07:49:27
Active 4849
134
0
01/30 07:49:27
Active 5c83
319
0
01/30 07:49:26
Active 1281
190
0
01/30 07:49:26
Active c10e
279
0
01/30 07:49:26
Active 092a
220
0
01/30 07:49:26
Active 021d
219
0
01/30 07:49:26
Active bf3d
317
0
01/30 07:49:26
Active 64c8
258
0
01/30 07:49:26
Active 26f6
397
0
01/30 07:49:26
Active 5871
156
0
01/30 07:49:26
Active 4fe2
209
0
01/30 07:49:26
Active e250
220
0
01/30 07:49:26
Active 0caf
235
0
01/30 07:49:26
Active 8572
348
0
01/30 07:49:26
Active 75dd
241
0
01/30 07:49:26
Active 6bb5
186
0
01/30 07:49:26
Active 165e
276
0
01/30 07:49:26
Active f270
195
0
01/30 07:49:26
Active a926
160
0
01/30 07:49:26
Active d206
388
0
01/30 07:46:55 07:47:22 6e0d
0
1365
01/30 07:46:55 07:47:20 96b3
0
1365
01/30 07:26:57 07:31:44 1bc2
2051
0
01/30 07:26:57 07:31:43 66ae
2049
0
01/30 07:26:57 07:31:43 8b9a
2051
0
01/30 07:26:57 07:31:43 bb51
2051
0
01/30 07:26:57 07:31:43 5647
2049
0
01/30 07:26:57 07:31:43 431d
2051
0
01/30 07:26:57 07:31:43 d91a
2051
0
01/30 07:26:57 07:31:43 d5a0
2049
0
01/30 07:26:57 07:31:43 75dd
2049
0
01/30 07:26:57 07:31:43 0448
2051
0
01/30 07:26:57 07:31:43 e3ac
2049
0
01/30 07:26:57 07:31:42 7660
2049
0
01/30 07:26:57 07:31:42 b09e
2049
0
01/30 07:26:57 07:31:42 7785
2051
0
01/30 07:26:57 07:31:40 5c83
2049
0
Utilities
TXAVG
----72
1
1
1
0
0
0
0
0
TXMAX
----1662
4
1
1
0
0
0
0
0
RXCNT
----36636
156
163
164
0
0
0
0
7264
Waits Retrys CPU OnLst OnNet OnBox

----- ------ --- ----- ----- ----35
0
7
0
0
0
189
0 12
0
0
0
83
0
8
0
0
0
179
0 14
0
0
4
120
0 10
13
0
20
180
0 11
35
0
20
118
0
7
0
0
0
133
0 10
18
9
11
179
0
9
16
0
20
63
0
8
0
0
0
94
0
9
3
3
2
101
0
7
21
0
20
103
0
9
0
0
5
211
0 11
16
0
20
140
0 12
0
0
6
63
0
6
20
0
20
129
0
9
0
0
0
82
0
7
0
0
8
106
0 12
0
0
0
229
0 12
8
0
20
1310
0 19
0
0
0
1334
0 19
0
0
0
782
0
8
0
0
0
771
0
8
0
0
0
824
0
9
0
0
0
871
0
9
0
0
0
755
0
8
0
0
0
932
0
9
0
0
0
1146
0 11
0
0
0
766
0
8
0
0
0
943
0 10
0
0
0
973
0 10
0
0
0
1126
0 10
0
0
0
887
0
9
0
0
0
735
0
8
0
0
0
896
0
9
0
0
0
676
0
8
0
0
0
303

01/30
01/30
01/30
01/30
01/30
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:31:36
07:31:27
07:31:24
07:31:02
07:30:10
3cfb
da7f
2f35
7a21
cb2a
2049
2051
2051
2049
2051
0
0
0
0
0
1177
778
839
912
1112
0
0
0
0
0
11
9
9
10
11
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Example 5
To display the last 31 TDN merges that are completed, type the following:
tdnstat -R

STATS SNAPSHOT DISPLAY : Mon Mar 17 10:12:54 1997
-----------------------BNS Service Statistics :
<OP>
<SUBOP>
TXCNT
BLK
LOCAL BLKQ TXAVG
-------------------- ---- ----MRG
CLEAR
54
0
54
0
0
MRG
INIX
97
0
20
0
2
MRG
MOVE
256
0
161
0
1
MRG
SENDREQ
106
0
82
0
3
MRG
SENDROW
109
0
95
0
2
Performance Summary of Last 31 Merges:
Rows/Sec
Bytes/Sec
Rows
Bytes
----------------------69
1147055
2
33142
1117
121188
34
3688
1135
123115
34
3688
1143
123993
34
3688
852
92372
34
3688
1127
122245
34
3688
1135
123162
34
3688
1134
123016
34
3688
1132
122823
34
3688
302
39862
9
1188
836
90921
33
3588
1114
121139
33
3588
440
42037
13
1241
436
41582
13
1241
430
33024
13
999
349
23971
25
1717
1318
111540
26
2201
472
35208
14
1044
813
68821
24
2031
793
67139
24
2031
236
22819
7
677
868
75681
26
2267
99
4853
4
196
95
13055
3
413
147
20253
3
413
195
18280
4
375
267
14962
8
449
1117
121184
34
3688
1182
127680
36
3888
175
16407
7
657
231
22331
7
677
304
PASS#
----4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
TXMAX
----0
4
1
8
23
RXCNT
----0
109
143
21
24
USEC
---30097
31700
31204
30983
41589
31426
31192
31229
31278
31045
41107
30853
30752
31088
31511
74612
20555
30888
30741
31511
30905
31203
42074
32954
21242
21369
31259
31701
31720
41713
31580
Utilities

AvgRows/Sec =
670
AvgBytes/Sec =
104249
Example 6
To display TDN message class-specific statistics, type the following:
tdnstat -C

STATS SNAPSHOT DISPLAY : Fri Oct 24 06:00:49 2008
<OP>
<SUBOP>
TXCNT
BLK
---------------MSG
TXGRPSEG
59519 7535
MSG
TXP2PSEG
158731 5233
MSG
TXGRPREC
164719
0
MSG
TXP2PREC
691070 16628
MSG
RXGRPSEG
69914
0
MSG
RXP2PSEG
54443
0
MSG
RXGRPREC
213601
0
MSG
RXP2PREC
379021
0
MSG
FCNOTIFY
8395
0
MSG Class Statistics :
MSG_CLASS
COUNT
PERCENT
------------------TRANSIENT
64907
6
PROCBOX
136581
13
HASHBOX
439127
41
GROUPBOX
182863
17
PROCCHAN
183225
17
HASHCHAN
26026
2
GROUPCHAN
22019
2
PRCGRPCHN
19271
2
P2PKMSG
85
0
Utilities
LOCAL
----14119
122098
3
412233
0
0
0
0
5580
BLKQ
---0
0
0
0
0
0
0
0
0
HIGHEST
------4
4
8
2
10
28
20
30
TXAVG
----2
5
1
5
0
0
0
0
0
CUR_CNT
------0
0
0
0
0
0
0
0
TXMAX
----37
180
2
80
0
0
0
0
0
RXCNT
----78374
54480
214408
379161
0
0
0
0
2621
FC_CNT
-----0
0
0
0
0
1907
0
0
305

Example 7
To display BNS Message Service Statistics and Reservation Flow Control (RFC) Statistics, type
the following:
tdnstat -F

STATS SNAPSHOT DISPLAY : Fri Jan 30 07:49:33 2004
<OP>
<SUBOP>
TXCNT
BLK
---------------MSG
TXGRPSEG
47091 24916
MSG
TXP2PSEG
282
2
MSG
TXGRPREC
62
0
MSG
TXP2PREC
391
0
MSG
RXGRPSEG
24644
0
MSG
RXP2PSEG
156
0
MSG
RXGRPREC
163
0
MSG
RXP2PREC
164
0
MSG
FCNOTIFY
18090
0
LOCAL
----24105
161
0
198
0
0
0
0
12322
BLKQ
---260
0
0
0
0
0
0
0
0
Reservation Flow Control Statistics :

Date
Start
End Chn
PtPs
Brds
---------- --------01/30 07:49:27
Active 4849
134
0
01/30 07:49:27
Active 5c83
319
0
01/30 07:49:26
Active 1281
190
0
01/30 07:49:26
Active c10e
279
0
01/30 07:49:26
Active 092a
220
0
01/30 07:49:26
Active 021d
219
0
01/30 07:49:26
Active bf3d
317
0
01/30 07:49:26
Active 64c8
258
0
01/30 07:49:26
Active 26f6
397
0
01/30 07:49:26
Active 5871
156
0
01/30 07:49:26
Active 4fe2
209
0
01/30 07:49:26
Active e250
220
0
01/30 07:49:26
Active 0caf
235
0
01/30 07:49:26
Active 8572
348
0
01/30 07:49:26
Active 75dd
241
0
01/30 07:49:26
Active 6bb5
186
0
01/30 07:49:26
Active 165e
276
0
01/30 07:49:26
Active f270
195
0
01/30 07:49:26
Active a926
160
0
01/30 07:49:26
Active d206
388
0
01/30 07:46:55 07:47:22 6e0d
0
1365
01/30 07:46:55 07:47:20 96b3
0
1365
01/30 07:26:57 07:31:44 1bc2
2051
0
01/30 07:26:57 07:31:43 66ae
2049
0
01/30 07:26:57 07:31:43 8b9a
2051
0
01/30 07:26:57 07:31:43 bb51
2051
0
01/30 07:26:57 07:31:43 5647
2049
0
01/30 07:26:57 07:31:43 431d
2051
0
01/30 07:26:57 07:31:43 d91a
2051
0
01/30 07:26:57 07:31:43 d5a0
2049
0
01/30 07:26:57 07:31:43 75dd
2049
0
306
TXAVG
----72
1
1
1
0
0
0
0
0
TXMAX
----1662
4
1
1
0
0
0
0
0
RXCNT
----36636
156
163
164
0
0
0
0
7264
Waits Retrys CPU OnLst OnNet OnBox

----- ------ --- ----- ----- ----35
0
7
0
0
0
189
0 12
0
0
0
83
0
8
0
0
0
179
0 14
0
0
4
120
0 10
13
0
20
180
0 11
35
0
20
118
0
7
0
0
0
133
0 10
18
9
11
179
0
9
16
0
20
63
0
8
0
0
0
94
0
9
3
3
2
101
0
7
21
0
20
103
0
9
0
0
5
211
0 11
16
0
20
140
0 12
0
0
6
63
0
6
20
0
20
129
0
9
0
0
0
82
0
7
0
0
8
106
0 12
0
0
0
229
0 12
8
0
20
1310
0 19
0
0
0
1334
0 19
0
0
0
782
0
8
0
0
0
771
0
8
0
0
0
824
0
9
0
0
0
871
0
9
0
0
0
755
0
8
0
0
0
932
0
9
0
0
0
1146
0 11
0
0
0
766
0
8
0
0
0
943
0 10
0
0
0
Utilities

01/30
01/30
01/30
01/30
01/30
01/30
01/30
01/30
01/30
01/30
01/30
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:26:57
07:31:43
07:31:43
07:31:42
07:31:42
07:31:42
07:31:40
07:31:36
07:31:27
07:31:24
07:31:02
07:30:10
0448
e3ac
7660
b09e
7785
5c83
3cfb
da7f
2f35
7a21
cb2a
2051
2049
2049
2049
2051
2049
2049
2051
2051
2049
2051
0
0
0
0
0
0
0
0
0
0
0
973
1126
887
735
896
676
1177
778
839
912
1112
0
0
0
0
0
0
0
0
0
0
0
10
10
9
8
9
8
11
9
9
10
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
0
0
0
0
0
0
0
0
0
The following table defines the columns.

The column
Is the
Date
date when the first message was received.
Start
time when the first message was received.
End
time when the last message was received.
PtPs
number of inbound minicast messages that have been delivered to the message
subsystem.
Brds
number of inbound broadcast messages that have been delivered to the message
subsystem.
Waits
number of inbound messages that had to wait due to flow control.
Retrys
number of inbound message retries due to allocation failure.
CPU
rough measure of per-message CPU overhead for flow control
OnLst
number of inbound messages currently waiting on the reservation list.
OnNet
number of inbound messages currently pending across the BYNET.
OnBox
number of inbound messages currently on mailboxes.
In addition to message service statistics (including FCNOTIFY services used for flow control
notifications), tdnstat displays statistics for up to 64 active and recently completed significant
row redistributions and table duplications.
Utilities
307

308
Utilities
CHAPTER 33
Warning:
Teradata Network Tuner

(tdntune)
Setting tunable parameters improperly can degrade system performance. This utility should
only be used under the direction of the Teradata Support Center.
The Teradata Network Tuner utility, tdntune, reads, displays, and writes Teradata Database
Network Services tunable parameters. TDN is a PDE subsystem that provides Teradata
Database Network Services.
Tunables are stored in the PDE Control GDO, a Teradata Database globally distributed object
that stores settings which are automatically made available to all nodes in the system.
Runs From

such as cnsterm
Linux command line
Syntax
tdntune
-h
get
file
set file
Utilities
Syntax element
Description
-h
Displays the help for tdntune.
1102D021
309
Chapter 33: Teradata Network Tuner (tdntune)

Syntax
Syntax element
Description
get [file]
Displays or writes the current settings of Teradata Database network services

tunable parameters from the PDE Control GDO.
Optionally, you can specify a file name, and the settings will be written to a
text file.
To change the Teradata Database network services tunable parameter
settings, edit this file and run tdntune using the set option, and
specifying the file name.
If a file name is not specified, the settings are displayed on screen; this is
the default behavior of tdntune.
set file
310
Reads new settings for Teradata Database network services tunable

parameters from file, and writes them to the PDE Control GDO, making
those settings available to all nodes of the system. file is required with the set
option.
Utilities

Syntax
Example
To show TDN tunables, type the following at the command line:
tdntune

# Fri Jan 30 08:27:24 2004
# GDO TDN TUNEABLES:
# -----------------PAGE_LWM
PAGE_HWM
PAGE_REQ
PAGE_REL
PAGE_MAX_REQS
PAGE_LMHR
CHN_BLK_TICK
GRP_BLK_TICK
GSM_BLK_TICK
MRG_BLK_TICK
MSG_BLK_TICK
FC_P2PREC_BLK_TICK
FC_P2PSEG_BLK_TICK
FC_GRPREC_BLK_TICK
FC_GRPSEG_BLK_TICK
SVC_TIME_METHOD
GWS_DISABLE
FCIN_P2PCHN_THRESHLD
FCIN_P2PCHN_INITVAL
FCIN_P2PGRP_THRESHLD
FCIN_P2PGRP_INITVAL
FCIN_GRP_THRESHLD
FCIN_GRP_INITVAL
FCIN_CHN_THRESHLD
FCIN_CHN_INITVAL
FCIN_RFC_ENABLE
FCIN_RFC_THRESHLD
FCOUT_THRESHLD
FCOUT_INITVAL
#
#
#
#
#
#
#
Utilities
128
1500
64
128
4
1000
1
1
1
4
4
4
4
4
4
UNIX_TIME
0
5
255
5
20
5
20
5
20
1
20
5
5
GDO FCIN_ADJ (Read-only) fields:

-------------------------------TPA_NODE_COUNT
2
FCIN_P2PCHN_ADJ_INITVAL 235
FCIN_P2PGRP_ADJ_INITVAL
0
FCIN_GRP_ADJ_INITVAL
0
FCIN_CHN_ADJ_INITVAL
0
311

Syntax
312
Utilities
CHAPTER 34
TPA Reset (tpareset)
The TPA Reset utility, tpareset, resets Teradata Database. All PDE tasks except for some kernel
daemons are killed. All database processes, including those for AMPs and PEs, are stopped
and restarted. TPA Reset options control whether dump information is collected, whether the
node on which tpareset is run is rebooted, and whether the system remains down or restarts.
TPA Reset can be used:
Caution:
after Teradata Database has been reconfigured
to activate new versions of Teradata Database software
to recover from a database hang
in other situations that warrant a full database shutdown and restart
Use TPA Reset only when absolutely necessary. TPA Reset has a system-wide effect. Shutting
down the system and restarting not only causes system down time, but can also have a
performance impact when the system starts up and runs standard recovery and reconcile
operations.
Runs From

such as cnsterm
Linux command line
Syntax
tpareset
reason
-xit
-x
-panic
-p
-exit
-e
-dump
-d
-nodump
-yes
-y
-stop
-s
-force
-f
-help
-h
Utilities
1102B230
313
Chapter 34: TPA Reset (tpareset)

Syntax
Note: Some strictly internal and rarely-needed options have been omitted from this
discussion. Those options are documented in the tpareset command-line help.
Syntax element
Description
-xit
Shuts down Teradata Database on all nodes of the system. The system must be
explicitly restarted after the -x option is used.
-exit
-stop
Brings PDE down on the node from which the tpareset was initiated. The
other nodes go through a reset cycle, but the initiating node stays down. On
an SMP system, this is equivalent to -exit.
Sets the state of the initiating node to DOWN/TDMAINT. Nodes in this state
stay down until tpareset -f or a system wide shutdown and restart brings them
back into the Teradata Databasesystem.
-force
Forces a full restart on all nodes of the system. This option has the following
effects:
Brings any nodes that are running but in DOWN/TDMAINT state back
into the Teradata Database system.
Clears the system-wide crash count
If the crash count was preventing the database from being started, this
option forces the database to be started on all nodes. -force should not be
used until the condition that caused the crash loop has been corrected.
Forces reconcile to run
Reconcile normally runs when any node that was down is brought back up,
or when a Teradata Database version switch has been requested,
necessitating a system reset.
Reconcile:
validates that each node is running the same version of the various
software components that comprise Teradata Database
ensures that these versions are compatible with each other
switches versions of specific components if such a version switch has
been requested. (Such version switches are specified from the ctl utility
programs.)
The -f option forces reconcile to run during a reset, regardless of status of
system nodes and regardless of whether a version switch has been
requested.
Forces the database cache to be discarded
The database cache may also be discarded in other reset situations when
the -f option has not been specified.
Note: Reinitializing the cache can add several minutes to restart time.
314
Utilities

Usage Notes
Syntax element
Description
-panic
Initiates a reboot of the node where tpareset was executed. A database dump is
captured from all nodes, and an operating system dump is captured on the
rebooted node. The remaining nodes undergo a normal reset and restart cycle
without being rebooted.
When the database restarts, the node from which tpareset was run is excluded
from the parallel database system. When the problem that required the panic
reset is resolved, the node can be returned to service by issuing another
tpareset.
Note: This option should be used only if the Teradata Support Center
determines that a dump is necessary for problem isolation.
-nodump
Prevents the -panic option from capturing a database-level dump. However,

an operating system dump will still be captured on the initiating node,
initiating a node reboot.
-dump
Causes a database dump to be captured before the system is reset and

restarted.
Note: This option should be used only if the Teradata Support Center
determines that a dump is necessary for problem isolation.
-yes
Suppresses the normal tpareset confirmation prompt.
reason
The tpareset command must end with a string that describes the reason for the
reset. The reason need not be delimited by double quotation marks or
apostrophes. The string cannot start with a dash (-).
-help
Displays tpareset command syntax information.
Usage Notes
The RESTART TPA command, available from Database Window (DBW), is similar to TPA
Reset, in that it resets and restarts Teradata Database. However, RESTART TPA lacks several of
the options of TPA Reset. For example, RESTART TPA cannot be used to shut down the PDE
component of Teradata Database. For more information about DBW, see Utilities Volume 1.
TPA Reset can only be run on nodes where PDE is running.
Example
> tpareset -d Recover from DBS hang.
You are about to restart the database
on the system
'Test1'
Do you wish to continue (default: n) [y,n]
Utilities
315

Usage Notes
316
Utilities
CHAPTER 35
Two-Phase Commit Console

(tpccons)
The Two-Phase Commit Console, tpccons, allows you to perform the following 2PC-related
functions:
Display the host identifiers for all in-doubt transactions.
Display a list of coordinators that have in-doubt transactions.
Display a list of sessions that have in-doubt transactions.
Resolve in-doubt transactions.
A transaction is considered in doubt after the server has voted to commit until the transaction
receives a commit or abort instruction from the coordinator. For the Teradata Database, the
coordinator is always either Information Management System (IMS) or Customer
Information Control System (CICS) and is never in doubt.
tpccons uses the Resolver Base Module (RBM) to resolve in-doubt transactions. Running
tpccons causes a logon to an RBM session. RBM sessions started from the system console by
the user do not appear in DBC.SessionTbl, while RBM sessions started by other users do.
Runs From
Tpccons runs from Database Window or comparable interface to the Teradata Database
Usage Notes
You must type your user logon id and password to use the Two-Phase Commit Console.
You must have the EXECUTE privilege on the TwoPCRule macro.
Note: If you logon as other than DBC, when prompted for your password, type the
password and remainder of the logon string, such as account ID, separated by a comma.
Utilities
You can abort any process by pressing the F3 function key. The system returns a failure
response if the abort is successful.
317
Chapter 35: Two-Phase Commit Console (tpccons)

Two-Phase Commit Console Commands
Two-Phase Commit Console Commands

The Two-Phase Commit Console utility presents a command-line environment that allows
the entry of the following commands, which are discussed in more detail in the sections that
follow.
318
Command
Description
COMMIT (or ROLLBACK)
Commits or aborts any in-doubt work units, and optionally, logs

the session off after the transaction is resolved.
DISPLAY
Displays the task-ids for all coordinators having in-doubt

transactions.
Utilities

Purpose
Commits or aborts any in-doubt work units, and optionally, logs the session off after the
transaction is resolved. Each transaction that is resolved is logged. For information about
DBC.InDoubtLogV, see Data Dictionary.
Syntax
COMMIT
ALL
ROLLBACK
A
,
AND LOGOFF
IN DOUBTS FOR
SESSIONS
sessions-no
,
RUN UNITS
run-unit-id
coord-id
ON
host-id
;
1102D003
Syntax element
Specifies
AND LOGGOFF
that the session is logged off after the transaction is resolved.
ALL
every in-doubt transaction for a given coordinator and host identifier.
SESSIONS
the sessions to be resolved by the session-no ID.
sessions-no
the session number of the in-doubt transaction returned from a DISPLAY IN

DOUBTS command.
RUN UNITS
the run units to be resolved by the run-unit-id.
run-unit-id
the run unit identifier of the in-doubt transaction returned from a DISPLAY
IN DOUBTS command.
IN DOUBTS FOR
a list of run unit identifiers and session identifiers for all in-doubt
transactions.
coord-id
the coordinator identifier, by host, of the in-doubt transaction displayed as a

hexadecimal string returned from a DISPLAY COORDINATORS command.
ON host-id
the host identifier of the in-doubt transaction obtained from a DISPLAY

HOSTS or a DISPLAY COORDINATORS command.
Usage Notes
The run-unit specified must have an in-doubt transaction. The request fails if a specified
session is not found or is not in-doubt. In such cases, no action is taken on any of the sessions,
and a fail message is displayed.
Utilities
319

DISPLAY
DISPLAY
Purpose
Displays the task-ids for all coordinators having in-doubt transactions.
Syntax
DISPLAY
HOSTS
host-id
COORDINATORS FOR
IN DOUBTS FOR
coord-id
*
*
ON
host-id
*
GT15A005
Syntax element
Specifies
HOSTS
all hosts connected to the system.
COORDINATORS FOR
the coordinators for all in-doubt transactions.
host-id
the host identifier on the system having in-doubt transactions,

interpreted as an integer.
IN DOUBTS FOR
a list of run unit identifiers and session identifiers for all in-doubt
transactions.
coord-id
the coordinator identifier, by host, of the in-doubt transaction

displayed as a hexadecimal string.
indicates all (either coordinators or hosts).
ON host-id
the host identifier of the in-doubt transaction obtained from a

DISPLAY HOSTS or a DISPLAY COORDINATORS command.
Usage Notes
If the coord-id option is specified, only sessions on the specified coordinator are listed. If a
host-id is specified, only sessions on the specified host are listed.
The DISPLAY IN DOUBTS FOR command returns a list consisting of a session number with
corresponding run-unit IDs. Session numbers are displayed as integers; run-unit IDs are
displayed as hex strings.
320
Utilities

Identifying and Resolving In-Doubt Transactions
Identifying and Resolving In-Doubt

Transactions
The following procedure shows how to use tpccons to identify and resolve in-doubt
transactions.
1
From the Supervisor Screen, type the following:

start tpccons
Press F8 to switch to the select screen and then select the partition that is running tpccons.
The system displays the following:
Enter your user id to logon, F7 for help, or RETURN to exit:
Type the following:

DBC

Enter the Password:
Type the password for the user DBC.

Logon successfully completed.
Type the following:

Display Hosts ;
Depending upon your installation, the system responds with the following:
Date: 00/06/25 Time: 11:00:00
Request successfully completed. 3 rows returned.
Host Id
------383
497
1124
Enter command, QUIT;, or F7 for help:
Type the following:

display coordinators for 497 ;
Depending upon your installation, the system displays the following:

Date: 00/06/25 Time: 11:00:07
Host Id: 497
Coordinator
-------------------A3A3A3A3A3
A1A1A1A1A1A1A1A1A1A1
A2A2A2A2A2A2A2A2A2A2
Utilities
321

Identifying and Resolving In-Doubt Transactions
7
Type the following:

display in doubts for A3A3A3A3A3 on 1124 ;

Date: 00/06/25 Time: 11:00:08
Host Id: 1124
Coordinator: A3A3A3A3A3
Session
RunUnit
----------------------1002
B1B1B1B1B1B1B1B1
1001
B2B2B2B2B2B2B2B2
1003
B3B3B3B3B3B3B3B3
Type the following:

commit session 1001 in doubt for A3A3A3A3A3 on
1124 ;

Request successfully completed. 1 In-doubt transaction resolved.
Type the following:

rollback and logoff all in doubt for A3A3A3A3A3 on 1124 ;

Request successfully completed. 2 In-doubt transaction resolved.
10 Type the following:

QUIT;

Two-Phase Commit Console Interface Terminated.
322
Utilities
CHAPTER 36
Update DBC (updatedbc)
The Update DBC utility, updatedbc, performs the following:

In table
Update DBC recalculates
DBASE
PermSpace, SpoolSpace, and TempSpace values for user DBC.

The PermSpace value in DBASE for user DBC is the total available
storage space minus the PermSpace for all other databases.
The SpoolSpace and TempSpace values in DBASE for user DBC are the
total available storage space.
For databases other than DBC, the PermSpace, SpoolSpace, and TempSpace
values in the DBASE table are the maximums declared when the database is
defined.
The DBASE table includes the following columns:
PermSpace
SpoolSpace
TempSpace
DATABASESPACE
MaxPermSpace, MaxSpoolSpace, and MaxTempSpace values for each

database in the system based on the PermSpace, SpoolSpace, and
TempSpace values in the DBASE table for that database.
The DATABASESPACE table includes the following columns:
CurrentPermSpace
CurrentSpoolSpace
CurrentTempSpace
MaxPermSpace
MaxSpoolSpace
MaxTempSpace
Values in the DBASE table are the global values. Values in the DATABASESPACE table are
local AMP values. The calculation is the global value divided by the number of AMPs in the
system.
The following table lists the difference between the Update DBC and Update Space utilities.
Utilities
The utility
Recalculates the
Update DBC
maximum allowed values for permanent, temporary, and spool space.
Update Space
current usage for permanent, temporary, and spool space.
323
Chapter 36: Update DBC (updatedbc)

Runs From
Use Update DBC only to correct inconsistency in the DBASE or DATABASESPACE tables,
which might occur as the result of rare types of system failures.
For descriptions of the DBASE and DATABASESPACE tables and columns, see Data
Dictionary.
For more information on the Update Space utility, see Chapter 37: Update Space
(updatespace).
Runs From
Update DBC runs from Database Window or comparable interface to the Teradata Database
324
Utilities
CHAPTER 37
Update Space (updatespace)
The Update Space utility, updatespace, recalculates the permanent, temporary, or spool space
used by either of the following:
A single database and its individual tables
All databases in a system and their individual tables
Update Space accomplishes this by performing the following:
Examining storage descriptors and adding up space for each table.
Setting values in CurrentPermSpace, CurrentTempSpace, or CurrentSpoolSpace in the

DATABASESPACE table for each table and for the containing database as a whole.
The following table lists the difference between the Update DBC and Update Space utilities.
The utility
Recalculates the
Update DBC
maximum allowed values for permanent, temporary, and spool space.
Update Space
current usage for permanent, temporary, and spool space.
Use Update Space only to correct inconsistency in the DATABASESPACE table, which might
occur as the result of rare types of system failures.
For descriptions of the DBASE and DATABASESPACE tables and columns, see Data
Dictionary.
For more information on the Update DBC utility, see Chapter 36: Update DBC
(updatedbc).
Runs From
Update Space runs from Database Window or comparable interface to the Teradata Database
Utilities
325
Chapter 37: Update Space (updatespace)

Syntax
Syntax
Update Space presents a command-line environment that allows the entry of the UPDATE
command, which has the following syntax.
UPDATE
SPACE FOR
ALL DATABASES
dbname
SPACE FOR
dbname
TEMPORARY
ALL
SPOOL
PSPOOL
1102H401
Syntax element
Specifies
TEMPORARY
to update only the temporary space.
ALL
to update all the space.
SPOOL
to update only the spool space.

Note: Spool space can be calculated for a single database only.
PSPOOL
to update only the spool space that persists across restarts.
SPACE FOR
specifies the name of the database(s) for which space is to be

recalculated.
ALL DATABASES
all the databases in a system.
dbname
the name of a single database.
Usage Notes
To exit the Update Space utility, type q or quit with no semicolon terminator, on the
command line.
Non-standard database names that contain special characters must be enclosed within double
quotation marks. Special characters are most punctuation characters and whitespace
characters. The delimiting double quotation marks are not counted as part of the name
length, and are not stored in the Data Dictionary tables.
To include a double quotation mark character as part of a database name, precede it with
another double quotation mark character.
326
Utilities

Usage Notes
For example:
Desired Database Name
Required Update Space Notation
Current Salary
"Current Salary"
D'Augusta
"D'Augusta"
db1 db @#$%
"db1 db @#$%"
db1."db2
"db1.""db2"
Db!@
""
"Db!@
"""""
Example 1
Enter Command
update all space for all databases;
Updating space for DBC
Space updated for DBC
Updating space for SYSTEMFE
Space updated for SYSTEMFE
Updating space for RESCRIBE
Space updated for RESCRIBE
Updating space for CRASHDUMPS
Space updated for CRASHDUMPS
Updating space for PUBLIC
Space updated for PUBLIC
Updating space for DEFAULT
Space updated for DEFAULT
Updating space for TDPUSER
Space updated for TDPUSER
Updating space for SYS_CALENDAR
Space updated for SYS_CALENDAR
Updating space for SYSADMIN
Space updated for SYSADMIN
Updating space for ALL
Space updated for ALL
Example 2
Enter Command
update temporary space for public;
Updating space for PUBLIC
Space updated for PUBLIC
Utilities
327

Usage Notes
328
Utilities
CHAPTER 38
Verify Pdisks (verify_pdisks)
The Verify Pdisks utility, verify_pdisks, is used to verify the pdisks on the system are accessible
and are mapped correctly.
Verify Pdisks reads each pdisk storage device on the node from which it was run and
determines the TVS system and disk IDs associated with that device. If the IDs differ from
those specified in the Vconfig GDO (globally distributed object that stores configuration
settings), or if the attempt to read the pdisk device fails, verify_pdisks returns an error with
information about the nature of the problem.
This utility can be run at any time regardless of the state of the PDE or Teradata Database.
Runs From

such as cnsterm
Linux command line
To start Verify Pdisks, type verify_pdisks at the command prompt. For general
information on starting the utilities from different interfaces, see Appendix B: Starting the
Utilities.
Syntax
verify_pdisks
-v
-h
-?
Utilities
1102A232
Syntax element
Description
-v
Provides a detailed (verbose) description of verify_pdisks activity.
-h
(Help mode) Displays usage.
-?
(Help mode) Displays usage.
329
Chapter 38: Verify Pdisks (verify_pdisks)

When to Run Verify Pdisks
Note: If no options are specified, Verify Pdisks reports any errors and summarizes the number
of errors detected. If no errors are detected, Verify Pdisks reports that all pdisks on the current
node are verified.
When to Run Verify Pdisks

Verify Pdisks should be run any time you suspect that the database is unable to access disks.
Some possible indicators include:
vprocs are reported as fatal** from vprocmanager status.
A database restart or restart loop.
Any errors following a system operating system restart or during the starting of PDE.
Errors in the /etc/.osm, or /var/adm/streams/* log files that indicate disk failures.
Note: Verify Pdisks automatically checks all pdisks for all AMP vprocs in the clique of the
node on which it is run. To check the entire system, Verify Pdisks should be run on one node
from each clique.
330
Utilities

Examples
Examples
Example 1
This example shows all pdisks on the current node are verified.
> verify_pdisks
All pdisks on this node verified.
Example 2
This example shows two errors detected by Verify Pdisks.
> verify_pdisks
*****ERROR DETECTED*****
subpool 1, pdisk /dev/pdisk/dsk1:
disk id was 1, should be 1.
system id was 0xF14EA20847AA36E0, should be 0x46A513645281BA31
*****1 error(s) found during pdisk verification*****
Example 3
This example shows an excerpt of Verify Pdisks output from the same system as the previous
example, but in verbose mode.
> verify_pdisks -v
1276 bytes successfully read from Vconfig GDO
TVS system-id from file: 0x46A513645281BA31
Succesfully loaded libtvsaalloclib.so.
This is node 002-10.
It is in clique 1.
Checking subpool 1 pdisks...
pdisk 0: /dev/pdisk/dsk1....
*****ERROR DETECTED*****
subpool 1, pdisk /dev/pdisk/dsk1:
disk id was 1, should be 1.
system id was 0xF14EA20847AA36E0, should be 0x46A513645281BA31.
*****1 error(s) found during pdisk verification*****
Please check the vconfig.txt file and/or the hardware.
Vconfig Text File

The file vconfig.txt describes the physical components of a system and how they are utilized. It
lists the mappings of virtual elements to physical elements (such as vprocs to physical disk
Utilities
331

Vconfig Text File
devices). These settings are stored in the Vconfig GDO, and automatically distributed to all
nodes of the system.
The vconfig text files can be inspected if Verify Pdisks reports errors in the configuration,
however, configuration changes should be made only by using the Parallel Upgrade Tool
(PUT). Do not edit the vconfig text file unless instructed to do so by Teradata Support Center
personnel.
The vconfig.txt file is located in /etc/opt/Teradata/tdconfig.
332
Utilities
CHAPTER 39
Vproc Manager (vprocmanager)
The Vproc Manager utility, vprocmanager, allows you to manage the virtual processors
(vprocs) in a Teradata Database system. Vprocs are a set of software processes that run under
Teradata Parallel Database Extensions (PDE) within the multitasking environment of the
operating system. Vprocs are the heart of Teradata Database, managing the basic functions of
the system.
Teradata Database systems can include the following vproc types.
Vproc Type
Description
AMP
Access module processors perform database functions, such as executing database

queries. Each AMP owns a portion of the overall database storage.
GTW
Gateway vprocs provide a socket interface to Teradata Database.
Node
The node vproc handles PDE and operating system functions not directly related to
AMP and PE work. Node vprocs cannot be externally manipulated, and do not
appear in the output of the Vproc Manager utility.
PE
Parsing engines perform session control, query parsing, security validation, query
optimization, and query dispatch.
RSG
Relay Services Gateway provides a socket interface for the replication agent, and for
relaying dictionary changes to the Teradata Meta Data Services utility.
TVS
Manages Teradata Database storage. AMPs acquire their portions of database

storage through the TVS vproc.
Vproc Manager allows you to perform the following:
Obtain the status of some or all of the vprocs
Change vproc states
Initialize and boot one or more specified AMP vprocs
Initialize the storage associated with one or more specified AMP vprocs
Force a database restart
Vproc Manager can be used with the Table Rebuild utility to initialize and boot a specific AMP
vproc in order to rebuild the portion of all tables associated with the vproc.
Utilities
333
Chapter 39: Vproc Manager (vprocmanager)

Runs From
Runs From

such as cnsterm
Linux command line
Definitions of Terms Used in Vproc Manager

The following terms apply to Vproc Manager:
VprocID
A VprocID is a number that identifies the vproc to Teradata Database. VprocIDs are in the
range of 0 through 16383, or 0 through 30719, depending on the system. When specifying
VprocIDs, decimal or hexadecimal numbers can be used. Hexadecimal numbers must
include a trailing X or x, for example, 3FFx and 77FFx.
VprocList
A VprocList is defined as a list of one or more vproc identifiers or a range of vproc
identifiers in the following format:
,
vprocid
vprocid
TO
vprocid
1102A251
Examples:
0 1 2 3
0, 1, 16382 to 16383
0 to 10, 16381, 16382
0 to 1, 27FEx
VprocState
VprocState defines the PDE system state of a vproc. VprocStates include the following:
FATAL
This VprocState indicates a serious problem with a vproc or its associated storage. For
example, if a vproc crashes repeatedly, or if there are corrupt tables that require a Table
Rebuild, a vproc will be set to the FATAL state.
When a TVS vproc is in FATAL state, all AMPs associated with it will be put into
FATAL state at the next database restart.
Note: The AMP or PE partitions are not started for a vproc in this state.
334
Utilities

FATAL**
This VprocState indicates an AMP cannot access its storage.
Note: The AMP partition is not started for a vproc in this state.
NEWPROC
This VprocState applies only to AMP and PE vprocs.
This VprocState indicates that either a new vproc is being added to the database
configuration or an existing vproc is being deleted.
A vproc with status NEWPROC is a member of the PDE message group but is not a
member of the operational Teradata Database message group. For more information,
contact the Teradata Support Center.
NONODE
This VprocState indicates that the physical hardware required to run this vproc is not
available. This state is not accepted as an argument to the SET command, although this
state might appear in the Vproc Status Table produced by the STATUS command.
Note: The AMP or PE partitions are not started for a vproc in this state.
NULL
This VprocState is undefined. It is not accepted as an argument to the SET command,
although this state might appear in the Vproc Status Table produced by the STATUS
command.
ONLINE
This VprocState indicates that the vproc is fully operational and actively participating
with the Teradata Database.
A vproc with status ONLINE is a member of both the PDE and Teradata Database
message group. For more information, contact the Teradata Support Center.
OFFLINE
Generally, this VprocState indicates vprocs that are not fully operational and have been
forced down by the Teradata Database or system administrator.
For example, if a node fails during system startup, its associated storage clique may be
prevented from starting, and the AMPs that use that storage will be set to OFFLINE.
This behavior is governed by settings in the Control GDO Editor (ctl) utility.
A vproc with status OFFLINE is a member of the PDE message group but is not a
member of the operational Teradata Database message group. For more information,
contact the Teradata Support Center.
When a TVS vproc is in OFFLINE state, all AMPs associated with it will be put into
FATAL state at the next database restart.
UTILITY
This vproc state applies only to AMP vprocs.
This VprocState is transitional and is used by database recovery and the RECONFIG
and Table Rebuild utilities to indicate that a previously OFFLINE/FATAL/NEWPROC
is interacting with the online Teradata Database.
Utilities
335

This vproc is a member of the PDE message groups but not a member of the
operational Teradata Database message groups.
ConfigStatus
The database component of Teradata Database maintains its own internal version of the
status of AMP and PE vprocs. That status is called the Teradata Database Logical
Configuration Status, and represented in the output of the Vproc Manager STATUS
command as a column named ConfigStatus. Vproc Manager cannot modify the
ConfigStatus of a vproc.
ConfigStatus can be any of the following:
Note: To clearly differentiate between VprocStates and ConfigStatus, VprocStates here are
written in all UPPERCASE letters, and ConfigStatus is written in mixed-case letters.
Online
The vproc is fully operational.
This usually coincides with the ONLINE VprocState.
Down
The vproc has been forced down.
This ConfigStatus usually coincides the OFFLINE, UTILITY, FATAL, and NONODE
VprocStates.
Catchup
This ConfigStatus for this vproc was previously Down, and it is being recovered in the
background. If System RestartKind is COLDWAIT, the ConfigStatus of this vproc will
become Online after recovery is complete.
This ConfigStatus usually coincides with the UTILITY VprocState.
Hold
The ConfigStatus for this vproc was previously Catchup or Down, and its data is in the
process of being recovered. The ConfigStatus of this vproc will become Online after
recovery is complete.
This ConfigStatus usually coincides with the ONLINE VprocState.
NewReady
This is either a newly added vproc or one that has been removed from the database
logical configuration.
This ConfigStatus usually coincides with the UTILITY or NEWPROC VprocState.
NewDown
This is a newly added vproc and has been forced down.
This ConfigStatus usually coincides with the NEWPROC VprocState.
Null
This vproc is not yet in the Teradata Database Logical Configuration. Recently, the
vproc might have been added to the PDE Physical Configuration or deleted from the
Teradata Database Logical Configuration, and database startup has not run yet.
Startup will note that this vproc does not appear in its configuration map and will
336
Utilities

change its ConfigStatus to NewReady. Null usually coincides with the NEWPROC
VprocState.
The following table illustrates each ConfigStatus and the VprocState that usually coincides
with each ConfigStatus.
VprocState
ConfigStatus
ONLINE
Online, Hold
OFFLINE
FATAL
NONODE
Down
UTILITY
Catchup, Down, NewReady
NEWPROC
NewReady, NewDown, Null
For an understanding of how vprocs behave during Teradata Database startup, see
VprocState/ConfigStatus Transitions During Teradata Database Startup on page 338.
RestartKind
RestartKind specifies the type of system restart to perform during the next database
restart. Types of valid restarts include:
COLD
A full restart, but transaction recovery will be deferred.
COLDWAIT
A full restart, but database startup will be held up until transaction recovery is
complete.
Utilities
337
338
VprocState/ConfigStatus Transitions During Teradata Database Startup

The following is the Key for the table that follows:
= is read as remains.
-> is read as becomes.
For a definition of RcvJrnl, see STATUS on page 354.

VprocState (prior to Teradata Database startup)
CONFIG-STATUS (prior to
Teradata Database
startup)
OFFLINE/FATAL/
NONODE
ONLINE
UTILITY (AMP vprocs only)
NEWPROC
Online
VprocState = ONLINE
ConfigStatus = Online
VprocState -> ONLINE

VprocState = OFFLINE/
FATAL/NONODE
ConfigStatus -> Down
This combination is
inconsistent and will be
transitioned as follows:
Hold
(AMP vprocs only)
VprocState = ONLINE
ConfigStatus -> Online
This combination is inconsistent

and will be transitioned as follows:
FATAL/NONODE
This combination is
VProcState -> ONLINE
Catchup
(AMP vprocs only)

and will be transitioned as
follows:
IF (NOT RcvJrnl) THEN
VprocState -> OFFLINE
ELSE IF (RestartKind =
COLDWAIT)
THEN
VprocState = ONLINE
ELSE
VprocState -> UTILITY
ConfigStatus = Catchup
IF (NOT RcvJrnl) THEN

ELSE
IF (RestartKind = COLDWAIT)
THEN
ELSE
VprocState = UTILITY
FATAL/NONODE
This combination is
Utilities
Utilities
VprocState (prior to Teradata Database startup)

CONFIG-STATUS (prior to
Teradata Database
startup)
ONLINE
UTILITY (AMP vprocs only)
Down
IF (VprocType = PE)
This vproc is currently undergoing

an ALL TABLES REBUILD using
the Table Rebuild utility program,
therefore:
ConfigStatus = Down
Table Rebuild will set to it
ONLINE/Online when it is
complete.
FATAL/NONODE
ConfigStatus = Down
This combination is
transitioned as follows
ConfigStatus = Down
IF RECONFIG THEN
ConfigStatus = NewReady
ELSE
and will be transitioned
as follows:
FATAL/NONODE
ConfigStatus -> NewDown
VprocState = NEWPROC
FATAL/NONODE
ConfigStatus = NewDown
VprocState = NEWPROC
ConfigStatus -> NewReady
THEN
VprocState = ONLINE
ELSE IF (VprocType = AMP)
THEN IF (NOT RECONFIG)
AND RcvJrnl
OFFLINE/FATAL/
NONODE
NEWPROC
THEN
ConfigStatus -> Catchup
ELSE IF (NOT RcvJrnl) THEN
ConfigStatus = Down
NewReady

follows:
VProcState -> NEWPROC
VprocState -> NEWPROC

NewDown

follows:

and will be transitioned as follows:
VprocState --> OFFLINE
339

Vproc Manager Command Syntax
Vproc Manager Command Syntax

Vproc Manager presents a command-line environment that allows the entry of Vproc
Manager commands, which have the following general syntax:
command
options
arguments
;
GS07A003
Syntax element
Can be a
options/arguments
VprocID, VprocState, or RestartKind.

Note: All arguments can be abbreviated to their shortest unique string.
Note: The Parallel Database Extensions (PDE) must be running in order for Vproc Manager
to run. Teradata Database does not need to be running.
Vproc Manager Commands

The following table briefly describes the function of each Vproc Manager command. The
commands are described in more detail in the sections that follow.
340
Command
Description
BOOT
Initializes and starts the database partitions of an AMP. This

command applies only to AMP vprocs with a VprocState of FATAL
and a ConfigStatus of Down.
HELP
Provides general help for Vproc Manager or detailed help if you

specify an option.
INITVDISK
Initializes the Teradata Database File System on the virtual storage

associated with a specific AMP. This command applies only to AMPs
that are in the FATAL or NEWPROC state.
QUIT
Causes Vproc Manager to exit.
RESTART
Forces a database restart.
SET RESTART
Sets the restart type to use during the next system restart.
SET vproclist
Defines the new state of a vproc or new states for a list of vprocs.
STATUS DBS
Reports the status of the Teradata Database.
STATUS DBS Orderby CN
Reports the status of Online and NotOnline Teradata Database AMP

vprocs ordered by cluster number.
Utilities

Vproc Manager Commands
Utilities
Command
Description
STATUS DBS Orderby HN
Reports the status of Online and NotOnline Teradata Database PE

vprocs ordered by host number.
STATUS DBS Orderby

Nodeid
Reports the status of Online and NotOnline Teradata Database

vprocs ordered by node id.
STATUS NOTONLINE
Reports the status row for vprocs and nodes that are not fully online.
STATUS ONLINE
Reports the status row for vprocs and nodes that are online.
STATUS PDE
Reports the status of the PDE.
STATUS RESTART
Reports the current system RestartKind.
STATUS SYSSTATE
Reports the current system state and the System Debugger, if it is

attached.
STATUS vproclist
Reports the vproc status table row for the specified vproc or vprocs.
STATUS
Reports the Teradata Database Status Table and the PDE Status
Table.
341

BOOT
BOOT
Purpose
The BOOT command initialize and start the database partitions of an AMP. This command
applies only to AMPs with VprocState of FATAL and ConfigStatus of Down.
Syntax
BOOT
vprocid
GS07B005
Syntax element
Description
vprocid
The number that identifies the vproc to be rebooted. For a description of

vprocIDs, see Definitions of Terms Used in Vproc Manager on page 334.
Usage Notes
The boot process asynchronously invokes the AMP startup task on the specified AMP. Vproc
Manager considers the boot complete after it has invoked the AMP startup task successfully in
the startup partition on the specified AMP. The AMP startup task itself determines whether
the system and the AMP are in the appropriate state for a boot and logs messages to the system
console.
Use this command in conjunction with Table Rebuild when you need to rebuild all tables on
an AMP. For more information, see Chapter 29: Table Rebuild (rebuild).
Example
The following example shows how to boot up AMP vproc #63.
Enter a command, Help, or Quit:
BOOT 63
WARNING: This command will destroy all user and dictionary data of vproc
63s vdisk. To recover from this may require an ALL TABLES REBUILD!
Are you sure you want to do this (Y/N)?
Y
The AMP startup task has been successfully invoked of vproc 63.
Please refer to the system console for additional information.
342
Utilities

CLEARMVAMP
CLEARMVAMP
Purpose
Clears the status of AMPs that were previously configured as target AMPs in move AMP
reconfig operation. Do not use this command during move or add AMP reconfig operations.
Running this command will cause the File System to be reinitialized on the target AMPs of the
last reconfiguration MOVE AMP operation.
Syntax
CLEARMVAMP
CL
1102A252
Utilities
343

HELP
HELP
Purpose
The HELP command provides general help for Vproc Manager or detailed help if you specify
an option.
Syntax
HELP
H
ALL
keyword
GS07B006
Syntax element
Description
ALL
Used to display the help text of the Vproc Manager in its entirety.
keyword
Either a command name, a VprocState, or a RestartKind.
Usage Notes
If no command option is specified, a brief introduction to Vproc Manager is displayed,
followed by instructions on how to receive additional help.
Example 1
help
The Vproc Manager utility program provides a means to manage/manipulate
various vproc attributes.The general command syntax is:
<COMMAND> <Options> <Arguments> [;]
That is, a command followed by its specific options and/or arguments and
terminated with an optional semi-colon. All commands, options, and
arguments may be abbreviated to the shortest unique string.
Valid commands are:
BOOT, HELP, INITVDISK, QUIT, RESTART, SET, and STATUS.
Enter "HELP <CommandName>" for detailed information on each command or
type "HELP ALL" for the help text in its entirety.
344
Utilities

HELP
Example 2
help quit
QUIT
o This command causes the VprocManager utility program
to exit.
Example 3
help cold
COLD and COLDWAIT are used to specify the types of restart to perform,
either as an option in the RESTART command or as a value supplied in the
SET RESTART command. They are defined as follows:
o COLD - A full restart, but transaction recovery will be deferred.
o COLDWAIT - A full restart, but DBS startup will be held up until
transaction recovery is complete.
Utilities
345

INITVDISK
INITVDISK
Purpose
The INITVDISK command initializes the Teradata Database File System on the storage
associated with a specific AMP, also known as the AMPs vdisk. This applies only to AMPs
with a VprocState of FATAL or NEWPROC. The state of the specified AMP remains
unchanged.
Syntax
INITVDISK
vprocid
GS07B007
Syntax element
Description
vprocid
The number that identifies the vproc to be initialized. For a description of

vprocIDs, see Definitions of Terms Used in Vproc Manager on page 334.
Usage Notes
The initialization is accomplished by invoking File System Initialization Task in the
Application partition on the specified AMP. InitVdisk will abort if the Application partition is
in use already.
The initialization of the storage associated with a NEWPROC AMP is only relevant prior to
database startup.
Database startup implicitly initializes the storage for NEWPROC AMPs (if necessary).
Example
INITVDISK 3
WARNING: This command will destroy all user and dictionary data of vproc
3s vdisk. To recover from this may require an ALL TABLES REBUILD!
Are you sure you want to do this (Y/N)?
Y
Starting the file system initialization task on vproc 3.
The Vdisk associated with vproc 3 has been initialized.
346
Utilities

QUIT
QUIT
Purpose
The QUIT command causes Vproc Manager to exit.
Syntax
QUIT
Q
1102A216
Utilities
347

RESTART
RESTART
Purpose
The RESTART command forces a database restart.
Syntax
RESTART
R
TPA
NODUMP
DUMP=
restartkind
restart comment
YES
NO
1102A153
Syntax element
Description
TPA
This option has no effect on the RESTART command. It is included for

compatibility.
NODUMP
A system dump will not occur. This is the default.
DUMP
Specifies whether a dump will occur:

YES means a dump will occur.
NO means no dump will occur.
restartkind
Specifies the type of restart to perform:

COLD indicates a full restart, including the database (DBS) component,
however, transaction recovery will be deferred.
COLDWAIT indicates a full restart, however, DBS startup will be
deferred until transaction recovery is complete.
If you do not specify a RestartKind, the current system setting is used.
restart comment
States the reason for the restart.
Usage Notes
The RESTART command implicitly causes Vproc Manager to exit.
To set the desired RestartKind or Restart Type, see or SET RESTART on page 350 or the
RESTART TPA command in the Database Window (DBW) chapter of Utilities Volume 1.
To view the current system setting for RestartKind or Restart Type, see STATUS DBS on
page 357.
For additional information on stopping and restarting the system, see Database
Administration.
348
Utilities

RESTART
Example 1
The following example shows how to perform a COLD restart and specifies a reason why.
RESTART COLD This is a test.
The system will
Dump
RestartKind
Reason
be restarted:
: NO
: COLD
: This is a test.
Example 2
The following example shows how to restart using the current system setting for RestartKind
and specifies a reason why.
RESTART DUMP = YES This is a test.
The system will
Dump
RestartKind
Reason
be restarted:
: YES
: COLD
: This is yet another test.
Example 3
The following example shows how to restart using the current system setting for RestartKind
and the default restart comment.
RESTART
The system will
DUMP
RestartKind
Reason
Utilities
be restarted:
: NO
: COLD
: System restarted by VprocManager.
349

SET RESTART
SET RESTART
Purpose
The SET RESTART command sets the restart type to use during the next restart of the system.
Syntax
SET
RESTART
restartkind
=
Syntax element
Description
restartkind
Specifies the type of restart to perform:
GS07B011
COLD indicates a full restart, including the database (DBS) component,

however, transaction recovery will be deferred.
COLDWAIT indicates a full restart, however, DBS startup will be deferred
until transaction recovery is complete.
If you do not specify a RestartKind, the current system setting is used.
For additional information, see RESTART on page 348.
Usage Notes
This function does not force an immediate database restart. For additional information, see
Stopping and Restarting the System in Database Administration.
Example
Enter a command, HELP or QUIT:
SET RESTART = COLDWAIT
The System RestartKind has been set to COLDWAIT.
350
Utilities

SET vproclist
SET vproclist
Purpose
The SET vproclist command sets the new state of a vproc or the new states for a list of vprocs.
Syntax
,
SET
S
vproclist
/V
vprocstate
=
1102A191
Syntax element
Description
/V
Specifies the verbose mode of output, which includes more information.
vproclist
A list of one or more vproc identifier numbers. For examples, see Definitions
of Terms Used in Vproc Manager on page 334.
vprocstate
Indicates the PDE system state of a vproc, such as ONLINE, OFFLINE, or

FATAL.
Usage Notes
The following table relates the changes to vproc states occurring before and after Teradata
Database restart.
Utilities
If the VprocState of an AMP or PE is changed

from
After the next system restart, the VprocState/

ConfigStatus is
either OFFLINE or FATAL to ONLINE,

and its ConfigStatus is Down
ONLINE/Online. The AMP will be in UTILITY/

Catchup state during recovery, immediately prior to
ONLINE/Online.
either OFFLINE or FATAL to NEWPROC,

and its ConfigStatus is NewDown
NEWPROC/NewReady.
ONLINE to either OFFLINE or FATAL
OFFLINE/Down or FATAL/Down.
NEWPROC to either OFFLINE or FATAL
OFFLINE/NewDown or FATAL/NewDown.
351

SET vproclist
Note: Any allowed VprocState transition becomes effective immediately. With the exception
of AMPs being recovered using the Recovery Control Task, no changes are made to the
ConfigStatus, the static message group, or whether the vproc is the Control AMP. These
changes are deferred until the next system restart.
The SET VprocList command is governed by the allowable VprocState transitions shown in the
following table.
Desired VprocState
Current
VprocState
NONODE
OFFLINE
ONLINE
NEWPROC
FATAL
UTILITY
NONODE
No change.
Not allowed.
Not allowed.
Not allowed.
Not allowed.
Not allowed.
OFFLINE
Not
allowed.
No change.
Allowed.
Allowed
Allowed.
Not allowed.
If ConfigStatus = Down,
initiate
recovery.
if ConfigStatus =
NewDown.
Not
allowed.
Allowed.
No change.
Not allowed.
Allowed.
Not allowed.
Not
allowed.
Allowed.
Not
allowed.
Allowed.
Not
allowed.
Not allowed.
ONLINE
NEWPROC
FATAL
UTILITY
352
ConfigStatus
will be Down
after system
restart.
ConfigStatus will
be Down after
system restart.
Not allowed.
No change.
ConfigStatus
will be
NewDown after
system restart.
Allowed.
Not allowed.
Config Status will

be NewDown after
system restart.
Allowed.
If ConfigStatus
= Down,
initiate
recovery.
Not allowed.
Allowed if
ConfigStatus
= NewDown.
No change.
Not allowed.
Not allowed.
Not allowed.
No change.
Utilities

SET vproclist
Example 1
This example shows how to take vprocs 0 and 1 offline.
set /v 0 to 1 offline
Vproc 0s VprocState has been set from ONLINE to OFFLINE.
NOTE: Vproc 0 will be forced down (i.e., its ConfigStatus will be Down)
after the next system restart.
Vproc 1s VprocState has been set from ONLINE to OFFLINE.
NOTE: Vproc 1 will be forced down (i.e., its ConfigStatus will be Down)
after the next system restart.
Example 2
This example shows how to take vproc 1 online.
set /v 1 online
Vproc 1s VprocState has been set from OFFLINE to ONLINE.
NOTE: Vproc 1 will begin recovery in the background via
the Recovery Control Task and will assume a
VprocState/ConfigStatus of UTILITY/Catchup.
Please refer to the System Console for
additional status information.
Utilities
353

STATUS
STATUS
Purpose
The STATUS command, without any options reports the status of the database and the PDE.
Syntax
STATUS
ST
GS07B012
Usage Notes
The following applies to systems with the total number of virtual processors up to 1024.
The Database Status Table includes a status row for each vproc that is defined on the system.
When applicable, a footnote will follow the Database Status Table, indicating which AMP
vproc has been selected as the Control AMP.
The following table shows the columns of the vproc status row.
354
Column
Description
Vproc Number
Uniquely identifies the vproc across the entire system.
Rel. Vproc#
Represents the number of the vproc relative to the Node upon which the vproc
resides.
Node ID
Identifies the node upon which the vproc resides. The Node ID is formatted as
CCC-MM, where CCC denotes the cabinet number, and MM denotes the
module number.
Movable
This indicates whether the vproc can be migrated to another node in its
defined clique if its primary node fails.
Crash Count
Represents the number of times the vproc has crashed. The count increments
with every attempted system restart. When the system restart succeeds, Crash
Count is reset to 0 for all vprocs.
Vproc State
Represents the current PDE system state of the vproc.
Config Status
Displays the Teradata Database Logical Configuration Map Status of the vproc.
Config Type
Represents the Teradata Database Logical Configuration Map Type of a vproc.
Utilities

STATUS
Column
Description
Cluster/Host No.
Displays the Cluster Number if the Config Type is AMP or displays the Host
No. if the Config Type is PE.
Cluster is the cluster number for the AMP as defined using the Configuration
Utility. The valid range of cluster numbers is 0 to 8099.
Host No. is the host number that was assigned to the PE using the
Configuration Utility. The valid range of host numbers is 1 to 1023.
RcvJrnl/Host Type
Displays the RcvJrnl (that is, Recovery Journaling) flag if the Config Type is
AMP or displays the Host Type if the Config Type is PE.
The RcvJrnl flag is Off if an AMP is down and the other AMPs in its cluster are
not to create a recovery journal for the down AMP.
Note: If you anticipate that an AMP will be down for a long period of time,
then Teradata recommends an offline rebuild of all tables on the AMP (after
the RcvJrnl flag has been set to Off).
The Host Type is the host type for the PE as defined using the Configuration
Utility and is one of the following:
TVS Vproc
IBM
COP
ATT3B
BULLHN
OS1100
For AMP vprocs, displays the associated TVS vproc.
The PDE Status Table includes a status row for each node that is defined on the system. The
columns of the node status row are shown in the following table.
Utilities
Column
Description
Node ID
The Node ID as defined using the Parallel Upgrade Tool (PUT). For more
information, see the Parallel Upgrade Tool (PUT) Reference. The Node ID is
formatted as CCC-MM, where CCC denotes the cabinet number and MM
denotes the module number.
Node State
The current state of the node, which is either ONLINE, DOWN, or STANDBY.
Clique Number
The clique number for the node as defined using the Parallel Upgrade Tool
(PUT). For more information, see the Parallel Upgrade Tool (PUT) Reference.
CPUs
The number of CPUs on the node.
Memory (MB)
The total memory size in megabytes for the node (rounded up to the nearest
integer).
CHANs
The number of channels attached to the node.
LANs
The number of LANs attached to the node.
355

STATUS
Column
Description
AMPs
The number of AMPs running on the node.
Node Name
The network name for the node.
When applicable, a footnote will follow the PDE Status Table, indicating which node is
defined as a Non-TPA Node (for STANDBY node).
Example
status
SYSTEM NAME: teradata-1
07/12/21 19:13:42
-------------------------
Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Config Cluster/ Host TVS
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----0*
1
1-01 Yes
0
ONLINE Online
AMP
0
On
10238
1
2
1-01 Yes
0
ONLINE Online
AMP
0
On
10237
8192
4
1-01 No
0
ONLINE N/A
GTW
1
COP
N/A
10237
5
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
10238
6
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
16383
3
1-01 Yes
0
ONLINE Online
PE
1
COP
N/A
-------------------------------------------------------------------------------*
DBS Control AMP
PDE PHYSICAL CONFIGURATION
-------------------------Node
Node
Clique
Memory
ID
State
Number CPUs (MB) CHANs LANs AMPs Node Name
------- ------- ------ ---- ------ ----- ---- ---- --------------------------1-01 ONLINE
0
2
2047
0
1
2 localhost
------------------------------------------------------------------------------
PDE State: RUN/STARTED
356
Utilities

STATUS DBS
STATUS DBS
Purpose
The STATUS DBS command reports the status of the Teradata Database.
Syntax
STATUS
DBS
ST
GS07A027
Usage Notes
The STATUS DBS command returns a status report for the Database Status Table only. The
Database Status Table includes a status row for each vproc that is defined on the system. When
applicable, a footnote will follow the Database Status Table, indicating which AMP vproc has
been selected as the Control AMP.
Column
Description
Vproc Number
Rel. Vproc#
Represents the number of the vproc number relative to the Node upon which
the vproc resides.
Node ID
Identifies the Node upon which the vproc resides. The Node ID is formatted as
CCC-MM, where CCC denotes the cabinet number and MM denotes the
module number.
Movable
This indicates whether the vproc can be migrated to another node in its defined
clique if its primary node fails.
Crash Count
Represents the number of times the vproc has crashed.
Vproc State
Represents the current PDE system state of a vproc.
Config Status
Displays the Teradata Database Logical Configuration Map Status of a vproc.
Config Type
Cluster/Host No.
Utilities
357

STATUS DBS
Column
Description
RcvJrnl/Host
Type
The RcvJrnl flag is Off, if an AMP is down and the other AMPs in its cluster are
then Teradata recommends an offline rebuild of all tables on the AMP (after the
RcvJrnl flag has been set to Off).
Utility and is one of the following: IBM, COP, ATT3B, BULLHN, or OS1100.
TVS Vproc
Example
status dbs
07/12/21 15:55:47
-------------------------
Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----0*
1
1-01 Yes
0
ONLINE Online
AMP
0
On
10238
1
2
1-01 Yes
0
ONLINE Online
AMP
0
On
10237
8192
4
1-01 No
0
ONLINE N/A
GTW
1
COP
N/A
10237
5
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
10238
6
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
16383
3
1-01 Yes
0
ONLINE Online
PE
1
COP
N/A
-------------------------------------------------------------------------------*
DBS Control AMP
358
Utilities

STATUS DBS ORDERBY CN
Purpose
The STATUS DBS Orderby CN command reports the status of Online and NotOnline
Teradata Database AMP vprocs ordered by cluster number.
Syntax
STATUS
DBS
ST
ORDERBY CN
GS07A026
Usage Notes
The STATUS DBS Orderby CN command returns the Online and NotOnline Teradata
Database AMP vprocs ordered by the cluster status tables only. When applicable, a footnote
will follow the Database Status Table, indicating which AMP vproc has been selected as the
Control AMP.
The following table shows the columns of the ONLINE vproc status row.
Column
Description
Vproc-Ids Range
Uniquely identifies the Vproc-id or Vproc-ids individually or in a range across

the entire system. Vproc numbers in the range of 0 through 30719 are used
exclusively by the Teradata Database configuration. Vproc numbers greater
than 30719 are used exclusively by PDE and are not included in the Teradata
Database logical configuration.
Crash Count
CN No.
Displays the cluster number for the AMP as defined using the Configuration
The following table shows the columns of the NOTONLINE vproc status row.
Utilities
Column
Description
Vproc-Ids Range

Crash Count
359

Column
Description
Vproc State
Represents the current PDE system state of a vproc if the state is not online.
Config Status
Cluster Number
Displays the cluster number for the AMP as defined using the Configuration
Example
360
Utilities

STATUS DBS ORDERBY HN
Purpose
The STATUS DBS Orderby HN command reports the status of Online and NotOnline
Teradata Database PE vprocs ordered by host number.
Syntax
STATUS
DBS
ST
ORDERBY HN
GS07A025
Usage Notes
The STATUS DBS ORDERBY HN command is used to return the Online and NotOnline
Teradata Database PE vprocs ordered by the host status tables only.
Utilities
Column
Description
Vproc-Ids Range

Crash Count
Moveable
Indicates whether the PE vproc can be migrated to another node in its defined
Host Number
Displays the host number that was assigned to the PE using the Configuration
Utility. The valid range of host numbers is 1 to 1023.
Host Type
Displays the host type for the PE as defined using the Configuration Utility and
is one of the following: IBM, COP, ATT3B, BULLHN, or OS1100.
361

Column
Description
Vproc-Ids Range

Crash Count
Moveable
Indicates whether the PE vproc can be migrated to another node in its defined
Vproc State
Config Status
Host Number
Displays the host number that was assigned to the PE using the Configuration
Host Type
Displays the host type for the PE as defined using the Configuration Utility and
is one of the following: IBM, COP, ATT3B, BULLHN, or OS1100.
Example
status dbs orderby hn
SYSTEM NAME: nirvana
08/12/21 15:29:09
-------------------------ONLINE PE vprocs ordered by Host No. - Vproc-Ids
Crash
Host
Host
Range
Count
Moveable
Number
Type
------------------- ------ ----------------16368-16382
0
Yes
52
COP
16345-16351
0
No
282
IBM
16353, 16357, 16359,
0
No
286
IBM
.
.
.
16362, 16366
------------------------------------------------------------------------------NOTONLINE PE vprocs ordered by Host No. - Vproc-Ids
Crash
Vproc
Config
Host
Host
Range
Count
Moveable
State
Status
Number
Type
----------------------------- -----------------------16383
0
Yes
NONODE
Down
52
COP
16344
0
No
NONODE
Down
282
IBM
16355, 16367
0
No
NONODE
Down
286
IBM
16352, 16364
0
No
NONODE
Down
289
IBM
------------------------------------------------------------------------------DBS State: Logons are enabled - Users are logged on
362
Utilities

STATUS DBS ORDERBY NODEID
Purpose
The STATUS DBS Orderby Nodeid command reports the status of Online and NotOnline
Teradata Database vprocs ordered by node id.
Syntax
STATUS
DBS
ST
ORDERBY NODEID
GS07A024
Usage Notes
The STATUS DBS Orderby Nodeid command is used to return the Online and NotOnline
Teradata Database vprocs ordered by the node id status tables only. When applicable, a
footnote will follow the Database Status Table, indicating which AMP vproc has been selected
as the Control AMP.
Column
Description
Vproc-Ids Range

Crash Count
Node Ids
module number.
Utilities
Column
Description
Vproc-Ids Range

363

Column
Description
Crash Count
Vproc State
Config Status
Node Ids
module number.
Example
status dbs orderby nodeid
SYSTEM NAME: nirvana
07/12/21 15:29:09
ONLINE AMP and PE vprocs ordered by Node ID - Vproc-Ids

Crash
Node
Vproc-Ids
Crash
Node
Range
Count
Ids
Range
Count
Ids
------------------------------------------------3, 7, 11, 15
0
9-00
16366
0
9-00
2, 6, 10, 14
0
9-02
1, 5, 9, 13
0
10-00
16362-16363, 16381
0
10-00
0*, 4, 8, 12
0
10-02
.
.
.
16369
0
17-00
16368
0
17-02
--------------------------------------------------------------------------NOTONLINE AMP and PE vprocs orderby Node ID - Vproc-Ids
Crash
Vproc
Config
Node
Range
Count
State
Status
IDs
------------------------------------- ------16367, 16383
0
NONODE
Down
9-00
16364
0
NONODE
Down
9-02
16355
0
NONODE
Down
11-02
17
0
UTILITY CATCHUP
11-02
21
0
NEWPROC NewReady
11-02
.
.
.
.
63
0
FATAL**
Down
15
-------------------------------------------------------------------------*
DBS Control AMP
** The storage associated with the AMP has an I/O error or can't be opened.
Vproc can be brought online after fixing the I/O error and restarting
the database.
364
Utilities

STATUS NOTONLINE
STATUS NOTONLINE
Purpose
The STATUS NOTONLINE command reports the status row for vprocs and nodes that are
not fully online.
Syntax
STATUS
ST
NOTONLINE
NO
GS07B017
Usage Notes
Column
Description
Vproc Number
Rel. Vproc#
resides.
Node ID
module number.
Can Move
Crash Count
Vproc State
Config Status
Config Type
Cluster/Host No.
Utilities
365

STATUS NOTONLINE
Column
Description
RcvJrnl/Host Type
TVS Vproc
IBM
COP
ATT3B
BULLHN
OS1100
Example
Enter a command, HELP, or QUIT:
status notonline
09/09/14 14:38:04
-------------------------
Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----5
6
2-14 Yes
0
OFFLINE Online
AMP
2
On
10237
--------------------------------------------------------------------------------
366
Utilities

STATUS ONLINE
STATUS ONLINE
Purpose
The STATUS ONLINE command reports the online status.
Syntax
STATUS
ST
ONLINE
ON
GS07B016
Usage Notes
If all vprocs are online, the STATUS ONLINE command simply reports that.
If one or more vprocs are offline, the STATUS ONLINE command displays a STATUS row for
each of the vprocs that is online. When applicable, a footnote will follow the Database Status
Table, indicating which AMP vproc has been selected as the Control AMP.
Utilities
Column
Description
Vproc Number
Rel. Vproc#
resides.
Node ID
module number.
Can Move
This indicates whether the vproc can be migrated to another node in its defined
Crash Count
Vproc State
Config Status
Config Type
367

STATUS ONLINE
Column
Description
Cluster/Host
No.
Displays the Cluster Number if the Config Type is AMP or displays the Host No.
if the Config Type is PE.
Host No. is the host number that was assigned to the PE using the Configuration
RcvJrnl/Host
Type
Displays the RcvJrnl (that is, Recovery Journaling) flag if the Config Type is AMP
or displays the Host Type if the Config Type is PE.
Note: If you anticipate that an AMP will be down for a long period of time, then
Teradata recommends an offline rebuild of all tables on the AMP (after the
RcvJrnl flag has been set to Off).
TVS Vproc
IBM
COP
ATT3B
BULLHN
OS1100
The PDE Status Table includes a status row for each node that is defined on the system. The
columns of the node status row are shown in the following table.
368
Column
Description
Node ID
Node State
Clique Number
CPUs
Memory (MB)
integer).
CHANs
LANs
AMPs
Utilities

STATUS ONLINE
Column
Description
Node Name
When applicable, a footnote will follow the PDE Status Table, indicating which node is
defined as a Non-TPA Node (for STANDBY node).
Example 1
If all vprocs are online, the STATUS ONLINE command simply reports that.
status online
SYSTEM NAME: ztest
08/01/09 20:08:13
All DBS vprocs are fully online.

All PDE nodes are fully online.
Example 2
If any vproc is offline, the STATUS ONLINE command returns the status row for all vprocs
and nodes that are fully online. In the following example, only the AMP identified with vproc
number zero is ONLINE.
status online
07/12/21 19:13:42
-------------------------
Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----0*
1
1-01 Yes
0
ONLINE Online
AMP
0
On
10238
8192
4
1-01 No
0
ONLINE N/A
GTW
1
COP
N/A
10237
5
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
10238
6
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
16383
3
1-01 Yes
0
ONLINE Online
PE
1
COP
N/A
-------------------------------------------------------------------------------*
DBS Control AMP
-------------------------Node
Node
Clique
Memory
ID
State
------- ------- ------ ---- ------ ----- ---- ---- --------------------------1-01 ONLINE
0
2
2047
0
1
2 localhost
-----------------------------------------------------------------------------PDE State: RUN/STARTED
Utilities
369

STATUS PDE
STATUS PDE
Purpose
The STATUS PDE command reports the status of the PDE.
Syntax
STATUS
PDE
ST
GS07A023
Usage Notes
The STATUS PDE command returns the PDE Status Table only. The PDE Status Table
includes a status row for each node that is defined on the system. The columns of the node
status row are shown in the following table.
370
Column
Description
Node ID
Node State
Clique Number
CPUs
Memory (MB)
integer).
CHANs
LANs
AMPs
Node Name
Utilities

STATUS PDE
Example
SYSTEM NAME: default_vconfig
03/01/21 13:35:49

-------------------------Node
Node
Clique
Memory
ID
State
------- ------- ------ ---- ------ ----- ---- ---- -------------------------------4-06 ONLINE
0
4
2043
0
1
4 puthod1_bynet
4-07 ONLINE
0
2
2043
0
1
4 puthod2_bynet
4-08 ONLINE
0
2
2043
0
1
4 puthod3_bynet
-----------------------------------------------------------------------------Node
Node
Clique
Memory
ID
State
------- ------- ------ ---- ------ ----- ---- ---- -------------------------------4-09^ STANDBY
0
0
0
0
1
4 puthod4_bynet
-----------------------------------------------------------------------------^ Non-TPA Node
Utilities
371

STATUS RESTART
STATUS RESTART
Purpose
The STATUS RESTART command reports the current system RestartKind setting.
Syntax
STATUS
ST
RESTART
R
GS07B019
Example
status restart
DBS RestartKind = COLD.
372
Utilities

STATUS SYSSTATE
STATUS SYSSTATE
Purpose
The STATUS SYSSTATE command reports the current system state and the System Debugger,
if it is attached.
Syntax
STATUS
ST
SYSSTATE
SYSS
GS07B018
Example
status sysstate
Utilities
373

STATUS vproclist
STATUS vproclist
Purpose
The STATUS vproclist command reports the vproc status table row for the specified vproc or
vprocs and allow a maximum of 30720 or 16384 vprocs, depending on the system, to be
specified. This command does not display a vproc status row for undefined vprocs.
Syntax
STATUS
vproclist
ST
GS07B015
Syntax element
Description
vproclist
A list of one or more vproc identifiers. For examples, see Definitions of

Terms Used in Vproc Manager on page 334.
Usage Notes
374
Column
Description
Vproc Number
Rel. Vproc#
Represents the number of the vproc number relative to the Node upon which
the vproc resides.
Node ID
module number.
Movable
Crash Count
Vproc State
Represents the current PDE system state of a vproc.
Config Status
Config Type
Utilities

STATUS vproclist
Column
Description
Cluster/Host No.
RcvJrnl/Host Type
The RcvJrnl flag is Off, if an AMP is down and the other AMPs in its cluster are
Utility and is one of the following: IBM, COP, ATT3B, BULLHN, or OS1100.
TVS Vproc
Utilities
375

STATUS vproclist
Example 1
status 1, 2, 8192 to 16383
07/12/21 15:55:47
-------------------------
Rcv
Jrnl/
Vproc Rel.
Node
Can
Crash Vproc
Config
Number Vproc# ID
Move Count State
Status
Type
Host No. Type Vproc
------ ------ ------ ----- ----- ------- -------- ------ -------- ----- ----0*
1
1-01 Yes
0
ONLINE Online
AMP
0
On
10238
1
2
1-01 Yes
0
ONLINE Online
AMP
0
On
10237
8192
4
1-01 No
0
ONLINE N/A
GTW
1
COP
N/A
10237
5
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
10238
6
1-01 Yes
0
ONLINE N/A
TVS
0
N/A
N/A
16383
3
1-01 Yes
0
ONLINE Online
PE
1
COP
N/A
-------------------------------------------------------------------------------*
DBS Control AMP
Example 2
The following is an example status display for undefined vprocs.
status 100 to 300
95/11/29 11:12:16
STATUS command ignored: None of the specified Vprocs are defined.
376
Utilities
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
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 3 digits.
Word
Keywords and variables.

UPPERCASE LETTERS represent a keyword.
Syntax diagrams show all keywords in uppercase, unless operating system
restrictions require them to be in lowercase.
lowercase letters represent a keyword that you must type in lowercase, such as a
Linux command.
Mixed Case letters represent exceptions to uppercase and lowercase rules. The
exceptions are noted in the syntax explanation.
lowercase italic letters represent a variable such as a column or table name.
Substitute the variable with a proper value.
lowercase bold letters represent an excerpt from the diagram. The excerpt is
defined immediately following the diagram that contains it.
UNDERLINED LETTERS represent the default value.
This applies to both uppercase and lowercase words.
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 with a keyword, 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.
Utilities
377
Appendix A: How to Read Syntax Diagrams

Continuation Links
Paths that are too long for one line use continuation links. Continuation links are circled
letters indicating the beginning and end of a link:
A
FE0CA002
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and
continue reading.
Required Entries
Required entries appear on the main path:
SHOW
FE0CA003
If you can choose from more than one entry, the choices appear vertically, in a stack. The first
entry appears on the main path:
SHOW
CONTROLS
VERSIONS
FE0CA005
Optional Entries
You may choose to include or disregard optional entries. Optional entries appear below the
main path:
SHOW
CONTROLS
378
FE0CA004
Utilities

If you can optionally choose from more than one entry, all the choices appear below the main
path:
READ
SHARE
JC01A010
ACCESS
Some commands and statements treat one of the optional choices as a default value. This
value is UNDERLINED. It is presumed to be selected if you type the command or statement
without specifying one of the options.
Strings
String literals appear in apostrophes:
'msgtext '
JC01A004
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:
,
,
(
cname
3
4
)
JC01B012
Utilities
379

Read loops from right to left.

The following conventions apply to loops:
IF...
THEN...
there is a maximum number of

entries allowed
the number appears in a circle on the return path.
there is a minimum number of

entries required
the number appears in a square on the return path.
a separator character is required

between entries
the character appears on the return path.
In the example, you may type cname a maximum of 4 times.
In the example, you must type at least three groups of column

names.
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

around entries
the beginning and end characters appear outside the return

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 each side of the break. The
name for the excerpted piece appears between the terminators in boldface type.
The boldface excerpt name and the excerpted phrase appears immediately after the main
diagram. The excerpted phrase starts and ends with a plain horizontal line:
LOCKING
excerpt
A
HAVING
con
excerpt
where_cond
,
cname
,
col_pos
JC01A014
380
Utilities

Multiple Legitimate Phrases

In a syntax diagram, it is possible for any number of phrases to be legitimate:
dbname
DATABASE
tname
TABLE
vname
VIEW
JC01A016
In this example, any of the following phrases are legitimate:
dbname
DATABASE dbname
tname
TABLE tname
vname
VIEW vname
Sample Syntax Diagram

,
CREATE VIEW
viewname
AS
A
LOCKING
cname
CV
LOCK
ACCESS
dbname
A
DATABASE
tname
FOR
SHARE
IN
READ
TABLE
WRITE
EXCLUSIVE
vname
VIEW
EXCL
,
SEL
B
MODE
expr
,
FROM
qual_cond
tname
.aname
C
HAVING cond
;
qual_cond
,
WHERE cond
GROUP BY
cname
,
col_pos
JC01A018
Utilities
381

Diagram Identifier
The alphanumeric string that appears in the lower right corner of every diagram is an internal
identifier used to catalog the diagram. The text never refers to this string.
382
Utilities
APPENDIX B
Starting the Utilities
Teradata Database offers several user interfaces from which the utilities may be started and
run.
Interface
Description
Database Window
(DBW)
DBW is a graphical tool that connects to the Teradata Database console

subsystem (CNS). CNS provides console services to utility programs that
operate on the database level of Teradata Database. Console utilities
should be started from DBW.
Note: Operators must be members of the tdtrusted user group to run
console utilities, or must be logged in as root. Non-tdtrused users may be
explicitly granted access to the console using the CNS GRANT
command. For more information on the GRANT command, see the
Database Window chapter of Utilities.
For low bandwith connections, command-line interfaces to CNS are
available, such as cnsterm and cnstool. Information on cnsterm and
cnstool is available in man page online documentation.
A subset of the console utilities can be run from the Remote Console
portlet of Teradata Viewpoint. For more information, see the Teradata
Viewpoint User Guide.
Linux command line
Utilities that run directly from the command line are primarily those
that operate on the PDE level of Teradata Database.

(HUTCNS)
HUTCNS runs a subset of utilities from a channel-attached host

terminal. It runs only on the z/OS operating system.
Note: Not all utilities support all available user interfaces. For a listing of supported user
interfaces for each utility, see the documentation for each utility.
When started, some utilities present their own interactive command-line or graphical user
interfaces. These utilities allow browsing and entering information, and continue running
until they are explicitly stopped. Many utilities that present their own command environment
are stopped by entering the QUIT command.
Some utilities that run from DBW can be stopped by issuing the stop window_number
command from the DBW Supervisor window, where window_number is the numeric
identifier of the DBW application window in which the utility is running. For more
information on DBW, see Utilities Volume 1.
Utilities
383
Appendix B: Starting the Utilities

Starting Utilities from Database Window

Database Window (DBW) is an X client program that requires an X server to be running on
the local machine. DBW supports standard X Windows display forwarding. To ensure that the
graphical user interface displays properly, you can use the standard -display option to
specify the host name or IP address of the local machine.
To start a utility from Database Window:
1
If not already done, set up the Teradata Database environment by typing:

tdatcmd
at the Linux command line.

2
Open DBW from the Linux command line by typing:

xdbw display displayspec &
where displayspec is the name or IP address of the local machine, followed by a colon and
the server number, typically 0 or 0.0. For example:
xdbw -display myworkstation.mycompany.com:0.0 &
or
xdbw -display 192.0.2.24:0.0 &
The DBW main window opens.
384
Click the Supvr button to open the Supervisor (supv) window.
Utilities

Under Enter a command type:

start utilityname [options]
where utilityname is the name of the utility, and options can include any of the available
command-line options and arguments of that utility. utilityname is not case-sensitive.
The following message appears:
Started 'utilityname' in window x
where x is the number of one of the four available application windows DBW provides.
Each utility started runs in one of the four application windows. The title bar of the
application window and the corresponding button in the DBW main window change to
reflect the name of the running utility. When the utility stops running, the application
window and main window button revert to the default text title (that is, Appl1, Appl2, and
so forth).
Note: Up to four utilities can be run concurrently in DBW. The message All Interactive
Partitions are busy!! indicates that all four application windows are occupied. In this case,
one of the four running utilities must be quit before another can be started.
For more information on DBW and CNS commands, and on options that are available
with the START command, see Utilities Volume 1.
Utilities
385

Starting Utilities from the Linux Command Line
Starting Utilities from the Linux Command Line

To start a utility from the Linux command line:
1
If not already done, set up the Teradata Database environment by typing:

tdatcmd
at the Linux command line.

2
On the command line type:

utilityname [options]
where utilityname is the name of the utility, and options can include any of the available
command-line options and arguments of that utility.
Note: Operators must be members of the tdtrusted user group or have root access to run
console utilities. Other users can run the utilities only if they have been explicitly granted
access using the GRANT command.
Starting Utilities from HUTCNS

HUTCNS is a console interface that runs a subset of the Teradata Database utilities from a
channel-attached host terminal. These utilities include: Query Session, Query Configuration,
Showlocks, and Recovery Manager. HUTCNS is available only on z/OS terminals.
To start a utility:
1
On the command line type:

HUTCNS
The HUTCNS screen appears:

****
****
**** Data Base Computer
*
*
*
* *
*
*
****
*
Program: DBS Console Interface
*
*
*
* *
****
****
****
Enter logon string as TDPID/UserID,Password
TDPID is the Teradata Database system name. After you enter the required information,
the terminal displays the following:
Enter the Utility to execute
- SESsionStatus
- CONfiguration
- LOCKsDisplay
- RCVmanager
First 3 characters are acceptable
Type the name or abbreviation of the specified utility.

The screen for the specified utility appears.
Note: To exit the utility from HUTCNS, type END or QUIT.
386
Utilities
Glossary
2PC
Two-phase Commit
AG
Allocation Group
AMP
Access Module Processor
ARC
Archive/Recovery
AWT
AMP Worker Task
BLK Block
BLC
Block-Level Compression
BTEQ Basic Teradata Query

CI Cylinder Index
CICS
Customer Information Control System
CID
Cylinder Index Descriptor
CNS
Teradata Database Console Subsystem
CJ
Changed Row Journal
COP Communications Processor

DB
Data Block
DBD Data Block Descriptor

DBQL
DBS
Database Query Log

Database System or Database Software
DBW
Database Window
DDL
Data Definition Language
DEM
Database Extensibility Mechanism
DML
Data Manipulation Language
Dwin Display Window
Utilities
FIB
File Information Block
FSE
Free Sector Entry
FSG
File Segment Subsystem
387
Glossary
FSP Free Space Percent

GDO Globally Distributed Object
GLOP Global and persistent
GUI
Graphical User Interface
hex
Hexadecimal
HG
Host Group
HN Host Number
HOST
HUT
Teradata Database Host Software

Host Utility
HUTCNS
IMS
Information management system
LAN
Local area network
LOB Large Object

LSN Log Sequence Number
LSNSPEC
LSN Specification
LUN
Logical Unit
MDS
Metadata Services
MI Master Index
MLOAD
MultiLoad
MPP Massively Parallel Processing

NoPI
No Primary Index
NPPI
Nonpartitioned Primary Index
NTA Nested Top Action

NUSI Non-Unique Secondary Index
OCES
OJ
Optimizer Cost Estimation Subsystem
Ordered System Change Journal
OLTP Online Transaction Processing
388
PCT
Partitioning Cache Threshold
PDE
Parallel Database Extensions
Utilities
Glossary
PE
Parsing Engine
PG
Performance Group
PID
PJ
Process ID
Permanent Journal
PMPC
PPI
Performance Monitor and Production Control
Partitioned Primary Index
PROC
Procedural Management Subsystem
PUT
Parallel Upgrade Tool
QIC
Quarter-inch Cartridge
RBM
Resolver Base Module
ResUsage Resource Usage

RFC
Reservation Flow Control
RJ Recovery Journal
RP
Resource Partition
RSG
Relay Services Gateway
RSS
Resource Sampling Subsystem
SDF
Source Specification for Data Formatting
SECTORSPEC Sector Specification

SMP
Symmetric MultiProcessing
stdin
Standard Input
stdout
Standard Output
supv Supervisor Window

Supvr
Supervisor Icon
sysinit
System Initializer
SysView
TBBLC
Temperature-Based Block-Level Compression
TCHN
Teradata Channel
TDGSS
Teradata Database Generic Security Services
TDP
Utilities
System View
Teradata Director Program
389
Glossary
Teradata ASM
TGTW
TJ
Teradata Active System Management
Teradata Gateway
Transient Journal
TLE
Target Level Emulation
TPA
Trusted Parallel Application
TZ
Time Zone
UDF
User-Defined Function
UDM
User-Defined Method
UDT
User-Defined Type
UNFES
Unfree Sector
UPI Unique Primary Index

USI
Unique Secondary Index
UTC
Universal Coordinated Time
vdisk
Virtual Disk
vproc
Virtual Processor
WAL
Write Ahead Logging
WCI
WAL Cylinder Index
WCID WAL Cylinder Index Descriptor

WD Workload Definition
WDB
WDBD
WLC
WLSN
WMI
390
WAL Data Block

WAL Data Block Descriptor
Workload Class
WAL Log Sequence Number
WAL Master Index
Utilities
Index
Allocation Groups, Priority Scheduler utility 93

determining relative weight 95
expedite attribute 94
parameters 94
Performance Groups and 94
query response time 97
resource accounting 97
weight 95
AMP Worker Tasks (AWTs)
limits 98
reservation for expedited allocation groups 100
reservations 98
reserving 100
resource allocation 99
EXIT command
Vproc Manager utility 347
External commands, Modify MPP List utility 77
B
BLOCKERS command, Lock Display utility 24
BOOT command, Vproc Manager utility 342
C
CANCEL ROLLBACK ON TABLE command, Recovery
Manager utility 203
CLEARMVAMP command, Vproc Manager utility 343
COMMIT command,
Two-Phase Commit Console utility 319
Configuration Display. See Query Configuration utility
Crashdumps, TPA Reset utility 313
D
Database Utilities overview 17
DB command, Lock Display utility 27
Dbschk 230
see also Resource Check Tools
DEFAULT PRIORITY command,
Recovery Manager utility 208
Delimiters in object names, Lock Logger utility 50
DISPLAY command, Modify MPP List utility 71
DISPLAY command, Two-Phase Commit Console utility 320
Dumplocklog utility. See Lock Logger utility
dumplocklogb, Lock Logger utility 51
Dumps, TPA Reset utility 313
Utilities
H
HELP command
Lock Display utility 30
Host utility (HUT) locks. See Show Locks utility
I
In-doubt transactions, identifying and resolving 321
INITVDISK command, Vproc Manager utility 346
L
LIST CANCEL ROLLBACK TABLES command,
LIST command, Modify MPP List utility 72
LIST LOCKS command, Recovery Manager utility 211
LIST ROLLBACK TABLES command,
LIST STATUS command, Recovery Manager utility 215
LIST STATUS proc-id command,
command overview 23
explicit and implicit lock modes 22
hash mark notation 23, 42
lock modes 22
lock request status 23
lock-mode contention 22
overview 21
starting 21, 253, 257
Lock Display utility commands
BLOCKERS 24
DB 27
HELP 30
QUIT 31
ROWHASH 32
ROWRANGE 35
TABLE 37
TRAN 39
391
Index
Lock log report

delimiters in object names 50
determining the blocked user 58
hexadecimal names support 50
hexadecimal syntax 50
inserting rows 55
non-standard names support 50
producing 51
quotation marks in object names 50
reducing lock log table size 55
reducing table size 53
Lock log tables, Lock Logger utility 46
Lock Logger utility 43
buffers 43
creating lock log tables 46
delimiters in object names 50
determining the blocked user 58
dumplocklogb 51
hexadecimal names in lock log report 50
inserting rows into log tables 55
lock log tables 46
lock logger table requirements 45
messages 64
non-standard names in lock log report 50
overview 43
producing a lock log report 51
quotation marks in object names 50
running from scripts 51
starting 43
Lock modes, Lock Display utility 22
Locks
explicit and implicit modes 22
mode contention 22
modes 22
request status 23
Locks, Table Rebuild utility 258
Lokdisp. See Lock Display utility
M
Messages, Locking Logger utility 64
Milestone limits, Priority Scheduler utility
resource usage 90
time-of-day 91
Modify MPP List utility
commands 69
editing a user-specified mpplist 69
editing the default mpplist 68
overview 67
starting 67
Modify MPP List utility commands 69
DISPLAY 71
external commands 77
LIST 72
392
OFF id_list 73
ON id_list 74
QUIT 75
WRITE 76
Modmpplist. see Modify MPP List utility
N
Node panic, TPA Reset utility 313
Nodecheck 236
log file 237
O
OFF id_list command, Modify MPP List utility 73
ON id_list command, Modify MPP List utility 74
P
Panic, TPA Reset utility 313
Performance Groups, Priority Scheduler utility 85
naming 86
recording PG name in a user record 87
Performance Periods, Priority Scheduler utility 88
components 89
resource usage 90
time-of-day limit 91
types and limits 89
Priority Scheduler utility (SLES 10 only) 79
active time 98
Allocation Group weight 95
Allocation Groups 93
commands, see schmon utility options
components 80
limiting CPU usage 98
overview 80
Performance Group names 86
Performance Groups 85
Performance Period types and limits 89
Performance Periods 88
resource accounting 97
Resource Partitions 83
resource usage milestone limits 90
Scheduling Sets 97, 98
schmon utility 103
see also schmon 79
using 82
Q
Qryconfig. See Query Configuration utility
Qrysessn. See Query Session utility
Query Configuration utility 155
about 155
Utilities
Index
ALL option 156

AMPs option (Online and Offline) 158
display options 155
getting help 159
options 156
overview 155
PE option (Online and Offline) 158
physical processors 155
Processors option (Online and Offline) 157
starting 155
vprocs 155
Query Session utility 161
ABORTING state 166
ACTIVE state 166
Archive sessions state displays 170
BLOCKED state 167
child sessions 162
DELAYED state 168
displays 163
FastExport sessions state displays 181
FastLoad sessions state displays 173
IDLE state 168
INDOUBT PARSING state 168
INDOUBT state 168
MultiLoad sessions state displays 176
overview 161
parent sessions 162
PARSING state 168
QTDELAYED state 169
QUIESCED ABORT state 169
QUIESCED ABORT WITH LOGOFF state 169
QUIESCED INDOUBT state 169
Recovery sessions state displays 170
RESPONSE state 169
SESDELAYED state 170
session state display 164
session states 161
starting 161
state information displays 165
stored procedures and 165
Teradata Index Wizard 165
QUIT command
Modify MPP List utility 75
Quotation marks in object names, Lock Logger utility 50
R
Rcvmanager. See Recovery Manager utility
REBUILD AMP command, Table Rebuild utility 261
REBUILD AMP FALLBACK TABLES command, Table
Rebuild utility 267
Utilities
REBUILD PRIORITY command,

Rebuild. See Table Rebuild utility
reconfig. See Reconfiguration utility
Reconfiguration Estimator utility 185
overview 185
Reconfiguration utility 187
overview 187
Recovery journal, Recovery Manager utility 194
assigning priority levels 190
automatic restarts 199
cancelling rollbacks on tables 200
changed row journal recovery record 195
changing priority levels for rollback 191
deferred down AMP recovery 196
deferred transaction recovery 193
down AMP recovery 193
messages 198
multiple recovery sessions 192
offline catchup mode 196
online catchup mode 197
online transaction recovery 191
ordered system change journal recovery record 195
overview 189
priority levels 190
recovering down AMPs 194
recovery journal 194
restarting 199
retrieving tables 202
starting 189
transaction recovery sequence 191
user-initiated restarts 199
Recovery Manager utility commands
CANCEL ROLLBACK ON TABLE 203
DEFAULT PRIORITY 208
HELP 209
LIST CANCEL ROLLBACK TABLES 210
LIST LOCKS 211
LIST ROLLBACK TABLES 212
LIST STATUS 215
LIST STATUS proc-id 220
QUIT 224
REBUILD PRIORITY 225
RECOVERY PRIORITY 225
ROLLBACK SESSION...PERFORMANCE GROUP 226
RECOVERY PRIORITY command,
Resource accounting, Priority Scheduler utility 97
active time 98
limiting system CPU usage 98
Resource Check Tools
creating a syscheckrc file 250
dbschk 230
393
Index
nodecheck 236
nodecheck log file 237
overview 229
starting 229
syscheck 243
syscheckrc file 248
Resource Partitions, Priority Scheduler utility
determining relative weight 84
limiting CPU usage 84
parameters 83
recommended set up 85
Resource Partitions,
Priority Scheduler utility (SLES 10 only) 83
Resource Partitions,Priority Scheduler utility 83
RESTART command, Vproc Manager utility 348
RESTART REBUILD command, Table Rebuild utility 270
Restart Teradata Database, reset Teradata Database 313
ROLLBACK command,
command, Recovery Manager utility 226
Rollbacks, cancelling with Recovery Manager utility 200
ROWHASH command, Lock Display utility 32
ROWRANGE command, Lock Display utility 35
S
Scheduling Sets, Priority Scheduler utility 97, 98
Schmon (SLES 10 only)
starting 103
see also Priority Scheduler utility
Schmon options (SLES 10 only)
-a 105
-b 110
-c 115
-d 117
-f 120
-h 121
-l 122
-M 130
-m 123
-p 140
-s 145
-t 150
-w 152
SDF file 279
elements 280
Session States. See Query Session utility
SET RESTART command, Vproc Manager utility 350
SET vproclist command, Vproc Manager utility 351
Show Locks utility 253
host utility locks 253
HUT lock conflicts 256
HUT locks 253
394
interpreting the display 254

Show locks utility
overview 253
Showlocks. See Show Locks utility
STATUS command
STATUS DBS command, Vproc Manager utility 357
STATUS DBS ORDERBY CN command,
STATUS DBS ORDERBY HN command,
STATUS DBS ORDERBY NODEID command,
STATUS NOTONLINE command,
STATUS ONLINE command, Vproc Manager utility 367
STATUS PDE command, Vproc Manager utility 370
STATUS RESTART command, Vproc Manager utility 372
STATUS SYSSTATE command, Vproc Manager utility 373
STATUS vproclist command, Vproc Manager utility 374
Syntax diagrams, how to read 377
Syscheck 243
creating a syscheckrc file 250
syscheckrc file 248
System CPU usage, limiting 98
T
TABLE command, Lock Display utility 37
Table Rebuild utility 257
error messages 259
help 260
locking during rebuilds 258
no-fallback tables 257
overview 257
rebuilding tables 265
restarting 270
running in the background 265, 268
Table Rebuild utility commands
overview 259
REBUILD AMP 261
REBUILD AMP FALLBACK TABLES 267
RESTART REBUILD 270
Task List utility 271
overview 271
starting 271
syntax 271
Tdlocaledef. See Teradata Locale Definition utility
Tdnstat. See Teradata Network Statistics utility
Tdntune. See Teradata Network Tuner utility
Teradata Database
resetting and restarting 313
Teradata Database Utilities overview 17
Utilities
Index
Teradata Locale Definition utility 277

overview 277
SDF file 279
starting 277
Teradata Network Statistics utility
overview 297
starting 297
using 298
Teradata Network Tuner utility 309
overview 309
starting 309
syntax 309
Time-of-day milestone limits, Priority Scheduler utility 91
TPA Reset utility 313
starting 313
syntax 313
Tpareset. See TPA Reset utility
Tpccons. See Two-Phase Commit Console utility
TRAN command, Lock Display utility 39
Tsklist. See Task List utility
in-doubt transactions, identifying and resolving 321
overview 317
starting 317
Two-Phase Commit Console utility commands
command overview 318
COMMIT 319
DISPLAY 320
ROLLBACK 319
U
Update DBC utility
overview 323
starting 324
Update DBS utility 323
Update Space utility 325
overview 325
starting 325
syntax 326
Updatedbc. See Update DBC utility
Updatespace. See Update Space utility
Utilities
alphabetical listing 17
running on different platforms 383
starting on z/OS 386
starting 329
when to run 330
Verify_pdisks. See Verify Pdisks utility
command syntax 340
ConfigStatus transitions 338
definitions of terms 334
overview 333
starting 334
VprocState transitions 338
Vproc Manager utility commands
BOOT 342
CLEARMVAMP 343
EXIT 347
HELP 344
INITVDISK 346
overview 340
QUIT 347
RESTART 348
SET RESTART 350
SET vproclist 351
STATUS 354
STATUS DBS 357
STATUS DBS ORDERBY CN 359
STATUS DBS ORDERBY HN 361
STATUS DBS ORDERBY NODEID 363
STATUS NOTONLINE 365
STATUS ONLINE 367
STATUS PDE 370
STATUS RESTART 372
STATUS SYSSTATE 373
STATUS vproclist 374
Vprocmanager. See Vproc Manager utility
W
WRITE command, Modify MPP List utility 76
Z
z/OS, starting utilities on 386
V
Vconfig GDO 331
Vconfig text file (vconfig.txt, vconfig.out) 331
Verify Pdisks utility 329
examples 331
overview 329
Utilities
395
Index
396
Utilities

1102 V 2 RR

Uploaded by

Copyright:

Available Formats

1102 V 2 RR

Uploaded by

Document Information

Original Title

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

1102 V 2 RR

Uploaded by

Copyright:

Available Formats

Teradata Database

Utilities: Volume 2 (L-Z)

Utilities Volume 1 includes utilities A-K.

Utilities Volume 2 includes utilities L-Z.

Supported Software Releases and Operating

SUSE Linux Enterprise Server (SLES)10

Resource Usage Macros and Tables

Platform-dependent Teradata Database Installation/Upgrade/Migration documents

Teradata Archive/Recovery Utility Reference

Teradata FastExport Reference

Teradata FastLoad Reference

Teradata MultiLoad Reference

Teradata Parallel Data Pump Reference

Changes to This Book

Teradata Database 14.0

Updated Syntax Diagram Conventions to mention mixed-case words in

Removed obsolete references to PDE state TPA.

Teradata Database 14.0

Renamed from Locking Logger utility.

Schmon is available only on SUSE Linux Enterprise Server (SLES) 10

Moved chapter to Support Utilities manual.

Moved chapter to Support Utilities manual.

Updated SQL in exampe of running Table Rebuild in the background.

Renamed from Locale Definition Utility.

Renamed from TDN Statistics

Renamed from TDN Tuner

Added new PSPOOL option.

Added description of CLEARMVAMP command.

Use the Teradata Information Products Publishing Library site

Download a documentation CD-ROM:

The Teradata home page provides links to numerous sources of

Teradata Customer Education designs, develops and delivers

Use Teradata @ Your Service to access Orange Books, technical

Teradata Developer Exchange provides articles on using

Teradata Database Optional Features

Teradata Row Level Security

Temporal Table Support

Teradata Virtual Storage (VS)

Chapter 17: Teradata Database Utilities . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 18: Lock Display (lokdisp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 19: Lock Logger (dumplocklog) . . . . . . . . . . . . . . . . . . . . . . . . .43

Chapter 20: Modify MPP List (modmpplist) . . . . . . . . . . . . . . . . . . . . . .67

Chapter 21: Priority Scheduler (schmon)

Chapter 22: Query Configuration (qryconfig) . . . . . . . . . . . . . . . . . 155

Chapter 23: Query Session (qrysessn) . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapter 24: Reconfiguration Estimator

Chapter 25: Reconfiguration Utility (reconfig) . . . . . . . . . . . . . . . . .187

Chapter 26: Recovery Manager (rcvmanager) . . . . . . . . . . . . . . . . .189

Chapter 27: Resource Check Tools

Chapter 28: Show Locks (showlocks) . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Chapter 29: Table Rebuild (rebuild) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Chapter 30: Task List (tsklist) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Chapter 31: Teradata Locale Definition Utility

Chapter 32: Teradata Network Statistics (tdnstat) . . . . . . . . . . .297

Chapter 33: Teradata Network Tuner (tdntune) . . . . . . . . . . . . . . .309

Chapter 34: TPA Reset (tpareset) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313

Chapter 35: Two-Phase Commit Console (tpccons) . . . . . . . . . . .317

Chapter 36: Update DBC (updatedbc) . . . . . . . . . . . . . . . . . . . . . . . . . . . .323

Chapter 37: Update Space (updatespace) . . . . . . . . . . . . . . . . . . . . . . .325