1. Vil Roufchaie www.dbpulsegroup.com
12/1/2018
Blocking Locks
Vil Roufchaie

2. What Will Be Covered In This Presentation?
12/1/2018
What Will Be Covered In This Presentation?
In this presentation I will briefly point out what lock are and how they operate in an Oracle database
Several locking and blocking lock examples will be discussed
Several useful SQL scripts to demonstrate blocking locks and how to terminate all such locks will also be presented
The details of Oracle locks are beyond the scope of his presentation
This presentation will enable you to address your locking issues at work with efficacy and more confidence
12/1/2018

3. Users Often Call & Scream:
12/1/2018
Users Often Call & Scream:
Why is the database so slow!
My program is going nowhere
Don’t understand why my program is blocking other programs?
Please kill these blocking sessions, they are making my [life miserable] program slow…
Please kill my programs ASAP, they are being [unkind to me] blocked
DBAs/Managers must 1st investigate before taking any actions
12/1/2018

4. Information Is Power! You (DBA/Mgr) doesn’t know:
12/1/2018
Information Is Power!
You (DBA/Mgr) doesn’t know:
What database/Unix privileges the users may possess?
And what actions they may have already taken?
And whether they’ve already killed the SID they are calling you about – Oracle quickly re-assigns SIDs, and if you kill that SID without probing 1st?
What information they are not sharing with you?
Whether they know the consequences of what they are asking for?
Whether they know what they are really asking you to do for them?
You (DBA/Mgr.) must probe into the situation and figure out what’s been happening…
12/1/2018

5. Why Is Locking An Important Subject
12/1/2018
Why Is Locking An Important Subject
From a user’s perspective, her/his application is the most important on the system
She may feel that her application will be the only program on the database,
and hence system resources may not get allocated and utilized wisely in a program’s development phase…
The truth of the matter is, there are almost always many other applications that are running in the database system concurrently that require system resources…
Locking provides synchronized access to Oracle resources
12/1/2018

6. Why Is Locking An important Subject
12/1/2018
Why Is Locking An important Subject
Unless care is taken in programming these applications, particularly how locks get utilized,
and the granularity with which they are implemented, which affects concurrency of data access,
a database can come to a stand-still due to what’s commonly termed as: Blocking Locks
Example: A long-running transaction takes a shared mode lock on a frequently accessed table, and all subsequent updates will be enqueued waiting for the lock taken by the 1st transaction to become free
12/1/2018

7. What Must A DBA know Having the confidence to kill
12/1/2018
What Must A DBA know
Being knowledgeable of:
locks,
blocking locks,
Being able to determine:
locked objects (tables),
relevant data blocks,
locked rows
is extremely important in a time-sensitive situation
The ability to identify:
the session blocking other sessions
the blocked sessions
Having the confidence to kill
The correct blocking/blocked sessions
And not the wrong sessions!
12/1/2018

8. Lock Record Size (bytes)
12/1/2018
Oracle Locks
A database without a locking system is like a city with roads that are void of traffic signals!
Oracle uses locks to control concurrent access to shared resources
Oracle Holds lock records in the database inside block headers where locked rows resides in what’s called: “Interested Transaction List” - ITL
DBMS
Lock Record Size (bytes)
Where Held
Oracle 40
Database Block
DB2
250
RAM
Microsoft
100
12/1/2018

9. Lock Types DML Locks: Select for update, Delete, Insert, Update
12/1/2018
Lock Types
DML Locks: Select for update, Delete, Insert, Update
DDL Locks: Create , Drop, Alter, etc.
Internal Locks and Latches: Light-wait serialization mechanism
Distributed Locks: (OPS cache consistency)
PCM Locks (used for cached blocked in OPS)
12/1/2018

10. 12/1/2018
DML Locks
TX (transaction) Locks Row-level locks are held automatically by oracle inside a transaction for DML (Select, Delete, Insert, Update) operations on a row, and other transactions will have to wait until this transaction either commits or rolls back
TM (Table/DML Enqueue) Locks Are used to lock a table during DML operations so table structure may not get changed from under while these operations are underway. No table “create”, “alter” or “drop” command will be allowed while this lock is being held
12/1/2018

