会话执行存储过程，等待被阻塞，Kill session场景模拟

本次场景来源：

通知某个会话：执行execute addupp(1,'five');类似的存储过程，会话等待：（会话等待两种情况：一种确实执行，但是未完成；另一种就是执行的操作无法获取资源，等待资源释放，即锁等待），本次测试锁：行锁等待测试：

本次场景测试：如何快速定位持有锁的会话，kill 释放资源

本次场景操作：

存储过程：执行Update操作，行锁等待，多个会话执行造成：行锁争用，会话被堵塞

模拟环境：行锁如何模拟：争用并发及锁，Lock 有序列，排队

#场景模拟在线： 用户scott，测试表ceshi 
#模拟会话一：调用存储A，插入3条测试数据
#模拟会话一：调用存储B，更新一条数据 SYS
#模拟会话二：调用储存B，更新（会话一）上条已经更新未提交的数据行，造成阻塞Yang
#模拟会话三：直接Update更新相同的数据行 cc用户
#模拟会话五、业务操作:更新数据发现阻塞：scott用户

测试表结构、insert存储过程A、update存储过程B如下所示：

SQL> desc ceshi Name
   Null?    Type
 ----------------------------------
 ID              NUMBER()
 NAME           VARCHAR2()

 #SYS用户创建存储过程：

#存储A
create or replace procedure
 addnew
 (n_id NUMBER, n_name VARCHAR2 )
 as
begin
 insert
 into scott.ceshi(id,name)
 values(n_id,n_name);
 commit;
 end addnew;
/

#存储B
create or replace procedure
 addupp
 (u_id NUMBER, u_name VARCHAR2 )
 as
begin
 update
 scott.ceshi set name='u_name'
 where id=u_id; end addupp;
/

#创建完成查询：

SQL> select OBJECT_NAME,OBJECT_TYPE,STATUS from user_objects where object_type='PROCEDURE' and OBJECT_NAME  like 'ADD%';

OBJECT_NAME  OBJECT_TYPE    STATUS

------------------------------------

ADDNEW        PROCEDURE      VALID

ADDUPP        PROCEDURE      VALID

#测试场景权限、数据处理：

SYS用户调用存储A：Insert 3条数据
SQL> execute addnew(,'yang');
SQL> execute addnew(,'cheng');
SQL> execute addnew(,'hehe');

#授予测试yang / cc 两个用户对测试表的对象权限：
SQL> grant select on scott.ceshi to yang;
SQL> grant update on ceshi to yang;
SQL> grant select on scott.ceshi to cc;
SQL> grant update on scott.ceshi to cc;

 存储过程授权：
 grant execute on addupp to yang;
 grant execute on addupp to cc;

#会话一：sys用户调用存储B，更新id=1,name='one'

 SQL> show user USER is "SYS"
 SQL> execute addupp(1,'one');

SQL> select * from scott.ceshi;

 ID NAME
 ----------
 1 one
 2 cheng
 3 hehe

#会话二：yang用户调用存储B，更新id=1,name='two'

SQL> show user USER is "YANG"
SQL> execute addupp(1,'two'); --等待

#会话三：cc用户调用存储B，更新id=1,name='three'

SQL> show user USER is "CC"
SQL> update scott.ceshi set name='three' where id=1;

#会话四：Scott用户调用存储B，更新id=1,name='five'

SQL> show user USER is "SCOTT"
SQL> execute addupp(1,'five');

##################以上是场景模拟，在线还原#################################
 #######################################以下是解决问题#####################

#我们很可能收到的通知是：执行操作发生等待，无法执行后，上报给我们xxx无法执行，上锁了

####SQL> execute addupp(1,'five'); @无法执行

处理思路：=>等待、无法执行原因：锁

=>什么对象

=>哪些会话在等待，持有这些资源

=>查询会话ID,SERIAL，Kill杀死会话，释放资源，让业务能快速恢复

=>查询对象类型：

SQL> select OWNER,OBJECT_NAME,OBJECT_TYPE from dba_objects where owner='SCOTT' and object_name='ADDUPP';

