h.lu/hkust l07: lock tuning. l07-lock tuning - 2 h.lu/hkust lock tuning the key is to combine the...

H.Lu/HKUST

L07: Lock Tuning

H.Lu/HKUST L07-Lock Tuning - 2

Lock Tuning The key is to combine the theory of concurrency control with practical DBMS

knowledge Goal: maximise DBMS throughput (not the response time of any single

transaction) Understand DBMS

Each DBMS product may have different default locking behaviours Example: SQL Server and Sybase

• Write locks are held to the end of a transaction• Read locks are released immediately after use• Not 2PL!

Understand applications What is the requirement for your transaction? What will be the transactions that will run in parallel to your transaction? Where is the start and the end of your transaction?

Understand runtime environment What are the concurrent transactions? What are their priorities? How your system has performed so far?


Ideal Transaction

Acquires few locks and favors shared locks over exclusive locks Reduce the number of conflicts -- conflicts are

due to exclusive locks Acquires locks with fine granularity

Reduce the scope of each conflict Holds locks for a short time

Reduce waiting


Lock Tuning – Some Guidelines Use special system facilities for long reads

E.g., multiversion read consistency Eliminate locking when it is unnecessary

E.g. when bulk loading, or statistical analysis Take advantages of transactional context to chop transactions into small pieces

Refer the textbook for a formal method Weaken isolation guarantees when the application allows it

SQL allows 4 level of consistency options Select the appropriate locking granularity

Table, record, field… Do DDL statements when not busy Think about partitioning

E.g., use multiple physical disks Void hot spots Tune the deadlock intervals

How long to time-out a transaction?


Snapshot Isolation

T1

T2

T3

TIME

R(Y) re

turns 1

R(Z) returns 0

R(X) re

turns 0

W(Y:=1)

W(X:=2, Z

:=3)

X=Y=Z=0

A facility provided by some DBMS (e.g. Oracle) that allows read-only queries hold no locks, yet appear to execute serializably.

Each transaction executes against the version of the data items that was committed when the transaction started: No locks for read Costs space (old copy of data must

be kept) When extended to read/write, no

guarantee of correctness T1: x:=y T2: y:= x Initially x=3 and y =17 Serial execution:

x,y=17 or x,y=3 Snapshot isolation:

x=17, y=3 if both transactions start at the same time.


Eliminate Unnecessary Locking

Locking is unnecessary when only one transaction runs at a time

e.g. loading the database When all transactions are read-only

When doing decision support queries on archival database


Weaken Isolation Levels Correctness vs. Performance

Number of locks held by each transaction Kind of locks Length of time a transaction holds locks

Life is full of compromises High performance, at the cost of allowing some bad things

happing Application programmer and DBA should make a decision

• An informed decision!


SQL Isolation Levels Degree 0:

Allow dirty read and lost update/nonrepeatable reads Write-locks released immediately after writing, and no read locks

Degree 1: Read Uncommitted (No lost update) Read may read dirty data, and will not be repeatable. Writes may not overwrite other transactions’ dirty data. Write-locks held for the duration of the transactions No read-locks

Degree 2: Read Committed (No dirty retrieval) Reads may access only committed data; but may not repeatable. Write locks follow two phase locking; read-locks released

immediately after the read operation. SQL Server default option

Degree 3: Serializable (no unrepeatable reads for read/write ) Reads may access only committed data, and reads are repeatable. Writes may not overwrite other transactions’ dirty data. Two phase locking.


Value of Serializability: Data

Settings:accounts( number, branchnum, balance);

create clustered index c on accounts(number); 100000 rows Cold buffer; same buffer size on all systems. Row level locking Isolation level (SERIALIZABLE or READ COMMITTED) SQL Server 7, DB2 v7.1 and Oracle 8i on Windows 2000 Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller

from Adaptec (80Mb), 4x18Gb drives (10000RPM), Windows 2000.


Value of Serializability: Transactions

Concurrent Transactions: T1: summation query [1 thread]

select sum(balance) from accounts;

T2: swap balance between two account numbers (in order of scan to avoid deadlocks) [N threads]

