Oracle 12.1.0.2中对象锁对系统的较大影响

131次阅读

共计 3399 个字符，预计需要花费 9 分钟才能阅读完成。

环境：Oracle 12.1.0.2 RAC，4 节点。

一、概述

通常来说，如果是 oltp 应用，那么部署在 rac 上，是不错的注意。但实现情况中，往往是混合类型，既有 OLTP 也有 OLAP。如果没有很好地进行资源管理和系统设计，那么系统的性能往往不如人意。造成系统慢的原因很多，其中一个就是 oracle rac 特有结构的负面作用。

例如如果一个过程或者包正在执行，且是一个长会话，需要很久才会释放，这个时候企图编译包，造成的一个大问题就是系统变慢，登录变慢。这是因为，编译会话企图获得执行包的排它锁，所以它需要不停地轮询各个实例，看这个对象是否被锁，结果毫无疑问，是被锁住，过了一会又会去查询。而我们知道，在多个实例之间查询对象的锁状态还是比较费时的，尤其是系统中有巨量锁的情况下，这个会耗费许多的 CPU。最终就是系统变慢。

二、方法

那么是否有可以解决的办法了？

oracle 本身并不提供这样的工具，但作为 dba 只能取监测这样的监测过程。

那么应该监视什么字典表呢？

监视 v$db_cache_object

关键的问题是，这个视图不知道是哪个会话，所以即使知道了，也难于执行 kill session 的操作。

监视 dba_ddl_locks

注：在这个视图中，不表明这个对象无法被编译，除非是排它的锁。

dba_ddl_lock$ 的定义

create or replace view sys.dba_ddl_locks as
select  s.sid session_id,
          substr(ob.kglnaown,1,30) owner,
          substr(ob.kglnaobj,1,30) name,
    decode(ob.kglhdnsp, 0, 'Cursor', 1, 'Table/Procedure/Type', 2, 'Body',
           3, 'Trigger', 4, 'Index', 5, 'Cluster', 13, 'Java Source',
             14, 'Java Resource', 32, 'Java Data', to_char(ob.kglhdnsp)) type,
    decode(lk.kgllkmod, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
       'Unknown') mode_held,
    decode(lk.kgllkreq,  0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
       'Unknown') mode_requested
   from v$session s, x$kglob ob, x$kgllk lk
   where lk.kgllkhdl = ob.kglhdadr
   and   lk.kgllkuse = s.saddr
   and   ob.kglhdnsp != 0;

其中

x$kgllk —[K]ernel [G]eneric [L]ibrary Cache Manager object [L]oc[K]s – 核心库缓存管理对象锁

x$kglob—[K]ernel [G]eneric [L]ibrary Cache Manager [OB]ject – 核心库缓存管理对象

前者是后者的明细，双方通过

– 关于 x$kgllk 的定义

SQL> desc x$kgllk;
名称类型
———- ———–
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
KGLLKADR RAW(4) —
KGLLKUSE RAW(4) — 会话地址(对应 v$session 的 saddr)
KGLLKSES RAW(4) —owner 地址
KGLLKSNM NUMBER —SID
KGLLKHDL RAW(4) —library cache object 句柄
KGLLKPNC RAW(4) —the address of the call pin
KGLLKPNS RAW(4) — 对应跟踪文件中的 session pin 值
KGLLKCNT NUMBER
KGLLKMOD NUMBER — 持有锁的模式(0 为 no lock/pin held﹐1 为 null,2 为 share﹐3 为 exclusive)
KGLLKREQ NUMBER — 请求锁的模式(0 为 no lock/pin held﹐1 为 null,2 为 share﹐3 为 exclusive)
KGLLKFLG NUMBER —cursor 的状态﹐8(10g 前) 或 2048(10g)表示这个 sql 正在运行﹐
KGLLKSPN NUMBER — 对应跟踪文件的 savepoint 的值
KGLLKHTB RAW(4)
KGLNAHSH NUMBER —sql 的 hash 值(对应 v$session 的 sql_hash_value)
KGLLKSQLID VARCHAR2(13) —sql ID，sql 标识符
KGLHDPAR RAW(4) —sql 地址(对应 v$session 的 sql_address)
KGLHDNSP NUMBER
USER_NAME VARCHAR2(30) — 会话的用戶名
KGLNAOBJ VARCHAR2(60) — 对象名称或者已分析并打开 cursor 的 sql 的前 60 个字符

– 关于 x$kglob 的定义

具体略。

在 cdb-rac 根中监视被锁定过程和会话

原有的 dba_ddl_locks 视图只是适用于单实例，为了方便 cdb-rac 的监视，必须进行调整。

create or replace view gv_ddl_locks as
select    s.con_id,
          p."PDB_NAME",
          s.inst_id,
          s.sid session_id,
          s.serial#,
          substr(ob.kglnaown,1,128) owner,
          substr(ob.kglnaobj,1,1000) name,
    decode(ob.kglhdnsp, 0, 'Cursor', 1, 'Table/Procedure/Type', 2, 'Body',
           3, 'Trigger', 4, 'Index', 5, 'Cluster', 13, 'Java Source',
             14, 'Java Resource', 32, 'Java Data', to_char(ob.kglhdnsp)) type,
    decode(lk.kgllkmod, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
     'Unknown') mode_held,lk.kgllkmod,
    decode(lk.kgllkreq,  0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
     'Unknown') mode_requested
   from  gv$session s, x$kglob ob, x$kgllk lk,cdb_pdbs p,GV$DB_OBJECT_CACHE GCO
   where lk.kgllkhdl = ob.kglhdadr and lk.con_id=ob.con_id and lk.inst_id=ob.inst_id
   and   lk.kgllkuse = s.saddr and lk.con_id=s.con_id and lk.inst_id=s.inst_id
   AND   GCO.INST_ID=OB.INST_ID AND GCO.CON_ID=OB.CON_ID AND GCO.ADDR=OB.KGLHDADR AND GCO.LOCKS<>0
   and   p."CON_ID"=s.con_id
   and   ob.kglhdnsp != 0;