Download Title Goes Here - Binus Repository

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Commitment ordering wikipedia , lookup

Clusterpoint wikipedia , lookup

Relational model wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Database model wikipedia , lookup

Serializability wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Concurrency control wikipedia , lookup

Transcript
Matakuliah
Tahun
: T0413
: 2009
Concurrency and locking
Pertemuan 8
What is a Transaction?
Your bank account
Your Mom’s bank account
Balance = $1000
Balance = $200
Transfer $100 from your account to your Mom’s account:
- Debit $100 from Savings account
- Credit $100 to Checking account
Bina Nusantara University
3
Concurrency overview
App A
App B
App C
App D
Bina Nusantara University
ID
Name
Age
3
Peter
33
5
John
23
22
Mary
22
35
Ann
55
4
Locking overview
App A
App B
App C
App D
Bina Nusantara University
ID
Name
Age
3
Peter
33
5
John
23
22
Mary
22
35
Ann
55
5
Concurrency
• DB2 was designed as a multi-user database
• Access to data must be coordinated properly and
transparently using a mechanism to ensure data integrity
and consistency
• Without some form of concurrency control, the following
problems may be encountered
–
–
–
–
Bina Nusantara University
Lost update
Uncommitted read
Non-repeatable read
Phantom read
6
Lost Update
Reservations
Flight
512
512
...
Seat
7C
7B
...
Update Reservations
Set P-name =
'Instruct'
Where Flight = 512
and Seat = '7C'
and P_name is NULL
512
Bina Nusantara University
7C
Instruct ...
P-Name
...
?
Update Reservations
Set P-name =
'Manager'
Where Flight = 512
and Seat = '7C'
and P_Name is NULL
512
7C Manager ...
7
Uncommitted Read
Reservations
Flight
512
Seat
7C
512
...
7B
...
P_Name
2 Select seat
From Reservations
Where P-name is NULL
1 Update Reservations
Set P-name = 'Instruct'
Where Flight = 512
and Seat = '7C'
and P_Name is NULL
512
3 Roll back
Bina Nusantara University
7C
Instruct
4 Incorrect results set
8
Non-repeatable Read
FLIGHT
SEAT
512
7B
DENVER
8A
SAN JOSE
1C
HONOLULU SAN JOSE
NAME
DESTINATION
ORIGIN
DALLAS
....
....
814
DENVER
....
134
....
....
Book a flight from Dallas to Honolulu
Bina Nusantara University
9
Phantom Read
Reservations
Flight
512
512
...
P-name
Seat
7B
7A
...
Susan Liu
1 Select seat
From Reservations
Where P-name is NULL
512
3 Repeat 1 now seat
Bina Nusantara
7AUniversity
is available
2
Update Reservations
Set P-name = 'NULL'
Where Flight = 512
and Seat = '7A'
and P-name = 'Susan Liu '
7B
10
Locking
• DB2 uses locking to maintain data integrity
• Locks are acquired automatically as needed to support a
transaction and are released when the transaction
terminates (COMMIT/ROLLBACK)
• Locks can be acquired on tables or rows
• Two basic types of locks:
– Share locks (S locks) – acquired when an application
wants to read and prevent others from updating the same
row
– Exclusive locks (X locks) – acquired when an application
updates, inserts, or deletes a row
Bina Nusantara University
11
Isolation Levels
• DB2 provides different levels of protection to isolate data
–
–
–
–
Uncommitted Read (UR)
Cursor Stability (CS)
Read Stability (RS)
Repeatable Read (RR)
• Isolation level can be specified at many levels
– Session (application). Defaults to CS
– Connection
– Statement
• For embedded SQL, the level is set at bind time
• For dynamic SQL, the level is set at run time
Bina Nusantara University
12
Comparing isolation levels
Bina Nusantara University
13
Isolation Levels – Uncommitted Read
• Uncommitted Read is also known as DIRTY READ
– Lowest level of isolation
– Provides highest degree of concurrency
• No row locks are obtained on read operations
– unless other application attempts to drop or alter table
• Update operations act as if using Cursor Stability
• Possible Situations
– Uncommitted Read
– Non-repeatable Read
– Phantom Read
• Situations Prevented
– Loss of Update
Bina Nusantara University
14
Isolation Levels – Cursor Stability
• Cursor Stability is the default isolation level
– Minimal degree of locking
– Locks the "current" row of a cursor
– If the row is only read
• the lock is held until a new row is fetched or the unit of work is
terminated
– If the row is updated
• the lock is held until the unit of work is terminated
• Possible Situations
– Non-repeatable Read
– Phantom Read
• Prevented Situations
– Loss of Update
Bina Nusantara University
– Uncommitted Read
15
Isolation Levels – Read Stability
• Locks all the rows an application retrieves within a
unit of work
– For a given cursor, it locks all rows that qualify for the result set
– Moderate degree of locking
• Possible Situations
– Phantom Read
• Prevented Situations
– Loss of Update
– Uncommitted Read
– Non-repeatable Read
Bina Nusantara University
16
Isolation Levels – Repeatable Read
• Highest isolation level, least concurrency
– Same query issued by the application more than once in a unit of
work will give the same result each time
– High degree of locking
– Locks held on all rows processed to build the result set
• i.e. rows not necessarily in the final result set may be locked
– No other application can update, delete, or insert a row that
would affect the result set until the unit of work completes
• Possible Situations
– none
• Prevented Situations
Bina Nusantara University
–
–
–
–
Loss of Update
Uncommitted Read
Non-repeatable Read
Phantom Read
17
Comparison of Isolation Level Terminolgy
DB2
.NET
JDBC
Uncommitted Read
ReadUncommitted
TRANSACTION_RE
OMMITTED
Cursor Stability (CS) ReadCommitted
TRANSACTION_RE
MITTED
Read Stability (RS)
RepeatableRead
TRANSACTION_RE
_READ
Repeatable Read
Serializable
TRANSACTION_SE
E
Bina Nusantara University
18
Statement Level Isolation
SELECT ... WITH {UR | CS | RS | RR}
UR = Uncommitted Read
CS = Cursor Stability
RS = Read Stability
RR = Repeatable Read
• Example Scenario:
– Application needs to get a "rough" count of how many rows
are in table. Performance is of utmost importance. Cursor
Stability isolation level is required with the exception of one
SQL statement:
SELECT COUNT(*) FROM tab1 WITH UR
Bina Nusantara University
19
Lock Escalation
Bina Nusantara University
20
Lock Escalation
• When optimizer thinks it is better to have one lock
on the entire table, rather than multiple row locks
• Database configuration parameters that affect lock
escalation:
– LOCKLIST – the amount of memory (4k pages) to
manage locks for all connected applications
• Default is 50 * 4K pages on Windows
– MAXLOCKS –Max percentage of the entire lock list that a
single application can use up
Bina Nusantara University
• Default is 22 percent
21
Lock Escalation (continued)
• If the default values are used, lock escalation occurs when a single
application requires more than 44K of lock memory
• If lock escalation, increase the value of LOCKLIST and MAXLOCKS
• Avoid lock escalations: Performance bottleneck
• Check the DB2 diagnostic log file (db2diag.log). The location is
shown below.
On Windows XP, 2003:
– C:\Documents and Settings\All Users\Application
Data\IBM\DB2\DB2COPY1\<instance name>
On Windows Vista:
– ProgramData\IBM\DB2\
On Linux/UNIX:
– INSTHOME/sqllib/db2dump (INSTHOME is the home directory of the
instance owner)
Bina Nusantara University
22
Lock Escalation indication in the db2diag.log
2007-01-02-23.04.43.699000 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417
data_management sqldEscalateLocks Probe:1 Database:SAMPLE
-- Start Table Lock Escalation.
-- Lock Count, Target : 28, 14
7570 6461 7465 2065 6d70 6c6f 7965 6520
7365 7420 6669 7273 746e 6d65 3d27 6162
6327
c'
update employee
set firstnme='ab
2007-01-02-23.04.43.699001 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417
data_management sqldEscalateLocks Probe:2 Database:SAMPLE
-- Lock Count, Target : 28, 14
-- Table (ID) Name : (2;5) ADMINISTRATOR.EMPLOYEE
-- Locks, Request Type : 25, X
-- Result (0 = success): 0
Bina Nusantara University
23
Application Lock Snapshot
Lock Snapshot
View locks currently held by
an application
UPDATE MONITOR
SWITCHES USING LOCK ON
GET SNAPSHOT FOR LOCKS
FOR APPLICATION
AGENT ID <handle>
Bina Nusantara University
Snapshot timestamp
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 11-05-2002 00:09:08.672586
=9
= *LOCAL.DB2.00B9C5050843
= 0001
= db2bp.exe
= ADMINISTRATOR
= UOW Waiting
= Not Collected
= 1252
=4
=0
List Of Locks
Lock Name
= 0x05000700048001000000000052
Lock Attributes
= 0x00000000
Release Flags
= 0x40000000
Lock Count
= 255
Hold Count
=0
Lock Object Name
= 98308
Object Type
= Row
Tablespace Name
= TEST4K
Table Schema
= ADMINISTRATOR
Table Name
= T2
Mode
=X
24
Lock Wait
• By default, an application waits indefinitely to obtain any
needed locks
• LOCKTIMEOUT (db cfg):
– Change to specify the number of seconds to wait for a lock
– Default value is -1 or infinite wait
• A database connection also has a user-definable
CURRENT LOCK TIMEOUT register
–
–
–
–
By default it inherits its value from the LOCKTIMEOUT parameter
Use the SET LOCK TIMEOUT statement to change its value
Once it is set for a connection, it persists across transactions
e.g. SET LOCK TIMEOUT=WAIT n
Bina Nusantara University
25
Deadlock Causes and Detection
RAISIN
BRAN
USER A
MILK
USER B
within a UNIT OF WORK (UOW)
Bina Nusantara University
INSERT CEREAL AND MILK into BOWL
26
Deadlock Settings
• Deadlocks are an application design issue most of
the time
• DLCHKTIME (db cfg) sets the time interval for
checking for deadlocks
– It defines the frequency that the database manager checks
for deadlocks among all the applications connected to a
database
• If you are experiencing many deadlocks, you should
re-examine your existing transactions and see if
any re-structuring is possible
27
Bina Nusantara University
Best Practices
• Keep transactions as short as possible
– Issue frequent COMMIT statements – even for read-only transactions
• Log transaction information only when required
– Purge data quick using:
• ALTER TABLE ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE
– Perform data modifications in batches/groups
• DELETE FROM ( SELECT * FROM tedwas.t1 WHERE c1 = …
FETCH FIRST 3000 ROWS ONLY )
– Use concurrency features in DB2 data movement tools
• Set the database level LOCKTIMEOUT parameter (usually between 30120 seconds)
– Can also use session-based lock timeout
• Do not retrieve more data than is required
– Use the FETCH FIRST n ROWS ONLY clause in SELECT statements
Bina Nusantara University
28