valX:=select balance from accounts where number=X;valY:=select balance from accounts where number=Y;update accounts set balance=valX where number=Y;update accounts set balance=valY where number=X;


Value of Serializability: Results

With SQL Server and DB2 the scan returns incorrect answers if the read committed isolation level is used (default setting)

With Oracle correct answers are returned (snapshot isolation), but beware of swapping

Oracle

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10

Concurrent update threadsRa

tio o

f cor

rect

ans

wers

read committed

serializable

SQLServer

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10Concurrent update threads

Ratio

of c

orre

ct a

nswe

rs

read committed

serializable


Cost of Serializability

Because the update conflicts with the scan, correct answers are obtained at the cost of decreased concurrency and thus decreased throughput.

Oracle

0 2 4 6 8 10

Concurrent Update ThreadsTh

rough

put

(trans/

sec)

read committed

serializableSQLServer

0 2 4 6 8 10

Concurrent Update Threads

Throu

ghpu

t (tra

ns/se

c)

read committed

serializable


Chop Transactions

Long transactions The more locks a transaction requests, the more

likely it is that it will have to wait for some other transactions to release a lock

The longer a transaction T executes, the more time another transaction will have to wait if it is blocked by T

Chop a long transaction into a number of shorter transactions.


Chop Transactions: An Example

Example: A bank allows customers to withdraw up to $1000 a day. In the evening it does batch update, that is update customers account balance and then the branch balance. During evening, there are occasional credit checks T1: update client’s account balance one by one followed

by update to the appropriate branch balance. T2: credit check: Checking a particular client’s balance

Possible solutions Chop T1 into many small transactions, Ti, each Ti update

the balance of one account (i) and related branch balance. Further chop Ti into two transactions, update client’s

account balance and branch balance, respectively.


Chop Transactions: Correctness

In the previous example, add one more transaction that checks whether the sum of individual account balances tally with the branch balances. How to chop?

Need to be careful to guarantee the correctness. Will the transaction that concurrent with T cause T to produce and

inconsistent state or to observe an inconsistent value if T is broken up? Will the transactions that are concurrent with T be made inconsistent

if T is broken up? A formal solution is available. A rule of thumb:

If T access X and Y, and any other concurrent transactions T’ access at most one of X or Y and nothing else, then T can be divided into two transactions, accessing X and Y respectively.


Transactions with Human Interaction

A transaction that holds locks during a screen interaction is an invitation to bottlenecks Airline Reservation

1. Retrieve list of seats available2. Talk with customer regarding availability3. Secure seat

Single transaction is intolerable, because each customer would hold lock on seats available.

Keep user interaction outside a transactional context Problem: ask for a seat but then find it’s unavailable. More

tolerable.


Granularity of Locking Different granularities of locks

Record-level by default page-level locking: prevent concurrent transactions from

accessing/modifying all records on a page page-level locking: prevent concurrent transactions from

accessing/modifying all pages that are part of that table. By default, recorded-level locking. Table level locking is useful:

Avoid blocking long transactions Used to avoid deadlocks Reduce locking overhead

Lock escalation Automatically upgrades row-level locks into a single page-level

locking when the number of row-level locks reaches Guidelines

Long transactions should use table-level locking, and short transactions should use record locks to enhance concurrency


Record vs. Table Locking : DataSettings:

accounts( number, branchnum, balance); create clustered index c on accounts(number);

100000 rows Cold buffer SQL Server 7, DB2 v7.1 and Oracle 8i on Windows 2000 No lock escalation on Oracle; Parameter set so that there is no lock

escalation on DB2; no control on SQL Server. Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller

from Adaptec (80Mb), 4x18Gb drives (10000RPM), Windows 2000.

No Concurrent Transactions: Update [10 000 updates]

update accounts set balance = Val; Insert [10 000 transactions], e.g. typical one:

insert into accounts values(664366,72255,2296.12);


Record vs. Table Locking : Results

Row locking is barely more expensive than table locking because recovery overhead is higher than row locking overhead Exception is updates on DB2 where table locking is distinctly less

expensive than row locking.

0

0.2

0.4

0.6

0.8