11. 12/1/2018
DDL Locks
DDL lock: Is placed during DDL operation and is released immediately upon completion
(DDL statements Are preceded by a “commit”)
DDL Lock Types:
Exclusive DDL Locks
Share DDL Locks
Breakable Parse Locks
12/1/2018

12. 12/1/2018
What’s A Transaction?
To understand a database, it is essential to know how it manages it’s transactions
A transaction is made up of one or more SQL operations
A transaction starts with a read/write operation and ends with a commit/rollback statement
12/1/2018

13. 12/1/2018
What’s A Transaction?
To manage a database is to manage it’s workload of: short and long transactions
These transaction hit the database at any time - serially or concurrently at will
12/1/2018

14. 12/1/2018
Transaction Process
Transaction locks are maintained through the life of the transaction
All locks and resources will be released as a transaction ends
12/1/2018

15. Transactions & Concurrency
12/1/2018
Transactions & Concurrency
Oracle maintains a high degree of transaction concurrency while keeping the database consistent via locks (enqueued locks) and what is called multiversion concurrency control system
What’s mulitversion concurrency?
Oracle allows a row to be written and read at the same time
“Writers won’t block Readers, Readers won’t block Writers” Oracle’s Slogan – but writers wait for other writers if they attempt to update identical rows
In order to maintain read consistency, Oracle maintains multiple temporary versions of data for read consistency
A reader reads an older version of data that’s locked and is being modified by another process
12/1/2018

