Teradata Database. Utilities: Volume 2 (L-Z)

Transcription

1 Teradata Database Utilities: Volume 2 (L-Z) Release 15.0 B K March 2014

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, Active Data Warehousing, Active Enterprise Intelligence, Applications-Within, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale, MyCommerce, SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, Teradata ServiceConnect, 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. Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Apple, Mac, and OS X all are registered trademarks of Apple Inc. Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access, Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum Support are servicemarks of Axeda Corporation. Data Domain, 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. Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other countries. 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 Dell 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. Quantum and the Quantum logo are trademarks of Quantum Corporation, registered in the U.S.A. and other countries. Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license. 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 teradata-books@lists.teradata.com. Any comments or materials (collectively referred to as "Feedback") sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright by Teradata. All Rights Reserved.

3 Preface Purpose This book, Utilities, describes the utility programs that support Teradata Database and consists of two manuals: Utilities: Volume 1 (A-K) includes utilities with names beginning with letters A through K. Utilities: Volume 2 (L-Z), this book, includes utilities with names beginning 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 3

4 Preface Supported Software Releases and Operating Systems Supported Software Releases and Operating Systems This book supports Teradata Database Teradata Database 15.0 is supported on: SUSE Linux Enterprise Server10 SP3 SUSE Linux Enterprise Server 11 SP1 Teradata Database client applications support other operating systems. Prerequisites You should be familiar with using the Database Window (DBW), which is required to run some of these utilities. For more information, see Appendix B: Starting the 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 15.0 March 2014 Lock Display ROWHASH command name has been changed to ROWKEY, and a Partition parameter has been added, which must be set to zero. 4 Utilities

5 Preface Additional Information Release Utility Description Teradata Database 15.0 March 2014 (continued) Table Rebuild If an AMP is online while all data or primary data is being rebuilt, an exclusive lock is placed on the database or table. If an AMP is online while fallback data is being rebuilt, a write lock is placed on the database or table. If the AMP is offline, a read lock is used in all cases. Additional Information URL Description 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. tays.teradata.com/ developer.teradata.com/ The Teradata home page provides links to numerous sources of information about Teradata. Links include: Executive reports, white papers, case studies of customer experiences with Teradata, and thought leadership Technical information, solutions, and expert advice Press releases, mentions and media resources Teradata Customer Education delivers training that builds skills and capabilities for our customers, enabling them to maximize their Teradata investment. Use Your Service to access Orange Books, technical alerts, and knowledge repositories, view and join forums, and download software patches. 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 teradatabooks@lists.teradata.com. Utilities 5

6 Preface Product Safety Information Product Safety Information This document might contain several types of product safety statements: Safety Information Type Notice Caution WARNING Description Indicates a situation which, if not avoided, could result in damage to property, such as to equipment or data, but not related to personal injury. Indicates a hazardous situation which, if not avoided, could result in minor or moderate personal injury. Indicates a hazardous situation which, if not avoided, could result in death or serious personal injury. Examples: Notice: Caution: Improper use of the Reconfiguration utility can result in data loss. A drive tray chassis weighs approximately 28.6 kg (63 lb). Do not attempt to remove or install the chassis until all the drives and modules have been removed. WARNING: Risk of electrical shock! Always remove power to the power supply/fan module before servicing it. Teradata Database Optional Features This book may include descriptions of the following optional Teradata Database features and products: Teradata Columnar Teradata Row Level Security Teradata SQL-H Teradata Temporal Teradata Virtual Storage (VS) Unity Source Link 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. 6 Utilities

7 Table of Contents Preface Purpose Audience Supported Software Releases and Operating Systems Prerequisites Changes to This Book Additional Information Product Safety Information Teradata Database Optional Features Chapter 16: Teradata Database Utilities Alphabetical Listing of Utilities Chapter 17: Lock Display (lokdisp) Lock Modes Lock Display Utility Commands BLOCKERS DB HELP QUIT ROWKEY ROWRANGE TABLE TRAN Utilities 7

8 Table of Contents Chapter 18: Modify MPP List (modmpplist) Modify MPP List Commands DISPLAY LIST OFF id_list ON id_list QUIT WRITE Running External Commands Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Overview Using Priority Scheduler Resource Partitions Performance Groups Performance Periods Allocation Groups Resource Accounting AMP Worker Task (AWT) Reservations and Limits Schmon Utility (schmon) (SLES 10 only) schmon -a schmon -b schmon -c schmon -d schmon -f schmon -h schmon -l schmon -m schmon -M schmon -p schmon -s schmon -t schmon -w Utilities

9 Table of Contents Chapter 20: Query Configuration (qryconfig) About Query Configuration Query Configuration Options Chapter 21: Query Session (qrysessn) Query Session States Parent and Child Sessions Query Session Displays Session State Display State Information Displays Archive and Recovery Sessions State Displays FastLoad Sessions State Displays MultiLoad Sessions State Displays FastExport Sessions State Displays Chapter 22: Recovery Manager (rcvmanager) Prerequisites Assigning Priority Levels Online Transaction Recovery Transaction Recovery Sequence Multiple Recovery Sessions Deferred Transaction Recovery Down AMP Recovery Startup/Restart Messages Restarts Cancelling Rollback on Tables Recovery Manager Commands CANCEL ROLLBACK ON TABLE DEFAULT PRIORITY HELP LIST CANCEL ROLLBACK TABLES LIST LOCKS LIST ROLLBACK TABLES Utilities 9

10 Table of Contents LIST STATUS LIST STATUS proc-id QUIT REBUILD/RECOVERY PRIORITY ROLLBACK SESSION...PERFORMANCE GROUP Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) Resource Check Tools Utilities dbschk nodecheck syscheck Chapter 24: Show Locks (showlocks) Host Utility Locks Interpreting the Show Locks Display Conflicts Chapter 25: Table Rebuild (rebuild) Rebuilding Tables Table Rebuild Utility Commands REBUILD AMP REBUILD AMP FALLBACK TABLES RESTART REBUILD Chapter 26: Task List (tsklist) Utilities

11 Table of Contents Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Example SDF Files Chapter 28: Teradata Network Statistics (tdnstat) Chapter 29: Teradata Network Tuner (tdntune) Chapter 30: TPA Reset (tpareset) Chapter 31: Update DBC (updatedbc) Chapter 32: Update Space (updatespace) Chapter 33: Verify Pdisks (verify_pdisks) Chapter 34: Vproc Manager (vprocmanager) Definitions of Terms Used in Vproc Manager Vproc Manager Command Syntax Vproc Manager Commands BOOT CLEARMVAMP HELP INITVDISK QUIT RESTART SET RESTART Utilities 11

12 Table of Contents SET vproclist STATUS STATUS DBS STATUS DBS ORDERBY CN STATUS DBS ORDERBY HN STATUS DBS ORDERBY NODEID STATUS NOTONLINE STATUS ONLINE STATUS PDE STATUS RESTART STATUS SYSSTATE STATUS vproclist Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions Appendix B: Starting the Utilities Starting Utilities from Database Window Starting Utilities from the Linux Command Line Starting Utilities from HUTCNS Glossary Index Utilities

13 CHAPTER 16 Teradata Database Utilities This chapter lists the Teradata Database utilities that are documented in Utilities: Volume 1 (A- K), Utilities: Volume 2 (L-Z), and Support Utilities. Alphabetical Listing of Utilities Utility Abort Host (aborthost) AMP Load (ampload) AWT Monitor (awtmon) CheckTable (checktable) CNS Run (cnsrun) Configuration Utility (config) Control GDO Editor (ctl) Cufconfig Utility (cufconfig) Database Initialization Program (DIP) DBS Control (dbscontrol) Dump Unload/Load (DUL, DULTAPE) Purpose Aborts all outstanding transactions running on a failed host, until the system restarts the host. 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. 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. Checks for inconsistencies between internal data structures such as table headers, row identifiers, and secondary indexes. Allows running of database utilities from scripts. Defines AMPs, PEs, and hosts, and describes their interrelationships for Teradata Database. Note: Configuration is documented in Support Utilities. Displays the fields of the PDE Control Parameters GDO, and allows modification of the settings. Displays configuration settings for the user-defined function and external stored procedure subsystem, and allows these settings to be modified. 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. Displays the DBS Control Record fields, and allows these settings to be modified. Saves system dump tables to tape, and restores system dump tables from tape. Utilities 13

14 Chapter 16: Teradata Database Utilities Alphabetical Listing of Utilities Utility Ferret Utility (ferret) Filer Utility (filer) Gateway Control (gtwcontrol) Gateway Global (gtwglobal) Lock Display (lokdisp) Modify MPP List (modmpplist) Priority Scheduler (schmon) (SLES 10 only) Query Configuration (qryconfig) Query Session (qrysessn) Reconfiguration Utility (reconfig) Reconfiguration Estimator (reconfig_estimator) Recovery Manager (rcvmanager) Purpose 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. Finds and corrects problems within the file system. Note: Filer is documented in Support Utilities. Modifies default values in the fields of the Gateway Control Globally Distributed Object (GDO). Monitors and controls the Teradata Database workstation-connected users and their sessions. Displays a snapshot capture of all real-time database locks and their associated currently-running sessions. Allows modification of the node list file (mpplist). Creates, modifies, and monitors Teradata Database process prioritization parameters. 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. Reports the current Teradata Database configuration, including the Node, AMP, and PE identification and status. Monitors the state of selected Teradata Database sessions on selected logical host IDs. Uses the component definitions created by the Configuration Utility to establish an operational Teradata Database. Note: Reconfiguration is documented in Support Utilities. 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: Redistribution Deletion NUSI building Note: Reconfiguration Estimator is documented in Support Utilities. Displays information used to monitor progress of a Teradata Database recovery. 14 Utilities

15 Chapter 16: Teradata Database Utilities Alphabetical Listing of Utilities Utility Resource Check Tools (dbschk, nodecheck, syscheck) Show Locks (showlocks) System Initializer (sysinit) Table Rebuild (rebuild) Teradata Locale Definition Utility (tdlocaledef) Teradata Network Statistics (tdnstat) Teradata Network Tuner (tdntune) Tpareset (tpareset) Task List (tsklist) Update DBC (updatedbc) Update Space (updatespace) Verify _pdisks (verify_pdisks) Vproc Manager (vprocmanager) Purpose Identifies slow down and potential hangs of Teradata Database, and displays system statistics that help identify the cause of the problem. 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 (L-Z). 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. 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. 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. Performs GetStat/ResetStat operations and displays or clears Teradata Database Network Services statistics. 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. Resets the PDE and database components of Teradata Database. Displays information about PDE processes and their tasks. 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. Recalculates the permanent, temporary, or spool space used by a single database or by all databases in a system. Verifies that the pdisks on Teradata Database are accessible and are mapped correctly. 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. Utilities 15

16 Chapter 16: Teradata Database Utilities Alphabetical Listing of Utilities For more information on... starting the utilities utilities related to Teradata Database security Archive and Recovery, FastExport, FastLoad, MultiLoad, and TPump See... the appendix titled Starting the Utilities Security Administration the following client utility books: Teradata Archive/Recovery Utility Reference Teradata FastExport Reference Teradata FastLoad Reference Teradata MultiLoad Reference Teradata Parallel Data Pump Reference 16 Utilities

17 CHAPTER 17 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 23 and TABLE on page 33. Lock information can also be monitored and displayed using the Lock Viewer portlet in Teradata Viewpoint. For more information, see Teradata Viewpoint User Guide. 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 17

18 Chapter 17: 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 Exclusive Implicit Access X X X X X X X Implicit Read X X X X X X Implicit Write X X X X X Implicit Exclusive X X X X Access X X X X X X Read X X X X Write X X 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. 18 Utilities

19 Chapter 17: Lock Display (lokdisp) 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 BLOCKERS DB HELP QUIT ROWKEY ROWRANGE TABLE TRAN Description Identifies the blocked transactions as well as their blocker transactions. Identifies the databases that have a database-level lock request. Provides general help for the Lock Display utility. Exits lokdisp. Identifies a rowhash-level lock request. Rowhash lock information is provided also. Identifies a rowrange-level lock request. Rowrange lock information is provided also. Identifies a table-level lock request. 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 23 and TABLE on page 33. Utilities 19

20 Chapter 17: Lock Display (lokdisp) BLOCKERS BLOCKERS Purpose The BLOCKERS command identifies blocked transactions and the transactions that are blocking them. Syntax BLOCKERS B TRAN ProcId ALL Uniq1 Uniq2 LIMIT NUMBER NONE KY01A098 Syntax element... ProcId Uniq1 Uniq2 ALL LIMIT NUMBER NONE Specifies... 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. a value that is normally specified as four hexadecimal digits. This value is the second component of a transaction ID. a value that is normally specified as four hexadecimal digits. This value is the third component of a transaction ID. that all blocked transactions and their corresponding blocker transactions will be considered. ALL is the default if you do not specify a transaction ID. the number of blocker transactions to consider for a blocked transaction. the desired limiting value. 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. 20 Utilities

21 Chapter 17: Lock Display (lokdisp) 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... Number of Blocked Trans displayed Blocked Trans Blocker Trans Includes the... total number of both blocked and blocker transactions. 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. 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: Database ID Database Name Table ID Table Name RowHashS RowHashE Utilities 21

22 Chapter 17: Lock Display (lokdisp) 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: Which amp(s) do you want to request on (S=Sampline/A=all/C=cancel/Q=quit): > AMP 0 REPORTS A LOCK ENTRIES Number of Blocked Trans displayed : 1 ========================================= Blocked Trans Number of blockers displays : 1 Number of blockers exists : 1 Blocker Trans : lock mode : Exclusive lock status : Granted lock objecttype : Table lock objectid : DBID : : DBNAME : STAFF : TableID : ,0000 : TableName : EMPLOYEE : RowHashS : : RowHashE : Utilities

23 Chapter 17: Lock Display (lokdisp) DB DB Purpose The DB command identifies the databases that have a database-level lock request. Syntax DB D DBname ALL KY01A096 Syntax element... DBname ALL Specifies... the name of a database. 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... Tran Host Session Mode User Database Specifies... currently running transactions with locks being applied. the logical host ID (the origin of the transaction). the session number for the transaction. the lock mode: Access Read Write Exclusive the logon-id for whom the lock is being requested. the name of the database being locked. Utilities 23

24 Chapter 17: Lock Display (lokdisp) DB Example 1 The following example shows locks on a sampling on all AMPs for the RECBDQTAC database: >lokdisp Amp Utility / / \ --- / / / / \ \ \ \ \ Release Version 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 - The following amps are available: > 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: Host: 2049 Session: Database: RECBDQTAC 0, 1000 Mode: WR* User: DBC AMP 2 REPORTS 1 LOCK ENTRIES GRANTED LOCK REQUEST(S): Tran: Host: 2049 Session: Database: RECBDQTAC 0, 1000 Mode: WR* User: DBC 24 Utilities

25 Chapter 17: Lock Display (lokdisp) 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 - The following amps are available: 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: B8 Host: 7169 Session: 0, 1010 Mode: WR* User:?????????????????????????????? Database:?????????????????????????????? Host: 7169 Session: 0, 1010 Mode: EX* User:?????????????????????????????? Database:?????????????????????????????? Utilities 25

26 Chapter 17: Lock Display (lokdisp) HELP HELP Purpose The HELP command provides general help for Lock Display. Syntax HELP H? KY01A097 Syntax element... Help, H, or? Specifies... 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. 26 Utilities

27 Chapter 17: Lock Display (lokdisp) QUIT QUIT Purpose The QUIT command exits lokdisp. Syntax QUIT Q 1102A216 Syntax element... QUIT or Q Specifies... that lokdisp should exit. Utilities 27

28 Chapter 17: Lock Display (lokdisp) ROWKEY ROWKEY Purpose The ROWKEY command identifies a rowhash-level lock request. Syntax ROWKEY ROWK DBname.Tablename ALL TypeAndIndex, Partition RowHash1 RowHash2 Syntax element... Specifies... DBname.Tablename TypeAndIndex Partition RowHash1 RowHash2 ALL the name of a database and the name of a table separated by a required period (.). 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. a partition identifier. This must be zero. a Teradata Database system-assigned rowhash value used to acquire a rowhash lock. Normally, this value is specified in decimal notation. a Teradata Database system-assigned rowhash value used to acquire a rowhash lock. Normally, this value is specified in decimal notation. that all tables that have a rowhash-level lock applied are considered. ALL is the default if you do not specify an object name. 28 Utilities

29 Chapter 17: Lock Display (lokdisp) ROWKEY Usage Notes The following table shows the components of ROWKEY command output. Component... Tran Host Session Mode User Database Table Row Hash Specifies... currently running transactions with locks being applied. the logical host ID (origin of the transaction). the session number for the transaction. the type of lock mode: Access Read Write Exclusive the logon-id for whom the lock is being requested. the name of the database being locked. the name of the locked table. the locked row hash. Note: The rowhash lock information is provided also. Example 1 The following example shows locks on AMPs 0 and 2 on Database RECBDQTAC and Table T1. rowkey - The following amps are available: > 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: Host: 2049 Session: 0, 1000 Mode: WR User: DBC Database: RECBDQTAC Table: T1 Row Hash Lock Subtable ID: 1536 Row Hash1: 62321,15470 Utilities 29

30 Chapter 17: Lock Display (lokdisp) ROWKEY AMP 2 REPORTS 2 LOCK ENTRIES GRANTED LOCK REQUEST(S): Tran: Host: 2049 Session: 0, 1000 Mode: WR User: DBC Database: RECBDQTAC Table: T1 Row Hash Lock Subtable ID: 1024 Row Hash1: 31158,40503 Host: 2049 Session: 0, 1000 Mode: WR User: DBC Database: RECBDQTAC Table: T1 Row Hash Lock Subtable ID: 1536 Row Hash1: 59106,30941 Example 2 The following example shows two locks on AMP 0 on the primary data subtable (TypeAndIndex value of 400) of database TEMP and Table T1. rowkey TEMP.t1 400, The following amps are available: > Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/ Q=quit): 0 > AMP 0 REPORTS 2 LOCK ENTRIES Tran: Hash Locks: 1 GRANTED LOCK REQUEST(S): Host: 0 Session: 0, 0 Mode: WR User: TEMP Database: TEMP Table: T1 Row Hash Lock Subtable ID: 1024 Row Hash1: 0, 1 BLOCKED LOCK REQUEST(S): Tran: Host: 0 Session: 0, 0 Mode: WR User: TEMP Database: TEMP Table: T1 Row Hash Lock Subtable ID: 1024 Row Hash1: 0, 1# 30 Utilities

31 Chapter 17: Lock Display (lokdisp) ROWRANGE ROWRANGE Purpose The ROWRANGE command identifies a rowrange-level lock request. Syntax ROWRANGE ROWR DBname.Tablename ALL TypeAndInde x KY01A095 Syntax element... Specifies... DBname.Tablename TypeAndIndex ALL the name of a database and the name of a table separated by a required period (.). 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. 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. Component... Tran Host Session Specifies... the currently running transactions with locks being applied. the logical host ID (origin of the transaction). the session number for the transaction. Utilities 31

32 Chapter 17: Lock Display (lokdisp) ROWRANGE Component... Mode User Database Table Row Range Specifies... the type of lock mode: Access Read Write Exclusive the logon-id for whom the lock is being requested. the name of the database being locked. the name of the table being locked. 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 - The following amps are available: > 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 BLOCKED LOCK REQUEST(S): Tran: Host: 0 Session: 0, 2053 Mode: Ac User: TD Database: STAFF Table: MANAGEMENT Row Range Lock Subtable ID: 0 Row Hash1: 0, 1 Row Hash2: 0, 2 # 32 Utilities

33 Chapter 17: Lock Display (lokdisp) TABLE TABLE Purpose The TABLE command identifies a table-level lock request. Syntax TABLE TA DBname.Tablename ALL KY01A093 Syntax element... DBname.Tablename ALL Specifies... the name of a database and the name of a table separated by a required period (.). 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... Tran Host Session Mode User Specifies... the currently running transactions with locks being applied. the logical host ID (origin of the transaction). the session number for the transaction. the type of lock mode: Access Read Write Exclusive the logon-id for whom the lock is being requested. Utilities 33

34 Chapter 17: Lock Display (lokdisp) TABLE Component... Database Table Specifies... the name of the database being locked. the name of the locked table. Example 1 The following example shows the locks on AMP 0 on the database RECBDQTAC and table T1: table - The following amps are available: > 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: Host: 2049 Session: Database: RECBDQTAC 0, 1000 Mode: WR* User: DBC Table: T AMP 2 REPORTS 1 LOCK ENTRIES GRANTED LOCK REQUEST(S): Tran: Host: 2049 Session: 0, 1000 Mode: WR* User: DBC Database: RECBDQTAC 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 - The following amps are available: 0 -> Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/Q=quit): A Host: 7169 Session: 0, 1441 Mode: EX User: DBC Database: STAFF Table:?????????????????????????????? Table name is not printed. 34 Utilities