1

update insert

Th

rou

gh

pu

t ra

tio

(ro

w l

ockin

g/t

ab

le l

ockin

g) db2 sqlserver oracle


Control Locking Granularity

Explicit control of the granularity Setting the escalation point

Set the threshold high enough so that in an online environment of relatively short transactions, escalation will never take place

Size of lock table Small size of lock table will cause the system to

escalate the lock granularity even transactions are short


Lock Table Implementation

A Lock info for A

A

H

10 1 117 RI D X LO1 LW1, LW410 1 117 PAG X LO110 1 117 TAB X LO1 LW310 1 118 RI D S LO2, LO3 LW2

l ockmode

l ockowner

l ockwai ter

spi d dbi d obj i dl ock

granul ari ty

Syslockinfo in SQL Server 7


Logical Bottleneck: Sequential Key Generation

Consider an application in which one needs a sequential number to act as a key in a table, e.g. invoice numbers for bills.

Ad hoc approach: a separate table holding the last invoice number. Fetch and update that number on each insert transaction.

Counter approach: use facility such as Sequence (Oracle)/Identity(MSSQL).


Counter Facility: Data

Settings:

default isolation level: READ COMMITTED; Empty tables

Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller from Adaptec (80Mb), 4x18Gb drives (10000RPM), Windows 2000.

accounts( number, branchnum, balance);create clustered index c on accounts(number); counter ( nextkey );insert into counter values (1);


Counter Facility: Transactions

No Concurrent Transactions: System [100 000 inserts, N threads]

• SQL Server 7 (uses Identity column)insert into accounts values (94496,2789);• Oracle 8iinsert into accounts values (seq.nextval,94496,2789);

Ad-hoc [100 000 inserts, N threads]begin transaction NextKey:=select nextkey from counter; update counter set nextkey = NextKey+1;commit transactionbegin transaction insert into accounts values(NextKey,?,?);commit transaction


Avoid Bottlenecks: Counters

System generated counter (system) much better than a counter managed as an attribute value within a table (ad hoc).

The Oracle counter can become a bottleneck if every update is logged to disk, but caching many counter numbers is possible.

Counters may miss ids.

SQLServer

0 10 20 30 40 50

Number of concurrent insertion threads

Th

rou

gh

pu

t (s

tate

me

nts

/se

c)

system

ad-hoc

Oracle

0 10 20 30 40 50


Th

rou

gh

pu

t (s

tate

men

ts/s

ec)

system

ad-hoc


Insertion Points: Transactions

No Concurrent Transactions: Sequential [100 000 inserts, N threads]

Insertions into account table with clustered index on ssnumData is sorted on ssnumSingle insertion point

Non Sequential [100 000 inserts, N threads]Insertions into account table with clustered index on

ssnumData is not sorted (uniform distribution)100 000 insertion points

Hashing Key [100 000 inserts, N threads]Insertions into account table with extra attribute att with clustered

index on (ssnum, att)Extra attribute attribute contains hash key (1021 possible values)1021 insertion points


Insertion Points

Page locking: single insertion point is a source of contention (sequential key with clustered index, or heap)

DB2 v7.1 and Oracle 8i do not support page locking.

Row Locking

0

200

400

600

800

0 10 20 30 40 50 60


Thro

ughp

ut(tu

ples

/sec

)

sequential

non sequential

hashing key

Page Locking

0

20

40

60

80

100

120

140

0 10 20 30 40 50 60


Thro

ughp

ut (t

uple

s/se

c)

sequential

non sequential

hashing key

Row locking: No contention between successive insertions.


Summary –Physical DB Design and Tuning

Brief introduction to a few major issues in physical database design and tuning Index selection Tuning relational schema (denormalization,

horizontal and vertical partitioning) Tuning relational queries Lock related tuning

There are other issues in tuning which are not covered in the class

h.lu/hkust l07: lock tuning. l07-lock tuning - 2 h.lu/hkust lock tuning the key is to combine the...

Documents

l07lock tuning

lock tuning slide

luhkust lock

luhkust l07

exclusive locks

locks life

shared locks

luhkust ideal transaction