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

Introduction to the Teradata® RDBMS for UNIX® Version 2 Release 2.1 - NCR

NCR Introduction to the Teradata® RDBMS for UNIX® Version 2 Release 2.1 - NCR, 1998. - 315 p.
Download (direct link): inntroduktionteradata1998.pdf
Previous << 1 .. 43 44 45 46 47 48 < 49 > 50 51 52 53 54 55 .. 76 >> Next

Access The requester does not care about the consistency of the data while it is accessing the database. An access lock permits modifications on the underlying data while the SELECT operation is in progress.

Introduction to the Teradata RDBMS for UNIX

10-7
Concurrency Control and Recovery

The Concept of the Lock

Teradata Automatic RDBMS Lock Levels

Deadlocks

This same information is illustrated below in tabular form.

Lock Lock Type Held
Request None Access Read Write Exclusive
Access Granted Granted Granted Granted Queued
Read Granted Granted Granted Queued Queued
Write Granted Granted Queued Queued Queued
Exclusive Granted Queued Queued Queued Queued

The Teradata RDBMS exerts most of its locks automatically.

The following table illustrates how the different locks are exerted for various types of SQL statements.

Type of SQL Statement Locking Level by Access Type Locking
UPI/NUPI/USI NUSI/Full Table Scan Mode
SELECT Row Hash Table Read
UPDATE Row Hash Table Write
DELETE Row Hash Table Write
INSERT Row Hash Not applicable Write
CREATE DATABASE DROP DATABASE MODIFY DATABASE Not applicable Database Exclusive
CREATE TABLE DROP TABLE ALTER TABLE Not applicable Table Exclusive

A deadlock occurs when transaction 1 places a lock on resource A, then needs to lock resource B. But resource B has already been locked by transaction 2, which in turn needs to place a lock on resource A. This state of affairs is called a deadlock, or a deadly embrace. The Teradata RDBMS resolves deadlocks by aborting one of the transactions. If the transaction originated from BTEQ, then BTEQ resubmits it. Any other client software may or may not resubmit the transaction.

10-8

Introduction to the Teradata RDBMS for UNIX
Concurrency Control and Recovery

Host Utility Locks

Introduction

HUT Lock Types

HUT Lock Characteristics

Host Utility Locks

The locking operation used by the Archive/Storage Facility (ASF2) and client-resident Archive/Recovery facilities are very different from those performed by the Teradata RDBMS. The locks are frequently referred to as HUT (for Host UTility) locks in the Teradata RDBMS manuals.

HUT locks are placed as follows.

Lock Type Object Locked
Read Any object being dumped.
Group Read Rows of a table being dumped if and only if the table is defined for an after-image permanent journal and you selected the appropriate option on the DUMP command.
Write Permanent journal table being restored.
Write All tables in a ROLLFORWARD or ROLLBACKWARD during recovery operations.
Write Journal table being deleted.
Exclusive Any object being restored.

HUT locks have the following characteristics.

• Associated with the currently logged-on user who entered the statement rather than with a job or transaction.

• Placed only on objects on the AMPs that are participating in a utility operation.

• Placed at the cluster level during a CLUSTER dump.

• Never conflict with a utility lock at another level that was placed on the same object for the same user.

• Remain active until they are released either by the RELEASE LOCK option of the utility command or by the execution of a Teradata SQL RELEASE LOCk statement after a utility operation completes.

• Automatically reinstated following a Teradata RDBMS restart if they had not been released.

Introduction to the Teradata RDBMS for UNIX

10-9
Concurrency Control and Recovery

System and Media Recovery

System and Media Recovery

Introduction

This topic describes how the Teradata RDBMS restarts itself after a system or media failure.

System Restarts

Unscheduled restarts occur for one of the following reasons:

• AMP or disk failure

• Software failure

• Parity error

All software recovery is effected in the same way. Hardware failures put the affected component offline and it remains so until repaired or replaced.

Two types of automatic recovery of transactions can occur when an Transaction Recovery unscheduled restart occurs:

• Single transaction recovery

• RDBMS recovery

The following table details when these two automatic recovery mechanisms take place.

This recovery type . . . Happens when . . .
single transaction the RDBMS aborted a single transaction because of: • Transaction deadlock timeout • User error • User-initiated abort command • An inconsistent data table • Unavailable resources for parsing Single transaction recovery uses the transient journal to effect its data restoration.
RDBMS a RDBMS restart is caused by: • Hardware failure • Software failure • User command

10-10

Introduction to the Teradata RDBMS for UNIX
Concurrency Control and Recovery

System and Media Recovery

Down AMP Recovery

When an AMP fails to come online during system recovery, the RDBMS continues to process transactions using fallback data. When the down AMP comes back online, down AMP recovery procedures begin to bring the data for the AMP up to date.
Previous << 1 .. 43 44 45 46 47 48 < 49 > 50 51 52 53 54 55 .. 76 >> Next