35 Chapter 17: Lock Display (lokdisp) TRAN TRAN Purpose The TRAN command identifies currently running transactions with locks being applied. Syntax TRAN TR ProcId ALL Uniq1 Uniq2 KY01A092 Syntax element... ProcId Uniq1 Uniq2 ALL Specifies... 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. a value that is normally specified as four hexadecimal digits. This value is the second component of a transaction ID. a value that is normally specified as four hexadecimal digits. This value is the third component of a transaction ID. 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 35

36 Chapter 17: Lock Display (lokdisp) 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... Tran Host Session Mode User Database Table DUMMY LOCK Specifies... the currently running transactions with locks being applied. the logical host ID (origin of the transaction). the session number for the transaction. the type of lock mode: Access Read Write Exclusive the logon-id for whom the lock is being requested. the name of the database being locked. the name of the locked table. 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 - The following amps are available: > Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/ Q=quit): a -> Please enter your selection from the list: tr all - The following amps are available: 0 1 -> Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/ Q=quit): a AMP 0 REPORTS 4 LOCK ENTRIES Utilities

37 Chapter 17: Lock Display (lokdisp) TRAN GRANTED LOCK REQUEST(S): Tran: EE0 Host: 1025 Session: 0, 1001 Mode: Ac User: DBC Database: DBC Table: DBASE Host: 1025 Session: 0, 1001 Mode: Ac User: DBC Database: DBC Table: TVM Host: 1025 Session: 0, 1001 Mode: WR User: DBC Database: RKPMED Table: STORES DUMMY LOCK Host: 1025 Session: 0, 1001 Mode: WR User: DBC Database: RKPMED Table: STORES AMP 1 REPORTS 3 LOCK ENTRIES GRANTED LOCK REQUEST(S): Tran: EE0 Host: 1025 Session: 0, 1001 Mode: Ac User: DBC Database: DBC Table: DBASE Host: 1025 Session: 0, 1001 Mode: Ac User: DBC Database: DBC Table: TVM Host: 1025 Session: 0, 1001 Mode: WR User: DBC Database: RKPMED Table: STORES < END OF OUTPUT > Utilities 37

38 Chapter 17: Lock Display (lokdisp) 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 - The following amps are available: > Which amp(s) do you want to request on (S=Sampling/A=all/C=cancel/ Q=quit): a AMP 2 REPORTS 2 LOCK ENTRIES GRANTED LOCK REQUEST(S): Tran: AACE Host: 1076 Session: 0,2013 Mode: EX User: USER1 Database: DBASE1 Table: TBL_1A Row Hash1: 31158,40503 BLOCKED LOCK REQUEST(S): Tran: AAD2 Host: 1076 Session: 0,2012 Mode: EX User: USER2 Database: DBASE1 Table: TBL_1A Row Hash1: 31158,40503# 38 Utilities

39 CHAPTER 18 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. For general information on starting the utilities from different interfaces, see Appendix B: 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 39

40 Chapter 18: 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 48. 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 1:pdetnt6_bynet 2:pdetnt7_bynet 3:pdetnt8_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. (Buffer has been Modified since last read) 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 (Buffer has been Modified since last read) 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 <anon> <anon> D:\TEMP\2\mpplist pdetnt5_bynet:1924: send completed: 485 bytes received (1 files/0 directories) pdetnt6_bynet:2933: send completed: 485 bytes received (1 files/0 directories) pdetnt7_bynet:3862: send completed: 485 bytes received (1 files/0 directories) 40 Utilities

41 Chapter 18: Modify MPP List (modmpplist) Modify MPP List Commands pdetnt8_bynet:4256: send completed: 485 bytes received (1 files/0 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 user s mpplist, mylist... 0:pdetnt5_bynet 1:pdetnt6_bynet 2:pdetnt7_bynet 3:pdetnt8_bynet all 4 nodes are online. mpp> off 2 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. (Buffer has been Modified since last read) 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 Modify MPP List Commands The following table lists the commands available from within the modmpplist session (that is, from the mpp> prompt). Command DISPLAY Description Outputs the current mpplist buffer as it would appear in file format to the STDOUT file. Utilities 41

42 Chapter 18: Modify MPP List (modmpplist) Modify MPP List Commands Command LIST OFF id_list ON id_list QUIT WRITE!COMMAND Description Outputs the list of node names, their unique node IDs, and the status of nodes in the current mpplist buffer to the STDOUT file. Changes the status of the IDs in the space-separated list to NO (offline). Changes the status of the IDs in the space-separated list to YES (online). Causes modmpplist to quit the interactive session. Forces the mpplist file to be written out to all nodes in the MPP system. Runs a Teradata Database or operating system command from within the modmpplist session. The modmpplist commands are discussed in detail in the following sections. 42 Utilities

43 Chapter 18: Modify MPP List (modmpplist) 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 43

44 Chapter 18: Modify MPP List (modmpplist) 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... IndexId nodename nodestatus Specifies... an arbitrary index number starting from 0 to N-1, where N is the number of nodes in the mpplist file. the name of a node. 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 all 4 nodes are online. 44 Utilities

45 Chapter 18: Modify MPP List (modmpplist) 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... id_list Specifies... list of node IDs. Example The following example changes node 2 to offline. mpp> off 2 1 node is offline. (Buffer has been Modified since last read) Utilities 45

46 Chapter 18: Modify MPP List (modmpplist) 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... id_list Specifies... list of node IDs. Example The following example changes node 3 to online. mpp> on 3 all 4 nodes are online. 46 Utilities

47 Chapter 18: Modify MPP List (modmpplist) 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 <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 47

48 Chapter 18: Modify MPP List (modmpplist) 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. 48 Utilities

49 Chapter 18: Modify MPP List (modmpplist) Running External Commands Running External Commands Syntax To run a Teradata Database or operating system command from within a modmpplist session, preface the command with an exclamation mark (!).!COMMAND 1102A031 Syntax element... COMMAND Specifies... 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 49

50 Chapter 18: Modify MPP List (modmpplist) Running External Commands 50 Utilities

51 CHAPTER 19 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 (TASM), 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 75. 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 51

52 Chapter 19: 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 1:M Performance Group 1:M Performance Period Milestone Limit Allocation Group Milestone Type 1:1 1:M = one to many 1:1 = one to one Allocation Group Type Weight 1102E421 The following table briefly summarizes the components of Priority Scheduler. 52 Utilities

53 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 53

54 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 55 Performance Groups on page 57 Performance Periods on page 60 Allocation Groups on page 65 To configure Priority Scheduler, see Schmon Utility (schmon) (SLES 10 only) on page 75. 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: 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. 54 Utilities

55 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 57 Allocation Groups on page 65 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. Parameter ID Resource Partition Name Weight Description An integer from 0 through 4 that identifies the Resource Partition. Priority Scheduler provides resource partition 0 as the default partition. A unique name for the Resource Partition. The name can contain no more than 16 characters. 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. Utilities 55

56 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Resource Partitions Parameter Limit Description 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 To determine the relative weight of each Resource Partition, do the following: 1 Add the individual respective weights of the active Resource Partitions ( ) for a sum of 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 effect on the scheduling strategy defined by other Priority Scheduler parameters, and does not apply to PE-only nodes. The relative weights of Allocation Groups and Resource Partitions are observed. 56 Utilities

57 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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. 2 Assign user work to other Resource Partitions. 3 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 internal work and tools 1 60 tactical queries. These are short, highly-tuned queries that facilitate decision-making in a time-sensitive environment 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 (TASM), 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 60. For more information on Allocation Groups, see Allocation Groups on page 65. 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, see schmon -p on page 112. Utilities 57

58 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Resource Partition ID Performance Period Type Performance Periods The name of the Performance Group that allows it to be assigned to a session. For more information, see Performance Group Names on page 58. An integer from 0 through 4 that identifies the Resource Partition owning the Performance Group. For more information, see Resource Partitions on page 55. 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 61. 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 Utilities

59 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Performance Groups Default Performance Group Default Weight L 5 M 10 H 20 R 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 user s 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 59

60 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Performance Periods IF... the logon command includes a Performance Group name matching one of the PGs assigned to the user the logon command does not include a Performance Group name the logon command includes a Performance Group name that is not specified in the account ID string portion of the user record) the logon command includes a Performance Group that is specified in the user s account ID string, but that has not yet been created using the schmon -p command THEN... the session is assigned to the specified PG. the session is assigned to the first Performance Group specified in the user s account ID string. If no PG is specified in the account ID string, the session defaults to Performance Group M. logon fails. 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 112. Every request is assigned to a Performance Group based on the logon process and by TASM, 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. 60 Utilities

61 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Performance Periods Performance Period Components The following table describes the components of a Performance Period. Component... Milestone Type Milestone Limit Allocation Group Defines the... 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 61. 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 61. number of the Allocation Group used to control sessions during this Performance Period. For more information, see Allocation Groups on page 65. 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 61

62 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Query resource usage Session resource usage Milestone Limit Units Seconds to hundredths of seconds, representing an amount of query CPU resource consumption per node. For example,.02. 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 24- hour 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 112. schmon -p 10 H1 1 Q Utilities

63 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Between 5:00 p.m. and 11:00 p.m., reduce the assigned weight to 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 63

64 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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/ Monday, use AG 5 until 0800 /2-5/ Tuesday through Friday, use AG 7 until 0900 /1-5/ Monday through Friday, use AG 2 until After 1800, use the next higher period. /6/ Saturday, use AG 7 until 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. 64 Utilities

65 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Allocation Groups For more information on schmon options, see Schmon Utility (schmon) (SLES 10 only) on page 75. 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 Group B Performance Period Performance Period Performance Period Allocation Group 7 Allocation Group F423 An Allocation Group cannot be referenced by Performance Groups from more than one Resource Partition. Utilities 65

66 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Allocation Groups Allocation Group Parameters The following table describes the parameters of an Allocation Group. Parameter Allocation Group ID Expedite Attribute Allocation Group Weight Limit Description Any number from 0 to 199 inclusive. 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 66. 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 67 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 Expedite Attribute 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%. 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: 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. 66 Utilities

67 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 70. Allocation Group Weight 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 Allocation Group 2 = 10 Allocation Group 3 = 20 Allocation Group 4 = 40 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 ( ) for a sum of 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) Allocation Group 2 = 28% (10/35) Allocation Group 3 = 57% (20/35) 3 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. Allocation Group 1 = 7% (.14 x.50) Allocation Group 2 = 14% (.28 x.50) Allocation Group 3 = 28% (.57 x.50) Utilities 67

68 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Allocation Group Weight Type of Work D 5 For demotions P2 10 Med/low priorities P1 40 High priorities B 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: = 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% 3 Add the assigned weights (5, 10, 40, and 20) of the active Allocation Groups within the Standard Resource Partition: = 75 4 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% 5 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. 68 Utilities

69 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 seconds seconds seconds 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 69

70 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 effect on the scheduling strategy defined by other Priority Scheduler parameters Is enforced separately on individual nodes of the Teradata Database system, but is not enforced on PE-only nodes. 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 70 Utilities

71 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) AMP Worker Task (AWT) Reservations and Limits AWT Resource Allocation 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. 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 ( = 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 71

72 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) AMP Worker Task (AWT) Reservations and Limits 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 77) One or more PGs use expedited AGs in Performance Period definitions (see schmon -p on page 112) One or more AWTs is reserved for expedited AGs (see schmon -w on page 124) 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.) 72 Utilities

73 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) AMP Worker Task (AWT) Reservations and Limits 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 (A-K). Example 1 awtmon default output > awtmon ====> Thu Feb 15 10:02: <==== Amp 0: Inuse: 22: FOUR: 1 NEW: 13 ONE: 8 Amp 2: Inuse: 20: NEW: 12 ONE: 8 Amp 4: Inuse: 20: NEW: 12 ONE: 8 Amp 6: Inuse: 20: NEW: 12 ONE: 8 Amp 8: Inuse: 20: NEW: 12 ONE: 8 Amp 10: Inuse: 20: NEW: 12 ONE: 8 Amp 12: Inuse: 20: NEW: 12 ONE: 8 Amp 14: Inuse: 20: NEW: 12 ONE: 8 Amp 16: Inuse: 21: NEW: 13 ONE: 8 Amp 18: 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 ====> Tue Feb 16 08:53: <==== 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: <==== LOOP_1: Inuse: 54: Amps: 5,6,11,12,17,18,23,29,30,35,36,41,42 Utilities 73

74 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) AMP Worker Task (AWT) Reservations and Limits LOOP_1: Inuse: 55: Amps: 0,47 LOOP_1: Inuse: 56: Amps: 24 ====> Tue Feb 16 08:53: <==== 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 LOOP_2: Inuse: 56: Amps: Utilities

75 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Schmon Utility (schmon) (SLES 10 only) Schmon Utility (schmon) (SLES 10 only) Function Runs From 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 (TASM), 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. 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 75

76 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) Schmon Utility (schmon) (SLES 10 only) Syntax schmon -a AG# div -x -s -S X weight limit none -T -d delay reps -b -c -d RP# RPNAME weight limit none -s -S -T -d delay -x -a -b -p -t -w -f path reps -f -h -l -m -M -p -s -t -w path specific option(s) limit none -S -P -L -n PG# all id age active disp -b -d delay reps -p -s -P -b -d delay -V PGNAME R T PP -s -S -T -d delay -x -S -T -d delay reps reps reps 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. 76 Utilities

77 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -a schmon -a Purpose The schmon -a option displays or sets Allocation Group parameters. Syntax schmon -a AG# div X weight limit none -x -s -S -T -d delay reps 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# div X 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. 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 77

78 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -a Syntax element weight limit none Description 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. 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. Specifies that no limit is to be enforced. This is the default value for limit. It is the same as specifying 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: 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 78 Utilities

79 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 95, and schmon -s on page 117. 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 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 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 session s tasks are assigned to Allocation Groups based on the session s 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 60. Utilities 79

80 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 The following appears: Stats: Mon Mar 8 14:47: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========= ========= ======== == ================= 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 The following appears: Stats: 3 node(s) Mon Mar 8 14:50: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] 80 Utilities

81 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -a === ====== ========== ========== ==== ========== ========= ========= ======== == ================= L[0] Example 4 To set the expedite attribute on an Allocation Group 1, type: schmon -a 1 N X 30 The following appears: Id Type Weight 1 N 5 >>>>> Changed to: 1 NX 30 Allocation Groups (0-199) Example 5 To change the weight of Allocation Group 5 from 1 to 10, type: schmon -a 5 S 10 The following appears: Id Type Weight 5 S 1 >>>>> Changed to: 5 S 10 Allocation Groups (0-199) Utilities 81

82 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -b schmon -b Purpose The schmon -b option displays or sets Resource Partition parameters. Syntax schmon -b RP# RPNAME weight limit none -s -S -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# RPNAME weight An integer from 0 through 4 that identifies the Resource Partition for which parameters will be set or displayed. 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. The name of the Resource Partition. Resource Partition names that contain spaces must be within double quotation marks. For example, RP ONE. 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. 82 Utilities

83 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -b Syntax element limit none Description A percentage limit on total CPU usage by all tasks controlled by the Resource Partition. The value ranges 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 RP is removed. Specifies that no limit is to be enforced. This is the default value for limit. It is the same as specifying 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. The -T output includes the following columns: 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 83

84 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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. 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 95, and schmon -s on page 117. 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 -b 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 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. 84 Utilities

85 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -b Usage Notes Example 1 For information on the settings displayed using the -b option, see schmon -d on page 89. 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 be 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. The following example shows a four-node MPP system. To display session data for Resource Partition 0 on the current node, type: schmon -b 0 -s The following appears: Stats: 3 node(s) Mon Mar 8 15:02: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== L[0] M[0] R[0] Example 2 The following example shows a four-node MPP system. Note: PDE was not up on one of the nodes. To display session data for Resource Partition 0 on all nodes, type: schmon -b 0 -S The following appears: Stats: 3 node(s) Mon Mar 8 15:02: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== L[0] M[0] R[0] Utilities 85

86 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 RP The following appears: Resource Partitions (0-4) Id Partition Name Weight Limit 1 RP1 50 none >>>>> Changed to: 1 RP Example 4 To reset the limit to none on Resource Partition 1, type: schmon -b 1 RP1 50 none The following appears: Resource Partitions (0-4) Id Partition Name Weight Limit 1 RP >>>>> Changed to: 1 RP1 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 The following appears: Resource Partitions (0-4) Id Partition Name Weight Limit 1 rp >>>>> Changed to: 1 RP NO none 86 Utilities

87 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 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. Utilities 87

88 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -c Usage Notes Example 1 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. To dump all settings, type: schmon -c The following appears: # Priority Scheduler Times & Attributes # Age_Time Active_Time Dispatch_Age schmon -t # System Limit schmon -l 100 # Resource Partitions schmon -b 0 Default 100 none # Allocation Groups schmon -a 1 N 5 none schmon -a 2 N 10 none schmon -a 3 N 20 none schmon -a 4 N 40 none # Performance Groups schmon -p 0 L 0 S schmon -p 1 M 0 S schmon -p 2 H 0 S schmon -p 3 R 0 S # AWT Expedited work type limits (reserve maximum) schmon -w Example 2 To dump only Allocation Group parameters, type: schmon -c -a The following appears: # Allocation Groups schmon -a 1 N 5 none schmon -a 2 N 10 none schmon -a 3 N 20 none schmon -a 4 N 40 none 88 Utilities

89 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Scheduler Times & Attributes Resource Partitions Description Displays scheduler times and attributes. 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. System CPU limits are not enforced on PE-only nodes. Displays Resource Partition parameters. 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 89

90 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -d Setting category Performance Groups Allocation Groups Description 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 ( ) of query resource usage. The character S indicates that milestone limits are seconds ( ) 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. 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. A value of 100 indicates that no limit is to be enforced. The character string none indicates that no limit is to be enforced. If Lim is not present, any previously defined limit is removed. 90 Utilities

91 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 Resource Partitions (0-4) 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 M 0 S H 0 S R 0 S 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 AWT Expedited work type limits res max Utilities 91

92 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 path Description Specifies a path from which input is to be read. If path is not specified, data is read from standard input (STDIN). Usage Notes Example 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 87. 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): 10 schmon -a Allocation Groups (0-199) Id Wght Lim Id Wght Lim Id Wght Lim Id Wght Lim 1 5 none 2 10 none 3 20 none 4 40 none 92 Utilities

93 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -h schmon -h Purpose The schmon -h option displays help for schmon. Syntax schmon -h specific option(s) 1102A063 Syntax element specific option(s) Description Specifies one or more schmon top-level options on which to display extended help. Utilities 93

94 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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. System CPU limits are not enforced on PE-only nodes. 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. A value of 100 indicates that no limit is to be enforced. 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: Utilities

95 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m schmon -m Purpose The schmon -m option displays or monitors Priority Scheduler resource usage statistics. Syntax schmon -m -S -P -L -b -d delay reps 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. - (a minus sign) indicates the value has decreased by the indicated amount since the previous schmon run. An unsigned number indicates the value has increased by the indicated amount since the previous schmon run. Note: The output of the -d option shows only those items for which data has changed since the previous schmon run. Utilities 95

96 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m Syntax element delay [reps] Description 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. 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 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 Stats Collection Resource Partitions Description The date and time of the statistics displayed, as well as repetition number, if you specify multiple repetitions. 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: 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 are collected from all nodes in an MPP system, this is the average percentage per Resource Partition for all nodes. 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. 96 Utilities

97 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m Statistics category Allocation Groups Work Requests Description 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. Note: The sum of relative weights might be greater or less than 100 due to the following considerations: 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 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. 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 97

98 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m The following apply to MPP configurations: For the -S option: The count of nodes for a single repetition or for multiple repetitions is displayed. Time information is displayed. If a node is offline, it is not be 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 regardless of the number of repetitions is displayed. No transient status messages are displayed. Example 1 The following example shows a four-node MPP system. To monitor current Priority Scheduler statistics for the current node, type: schmon -m The following appears: Stats: Tue Jan 20 07:48: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of AG Wgt % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== L M R, PGFive 200 MAX System Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Example 2 The following example shows a four-node MPP system. Note: PDE was not up on one of the nodes. 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 The following appears: Stats: 3 node(s) Mon Mar 8 15:32: 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 98 Utilities

99 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m === === === ======= === ======= ===== ===== =================== =================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== =================== =================== 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 The following appears: Stats: Wed Jan 13 10:53: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === ==== === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of Delay Delay Total AG Wgt % (msec) % (sblks) Tasks Sets Count Skipped Delay === ==== === ======= === ======= ===== ===== ======= ======= ========== MAX Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== The following table explains the additional columns related to CPU limits and delays. Column Delay Count Delay Skipped Total Delay Explanation 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. The number of delays skipped due to tasks being in non-delayable states. 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. Utilities 99

100 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 The following appears: Stats Collection #1: Mon Mar 20 18:02: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of AG Wgt % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== M Stats Collection #2: Mon Mar 20 18:02: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of AG Wgt % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== 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: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of AG Wgt % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== H, R PG10, PG11, PG PG11, PG12, PG MAX System Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== >schmon -m -P Stats: Mon Oct 30 14:33: Avg CPU Avg I/O # of # of RP PG % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== 100 Utilities

