From Block to Lock Tobias Deml

1. BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF
HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH
From Block to Lock
Lock modes from theory to practice
Tobias Deml

2. About…
From Block to Lock2 12.11.2015
Consultant, Trivadis GmbH, Munich
Since more then 6 years working in Oracle environment
– Development
– Administration
– Consulting
Focus areas
– Performancetuning
– High Availability
– Migrations

3. Our company.
From Block to Lock3 12.11.2015
Trivadis is a market leader in IT consulting, system integration, solution engineering
and the provision of IT services focusing on and
technologies
in Switzerland, Germany, Austria and Denmark. We offer our services in the following
strategic business fields:
Trivadis Services takes over the interacting operation of your IT systems.
O P E R A T I O N

4. COPENHAGEN
MUNICH
LAUSANNE
BERN
ZURICH
BRUGG
GENEVA
HAMBURG
DÜSSELDORF
FRANKFURT
STUTTGART
FREIBURG
BASEL
VIENNA
With over 600 specialists and IT experts in your region.
From Block to Lock4 12.11.2015
14 Trivadis branches and more than
600 employees
200 Service Level Agreements
Over 4,000 training participants
Research and development budget:
CHF 5.0 million
Financially self-supporting and
sustainably profitable
Experience from more than 1,900
projects per year at over 800
customers

5. Agenda
From Block to Lock5 12.11.2015
1. Theoretical baselines
2. Different types of locks
3. Analysis
4. Locks and foreign key constraints
5. Conclusion

6. The known scenario
From Block to Lock6 12.11.2015
„We have a lock
in our database!“

7. From Block to Lock7 12.11.2015
Are these locks really needed?

8. RDBMS
From Block to Lock8 12.11.2015
Relational database management system
Theoretical baselines
– „A Relational Model of Data for Large Shared Data Banks“
– Mathematician and Physicist Edgar F. Codd
Definition of several rules for structured storage of data

9. Integrity, Consistency and Concurrency
From Block to Lock9 12.11.2015
Referential integrity
– Relations between different database objects (constraints)
Consistency
– Reflecting the right revision of the data
Concurrency
– Changing data from different directions simultaneously

10. Variation of locks
From Block to Lock10 12.11.2015
DML Locks
 Row Locks (TX)
 Table Locks (TM)
 Row Shared (SS/RS)
 Row Exclusive (SX/RX)
 Shared (S)
 Shared Row Exclusive
(SSX/SRX)
 Exclusive (X)
DDL Locks
 Exclusive
 Share
 Breakable Parse Lock
System Locks
 Latches
 Mutexes
 Internal

11. From Block to Lock11 12.11.2015
DML Locks

12. Row Locks (TX)
From Block to Lock12 12.11.2015
Blockage of one or more rows of a table (DML operation)
Exclusive
Always accompanied with a regarding table lock
Released by ending of the transaction

13. Table Locks (TM) I
From Block to Lock13 12.11.2015
Blockage of a table
Triggered by user or caused implicitly
Row Shared Lock (SS/RS)
– least restrictive lock
– protects against DDL operation on the table
Row Exclusive Table Lock (SX/RX)
– indicates that a DML is executed
– able to modify a row

14. Table Locks (TM) II
From Block to Lock14 12.11.2015
Shared Table Lock (S)
– DML operations just allowed if at most one S-Lock is set.
– no other data adjustment possible
Shared Row Table Exclusive Lock (SSX/SRX)
– more restrictive then S-Lock
Exclusive Lock (X)
– most restrictive table lock
– querying of data still possible

15. Table Locks (TM)
From Block to Lock15 12.11.2015
RS RX S SRX X
Select Y Y Y Y Y
Insert Y Y N N N
Update Y Y N N N
Delete Y Y N N N
Select… for Update Y Y N N N
Table Lock (RS) Y Y Y Y N
Table Lock (RX) Y Y N N N
Table Lock (S) Y N Y N N
Table Lock (SRX) Y N N N N
Table Lock (X) N N N N N

