in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 126 127 128 129 130 131 < 132 > 133 134 135 136 137 138 .. 218 >> Next

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 Administration Chapter 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 - 1 Chapter 10: Handling Teradata Crashdumps

Dump Types

Dump Types

System Dumps

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.

PDE Crashdumps

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.

DBS Dumps

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
Previous << 1 .. 126 127 128 129 130 131 < 132 > 133 134 135 136 137 138 .. 218 >> Next