101 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -m Example Avg CPU Avg I/O # of # of AG PG % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== R PG PG PG PG PG PG System Avg queue Avg queue Avg service AG PG #requests wait(msec) length time(msec) === === ========== ========== ========== =========== 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: Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Rel Avg CPU Avg I/O # of # of AG Wgt % (msec) % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== M R PG10, PG11, PG PG10, PG11, PG PG10, PG11, PG PG10, PG11, PG MAX System Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Utilities 101

102 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 -s -P -b -d delay -V 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 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. 102 Utilities

103 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M 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. - (a minus sign) indicates the value has decreased by the indicated amount since the previous schmon run. An unsigned number indicates the value has increased by the indicated amount since the previous schmon run. For examples of the -d option output, see schmon -m on page 95. Note: The output of the -d option shows only those items for which data has changed since the previous schmon run. 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. 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. 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 Stats Description The date and time of the statistics displayed, as well as repetition number, if you specify multiple repetitions. Utilities 103

104 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Statistics category Resource Partitions Description 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: 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 are collected from all nodes in an MPP system, this is the average percentage per Resource Partition for all nodes. 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 preceding collection period. When statistics are collected from all nodes in an MPP system, this is 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. 104 Utilities

105 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Statistics category Allocation Groups Description 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. Note: The sum of relative weights might be greater or less than 100 due to the following considerations: 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 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 preceding collection period. When statistics are collected from all nodes in an MPP system, this is 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 105

106 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Statistics category Work Requests Description 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. The following apply to MPP configurations: For the -M option: The count of nodes for a single repetition or for multiple repetitions is displayed. Time information is displayed. If a node is offline, it is not be 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 regardless of the number of repetitions is displayed. No transient status messages are displayed. Example 1 schmon -M Stats: 4 node(s) Tue Oct 25 14:10: 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 == === === ======= === ======= ===== ===== ====== ===== ===== =============== ====== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks == === === ======= === ======= ===== ===== ====== ===== ===== =============== ====== MAX Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Minimum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Utilities

107 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Maximum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Example 2 The following example shows a four-node MPP system with one node where PDE is NULL. Note: PDE was not up on one of the nodes. To monitor Priority Scheduler statistics for all nodes with a five-second delay between two repetitions of the display, type: schmon -M 5 2 The following appears: Stats Collection #1: 3 node(s) Sat Aug 30 08:44: 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 === === === ======= === ======= ===== ===== ================= ================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== ================= ================== Stats Collection #2: 3 node(s) Sat Aug 30 08:44: 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 === === === ======= === ======= ===== ===== ================= ================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== ================= ================== 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. Note: PDE was not up on one of the nodes. 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 The following appears: Utilities 107

108 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Stats: 3 node(s) Sat Aug 30 08:45: Avg Avg Rel Avg CPU Avg I/O # of # of RP Wgt % (msec) % (sblks) Tasks Sets === === === ======= === ======= ===== ===== ============================== Avg Avg Rel Avg CPU Avg I/O # of # of AG Wgt % (msec % (sblks) Tasks Sets Performance Groups Affected === === === ======= === ======= ===== ===== ============================== M Example 4 To display the names of the nodes that have the minimum and maximum resource usage, type: schmon -M -n The following appears: Stats: 4 node(s) Tue Oct 25 14:10: 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 === === === ======= === ======= ===== ===== ===================== =================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== ===================== =================== MAX Node Names: RP/AG CPU_min CPU_max I/O_min I/O_max Tasks_min Tasks_max ===== ========== ========== ========== ========== ========== ========== RP0 tnt45_byne tnt47_byne tnt47_byne tnt46_byne tnt45_byne tnt44_byne AG2 tnt45_byne tnt47_byne tnt47_byne tnt46_byne tnt45_byne tnt44_byne AG200 tnt44_byne tnt47_byne tnt45_byne tnt47_byne tnt45_byne tnt44_byne Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Minimum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Maximum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Node Names: RP/AG Rqsts_min Rqsts_max QWait_min QWait_max QLen_min QLen_max STime_min STime_max ===== ========= ========= ========= ========= ========= ========= ========= ======== AG2 tnt44_byn tnt47_byn tnt46_byn tnt47_byn tnt46_byn tnt47_byn tnt44_byn tnt47_byn AG200 tnt46_byn tnt47_byn tnt46_byn tnt47_byn tnt46_byn tnt47_byn tnt46_byn tnt47_byn 108 Utilities

109 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Example 5 To show RP and AG resource usage statistics, type: schmon -M -s The following appears: Stats: 4 node(s) Tue Oct 25 14:11: 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 === === === ======= === ======= ===== ===== ===================== =================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== ===================== =================== MAX Statistics: RP 0 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: 9.50 StdDev: StdDev: StdDev: 0.83 Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 2 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: 9.50 StdDev: StdDev: StdDev: 0.83 Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 200 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: StdDev: StdDev: StdDev: 1.22 Range Freq Range Freq Range Freq ====================== ====================== ====================== Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Minimum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Maximum Avg queue Avg queue Avg service AG #requests wait(msec) length time(msec) === ========== ========== ========== =========== Utilities 109

110 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Statistics: AG 2 (4 Active Nodes): Requests Median: Q Length Median: 0.00 StdDev: 8.66 StdDev: 0.00 Range Freq Range Freq ====================== ====================== Que Wait Median: 1.00 Srv Time Median: StdDev: 0.38 StdDev: Range Freq Range Freq ====================== ====================== AG 200 (2 Active Nodes): Requests Median: 3.00 Q Length Median: 0.00 StdDev: 2.83 StdDev: 0.00 Range Freq Range Freq ====================== ====================== Que Wait Median: Srv Time Median: StdDev: StdDev: Range Freq Range Freq ====================== ====================== Example 6 To show statistics in verbose mode, which includes inactive nodes, type: schmon -M -s -V The following appears: Stats: 4 node(s) Tue Oct 25 14:13: 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 === === === ======= === ======= ===== ===== ===================== =================== Avg Avg Node Resource Usage Rel Avg CPU Avg I/O # of # of Minimum Maximum AG Wgt % (msec) % (sblks) Tasks Sets CPU I/O Tasks CPU I/O Tasks === === === ======= === ======= ===== ===== ===================== =================== MAX Statistics: RP 0 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: StdDev: StdDev: StdDev: 1.22 Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 2 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: StdDev: StdDev: StdDev: Utilities

111 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -M Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 3 (1 Active Node): CPU Median: I/O Median: 0.00 Tasks Median: 2.00 StdDev: 0.00 StdDev: 0.00 StdDev: 0.00 Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 3 (All Nodes): CPU Median: 0.00 I/O Median: 0.00 Tasks Median: 0.00 StdDev: StdDev: 0.00 StdDev: 0.87 AG 4 (1 Active Node): CPU Median: I/O Median: 0.00 Tasks Median: 0.00 StdDev: 0.00 StdDev: 0.00 StdDev: 0.00 Range Freq Range Freq Range Freq ====================== ====================== ====================== AG 4 (All Nodes): CPU Median: 0.00 I/O Median: 0.00 Tasks Median: 0.00 StdDev: 4.76 StdDev: 0.00 StdDev: 0.00 AG 200 (4 Active Nodes): CPU Median: I/O Median: Tasks Median: StdDev: StdDev: StdDev: 1.22 Range Freq Range Freq Range Freq ====================== ====================== ====================== Utilities 111

112 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -p schmon -p Purpose The schmon -p option sets or displays Performance Group parameters. Syntax schmon -p PG# PGNAME R T PP -x -s -S -T -d delay reps 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# PGNAME R An integer from 0 through 249 that identifies the Performance Group for which parameters will be set or displayed. 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. 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. 112 Utilities

113 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -p Syntax Element T PP 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 ( ) 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 ( ) 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. 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 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: 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. Utilities 113

114 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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. The -T output includes the following columns: 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 -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 95, and schmon -s on page 117. Note: The output of the -d option shows only those items for which data has changed since the previous schmon run. 114 Utilities

115 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -p Syntax Element delay [reps] Description Causes schmon -p 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 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 115

116 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -p The following apply to MPP configurations: For the -S option: The count of nodes for a single repetition or for multiple repetitions is displayed. Time information is displayed. If a node is offline, it is not be 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 regardless of the number of repetitions is displayed. No transient status messages are displayed. Example 1 To display session data for sessions assigned to Performance Group 1, type: schmon -p 1 -s The following appears: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== 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/ Monday, use AG 5 until 0800 /2-5/ Tuesday through Friday, use AG 7 until 0900 /1-5/ Monday through Friday, use AG 2 until After 1800, use the next higher period. /6/ Saturday, use AG 7 until 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/ /2-5/ /1-5/ /6/ The following appears: Performance Groups (0-249) Id Group Name RP Type Milestones & Allocation Groups[0-7] 2 M 0 T /1/ /2-5/ /1-5/ /6/ Utilities

117 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 id -S -T -d delay reps 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 id Shows information for all sessions. This is the default. 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. The -T output includes the following columns: 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 117

118 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -s 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. 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 -s to run again automatically after a specified delay using the current 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 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: Column AG Host ID Session Request #tsk Description Allocation Group ID. Host system of an active session. Session number of an active session. Request number of an active session. Number of tasks working on behalf of the session. 118 Utilities

119 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -s Column CPU(msec) DSK(blk) RP PG [PP] Description Number of milliseconds of CPU time accumulated by the session or request during the previous age period. Number of disk blocks transferred by the session or request during the previous age period. Resource Partition to which the line s allocation group belongs. Performance Group to which the session is assigned. Performance Period currently controlling the session. Each Performance Group defines one or more Performance Periods. A PG s 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 57 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 The following appears: Stats: Mon Mar 8 15:49: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== L[0] M[0] R[0] Utilities 119

120 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== PG5[0] PG5[0] Tsk Addr Tskid Prio Session Request Tskuse Setterm # Delay Delay Time ==================== ====== ==== ======= ======= ========== ======= ======= ========== 0xffffc c xffffc20011f6e xffffc20011fee xffffc e xffffc20011f6f xffffc xffffc xffffc200135c Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== System[0] System[0] System[0] System[0] System[0] System[0] Tsk Addr Tskid Prio Session Request Tskuse Setterm # Delay Delay Time ==================== ====== ==== ======= ======= ========== ======= ======= ========== 0xffffc20011be xffffc20011be xffffc20011be0e xffffc20011be xffffc20011be1c xffffc20011e xffffc20011f2a 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: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== System[0] Stats Collection #2: Mon Aug 04 17:53: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== System[0] Stats Collection #3: Mon Aug 04 17:53: No difference in data this period 120 Utilities

121 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== PG5[0] PG5[0] Tsk Addr Tskid Prio Session Request Tskuse Setterm # Delay Delay Time ==================== ====== ==== ======= ======= ========== ======= ======= ========== 0xffffc20013a4b xffffc20013a Stats Collection #2: Fri Feb 5 14:13: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== PG5[0] PG5[0] Tsk Addr Tskid Prio Session Request Tskuse Setterm # Delay Delay Time ==================== ====== ==== ======= ======= ========== ======= ======= ========== 0xffffc20013a4b xffffc20013a Stats Collection #3: Fri Feb 5 14:13: Session Usage Query Usage AG HostID Session Request #tsk CPU(msec) DSK(blk) CPU(msec) DSK(blk) RP PG [PP] === ====== ========== ========== ==== ========== ========== ========== ========== === =============== PG5[0] PG5[0] Tsk Addr Tskid Prio Session Request Tskuse Setterm # Delay Delay Time ==================== ====== ==== ======= ======= ========== ======= ======= ========== - 0xffffc20013a4b xffffc20013a Utilities 121

122 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 specifies a wait period in seconds. 122 Utilities

123 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -t Example To view the current settings, type: schmon -t The following appears: Age Time(sec): 60 Active Time(sec): 61 Disp Age(sec): 5 To change the settings, type: schmon -t The following appears: Age Time(sec): 60 Active Time(sec): 61 Disp Age(sec): 0 >>>>> Changed to: Age Time(sec): 30 Active Time(sec): 31 Disp Age(sec): 5 Utilities 123

124 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) 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 maximum 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. 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. 124 Utilities

125 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -w Usage Notes Example 1 The Expedite attribute is defined by an Allocation Group. For more information see Expedite Attribute on page 66 and AMP Worker Task (AWT) Reservations and Limits on page 70. Consider scripting a set of schmon commands for each restoration and maintenance. 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 The following appears: res max AWT Expedited work type limits 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 The following appears: res max AWT Expedited work type limits >>>>> Changed to: 5 10 Utilities 125

126 Chapter 19: Priority Scheduler (schmon) (SLES 10 only) schmon -w 126 Utilities

127 CHAPTER 20 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 and Reconfiguration utilities, see Support Utilities. The Query Configuration utility is also referred to as Configuration Display. Runs From Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Teradata Viewpoint Remote Console portlet Host Utility Console 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. About Query Configuration Vprocs and Physical Processors Display Options 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. 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: Complete configuration Node, online or offline Utilities 127

128 Chapter 20: Query Configuration (qryconfig) Query Configuration Options AMPs, online or offline PEs, online or offline Query Configuration Options 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, QUIT or END to terminate. all DBS Configuration Status Report: 00/06/13 18:31:23 Vproc Node Config Config Cluster/ Vproc Node Config Config Cluster/ Number ID Type Status Host No. Number ID Type Status Host No AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online Utilities

129 Chapter 20: Query Configuration (qryconfig) Query Configuration Options AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online PE Online PE Online PE Online Processors Option 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. 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 128. 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. Enter display option, QUIT or END to terminate. online processors DBS Configuration Status Report: 00/06/13 18:35:56 Vproc Node Config Cluster/ Vproc Node Config Cluster/ Number ID Type HostId Number ID Type Host No AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP PE PE PE PE 1 Utilities 129

130 Chapter 20: Query Configuration (qryconfig) Query Configuration Options 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. Enter display option, QUIT or END to terminate. amps DBS Configuration Status Report: 00/06/13 18:38:20 Vproc Node Config Config Cluster/ Vproc Node Config Config Cluster/ Number ID Type Status Host No. Number ID Type Status Host No AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online AMP Online 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. 130 Utilities

131 Chapter 20: Query Configuration (qryconfig) Query Configuration Options Enter display option, QUIT or END to terminate. pes DBS Configuration Status Report: 00/06/13 18:44:20 Vproc Node Config Config Cluster/ Vproc Node Config Config Cluster/ Number ID Type Status Host No. Number ID Type Status Host No PE Online PE Online PE Online PE Online 1 Online PEs and Offline PEs Options Getting HELP 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. To produce a list of all of the Query Configuration options, type HELP or question mark (?). The list of options appears as follows: Enter display option, QUIT or END to terminate. 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 131

132 Chapter 20: Query Configuration (qryconfig) Query Configuration Options 132 Utilities

133 CHAPTER 21 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 Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Teradata Viewpoint Remote Console portlet Host Utility Console 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. Query Session States Query Session provides information on the following possible states of a session. The Session State... ABORTING ACTIVE BLOCKED DELAYED Indicates that... the session is aborting its latest request. the session has sent steps to the dispatcher and possibly to one or more AMP vprocs. an active session is waiting for a database lock to be released. the session is being delayed because query limit, imposed by a Teradata Active System Management (TASM) throttle rule, has been met. Utilities 133

134 Chapter 21: Query Session (qrysessn) Parent and Child Sessions The Session State... IDLE INDOUBT INDOUBT PARSING PARSING QTDELAYED QUIESCED ABORT QUIESCED ABORT WITH LOGOFF QUIESCED INDOUBT RESPONSE SESDELAYED Indicates that... the Teradata Database system recognizes a session, but no processing is taking place. a two-phase commit session is in doubt. a two-phase commit session is in doubt and is parsing a vote or commit request. the session is active in the Teradata SQL parser phase, before the steps are dispatched to the AMP vprocs. the session is waiting for rows to be inserted into a queue table. the session is blocked from executing further requests because transactions associated with this session are being aborted. 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. the session is blocked from exercising further requests because the outstanding transaction/request will be terminated. a response to a session request is in process. the session is being delayed because a utility limit, imposed by a TASM 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. 134 Utilities

135 Chapter 21: Query Session (qrysessn) 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... an integer an asterisk (*) a question mark (?) a carriage return (Enter) THEN... Query Session provides information only for the sessions associated with the specified logical host ID. Query Session provides information on sessions for every logical host. you will get Help for this entry. 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... an integer to indicate a specific session ID 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. an asterisk (*) a question mark THEN you see... the following prompt: Is detail information needed if the session is involved in HUT/FastLoad/ MLoad/Export? y-yes, n-no 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. the following prompt: 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. help concerning input information. Utilities 135

136 Chapter 21: Query Session (qrysessn) 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 DBC The columns for the Session Identifier display the following information. The column named... Host Session PE DBC User ID Contains the... logical host identifier. session identifier. PE number of the PE to which the session is assigned. 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 Host Session PE DBC User ID DBC State Details : ACTIVE Statements Dispatched Time CPU Usage Accesses :22: Utilities

137 Chapter 21: Query Session (qrysessn) State Information Displays Session State Details During Stored Procedure Execution If a stored procedure is being executed, the following session state information is displayed. Session State Query Results : 00/06/15 13:14:13 Host Session PE DBC User ID 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. Session State Query Results : 02/04/15 12:22:03 Host Session PE DBC User ID USER1 State Details: <status> Analyzing a workload for index recommendations. State Information Displays This following sections provide session information for each possible state: ABORTING ACTIVE BLOCKED DELAYED IDLE INDOUBT INDOUBT PARSING PARSING QTDELAYED QUIESCED ABORT QUIESCED ABORT WITH LOGOFF QUIESCED INDOUBT RESPONSE SESDELAYED Utilities 137

138 Chapter 21: Query Session (qrysessn) State Information Displays 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 :22: The columns on the ABORTING state display provide the following information. The column named... Statements Code Time CPU Usage Accesses Contains the... statements, up to the number displayed, that are aborting. error that caused the abort. time that the abort step was sent to the AMP. accumulated time in thousandths of a second that all AMPs spent processing the current request. 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 Statements Dispatched Time CPU Usage Accesses :22: The columns on the ACTIVE state display provide the following information. The column named... Statements Dispatched Time CPU Usage Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step in the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. 138 Utilities

139 Chapter 21: Query Session (qrysessn) State Information Displays The column named... Accesses Contains the... total number of segment access calls executed on all AMPs for the 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 READ 19 NO The columns on the BLOCKED state display provide the following information. The column named... Resource Statement AMPs Mode AMP Vproc HUT Contains the... 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. highest statement number for which steps have been dispatched to the AMPs. number of AMPs for which the session is waiting to acquire a lock. type of lock requested by the session. number of the AMP with the blocked session. host utility lock (if encountered). Utilities 139

140 Chapter 21: Query Session (qrysessn) State Information Displays 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 rule s 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 140 Utilities

141 Chapter 21: Query Session (qrysessn) State Information Displays QTDELAYED State QUIESCED ABORT 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 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 Utilities 141

142 Chapter 21: Query Session (qrysessn) Archive and Recovery Sessions State Displays This column for the RESPONSE display contains the following information. The column named... Statements Contains the... 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 Archive and Recovery Sessions State Displays 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 Statements Dispatched Time CPU Usage Accesses Byte Count :22: ,367 The Active State Display for a parent session involved in processing an Archive and Recovery request contains the following information. 142 Utilities

143 Chapter 21: Query Session (qrysessn) Archive and Recovery Sessions State Displays The column named... Statements Dispatched Time CPU Usage Accesses Byte Count Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. 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 Restore 14:22: ,234 The directed request active state display for a parent session involved in processing an Archive and Recovery request contains the following information. The column named... Request # Operation Time CPU Usage Accesses Byte Count Contains the... number of the request. type of operation being performed. time that the last step for the highest statement was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. total number of bytes accessed by the Archive and Recovery operation. Utilities 143

144 Chapter 21: Query Session (qrysessn) Archive and Recovery Sessions State Displays 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... Operation CPU Usage Accesses Byte Count Contains the... type of operation being performed. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. total number of bytes accessed by the Archive and Recovery operation. Child Session Display The following shows an example display for child sessions involved in an Archive and Recovery operation. Session # Request # State TimeStamp Byte Count Inactive 17:57:21 1, Active 17:57: Inactive 17:57:41 3,024 Child sessions involved in Archive and Recovery operations display these columns. The column named... Session # Request # State TimeStamp Byte Count Contains the... session identifier. number of the request. state of the session, indicating whether the session is active or inactive. 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. total number of bytes accessed by the session. 144 Utilities

145 Chapter 21: Query Session (qrysessn) FastLoad Sessions State Displays 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 Statements Dispatched Time CPU Usage Accesses Row Count :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. The column named... Statements Dispatched Time CPU Usage Accesses Row Count Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. total number of rows loaded by the FastLoad utility. Utilities 145

146 Chapter 21: Query Session (qrysessn) FastLoad Sessions State Displays 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 Statements Dispatched Time CPU Usage Accesses :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... Statements Dispatched Time CPU Usage Accesses Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session 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 CPU Usage Accesses Row Count ,321 The display for an inactive parent session in the loading phase of a FastLoad operation contains the following information. 146 Utilities

