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 .. 190 191 192 193 194 195 < 196 > 197 198 199 200 201 202 .. 218 >> Next


AMPState is non-idle.

This typically means that AMPState may be ACTIVE or BLOCKED.

AMPCPUSec and AMPIO (logical I/O) show resource usage.

The following table shows the primary resource usage and where the work is charged for the three major operations carried out in an ARC job:

ARC Statements 1 SQL Session n HUTPARSE Sessions 1 HUTCTL Session
DUMP (ARCHIVE) The system performs a System charges work to The system performs a
small amount of work. AMPs. small amount of work.
AMPState or PEState AMPState is non-idle; AMPState or PEState
looks IDLE most of the AMPCPU and AMPIO looks IDLE most of the
time and does not show resource usage. time and does not show
show resource usage. resource usage. Note that on NT there is a new optional Graphical User Interface (GUI) for a number of PDE tools including ctl.

B - 20

Teradata RDBMS Database Administration Appendix B: Import/Export Utilities

Monitoring an ARC Job

ARC Statements 1 SQL Session n HUTPARSE Sessions 1 HUTCTL Session
RESTORE The system performs a small amount of work. AMPState or PEState looks IDLE most of the time and does not show resource usage. System charges work to AMPs. AMPState is non-idle; AMPCPU and AMPIO show resource usage. The system performs some of work. AMPState is non-idle; AMPCPU and AMPIO show resource usage.
ROLLFORWARD/ ROLLBACK The system performs a small amount of work. AMPState or PEState looks IDLE most of the time and does not show resource usage. System charges work to AMPs. AMPState is non-idle; AMPCPU and AMPIO show resource usage.

Session Partitions Used

An ARC job uses one of three different session partitions, depending on whether the system performs a dump/restore or rollforward/rollback operation:

Partition Description
Teradata SQL Typically used in a manner similar to the Teradata SQL partition in FastLoad/MultiLoad. This session includes activity such as parsing, security checking, and controlling job execution. PEs mainly perform the work in this partition.
HUTPARSE Similar to the FASTLOAD partition. Within this partition, the same job has multiple sessions, which use AMP resources to transfer data during a dump/restore operation. AMPs mainly perform the work in this partition.
HUTCTL Special variation of the HUTPARSE partition. The system uses this partition when it does not require parallel execution of multiple sessions. The system uses only one HUTCTL session during an ARC job for operations such as rollback, rollforward, or build. AMPs mainly perform the work in this partition. Note that on NT there is a new optional Graphical User Interface (GUI) for a number of PDE tools including ctl.

B - 20 Teradata RDBMS Database Administration

Appendix B: Import/Export Utilities

Monitoring an ARC Job

Teradata Manager and ARC

As a general rule, ARC operations result in two classes of statements, and the class of statement determines which partitions become involved:

Statement Class Description
Low data volume transfer The system initially processes rollforward, rollback, and build operations during the Teradata SQL session.
Once the setup for the operation has completed, the system performs the actual work involved in the operation during the session associated with the HUTCTL Partition.
High data volume transfer Statements such as DUMP and RESTORE utilize a number of sessions to maximize the volume of data the system can transfer between the host (or client) and Teradata RDBMS in the minimum time. The system performs setup during the Teradata SQL session, and performs real work in the other partitions. HUTPARSE sessions transfer data for the Dump/Restore operation. The system uses the HUTCTL session for portions of the process not related to Teradata RDBMS to/from host (or client) data transfer.

Note that on NT there is a new optional Graphical User Interface (GUI) for a

number of PDE tools including ctl.

Some possibly unusual items might show up while monitoring sessions:

Not all partitions are actually used in all jobs.

Even during the data transfer portion of a DUMP operation, the system may not use all HUTPARSE sessions. If the number of HUTPARSE sessions is greater than the number of AMPs, the number of sessions actually used are a multiple of the number of AMPs. Other available HUTPARSE sessions remain idle.

Neither HUTPARSE nor HUTCTL sessions have a defined RunProcId (that is, the vproc(s) that executes the work initiated by these sessions changes from request to request).

The main oddity you might notice while monitoring sessions with Teradata

Manager is that ARC may not make even use of available AMP resources.

In the following situations, DiskReads, DiskWrites, CPUUse, and DiskUse are

noticeably higher on a subset of the AMPs than on other AMPs:

B - 20

Teradata RDBMS Database Administration Appendix B: Import/Export Utilities

Monitoring an ARC Job
Previous << 1 .. 190 191 192 193 194 195 < 196 > 197 198 199 200 201 202 .. 218 >> Next