OWNER     OBJECT_NAME         OBJECT_TYPE

--------------------------------------------------------------------------------
SCOTT      ADDUPP               PROCEDURE

=>查询：被锁定的对象及锁定次数

视图V$DB_OBJECT_CACHE： 找到被锁定的对象

#通过此视图：可以找出某个用户下：被锁定的对象，及锁定次数
 col name for a10
 col type for a20
 col locks for 999
 col locked_total 9999
 select
 name,type,locks,locked_total from v$db_object_cache where owner='SCOTT' and
 locks is not null;
NAME       TYPE                 LOCKS LOCKED_TOTAL
---------- -------------------- ----- ------------
CESHI       TABLE                    0           60
DBMS_OUTPUT CURSOR                   0           17
ADDUPP     PROCEDURE                1            2
SCOTT      PUB SUB INTERNAL INF     1            3

#根据应用反馈的命令 or 用户对象，本次关注点：是ADDUPP 调用程序，无法执行

#通过被锁定的对象：找到被锁定的SID

 视图：V$ACCESS  #显示当前施加在库高速缓存对象上的锁定信息：
  SID 访问对象的会话编号
  OWNER  对象拥有者
  OBJECT 对象名称
  TYPE    对象类型

 #通过此视图：找到那些用户对此对象进行了锁定  select * from v$access;
select * from v$access where type='PROCEDURE' and object='ADDUPP';
     SID OWNER     OBJECT      TYPE
---------- ----------------------------------------------------------------
     40 SCOTT      ADDUPP    PROCEDURE
     42 YANG       ADDUPP    PROCEDURE

#####注意：RAC环境下：需要注意Inst_id 实例序号：

#通过SID找到会话serial#

 #v$session 视图：

 select sid,serial#,username,TIME_SINCE_LAST_WAIT_MICRO,BLOCKING_SESSION_STATUS from v$session where
 sid in (40,42);

       SID    SERIAL# USERNAME TIME_SINCE_LAST_WAIT_MICRO BLOCKING_SE
---------- ---------- ------------------------------ ----------------
        40        275 SCOTT               0                    VALID
        42        897 YANG                0                    VALID

#SID  会话标识符
#SERIAL# 会话标识符，可重复使用，为了避免重复：会话序列号标识： sid+ serial#= 唯一会话信息
#USERNAME 会话登录用户名
#TIME_SINCE_LAST_WAIT_MICRO 会话最后一次执行操作--距离现在多少秒，会话空闲时间
#BLOCKING_SESSION_STATS  会话是否被阻塞：被阻塞则状态为valid

#此时可以使用如下命令：立即杀死被锁定的会话：

# alter system kill session 'sid,serial#' immediate;

#但是对于本次实验测试来说，锁还是存在的，SYS用户是源头，还未查询得到信息：

#继续查询分析：如何找到锁的源头：

#当：BLOCKING_SESSION_STATUS的状态为vaild代表会话被阻塞：
 #找到阻塞的源头会话：
 SQL> select sid,serial#,username,blocking_session_status,BLOCKING_INSTANCE,
 BLOCKING_SESSION,FINAL_BLOCKING_SESSION_STATUS,FINAL_BLOCKING_INSTANCE,
 FINAL_BLOCKING_SESSION from v$session where  sid in (,);
 ----------------- ---------------- ----------- -----------------------
        SID                                会话ID
      SERIAL#                            会话序列号
      USERNAME                 SCOTT    YANG   会话用户名
 blocking_session_status       VALID    VALID  会话是否被阻塞：VALID有阻塞 no holder没有阻塞
  BLOCKING_INSTANCE                           阻塞会话的实例号
  BLOCKING_SESSION                          阻塞会话ID
 FINAL_BLOCKING_SESSION_STATUS VALID    VALID   有一个阻塞源头会话： no holder没有会话阻塞
  FINAL_BLOCKING_INSTANCE                     阻塞源头会话实例ID
FINAL_BLOCKING_SESSION                      阻塞源头ID 

#yang用户在等待会话ID 51释放行锁：
#51用户的信息：
SQL> select sid,serial#,username from v$session where sid=;

       SID    SERIAL# USERNAME
