Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
32
Добавлен:
16.04.2013
Размер:
4.96 Mб
Скачать

Using Serializable Transactions for Concurrency Control

Viewing and Monitoring Locks

Table 5–4 describes Oracle Database facilities to display locking information for ongoing transactions within an instance.

Table 5–2 Ways to Display Locking Information

Tool

Description

 

 

Oracle Enterprise

From the Additional Monitoring Links section of the

Manager 10g Database

Database Performance page, click Database Locks to

Control

display user blocks, blocking locks, or the complete list of

 

all database locks. Refer to Oracle 2 Day DBA for more

 

information.

UTLLOCKT.SQL

The UTLLOCKT.SQL script displays a simple character lock

 

wait-for graph in tree structured fashion. Using any ad hoc

 

SQL tool (such as SQL*Plus) to execute the script, it prints

 

the sessions in the system that are waiting for locks and

 

the corresponding blocking locks. The location of this

 

script file is operating system dependent. (You must have

 

run the CATBLOCK.SQL script before using

 

UTLLOCKT.SQL.)

 

 

Using Serializable Transactions for Concurrency Control

By default, Oracle Database permits concurrently executing transactions to modify, add, or delete rows in the same table, and in the same data block. Changes made by one transaction are not seen by another concurrent transaction until the transaction that made the changes commits.

If a transaction A attempts to update or delete a row that has been locked by another transaction B (by way of a DML or SELECT... FOR UPDATE statement), then A's DML command blocks until B commits or rolls back. Once B commits, transaction A can see changes that B has made to the database.

For most applications, this concurrency model is the appropriate one, because it provides higher concurrency and thus better performance. But some rare cases require transactions to be serializable. Serializable transactions must execute in such a way that they appear to be executing one at a time (serially), rather than concurrently. Concurrent transactions executing in serialized mode can only make

How Oracle Database Processes SQL Statements 5-19

Using Serializable Transactions for Concurrency Control

database changes that they could have made if the transactions ran one after the other.

Figure 5–2 shows a serializable transaction (B) interacting with another transaction

(A).

The ANSI/ISO SQL standard SQL92 defines three possible kinds of transaction interaction, and four levels of isolation that provide increasing protection against these interactions. These interactions and isolation levels are summarized in Table 5–3.

Table 5–3 Summary of ANSI Isolation Levels

Isolation Level

Dirty Read1

Non-Repeatable Read2

Phantom Read3

READ UNCOMMITTED

Possible

Possible

Possible

READ COMMITTED

Not possible

Possible

Possible

REPEATABLE READ

Not possible

Not possible

Possible

SERIALIZABLE

Not possible

Not possible

Not possible

1A transaction can read uncommitted data changed by another transaction.

2A transaction rereads data committed by another transaction and sees the new data.

3A transaction can execute a query again, and discover new rows inserted by another committed transaction.

The behavior of Oracle Database with respect to these isolation levels is summarized in Table 5–4.

Table 5–4 ANSI Isolation Levels and Oracle Database

Isolation Level

Description

READ UNCOMMITTED Oracle Database never permits "dirty reads." Although some other database products use this undesirable technique to improve thoughput, it is not required for high throughput with Oracle Database.

5-20 Oracle Database Application Developer's Guide - Fundamentals

 

 

Using Serializable Transactions for Concurrency Control

 

 

 

 

Table 5–4 (Cont.)

ANSI Isolation Levels and Oracle Database

 

 

 

 

Isolation Level

Description

 

 

 

 

READ COMMITTED

Oracle Database meets the READ COMMITTED isolation

 

 

standard. This is the default mode for all Oracle

 

 

Database applications. Because an Oracle Database

 

 

query only sees data that was committed at the

 

 

beginning of the query (the snapshot time), Oracle

 

 

Database actually offers more consistency than is

 

 

required by the ANSI/ISO SQL92 standards for READ

 

 

COMMITTED isolation.

 

REPEATABLE READ

Oracle Database does not normally support this isolation

 

 

level, except as provided by SERIALIZABLE.

 

SERIALIZABLE

Oracle Database does not normally support this isolation

 

 

level, except as provided by SERIALIZABLE.

 

 

 

How Serializable Transactions Interact

Figure 5–2 on page 5-22 shows how a serializable transaction (Transaction B) interacts with another transaction (A, which can be either SERIALIZABLE or READ COMMITTED).

When a serializable transaction fails with an ORA-08177 error ("cannot serialize access"), the application can take any of several actions:

Commit the work executed to that point

Execute additional, different, statements, perhaps after rolling back to a prior savepoint in the transaction

Roll back the entire transaction and try it again

Oracle Database stores control information in each data block to manage access by concurrent transactions. To use the SERIALIZABLE isolation level, you must use the INITRANS clause of the CREATE TABLE or ALTER TABLE command to set aside storage for this control information. To use serializable mode, INITRANS must be set to at least 3.

How Oracle Database Processes SQL Statements 5-21

Using Serializable Transactions for Concurrency Control

Figure 5–2 Time Line for Two Transactions

TRANSACTION A

(arbitrary)

begin work update row 2 in block 1

insert row 4

commit

TIME

Issue update "too recent" for B to see

Change other row in same block, see own changes

Create possible "phantom" row

Uncommitted changes invisible

Make changes visible to transactions that begin later

Make changes after A commits

B can see its own changes but not the committed changes of transaction A.

Failure on attempt to update row updated and committed since transaction B began

TRANSACTION B

(serializable)

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE read row 1 in block 1

update row 1 in block 1 read updated row 1 in block 1

read old row 2 in block 1 search for row 4 (notfound)

update row 3 in block 1

re-read updated row 1 in block 1

search for row 4 (not found) read old row 2 in block 1

update row 2 in block 1 FAILS; rollback and retry

5-22 Oracle Database Application Developer's Guide - Fundamentals

Соседние файлы в папке Oracle 10g