147 Chapter 21: Query Session (qrysessn) FastLoad Sessions State Displays The column named... CPU Usage Accesses Row Count Contains the... accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. 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 The inactive parent session display for sessions involved in any phase other than the loading phase contains the following information. The column named... CPU Usage Accesses Contains the... accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the 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 # State TimeStamp Byte Count Inactive 15:57:10 5, Active 15:57: Utilities 147

148 Chapter 21: Query Session (qrysessn) MultiLoad Sessions State Displays The display for Child sessions involved in FastLoad operations contain the following information. The column named... Sessions# Request # State TimeStamp Row Count Contains the... session identifier. number of the request. state of the session, indicating whether the session is active or inactive. 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. total number of rows loaded by the session. MultiLoad Sessions State Displays 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 Statements Dispatched Time CPU Usage Accesses DMLCount :09: Utilities

149 Chapter 21: Query Session (qrysessn) MultiLoad Sessions State Displays 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... Statements Dispatched Time CPU Usage Accesses DML Count Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. 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. State Details : Session involved in MLOAD utility MLoad Phase : Application. Task Running : Apply Task Statements Dispatched Time CPU Usage Accesses :09: ,637 DataBase.Table = SPOOL_RES.WT_TDEM_PAIMT_MED Action = Process Data and Secondary index # of WorkRows applied = 1,210,838 Total # of WorkRows = 51,639,908 # of NUSI change rows applied = 0 Total # of NUSI change rows = 0 The display for active parent sessions involved in the Apply Task of a MultiLoad operation provides the following information. Utilities 149

150 Chapter 21: Query Session (qrysessn) MultiLoad Sessions State Displays The column named... Statements Dispatched Time CPU Usage Accesses Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. In addition, the display provides the following information. Field DataBase.Table Action Description Identifies the table on which the MultiLoad operation is running. 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 # of NUSI change rows applied Total # of NUSI change rows Displays the total number of rows processed. Number of nonunique secondary index rows processed in the apply phase. 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. State Details : Session involved in MLOAD utility MLoad Phase : Application. Task Running : Delete Task Statements Dispatched Time CPU Usage Accesses :24: ,987 DataBase.Table = SPOOL_RES.WT_TDEM_PAIMT_MED Action = Process Data # of rows scanned = 22,357 # of rows deleted = 245,349 Note: The values shown include both the primary and the fallback count. 150 Utilities

151 Chapter 21: Query Session (qrysessn) MultiLoad Sessions State Displays 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. Statements Dispatched Time CPU Usage Accesses Row Count :23: ,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... Statements Dispatched Time CPU Usage Accesses Row Count Contains the... total number of statements in the current session request. highest statement number dispatched to the AMPs. time that the last step for the highest statement number was sent to the AMPs. accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. 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. CPU Usage Accesses Row Count ,673 These are the possible descriptions of the phase: Utilities 151

152 Chapter 21: Query Session (qrysessn) MultiLoad Sessions State Displays 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... CPU Usage Accesses Row Count Contains the... accumulated time in thousandths of a second that all AMPs spent processing the current request. total number of segment access calls executed on all AMPs for the session request. 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 # State TimeStamp Row Count Inactive 15:57:10 5, Active 15:57: Child sessions involved in MultiLoad operations display these columns. The column named... Session # Request # State TimeStamp Row Count Contains the... session identifier. number of the request. state of the session, indicating whether the session is active or inactive. 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. total number of rows loaded by the session. 152 Utilities

153 Chapter 21: Query Session (qrysessn) FastExport Sessions State Displays 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. Session State Query Results : 00/06/14 18:35:54 Host Session PE DBC User ID DBC State Details : Active PARENT session involved in FastExport FastExport Phase : Vertical redistribution. Statements Dispatched Time CPU Usage Accesses :35: ,922 Detail information for CHILDREN sessions in FastExport Util. Utilities 153

154 Chapter 21: Query Session (qrysessn) FastExport Sessions State Displays Session # Request # State Inactive Inactive Inactive 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. Session State Query Results : 00/06/13 18:38:59 Host Session PE DBC User ID DBC State Details : Active PARENT session involved in FastExport FastExport Phase : Vertical redistribution. Statements Dispatched Time CPU Usage Accesses :37: ,314 Detail information for CHILDREN sessions in FastExport Util. Session # Request # State Inactive Inactive Inactive Inactive The following example shows that the Teradata Database system continues to process the vertical redistribution phase. Session State Query Results : 00/06/12 18:38:59 Host Session PE DBC User ID DBC State Details : Active PARENT session involved in FastExport FastExport Phase : Horizontal redistribution. Statements Dispatched Time CPU Usage Accesses :42: ,314 Detail information for CHILDREN sessions in FastExport Util. Session # Request # State Inactive Inactive 154 Utilities

155 Chapter 21: Query Session (qrysessn) FastExport Sessions State Displays Inactive 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. Session State Query Results : 00/06/09 18:43:41 Host Session PE DBC User ID DBC State Details : Active PARENT session involved in FastExport FastExport Phase : Horizontal redistribution. Statements Dispatched Time CPU Usage Accesses :42: ,305 Detail information for CHILDREN sessions in FastExport Util. Session # Request # State Inactive Inactive Inactive Inactive FastExport Session - Inactive The following example shows that the FastExport session is inactive, waiting for the select to complete. Session State Query Results : 00/06/08 18:39:28 Host Session PE DBC User ID N/A DBC State Details : Child Session involved in FastExport Utility FastExport Phase : Returning data. Request # State Parent Session Inactive 1069 Utilities 155

156 Chapter 21: Query Session (qrysessn) FastExport Sessions State Displays 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. Session State Query Results : 00/06/07 18:49:09 Host Session PE DBC User ID N/A DBC State Details : Child Session involved in FastExport Utility FastExport Phase : Returning data. Request # State Statement Blocks Returned Total Block Active 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. Session State Query Results : 00/06/06 18:50:52 Host Session PE DBC User ID DBC State Details : Child Session involved in FastExport Utility FastExport Phase : Returning data. Request # State Statement Blocks Returned Total Block Active Utilities

157 CHAPTER 22 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 Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm. Type start rcvmanager at the DBW command prompt. Teradata Viewpoint Remote Console portlet Host Utility Console 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. 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 157

158 Chapter 22: 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 193. 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 No work load competition Computeintensive work load Moderate or heavy disk work load Description 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. 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. 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. 158 Utilities

159 Chapter 22: Recovery Manager (rcvmanager) Online Transaction Recovery Guideline I/O saturation Description 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 194. 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 AMP s disk. IF... all the modification operations successfully complete on all the AMPs working on behalf of the transaction a transaction does not complete due to a Teradata Database system crash or forced restart THEN... that transaction is successful and there is no further concern for recovery of that transaction. those transactions are backed out as part of the Teradata Database system recovery process when the Teradata Database system restarts. Utilities 159

160 Chapter 22: Recovery Manager (rcvmanager) Transaction Recovery Sequence Transaction Recovery Sequence The general sequence of a Teradata Database system recovery is as follows: 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. 2 All locks needed for the recovery are set, and the Teradata Database system begins roll back or completion of the transactions. 3 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. 4 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 160 Utilities

161 Chapter 22: Recovery Manager (rcvmanager) Deferred Transaction Recovery 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. 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. 2 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 184. Utilities 161

162 Chapter 22: Recovery Manager (rcvmanager) Down AMP Recovery Recovering Down AMPs DOWN AMP RECOVERY STATUS at HH:MM:SS MM/DD/YY AMP to be Current Pass Next Pass caught up Pass OJ CJ OJ CJ ,081 - AMP Status: Online Catchup - Not currently executing recovery , ,081 - AMP Status: Offline Catchup - Transaction Recovery: 25,488 TJ Rows , AMP Status: Online Catchup - Change Row Recovery: 26% complete in this pass , ,228 - AMP Status: Offline Catchup - Rebuilding Database1.Table1: 45% complete 0005* ,888 - AMP Status: Offline Catchup - Between passes * - would probably be placed in online catch up if a restart occurred 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. 2 The extracted Ordered System Change Journal (OJ) is processed, rebuilding various subtables. 3 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. 4 The OJ entries are applied. Ones which take a significant amount of time are the build operations. 5 Current CJ entries are applied. Each CJ entry represents one row to be updated (insert, delete, update). 6 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. 7 The Next Pass OJ and CJ entries become the Current Pass entries. 8 Repeat steps 2 through 7 indefinitely. 9 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. 162 Utilities

163 Chapter 22: Recovery Manager (rcvmanager) Down AMP Recovery 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. 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. 2 The Down AMP RJ records the changes that should have been made to fallback-protected rows of the inoperative AMP. 3 The changes are applied when the down AMP recovers. The Recovery Journal maintains the following two sets of records: Record Changed Row Journal (CJ) Ordered System Change Journal (OJ) Function Logs changed rows in an AMP cluster by logging pointers to the rows that have been changed, but does not log the actual rows. 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 163

164 Chapter 22: Recovery Manager (rcvmanager) 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. 2 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* No 0 Online Online AMP 0 On No 0 Offline Down AMP 0 On 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 3 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 4 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 164 Utilities

165 Chapter 22: Recovery Manager (rcvmanager) 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: 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* No 0 Online Online AMP 0 On No 0 Utility Catchup AMP 0 On No 0 Online Online PE 52 COP * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD The disable list is empty To verify if an offline AMP, for example, is almost in catchup, do the following: 1 Start rcvmanager. 2 To check the offline AMP status, type: list status; One of the following messages appears: Message... - AMP Status: Not in recovery - Down - AMP Status: Offline Catchup - Executing miscellaneous Recovery actions - AMP Status: Offline Catchup - Between Passes * - would probably be placed in online catchup if a restart occurs. Means that the... AMP is still down. AMP is in catchup mode. 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 165

166 Chapter 22: Recovery Manager (rcvmanager) 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 164. 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 /02/06 11:35:31 Running DBS Version: /02/06 11:35:31 Running PDE Version: /02/06 11:35:32 Current DBS config maps are synchronized (Version: 11) 98/02/06 11:35:32 New DBS config maps are synchronized (Version: 11) 98/02/06 11:35:32 AMP 0000 has been selected as the Control AMP 98/02/06 11:35:33 Initializing DBS Vprocs 98/02/06 11:35:36 Configuration is operational 98/02/06 11:35:36 Starting AMP partitions 98/02/06 11:35:40 Connection accepted 98/02/06 11:36:02 Voting for transaction recovery 98/02/06 11:36:05 Recovery session 1 contains 77 rows on AMP /02/06 11:36:16 Starting transaction recovery 98/02/06 11:36:18 Completed transaction recovery 98/02/06 11:36:18 Starting PE partitions 98/02/06 11:37:03 System is operational 98/02/06 11:37:05 Users are logged on 98/02/06 11:37:05 Logons are enabled The following table lists and explains these and other messages. Message # AMP mmmm in cluster nnn is back online 2 - AMP mmmm is in offline catchup 3 - AMP mmmm is in online catchup 4 - AMP mmmm not brought online for the following reason(s): Means... the specified AMP which was offline is now back online. the AMP is in offline catchup mode. the AMP is in online catchup mode. 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. 166 Utilities

167 Chapter 22: Recovery Manager (rcvmanager) Restarts Message # Completed transaction recovery Means... 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 Starting transaction recovery 9 - Startup will wait for recovery to complete 10 - Voting for transaction recovery 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. transaction recovery has started on online AMPs. the user initiated a COLDWAIT restart. 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 Automatic Restarts User-initiated User-Initiated 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. 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 167

168 Chapter 22: Recovery Manager (rcvmanager) Cancelling Rollback on Tables Issue the RESTART command. For information on the RESTART command, see Chapter 34: 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. Cancelling Rollback on Tables 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: The rollback of a table is likely to take longer than its restoration. The table, such as a temporary table, is unimportant. Caution: 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. 2 You identify a large table(s) that can be restored faster than the rollback will take. 3 You perform a LIST ROLLBACK TABLES to see which tables are undergoing rollback. 4 You perform a CANCEL ROLLBACK ON TABLE. 5 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. 168 Utilities

169 Chapter 22: Recovery Manager (rcvmanager) Cancelling Rollback on Tables 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 172. To cancel the rollback on tables, do the following: 1 Start rcvmanager. 2 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 Type Y to confirm. For more information on rollbacks, see the following commands: CANCEL ROLLBACK ON TABLE on page 171 LIST CANCEL ROLLBACK TABLES on page 178 LIST ROLLBACK TABLES on page 180 Utilities 169

170 Chapter 22: Recovery Manager (rcvmanager) 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 CANCEL ROLLBACK ON TABLE DEFAULT PRIORITY HELP LIST CANCEL ROLLBACK TABLES LIST LOCKS LIST ROLLBACK TABLES LIST STATUS QUIT REBUILD/RECOVERY PRIORITY ROLLBACK SESSION... PERFORMANCE GROUP Description Cancels rollback processing on tables currently undergoing rollback as part of a Teradata Database system recovery or an online, usertransaction abort. Sets the priorities to the default values. Displays the syntax for the commands supported by rcvmanager. 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. Displays all locks currently held by transaction recovery. Displays a report with the names and details of the tables undergoing rollback in the Teradata Database system. Displays transaction recovery information and AMP recovery information for unavailable AMPs or detailed information about the recovery process of a specific AMP. Exits rcvmanager. Sets or displays a priority level for use by the Table Rebuild utility and a Teradata Database system recovery operation. 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. 170 Utilities

171 Chapter 22: Recovery Manager (rcvmanager) CANCEL ROLLBACK ON TABLE 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... table_id Specifies... 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 172. Usage Notes Caution: 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: 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 171

172 Chapter 22: Recovery Manager (rcvmanager) CANCEL ROLLBACK ON TABLE The typical process of cancelling rollback on a table is as follows: 1 The rollback is taking too long. 2 You identify a large table(s) that can be restored faster than the rollback will take. 3 You perform a LIST ROLLBACK TABLES to see which tables are undergoing rollback. 4 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. 5 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: 172 Utilities

173 Chapter 22: Recovery Manager (rcvmanager) CANCEL ROLLBACK ON TABLE > dbc Rollback will be cancelled for: 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. > CANCEL ROLLBACK ON TABLE 0:6708; 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. > CANCEL ROLLBACK ON TABLE 0:6710; Entry ignored as table 0:6710 has referential integrity constraint. Enter command, "QUIT;" or "HELP;" : > CANCEL ROLLBACK ON TABLE 0:6711; Entry ignored as table 0:6711 has referential integrity constraint. Enter command, "QUIT;" or "HELP;" : > CANCEL ROLLBACK ON TABLE 0:6712; Rollback will be cancelled for: 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. > CANCEL ROLLBACK ON TABLE 0:6707; Rollback will be cancelled for: 0000:6707 "EmployeeDB"."Temp_Table" The following join and/or hash indexes will be invalidated: "EmployeeDB"."Sal_Join" Confirm y/n? > y Utilities 173

174 Chapter 22: Recovery Manager (rcvmanager) CANCEL ROLLBACK ON TABLE 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 > CANCEL ROLLBACK ON TABLE 0: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: Rollback will be cancelled for: 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. 174 Utilities

175 Chapter 22: Recovery Manager (rcvmanager) CANCEL ROLLBACK ON TABLE To... delete all the rows in the table and make it valid again drop the table so that you can create it again retrieve a single table for SELECT operations restore the table from an archive using ARC utility take a dump of the table using ARC utility rebuild the table headers Use the... DELETE statement with the ALL option. DROP TABLE statement. LOCKING request modifier with the READ OVERRIDE option. RESTORE command. DUMP command. Table Rebuild utility. Note: CheckTable utility skips checking on tables whose rollback you cancel. Utilities 175

176 Chapter 22: Recovery Manager (rcvmanager) 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. 176 Utilities

177 Chapter 22: Recovery Manager (rcvmanager) 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; { STATUS [<proc-id>] } { LOCKS } LIST { ROLLBACK TABLES } { CANCEL ROLLBACK TABLES }; { REBUILD } [ Low ] { } PRIORITY [ Medium ] ; { RECOVERY } [ High ] DEFAULT 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 177

178 Chapter 22: Recovery Manager (rcvmanager) 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... CANCEL ROLLBACK TABLES Specifies... to display the list of tables upon which rollback is cancelled. Usage Notes Example 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. 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 :6707 "Department"."Dept_Details" 0000:6712 "Department"."Temp_Table" 178 Utilities

179 Chapter 22: Recovery Manager (rcvmanager) LIST LOCKS LIST LOCKS Purpose The LIST LOCKS command displays all locks currently held by transaction recovery. Syntax LIST LOCKS ; 1102A047 Syntax element... LOCKS Specifies... to displays locks held by online transaction recovery. Usage Notes Example 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. 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 Lock Object Mode Object Name Write Database "AssetsDB" Write Row hash "Clients"."TurnOver" Write Row hash "EmployeeInfo"."NewHires" Exclusive Row hash "SampleDB"."pseudo table" Exclusive Table "SampleDB"."SampleTable" Utilities 179

180 Chapter 22: Recovery Manager (rcvmanager) LIST ROLLBACK TABLES LIST ROLLBACK TABLES 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... ROLLBACK TABLES Specifies... 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 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. This part... online user rollback tables Displays a list of tables in the sessions that are undergoing rollback as part of... user-requested abort. 180 Utilities

181 Chapter 22: Recovery Manager (rcvmanager) LIST ROLLBACK TABLES This part... system recovery rollback tables Displays a list of tables in the sessions that are undergoing rollback as part of... Teradata Database system recovery. The following table explains what information the report columns provide: Column... Host Session User ID Performance Group AMP W/Count TJ Rows Left TJ Row Count TJ Rows Done Time Est. Specifies the... ID of the host machine. session number in which rollback is in progress. ID of the user who has initiated the session. 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 194. AMP on which the maximum number of Transient Journal rows are left to be processed. maximum number of rows left to be processed in the Transient Journal for the specific session on any AMP. number of rows processed in the Transient Journal for the specific session. 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 Session User ID Performance Group AMP W/Count :0481 M 1 TJ Rows Left TJ Rows Done Time Est ,478 1,098 01:37 Utilities 181

182 Chapter 22: Recovery Manager (rcvmanager) LIST ROLLBACK TABLES Table ID Name :3883 "rcv_user1"."cr_in001" 0000:388B "rcv_user1"."cr_in002" 0000:3884 "rcv_user1"."cr_ri001"* 0000:3889 "rcv_user1"."cr_ri002"* SYSTEM RECOVERY ROLLBACK TABLE LIST Host Session TJ Row Count ,032 Table ID Name :045A "EmployeeDB"."Parent_Table"* 0005:045B "EmployeeDB"."Temp_Table" * - Referential Integrity table, cannot be used in CANCEL ROLLBACK ON TABLE command. 182 Utilities

183 Chapter 22: Recovery Manager (rcvmanager) 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... STATUS Provides... 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 183

184 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS Report Information Example 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. ONLINE TRANSACTION RECOVERY JOURNAL COUNTS at 13:49:28 98/02/06 Recovery AMP Session Count W/Count , , 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. 184 Utilities

185 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS The following table describes the Header and first-line data. Data AMP to be caught up Pass Current Pass Next Pass Description 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. 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. 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. 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 185

186 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS The following table describes the second data line (AMP Status). Data Online Catchup Offline Catchup Not In Recovery Description 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. 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. This AMP is not running down AMP recovery; it is physically offline. The following table describes the third data line (AMP Recovery Status Line). Data Transaction Recovery: ZZZ,ZZZ,ZZ9 TJ Rows Rebuilding Table [DBase.Table]: Z9% complete in this pass Change Row Recovery: Z9% complete in this pass Between Passes Miscellaneous OJ Processing Down Description 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. 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. 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. 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. Indicates that time is spent processing the various short running OJ entries, for example, releasing host utility locks. 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. 186 Utilities

187 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS Data Not currently executing recovery Description 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 Next Pass caught up Pass OJ CJ OJ CJ ,531 - AMP Status: Not in recovery - Down Utilities 187

188 Chapter 22: Recovery Manager (rcvmanager) 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... STATUS proc-id Provides... 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. 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. 188 Utilities

189 Chapter 22: Recovery Manager (rcvmanager) 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. Data Row Count Description The number of rows in the table to be rebuilt. Utilities 189

190 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS proc-id Data Status Name Description 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. 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 Next Pass caught up Pass OJ CJ OJ CJ ,531 - AMP Status: Not in recovery - Down 190 Utilities

191 Chapter 22: Recovery Manager (rcvmanager) LIST STATUS proc-id TABLES TO BE REBUILT Row Count Status Name ,598 "RESCRIBE"."Rescribe11" 897,598 "RESCRIBE"."Rescribe12" 897,598 "RESCRIBE"."Rescribe13" 897,598 "RESCRIBE"."Rescribe14" ,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 ,216 "RESCRIBE"."Rescribe10" 161,216 "RESCRIBE"."Rescribe30" 161,216 "RESCRIBE"."Rescribe20" 161,216 "RESCRIBE"."Rescribe12" 161,216 "RESCRIBE"."Rescribe32" 161,216 "RESCRIBE"."Rescribe22" 161,216 "RESCRIBE"."Rescribe14" ,128,512 total rows. There is insufficient data to estimate the rebuild time. Utilities 191

