Oracle Tuning Locks Related

-- ------------------------- 0.2 QUICK VIEW ON LOCKS: (use the sys.obj$ to find ID1:) -- -----------------------First, lets take a look at some important dictionary views with respect to locks: SQL> desc v$lock; Name Null? Type ----------------------------- -------- -------------------ADDR RAW(8) KADDR RAW(8) SID NUMBER TYPE VARCHAR2(2) ID1 NUMBER ID2 NUMBER LMODE NUMBER REQUEST NUMBER CTIME NUMBER BLOCK NUMBER This view stores all information relating to locks in the database. The interesting columns in this view are sid (identifying the session holding or aquiring the lock), type, and the lmode/request pair. Important possible values of type are TM (DML or Table Lock), TX (Transaction), MR (Media Recovery), ST (Disk Space Transaction). Exactly one of the lmode, request pair is either 0 or 1 while the other indicates the lock mode. If lmode is not 0 or 1, then the session has aquired the lock, while it waits to aquire the lock if request is other than 0 or 1. The possible values for lmode and request are: 1: null, 2: Row Share (SS), 3: Row Exclusive (SX), 4: Share (S), 5: Share Row Exclusive (SSX) and 6: Exclusive(X) If the lock type is TM, the column id1 is the object's id and the name of the object can then be queried like so: select name from sys.obj$ where obj# = id1 A lock type of JI indicates that a materialized view is being SQL> desc v$locked_object; Name Null? Type ----------------------------- -------- -------------------XIDUSN NUMBER XIDSLOT NUMBER XIDSQN NUMBER OBJECT_ID NUMBER SESSION_ID NUMBER ORACLE_USERNAME VARCHAR2(30) OS_USER_NAME VARCHAR2(30) PROCESS VARCHAR2(12) LOCKED_MODE NUMBER SQL> desc dba_waiters; Name Null? Type ----------------------------- -------- -------------------WAITING_SESSION NUMBER HOLDING_SESSION NUMBER LOCK_TYPE VARCHAR2(26) MODE_HELD VARCHAR2(40)

MODE_REQUESTED VARCHAR2(40) LOCK_ID1 NUMBER LOCK_ID2 NUMBER SQL> desc v$transaction; Name Null? Type ----------------------------- -------- -------------------ADDR RAW(8) XIDUSN NUMBER XIDSLOT NUMBER XIDSQN NUMBER UBAFIL NUMBER UBABLK NUMBER UBASQN NUMBER UBAREC NUMBER STATUS VARCHAR2(16) START_TIME VARCHAR2(20) START_SCNB NUMBER START_SCNW NUMBER START_UEXT NUMBER START_UBAFIL NUMBER START_UBABLK NUMBER START_UBASQN NUMBER START_UBAREC NUMBER SES_ADDR RAW(8) FLAG NUMBER SPACE VARCHAR2(3) RECURSIVE VARCHAR2(3) NOUNDO VARCHAR2(3) PTX VARCHAR2(3) NAME VARCHAR2(256) PRV_XIDUSN NUMBER PRV_XIDSLT NUMBER PRV_XIDSQN NUMBER PTX_XIDUSN NUMBER PTX_XIDSLT NUMBER PTX_XIDSQN NUMBER DSCN-B NUMBER DSCN-W NUMBER USED_UBLK NUMBER USED_UREC NUMBER LOG_IO NUMBER PHY_IO NUMBER CR_GET NUMBER CR_CHANGE NUMBER START_DATE DATE DSCN_BASE NUMBER DSCN_WRAP NUMBER START_SCN NUMBER DEPENDENT_SCN NUMBER XID RAW(8) PRV_XID RAW(8) PTX_XID RAW(8) Queries you can use in investigating locks:

