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 .. 42 43 44 45 46 47 < 48 > 49 50 51 52 53 54 .. 76 >> Next


Application-initiated asynchronous aborts also cause full transaction rollback in the ANSI environment.

Introduction to the Teradata RDBMS for UNIX

10-3
Concurrency Control and Recovery

The Concept of the Transaction

Teradata Transactions

How to Undo an Update

Teradata transactions can be either implicit or explicit.

Multistatement requests and macros are examples of implicit transactions.

The sorts of transactions undertaken by embedded SQL applications are examples of explicit transactions. Consider the following COBOL program with embedded SQL and transactions (no COBOL code is shown, but the embedded SQL code is of the type required by COBOL SQL programs).

EXEC SQL

BEGIN TRANSACTION

END-EXEC

EXEC SQL

DELETE FROM Employee WHERE Name = 'Smith T'

END-EXEC EXEC SQL

UPDATE Department

SET EmpCount=EmpCount-1

WHERE DeptNo=500

END-EXEC

EXEC SQL

END TRANSACTION

END-EXEC

If an error were to occur during the processing of either the DELETE or UPDATE statement within the bEgIN TRANSACTION and END TRANSACTION statements, both Employee and Department tables would be restored to their states before the transaction began.

When an error occurs during a Teradata transaction, the entire transaction is rolled back.

An obvious question to ask is this: how do you undo an update once it has been made?

The answer is by applying a transaction log (or journal) to the database to write it back to its state before the transaction began. The journal contains before images of the database, which you can use to undo a transaction.

A transaction log of after images of the database can be used to redo a transaction.

Transactions begin and end at a checkpoint or synchronization point. The transaction recovery system uses these checkpoints to apply its data to exactly the right time to recover the database to an earlier (or later) state.

10-4

Introduction to the Teradata RDBMS for UNIX
Concurrency Control and Recovery

The Concept of the Lock

The Concept of the Lock

A lock is a means of claiming usage rights on some resource.

Introduction

There can be several different types of resources that can be locked and several different ways of locking those resources.

Most locks exerted on Teradata resources are locked automatically OvervieW of Teradata by default. Users can override some locks by making specific lock

RDBMS Locking specifications, but the overrides are allowed only when the integrity

of the data can be assured.

The type of lock exerted depends on the data integrity requirement of the request.

A request for a locked resource by another user is queued until the process using the resource releases its lock on that resource.

The Teradata lock manager implicitly locks the following objects.

Object Locked Description
Database Locks rows of all tables in the database
Table Locks all rows in the table and any index and fallback subtables
View Locks all underlying tables in the view
Row hash Locks the primary copy of a row (all rows that share the same hash code)

Introduction to the Teradata RDBMS for UNIX

10-5
Concurrency Control and Recovery

The Concept of the Lock

The best example of why locks are required for database Why is L°cking Required management systems in which multiple processes are accessing the

for Database Management same database is the well known lost update anomaly.

Systems? Consider the following picture.

Figure 10-1

Lost Update Anomaly.

Execution of Execution of

transaction T1 Database transaction T2

FG11A001

This is a classic example of a nonserializable set of transactions. If locking had been in effect, there is no way that the database could add $3,000.00 to $500.00 and get two different (wrong) results. This is only the most common problem encountered in a transaction processing system without locks. There are several other classic problems, but the lost update problem is sufficient to illustrate the necessity of locking.

A user can lock three resource types in a Teradata database:

Teradata Lock Levels ^ ,

• Database

• Table

• Row Hash

10-6

Introduction to the Teradata RDBMS for UNIX
Concurrency Control and Recovery

The Concept of the Lock

Teradata Lock Types

Users can exert four different levels of locking on Teradata resources. The following table explains the lock types.

Lock Type Description
Exclusive The requester has exclusive rights to the locked resource. No other process can read from, write to, or access the locked resource in any way. Exclusive locks are generally only necessary when structural changes are being made to the database.
Write The requester has exclusive rights to the locked resource except for readers not concerned with data consistency.
Read The requester has exclusive rights to the locked resource while it is reading that resource. Read locks ensure consistency during read operations such as those that occur during a SELECT statement. Several users can hold Read locks on a resource, during which no modification of that resource is permitted.
Previous << 1 .. 42 43 44 45 46 47 < 48 > 49 50 51 52 53 54 .. 76 >> Next