192 Chapter 22: Recovery Manager (rcvmanager) 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. 192 Utilities

193 Chapter 22: Recovery Manager (rcvmanager) 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 193

194 Chapter 22: Recovery Manager (rcvmanager) ROLLBACK SESSION...PERFORMANCE GROUP 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 host_id,session_id A A PERFORMANCE GROUP Perf_Group_Name ; 1102A140 Syntax element... host_id session _id Perf_Group_Name Specifies the... identifiers for the host and session whose Performance Group you want to see or set. You must specify both these identifiers in the order mentioned: host_id followed by a comma and session _id. The session _id maximum is 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 195. 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 19: Priority Scheduler (schmon) (SLES 10 only). 194 Utilities

195 Chapter 22: Recovery Manager (rcvmanager) ROLLBACK SESSION...PERFORMANCE GROUP 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 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. 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. Utilities 195

196 Chapter 22: Recovery Manager (rcvmanager) ROLLBACK SESSION...PERFORMANCE GROUP 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. Enter command, "QUIT;" or "HELP;" : 196 Utilities

197 CHAPTER 23 Resource Check Tools (dbschk, nodecheck, syscheck) 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 dbschk nodecheck syscheck syscheckrc Description A standalone tool that monitors the Teradata Database response time. 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. A standalone tool that analyzes relevant Teradata Database system data from the local node. 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. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Utilities 197

198 Chapter 23: 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 -delay sleep_seconds Description 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 Displays a short description of dbschk and the command-line options. 198 Utilities

199 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) dbschk Syntax Element -job job_program Description 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 -logflush flush_seconds 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). 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 199

200 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) dbschk Syntax Element -power switch -rate attempts -reset -save -timeout wait_seconds Description 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. 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. 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. 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. 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. 200 Utilities

201 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) dbschk Syntax Element -trigger trigger_program Description 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 Example 1 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. 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 timeout : 300 seconds rate : 5 trials delay : 1200 seconds logflush : 3600 seconds job : csp -mode list -source table logfile : /var/opt/teradata/tdtemp/dbschk.log trigger : pdestate -a Utilities 201

202 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 timeout : 300 seconds rate : 5 trials delay : 1200 seconds logflush : 3600 seconds job : csp -mode list -source table logfile : stdout trigger : pdestate -a Factory default values : power : OFF timeout : 300 seconds rate : 5 trials delay : 1200 seconds logflush : 3600 seconds job : csp -mode list -source table logfile : D:\Program Files\Teradata\Tdat\TdTemp\dbschk.log trigger : pdestate -a Do you want to save the new settings as dbschk default values? (y/n): y New settings saved... (dbschk): Normal termination - OK 202 Utilities

203 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 timeout : 300 seconds rate : 5 trials delay : 5 seconds logflush : 3600 seconds job : csp -mode list -source table logfile : stdout trigger : pdestate -a Factory default values: power : OFF timeout : 300 seconds rate : 5 trials delay : 1200 seconds logflush : 3600 seconds job : csp -mode list -source table logfile : /var/opt/teradata/tdtemp/dbschk.log trigger : pdestate -a 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: /13/(12351) csp: * 2007/05/24-09:23: /13/(12191) csp: * 2007/05/24-09:15: /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: /13/(12351) csp: * 2007/05/24-09:23: /13/(12191) csp: * 2007/05/24-09:15: /0/(11215) (dbschk): retstatus = 1020, status = 0, childpid = 1020 (dbschk): Sample Query finished normally, response time=2 seconds, (dbschk): Normal termination - OK Utilities 203

204 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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. -h Provides basic help on command line options. -I Lists threshold values for -nodeonly and -timercontrol tunables. 204 Utilities

205 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 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 205

206 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 FREESWAP 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 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 WARN -0 ALERT -0 BNSBLKQ WARN 500 ALERT 100 FREEMEM WARN ALERT -500 FREESWAP WARN ALERT MSGEVCOUNT WARN 100 ALERT 300 RXMSGFC WARN 90 ALERT Utilities

207 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) nodecheck SEGTBLFULL WARN 80 ALERT 100 -timercontrol SARSAMPLE 5 SARSLEEP 2 TDNSTATSAMPLE 2 TDNSTATSLEEP 5 Example 3 The following is an example of running syscheck with the -I option to display -nodeonly and -timercontrol tunables. nodecheck -I Tunable WARN ALERT AMPWT <=0 <=0 BNSBLKQ >=500 >=100 FREEMEM <=1000 <=500 FREESWAP <=2000 <=1000 MSGEVCOUNT >=100 >=300 RXMSGFC >=90 >=100 SEGTBLFULL >=80 >=100 Tunable Value SARSAMPLE 5 SARSLEEP 2 TDNSTATSAMPLE 2 TDNSTATSLEEP 5 Example 4 The following is an example of running nodecheck with the -L option. nodecheck -L Writing to log file: /tpi-data/nodecheck.8 Reading Node Resources... please wait... Which Linux are we: SuSE FreeMemory(Pages) and FreeSwap(Blocks) /usr/bin/sar -r 2 5 FREEMEM FREESWAP 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 Utilities 207

208 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) nodecheck 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 5 The following is an example of running nodecheck with the -v option. nodecheck -v Reading Node Resources... please wait... Which Linux are we: SuSE FreeMemory(Pages) and FreeSwap(Blocks) /usr/bin/sar -r 2 5 FREEMEM FREESWAP 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 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 208 Utilities

209 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) nodecheck 0 RXGRPSEG 0 RXP2PSEG Evaluating results... please wait... Resource Current Current Threshold Vproc Number/ Description Level Value Value Message Type FreeMemory(Pages) OK FreeSwap(Blocks) OK PDE Msg Daemon Queue Length OK 0 BNS Block Queue Length OK 0 Available AMP Worker Tasks OK 55 0 Available AMP Worker Tasks OK 56 1 Available AMP Worker Tasks OK 56 2 Available AMP Worker Tasks OK 56 3 Available AMP Worker Tasks OK 56 4 Available AMP Worker Tasks OK 56 5 BNS Msg Reject%(FC) OK 0 RXGRPREC BNS Msg Reject%(FC) OK 0 RXGRPSEG BNS Msg Reject%(FC) OK 0 RXP2PREC BNS Msg Reject%(FC) OK 0 RXP2PSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXGRPSEG BNS Msg Reject%(SEGTBLFULL) OK 0 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 Which Linux are we: SuSE FreeMemory(Pages) and FreeSwap(Blocks) /usr/bin/sar -r 2 5 FREEMEM FREESWAP 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 Utilities 209

210 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) nodecheck 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... Resource Current Current Threshold Vproc Number/ Description Level Value Value Message Type FreeMemory(Pages) OK FreeSwap(Blocks) OK PDE Msg Daemon Queue Length OK 0 BNS Block Queue Length OK 0 Available AMP Worker Tasks OK 55 0 Available AMP Worker Tasks OK 56 1 Available AMP Worker Tasks OK 56 2 Available AMP Worker Tasks OK 56 3 Available AMP Worker Tasks OK 56 4 Available AMP Worker Tasks OK 56 5 BNS Msg Reject%(FC) OK 0 RXGRPREC BNS Msg Reject%(FC) OK 0 RXGRPSEG BNS Msg Reject%(FC) OK 0 RXP2PREC BNS Msg Reject%(FC) OK 0 RXP2PSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXGRPSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXP2PSEG Messages nodecheck displays the following types of messages. The message... Error Warning Appears... 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. invalid information is found during processing of the syscheckrc file or for other reasons. 210 Utilities

211 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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. -h Provides basic help on command line options. -I Lists threshold values for -nodeonly and -timercontrol tunables. Utilities 211

212 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 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: 212 Utilities

213 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 216. 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 Current Current Threshold Vproc Number Description Level Value Value Message Type FreeMemory(Pages) WARN 992 <=1000 Utilities 213

214 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck Example 2 Example 3 Example 4 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 WARN -0 ALERT -0 BNSBLKQ WARN 500 ALERT 100 FREEMEM WARN ALERT -500 FREESWAP WARN ALERT MSGEVCOUNT WARN 100 ALERT 300 RXMSGFC WARN 90 ALERT 100 SEGTBLFULL WARN 80 ALERT 100 VPRPAGES WARN -2 ALERT -0 -timercontrol SARSAMPLE 1 SARSLEEP 1 TDNSTATSAMPLE 1 TDNSTATSLEEP 1 The following is an example of running syscheck with the -I option to display -nodeonly and -timercontrol tunables. syscheck -I Tunable WARN ALERT AMPWT <=0 <=0 BNSBLKQ >=500 >=100 FREEMEM <=1000 <=500 FREESWAP <=2000 <=1000 MSGEVCOUNT >=100 >=300 RXMSGFC >=90 >=100 SEGTBLFULL >=80 >=100 VPRPAGES <=2 <=0 Tunable Value SARSAMPLE 1 SARSLEEP 1 TDNSTATSAMPLE 1 TDNSTATSLEEP 1 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 No tunables show status of WARN or ALERT Example 5 syscheck -v 214 Utilities

215 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck Processing resource values for any status... please wait... NODE ID: localhost Example 6 - Windows Resource Current Current Threshold Vproc Number/ Description Level Value Value Message Type FreeMemory(Pages) OK 3158 FreeSwap(Blocks) OK PDE Msg Daemon Queue Length OK 0 BNS Block Queue Length OK 0 Available AMP Worker Tasks OK 55 0 Available AMP Worker Tasks OK 56 1 BNS Msg Reject%(FC) OK 0 RXGRPREC BNS Msg Reject%(FC) OK 0 RXGRPSEG BNS Msg Reject%(FC) OK 0 RXP2PREC BNS Msg Reject%(FC) OK 0 RXP2PSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXGRPSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXP2PSEG 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 Current Current Threshold Vproc Number/ Description Level Value Value Message Type FreeMemory(Pages) OK 3207 FreeSwap(Blocks) OK PDE Msg Daemon Queue Length OK 0 BNS Block Queue Length OK 0 Available AMP Worker Tasks OK 55 0 Available AMP Worker Tasks OK 56 1 BNS Msg Reject%(FC) OK 0 RXGRPREC BNS Msg Reject%(FC) OK 0 RXGRPSEG BNS Msg Reject%(FC) OK 0 RXP2PREC BNS Msg Reject%(FC) OK 0 RXP2PSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXGRPSEG BNS Msg Reject%(SEGTBLFULL) OK 0 RXP2PSEG Utilities 215

216 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) 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 218. The default syscheckrc file is read and processed at the following locations. On... Linux Windows The default syscheckrc file is located in the... /usr/pde/etc directory. 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 Utilities

217 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck FREEMEM WARN ALERT -500 FREESWAP WARN ALERT MSGEVCOUNT WARN 100 ALERT 300 RXMSGFC WARN 90 ALERT 100 SEGTBLFULL WARN 80 ALERT 100 VPRPAGES WARN -2 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 2 SARSAMPLE 5 TDNSTATSLEEP 5 TDNSTATSAMPLE 2 The -testdriver section maps to the executables of each node and is different, depending on the platform. Caution: 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 218. The following table describes each system resource attribute. System Resource Attribute AMPWT BNSBLKQ FREEMEM FREESWAP MSGEVCOUNT RXMSGFC Description Warning and alert threshold level for available (or running out) of AMP work tasks (AWTs). Warning and alert threshold level for BNS services in BNS block queue. Warning and alert threshold levels for freemem pages. Warning and alert threshold levels for freeswap blocks. Warning and alert threshold levels for message count in PDE message event queue. Warning and alert threshold for percentage of message count being flow controlled at the receiver side. Utilities 217

218 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck System Resource Attribute SEGTBLFULL Description 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: 1 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.) 2 Use a text editor to modify your new file. 218 Utilities

219 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck Custom syscheckrc File Example The following is an example of a custom-modified syscheckrc file. nodecheck -D -nodeonly AMPWT WARN -3 ALERT -0 BNSBLKQ WARN 300 ALERT 600 FREEMEM WARN -500 ALERT -250 FREESWAP WARN ALERT -500 MSGEVCOUNT WARN 200 ALERT 400 RXMSGFC WARN 75 ALERT 100 SEGTBLFULL WARN 75 ALERT 100 -timercontrol SARSAMPLE 1 SARSLEEP 1 TDNSTATSAMPLE 1 TDNSTATSLEEP 1 You can also specify a customized resource configuration file for syscheck and nodecheck to use by specifying the -r option with the configuration file s 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 219

220 Chapter 23: Resource Check Tools (dbschk, nodecheck, syscheck) syscheck 220 Utilities

221 CHAPTER 24 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. Lock information can also be monitored and displayed using the Lock Viewer portlet in Teradata Viewpoint. For more information, see Teradata Viewpoint User Guide. Runs From Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Teradata Viewpoint Remote Console portlet Host Utility Console 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. 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: 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. Utilities 221

222 Chapter 24: Show Locks (showlocks) Interpreting the Show Locks Display Locks are placed at the cluster level during a CLUSTER dump. 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. Interpreting the Show Locks Display 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 Version 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 222 Utilities

223 Chapter 24: Show Locks (showlocks) Conflicts accounting.invoice USER ADMIN MODE Read AMP All AMPs parts USER PETERS MODE Read AMP 24 personnel.employee USER ACCMGR MODE Excl AMP 27 service USER DBC MODE Excel AMP 3 --ShowLocks Processing Complete-- 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... ADMIN Placed the lock on the... 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. 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... xxxx yyyy Is... either a Write or Exclusive lock. DBC, DBC.TVM, or DBC.DBase. After reporting a conflict, Show Locks terminates. Utilities 223

224 Chapter 24: Show Locks (showlocks) Conflicts 224 Utilities

225 CHAPTER 25 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. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. 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 236. 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 225

226 Chapter 25: Table Rebuild (rebuild) Rebuilding Tables Locking During Rebuilds 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 239. 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 all data or primary data is being rebuilt, an exclusive lock is placed on the database or table. If an AMP is online while fallback data is being rebuilt, a write lock is placed on the database or table. If the AMP is offline, a read lock is used in all cases. 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. 226 Utilities

227 Chapter 25: Table Rebuild (rebuild) Table Rebuild Utility Commands Table Rebuild Utility Commands Table Rebuild presents a command-line environment that allows the entry of the following commands. Command REBUILD AMP REBUILD AMP FALLBACK TABLES RESTART REBUILD Description Rebuilds all tables, a selected table, or all tables in a selected database for a specified AMP. Rebuilds only tables with fallback protection. 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 229 and REBUILD AMP FALLBACK TABLES on page 236. 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: 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. Utilities 227

228 Chapter 25: Table Rebuild (rebuild) Table Rebuild Utility Commands To recover the table, restore it from the latest archive. If restoring from an archive is not an option, contact the Teradata Support Center. When a table is marked by the Reconfig utility as being in an invalid state and not redistributable, there is no guarantee that the rows in the table are where they should be. Table Rebuild cannot rebuild the table, and displays Unable to rebuild due to pending Reconfig Abort of table tablename. In these cases, before rebuilding the table you should first recover these tables by restoring them from the latest archive, or drop these tables. 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 AMP s 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> - Rebuild all tables on an AMP <F3> - Rebuild all data tables in a database <F4> - Rebuild a single table <F5> - Rebuild fallback protected tables only <F6> - Rebuild a previous rebuild after a system restart <F7> - General 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. 228 Utilities

229 Chapter 25: Table Rebuild (rebuild) REBUILD AMP REBUILD AMP Purpose Rebuilds data on a specified AMP. The rebuild operation can include: All tables on the AMP For a specified database: Primary, fallback, or both types of data in a specified database For a specified table: Primary, fallback, or both types of data, down regions, table header, or a specific range of rows Syntax REBUILD AMP nnnn ALL TABLES dbase dbase.tbl ALL DATA ALL DATA PRIMARY DATA FALLBACK DATA A dbase.tbl DOWN REGION ; TABLE HEADER lock_wait_minutes row range A 3 ;, LOG INTO logdbase.logtbl, NO LOCK ON NO FALLBACK TABLES, WITH DATABASE LOCK, WITH TABLE LOCK, WITH ROWRANGE LOCK, IN PARALLEL n TABLES A row range SUBTABLE subtable_id ROWRANGE start_rowid end_rowid AUTOADJUSTBLOCKS A Utilities 229

230 Chapter 25: Table Rebuild (rebuild) REBUILD AMP Syntax element nnnn ALL TABLES dbase dbase.tbl ALL DATA PRIMARY DATA FALLBACK DATA DOWN REGION Specifies the number of the AMP that is to be rebuilt. 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 233. 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. 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. 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. 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. 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. to rebuild only the down regions of the specified table. Down regions are ranges of rows for which Teradata Database has detected file system errors. The rows are marked as down, and their data can be rebuilt from fallback copies. 230 Utilities

231 Chapter 25: Table Rebuild (rebuild) REBUILD AMP Syntax element TABLE HEADER SUBTABLE subtable_id ROWRANGE start_rowid end_rowid Specifies to rebuild the table header on the specified AMP. At least one AMP in the system must be online. Information in fields 4, 6, and 10 of the table header row may be lost as a result of the rebuild. For more information on these fields, see Database Design. to rebuild a specific subtable. subtable_id is a non-zero 16-bit number in hexadecimal format that identifies the subtable to be rebuilt. For example, 400 represents the primary data subtable of the specified table, and 800 represents the fallback data subtable for the primary data. Rebuilds the specified range of rows. The format for a row ID comprises five hexadecimal values: partition number: a 64-bit number in hexadecimal format, or 0 for a non-partitioned table hash0: 16-bit hexadecimal number hash1: 16-bit hexadecimal number unique0: a 16-bit hexadecimal number unique1: a 16-bit hexadecimal number Each hexadecimal value can optionally include an H suffix. Examples of valid row IDs: 0H B334 4BFA B334H 4BFA 00H 01 0H B334H 4BFAH 0H 1H 0 B334 4BFA 0 1 AUTOADJUSTBLOCKS lock_wait_minutes LOG INTO logdbase.logtbl specifies that Table Rebuild should automatically adjust the specified row range to include complete blocks if the specified row range starts or ends in the middle of a bad block. If this option is not specified and a row range starts or ends in the middle of a bad data block, REBUILD returns an error. the amount of time in minutes that Table Rebuild should wait to obtain a table lock. The default is zero, which means REBUILD waits indefinitely. 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 234. Utilities 231

232 Chapter 25: Table Rebuild (rebuild) REBUILD AMP Syntax element NO LOCK [ON NO FALLBACK TABLES] WITH DATABASE LOCK WITH TABLE LOCK WITH ROWRANGE LOCK Specifies 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. 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. that a table-level read lock will be placed on the source AMP table to be used to rebuild the corrupted table. Note: This option is valid only with the ALL TABLES option. 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: This option is valid only with the ALL TABLES option. For a partitioned table, a rowrange lock is not used. A table-level lock is used instead. 232 Utilities

233 Chapter 25: Table Rebuild (rebuild) REBUILD AMP Syntax element [n TABLES] IN PARALLEL Specifies 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 239), 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. 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 Utilities: Volume 1 (A-K). 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. 2 Restart the Teradata Database. Note: This step is not necessary if the rebuilding AMP state was FATAL before the last Teradata Database restart. 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 Utilities 233

234 Chapter 25: Table Rebuild (rebuild) REBUILD AMP 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 or 16383, depending on the system. Note: Hex numbers can also be specified by appending a trailing x (for example, 0x, 3FFx). 4 Start Table Rebuild and run an ALL TABLES rebuild on this AMP. 5 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. 6 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 SET TABLE logdb.logtbl, 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(600) CHARACTER SET UNICODE) /* message text */ PRIMARY INDEX (MsgDate, MsgTime); Column MsgDate and MsgTime MsgAMP MsgCode MsgText Contents The system date and time when the message was generated. Together these columns comprise a non-unique primary index for the log table. The four-digit vproc number of the rebuilding AMP. A single character code indicating the type of rebuild message. See below. The text of the rebuild message. 234 Utilities

235 Chapter 25: Table Rebuild (rebuild) REBUILD AMP MsgCode is one of the following values: Value Meaning A normal message D E J N R S 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 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 235

236 Chapter 25: Table Rebuild (rebuild) REBUILD AMP FALLBACK TABLES REBUILD AMP FALLBACK TABLES 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 REBUILD AMP nnnn FALLBACK TABLES A A 3 ;, LOG INTO logdbase.logtbl, WITH DATABASE LOCK, WITH TABLE LOCK, WITH ROWRANGE LOCK, IN PARALLEL n TABLES 1102B221 Syntax element nnnn FALLBACK TABLES LOG INTO logdbase.logtbl Specifies the number of the AMP vproc to be rebuilt. 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. 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 Utilities