=========================================== SELECT XIDUSN,OBJECT_ID,SESSION_ID,ORACLE_USERNAME,OS_USER_NAME,PROCESS from v$locked_object; SELECT d.OBJECT_ID, substr(OBJECT_NAME,1,20), l.SESSION_ID, l.ORACLE_USERNAME, l.LOCKED_MODE from v$locked_object l, dba_objects d where d.OBJECT_ID=l.OBJECT_ID; SELECT ADDR, KADDR, SID, TYPE, ID1, ID2, LMODE, BLOCK from v$lock; SELECT a.sid, a.saddr, b.ses_addr, a.username, b.xidusn, b.used_urec, b.used_ublk FROM v$session a, v$transaction b WHERE a.saddr = b.ses_addr; SELECT s.sid, l.lmode, l.block, substr(s.username, 1, 10), substr(s.schemaname, 1, 10),substr(s.osuser, 1, 10), substr(s.program, 1, 30), s.command FROM v$session s, v$lock l WHERE s.sid=l.sid; SELECT p.spid, s.sid, p.addr,s.paddr,substr(s.username, 1, 10), substr(s.schemaname, 1, 10), s.command,substr(s.osuser, 1, 10), substr(s.machine, 1, 10) FROM v$session s, v$process p WHERE s.paddr=p.addr SELECT sid, serial#, command,substr(username, 1, 10), osuser, sql_address,LOCKWAIT, to_char(logon_time, 'DD-MM-YYYY;HH24:MI'), substr(program, 1, 30) FROM v$session; SELECT sid, serial#, username, LOCKWAIT from v$session; SELECT v.SID, v.BLOCK_GETS, v.BLOCK_CHANGES, w.USERNAME, w.OSUSER, w.TERMINAL FROM v$sess_io v, V$session w WHERE v.SID=w.SID ORDER BY v.SID; SELECT * from dba_waiters; SELECT waiting_session, holding_session, lock_type, mode_held FROM dba_waiters; SELECT p.spid unix_spid, s.sid sid, p.addr, s.paddr, substr(s.username, 1, 10) username, substr(s.schemaname, 1, 10) schemaname, s.command command, substr(s.osuser, 1, 10) osuser, substr(s.machine, 1, 25) machine FROM v$session s, v$process p

WHERE s.paddr=p.addr ORDER BY p.spid;

-- explanation of locks: Locks: 0, 'None', /* Mon Lock equivalent */ 1, 'Null', /* N */ 2, 'Row-S (SS)', /* L */ 3, 'Row-X (SX)', /* R */ 4, 'Share', /* S */ 5, 'S/Row-X (SRX)', /* C */ 6, 'Exclusive', /* X */ to_char(b.lmode) TX: enqueu, waiting TM: DDL on object MR: Media Recovery A TX lock is acquired when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK. It is used mainly as a queuing mechanism so that other sessions can wait for the transaction to complete. TM Per table locks are acquired during the execution of a transaction when referencing a table with a DML statement so that the object is not dropped or altered during the execution of the transaction, if and only if the dml_locks parameter is non-zero. LOCKS: locks op user objects, zoals tables en rows LATCH: locks op system objects, zoals shared data structures in memory en data dictionary rows LOCKS - shared of exclusive LATCH - altijd exclusive UL= user locks, geplaats door programmatuur m.b.v. bijvoorbeeld DBMS_LOCK package DML LOCKS: data manipulatie: table lock, row lock DDL LOCKS: preserves de struktuur van object (geen simulane DML, DDL statements) DML locks: row lock (TX): voor rows (insert, update, delete) row lock plus table lock: row lock, maar ook voorkomen DDL statements table lock (TM): automatisch bij insert, update, delete, ter voorkoming DDL op table table lock: S: share lock RS: row share RSX: row share exlusive RX: row exclusive X: exclusive (ANDere tansacties kunnen alleen SELECT..) in V$LOCK lmode column: 0, None 1, Null (NULL) 2, Row-S (SS) 3, Row-X (SX) 4, Share (S) 5, S/Row-X (SSX) 6, Exclusive (X) Internal Implementation of Oracle Locks (Enqueue) Oracle server uses locks to provide concurrent access to shared resources whereas

it uses latches to provide exclusive and short-term access to memory structures inside the SGA. Latches also prevent more than one process to execute the same piece of code, which other process might be executing. Latch is also a simple lock, which provides serialize and only exclusive access to the memory area in SGA. Oracle doesn �t use latches to provide shared access to resources because it will increase CPU usage. Latches are used for big memory structure and allow operations required for locking the sub structures. Shared resources can be tables, transactions, redo threads, etc. Enqueue can be local or global. If it is a single instance then enqueues will be local to that instance. There are global enqueus also like ST enqueue, which is held before any space transaction can be occurred on any tablespace in RAC. ST enqueues are held only for dictionary-managed tablespaces. These oracle locks are generally known as Enqueue, because whenever there is a session request for a lock on any shared resource structure, it's lock data structure is queued to one of the linked list attached to that resource structure (Resource structure is discussed later). Before proceeding further with this topic, here is little brief about Oracle locks. Oracle locks can be applied to compound and simple objects like tables and the cache buffer. Locks can be held in different modes like shared, excusive, null, sub-shared, sub-exclusive and shared sub-exclusive. Depending on the type of object, different modes are applied. Foe example, a compound object like a table with rows, all above mentioned modes could be applicable whereas for simple objects only the first three will be applicable. These lock modes don�t have any importance of their own but the importance is how they are being used by the subsystem. These lock modes (compatibility between locks) define how the session will get a lock on that object.