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

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 137 138 139 140 141 142 < 143 > 144 145 146 147 148 149 .. 218 >> Next

Windows 2000 system dump When the Windows 2000 operating system crashes, it displays a bright blue screen with crash messages. As with UNIX, this produces a full memory dump. The size of the dump is equal to the size of memory on your system. Windows 2000 system dumps are in %root%MEMORY.DMP (C:\WINNT\MEMORY.DMP is the default).

11 - 2

Teradata RDBMS Database Administration Chapter 11: Handling System Dumps

Forcing System Dumps

Forcing System Dumps

You can force a system crash or a TPA restart to recover from a system hang. The forced dump may provide useful information about why the system hung.

Before forcing a dump, you must first determine whether you need a system or PDE dump. You control the type of dump by the way you force the dump.

Select the dump type you need from the following table:

IF one or more of the following conditions exist ... THEN force this dump type . Using this tool .
The node is not responding The system is not making a PDE crashdump. (The system does not respond to input while it is making a PDE crashdump). System UNIX: Follow the process outlined in "Copying UNIX System Dumps to Media" on page 11-7
Windows 2000: <Ctrl><Alt><Delete>, choose Shut Down
Teradata RDBMS sessions are not progressing (the system is hung) New sessions cannot start The Administration Workstation (AWS) is responding The rlogin shell is responding. PDE It is important that you follow the instructions in "Forced Restarts" on page 9-5.

Teradata RDBMS Database Administration

11 - 3 Chapter 11: Handling System Dumps

Forcing System Dumps

Handling UNIX Dumps

Use the xctl utility to verify that system dumps are set up to be saved automatically. The Dump Type debug field should read as follows:

Field Name Value Purpose
Dump Type UNIX Save the UNIX System dump if UNIX panics.
System

If Dump Type has a different value, refer to Teradata RDBMS Utilities for instructions on how to change it.

UNIX tries to prevent new system dumps from writing over existing dumps that have not been saved. To control how the node manages dumps, you can:

Clear the dump device manually to allow new dumps to be taken.

Change the values of the dump area control options.

UNIX System Dump Process

The UNIX System dump process is as follows:

Stage Process
1 The system enters the Startup Subsystem (SUS).
2 The system saves hardware registers.
3 The system performs diagnostics.
4 The dump begins.
5 The bottom line of the screen shows the changing percentage of memory already dumped. Note: If the percentage stops incrementing, the dump is hung. To recover, turn off power to the node, then turn power back on. (The method you use to turn the system off and on may vary depending on your platform. For example, on an NCR 3500 or 4100 system, use the front panel power switch; on an MPP system, use the control screens on your AWS to cycle the power.)
6 When the dump is complete, the remaining SUS diagnostics run and the system boots normally.

11 - 4

Teradata RDBMS Database Administration 11 - 3 Chapter 11: Handling System Dumps

Forcing System Dumps

Clearing the UNIX Dump Area

Since a UNIX system dump fills the entire dump area, the system can take no other UNIX system dumps until you save the dump.

After a set interval, the system clears the dump area so that it can capture another dump. If necessary, you can clear the area manually before that time.

Your options are:

To permit a new dump to be captured before the automatic interval, manually clear the dump area with the command:

# /sbin/dumpsave -c

Note: This command does not alter the actual contents of the dump area. You can view it with the CRASH command until a new dump is taken.

Let the system clear the dump area automatically if a dump is still present a set period of time after it was captured.

By default, this time period is 24 hours, but you can alter this value, as well as other dump area management options, as described in the following section.

Customizing the UNIX Dump Area Control Options

Several options that affect UNIX system dump area management are defined in the file:

/etc/default/dump

Edit this file to change the default option values. You may want to change one or more of the following options (refer to the NCR UNIX MP-RAS documentation for editing instructions):

Option Comment
FLAG_TIMEOUT FLAG_TIMEOUT is the delay between taking the dump and automatic clearing of the dump. The default is 24 hours. Many Teradata RDBMS sites change this; 96 hours is a typical value.
TIME (Boot Message Timeout) Set this value to zero to suppress the boot-time message. (Any non-zero value only delays the boot process unnecessarily for that number of seconds.) The system boot process automatically displays a reminder that there is an unsaved, uncleared dump in the dump area and waits for the TIME period before continuing with the boot. UNIX issues this message because some systems use the same slices for Dump and Swap space. UNIX MP-RAS with Teradata RDBMS uses separate Dump and Swap slices. Thus, on TPA nodes there is no need to save a dump before booting.
Previous << 1 .. 137 138 139 140 141 142 < 143 > 144 145 146 147 148 149 .. 218 >> Next