237 Chapter 25: Table Rebuild (rebuild) REBUILD AMP FALLBACK TABLES Syntax element WITH DATABASE LOCK WITH TABLE LOCK WITH ROWRANGE LOCK [n TABLES] IN PARALLEL Specifies 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. that a table-level read lock will be placed on the source AMP table to be used to rebuild the corrupted table. 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. 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 Utilities: Volume 1 (A-K). 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, Utilities 237

238 Chapter 25: Table Rebuild (rebuild) REBUILD AMP FALLBACK TABLES 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, MsgText VARCHAR(600) CHARACTER SET UNICODE 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 D E J N R S 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. 238 Utilities

239 Chapter 25: Table Rebuild (rebuild) 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 nnnn Specifies 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. Utilities 239

240 Chapter 25: Table Rebuild (rebuild) RESTART REBUILD 240 Utilities

241 CHAPTER 26 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. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. 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 241

242 Chapter 26: 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. 242 Utilities

243 Chapter 26: Task List (tsklist) 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: 7 ProcessID: 3edd VprocID(RelVpr): 0(1) Flags: 4100 scpstart Part: 8 ProcessID: 3edf VprocID(RelVpr): 0(1) Flags: 4100 utadvtsk Part: 9 ProcessID: 3ecf VprocID(RelVpr): 0(1) Flags: 4100 fsustart Part: 11 ProcessID: 3ed7 VprocID(RelVpr): 0(1) Flags: 4100 actmain Part: 15 ProcessID: 3ec4 VprocID(RelVpr): 0(1) Flags: 4100 sssmain Part: 17 ProcessID: 3ecb VprocID(RelVpr): 0(1) Flags: 4100 sssrss Part: 7 ProcessID: 3ede VprocID(RelVpr): 1(2) Flags: 4100 scpstart Part: 8 ProcessID: 3ee0 VprocID(RelVpr): 1(2) Flags: 4100 utadvtsk Part: 9 ProcessID: 3ed5 VprocID(RelVpr): 1(2) Flags: 4100 fsustart Part: 11 ProcessID: 3ed8 VprocID(RelVpr): 1(2) Flags: 4100 actmain Part: 7 ProcessID: 3ee1 VprocID(RelVpr): 16383(3) Flags: 4100 scpstart Part: 8 ProcessID: 3ee4 VprocID(RelVpr): 16383(3) Flags: 4100 rtsmain Part: 12 ProcessID: 3ee3 VprocID(RelVpr): 16383(3) Flags: 4100 sestsk Part: 13 ProcessID: 3ee2 VprocID(RelVpr): 16383(3) Flags: 4100 disstart Part: 10 ProcessID: 3ebf VprocID(RelVpr): 8192(4) Flags: 4100 gtwgateway Example 2 Task List running in summary mode to show all processes. > tsklist -as Part: 0 ProcessID: 3e85 VprocID(RelVpr): 16384(0) Flags: 880 pdemain Part: 0 ProcessID: 3eb5 VprocID(RelVpr): 16384(0) Flags: 4184 segmain Part: 0 ProcessID: 3eb6 VprocID(RelVpr): 16384(0) Flags: 4184 cfgmain Part: 0 ProcessID: 3ec1 VprocID(RelVpr): 16384(0) Flags: 4184 dmp Part: 0 ProcessID: 3ec0 VprocID(RelVpr): 16384(0) Flags: 4104 dbgsrvr Part: 0 ProcessID: 3ec2 VprocID(RelVpr): 16384(0) Flags: 4104 csp Part: 0 ProcessID: 3ed9 VprocID(RelVpr): 16384(0) Flags: 4104 udfsrvtsk Part: 0 ProcessID: 3eda VprocID(RelVpr): 16384(0) Flags: 4104 udfsrvtsk Part: 0 ProcessID: 3edb VprocID(RelVpr): 16384(0) Flags: 4104 udfsrvtsk Part: 0 ProcessID: 3edc VprocID(RelVpr): 16384(0) Flags: 4104 udfsrvtsk Part: 2 ProcessID: 3ebd VprocID(RelVpr): 16384(0) Flags: 4100 cnscim Part: 7 ProcessID: 3ec3 VprocID(RelVpr): 16384(0) Flags: 4100 cspslave Part: 0 ProcessID: 3ebb VprocID(RelVpr): 0(1) Flags: 4000 pdevproc Part: 7 ProcessID: 3edd VprocID(RelVpr): 0(1) Flags: 4100 scpstart Part: 8 ProcessID: 3edf VprocID(RelVpr): 0(1) Flags: 4100 utadvtsk Part: 9 ProcessID: 3ecf VprocID(RelVpr): 0(1) Flags: 4100 fsustart Part: 11 ProcessID: 3ed7 VprocID(RelVpr): 0(1) Flags: 4100 actmain Part: 15 ProcessID: 3ec4 VprocID(RelVpr): 0(1) Flags: 4100 sssmain Part: 17 ProcessID: 3ecb VprocID(RelVpr): 0(1) Flags: 4100 sssrss Part: 0 ProcessID: 3ebc VprocID(RelVpr): 1(2) Flags: 4000 pdevproc Part: 7 ProcessID: 3ede VprocID(RelVpr): 1(2) Flags: 4100 scpstart Part: 8 ProcessID: 3ee0 VprocID(RelVpr): 1(2) Flags: 4100 utadvtsk Part: 9 ProcessID: 3ed5 VprocID(RelVpr): 1(2) Flags: 4100 fsustart Part: 11 ProcessID: 3ed8 VprocID(RelVpr): 1(2) Flags: 4100 actmain Utilities 243

244 Chapter 26: Task List (tsklist) Examples Part: 7 ProcessID: 3ee1 VprocID(RelVpr): 16383(3) Flags: 4100 scpstart Part: 8 ProcessID: 3ee4 VprocID(RelVpr): 16383(3) Flags: 4100 rtsmain Part: 12 ProcessID: 3ee3 VprocID(RelVpr): 16383(3) Flags: 4100 sestsk Part: 13 ProcessID: 3ee2 VprocID(RelVpr): 16383(3) Flags: 4100 disstart Part: 10 ProcessID: 3ebf VprocID(RelVpr): 8192(4) Flags: 4100 gtwgateway Example 3 > tsklist -p 15 Task List running to show task information on programs running in partition 15. Part: 15 ProcessID: 3ec4 VprocID(RelVpr): 0(1) Flags: 4100 sssmain Pid: TaskID: 0001 Flags: 1000 main is paused Pid: TaskID: 0002 Flags: 0 (admin) is in adminwait Pid: 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: e c8bc0 Seq: 0 Tasks: 3 Admin: KTCB: e a67600 ReqKTCB: e a66058 Args: Pid: TaskID: 0001 Flags: 1000 main is paused KTCB: e a67398 Handle: d98 Dbg: 0 Prio: 0 WakeReason: 0 WakeCode: WorkType: 254 WorkEst: 0 FSG: nios=0 preios=0 logios=2 nsegs=0 SEG: nsegs=2 Pid: TaskID: 0002 Flags: 0 (admin) is in adminwait KTCB: e a67600 Handle: da6 Dbg: 0 Prio: 0 WakeReason: 0 WakeCode: WorkType: 254 WorkEst: 0 FSG: nios=0 preios=0 logios=0 nsegs=0 SEG: nsegs=0 Pid: TaskID: 0006 Flags: 0 sssacctg is in msgwait KTCB: e a5920 Handle: f26 Dbg: 0 Prio: 0 WakeReason: 0 WakeCode: WorkType: 254 WorkEst: 0 FSG: nios=0 preios=0 logios=0 nsegs=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: 0 ProcessID: 3e85 VprocID(RelVpr): 16384(0) Flags: 880 pdemain Part: 0 ProcessID: 3ebb VprocID(RelVpr): 0(1) Flags: 4000 pdevproc Part: 0 ProcessID: 3ebc VprocID(RelVpr): 1(2) Flags: 4000 pdevproc Example 6 Task List running to show only pdemain task information. > tsklist pdemain Part: 0 ProcessID: 3e85 VprocID(RelVpr): 16384(0) Flags: 880 pdemain 244 Utilities

245 Chapter 26: Task List (tsklist) Examples Pid: TaskID: 0001 Flags: 0 main is busy running Pid: TaskID: 0002 Flags: 0 logd is busy in syscall Pid: TaskID: 0006 Flags: 0 tparesetd is busy in tdnio Pid: TaskID: 0007 Flags: 0 msgkevd_start is busy in msgevd Pid: TaskID: 0008 Flags: 0 msgkmsg_main is busy in msgwait Pid: TaskID: 000b Flags: 0 trad_mainloop is busy in traread Pid: TaskID: 0010 Flags: 0 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: 0 ProcessID: 3e85 VprocID(RelVpr): 16384(0) Flags: 880 pdemain Pid: TaskID: 0001 Flags: 0 main is busy running Pid: TaskID: 0002 Flags: 0 0x a0fa0 is busy in syscall Pid: TaskID: 0006 Flags: 0 0x e750 is busy in tdnio Pid: TaskID: 0007 Flags: 0 0xc e154d0 is busy in msgevd Pid: TaskID: 0008 Flags: 0 0x b3f0 is busy in msgwait Pid: TaskID: 000b Flags: 0 0x f260 is busy in traread Pid: TaskID: 0010 Flags: 0 0x e000 is busy in syswait Utilities 245

246 Chapter 26: Task List (tsklist) Examples 246 Utilities

247 CHAPTER 27 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. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Syntax tdlocaledef -input filename -output filename new Gt15b004 tdlocaledef -reverse current filename -source filename 1102A145 Utilities 247

248 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) Syntax Syntax element... Is... -input filename -output filename -output new -reverse current -reverse 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 249. 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. 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 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 /etc/opt/teradata/tdconfig. 248 Utilities

249 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) 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 in SQL. SDF quoted strings are delimited by the quotation mark (U+0022) and can specify almost any Unicode character accepted by Teradata Database. However note the following restrictions: Characters within SDF quoted strings are limited to the printable 7-bit ASCII characters (U+0020, U+0021 and U+0023 through U+007E). The quotation mark itself (U+0022) cannot be used within an SDF quoted string. Utilities 249

250 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File SDF Elements The reverse solidus (\) character(u+005c) does not represent itself, but instead can be used to specify Unicode characters above U+009F. The sequence \uxxxx specifies the corresponding Unicode character U+ XXXX, where XXXX is the hexadecimal for the Unicode character. Formats are restricted to valid formats as specified insql Data Types and Literals. 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. 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. 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 ShortDays LongDays ; { "short_day_name" } ; Gt15b007 { "long_day_name" } Gt15b008 short_day_name is one of seven abbreviated names for the days of the week in the native language. These names can vary in length. You must have seven. 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. 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. Example: LongDays {"Sunday";"Monday";"Tuesday"; "Wednesday";"Thursday";"Friday"; "Saturday"} 250 Utilities

251 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... Description ShortMonths LongMonths ; { "short_month_name" } Gt15b009 ; { "long_month_name" } Gt15b010 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"} long_month_name is one of 12 full names for the months of the year in the native language. 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. RadixSeparator { "radix_separator_character" } Gt15b012 These names can vary in length. You must have both. Example: AMPM {"AM";"PM"} 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 251

252 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... GroupSeparator GroupingRule { "group_separator_character" } { "grouping_rule_number" } Gt15b013 Gt15b014 Description 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 {","} 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 grouping shall 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 is formatted as 123,456, GroupingRule {"3,2,-1"} For GroupingRule { 3,2,-1 }, the numeric value is formatted as 1234,56, Utilities

253 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... Description Currency ISOCurrency { "currency_symbol" } Gt15b015 { "iso_currency_abbrev" } Gt15b016 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 {"$"} iso_currency_abbrev is a string representing the local currency as an uppercase three-character code from ISO You are responsible for verifying that the string is specified in ISO 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: ISOCurrency {"USD"} Utilities 253

254 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... CurrencyName { "currency_name" } Gt15b017 Description currency_name is a string representing the local currency as a completely spelled out currency name. 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: CurrencyName {"US Dollars"} CurrencyRadixSeparator { "currency_radix_separator_character" } Gt15b018 currency_radix_separator_character is a character that separates the integer and fractional part of monetary strings. Separators cannot contain the following: 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 {"."} 254 Utilities

255 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... CurrencyGroupSeparator CurrencyGroupingRule { "currency_group_separator_character" } Gt15b019 { "currency_grouping_rule_number" } Gt15b020 Description currency_group_separator_character is a character that separates groups of digits in the integer part of monetary strings. Separators cannot contain the following: plus sign (+) minus sign (-) digits E (by itself) e (by itself) Example: CurrencyGroupSeparator {","} 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"} DualCurrency { "dual_currency_symbol" } Gt15b021 dual_currency_symbol is a string representing the dual 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: DualCurrency {"$"} Utilities 255

256 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... DualISOCurrency { "dual_iso_currency_abbrev" } Gt15b022 Description dual_iso_currency_abbrev is a string representing the dual currency as a three-character code from ISO You are responsible for verifying that the string is specified in ISO 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: DualISOCurrency {"USD"} DualCurrencyName { "dual_currency_name" } Gt15b023 dual_currency_name is a string representing the dual currency as a completely spelled out currency name. 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: DualCurrencyName {"US Dollars"} BYTEINT { "byteint_default_format" } Gt15b024 byteint_default_format is a string representing the default format applied to BYTEINT data types. Example: BYTEINT {"-(3)9"} 256 Utilities

257 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... Description INTEGER SMALLINT BIGINT NUMERIC { "integer_default_format" } Gt15b026 { "small_integer_default_format" } Gt15b025 { "big_integer_default_format" } 1102A144 { "numeric_decimal_default_format" } Gt15b027 integer_default_format is a string representing the default format applied to INTEGER data types. Example: INTEGER {"-(10)9"} small_integer_default_format is a string representing the default format applied to SMALLINT data types. Example: SMALLINT {"-(5)9"} big_integer_default_format is a string representing the default format applied to BIGINT data types. Example: BIGINT {"-(19)9"} 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 {" E-999"} Utilities 257

258 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) SDF File Syntax element... Description DATE TIME { "date_default_format" } { "time_default_format" } Gt15b029 Gt15b030 date_default_format is a string representing the default format applied to DATE and PERIOD(DATE) data types. Example: DATE {"YY/MM/DD"} 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"} TIMESTAMP TimeZoneString { "timestamp_default_format" } Gt15b031 { "time_zone_string"; time_zone_rules } 1102A248 timestamp_default_format is a string representing the default format applied to TIMESTAMP, TIMESTAMP WITH TIME ZONE, and PERIOD(TIMESTAMP) data types. Example: TIMESTAMP {"YYYY-MMDDBHH:MI:SS.S(F)Z"} time_zone_string names a time zone or GMT offset. 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"; "2"; "4"; "4"; "1"; "0"; "0"; "02:00:00"; "3"; "10"; "0"; "0"; "-1"; "02:00:00"; "1987"; "2006"; "-8"; "0"; "-7"; "0"; "4"; "3"; "8"; "0"; "0"; "02:00:00"; "4"; "11"; "1"; "0"; "0"; "02:00:00";"2007"; "9999"; "-8"; "0"; "-7"; "0"} Note: Rules in sample time zone strings cover years from 1987 to If you need the rules to cover years prior to 1987, you can modify the samples and add additional rules. 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. 258 Utilities

259 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) Example SDF Files Syntax element... Description NUMBER { "number_default_format" } 1102A253 number_default_format is a string representing the default format applied to NUMBER data types. Example: NUMBER {"FN9"} Example SDF Files Example 1 This example shows the Teradata Database default formatting settings. // File name : tdlocaledef.txt // Purpose : This file contains the specifications for data formatting(sdf) // defined by the user. // Scope : Project - subsystems // Required files: None // History : Created // Added BIGINT // 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"; Utilities 259

260 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) 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 {","} CurrencyGroupingRule {"3"} DualCurrency {"$"} DualISOCurrency {"USD"} DualCurrencyName {"US Dollars"} // Data type default formats BYTEINT {"-(3)9"} INTEGER {"-(10)9"} SMALLINT {"-(5)9"} BIGINT {"-(19)9"} NUMERIC {"--(I).9(F)"} REAL {" E-999"} DATE {"YY/MM/DD"} TIME {"HH:MI:SS.S(F)Z"} TIMESTAMP {"YYYY-MM-DDBHH:MI:SS.S(F)Z"} NUMBER {"FN9"} // System Time Zone string TimeZoneString {""} 260 Utilities

261 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) Example SDF Files Example 2 Customized SDF for Japanese Data Formatting // DBS System Formatting Data // Day and month names 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. 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"; Utilities 261

262 Chapter 27: Teradata Locale Definition Utility (tdlocaledef) Example SDF Files } "\u5348\u5f8c"; // Parsing Elements RadixSeparator {"."} GroupSeparator {","} GroupingRule {"3"} Currency {"\u00a5"} ISOCurrency {"JPY"} CurrencyName {"Yen"} CurrencyRadixSeparator {"."} CurrencyGroupSeparator {","} CurrencyGroupingRule {"3"} DualCurrency {"\u00a5"} DualISOCurrency {"JPY"} DualCurrencyName {"Yen"} // Data type default formats BYTEINT {"-(3)9"} INTEGER {"G-(I)9"} SMALLINT {"G-(I)9"} BIGINT {"G-(I)9"} NUMERIC {"G--(I)D9(F)"} REAL {"G-9D E-999"} DATE {"YYYY\u5E74MM\u6708DD\u65E5"} TIME {"HH\u6642MI\u5206SSDS(F)\u79D2Z"} TIMESTAMP {"YYYY\u5E74MM\u6708DD\u65E5BHH\u6642MI\u5206SSDS(F)\u79D2Z"} NUMBER {"FN9"} // System Time Zone string TimeZoneString {""} 262 Utilities

263 CHAPTER 28 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 Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Linux command line For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Syntax tdnstat -a -C -F -G -q t -v -d n -M -R -t -c min -z -Z 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. Utilities 263

264 Chapter 28: 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. t n 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. Teradata Network Statistics Displays 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 1 To view statistics, type the following: 264 Utilities

265 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays tdnstat Depending on your system, output similar to the following appears: STATS SNAPSHOT DISPLAY : Sun Feb 29 09:19: BNS PagePool Statistics : PAGE COUNT 214 PAGE REQUESTS 184 PAGE REQ_LONGEST 1 BNS BlockQueue Statistics : BLKQ BLK_CNT 452 BLKQ UBLK_CNT 452 BNS ArrayTable Statistics : OBJ CHN_INUSE 191 OBJ CHN_PAGES 7 OBJ CHN_GET 193 OBJ CHN_PUT 2 OBJ GRP_INUSE 129 OBJ GRP_PAGES 2 OBJ GRP_GET 197 OBJ GRP_PUT 68 OBJ GSM_INUSE 5 OBJ GSM_PAGES 1 OBJ GSM_GET 152 OBJ GSM_PUT 147 BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT CHN GET CHN PUT CHN FIRST CHN SIGNAL CHN READ CHN SET CHN UNASS CHN COUNT CHN SIGINIT CHN GRPCNT GRP GET GRP PUT GRP ENTER GRP LEAVE GRP INVALID GRP TEST GRP VALID GRP COUNT GRP IMPLENTR GRP TPASYNC GSM GET GSM PUT GSM DECR Utilities 265

266 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays GSM INCR GSM READ GSM WRITE GSM ATOMIC MRG CLEAR MRG INIX MRG MOVE MRG SENDREQ MRG SENDROW MSG TXGRPSEG MSG TXP2PSEG MSG TXGRPREC MSG TXP2PREC MSG RXGRPSEG MSG RXP2PSEG MSG RXGRPREC MSG RXP2PREC NET CHKBYDEST CFG SELCOORD CFG SELTPA RX MSG Service Statistics : RXGRPSEG MultiPackets = 9 10 % GlobalWork = % Received_Data = 1808 KB 100 % RXP2PSEG MultiPackets = 45 2 % Received_Data = KB 100 % RXGRPREC GlobalWork = % ChnNotReady = 1 0 % SBR_FCount = 84 4 % BitBucket_Num = 85 4 % BitBucket_Data = 19 KB 8 % Received_Data = 195 KB 91 % RXP2PREC ChnNotReady = 3 0 % InBandMsgs = % Received_Data = 529 KB 100 % TX MSG Service Statistics : TXGRPSEG MultiPackets = 5 13 % GlobalWork = % TXP2PSEG MsgToLocal = % MultiPackets = 49 1 % TXGRPREC ChnNotReady = 1 0 % COR_FCount = % MsgToLocal = 1 0 % ProcGroup = 1 0 % GlobalWork = % TXP2PREC MsgToLocal = % InBandMsgs = % 266 Utilities