16. From Block to Lock16 12.11.2015
DDL Locks

17. DDL Locks I
From Block to Lock17 12.11.2015
protects the definition in data dictionary
blockage never extended
automatically release after finishing the DDL operation
Exclusive DDL Lock
– locks the definition of an object exclusively
– prevents from modification or dropping
– e.g. during ALTER TABLE statement

18. DDL Locks II
From Block to Lock18 12.11.2015
Share DDL Lock
– locks the definition of an object shared
– prohibits from dropping
– e.g. during CREATE PROCEDURE statement
Breakable Parse Lock
– hold references to all related objects in the Shared Area
– can be broken by every conflicting DDL operation

19. From Block to Lock19 12.11.2015
System Locks

20. System Locks I
From Block to Lock20 12.11.2015
Latches
– regulates multiuser access to shared structures
– locks a group of objects
– protect memory from corruption
– preventing from following situations:
> Concurrent modification by different sessions
> Reading uncommitted data
> Aging out memory while access

21. System Locks II
From Block to Lock21 12.11.2015
Mutexes
– behavior is similar to a latch
– locks a single object not a group of those
– more efficient then a latch, factor depends on the OS
Internal Locks
> Dictionary cache locks
> File and log management locks
> Tablespace and undo segment locks

22. From Block to Lock22 12.11.2015
Deadlocks

23. Deadlocks
From Block to Lock23 12.11.2015
Concurrency between two or more sessions
Automatically solved by the oracle instance
Analysis of the deadlock trace file

24. Deadlocks
From Block to Lock24 12.11.2015
General information

25. Deadlocks
From Block to Lock25 12.11.2015
Information about the killed session

26. Deadlocks
From Block to Lock26 12.11.2015
Information about the killed sessions

27. Deadlocks
From Block to Lock27 12.11.2015
Deadlock graph

28. From Block to Lock28 12.11.2015
Locks and Foreign Keys

29. Locks and Foreign Keys
From Block to Lock29 12.11.2015

30. From Block to Lock30 12.11.2015
DEMO 

31. Locks and Foreign Keys
From Block to Lock31 12.11.2015
ensure the integrity between tables
preventing the violation using locks and error messages
Indexing the foreign key is often the right way,
but should never be the rule!

32. From Block to Lock32 12.11.2015
Analysis

33. Views in data dictionary
From Block to Lock33 12.11.2015
GV$LOCK
GV$LOCK_TYPE
GV$LOCKED_OBJECT
GV$LATCH
GV$WAIT_CHAINS
DBA_DML_LOCKS
DBA_BLOCKERS
DBA_WAITERS

34. General lock overview
From Block to Lock34 12.11.2015
Entire SQL statement:
https://tddba.wordpress.com/scripts/

35. Conclusion
From Block to Lock35 12.11.2015
Locks are needed to ensure basic database functionality
Prepare your environment for minimal concurrency
Preventive is better then reactive tuning
Know what to do when it's time to do!

36. From Block to Lock36 12.11.2015
Further information…
https://docs.oracle.com/database/121/CNCPT/consist.htm#CNCPT020
https://docs.oracle.com/database/121/SQLRF/ap_locks001.htm#SQLRF55502
https://docs.oracle.com/database/121/REFRN/GUID-87D76889-832C-4BFC-B8B0-154A22721781.htm#REFRN30121

37. Any Question…?
Tobias Deml
Consultant
Tel. +49 89 992 759 324
Tobias.Deml@trivadis.com
12.11.2015 From Block to Lock37
@TobiasDemlDBA
tddba.wordpress.com

38. © Trivadis – Das Unternehmen38 12.11.2015
Trivadis at the DOAG 2015
Level 3 - right next to the escalator
We look forward to your visit.
Because with Trivadis you always win.