16. Transactions & Read Consistency
12/1/2018
Transactions & Read Consistency
Example:
While transaction #2 is modifying block, transaction #1 tries to read same block
Current Version (as viewed by transaction #2, SCN=101)
Old Version (as viewed by transaction #1, SCN = 100)
Oracle Block Header
SCN =101
ITL Free Space …
Rows …
Empname = Jones, Extension = 7777
Oracle Block Header
SCN =100
ITL Free Space …
Rows …
Empname = Jones, Extension = 6666
12/1/2018

17. Transactions & Concurrency
12/1/2018
Transactions & Concurrency
The higher the concurrency, the higher the throughput of a database
To enable a high level of concurrency, Oracle applies locks in a least restrictive way – row-level locking
Oracle supports row- as well as table-level locking
These locks are implicitly applied by Oracle
12/1/2018

18. Oracle Lock Granularity
12/1/2018
Oracle Lock Granularity
Every time a user issues a lock, another process can be held back from using the locked resource
The lower lock granularity, the higher concurrency of access to Oracle database
A table-level lock prevents many users from modifying table data entirely
A row-level lock is the preferred lock and is the default lock used by Oracle
12/1/2018

19. Row-level Locking Strategy
12/1/2018
Row-level Locking Strategy
Each row within a table can be locked individually
The locking process has exclusive right to update the locked row
The remaining rows can be updated by other processes
All rows being updated can be read by other processes – they see the old version of the updated data via RBS blocks
12/1/2018

20. What Happens When A Row-level Lock Is Placed On A Row?
12/1/2018
What Happens When A Row-level Lock Is Placed On A Row?
1st a DML lock is placed on the row
No other processes can lock or update this row
This lock will be released when the locking process commits or rolls back
2nd a DDL lock is placed on the table containing the row to prevent anyone from altering or dropping the table while the row is undergoing the update
12/1/2018

21. What Happens When A Table-level Lock Is Placed On A Table?
12/1/2018
What Happens When A Table-level Lock Is Placed On A Table?
The Whole table is locked
Only the table-locking process can update rows in the table
(The above process, trying to update a row in the table, will obtain a Row Share Exclusive lock on the table as a whole)
No rows in the table can be updated by other processes – writers will block other writers
12/1/2018

22. What Happens When A Table-level Lock Is Placed On A Table?
12/1/2018
What Happens When A Table-level Lock Is Placed On A Table?
… The Whole table is locked
Other processes can query all rows, including the one being updated in the table – writers won’t block readers
These query-only processes are redirected to the locking process’s rollback data – writer’s rollback data used for read consistency
(The Row Share Exclusive lock is released upon transaction commit/rollback)
12/1/2018

23. Oracle Lock Modes There are two basic lock modes: Row exclusive (RX)
12/1/2018
Oracle Lock Modes
There are two basic lock modes:
Exclusive (X)
A lock held in this mode is for update and the resource held can be changed only by the holding process (until the lock is released)
Share (S)
Allows resource to be shared among multiple concurrent users
Prevents other users to acquire an exclusive lock to modify the shared resource
Row exclusive (RX)
Share (S) table locks
Share row exclusive (SRX) table lock
Exclusive (X) table lock
12/1/2018

24. Exclusive Locks Examples
12/1/2018
Exclusive Locks Examples
SQL Type
Lock Mode
Select ... From table …
No lock needed
Insert … Into table … RX
Delete From table …
Update table …
Select ... From table for update
Lock table in Row Exclusive mode
Lock Table in Share Row Exclusive mode
SRX
Lock Table in Exclusive mode X
12/1/2018

25. Shared Locks Examples SQL Type Lock Mode Lock table in Row Share Mode
12/1/2018
Shared Locks Examples
SQL Type
Lock Mode
Lock table in Row Share Mode RS
Lock table in Share Mode S
12/1/2018

26. Each Type of Lock Allows Other Locks To Be Granted On A Resource:
12/1/2018
Each Type of Lock Allows Other Locks To Be Granted On A Resource:
Exclusive (X) = Allow SELECT queries only
Share (S) = Allow ROW SHARE or SHARE locks to be granted to the locked rows.
Share Row Exclusive (SRX) = Allow ROW SHARE locks to be granted to the locked rows.
Row Exclusive (RX) = Allow ROW EXCLUSIVE or ROW SHARE locks to be granted to the locked rows.
Row Share (RS) = Allow ROW EXCLUSIVE or ROW SHARE or SHARE locks to be granted to the locked rows.
12/1/2018

27. Latches Latches provide exclusive access to data structures in the SGA
12/1/2018
Latches
Latches provide exclusive access to data structures in the SGA
They generally only allow a single process to examine a data structure of interest – and hence are very restrictive and do not promote concurrency
Latches act as short-term locks on simpler data structures
There is no request queuing mechanism for latches – they keep trying until the resource is acquired
12/1/2018

28. Lock Management By Oracle
12/1/2018
Lock Management By Oracle
Lock management is done implicitly on your behalf by Oracle
There is no lock management system in Oracle
Oracle resolves deadlocks automatically with small impact on system performance
Select name, value
From v$sysstat
Where name = ‘enqueue deadlocks’;
NAME VALUE
enqueue deadlocks
12/1/2018

29. 12/1/2018
Lock Management By DBA
As DBA you will be mainly concerned about a lock being held by a process which may be blocking other processes’ ability to modify the locked resource
Processes serialize on a resource due to a blocking lock
Oracle provides a utility: utllockt.sql
C:\oracle\ora92\rdbms\admin
WAITING_Session LOCK_TYP MODE_requested MODE_held LOCK_ID LOCK_ID2
None
Transaction Excl Excl
SQL> desc dba_locks;
Name Null? Type
SESSION_ID NUMBER
LOCK_TYPE VARCHAR2(26)
MODE_HELD VARCHAR2(40)
MODE_REQUESTED VARCHAR2(40)
LOCK_ID VARCHAR2(40)
LOCK_ID VARCHAR2(40)
LAST_CONVERT NUMBER
BLOCKING_OTHERS VARCHAR2(40)
12/1/2018

30. 12/1/2018
Blocking Locks
12/1/2018

31. 12/1/2018
Blocking Locks
(When processes requiring exclusive access to the same data are fired off at the same time, all will queue up behind the one process which grabs the lock 1st)
User actions may cause a process to be blocked
example:
a user kills a process with “kill -9” and submits the same process later, all the while the initial process is running and holding on to the blocking lock assuming that it had been “killed”
12/1/2018

32. Blocking Locks (Blocking locks can stop applications from processing)
12/1/2018
Blocking Locks
(Blocking locks can stop applications from processing)
Blocking locks are mainly:
TX (transaction) locks or
TM (table) locks
Example: session 1: SQL> Select * from scott.emp1 for update nowait; - (User goes to lunch)
- Guarantees user the 1st right to update emp table rows
session 2: SQL> update scott.emp1 set empno=empno+1;
- session 2 hangs waiting for session 1 to commit or rollback
12/1/2018

33. Blocking Locks Identify Blocking and blocked sessions
12/1/2018
Blocking Locks
Identify Blocking and blocked sessions
SQL> Select * from v$lock;
ADDR KADDR SID TY ID ID LMODE REQUEST CTIME BLOCK
682BE BE XR
682BE48C 682BE49C TS
67AA AA442C TM
682BE3A BE3B TX
67AF AF2A TX
67AA AA43A TM
SQL> select * from dba_blockers;
HOLDING_SESSION 10
SQL> select l1.sid "Blocking SID", l2.sid "Blocked SID"
from v$lock l1, v$lock l2
where l1.block =1 and l2.request > 0, and l1.id1=l2.id1 and l1.id2=l2.id2;
Blocking SID Blocked SID
12/1/2018

34. Blocking Locks Identify the Object: Select object_name
12/1/2018
Blocking Locks
Identify the Object:
Select object_name
From dba_objects
Where object_id=&id
Enter value for id: 30778
OBJECT_NAME
EMP1
Identify the obj#, file#, block#, and rowid of the blocked row:
Select row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#
From v$session
Where sid=&sid;
Enter value for sid: 9
ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
12/1/2018

35. Avoid Blocking Locks In Your Apps
12/1/2018
Avoid Blocking Locks In Your Apps
If pessimistic (early) locking implemented
“Select * from emp for update nowait”
Reduced app scalability through Blocking other processes
Have some mechanism in your app to time-out idle sessions
If optimistic locking (late locking) implemented
“Update emp set empno = empno -10”
Where ename = ‘Johnson’ ”
Improved app scalability – there is no advance locking
But be wary of Lost Updates
Opt for fine-granularity locking in your applications – row-level is better than table-level, etc.?
12/1/2018

36. (Blocking) Locks Useful Oracle Views & Scripts
12/1/2018
(Blocking) Locks Useful Oracle Views & Scripts
v$session is a useful view:
ROW_WAIT_OBJ# Database object
ROW_WAIT_FILE# File number
ROW_WAIT_BLOCK# Block number
ROW_WAIT_ROW# Row number (for row-level locks)
v$lock
v$process
utllockt.sql – Oracle’s report showing blocking and waiting sessions in a tree-structured format
v$waiters (run catblock.sql 1st)
Name
WAITING_SESSION
HOLDING_SESSION
LOCK_TYPE
MODE_HELD
MODE_REQUESTED
LOCK_ID1
LOCK_ID2
dba_blockers:
Name Null? Type
HOLDING_SESSION NUMBER
12/1/2018

37. User-Provided Data Client Box Oracle Server Box Oracle SID
12/1/2018
User-Provided Data
V$session:
osuser
process
module
v$session
sid
v$process
spid
Client
Box
Oracle Server
Box
User login name (os)
User process id (os)
User program module Name (user-submitted program name)
Oracle SID
Shadow process id (dedicated connection)
12/1/2018

38. 12/1/2018
User-Provided Data
A user may provide any or part of any of the following information to you, the DBA:
Client Machine/where he launched his program:
OS User name (v$session.osuser) User id name on client machine: vr1994
OS Process id (v$session.process)
User program process id number on client machine
Program Module name (v$session.module)
User program module name, iSQL*PLUS, SQL*PLUS
Oracle Server Machine:
OS Shadow Process id (v$process.spid) Shadow process id number – dedicated connection
Oracle Session id (v$session.sid)
User session’s sid
12/1/2018

39. Identifying the Blocking Session
12/1/2018
Identifying the Blocking Session
Identifying a session in an environment with numerous instances and databases can be a daunting experience
Users mostly know their application’s names and not more
You’ll need to make sense of the bits-and-pieces you may get from your users,
In order to pin-point the culprit session(s)
12/1/2018

40. Identifying the Blocking Session
12/1/2018
Identifying the Blocking Session
Ask user if s/he knows any of the following:
process id
Shadow process id
OS user id
Module name (iSQL*Plus, SQL*Plus, application name, etc.)
Session id
The SQL that was running when their process was blocked
12/1/2018

41. 12/1/2018
Identifying the Blocking Session: User Supplies The DBA What He Deems To Be His Job’s OS Process id On the Client Box
User supplies the process id of the program he launched from his machine (client-server1) or some parent/child process he believes is the process id: 2021
DBA must determine the target database user is connected to
DBA logs into remote-server1 and runs UNIX’s process status (ps)command
Traverse child process ids to the end
$ ps -ef |grep 2021|grep -v grep
vr :29:13 ?
$ ps -ef |grep 2050 |grep -v grep
vr :29:13 ?
$ ps -ef |grep 2059 |grep -v grep
vr :29:13 ?
$ ps -ef |grep 2231 |grep -v grep
vr :29:13 ?
12/1/2018

42. 12/1/2018
Identifying the Blocking Session: Using Program OS ID, determine The SID On Server Machine
select
s.sid sid, s.serial# serial, s.osuser osuser, s.username username, s.module module,p.spid spid, s.process process, s.machine machine, last_call_et active_length, to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') logontime, s.status status
from
v$process p, v$session s
where
s.paddr = p.addr (+)
and s.process = '&process'
SQL> /
Enter value for process: 2231
Module Shadow Remote Remote Session Session Session
SID Serial OS User Username name Process id Process id Server name active_length Logon Time Status
vr system iSQL*Plus client-server /18 11:14: ACTIVE
12/1/2018

43. 12/1/2018
Modify This SQL Where High-lighted In Green According To What’s On The Next two Slides
select
s.sid sid, s.serial# serial, s.osuser osuser, s.username username, s.module module,p.spid spid, s.process process, s.machine machine, last_call_et active_length, to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') logontime, s.status status
from
v$process p, v$session s
where
s.paddr = p.addr (+)
and s.process = '&process'
SQL> /
Enter value for process: 2231
Module Shadow Remote Remote Session Session Session
SID Serial OS User Username name Process id Process id Server name active_length Logon Time Status
vr system iSQL*Plus client-server /18 11:14: ACTIVE
12/1/2018

44. User Provided Data (Client Machine)
12/1/2018
User Provided Data (Client Machine)
OS User name (v$session.osuser) User id name on client machine: vr1994
where
s.paddr = p.addr (+)
and s.osuser = '&osuser‘
SQL>/
Enter value for osuser: vr1994
OS Process id (v$session.process)
User program process id number on client machine
and s.process = '&process‘
Enter value for process: 2231
Program Module name (v$session.module)
User program module name, iSQL*Plus, SQL*Plus, etc.
Enter value for module: iSQL*PLUS
and s.module = '&module‘
12/1/2018

45. User Provided Data (Server Machine)
12/1/2018
User Provided Data (Server Machine)
OS Shadow Process id (v$process.spid) - Shadow process id number (dedicated connection)
ps –ef | grep oracleTEST [instance name]| grep LOCAL=NO| grep 10:
oracle :33:31 ? :05 oracleTEST (LOCAL=NO)
oracle :20:01 ? :12 oracleTEST (LOCAL=NO)
oracle :20:12 ? :13 oracleTEST (LOCAL=NO)
oracle :20:14 ? :07 oracleTEST (LOCAL=NO)
where
s.paddr = p.addr (+)
and p.spid = '&spid‘
SQL> /
Enter value for shadow_pid:15551
Oracle Session id (v$session.sid) - User session’s sid
and s.sid = '&sid‘
Enter value for sid:15
Client
Box
Server Box
12/1/2018

46. Some v$session columns definitions
12/1/2018
Some v$session columns definitions
select
s.sid sid, s.serial# serial, s.osuser osuser, s.username username, s.module module,p.spid spid, s.process process, s.machine machine, last_call_et active_length, to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') logontime, s.status status
from
v$process p, v$session s
last_call_et: shows you how long the active session has been active
logon_time: Time when the user loged in
Status: Session status (active/inactice)
12/1/2018

47. Use Top Command to Display Shadow Process id
12/1/2018
Use Top Command to Display Shadow Process id
$ top
CPU TTY PID U SERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
? oracle M 6410K run : oracleTEST
? oracle M 6410K sleep : oracleTEST
? oracle M 6410K sleep : oracleTEST
12/1/2018

48. Identifying Blocking Locks
12/1/2018
Identifying Blocking Locks
select l.sid SID,
decode(l.type,'TM','DML','TX',
'Trans','UL','User',l.type) Lock_Type,
decode(l.lmode,0,'None',1,'Null',2,'Row-S',3,'Row-X',
4,'Share',5,'S/Row-X',6,'Exclusive', l.lmode) Lock_Held_In,
decode(l.request,0,'None',1,'Null',2,'Row-S',3,'Row-X',
4,'Share',5,'S/Row-X',6,'Exclusive', l.request) Lock_Req_In,
l.ctime Duration_Seconds,
decode(l.block,0,'NO',1,'YES') Blocking
from v$lock l
where l.request != 0 or l.block != 0
order by l.id1, l.lmode desc, l.ctime desc /
SID Lock_Type Lock_Held_In Lock_Req_In Duration_Seconds Blocking
Trans Exclusive None YES
Trans None Exclusive NO
12/1/2018

49. Kill The Blocking Session
12/1/2018
Kill The Blocking Session
select
s.sid sid, s.serial# serial, s.osuser osuser, s.username username, s.module module,p.spid spid, s.process process, s.machine machine, last_call_et active_length, to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') logontime, s.status status
from
v$process p, v$session s
where
s.paddr = p.addr (+)
and s.sid = '&sid'
SQL> /
Enter value for sid: 115
Module Shadow Remote Remote Session Session Session
SID Serial OS User Username name Process id Process id Server name active_length Logon Time Status
vr system iSQL*Plus client-server /18 11:14: ACTIVE
Alter system kill session ‘115,10366’ immediate;
12/1/2018

50. Identifying the Blocking Session: User Provides Locked Object’s Name
12/1/2018
Identifying the Blocking Session: User Provides Locked Object’s Name
From a separate session we submitted the following query:
SQL> lock table scott.emp in exclusive mode;
select l.sid sid, serial# Serial#,
decode(l.type,'TM','DML','TX','Trans','UL','User',l.type) Lock_Type,
decode(l.lmode,0,'None',1,'Null',2,'Row-S',3,'Row-X',4,'Share',5,'S/Row-X',6,'Excl') Lock_Mode,
o.owner Owner,
o.object_name Obj_Name,
l.ctime Duration_Seconds,
o.status Status
from dba_objects o, v$lock l, v$session s
where l.id1 = o.object_id
and o.object_name = upper (‘&object_name’)
and l.sid=s.sid
order by o.owner
Enter value for object_name: emp
SID Serial# Lock_Type Lock_Mode Owner Obj_Name Duration_Seconds Status
DML Excl SCOTT EMP VALID
Alter system kill session ‘13,4466’ immediate;
12/1/2018

51. Identifying Session’s Serial# User Provides Blocking SID
12/1/2018
Identifying Session’s Serial# User Provides Blocking SID
From a separate session we submitted the following query:
SQL> lock table scott.emp in exclusive mode;
select l.sid sid, serial# Serial#,
decode(l.type,'TM','DML','TX','Trans','UL','User',l.type) Lock_Type,
decode(l.lmode,0,'None',1,'Null',2,'Row-S',3,'Row-X',4,'Share',5,'S/Row-X',6,'Excl') Lock_Mode,
o.owner Owner,
o.object_name Obj_Name,
l.ctime Duration_Seconds,
o.status Status
from dba_objects o, v$lock l, v$session s
where l.id1 = o.object_id
and l.sid = &sid
and l.sid=s.sid
order by o.owner, o.object_name;
Enter value for sid: 13
SID Serial# Lock_Type Lock_Mode Owner Obj_Name Duration_Seconds Status
DML Excl SCOTT EMP VALID
Alter system kill session ‘13,4466’ immdediate;
12/1/2018

52. Precautionary Measures Before Killing a Session
12/1/2018
Precautionary Measures Before Killing a Session
Make every effort to contact the user
If the user cannot be reached, then contact his manager, (or someone with authority to give you the go-ahead to kill the session)
Ask if the user has killed any session(s)
Ask the user to a listing of all the actions he’s taken so far
Collect and verify user-supplied data about the session to be killed:
SID -- Oracle re-uses (completed, aborted and rolled- back) SIDs very quickly
Osuser
Oracle user name
Session start time
Module name
SQL being executed
12/1/2018

53. 12/1/2018
Some Useful Hints
1st Kill your session by using Oracle’s “Alter system kill session ‘pid,serial#’ immdediate;”
UNIX “Kill -9 process#” will not guarantee session termination
Use “kill -15”, instead of “kill -9”, wherever possible
Killing an active session can take minutes or sometime hours depending on: - Extent of un-committed changes made to the database by the transaction
When rollback process is completed, all session resources, locks, various memory spaces, are freed up
12/1/2018

54. 12/1/2018
Killing Steps
Display and verify all session information possible Module Shadow Remote Remote Session Session Session
SID Serial OS User Username name Process id Process id Server name active_length Logon Time Status
vr system iSQL*Plus client-server /18 11:14: ACTIVE
Alter system kill session ‘115,10366’ immdediate;
Confirm your kill: Module Shadow Remote Remote Session Session Session
vr system iSQL*Plus client-server /18 11:14: killed
Kill Shadow process: Kill
Verify again:
SQL> / (see slides xx & zz for the SQL)
Enter value for sid: 115
No rows selected (unless SID was reassigned in the interim!)
12/1/2018

55. Session Being Killed Is taking Long?
12/1/2018
Session Being Killed Is taking Long?
After killing a session, you may monitor the roll-back progress by running the following query, if session status remains ACTIVE:
select s.sid Sid,
s.username User_Name,
t.start_time Start_time,
t.used_ublk Blks_in_RBS,
t.status Xaction_Status
from v$session s, v$transaction t
where t.ses_addr = s.saddr
and s.sid = &sid;
Xaction
Sid User_Name Start_Time Blks_in_RBS Status
vr /17 10:13: ACTIVE
12/1/2018

56. Example User provides Module Name
12/1/2018
Example User provides Module Name
A user calls and asks that you must kill a series of sessions as they are blocked, providing you with module name (SQL*Plus)
Following is as example of what might have happened:
In Session 1 user submits the following statement through a SQL*Plus session:
Select * from scott.emp for update nowait;
From SQL*Plus sessions 3, 4, and 5 he submits the following simultaneously:
update scott.emp1 set empno = y;
12/1/2018

57. Example User Provides Module Name, Show Blocking/Blocked Session
12/1/2018
Example User Provides Module Name, Show Blocking/Blocked Session
SQL> l
Select l.sid SID,
decode(l.type,'TM','DML','TX',
'Trans','UL','User',l.type) Lock_Type,
decode(l.lmode,0,'None',1,'Null',2,'Row-S',3,'Row-X',
4,'Share',5,'S/Row-X',6,'Exclusive', l.lmode) Lock_Held_In,
decode(l.request,0,'None',1,'Null',2,'Row-S',3,'Row-X',
4,'Share',5,'S/Row-X',6,'Exclusive', l.request) Lock_Req_In,
l.ctime Duration_Seconds,
decode(l.block,0,'NO',1,'YES') Blocking
From v$lock l
Where l.request != 0 or l.block != 0
order by l.id1, l.lmode desc, l.ctime desc
SQL> /
SID LOCK_TYPE LOCK_ HELD_IN LOCK_REQ_IN DURATION_SECONDS BLOCKING
Trans Exclusive None ,069 YES
Trans None Exclusive , NO
Trans None Exclusive , NO
Trans None Exclusive , NO
12/1/2018

58. 12/1/2018
Example User Provides Module Name, Display SID, Serial#, shadow_pid, etc.
select
s.sid sid, s.serial# serial, s.osuser osuser, s.username username, s.module module,p.spid spid, s.process process, s.machine machine, last_call_et active_length, to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') logontime, s.status status
from
v$process p, v$session s
where
s.paddr = p.addr (+)
and s.module = '&module‘
SQL> /
Enter value for module: SQL*Plus
SID SERIAL OSUSER USERNAME MODULE SPID PROCESS LOGONTIME STATUS
PULSER\Vil SYSTEM SQL*Plus : /24/06 16:54:24 ACTIVE
PULSER\Vil SYSTEM SQL*Plus : /24/06 14:46:24 ACTIVE
PULSER\Vil SYSTEM SQL*Plus : /24/06 14:47:19 ACTIVE
PULSER\Vil SYSTEM SQL*Plus : /24/06 16:57:29 ACTIVE
12/1/2018

59. 12/1/2018
Example Using Shadow_pid, Create Script To Kill Multiple Shadow Processes
spool kill_shadows.ksh
select 'kill -15 ' || p.spid
from v$process p , v$session s
where s.module = '&Module_Name'
and s.paddr = p.addr (+)
order by s.sid /
spool off
Enter value for Module_Name: SQL*Plus
kill
kill
kill
kill
12/1/2018

60. Example Create Script to Kill Oracle Sessions
12/1/2018
Example Create Script to Kill Oracle Sessions
Spool alter_kill_sessions.sql
Select 'alter system kill session ' || ''''|| sid
|| ',' || serial# ||'''' || ' immediate;'
From v$session
Where module = '&module'
Order by sid /
Spool off
alter system kill session '9,9' immediate;
alter system kill session '10,8' immediate;
alter system kill session '12,18' immediate;
alter system kill session '15,290' immediate;
Then execute scripts in the following order:
$ kill_shadows.ksh
12/1/2018

61. Conclusion: What Can A DBA or Manager Do?
12/1/2018
Conclusion: What Can A DBA or Manager Do?
Proactively monitor Blocking Locks in the system
Limit the time that a row/resource is locked
Ask developers to solve it in the application so that the locking resource session times out
Ask DBAs to use Resource Profiles so that the locking resource session times out when it reaches “Kernel Limits”
“Maximum connect/idle time”
SQL> select * from dba_profiles;
PROFILE RESOURCE_NAME RESOURCE LIMIT
DEFAULT CONNECT_TIME KERNEL UNLIMITED
DEFAULT IDLE_TIME KERNEL UNLIMITED
DEFAULT CPU_PER_SESSION KERNEL UNLIMITED
DEFAULT PASSWORD_GRACE_TIME PASSWORD UNLIMITED …
To enable kernel limits 1st set resource limit to TRUE
NAME TYPE VALUE
enqueue_resources integer
resource_limit boolean FALSE
12/1/2018

62. What Can you Do AS DBA or Manager
12/1/2018
What Can you Do AS DBA or Manager
Work closely with developers and check out their code before they get into production systems
12/1/2018

63. www.dbpulsegroup.com (925) 216-6239 vil@dbpulsegroup.com
12/1/2018
(925)
12/1/2018