267 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays Example 2 To view all TDN statistics, including Reservation Flow Control (RFC) Statistics, type the following: tdnstat -a Depending on your system, output similar to the following appears: STATS SNAPSHOT DISPLAY : Tue Feb 24 17:10: BNS PagePool Statistics : PAGE COUNT 189 PAGE REQUESTS PAGE REQ_LONGEST 1 BNS BlockQueue Statistics : BLKQ BLK_CNT 652 BLKQ UBLK_CNT 652 BNS ArrayTable Statistics : OBJ CHN_INUSE 163 OBJ CHN_PAGES 6 OBJ CHN_GET 163 OBJ GRP_INUSE 129 OBJ GRP_PAGES 2 OBJ GRP_GET 131 OBJ GRP_PUT 2 OBJ GSM_PAGES 1 OBJ GSM_GET 78 OBJ GSM_PUT 78 BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT CHN GET CHN PUT CHN FIRST CHN SIGNAL CHN READ CHN SET CHN UNASS CHN COUNT CHN SIGINIT CHN GRPCNT GRP GET GRP PUT GRP ENTER GRP LEAVE GRP INVALID GRP TEST GRP VALID GRP COUNT GRP IMPLENTR Utilities 267

268 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays GRP TPASYNC GSM GET GSM PUT GSM DECR GSM INCR GSM READ GSM WRITE MRG CLEAR MRG INIX MRG MOVE MRG SENDREQ MRG SENDROW MSG TXGRPSEG MSG TXP2PSEG MSG TXGRPREC MSG TXP2PREC MSG RXGRPSEG MSG RXP2PSEG MSG RXGRPREC MSG RXP2PREC NET FSHBYDEST NET FSHBYSRC NET CHKBYDEST NET CHKBYSRC CFG SELCOORD CFG SELTPA RX MSG Service Statistics : RXGRPSEG MultiPackets = 33 2 % GlobalWork = % Received_Data = KB 100 % RXP2PSEG ChnNotReady = 19 0 % MultiPackets = % Received_Data = KB 100 % RXGRPREC GlobalWork = % ChnNotReady = 17 0 % BitBucket_Num = 17 0 % BitBucket_Data = 1 KB 0 % Received_Data = KB 99 % RXP2PREC ChnNotReady = 40 0 % InBandMsgs = % Received_Data = KB 100 % TX MSG Service Statistics : TXGRPSEG MsgToLocal = 2 0 % MultiPackets = 11 1 % GlobalWork = % ProcGroup = 4 0 % TXP2PSEG MsgToLocal = % MultiPackets = % TXGRPREC ChnNotReady = 4 0 % MsgToLocal = 1 0 % ProcGroup = 1 0 % 268 Utilities

269 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays GlobalWork = % TXP2PREC ChnNotReady = 6 0 % MsgToLocal = % InBandMsgs = % BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT MSG TXGRPSEG MSG TXP2PSEG MSG TXGRPREC MSG TXP2PREC MSG RXGRPSEG MSG RXP2PSEG MSG RXGRPREC MSG RXP2PREC MSG FCNOTIFY Reservation Flow Control Statistics : Date Start End Chn PtPs Brds Waits Retrys CPU OnLst OnNet OnBox /30 07:49:27 Active /30 07:49:27 Active 5c /30 07:49:26 Active /30 07:49:26 Active c10e /30 07:49:26 Active 092a /30 07:49:26 Active 021d /30 07:49:26 Active bf3d /30 07:49:26 Active 64c /30 07:49:26 Active 26f /30 07:49:26 Active /30 07:49:26 Active 4fe /30 07:49:26 Active e /30 07:49:26 Active 0caf /30 07:49:26 Active /30 07:49:26 Active 75dd /30 07:49:26 Active 6bb /30 07:49:26 Active 165e /30 07:49:26 Active f /30 07:49:26 Active a /30 07:49:26 Active d /30 07:46:55 07:47:22 6e0d /30 07:46:55 07:47:20 96b /30 07:26:57 07:31:44 1bc /30 07:26:57 07:31:43 66ae /30 07:26:57 07:31:43 8b9a /30 07:26:57 07:31:43 bb /30 07:26:57 07:31: /30 07:26:57 07:31:43 431d /30 07:26:57 07:31:43 d91a /30 07:26:57 07:31:43 d5a /30 07:26:57 07:31:43 75dd /30 07:26:57 07:31: /30 07:26:57 07:31:43 e3ac /30 07:26:57 07:31: /30 07:26:57 07:31:42 b09e /30 07:26:57 07:31: /30 07:26:57 07:31:40 5c Utilities 269

270 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays 01/30 07:26:57 07:31:36 3cfb /30 07:26:57 07:31:27 da7f /30 07:26:57 07:31:24 2f /30 07:26:57 07:31:02 7a /30 07:26:57 07:30:10 cb2a Example 3 To display the last 31 TDN merges that are completed, type the following: tdnstat -R Depending on your system, output similar to the following appears: STATS SNAPSHOT DISPLAY : Mon Mar 17 10:12: BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT MRG CLEAR MRG INIX MRG MOVE MRG SENDREQ MRG SENDROW Performance Summary of Last 31 Merges: Rows/Sec Bytes/Sec Rows Bytes PASS# USEC Utilities

271 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays AvgRows/Sec = 670 AvgBytes/Sec = Example 4 To display TDN message class-specific statistics, type the following: tdnstat -C Depending on your system, output similar to the following appears: STATS SNAPSHOT DISPLAY : Fri Oct 24 06:00: BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT MSG TXGRPSEG MSG TXP2PSEG MSG TXGRPREC MSG TXP2PREC MSG RXGRPSEG MSG RXP2PSEG MSG RXGRPREC MSG RXP2PREC MSG FCNOTIFY MSG Class Statistics : MSG_CLASS COUNT PERCENT HIGHEST CUR_CNT FC_CNT TRANSIENT PROCBOX HASHBOX GROUPBOX PROCCHAN HASHCHAN GROUPCHAN PRCGRPCHN P2PKMSG 85 0 Utilities 271

272 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays Example 5 To display BNS Message Service Statistics and Reservation Flow Control (RFC) Statistics, type the following: tdnstat -F Depending on your system, output similar to the following appears: STATS SNAPSHOT DISPLAY : Fri Jan 30 07:49: BNS Service Statistics : <OP> <SUBOP> TXCNT BLK LOCAL BLKQ TXAVG TXMAX RXCNT MSG TXGRPSEG MSG TXP2PSEG MSG TXGRPREC MSG TXP2PREC MSG RXGRPSEG MSG RXP2PSEG MSG RXGRPREC MSG RXP2PREC MSG FCNOTIFY Reservation Flow Control Statistics : Date Start End Chn PtPs Brds Waits Retrys CPU OnLst OnNet OnBox /30 07:49:27 Active /30 07:49:27 Active 5c /30 07:49:26 Active /30 07:49:26 Active c10e /30 07:49:26 Active 092a /30 07:49:26 Active 021d /30 07:49:26 Active bf3d /30 07:49:26 Active 64c /30 07:49:26 Active 26f /30 07:49:26 Active /30 07:49:26 Active 4fe /30 07:49:26 Active e /30 07:49:26 Active 0caf /30 07:49:26 Active /30 07:49:26 Active 75dd /30 07:49:26 Active 6bb /30 07:49:26 Active 165e /30 07:49:26 Active f /30 07:49:26 Active a /30 07:49:26 Active d /30 07:46:55 07:47:22 6e0d /30 07:46:55 07:47:20 96b /30 07:26:57 07:31:44 1bc /30 07:26:57 07:31:43 66ae /30 07:26:57 07:31:43 8b9a /30 07:26:57 07:31:43 bb /30 07:26:57 07:31: /30 07:26:57 07:31:43 431d /30 07:26:57 07:31:43 d91a /30 07:26:57 07:31:43 d5a /30 07:26:57 07:31:43 75dd Utilities

273 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays 01/30 07:26:57 07:31: /30 07:26:57 07:31:43 e3ac /30 07:26:57 07:31: /30 07:26:57 07:31:42 b09e /30 07:26:57 07:31: /30 07:26:57 07:31:40 5c /30 07:26:57 07:31:36 3cfb /30 07:26:57 07:31:27 da7f /30 07:26:57 07:31:24 2f /30 07:26:57 07:31:02 7a /30 07:26:57 07:30:10 cb2a The following table defines the columns. The column Date Start End PtPs Brds Waits Retrys CPU OnLst OnNet OnBox Is the date when the first message was received. time when the first message was received. time when the last message was received. number of inbound minicast messages that have been delivered to the message subsystem. number of inbound broadcast messages that have been delivered to the message subsystem. number of inbound messages that had to wait due to flow control. number of inbound message retries due to allocation failure. rough measure of per-message CPU overhead for flow control number of inbound messages currently waiting on the reservation list. number of inbound messages currently pending across the BYNET. 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 273

274 Chapter 28: Teradata Network Statistics (tdnstat) Teradata Network Statistics Displays 274 Utilities

275 CHAPTER 29 Teradata Network Tuner (tdntune) WARNING: 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 Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Linux command line For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Syntax tdntune -h get file set file 1102D021 Syntax element Description -h Displays the help for tdntune. Utilities 275

276 Chapter 29: Teradata Network Tuner (tdntune) Syntax Syntax element get [file] set file Description 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. 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. 276 Utilities

277 Chapter 29: Teradata Network Tuner (tdntune) Syntax Example To show TDN tunables, type the following at the command line: tdntune Depending on your system, output similar to the following appears: # Fri Jan 30 08:27: # GDO TDN TUNEABLES: # PAGE_LWM 128 PAGE_HWM 1500 PAGE_REQ 64 PAGE_REL 128 PAGE_MAX_REQS 4 PAGE_LMHR 1000 CHN_BLK_TICK 1 GRP_BLK_TICK 1 GSM_BLK_TICK 1 MRG_BLK_TICK 4 MSG_BLK_TICK 4 FC_P2PREC_BLK_TICK 4 FC_P2PSEG_BLK_TICK 4 FC_GRPREC_BLK_TICK 4 FC_GRPSEG_BLK_TICK 4 SVC_TIME_METHOD UNIX_TIME GWS_DISABLE 0 FCIN_P2PCHN_THRESHLD 5 FCIN_P2PCHN_INITVAL 255 FCIN_P2PGRP_THRESHLD 5 FCIN_P2PGRP_INITVAL 20 FCIN_GRP_THRESHLD 5 FCIN_GRP_INITVAL 20 FCIN_CHN_THRESHLD 5 FCIN_CHN_INITVAL 20 FCIN_RFC_ENABLE 1 FCIN_RFC_THRESHLD 20 FCOUT_THRESHLD 5 FCOUT_INITVAL 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 Utilities 277

278 Chapter 29: Teradata Network Tuner (tdntune) Syntax 278 Utilities

279 CHAPTER 30 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: 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 Caution: 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 Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm Linux command line For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Syntax tpareset -xit -x -exit -e -panic -p -nodump -dump -d -yes -y reason -stop -s -force -f -help -h 1102B230 Utilities 279

280 Chapter 30: 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 -xit -exit -stop -force Description Shuts down Teradata Database on all nodes of the system. The system must be explicitly restarted after the -x option is used. 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. 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. 280 Utilities

281 Chapter 30: TPA Reset (tpareset) Usage Notes Syntax element -panic -nodump -dump -yes reason -help Description 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. 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. 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. Suppresses the normal tpareset confirmation prompt. 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 (-). 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 (A-K). 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 281

282 Chapter 30: TPA Reset (tpareset) Usage Notes 282 Utilities

283 CHAPTER 31 Update DBC (updatedbc) The Update DBC utility, updatedbc, performs the following: In table DBASE DATABASESPACE Update DBC recalculates 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 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. The utility Update DBC Update Space Recalculates the maximum allowed values for permanent, temporary, and spool space. current usage for permanent, temporary, and spool space. Utilities 283

284 Chapter 31: 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 32: Update Space (updatespace). Runs From Update DBC runs from Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. 284 Utilities

285 CHAPTER 32 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 Update DBC Update Space Recalculates the maximum allowed values for permanent, temporary, and spool 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 31: Update DBC (updatedbc). Runs From Update Space runs from Database Window or comparable interface to the Teradata Database console subsystem, such as cnsterm. For general information on starting the utilities from different interfaces, see Appendix B: Starting the Utilities. Utilities 285

286 Chapter 32: 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 TEMPORARY ALL SPACE FOR ALL DATABASES ; dbname SPOOL SPACE FOR dbname PSPOOL 1102H401 Syntax element TEMPORARY ALL SPOOL PSPOOL Specifies to update only the temporary space. to update all the space. to update only the spool space. Note: Spool space can be calculated for a single database only. to update only the spool space that persists across restarts. SPACE FOR ALL DATABASES dbname specifies the name of the database(s) for which space is to be recalculated. all the databases in a system. 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. 286 Utilities

