Download (direct link):
• Status field to the DB Window
• DBC.Software_Event_Log (UNIX)
• / var / adm / streams (UNIX)
• /tpi-data/nodecheck.tpacycle_n (UNIX)
• ... \tdConfig\tpi-data\nodecheck.tpacycle_n (Windows 2000)
• Windows Event Log (which can be viewed with Windows Event Viewer)
Restarting Jobs with Identity Columns
If a restart occurs during a BTEQ import, BTEQ will re-submit the last uncompleted row insert after the system recovers from the restart. Numbering will continue from there. If a session abort occurs during a channel-attached BTEQ import, the last uncompleted row insert will not be re-submitted and associated data may be lost.
Associated data may also be lost if a network-attached BTEQ import session is aborted and there is no other session to re-submit through. In both cases of session abort, manually restarting the import can result in duplicate rows if rows newly inserted before the session abort are not deleted.
Restart Log Table
TPump works on multi-statement requests. Each request has a certain number of statements packed into it according to the PACK specification in the BEGIN LOAD command. In robust mode, each request is written into a restart log table.
9 - 10 Teradata RDBMS Database Administration
Chapter 9: Stopping and Restarting the System
Startup and Recovery
Because Teradata RDBMS guarantees either completion or rollback of all statements packed in a request, the restart log will always accurately reflect the completion status of a TPump import.
If a restart occurs, TPump will query the restart log table and re-execute requests that are not logged. Similarly for BTEQ inserts, it may be possible for a restart to cause such duplicates, as BTEQ may re-drive an insert request even if the previous insert has completed.
The duplicates will not be detected if the target table is not defined with a UPI. TPump in Simple Mode
TPump in simple mode does not utilize a restart log for restart recovery. TPump will flag an error if it is run in simple mode and the target table has an identity column PI.
This restriction is necessary because rows that are duplicates with the exception of the identity column could result if some requests are re-processed after restart recovery.
However, it cannot detect all cases of identity column inserts. One example is a DML statement on a non-identity table that triggers inserts into an identity column table.
9 - 10
Teradata RDBMS Database AdministrationChapter 10:
Handling Teradata Crashdumps
Snapshot dumps and PDE crashdumps originate from the Teradata TPA and therefore are applicable to both UNIX and Windows 2000 systems.
This chapter introduces the TPA dumps and describes how to manage and administer PDE crashdumps. Topics discussed cover:
• The types of crashdumps
• Special features available with snapshot dumps
• PDE crashdumps versus system dumps
• PDE crashdump location on UNIX and on Windows 2000
• Crashloop control and forcing dumps
• Saving crashdumps
• Copying formatted dump files to disk or tape
• Deleting dump files
Teradata RDBMS Database Administration
10 - 1Chapter 10: Handling Teradata Crashdumps
A system dump is the undigested contents of memory at the time of an OS crash. The content of the dump depends on your server operating system, as explained in "System Dump Types and Locations" on page 11-2.
A PDE crashdump is a selective dump of memory at the time of a Teradata RDBMS restart. When a Teradata RDBMS problem causes the system to restart, the system will take a PDE dump and write the contents of the dump to a default location.
PDE crashdumps provide only what information might be needed to analyze a problem within the Teradata PDE or RDBMS. It can also contain pages read in from swap space that are not in memory at the time of the dump. The exact content depends on the cause of the reset.
All nodes remain available on the BYNET while capturing a PDE crashdump. When the last node completes a PDE crashdump capture, the restart immediately continues.
If a node is out-of-service due to a hang condition or system crash, the Teradata TPA configuration window is not closed until a waiting period elapses.
This does not significantly change the amount of time it takes to capture the PDE dump, and saves downtime when a node is not available for reasons other than dump processing.
Snapshot Dump Facility
The Snapshot Dump facility captures the image of a failed process without requiring a TPA reset. It is written only on the originating node and is generated by:
• A PE, when statement processing encounters an error before execution steps have been distributed to the AMPs.
• An AMP, when step processing encounters an error.
The dump information is for one of the following, depending on what is important for the module that issued the dump request:
• The task that issued the snapshot dump request