Download (direct link):
For those sessions in which work is charged to AMPs, Teradata Manager displays:
• AMPState is non-idle.
This typically means that AMPState may be ACTIVE or BLOCKED.
• PEState in EXPORT sessions is UNKNOWN.
• AMPCPUSec and AMPIO (logical I/O) show resource usage.
The following table describes the three primary phases of a FastExport job and shows where resource usage occurs.
• In the data selection phase, the system processes the Teradata SQL SELECT request to retrieve a large amount of data from the Teradata server and to place the data into a spool file. The system performs most of the work on the AMPs in the Request SQL session. The minimal PE work done involves parsing.
• In the distribution phase, the system prepares data for return to the client. It is difficult to discern when this phase starts because no message is displayed. However, when the distribution phase completes, the Select execution completed message displays. In this phase, the system performs all work on the AMPs in the Request SQL session.
• In the data transfer phase, the AMPs return data to the client over multiple sessions. The system performs work during the n EXPORT sessions and charges that work to the AMPs. The system reports AMP resource usage for those EXPORT sessions, and reports the PEState as unknown.
B - 16 Teradata RDBMS Database Administration
Appendix B: Import/Export Utilities
Monitoring a FastLoad or MultiLoad Job
FastExport Phases Start of FastExport Phase Request SQL Session n EXPORT Sessions
Data selection Select request submitted to the DBC 1 The system charges work to AMPs. 2 In Teradata Manager, AMPState is ACTIVE; AMPCPU and AMPIO show resource usage.
Distribution 1 The system charges work to AMPs. 2 AMPCPU and AMPIO show resource usage.
Data transfer Select execution completed 1 The system charges work to AMPs. 2 AMPState or PEState is non-idle most of time; AMPCPU and AMPIO show resource usage
The FastExport client utility uses Log SQL session (not shown) to read the restart log in the event of a system restart so that the utility knows when to recover the job. Because the work performed is minimal, this session does not show resource usage.
The system performs work in two different partitions during the data transfer phase of a FastExport job:
Teradata SQL The system logs on two sessions under this partition.
EXPORT The system logs on n sessions under this partition. The number n is calculated as greater than one and less than or equal to the number of AMPs. Each session has a RunVProcNo associated with an AMP.
B - 16
Teradata RDBMS Database AdministrationAppendix C:
This appendix describes the various types of event logs and error logs you can use to identify problems on the system, including:
• Types of logs and their contents, including:
• Tables of node error logs
The node error logs are common to all Teradata installations.
• Administration Workstation (AWS) error logs
The AWS logs are applicable only to NCR WorldMark Massive Parallel | Processing (MPP) systems.
• Procedures for accessing some of these logs
• Information about verifying the BYNET
• Viewing the SW_Event_Log
Note: You can view Windows 2000 error logs using Windows 2000 Event Viewer. For more information on these logs and using the event viewer, consult your Windows 2000 help documentation.
Teradata RDBMS Database Administration
A - 1Appendix C: Error Logs
Log File Summary
Log File Summary
This section contains node and AWS error log information.
Note: The Cabinet Management Interface Controller (CMIC) Garbage Flag filters the bulk of CMIC messages and prevents them from being collected in the Console Log. Turn this flag ON for each cabinet.
Teradata RDBMS and Kernel Error Sequence
On UNIX, the system must pass messages for Teradata RDBMS errors through the logger daemon before inserting the errors into the log. Sometimes Teradata RDBMS errors can appear after error messages logged by the kernel, even though the Teradata RDBMS error actually occurred first.
This is particularly true when a Trusted Parallel Application (TPA) reset occurs. You usually see messages logged by kernel reset code in the log prior to the message for the event that initiated the reset.
Node Error Logs
This directory/file name ... Contains . And lasts .
/etc/.osm • A copy of most of the console output information. All console output information is stored in the /var/console/console.log file on the AWS. • Output from the reconcile utility. until the next reboot. During a reboot, the file /etc/.osm gets moved to /etc/.osm.old. Upon a second reboot, this information is lost.
/var/adm / streams/* files for each day of the year, uniquely identified with a month and day. Each file includes almost all system error, BYNET error, and PDE error. no more than two weeks. A UNIX cron job runs every Sunday night just after midnight, which renames all error* files to oerror* and deletes the old set of oerror files. If you disable the cron job, files accumulate until they fill up /var. If storage is unlimited, the date-unique filenames make these files good for one year.