---------- ---------- ------------------------------
                SYS

#本次实验有个遗憾：

三个update都是使用存储过程调用执行，

其中两个会话通过V$ACCESS堵塞对象进行查询，

另一个会话通过v$session阻塞源头会话查询得到

但是？ 还有一个会话cc 使用的是update直接操作执行，本次未分析得到：

##########如何快速，链路分析锁等待#######

使用工具： oradebug

有锁，使用Oradebug 工具生成trace文件进行分析：

#操作
 SQL> oradebug hanganalyze 3
Hang Analysis in /picclife/app/oracle/diag/rdbms/aa/dingding/trace/dingding_ora_6118.trc

分析trace文件：

# 处理 攻击：命令：挂起分析级别3
Processing Oradebug command 'hanganalyze 3'

*** 2018-04-08 12:03:34.037
===============================================================================
HANG ANALYSIS:  挂起分析：
  instances (db_name.oracle_sid): aa.dingding  数据库.实例名称
  oradebug_node_dump_level: 3
  analysis initiated by oradebug   分析：每秒采样一次

 #最有可能引起的  Hang链路
Chains most likely to have caused the hang:
#  来自客户端sql*net消息，行锁
 [a] Chain 1 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'
     Chain 1 Signature Hash: 0x38c48850
 [b] Chain 2 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'
     Chain 2 Signature Hash: 0x38c48850
 [c] Chain 3 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'
     Chain 3 Signature Hash: 0x38c48850
 

三条链路：行锁：

第一条链路：

Chain 1:   链路1
            session id: 40             会话ID
        session serial #: 275            会话序列号

#######通过如上信息查询：为SCOTT用户，等待用户#########
SQL> select username from v$session where sid=40 and serial#=275;

USERNAME
------------------------------
SCOTT

             is waiting for 'enq: TX - row lock contention' with wait info:
            time in wait: 50 min 58 sec ###等待时间 50分钟 58秒   
  要执行的SQL：  update
             current sql: UPDATE CESHI SET NAME='u_name' WHERE ID=:B1 

and is blocked by   阻塞用户（罪魁祸首）：
        session id: 51      阻塞用户ID
        session serial #: 3135    阻塞用户序列号  ：如下等待客户端返回信息

 ####链1签名：“来自客户机的SQL*Net消息”=“Enq:TX-行锁定争用”#####
Chain 1 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'

第二条链路：

Chain 2:
         session id: 35         会话35：
        session serial #: 583        SERIAL# 583

######经过查询：此等待用户是CC用户
SQL> select username from v$session where sid=35 and serial#=583;

USERNAME
------------------------------
CC  

###也是Udate信息 ：是直接执行，不是调用程序
             current sql: update scott.ceshi set name='three' where id=1

 # 本会话是链路一的成员

 # 被实例一，会话ID 51,SESSION阻塞，
    and is blocked by 'instance: 1, os id: 5854, session id: 51',
    which is a member of 'Chain 1'.

第三条链路：

Chain :
                 session id:
        session serial #: 

#######是用户yang，等待会话ID51释放锁
 SQL> select username from v$session where sid= and serial#=;

USERNAME
------------------------------
YANG   

             current sql: UPDATE SCOTT.CESHI SET NAME='u_name' WHERE ID=:B1 

#同样被会话id 51堵塞，是链路一的成员
 and is blocked by 'instance: 1, os id: 5854, session id: 51',
    which is a member of 'Chain 1'.

Chain  Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'

小结:

链路一、scott用户：调用存储过程更新SCOTT.CESHI：被会话51堵塞，链路一

链路二、CC用户：update操作SCOTT.CESHI：被会话51堵塞，链路一成员

链路三、YANG用户：调用存储过程更新SCOTT.CESHI：被会话51堵塞，链路一

#SID 51用户的信息：
SQL> select sid,serial#,username from v$session where sid=51;

       SID    SERIAL# USERNAME
---------- ---------- ------------------------------
        51       3135 SYS

#找到链路上堵塞源头：+堵塞会话，剩下就是考虑杀谁，放谁了