from block to lock

Post on 12-Apr-2017

242 Views

Category:

Presentations & Public Speaking

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

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.

From Block to Lock3 12.11.2015

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.

From Block to Lock4 12.11.2015

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

From Block to Lock5 12.11.2015

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

The known scenario

From Block to Lock6 12.11.2015

„We have a lock in our database!“

From Block to Lock7 12.11.2015

Are these locks really needed?

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

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

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

From Block to Lock11 12.11.2015

DML Locks

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

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

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

Table Locks (TM)

From Block to Lock15 12.11.2015

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

From Block to Lock16 12.11.2015

DDL Locks

DDL Locks I

From Block to Lock17 12.11.2015

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

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

From Block to Lock19 12.11.2015

System Locks

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

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

From Block to Lock22 12.11.2015

Deadlocks

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

Deadlocks

From Block to Lock24 12.11.2015

General information

Deadlocks

From Block to Lock25 12.11.2015

Information about the killed session

Deadlocks

From Block to Lock26 12.11.2015

Information about the killed sessions

Deadlocks

From Block to Lock27 12.11.2015

Deadlock graph

From Block to Lock28 12.11.2015

Locks and Foreign Keys

Locks and Foreign Keys

From Block to Lock29 12.11.2015

From Block to Lock30 12.11.2015

DEMO

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!

From Block to Lock32 12.11.2015

Analysis

Views in data dictionary

From Block to Lock33 12.11.2015

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

General lock overview

From Block to Lock34 12.11.2015

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

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!

From Block to Lock36 12.11.2015

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 Tobias.Deml@trivadis.com

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.

top related