287 Chapter 32: Update Space (updatespace) Usage Notes For example: Desired Database Name Current Salary D'Augusta db1 db1."db2 Required Update Space Notation "Current Salary" "D'Augusta" "db1 "db1.""db2" "" """"" 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 287

288 Chapter 32: Update Space (updatespace) Usage Notes 288 Utilities

289 CHAPTER 33 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 Database Window or comparable interface to the Teradata Database console subsystem, 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 -? 1102A232 Syntax element Description -v Provides a detailed (verbose) description of verify_pdisks activity. -h (Help mode) Displays usage. -? (Help mode) Displays usage. Utilities 289

290 Chapter 33: 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. 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 0x46A BA31 *****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: 0x46A BA Utilities

291 Chapter 33: Verify Pdisks (verify_pdisks) Vconfig Text File Succesfully loaded libtvsaalloclib.so. This is node 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 0x46A BA31. *****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 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. Utilities 291

292 Chapter 33: Verify Pdisks (verify_pdisks) Vconfig Text File 292 Utilities

293 CHAPTER 34 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 AMP GTW Node PE RSG TVS Description Access module processors perform database functions, such as executing database queries. Each AMP owns a portion of the overall database storage. Gateway vprocs provide a socket interface to Teradata Database. 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. Parsing engines perform session control, query parsing, security validation, query optimization, and query dispatch. Relay Services Gateway provides a socket interface for relaying dictionary changes to the Teradata Meta Data Services utility. 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 293

294 Chapter 34: Vproc Manager (vprocmanager) Runs From 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. 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: , 1, to to 10, 16381, 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. 294 Utilities

295 Chapter 34: Vproc Manager (vprocmanager) Definitions of Terms Used in Vproc Manager FATAL* This VprocState indicates a lost I/O write. FATAL** This VprocState indicates an I/O read issue. 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 295

296 Chapter 34: Vproc Manager (vprocmanager) Definitions of Terms Used in Vproc Manager 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 296 Utilities

297 Chapter 34: Vproc Manager (vprocmanager) Definitions of Terms Used in Vproc Manager 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 ONLINE OFFLINE FATAL NONODE UTILITY NEWPROC ConfigStatus Online, Hold Down Catchup, Down, NewReady NewReady, NewDown, Null For an understanding of how vprocs behave during Teradata Database startup, see VprocState/ConfigStatus Transitions During Teradata Database Startup on page 298. 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 297

298 298 Utilities VprocState/ConfigStatus Transitions During Teradata Database Startup CONFIG-STATUS (prior to Teradata Database startup) Online Hold (AMP vprocs only) Catchup (AMP vprocs only) 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 314. ONLINE VprocState = ONLINE ConfigStatus = Online VprocState = ONLINE ConfigStatus -> Online This combination is inconsistent and will be transitioned as follows: IF (NOT RcvJrnl) THEN VprocState -> OFFLINE ConfigStatus -> Down ELSE IF (RestartKind = COLDWAIT) THEN VprocState = ONLINE ConfigStatus -> Online ELSE VprocState -> UTILITY ConfigStatus = Catchup VprocState (prior to Teradata Database startup) UTILITY (AMP vprocs only) VprocState -> ONLINE ConfigStatus = Online This combination is inconsistent and will be transitioned as follows: VprocState -> ONLINE ConfigStatus -> Online IF (NOT RcvJrnl) THEN VprocState -> OFFLINE ConfigStatus -> Down ELSE IF (RestartKind = COLDWAIT) THEN VprocState -> ONLINE ConfigStatus -> Online ELSE VprocState = UTILITY ConfigStatus = Catchup OFFLINE/FATAL/ NONODE VprocState = OFFLINE/ FATAL/NONODE ConfigStatus -> Down VprocState = OFFLINE/ FATAL/NONODE ConfigStatus -> Down VprocState = OFFLINE/ FATAL/NONODE ConfigStatus -> Down NEWPROC This combination is inconsistent and will be transitioned as follows: VprocState -> ONLINE ConfigStatus = Online This combination is inconsistent and will be transitioned as follows: VProcState -> ONLINE ConfigStatus -> Online This combination is inconsistent and will be transitioned as follows: VprocState -> UTILITY ConfigStatus = Catchup

299 Utilities 299 CONFIG-STATUS (prior to Teradata Database startup) Down NewReady NewDown ONLINE IF (VprocType = PE) THEN VprocState = ONLINE ConfigStatus -> Online ELSE IF (VprocType = AMP) THEN IF (NOT RECONFIG) AND RcvJrnl THEN VprocState -> UTILITY ConfigStatus -> Catchup ELSE IF (NOT RcvJrnl) THEN VprocState -> OFFLINE ConfigStatus = Down This combination is inconsistent and will be transitioned as follows: VProcState -> NEWPROC ConfigStatus = NewReady This combination is inconsistent and will be transitioned as follows: VprocState -> OFFLINE ConfigStatus = NewDown VprocState (prior to Teradata Database startup) UTILITY (AMP vprocs only) This vproc is currently undergoing an ALL TABLES REBUILD using the Table Rebuild utility program, therefore: VprocState = UTILITY ConfigStatus = Down Table Rebuild will set to it ONLINE/Online when it is complete. IF RECONFIG THEN VprocState = UTILITY ConfigStatus = NewReady ELSE This combination is inconsistent and will be transitioned as follows: VprocState -> NEWPROC ConfigStatus = NewReady This combination is inconsistent and will be transitioned as follows: VprocState --> OFFLINE ConfigStatus = NewDown OFFLINE/FATAL/ NONODE VprocState = OFFLINE/ FATAL/NONODE ConfigStatus = Down VprocState = OFFLINE/ FATAL/NONODE ConfigStatus -> NewDown VprocState = OFFLINE/ FATAL/NONODE ConfigStatus = NewDown NEWPROC This combination is inconsistent and will be transitioned as follows VprocState -> OFFLINE ConfigStatus = Down VprocState = NEWPROC ConfigStatus = NewReady VprocState = NEWPROC ConfigStatus -> NewReady

300 Chapter 34: Vproc Manager (vprocmanager) 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 options/arguments Can be a 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. Command BOOT HELP INITVDISK QUIT RESTART SET RESTART SET vproclist STATUS DBS STATUS DBS Orderby CN Description 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. Provides general help for Vproc Manager or detailed help if you specify an option. 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. Causes Vproc Manager to exit. Forces a database restart. Sets the restart type to use during the next system restart. Defines the new state of a vproc or new states for a list of vprocs. Reports the status of the Teradata Database. Reports the status of Online and NotOnline Teradata Database AMP vprocs ordered by cluster number. 300 Utilities

301 Chapter 34: Vproc Manager (vprocmanager) Vproc Manager Commands Command STATUS DBS Orderby HN STATUS DBS Orderby Nodeid STATUS NOTONLINE STATUS ONLINE STATUS PDE STATUS RESTART STATUS SYSSTATE STATUS vproclist STATUS Description Reports the status of Online and NotOnline Teradata Database PE vprocs ordered by host number. Reports the status of Online and NotOnline Teradata Database vprocs ordered by node id. Reports the status row for vprocs and nodes that are not fully online. Reports the status row for vprocs and nodes that are online. Reports the status of the PDE. Reports the current system RestartKind. Reports the current system state and the System Debugger, if it is attached. Reports the vproc status table row for the specified vproc or vprocs. Reports the Teradata Database Status Table and the PDE Status Table. Utilities 301

302 Chapter 34: Vproc Manager (vprocmanager) 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 B vprocid GS07B005 Syntax element vprocid Description The number that identifies the vproc to be rebooted. For a description of vprocids, see Definitions of Terms Used in Vproc Manager on page 294. 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 25: 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 63 s 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. 302 Utilities

303 Chapter 34: Vproc Manager (vprocmanager) 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 303

304 Chapter 34: Vproc Manager (vprocmanager) 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 ALL keyword Description Used to display the help text of the Vproc Manager in its entirety. 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 Enter a command, Help, or Quit: 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. 304 Utilities

305 Chapter 34: Vproc Manager (vprocmanager) HELP Example 2 Enter a command, Help, or Quit: help quit QUIT o This command causes the VprocManager utility program to exit. Example 3 Enter a command, Help, or Quit: 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 305

306 Chapter 34: Vproc Manager (vprocmanager) INITVDISK INITVDISK Purpose The INITVDISK command initializes the Teradata Database File System on the storage associated with a specific AMP, also known as the AMP s vdisk. This applies only to AMPs with a VprocState of FATAL or NEWPROC. The state of the specified AMP remains unchanged. Syntax INITVDISK I vprocid GS07B007 Syntax element vprocid Description The number that identifies the vproc to be initialized. For a description of vprocids, see Definitions of Terms Used in Vproc Manager on page 294. 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 Enter a command, Help, or Quit: INITVDISK 3 WARNING: This command will destroy all user and dictionary data of vproc 3 s 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. 306 Utilities

307 Chapter 34: Vproc Manager (vprocmanager) QUIT QUIT Purpose The QUIT command causes Vproc Manager to exit. Syntax QUIT Q 1102A216 Utilities 307

308 Chapter 34: Vproc Manager (vprocmanager) RESTART RESTART Purpose The RESTART command forces a database restart. Syntax RESTART R TPA NODUMP restartkind restart comment DUMP= YES NO 1102A153 Syntax element TPA NODUMP DUMP restartkind restart comment Description This option has no effect on the RESTART command. It is included for compatibility. A system dump will not occur. This is the default. Specifies whether a dump will occur: YES means a dump will occur. NO means no dump will occur. 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. 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 310 or the RESTART TPA command in the Database Window (DBW) chapter of Utilities: Volume 1 (A-K). To view the current system setting for RestartKind or Restart Type, see STATUS DBS on page 317. For additional information on stopping and restarting the system, see Database Administration. 308 Utilities

309 Chapter 34: Vproc Manager (vprocmanager) RESTART Example 1 The following example shows how to perform a COLD restart and specifies a reason why. Enter a command, Help, or Quit: RESTART COLD This is a test. The system will be restarted: Dump : NO RestartKind : COLD Reason : 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. Enter a command, Help, or Quit: RESTART DUMP = YES This is a test. The system will be restarted: Dump : YES RestartKind : COLD Reason : 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. Enter a command, Help, or Quit: RESTART The system will be restarted: DUMP : NO RestartKind : COLD Reason : System restarted by VprocManager. Utilities 309

310 Chapter 34: Vproc Manager (vprocmanager) SET RESTART SET RESTART Purpose The SET RESTART command sets the restart type to use during the next restart of the system. Syntax SET S RESTART R = restartkind GS07B011 Syntax element restartkind Description 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. For additional information, see RESTART on page 308. 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. 310 Utilities

311 Chapter 34: Vproc Manager (vprocmanager) 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 /V vproclist = vprocstate 1102A191 Syntax element Description /V Specifies the verbose mode of output, which includes more information. vproclist vprocstate A list of one or more vproc identifier numbers. For examples, see Definitions of Terms Used in Vproc Manager on page 294. 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. If the VprocState of an AMP or PE is changed from either OFFLINE or FATAL to ONLINE, and its ConfigStatus is Down either OFFLINE or FATAL to NEWPROC, and its ConfigStatus is NewDown ONLINE to either OFFLINE or FATAL NEWPROC to either OFFLINE or FATAL After the next system restart, the VprocState/ ConfigStatus is ONLINE/Online. The AMP will be in UTILITY/ Catchup state during recovery, immediately prior to ONLINE/Online. NEWPROC/NewReady. OFFLINE/Down or FATAL/Down. OFFLINE/NewDown or FATAL/NewDown. Utilities 311

312 Chapter 34: Vproc Manager (vprocmanager) 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. Current VprocState NONODE Desired VprocState NONODE OFFLINE ONLINE NEWPROC FATAL UTILITY No change. Not allowed. Not allowed. Not allowed. Not allowed. Not allowed. OFFLINE Not allowed. No change. Allowed. If Config- Status = Down, initiate recovery. Allowed if Config- Status = NewDown. Allowed. Not allowed. ONLINE Not allowed. Allowed. ConfigStatus will be Down after system restart. No change. Not allowed. Allowed. ConfigStatus will be Down after system restart. Not allowed. NEWPROC Not allowed. Allowed. ConfigStatus will be NewDown after system restart. Not allowed. No change. Allowed. Config Status will be NewDown after system restart. Not allowed. FATAL Not allowed. Allowed. Allowed. If ConfigStatus = Down, initiate recovery. Allowed if ConfigStatus = NewDown. No change. Not allowed. UTILITY Not allowed. Not allowed. Not allowed. Not allowed. Not allowed. No change. 312 Utilities

313 Chapter 34: Vproc Manager (vprocmanager) SET vproclist Example 1 This example shows how to take vprocs 0 and 1 offline. Enter a command, HELP or QUIT: set /v 0 to 1 offline Vproc 0 s 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 1 s 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. Enter a command, HELP or QUIT: set /v 1 online Vproc 1 s 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 313

314 Chapter 34: Vproc Manager (vprocmanager) 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 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. Column Vproc Number Rel. Vproc# Node ID Movable Crash Count Vproc State Config Status Config Type Description Uniquely identifies the vproc across the entire system. Represents the number of the vproc relative to the Node upon which the vproc resides. 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. This indicates whether the vproc can be migrated to another node in its defined clique if its primary node fails. 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. Represents the current PDE system state of the vproc. Displays the Teradata Database Logical Configuration Map Status of the vproc. Represents the Teradata Database Logical Configuration Map Type of a vproc. 314 Utilities

315 Chapter 34: Vproc Manager (vprocmanager) STATUS Column Cluster/Host No. RcvJrnl/Host Type TVS Vproc Description 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 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 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: 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. Column Node ID Node State Clique Number CPUs Memory (MB) CHANs LANs Description 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. The current state of the node, which is either ONLINE, DOWN, or STANDBY. The clique number for the node as defined using the Parallel Upgrade Tool (PUT). For more information, see the Parallel Upgrade Tool (PUT) Reference. The number of CPUs on the node. The total memory size in megabytes for the node (rounded up to the nearest integer). The number of channels attached to the node. The number of LANs attached to the node. Utilities 315

316 Chapter 34: Vproc Manager (vprocmanager) STATUS Column AMPs Node Name Description The number of AMPs running on the node. 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 Enter a command, HELP or QUIT: status SYSTEM NAME: teradata-1 07/12/21 19:13:42 DBS LOGICAL CONFIGURATION 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 * Yes 0 ONLINE Online AMP 0 On Yes 0 ONLINE Online AMP 0 On No 0 ONLINE N/A GTW 1 COP N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE Online PE 1 COP N/A * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD PDE PHYSICAL CONFIGURATION Node Node Clique Memory ID State Number CPUs (MB) CHANs LANs AMPs Node Name ONLINE localhost PDE State: RUN/STARTED 316 Utilities

317 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS STATUS DBS Purpose The STATUS DBS command reports the status of the Teradata Database. Syntax STATUS ST DBS 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. The following table shows the columns of the vproc status row. Column Vproc Number Rel. Vproc# Node ID Movable Crash Count Vproc State Config Status Config Type Cluster/Host No. Description Uniquely identifies the vproc across the entire system. Represents the number of the vproc number relative to the Node upon which the vproc resides. 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. This indicates whether the vproc can be migrated to another node in its defined clique if its primary node fails. Represents the number of times the vproc has crashed. Represents the current PDE system state of a vproc. Displays the Teradata Database Logical Configuration Map Status of a vproc. Represents the Teradata Database Logical Configuration Map Type of a vproc. 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 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 Utilities 317

318 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS Column RcvJrnl/Host Type TVS Vproc Description 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: IBM, COP, ATT3B, BULLHN, or OS1100. For AMP vprocs, displays the associated TVS vproc. Example Enter a command, HELP or QUIT: status dbs SYSTEM NAME: teradata-1 07/12/21 15:55:47 DBS LOGICAL CONFIGURATION 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 * Yes 0 ONLINE Online AMP 0 On Yes 0 ONLINE Online AMP 0 On No 0 ONLINE N/A GTW 1 COP N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE Online PE 1 COP N/A * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD 318 Utilities

319 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY CN 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 ST DBS 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 Vproc-Ids Range Crash Count CN No. Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Represents the number of times the vproc has crashed. Displays the cluster number for the AMP as defined using the Configuration Utility. The valid range of cluster numbers is 0 to The following table shows the columns of the NOTONLINE vproc status row. Column Vproc-Ids Range Crash Count Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Represents the number of times the vproc has crashed. Utilities 319

320 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY CN Column Vproc State Config Status Cluster Number Description Represents the current PDE system state of a vproc if the state is not online. Displays the Teradata Database Logical Configuration Map Status of a vproc. Displays the cluster number for the AMP as defined using the Configuration Utility. The valid range of cluster numbers is 0 to Example 320 Utilities

321 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY HN 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 ST DBS 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. The following table shows the columns of the ONLINE vproc status row. Column Vproc-Ids Range Crash Count Moveable Host Number Host Type Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Represents the number of times the vproc has crashed. Indicates whether the PE vproc can be migrated to another node in its defined clique if its primary node fails. Displays the host number that was assigned to the PE using the Configuration Utility. The valid range of host numbers is 1 to 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. Utilities 321

322 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY HN The following table shows the columns of the NOTONLINE vproc status row. Column Vproc-Ids Range Crash Count Moveable Vproc State Config Status Host Number Host Type Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Represents the number of times the vproc has crashed. Indicates whether the PE vproc can be migrated to another node in its defined clique if its primary node fails. Represents the current PDE system state of a vproc if the state is not online. Displays the Teradata Database Logical Configuration Map Status of a vproc. Displays the host number that was assigned to the PE using the Configuration Utility. The valid range of host numbers is 1 to 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 Enter a command, HELP or QUIT: status dbs orderby hn SYSTEM NAME: nirvana 08/12/21 15:29:09 DBS LOGICAL CONFIGURATION ONLINE PE vprocs ordered by Host No. - - Vproc-Ids Crash Host Host Range Count Moveable Number Type Yes 52 COP No 282 IBM 16353, 16357, 16359, 0 No 286 IBM , NOTONLINE PE vprocs ordered by Host No. - - Vproc-Ids Crash Vproc Config Host Host Range Count Moveable State Status Number Type Yes NONODE Down 52 COP No NONODE Down 282 IBM 16355, No NONODE Down 286 IBM 16352, No NONODE Down 289 IBM DBS State: Logons are enabled - Users are logged on DBS RestartKind: COLD 322 Utilities

323 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY NODEID 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 ST DBS 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. The following table shows the columns of the ONLINE vproc status row. Column Vproc-Ids Range Crash Count Node Ids Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Represents the number of times the vproc has crashed. 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. The following table shows the columns of the NOTONLINE vproc status row. Column Vproc-Ids Range Description 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 are used exclusively by the Teradata Database configuration. Vproc numbers greater than are used exclusively by PDE and are not included in the Teradata Database logical configuration. Utilities 323

324 Chapter 34: Vproc Manager (vprocmanager) STATUS DBS ORDERBY NODEID Column Crash Count Vproc State Config Status Node Ids Description Represents the number of times the vproc has crashed. Represents the current PDE system state of a vproc if the state is not online. Displays the Teradata Database Logical Configuration Map Status of a vproc. 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. Example Enter a command, HELP or QUIT: status dbs orderby nodeid SYSTEM NAME: nirvana 07/12/21 15:29:09 DBS LOGICAL CONFIGURATION ONLINE AMP and PE vprocs ordered by Node ID - - Vproc-Ids Crash Node Vproc-Ids Crash Node Range Count Ids Range Count Ids , 7, 11, , 6, 10, , 5, 9, , *, 4, 8, NOTONLINE AMP and PE vprocs orderby Node ID - - Vproc-Ids Crash Vproc Config Node Range Count State Status IDs , NONODE Down NONODE Down NONODE Down UTILITY CATCHUP NEWPROC NewReady FATAL** Down * 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. 324 Utilities

325 Chapter 34: Vproc Manager (vprocmanager) 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 The following table shows the columns of the vproc status row. Column Vproc Number Rel. Vproc# Node ID Can Move Crash Count Vproc State Config Status Config Type Cluster/Host No. Description Uniquely identifies the vproc across the entire system. Represents the number of the vproc relative to the Node upon which the vproc resides. 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. This indicates whether the vproc can be migrated to another node in its defined clique if its primary node fails. 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. Represents the current PDE system state of the vproc. Displays the Teradata Database Logical Configuration Map Status of the vproc. Represents the Teradata Database Logical Configuration Map Type of a vproc. 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 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 Utilities 325

326 Chapter 34: Vproc Manager (vprocmanager) STATUS NOTONLINE Column RcvJrnl/Host Type TVS Vproc Description 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: IBM COP ATT3B BULLHN OS1100 For AMP vprocs, displays the associated TVS vproc. Example Enter a command, HELP, or QUIT: status notonline SYSTEM NAME: teradata-1 09/09/14 14:38:04 DBS LOGICAL CONFIGURATION 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 Yes 0 OFFLINE Online AMP 2 On Utilities

327 Chapter 34: Vproc Manager (vprocmanager) 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. The following table shows the columns of the vproc status row. Column Vproc Number Rel. Vproc# Node ID Can Move Crash Count Vproc State Config Status Config Type Description Uniquely identifies the vproc across the entire system. Represents the number of the vproc relative to the Node upon which the vproc resides. 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. This indicates whether the vproc can be migrated to another node in its defined clique if its primary node fails. 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. Represents the current PDE system state of the vproc. Displays the Teradata Database Logical Configuration Map Status of the vproc. Represents the Teradata Database Logical Configuration Map Type of a vproc. Utilities 327

328 Chapter 34: Vproc Manager (vprocmanager) STATUS ONLINE Column Cluster/Host No. RcvJrnl/Host Type TVS Vproc Description 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 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 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: 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. Column Node ID Node State Clique Number CPUs Memory (MB) CHANs LANs AMPs Description 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. The current state of the node, which is either ONLINE, DOWN, or STANDBY. The clique number for the node as defined using the Parallel Upgrade Tool (PUT). For more information, see the Parallel Upgrade Tool (PUT) Reference. The number of CPUs on the node. The total memory size in megabytes for the node (rounded up to the nearest integer). The number of channels attached to the node. The number of LANs attached to the node. The number of AMPs running on the node. 328 Utilities

329 Chapter 34: Vproc Manager (vprocmanager) STATUS ONLINE Column Node Name Description 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 1 If all vprocs are online, the STATUS ONLINE command simply reports that. Enter a command, HELP or QUIT: 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. Enter a command, HELP or QUIT: status online SYSTEM NAME: teradata-1 07/12/21 19:13:42 DBS LOGICAL CONFIGURATION 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 * Yes 0 ONLINE Online AMP 0 On No 0 ONLINE N/A GTW 1 COP N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE Online PE 1 COP N/A * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD PDE PHYSICAL CONFIGURATION Node Node Clique Memory ID State Number CPUs (MB) CHANs LANs AMPs Node Name ONLINE localhost PDE State: RUN/STARTED Utilities 329

330 Chapter 34: Vproc Manager (vprocmanager) STATUS PDE STATUS PDE Purpose The STATUS PDE command reports the status of the PDE. Syntax STATUS ST PDE 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. Column Node ID Node State Clique Number CPUs Memory (MB) CHANs LANs AMPs Node Name Description 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. The current state of the node, which is either ONLINE, DOWN, or STANDBY. The clique number for the node as defined using the Parallel Upgrade Tool (PUT). For more information, see the Parallel Upgrade Tool (PUT) Reference. The number of CPUs on the node. The total memory size in megabytes for the node (rounded up to the nearest integer). The number of channels attached to the node. The number of LANs attached to the node. The number of AMPs running on the node. The network name for the node. 330 Utilities

331 Chapter 34: Vproc Manager (vprocmanager) STATUS PDE Example SYSTEM NAME: default_vconfig 03/01/21 13:35:49 PDE PHYSICAL CONFIGURATION Node Node Clique Memory ID State Number CPUs (MB) CHANs LANs AMPs Node Name ONLINE puthod1_bynet 4-07 ONLINE puthod2_bynet 4-08 ONLINE puthod3_bynet Node Node Clique Memory ID State Number CPUs (MB) CHANs LANs AMPs Node Name ^ STANDBY puthod4_bynet ^ Non-TPA Node PDE State: RUN/STARTED Utilities 331

332 Chapter 34: Vproc Manager (vprocmanager) STATUS RESTART STATUS RESTART Purpose The STATUS RESTART command reports the current system RestartKind setting. Syntax STATUS ST RESTART R GS07B019 Example Enter a command, HELP, or QUIT: status restart DBS RestartKind = COLD. 332 Utilities

333 Chapter 34: Vproc Manager (vprocmanager) 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 Enter a command, HELP, or QUIT: status sysstate DBS State: Logons are enabled - The system is quiescent PDE State: RUN/STARTED Utilities 333

334 Chapter 34: Vproc Manager (vprocmanager) 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 or vprocs, depending on the system, to be specified. This command does not display a vproc status row for undefined vprocs. Syntax STATUS ST vproclist GS07B015 Syntax element vproclist Description A list of one or more vproc identifiers. For examples, see Definitions of Terms Used in Vproc Manager on page 294. Usage Notes The following table shows the columns of the vproc status row. Column Vproc Number Rel. Vproc# Node ID Movable Crash Count Vproc State Config Status Config Type Description Uniquely identifies the vproc across the entire system. Represents the number of the vproc number relative to the Node upon which the vproc resides. 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. This indicates whether the vproc can be migrated to another node in its defined clique if its primary node fails. Represents the number of times the vproc has crashed. Represents the current PDE system state of a vproc. Displays the Teradata Database Logical Configuration Map Status of a vproc. Represents the Teradata Database Logical Configuration Map Type of a vproc. 334 Utilities

335 Chapter 34: Vproc Manager (vprocmanager) STATUS vproclist Column Cluster/Host No. RcvJrnl/Host Type TVS Vproc Description 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 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 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: IBM, COP, ATT3B, BULLHN, or OS1100. For AMP vprocs, displays the associated TVS vproc. Example 1 Enter a command, HELP or QUIT: status 1, 2, 8192 to SYSTEM NAME: teradata-1 07/12/21 15:55:47 DBS LOGICAL CONFIGURATION 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 * Yes 0 ONLINE Online AMP 0 On Yes 0 ONLINE Online AMP 0 On No 0 ONLINE N/A GTW 1 COP N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE N/A TVS 0 N/A N/A Yes 0 ONLINE Online PE 1 COP N/A * DBS Control AMP DBS State: Logons are enabled - The system is quiescent DBS RestartKind: COLD Utilities 335

336 Chapter 34: Vproc Manager (vprocmanager) STATUS vproclist Example 2 The following is an example status display for undefined vprocs. Enter a command, HELP, or QUIT: status 100 to 300 SYSTEM NAME: teradata-1 95/11/2911:12:16 STATUS command ignored: None of the specified Vprocs are defined. 336 Utilities

337 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 Spaces Punctuation Keywords and variables. UPPERCASE LETTERS represent a keyword. Syntax diagrams show all keywords for SQL statements 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 can be used to represent functions, methods, and other non- SQL keywords that can be entered in uppercase, lowercase or mixed case. 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. Use one space between items such as keywords or variables. 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 337

338 Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions 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 A Required Entries When you see a circled letter in a syntax diagram, go to the corresponding circled letter and continue reading. Required entries appear on the main path: FE0CA002 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 FE0CA Utilities

339 Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions If you can optionally choose from more than one entry, all the choices appear below the main path: READ SHARE ACCESS JC01A010 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:, 3, 4 ( cname ) JC01B012 Utilities 339

340 Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions Read loops from right to left. The following conventions apply to loops: IF... there is a maximum number of entries allowed there is a minimum number of entries required a separator character is required between entries a delimiter character is required around entries THEN... the number appears in a circle on the return path. In the example, you may type cname a maximum of 4 times. the number appears in a square on the return path. In the example, you must type at least three groups of column names. the character appears on the return path. If the diagram does not show a separator character, use one blank space. In the example, the separator character is a comma. 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 A HAVING con where_cond excerpt, cname, col_pos JC01A Utilities

341 Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions Multiple Legitimate Phrases In a syntax diagram, it is possible for any number of phrases to be legitimate: DATABASE TABLE VIEW dbname tname vname 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 CV cname LOCKING LOCK A dbname ACCESS B DATABASE FOR SHARE MODE tname IN READ TABLE WRITE vname EXCLUSIVE VIEW EXCL,, B SEL expr FROM tname qual_cond C.aname C HAVING cond ; qual_cond WHERE cond, GROUP BY cname, col_pos JC01A018 Utilities 341

342 Appendix A: How to Read Syntax Diagrams Syntax Diagram Conventions 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. 342 Utilities

343 APPENDIX B Starting the Utilities Teradata Database offers several interfaces from which the utilities may be started and run. Interface Database Window (DBW) Linux command line Host Utility Console (HUTCNS) Description 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 Teradata Viewpoint User Guide. Utilities that run directly from the command line are primarily those that operate on the PDE level of Teradata Database. HUTCNS runs a subset of utilities from a mainframe-attached host terminal. It runs only on the z/os operating system. Chapter names in the Utilities manuals 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. 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 Utilities 343

344 Appendix B: Starting the Utilities Starting Utilities from Database Window identifier of the DBW application window in which the utility is running. For more information on DBW, see Utilities Volume 1. 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 :0.0 & The DBW main window opens. 3 Click the Supvr button to open the Supervisor (supv) window. 344 Utilities

345 Appendix B: Starting the Utilities Starting Utilities from Database Window 4 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 (A-K). Utilities 345