from block to lock

BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENF HAMBURG KOPENHAGEN LAUSANNE MÜNCHEN STUTTGART WIEN ZÜRICH

From Block to LockLock modes from theory to practiceTobias Deml

About…

From Block to Lock2 12.11.2015

Consultant, Trivadis GmbH, MunichSince more then 6 years working in Oracle environment– Development– Administration– ConsultingFocus areas– Performancetuning– High Availability– Migrations

Our company.


Trivadis is a market leader in IT consulting, system integration, solution engineeringand the provision of IT services focusing on andtechnologiesin Switzerland, Germany, Austria and Denmark. We offer our services in the followingstrategic business fields:

Trivadis Services takes over the interacting operation of your IT systems.

O P E R A T I O N

COPENHAGEN

MUNICH

LAUSANNEBERN

ZURICHBRUGG

GENEVA

HAMBURG

DÜSSELDORF

FRANKFURT

STUTTGART

FREIBURG

BASEL

VIENNA

With over 600 specialists and IT experts in your region.


14 Trivadis branches and more than600 employees200 Service Level AgreementsOver 4,000 training participantsResearch and development budget:CHF 5.0 millionFinancially self-supporting andsustainably profitableExperience from more than 1,900 projects per year at over 800customers

Agenda


1. Theoretical baselines2. Different types of locks3. Analysis 4. Locks and foreign key constraints5. Conclusion

The known scenario


„We have a lock in our database!“


Are these locks really needed?

RDBMS


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

Integrity, Consistency and Concurrency


Referential integrity– Relations between different database objects (constraints)

Consistency– Reflecting the right revision of the data

Concurrency– Changing data from different directions simultaneously

Variation of locks


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


DML Locks

Row Locks (TX)


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

Table Locks (TM) I


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

Table Locks (TM) II


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

Table Locks (TM)


RS RX S SRX XSelect Y Y Y Y YInsert Y Y N N NUpdate Y Y N N NDelete Y Y N N NSelect… for Update Y Y N N NTable Lock (RS) Y Y Y Y NTable Lock (RX) Y Y N N NTable Lock (S) Y N Y N NTable Lock (SRX) Y N N N NTable Lock (X) N N N N N


DDL Locks

DDL Locks I


protects the definition in data dictionaryblockage never extendedautomatically 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

DDL Locks II


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


System Locks

System Locks I


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

System Locks II


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


Deadlocks

Deadlocks


Concurrency between two or more sessions

Automatically solved by the oracle instance

Analysis of the deadlock trace file

Deadlocks


General information

Deadlocks


Information about the killed session

Deadlocks


Information about the killed sessions

Deadlocks


Deadlock graph


Locks and Foreign Keys


DEMO



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!


Analysis

Views in data dictionary


GV$LOCK GV$LOCK_TYPEGV$LOCKED_OBJECTGV$LATCHGV$WAIT_CHAINSDBA_DML_LOCKSDBA_BLOCKERSDBA_WAITERS

General lock overview


Entire SQL statement:https://tddba.wordpress.com/scripts/

Conclusion


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!


Further information…

https://docs.oracle.com/database/121/CNCPT/consist.htm#CNCPT020https://docs.oracle.com/database/121/SQLRF/ap_locks001.htm#SQLRF55502https://docs.oracle.com/database/121/REFRN/GUID-87D76889-832C-4BFC-B8B0-154A22721781.htm#REFRN30121

Any Question…?Tobias DemlConsultantTel. +49 89 992 759 324 [email protected]

12.11.2015 From Block to Lock37

@TobiasDemlDBAtddba.wordpress.com

© Trivadis – Das Unternehmen38 12.11.2015

Trivadis at the DOAG 2015Level 3 - right next to the escalator

We look forward to your visit.Because with Trivadis you always win.

from block to lock

Presentations & Public Speaking