Oracle Clinic - Maclean Liu的个人技术博客

Archivelog Completed Before VS UNTIL TIME

Maclean Liu — Thu, 17 May 2012 13:10:32 +0000

有网友在T.ASKMACLEAN.COM上提问关于”DELETE ARCHIVELOG ALL COMPLETED BEFORE” 与 “DELETE ARCHIVELOG UNTIL TIME “的区别。为了了解这2个命令细微的差别，我们先来温习一些 ARCHIVED LOG的知识。

V$ARCHIVED_LOG:

FIRST_TIME             DATE     Timestamp of the first change
NEXT_TIME              DATE     Timestamp of the next change
COMPLETION_TIME        DATE     Time when the archiving completed

FIRST_TIME代表该归档日志中LOW SCN对应的时间戳，而NEXT_TIME代表HIGH SCN对应的时间戳； COMPLETION_TIME指该日志实际归档成功的时间，当归档可以快速完成时 NEXT_TIME往往等于COMPLETION_TIME，但是也存在因为LOGFILE SIZE尺寸较大导致archive归档操作持续较长时间，导致 NEXT_TIME << COMPLETION_TIME的情况存在。

我们来看一个例子：

首先通过修改log_archive_max_processes=1，保证实例只拥有一个ARC0归档进程:

SQL> select * from V$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL>
SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.oracledatabase12g.com

SQL> alter system set log_archive_max_processes=1;
System altered.

[oracle@vrh8 udump]$ ps -ef|grep arc|grep -v grep
oracle   21777     1  0 07:22 ?        00:00:00 ora_arc0_G10R25

SQL> alter session set nls_date_format='YYYY-MM-DD hh24:mi:ss';
Session altered.

SQL> select  SEQUENCE#, FIRST_CHANGE# from v$log where status='CURRENT';

 SEQUENCE# FIRST_CHANGE#
---------- -------------
       232       2476748

CURRENT LOGFILE当前在线日志的SEQUENCE#=232， FIRST_CHANGE#=2476748。

我们利用oradebug suspend 命令将ARC0归档后台进程强制挂起，这将导致归档长时间无法完成；注意不要在生产环境做这样的操作！！

SQL> oradebug setospid 21777;
Oracle pid: 20, Unix process pid: 21777, image: oracle@vrh8.oracle.com (ARC0)

SQL> oradebug suspend;
Statement processed.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

WAIT A MOMENT;

SQL> select sequence#,name,first_time,next_time,COMPLETION_TIME from v$archived_log where sequence# =( select max(sequence#) from v$archived_log);

 SEQUENCE#
----------
NAME
--------------------------------------------------------------------------------
FIRST_TIME          COMPLETION_TIME
------------------- -------------------
       231
/s01/flash_recovery_area/G10R25/archivelog/2012_05_17/o1_mf_1_231_7v9rh2rg_.arc
2012-05-17 07:32:44 2012-05-17 07:32:50

可以看到手动suspend ARC0后switch logfile，归档没有照常发生，V$ARCHIVED_LOG中最大的SEQUENCE#仍是 231。之后我们resume ARC0：

SQL> exec dbms_lock.sleep(60);

SQL> oradebug resume;
Statement processed.

SQL>  set linesize 80  pagesize 1400;
SQL>  select sequence#,name,first_time,next_time,COMPLETION_TIME from v$archived_log where sequence# =( select max(sequence#) from v$archived_log);

 SEQUENCE#
----------
NAME
--------------------------------------------------------------------------------
FIRST_TIME          NEXT_TIME           COMPLETION_TIME
------------------- ------------------- -------------------
       232
/s01/flash_recovery_area/G10R25/archivelog/2012_05_17/o1_mf_1_232_7v9s3dcf_.arc
2012-05-17 07:32:50 2012-05-17 07:41:32 2012-05-17 07:43:40

NEXT_TIME=07:41:32 而 COMPLETION_TIME= 07:43:40，相差了2分钟左右。

DUMP LOGFILE可以了解更多信息：

SQL> alter system dump logfile '/s01/flash_recovery_area/G10R25/archivelog/2012_05_17/o1_mf_1_232_7v9s3dcf_.arc';

System altered.

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug tracefile_name
/s01/admin/G10R25/udump/g10r25_ora_21848.trc

SQL> !vi /s01/admin/G10R25/udump/g10r25_ora_21848.trc

 Low  scn: 0x0000.0025cacc (2476748) 05/17/2012 07:32:50
 Next scn: 0x0000.0025cb8f (2476943) 05/17/2012 07:41:32
 Enabled scn: 0x0000.0005eca9 (388265) 11/07/2011 03:58:11
 Thread closed scn: 0x0000.0025cacc (2476748) 05/17/2012 07:32:50

以上我们复习了关于ARCHIVED LOG 的FIRST_TIME和 COMPLETION_TIME的知识，接下来我们实际来了解”DELETE ARCHIVELOG ALL COMPLETED BEFORE” 与 “DELETE ARCHIVELOG UNTIL TIME “的区别。

RMAN会通过$ORACLE_HOME/rdbms/admin/recover.bsq将RMAN命令解析成PL/SQL包的调用，包括：DBMS_RCVMAN和DBMS_BACKUP_RESTORE等内置PACKAGE。

当使用BACKUP/DELETE ARCHIVELOG “Completed Before”/”UNTIL TIME”时DBMS_RCVMAN会调用以下一个SQL语句，查询V$ARCHIVED_LOG视图中是否有满足条件的归档日志：

HASH_VALUE=  3114867949

SELECT :B20 TYPE_CON,
       RECID KEY_CON,
       RECID RECID_CON,
       STAMP STAMP_CON,
       TO_NUMBER(NULL) SETSTAMP_CON,
       TO_NUMBER(NULL) SETCOUNT_CON,
       TO_NUMBER(NULL) BSRECID_CON,
       TO_NUMBER(NULL) BSSTAMP_CON,
       TO_NUMBER(NULL) BSKEY_CON,
       TO_NUMBER(NULL) BSLEVEL_ CON,
       TO_CHAR(NULL) BSTYPE_CON,
       TO_NUMBER(NULL) ELAPSESECS_CON,
       TO_NUMBER(NULL) P IECECOUNT_CON,
       NAME FILENAME_CON,
       TO_CHAR(NULL) TAG_CON,
       TO_NUMBER(NULL) COPYNUM BER_CON,
       STATUS STATUS_CON,
       BLOCKS BLOCKS_CON,
       BLOCK_SIZE BLOCKSIZE_CON,
       'DISK' DEVICETYPE_CON,
       COMPLETION_TIME COMPTIME_CON,
       TO_DATE(NULL) CFCREATIONTIME_CON,
       TO_NUMBER(NULL) PIECENUMBER_CON,
       TO_DATE(NULL) BPCOMPTIME_CON,
       TO_CHAR(NULL) BPC OMPRESSED_CON,
       :B19 TYPE_ACT,
       TO_NUMBER(NULL) FROMSCN_ACT,
       TO_NUMBER(NULL) TOSCN _ACT,
       TO_DATE(NULL) TOTIME_ACT,
       TO_NUMBER(NULL) RLGSCN_ACT,
       TO_DATE(NULL) RLGTIM E_ACT,
       TO_NUMBER(NULL) DBINCKEY_ACT,
       TO_NUMBER(NULL) LEVEL_ACT,
       TO_NUMBER(NULL) DFNUMBER_OBJ,
       TO_NUMBER(NULL) DFCREATIONSCN_OBJ,
       TO_NUMBER(NULL) CFSEQUENCE_OBJ,
       TO_DATE(NULL) CFDATE_OBJ,
       SEQUENCE# LOGSEQUENCE_OBJ,
       THREAD# LOGTHREAD_OBJ,
       RES ETLOGS_CHANGE# LOGRLGSCN_OBJ,
       RESETLOGS_TIME LOGRLGTIME_OBJ,
       FIRST_CHANGE# LOGLO WSCN_OBJ,
       FIRST_TIME LOGLOWTIME_OBJ,
       NEXT_CHANGE# LOGNEXTSCN_OBJ,
       NEXT_TIME LOGN EXTTIME_OBJ,
       DECODE(END_OF_REDO_TYPE, 'TERMINAL', 'YES', 'NO') LOGTERMINAL_OBJ,
       T O_CHAR(NULL) CFTYPE_OBJ,
       TO_NUMBER(NULL) KEEP_OPTIONS,
       TO_DATE(NULL) KEEP_UNTIL,
       TO_NUMBER(NULL) AFZSCN_ACT,
       TO_DATE(NULL) RFZTIME_ACT,
       TO_NUMBER(NULL) RFZSCN_A CT,
       TO_CHAR(NULL) MEDIA_CON,
       IS_RECOVERY_DEST_FILE ISRDF_CON
  FROM V$ARCHIVED_LOG
 WHERE (:B18 IS NULL OR THREAD# = :B18)
   AND (:B17 IS NULL OR SEQUENCE# = :B17)
   AND (:B16 IS NULL OR FIRST_CHANGE# = :B16)
   AND (:B15 IS NULL OR NAME LIKE :B15)
   AND (:B14 IS NULL OR COMPLETION_TIME >= :B14)
   AND (:B13 IS NULL OR COMPLETION_TIME <= :B13)
   AND DECODE(:B10,
              :B12,
              DECODE(STATUS, 'A', :B9, :B11),
              DBMS _RCVMAN.ISSTATUSMATCH(STATUS, :B10)) = :B9
   AND STANDBY_DEST = 'NO'
   AND (ARCHIVE D = 'YES')
   AND (:B8 IS NULL OR THREAD# = :B8)
   AND (:B7 IS NULL OR SEQUENCE# >= :B7)
   AND (:B6 IS NULL OR SEQUENCE# <= :B6)
   AND (:B5 IS NULL OR NEXT_CHANGE# > :B5)
   AND (:B4 IS NULL OR FIRST_CHANGE# < :B4)
   AND (:B3 IS NULL OR NAME LIKE :B 3)
   AND (:B2 IS NULL OR NEXT_TIME > :B2)
   AND (:B1 IS NULL OR FIRST_TIME <= :B1)
 ORDER BY RESETLOGS_CHANGE#,
          RESETLOGS_TIME,
          THREAD#,
          SEQUENCE#,
          LOGTERMINAL_OB    J DESC,
          STAMP_CON         DESC

已知该语句的HASH_VALUE=3114867949 ，虽然该语句使用了绑定变量且似乎10046 TRACE capture不到其BIND VALUE，但仍可以通过v$sql_bind_capture视图找到：

当DELETE ARCHIVELOG UNTIL TIME ‘SYSDATE-7′;执行时：

col name for a20
col value_string for a50		  

SQL> select name,value_string from v$sql_bind_capture where hash_value='3114867949';

:B20
:B19
:B18                 NULL
:B18                 NULL
:B17                 NULL
:B17                 NULL
:B16                 NULL
:B16                 NULL
:B15                 NULL
:B15                 NULL
:B14                 NULL
:B14                 NULL
:B13                 NULL
:B13                 NULL
:B10                 27
:B12                 1
:B9                  1
:B11                 0
:B10                 27
:B9                  1
:B8                  NULL
:B8                  NULL
:B7                  NULL
:B7                  NULL
:B6                  NULL
:B6                  NULL
:B5                  NULL
:B5                  NULL
:B4                  NULL
:B4                  NULL
:B3                  NULL
:B3                  NULL
:B2                  NULL
:B2                  NULL
:B1                  05/10/12 07:15:26
:B1                  05/10/12 07:15:26

36 rows selected.

其中有意义的绑定值为：

:B1 05/10/12 07:15:26 =》即SYSDATE – 7

可以在上述SQL中找到相关条件:B1 IS NULL OR FIRST_TIME <= :B1，即 FIRST_TIME <= ‘SYSDATE-7′;

即 UNTIL TIME 的TIME指的是 ARCHIVELOG的FIRST_TIME ，即归档日志中LOW SCN对应的时间戳；其意思为找出所有LOW SCN TIMESTAMP小于等于指定的时间变量的归档日志。

当DELETE ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-7′;执行时：

SQL> select name,value_string from v$sql_bind_capture where hash_value='3114867949';

:B20
:B19
:B18                 NULL
:B18                 NULL
:B17                 NULL
:B17                 NULL
:B16                 NULL
:B16                 NULL
:B15                 NULL
:B15                 NULL
:B14                 NULL
:B14                 NULL
:B13                 05/10/12 07:21:00
:B13                 05/10/12 07:21:00
:B10                 27
:B12                 1
:B9                  1
:B11                 0
:B10                 27
:B9                  1
:B8                  NULL
:B8                  NULL
:B7                  NULL
:B7                  NULL
:B6                  NULL
:B6                  NULL
:B5                  0
:B5                  0
:B4                  281474976710656
:B4                  281474976710656
:B3                  NULL
:B3                  NULL
:B2                  NULL
:B2                  NULL
:B1                  NULL
:B1                  NULL

其中有意义的绑定值为 :B13 05/10/12 07:21:00=> ‘SYSDATE-7′

SQL中的相关条件:B13 IS NULL OR COMPLETION_TIME <= :B13 即 COMPLETION_TIME <=’SYSDATE=7′;

COMPLETED BEFORE指的是ARCHIVELOG的COMPLETION_TIME，即实际归档操作完成的时间；其意思为找出所有归档完成时间小于指定的时间变量的归档日志。

当DELETE ARCHIVELOG ALL COMPLETED AFTER ‘SYSDATE-7′;执行时：

SQL> select name,value_string from v$sql_bind_capture where hash_value='3114867949';

:B20
:B19
:B18                 NULL
:B18                 NULL
:B17                 NULL
:B17                 NULL
:B16                 NULL
:B16                 NULL
:B15                 NULL
:B15                 NULL
:B14                 05/10/12 07:23:03
:B14                 05/10/12 07:23:03
:B13                 NULL
:B13                 NULL
:B10                 27
:B12                 1
:B9                  1
:B11                 0
:B10                 27
:B9                  1
:B8                  NULL
:B8                  NULL
:B7                  NULL
:B7                  NULL
:B6                  NULL
:B6                  NULL
:B5                  0
:B5                  0
:B4                  281474976710656
:B4                  281474976710656
:B3                  NULL
:B3                  NULL
:B2                  NULL
:B2                  NULL
:B1                  NULL
:B1                  NULL

:B14 IS NULL OR COMPLETION_TIME >= :B14，类似的AFTER操作仅仅是从小于等于变成了大于等于。

COMPLETED AFTER指的是ARCHIVELOG的COMPLETION_TIME，即实际归档操作完成的时间；其意思为找出所有归档完成时间大于等于指定的时间变量的归档日志。

Summary :

UNTIL TIME的TIME 指的是 ARCHIVELOG的FIRST_TIME ，即归档日志中LOW SCN对应的时间戳；其意思为找出所有LOW SCN TIMESTAMP小于等于指定的时间变量的归档日志。

COMPLETED BEFORE 指的是ARCHIVELOG的COMPLETION_TIME，即实际归档操作完成的时间；其意思为找出所有归档完成时间小于指定的时间变量的归档日志。

COMPLETED AFTER 指的是ARCHIVELOG的COMPLETION_TIME，即实际归档操作完成的时间；其意思为找出所有归档完成时间大于等于指定的时间变量的归档日志。

Question:

搞清楚这些细节对实际的工作由什么意义？

Answer:

ARCHIVELOG相关过滤条件 UNTIL TIME 和 COMPLETED BEFORE是存在区别的，在平时备份BACKUP时可能感受不到这种区别。

试想这样一个场景，
SEQUENCE A 的ARCHIVELOG 的First TIME为 07:45 、 NEXT TIME为08:10、归档操作耗费了1分钟即COMPLETION_TIME为08:11
SEQUENCE A+1即后续的一个ARCHIVELOG的 FIRST TIME为08:10，NEXT TIME为08:30……..

我们以08:00为时间变量，

若使用DELETE ARCHIVELOG UNTIL TIME 08:00 ，因为SENQUENCE A的FIRST_TIME <08:00，所以SEQUENCE A将被删除，若没有相应的归档备份或COPY，则意味着08:00~08:10 这段时间将变成unrecoverable；

若使用DELETE ARCHIVELOG ALL COMPLETED BEFORE 08:00，因为SENQUENCE A的COMPLETION_TIME>08:00，所以SEQUENCE A将不被删除。

来实际体验一下这个结论，SEQUENCE 232的
FIRST_TIME=2012-05-17 07:32:50,
NEXT TIME=2012-05-17 07:41:32,
COMPLETION_TIME=2012-05-17 07:43:40

RMAN> DELETE ARCHIVELOG  ALL COMPLETED BEFORE "to_timestamp('2012-05-17 07:40:00','YYYY-MM-DD hh24:mi:ss')";

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=140 devtype=DISK

RMAN> DELETE ARCHIVELOG  UNTIL TIME "to_timestamp('2012-05-17 07:40:00','YYYY-MM-DD hh24:mi:ss')";

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=140 devtype=DISK

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
39      1    232     A 17-MAY-12 /s01/flash_recovery_area/G10R25/archivelog/2012_05_17/o1_mf_1_232_7v9s3dcf_.arc

Do you really want to delete the above objects (enter YES or NO)? y
deleted archive log
archive log filename=/s01/flash_recovery_area/G10R25/archivelog/2012_05_17/o1_mf_1_232_7v9s3dcf_.arc recid=39 stamp=783503020
Deleted 1 objects

[视频教学]Maclean教你用Vbox在Enterprise Linux 5上安装Oracle 10gR2 RAC

Maclean Liu — Wed, 16 May 2012 16:16:36 +0000

【视频教学】Maclean手把手教你用Vbox在Enterprise Linux 5上安装Oracle 10gR2 RAC数据库

WebEx视频播放软件，以下wrf格式文件需要使用webex播放，

下载WebEX：　

WebEx.zip (2.55 MB)

Agenda:

相关脚本和命令附件： 脚本命令.txt (1.71 KB)

第一讲视频-在Windows上安装Vbox

第一讲视频-在Windows上安装Vbox.zip (4.41 MB)

第二讲视频-在Vbox上安装Oracle Enterprise Linux 5.7虚拟主机

第二讲视频-在Vbox上安装Oracle Enterprise Linux 5.7虚拟主机.zip (12.05 MB)

第三讲视频-配置并克隆Oracle Enterprise 5.7虚拟主机

第三讲视频-配置并克隆Oracle Enterprise 5.7虚拟主机.zip (14.82 MB)

第四讲视频-配置Vbox共享存储和UDEV存储设备绑定

第四讲视频-配置Vbox共享存储和UDEV存储设备绑定.zip (13.16 MB)

第五讲视频-安装10.2.0.1 x64 Linux Oracle Clusterware CRS

第五讲视频-安装10.2.0.1 x64 Linux Oracle Clusterware CRS.zip (10.48 MB)

第六讲视频-升级Clusterware CRS 10.2.0.1 到 Patchset 10.2.0.5

第六讲视频-升级Clusterware CRS 10.2.0.1 到 Patchset 10.2.0.5 .zip (3.2 MB)

第七讲视频-安装10.2.0.1 DB数据库并升级到10.2.0.5 Patchset 并DBCA创建数据库

第七讲视频-安装10.2.0.1DB数据库升级到10.2.0.5创建数据库.zip (10.37 MB)

Know More About Oracle Row Lock

Maclean Liu — Wed, 16 May 2012 06:13:27 +0000

我们都知道在Oracle中实现了细粒度的行锁row lock，且在ORACLE的内部实现中没有使用基于内存的行锁管理器，row lock是依赖于数据块本身实现的。换句话说判定一行数据究竟有没有没锁住，要求Server Process去pin住相应的block buffer并检查才能够发现。

但是试想一个场景，若process A 通过update语句锁定了数据表 Z数据块上的一行数据，并长时间既没有rollback亦没有commit；此时Process B也运行了一条DML语句，它通过索引找到rowid并找到了 Z数据块，它发现这一行数据已经被process A发起的一个事务的ITL锁住了，它可能试图做一些cleanout操作，但是发现被锁住的row在相关的事务表中仍未被commit，那么很抱歉的是Process B需要进入”enq: TX – row lock contention”的等待事件了。问题在于Process B的无尽等待的终结在哪里呢？

有同学肯定会说只要Process A释放了其锁定的row，那么Process B就会立即结束其”enq: TX – row lock contention”等待了。

事实是这样的吗？我们来看一个演示:

SESSION A:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.oracledatabase12g.com

SQL> create table maclean_lock(t1 int);
Table created.

SQL> insert into maclean_lock values (1);
1 row created.

SQL> commit;

Commit complete.

SQL> select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid) from maclean_lock;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID)
------------------------------------ ------------------------------------
                               67642                                    1

SQL>  select distinct sid from v$mystat;

       SID
----------
       142

SQL> select pid,spid from v$process where addr = ( select paddr from v$session where sid=(select distinct sid from v$mystat));

       PID SPID
---------- ------------
        17 15636

使用SESSION A 创建一个savepoint ，并update 表上的唯一一行数据        

SQL>  savepoint NONLOCK;

Savepoint created.

SQL> select * From v$Lock where sid=142;

no rows selected

SQL> set linesize 140 pagesize 1400

SQL>  update maclean_lock set t1=t1+2;

1 row updated.

SQL> select * From v$Lock where sid=142;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
0000000091FC69F0 0000000091FC6A18        142 TM      55829          0          3          0          6          0
00000000914B4008 00000000914B4040        142 TX     393232        609          6          0          6          0        

SQL> select dump(3,16) from dual;

DUMP(3,16)
--------------------------------------------------------------------------------
Typ=2 Len=2: c1,4

ALTER SYSTEM DUMP DATAFILE 1 BLOCK 67642;

 Object id on Block? Y
 seg/obj: 0xda16  csc: 0x00.234718  itc: 2  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.00f.000001e0  0x00800075.02a6.29  C---    0  scn 0x0000.00234711
0x02   0x0007.018.000001fe  0x0080065c.017a.02  ----    1  fsc 0x0000.00000000

data_block_dump,data header at 0x81d185c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x081d185c
bdba: 0x0041083a
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f9a
avsp=0x1f83
tosp=0x1f83
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0x1f9a
block_row_dump:
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x2  cc: 1
col  0: [ 2]  c1 04
end_of_block_dump

观察 BLOCK DUMP 可以发现 唯一的一行被XID=0x0007.018.000001fe 的transaction锁定 lb:0x1

启动SESSION B ，执行同样的UPDATE语句 会引发enq: TX - row lock contention 等待

SQL> select distinct sid from v$mystat;

       SID
----------
       140

SQL> select pid,spid from v$process where addr = ( select paddr from v$session where sid=(select distinct sid from v$mystat));

       PID SPID
---------- ------------
        24 15652

SQL> alter system set "_trace_events"='10000-10999:255:24';

System altered.        

SQL> update maclean_lock set t1=t1+2;

select * From v$Lock where sid=142 or sid=140 order by sid;

SESSION C:

SQL> select * From v$Lock where sid=142 or sid=140 order by sid;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
0000000091FC6B10 0000000091FC6B38        140 TM      55829          0          3          0         84          0
00000000924F4A58 00000000924F4A78        140 TX     458776        510          0          6         84          0
00000000914B51E8 00000000914B5220        142 TX     458776        510          6          0        312          1
0000000091FC69F0 0000000091FC6A18        142 TM      55829          0          3          0        312          0

可以看到 SESSION B SID=140 对SESSION A 的TX ENQUEUE 有X mode的REQUEST

SQL> oradebug dump systemstate 266;
Statement processed.

SESSION B waiter's enqueue lock

      SO: 0x924f4a58, type: 5, owner: 0x92bb8dc8, flag: INIT/-/-/0x00
      (enqueue) TX-00070018-000001FE    DID: 0001-0018-00000022
      lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
      req: X, lock_flag: 0x0, lock: 0x924f4a78, res: 0x925617c0
      own: 0x92b76be0, sess: 0x92b76be0, proc: 0x92a737a0, prv: 0x925617e0

TX-00070018-000001FE=> TX 458776 510

SESSION A owner's enqueue lock 

      SO: 0x914b51e8, type: 40, owner: 0x92b796d0, flag: INIT/-/-/0x00
      (trans) flg = 0x1e03, flg2 = 0xc0000, prx = 0x0, ros = 2147483647 bsn = 0xed5 bndsn = 0xee7 spn = 0xef7
      efd = 3
      file:xct.c lineno:1179
      DID: 0001-0011-000000C2
      parent xid: 0x0000.000.00000000
      env: (scn: 0x0000.00234718  xid: 0x0007.018.000001fe  uba: 0x0080065c.017a.02  statement num=0  parent xid: xid: 0x0000.000.00000000  scn: 0x00
00.00234718 0sch: scn: 0x0000.00000000)
      cev: (spc = 7818  arsp = 914e8310  ubk tsn: 1 rdba: 0x0080065c  useg tsn: 1 rdba: 0x00800069
            hwm uba: 0x0080065c.017a.02  col uba: 0x00000000.0000.00
            num bl: 1 bk list: 0x91435070)
            cr opc: 0x0 spc: 7818 uba: 0x0080065c.017a.02
      (enqueue) TX-00070018-000001FE    DID: 0001-0011-000000C2
      lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
      mode: X, lock_flag: 0x0, lock: 0x914b5220, res: 0x925617c0
      own: 0x92b796d0, sess: 0x92b796d0, proc: 0x92a6ffd8, prv: 0x925617d0
       xga: 0x8b7c6d40, heap: UGA
      Trans IMU st: 2 Pool index 65535, Redo pool 0x914b58d0, Undo pool 0x914b59b8
      Redo pool range [0x86de640 0x86de640 0x86e0e40]
      Undo pool range [0x86dbe40 0x86dbe40 0x86de640]
        ----------------------------------------
        SO: 0x91435070, type: 39, owner: 0x914b51e8, flag: -/-/-/0x00
        (List of Blocks) next index = 1
        index   itli   buffer hint   rdba       savepoint
        -----------------------------------------------------------
            0      2   0x647f1fc8    0x41083a     0xee7

在SESSION A中 ROLLBACK 到savepoint:

SQL> rollback to NONLOCK;

Rollback complete.

因为这个savepoint 是在update语句之前创建的 所以UPDATE相关的操作应当被 ROLLBACK:

SQL> select * From v$Lock where sid=142 or sid=140;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
00000000924F4A58 00000000924F4A78        140 TX     458776        510          0          6        822          0
0000000091FC6B10 0000000091FC6B38        140 TM      55829          0          3          0        822          0
00000000914B51E8 00000000914B5220        142 TX     458776        510          6          0       1050          1

可以看到 SESSION A 142 回滚到SAVEPOINT 也释放了表上的TM LOCK 

但是请注意 ROLLBACK TO SAVEPOINT并不会释放SESSION已获得TX LOCK！！！！
如上面的输出SESSION 142仍持有TX ID1=458776 ID2=510， 这是因为ROLLBACK TO SAVEPOINT并不会放弃整个事务ABORT TRANSACTION

但是 SESSION B  SID=140仍被  SESSION A 阻塞 , 实际观察也可以发现SESSION B的 update语句仍HANG着。

我们来看一下此时的CACHE中的数据块：

 Object id on Block? Y
 seg/obj: 0xda16  csc: 0x00.2347b7  itc: 2  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.00f.000001e0  0x00800075.02a6.29  C---    0  scn 0x0000.00234711
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

data_block_dump,data header at 0x745d85c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x0745d85c
bdba: 0x0041083a
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f9a
avsp=0x1f83
tosp=0x1f83
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0x1f9a
block_row_dump:
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 2]  c1 02
end_of_block_dump

可以看到 ITL=0x02的 事务已经被回滚清理，col  0: [ 2]  c1 02 的数据已经不被锁定

此时若我们另开一个SESSION D ，那么因为没有row lock所以 其UPDATE是可以顺利完成的

SESSION D:

SQL> update maclean_lock set t1=t1+2;

1 row updated.

SQL> rollback;

Rollback complete.

那么SESSION B 为什么无谓地等待着呢？

这就涉及到ORACLE的内部实现机制了， 注意虽然很多时候我们把 TX lock叫做 row lock ， 但是实际上它们是2回事。
row lock是基于数据块实现的， 而TX lock则是通过内存中的ENQUEUE LOCK实现的。

问题在于若一个进程PROCESS K在DML过程中发现其所需要的数据行已经被其他进程锁定了，如果不依赖于内存中的TX LOCK， 
这意味着PROCESS Z需要定期去读取检查该数据行锁在的数据块以发现相应的ROW LOCK是否已经被释放了， 
可以想象如果在OLTP环境中这样去设计所造成的性能损失将是巨大的。 

所以ROW LOCK的Release 就需要依赖于TX的ENQUEUE LOCK，大致的过程是这样的Process J 首先锁定了数据块中的一行，
Process K需要更新同样的一行数据 ，Process K读取该行锁在数据块，发现该row piece的lb不是0x0 ，而指向一个ITL，
Process Z分析该ITL就可以得到之前Process J的事务的XID，就可以找到Process J这个事务的TX lock,
PROCESS K 就会在TX resource的Enqueue Waiter Linked List上创建一个X mode(exclusive)的enqueue lock。
这样当Process J释放TX lock时，Process J就会查看该TX resource的Enqueue Waiter Linked List
并发现Process K还在那里等待，并会POST一个信息给Process K说 TX lock已经被我释放，
隐含的意思就是row lock也已经被我释放，你可以继续工作了。

我们来细致入微地观察 这整个过程：

SESSION A 对应的PID =17 我们在之前的演示中已经自解释了这一点
SESSION B 对应的PID =24 

通过之前所做的 "_trace_events"='10000-10999:255:24';  KST trace 可以详细地观察 Server Process的行为

SESSION A PID=17  首先 acqure了SX mode表上的TM Lock ，之后 启动事务Transaction绑定了一个UNDO SEGMENT 7，获取了XID 7.24.510，
并acquire 了X mode的 TX-00070018-000001fe 。

这里可以看到 00070018-000001fe 其实就是 7- 24 - 510即 XID 。

781F4B8A:007A569C    17   142 10704  83 ksqgtl: acquire TM-0000da15-00000000 mode=SX flags=GLOBAL|XACT why="contention"
781F4B92:007A569D    17   142 10704  19 ksqgtl: SUCCESS
781F4BB3:007A569E    17   142 10812   2 0x000000000041083A 0x0000000000000000 0x0000000000234717
781F4BBA:007A569F    17   142 10812   3 0x0000000000000000 0x0000000000000000 0x0000000000000000
781F4BC0:007A56A0    17   142 10812   4 0x0000000000000000 0x0000000000000000 0x0000000000000000
781F4BD3:007A56A1    17   142 10812   5 0x000000000041083A 0x0000000000000000 0x0000000000000000
781F4BFE:007A56A2    17   142 10811   1 0x000000000041083A 0x0000000000000000 0x0000000000234711 0x0000000000000002
781F4C06:007A56A3    17   142 10811   2 0x000000000041083A 0x0000000000000000 0x0000000000234718 0x00007FA074EDA560
781F4C26:007A56A4    17   142 10813   1 ktubnd: Bind usn 7 nax 1 nbx 0 lng 0 par 0
781F4C43:007A56A5    17   142 10813   2 ktubnd: Txn Bound xid: 7.24.510
781F4C4A:007A56A6    17   142 10704  83 ksqgtl: acquire TX-00070018-000001fe mode=X flags=GLOBAL|XACT why="contention"
781F4C51:007A56A7    17   142 10704  19 ksqgtl: SUCCESS

之后因为前台没有操作 所以进入空闲等待

781F4CBF:007A56A8    17   142 10005   1 KSL WAIT BEG [SQL*Net message to client] 1650815232/0x62657100 1/0x1 0/0x0
781F4CCC:007A56A9    17   142 10005   2 KSL WAIT END [SQL*Net message to client] 1650815232/0x62657100 1/0x1 0/0x0 time=13
781F4CDE:007A56AA    17   142 10005   1 KSL WAIT BEG [SQL*Net message from client] 1650815232/0x62657100 1/0x1 0/0x0
786BD85D:007A57E0    17   142 10005   2 KSL WAIT END [SQL*Net message from client] 1650815232/0x62657100 1/0x1 0/0x0 time=5016447
786BD966:007A57E1    17   142 10005   1 KSL WAIT BEG [SQL*Net message to client] 1650815232/0x62657100 1/0x1 0/0x0
786BD96E:007A57E2    17   142 10005   2 KSL WAIT END [SQL*Net message to client] 1650815232/0x62657100 1/0x1 0/0x0 time=8

SESSION B 对应的PID =24  ，它也首先获得了 SX mode的 TM lock，发现row lock后 acquire X mode的TX-00070018-000001fe

ksqgtl: acquire TM-0000da15-00000000 mode=SX flags=GLOBAL|XACT why="contention"
ksqgtl: SUCCESS
0x000000000041083A 0x0000000000000000 0x00000000002354F8
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000041083A 0x0000000000000000 0x00000000002354F8 0x0000000000000001
0x000000000041083A 0x0000000000000000 0x00000000002354F8 0x0000000008A63780
0x0000000000000001 0x0000000000800861 0x0000000000000241 0x0000000000000001
0x000000000041083A 0x0000000000000001 0x0000000000000001
0x000000000041083A 0x0000000000000000 0x00000000002354F9 0x0000000000000002
ksqgtl: acquire TX-00070018-000001fe mode=X flags=GLOBAL|LONG why="row lock contention"
C4048EBD:007F52B6    24   140 10005   2 KSL WAIT END [enq: TX - row lock contention] 1415053318/0x54580006 458776/0x70018 510/0x1fe time=2929879
C4048ED4:007F52B7    24   140 10005   1 KSL WAIT BEG [enq: TX - row lock contention] 1415053318/0x54580006 458776/0x70018 510/0x1fe
C43146CA:007F535E    24   140 10005   2 KSL WAIT END [enq: TX - row lock contention] 1415053318/0x54580006 458776/0x70018 510/0x1fe time=2930676

因为等待的时间过久 ,PID=24 还会定期调用ksqcmi检查是否存在死锁 deadlock

C43146D9:007F535F    24   140 10704 134 ksqcmi: performing local deadlock detection on TX-00070018-000001fe
C43146F8:007F5360    24   140 10704 150 ksqcmi: deadlock not detected on TX-00070018-000001fe

接着 我们对 PID 17 执行ROLLBACK 彻底回滚 ，真正放弃这个事务：

PID 17 

ROLLBACK;

D7A495BB:007F9D3E    17   142 10005   4 KSL POST SENT postee=24 loc='ksqrcl' id1=0 id2=0 name=   type=0
D7A495D8:007F9D3F    17   142 10444  12 ABORT TRANSACTION - xid: 0x0007.018.000001fe

注意  PID 17 查看了 TX resource的Enqueue Waiter linked List 发现了PID 24在等待，于是使用KSL POST SENT 告知 PID 24，
我已经ksqrcl释放了ENQUEUE LOCK

而PID 24也立即收到了KSL POST (KSL POST RCVD poster=17)， 并ksqgtl成功获得 TX-00070018-000001fe 随后 ksqrcl释放，
注意PID 24实际不会沿用这个 TX lock和USN ，而是自行绑定了 USN 3 XID 3.11.582 ，并成功acquire TX-0003000b-00000246

D7A49616:007F9D41    24   140 10005   3 KSL POST RCVD poster=17 loc='ksqrcl' id1=0 id2=0 name=   type=0 fac#=0 facpost=1
D7A4961C:007F9D42    24   140 10704  19 ksqgtl: SUCCESS
D7A4967D:007F9D43    24   140 10704 117 ksqrcl: release TX-00070018-000001fe mode=X
D7A496A5:007F9D44    24   140 10813   1 ktubnd: Bind usn 3 nax 1 nbx 0 lng 0 par 0
D7A496C2:007F9D45    24   140 10813   2 ktubnd: Txn Bound xid: 3.11.582
D7A496C7:007F9D46    24   140 10704  83 ksqgtl: acquire TX-0003000b-00000246 mode=X flags=GLOBAL|XACT why="contention"
D7A496E4:007F9D47    24   140 10704  19 ksqgtl: SUCCESS

ROW LOCK的Release 就需要依赖于TX的ENQUEUE LOCK，大致的过程是这样的Process J 首先锁定了数据块中的一行， Process K需要更新同样的一行数据，Process K读取该行锁在数据块，发现该row piece的lb不是0×0 ，而指向一个ITL，Process Z分析该ITL就可以得到之前Process J的事务的XID，就可以找到Process J这个事务的TX lock,PROCESS K 就会在TX resource的Enqueue Waiter Linked List上创建一个X mode(exclusive)的enqueue lock。这样当Process J释放TX lock时，Process J就会查看该TX resource的Enqueue Waiter Linked List 并发现Process K还在那里等待，并会POST一个信息给Process K说 TX lock已经被我释放，隐含的意思就是row lock也已经被我释放，你可以继续工作了。

10%的IOS设备已经更新到版本5.1.1

Maclean Liu — Thu, 10 May 2012 12:04:34 +0000

APPLE iOS系统的更新率令Android望尘莫及。住在佛吉尼亚州的David Smith是一位独立的iOS应用开发者，他提供了数据以支持这种说法。

David Smith开发了多个iOS APP，包括 Audiobooks 和 InstaBackup ；并且他对iOS 5.1.1 版本的更新下载做了追踪。他指出10%的iOS用户已经升级到最新版本的APPLE移动操作系统。

Apple iOS 5.1.1 在官方发布的24小时就获得了极高的采用率。开发者们指出80%的iOS用户已经更新到了去年十一月发布的iOS 5.0.1版本上。

极具对比性的是， Android系统最新版本的采用率仍保持在一个极低的水平。从Google 开发者那里获得的数据显示 Android Ice Cream sandwich的采样率仅占所有Android设备的5%。

在所有的安卓智能手机和平板设备中，版本4.0 和 4.0.2仅拥有0.5%的装机率。 Google 最新版本的移动操作系统，版本4.0.3 、4.0.4 、4.4占4.4%装机率。

From http://t.cn/zORzTfe

Welcome to Nexus S?

Know more about Cache Buffer Handle

Maclean Liu — Thu, 10 May 2012 08:57:11 +0000

在之前的文章《latch free:cache buffer handles造成的SQL性能问题》中我介绍了cache buffer handle latch的一些知识，在这里我们复习一下：

“当会话需要pin住buffer header时它首先要获去buffer handle，得到buffer handle的过程中首先要抢占cache buffer handles栓，为了避免对于cache buffer handles栓的过度争用，每个会话被允许cache一小撮buffer handles,也叫保留集(reserved set)。该保留集的上限由隐式参数_db_handles_cached(默认为5)所控制，在此基础上会话在执行不是十分复杂的SQL时不必反复申请栓。
同时存在一些十分复杂的语句，需要同时pin住大量的缓存，此时若存在空闲的handle，会话被允许索要手头5个cached buffer handles以外的handle。也为了限制单个会话的资源占用量，Oracle通过内部算法总是尽量让每个进程能够pin住”合理份额“的buffer，由此单个会话同一时间所能持有的总handle数等于db_block_buffers/processes，隐式参数_cursor_db_buffers_pinned指出了该值。另cache buffer handles并没有子栓，仅有父栓本身，所以如果系统中有大量复杂SQL，会话所能cache的buffer handles远不足以满足需求时，该栓就成为整个系统性能的瓶颈，甚至可能出现潜在的死锁/饿死问题。”

应网友在T.ASKMACLEAN.COM上的提问，我们介绍更多cache Buffer handle相关的知识：

cache buffer handle 结构:

------------------------------
|  Buffer state object       |
------------------------------
|  Place to hang the buffer  |
------------------------------
|  Consistent Get?           |
------------------------------
|  Proc Owning SO            |
------------------------------
|  Flags(RIR)                |
------------------------------

来看一个 cache buffer handle

SO: 70000046fdfe530, type: 24, owner: 70000041b018630, flag: INIT/-/-/0×00
(buffer) (CR) PR: 70000048e92d148 FLG: 0×500000
lock rls: 0, class bit: 0
kcbbfbp: [BH: 7000001c7f069b0, LINK: 70000046fdfe570]
where: kdswh02: kdsgrp, why: 0
BH (7000001c7f069b0) file#: 12 rdba: 0×03061612 (12/398866) class: 1 ba: 7000001c70ee000
set: 75 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 2 obj: 66209 objn: 48710 tsn: 6 afn: 12
hash: [700000485f12138,700000485f12138] lru: [70000025af67790,700000132f69ee0]
lru-flags: hot_buffer
ckptq: [NULL] fileq: [NULL] objq: [700000114f5dd10,70000028bf5d620]
use: [70000046fdfe570,70000046fdfe570] wait: [NULL]
st: SCURRENT md: SHR tch: 0
flags: affinity_lock
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
where: kdswh02: kdsgrp, why: 0

# Example:
# (buffer) (CR) PR: 37290 FLG: 0
# kcbbfbp : [BH: befd8, LINK: 7836c] (WAITING)

Buffer handle (X$KCBBF) kernel cache, buffer buffer_handles

Query x$kcbbf – lists all the buffer handles

相关参数

_db_handles             System-wide simultaneous buffer operations ,no of buffer handles
_db_handles_cached     Buffer handles cached each process , no of processes default 5
_cursor_db_buffers_pinned additional number of buffers a cursor can pin at once
_session_kept_cursor_pins     Number of cursors pins to keep in a session

When a buffer is pinned it is attached to buffer state object.

接下来我们实际体验一下 cache buffer handles latch 和 buffer pin的影响：

SESSION A :

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> create table test_cbc_handle(t1 int);

Table created.

SQL> insert into test_cbc_handle values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> select rowid from test_cbc_handle; 

ROWID
------------------
AAANO6AABAAAQZSAAA

SQL> select * from test_cbc_handle where rowid='AAANO6AABAAAQZSAAA';

        T1
----------
         1 

SQL> select addr,name from v$latch_parent where name='cache buffer handles';

ADDR             NAME
---------------- --------------------------------------------------
00000000600140A8 cache buffer handles

SQL> select to_number('00000000600140A8','xxxxxxxxxxxxxxxxxxxx') from dual;

TO_NUMBER('00000000600140A8','XXXXXXXXXXXXXXXXXXXX')
----------------------------------------------------
                                          1610694824

注意cache buffer handles只有一个parent latch 而没有 child latch

我们让SESSION A hold 住唯一的一个cache buffer handles parent latch
这会用到 oradebug call kslgetl 命令， kslgetl是oracle内部get latch的函数

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug call kslgetl 1610694824 1;
Function returned 1

另外开一个SESSION B 来观察：

SQL> select * from v$latchholder;

       PID        SID LADDR            NAME                                                                   GETS
---------- ---------- ---------------- ---------------------------------------------------------------- ----------
        15        141 00000000600140A8 cache buffer handles                                                    119

cache buffer handles latch 确实被session A hold住了,这将阻塞其他进程acquire cache buffer handle latch

SQL> select * from test_cbc_handle where rowid='AAANO6AABAAAQZSAAA';

        T1
----------
         1

但此时其他Server Process还是可以正常 read buffer， 这是因为隐藏参数"_db_handles_cached",
默认process会cache 5个 cache buffer handle 

修改"_db_handles_cached"=0，让process不再拥有5个缓存的cache buffer handle ，
这将导致 process 若需要pin buffer，则必须hold cache buffer handle latch以便分配一个cache buffer handle

SQL> alter system set "_db_handles_cached"=0 scope=spfile;

System altered.

并重启实例 

shutdown immediate;
startup;

session A:

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug call kslgetl 1610694824 1;
Function returned 1

session B:

select * from test_cbc_handle where rowid='AAANO6AABAAAQZSAAA';

session B hang!!

WHY?

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug dump systemstate 266;
Statement processed.

  SO: 0x11b30b7b0, type: 2, owner: (nil), flag: INIT/-/-/0x00
  (process) Oracle pid=22, calls cur/top: (nil)/0x11b453c38, flag: (0) -
            int error: 0, call error: 0, sess error: 0, txn error 0
  (post info) last post received: 0 0 0
              last post received-location: No post
              last process to post me: none
              last post sent: 0 0 0
              last post sent-location: No post
              last process posted by me: none
    (latch info) wait_event=0 bits=8
      holding    (efd=4) 600140a8 cache buffer handles level=3

  SO: 0x11b305810, type: 2, owner: (nil), flag: INIT/-/-/0x00
  (process) Oracle pid=10, calls cur/top: 0x11b455ac0/0x11b450a58, flag: (0) -
            int error: 0, call error: 0, sess error: 0, txn error 0
  (post info) last post received: 0 0 0
              last post received-location: No post
              last process to post me: none
              last post sent: 0 0 0
              last post sent-location: No post
              last process posted by me: none
    (latch info) wait_event=0 bits=2
        Location from where call was made: kcbzgs:
      waiting for 600140a8 cache buffer handles level=3

FBD93353:000019F0    10   162 10005   1 KSL WAIT BEG [latch: cache buffer handles] 1610694824/0x600140a8 125/0x7d 0/0x0
FF936584:00002761    10   144 10005   1 KSL WAIT BEG [latch: cache buffer handles] 1610694824/0x600140a8 125/0x7d 0/0x0

PID=22 holding 持有cache buffer handles latch

PID=10 等待 cache buffer handles latch， 这是因为"_db_handles_cached"=0 导致 process自身没有缓存cache buffer handles

这个systemstate中找不到 kcbbfbp cache buffer handle对象，
因为 "_db_handles_cached"=0 且 cache buffer handles latch被hold 住了

我们释放cache buffer handles latch ， 来观察 buffer被pin住而不是释放时的情境

session A exit 

session B:

SQL> select * from v$latchholder;

no rows selected

SQL> insert into test_cbc_handle values(2);

1 row created.

SQL> commit;

Commit complete.

SQL>
SQL> select t1,rowid from test_cbc_handle;

        T1 ROWID
---------- ------------------
         1 AAANPAAABAAAQZSAAA
         2 AAANPAAABAAAQZSAAB

SQL> select spid,pid from v$process where addr = ( select paddr from v$session where sid=(select distinct sid from v$mystat));

SPID                PID
------------ ----------
19251                10

用 GDB 对 SPID=19215 做debug ， 使用 kcbrls 函数作为breakpoint 这会让 进程无法release buffer

[oracle@vrh8 ~]$ gdb $ORACLE_HOME/bin/oracle 19251
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/bin/oracle...(no debugging symbols found)...done.
Attaching to program: /s01/oracle/product/10.2.0.5/db_1/bin/oracle, process 19251
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libskgxp10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libskgxp10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libhasgen10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libhasgen10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libskgxn2.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libskgxn2.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libocr10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libocr10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libocrb10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libocrb10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libocrutl10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libocrutl10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libjox10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libjox10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libclsra10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libclsra10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libdbcfg10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libdbcfg10.so
Reading symbols from /s01/oracle/product/10.2.0.5/db_1/lib/libnnz10.so...(no debugging symbols found)...done.
Loaded symbols for /s01/oracle/product/10.2.0.5/db_1/lib/libnnz10.so
Reading symbols from /usr/lib64/libaio.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libaio.so.1
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
0x00000035c000d940 in __read_nocancel () from /lib64/libpthread.so.0

 (gdb) break kcbrls

Breakpoint 1 at 0x10e5d24

session B:

select * from test_cbc_handle where rowid='AAANPAAABAAAQZSAAA'; select hang !!

GDB

(gdb) c
Continuing.

Breakpoint 1, 0x00000000010e5d24 in kcbrls ()
(gdb) bt
#0  0x00000000010e5d24 in kcbrls ()
#1  0x0000000002e87d25 in qertbFetchByUserRowID ()
#2  0x00000000030c62b8 in opifch2 ()
#3  0x00000000032327f0 in kpoal8 ()
#4  0x00000000013b7c10 in opiodr ()
#5  0x0000000003c3c9da in ttcpip ()
#6  0x00000000013b3144 in opitsk ()
#7  0x00000000013b60ec in opiino ()
#8  0x00000000013b7c10 in opiodr ()
#9  0x00000000013a92f8 in opidrv ()
#10 0x0000000001fa3936 in sou2o ()
#11 0x000000000072d40b in opimai_real ()
#12 0x000000000072d35c in main ()

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug dump systemstate 266;
Statement processed.

此时可以看到 kcbbfbp buffer cache handle 将  SO state object 和 BH BUFFER HEADER  link在一起

    ----------------------------------------
    SO: 0x11b452348, type: 3, owner: 0x11b305810, flag: INIT/-/-/0x00
    (call) sess: cur 11b41bd18, rec 0, usr 11b41bd18; depth: 0
      ----------------------------------------
      SO: 0x1182dc750, type: 24, owner: 0x11b452348, flag: INIT/-/-/0x00
      (buffer) (CR) PR: 0x11b305810 FLG: 0x108000
      class bit: (nil)
      kcbbfbp: [BH: 0xf2fc69f8, LINK: 0x1182dc790]
      where: kdswh05: kdsgrp, why: 0
      BH (0xf2fc69f8) file#: 1 rdba: 0x00410652 (1/67154) class: 1 ba: 0xf297c000
        set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 272
        dbwrid: 0 obj: 54208 objn: 54202 tsn: 0 afn: 1
        hash: [f2fc47f8,1181f3038] lru: [f2fc6b88,f2fc6968]
        obj-flags: object_ckpt_list
        ckptq: [1182ecf38,1182ecf38] fileq: [1182ecf58,1182ecf58] objq: [108712a28,108712a28]
        use: [1182dc790,1182dc790] wait: [NULL]
        st: XCURRENT md: SHR tch: 12
        flags: buffer_dirty gotten_in_current_mode block_written_once
                redo_since_read
        LRBA: [0xc7.73b.0] HSCN: [0x0.1cbe52] HSUB: [1]
        Using State Objects
          ----------------------------------------
          SO: 0x1182dc750, type: 24, owner: 0x11b452348, flag: INIT/-/-/0x00
          (buffer) (CR) PR: 0x11b305810 FLG: 0x108000
          class bit: (nil)
          kcbbfbp: [BH: 0xf2fc69f8, LINK: 0x1182dc790]
          where: kdswh05: kdsgrp, why: 0
        buffer tsn: 0 rdba: 0x00410652 (1/67154)
        scn: 0x0000.001cbe52 seq: 0x01 flg: 0x02 tail: 0xbe520601
        frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 2]  c1 02
tab 0, row 1, @0x1f94
tl: 6 fb: --H-FL-- lb: 0x2  cc: 1
col  0: [ 2]  c1 15
end_of_block_dump        

(buffer) (CR) PR: 0x11b305810 FLG: 0x108000

st: XCURRENT md: SHR tch: 12
该 buffer header的status= XCURRENT mode=KCBMSHARE KCBMSHR     current share

也可以通过  x$kcbbf 找到相关的 cache buffer handle

SQL> select distinct KCBBPBH from  x$kcbbf ;

KCBBPBH
----------------
00
00000000F2FC69F8            ==>0xf2fc69f8

SQL> select * from x$kcbbf where kcbbpbh='00000000F2FC69F8';

ADDR                   INDX    INST_ID KCBBFSO_TYP KCBBFSO_FLG KCBBFSO_OWN
---------------- ---------- ---------- ----------- ----------- ----------------
  KCBBFFLG    KCBBFCR    KCBBFCM KCBBFMBR         KCBBPBH
---------- ---------- ---------- ---------------- ----------------
KCBBPBF          X0KCBBPBH        X0KCBBPBF        X1KCBBPBH
---------------- ---------------- ---------------- ----------------
X1KCBBPBF        KCBBFBH            KCBBFWHR   KCBBFWHY
---------------- ---------------- ---------- ----------
00000001182DC750        748          1          24           1 000000011B452348
   1081344          1          0 00               00000000F2FC69F8
00000001182DC750 00               00000001182DC750 00
00000001182DC7F8 00                      583          0

SQL> desc x$kcbbf;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ADDR                                               RAW(8)
 INDX                                               NUMBER
 INST_ID                                            NUMBER
 KCBBFSO_TYP                                        NUMBER
 KCBBFSO_FLG                                        NUMBER
 KCBBFSO_OWN                                        RAW(8)
 KCBBFFLG                                           NUMBER
 KCBBFCR                                            NUMBER
 KCBBFCM                                            NUMBER
 KCBBFMBR                                           RAW(8)
 KCBBPBH                                            RAW(8)
 KCBBPBF                                            RAW(8)
 X0KCBBPBH                                          RAW(8)
 X0KCBBPBF                                          RAW(8)
 X1KCBBPBH                                          RAW(8)
 X1KCBBPBF                                          RAW(8)
 KCBBFBH                                            RAW(8)
 KCBBFWHR                                           NUMBER
 KCBBFWHY                                           NUMBER

gdb 退出 让process能够顺利完成kcbrls release buffer后 相关的cache buffer handle被清理

SQL> select distinct KCBBPBH from  x$kcbbf ;

KCBBPBH
----------------
00

一些有用的Exadata诊断命令

Maclean Liu — Wed, 02 May 2012 13:15:05 +0000

检测check Exadata Image & OS versions , GI & DB patches

sundiag
exacheck
cellserv ==>  imageinfo
dbhost   ==>  /usr/local/bin/imagehistory 

Also check the version of the switch.

Login to Switch and execute the following command

[root@myswitch-1 sbin]# version

[root@dmorlsw-ib2 sbin]# cd /usr/local/bin
[root@dmorlsw-ib2 bin]# ls -lrt version
-rwxr-xr-x 1 root root 20356 Apr 4 2011 version

Output will look as below.

[root@dmorlsw-ib2 ~]# version
SUN DCS 36p version: 1.3.3-2
Build time: Apr 4 2011 11:15:19
SP board info:
Manufacturing Date: 2009.05.05
Serial Number: "NCD3X0178"
Hardware Revision: 0x0006
Firmware Revision: 0x0102
BIOS version: NOW1R112
BIOS date: 04/24/2009

ib8#  cat /sys/class/infiniband/is4_0/fw_ver
7.2.300

ib8 # cat /sys/class/dmi/id/bios_version
NOW1R112 

ib8 #  nm2version
NM2-36p version: 1.0.1-1
Build time: Sep 14 2009 12:52:51
ComExpress info:
Manufacturing Date: 2009.08.19
Serial Number:
Hardware Revision: 0x0006
Firmware Revision: 0x0102

{ case `uname` in
Linux ) ILOM="/usr/bin/ipmitool sunoem cli" ;;
SunOS ) ILOM="/opt/ipmitool/bin/ipmitool sunoem cli" ;;
esac ; ImageInfo="/opt/oracle.cellos/imageinfo" ;
uname -srm ; head -1 /etc/*release ; uptime | cut -d, -f1 ;
$ILOM "show /SP system_description system_identifier" | grep = ;
$ImageInfo -activated -node -status -ver | grep -v ^$ ;
} | tee /tmp/ExaInfo.log

$GRID_HOME/OPatch/opatch lsinv -all -oh $GRID_HOME | tee /tmp/OPatchInv.log
$ORACLE_HOME/OPatch/opatch lsinv -all | tee -a /tmp/OPatchInv.log

cat /tmp/ExaInfo.log
Linux 2.6.18-128.1.16.0.1.el5 x86_64
==> /etc/enterprise-release <==
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)

==> /etc/redhat-release <==
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
 20:37:56 up 458 days
 system_description = SUN FIRE X4170 SERVER, ILOM v3.0.6.10.b, r52264
 system_identifier = Sun Oracle Database Machine
Active image version: 11.2.1.2.3
Active image activated: XXXX-XX-XX 12:27:12 +0800
Active image status: success
Active node type: COMPUTE
Inactive image version: undefined

FileName: OPatchInv.log
----------------
...
Oracle Home       : /u01/app/11.2.0/grid
Central Inventory : /u01/app/oraInventory
  from           : /etc/oraInst.loc
OPatch version    : 11.2.0.1.2
OUI version       : 11.2.0.1.0
OUI location      : /u01/app/11.2.0/grid/oui
...
--------------------------------------------------------------------------------
List of Oracle Homes:
  Name                                       Location
  Ora11g_gridinfrahome1         /u01/app/11.2.0/grid
  OraDb11g_home1                  /u01/app/oracle/product/11.2.0/dbhome_1
--------------------------------------------------------------------------------
Installed Top-level Products (1):
Oracle Grid Infrastructure                                           11.2.0.1.0
...
Interim patches (2) :
Patch  9524394      : applied on Thu Jun 03 20:46:05 CST 2010
... {TRACKING BUG FOR 11.2.0.1 DB MACHINE BUNDLE PATCH 3}
Patch  9455587      : applied on Fri Apr 02 18:27:47 CST 2010
... {MERGE REQUEST ON TOP OF 11.2.0.1.0 FOR BUGS 8483425 8667622 8702731 8730804}
Rac system comprising of multiple nodes
 Local node = dbserv01
 Remote node = dbserv02
 Remote node = dbserv03
 Remote node = dbserv04
--------------------------------------------------------------------------------
OPatch succeeded.
...
Oracle Home       : /u01/app/oracle/product/11.2.0/dbhome_1
...
Oracle Database 11g                                                  11.2.0.1.0
...
Interim patches (5) :
Patch  8888434      : applied on Sat Jan 08 00:27:33 CST 2011
... {AIX-ASM-CF: LMHB TERMINATE INSTANCE WHEN OFFLINE ONE FAILGROUP IN ASM DG}
Patch  8730312      : applied on Thu Jun 03 21:30:03 CST 2010
... {FWD MERGE FOR BASE BUG 8715387 FOR 12G}
Patch  9502717      : applied on Thu Jun 03 21:25:54 CST 2010
... {LMS HIT ORA-600 [KJBLDRMNEXTPKEY:SEEN] AND CRASHED THE INSTANCE}
{ + same 2 as GI above}

检测 cell server Cache Policy

cell08#  MegaCli64 -LDInfo -Lall -aALL | grep 'Current Cache Policy'
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

cell09#  MegaCli64 -LDInfo -Lall -aALL | grep 'Current Cache Policy'
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU

Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Cache policy is in WB
Would recommend proactive  battery repalcement.

Example :
a. /opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp  -Cache -LALL -aALL ####( Will list the cache policy)

b. /opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp  -WB  -LALL -aALL ####( Will try to change teh policy from xx to WB)
     So policy Change to WB will not come into effect immediately
     Set Write Policy to WriteBack on Adapter 0, VD 0 (target id: 0) success
     Battery capacity is below the threshold value

检测cell BBU备用电池状态：

cell08# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0

BBU status for Adapter: 0

BatteryType: iBBU
Voltage: 4061 mV
Current: 0 mA
Temperature: 36 C

BBU Firmware Status:

Charging Status : None
Voltage : OK
Temperature : OK
Learn Cycle Requested : No
Learn Cycle Active : No
Learn Cycle Status : OK
Learn Cycle Timeout : No
I2c Errors Detected : No
Battery Pack Missing : No
Battery Replacement required : No
Remaining Capacity Low : Yes
Periodic Learn Required : No

Battery state:

GasGuageStatus:
Fully Discharged : No
Fully Charged : Yes
Discharging : Yes
Initialized : Yes
Remaining Time Alarm : No
Remaining Capacity Alarm: No
Discharge Terminated : No
Over Temperature : No
Charging Terminated : No
Over Charged : No

Relative State of Charge: 99 %
Charger System State: 49168
Charger System Ctrl: 0
Charging current: 0 mA
Absolute state of charge: 21 %
Max Error: 2 %

Exit Code: 0x00

批量检测BBU 信息:

dcli -g ~/cell_group -l root -t '{
uname -srm ; head -1 /etc/*release ; uptime | cut -d, -f1 ; imagehistory ;
ipmitool sunoem cli "show /SP system_description system_identifier" | grep = ;
ipmitool sunoem cli "show /SP/policy FLASH_ACCELERATOR_CARD_INSTALLED
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0 | egrep -i
'BBU|Battery|Charge:|Fully|Low|Learn' ;
}' | tee /tmp/ExaInfo.log

Target cells: ['cellserv01', 'cellserv02', 'cellserv03', 'cellserv04', 'cellserv05', 'cellserv06', 'cellserv07']
cellserv01: Linux 2.6.18-128.1.16.0.1.el5 x86_64
cellserv01: ==> /etc/enterprise-release <==
cellserv01: Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
cellserv01:
cellserv01: ==> /etc/redhat-release <==
cellserv01: Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
cellserv01: 01:17:39 up 635 days
cellserv01: Version : 11.2.1.2.1
cellserv01: Image activation date : 2011-03-25 11:59:34 -0800
cellserv01: Imaging mode : fresh
cellserv01: Imaging status : success
cellserv01:
cellserv01: Version : 11.2.1.2.3
cellserv01: Image activation date : 2011-04-13 12:15:46 +0800
cellserv01: Imaging mode : patch
cellserv01: Imaging status : success
cellserv01:
cellserv01: Version : 11.2.1.2.6
cellserv01: Image activation date : 2011-05-27 23:08:22 +0800
cellserv01: Imaging mode : patch
cellserv01: Imaging status : success
cellserv01:
cellserv01: system_description = SUN FIRE X4275 SERVER, ILOM v3.0.6.10.b, r52264
cellserv01: system_identifier = Sun Oracle Database Machine
cellserv01: Connected. Use ^D to exit.
cellserv01: -> show /SP/policy FLASH_ACCELERATOR_CARD_INSTALLED
cellserv01: show: No matching properties found.
cellserv01:
cellserv01: -> Session closed
cellserv01: Disconnected
cellserv01: BBU status for Adapter: 0
cellserv01: BatteryType: iBBU
cellserv01: BBU Firmware Status:
cellserv01: Learn Cycle Requested : No
cellserv01: Learn Cycle Active : No
cellserv01: Learn Cycle Status : OK
cellserv01: Learn Cycle Timeout : No
cellserv01: Battery Pack Missing : No
cellserv01: Battery Replacement required : No
cellserv01: Remaining Capacity Low : Yes
cellserv01: Periodic Learn Required : No
cellserv01: Battery state:
cellserv01: Fully Discharged : No
cellserv01: Fully Charged : Yes
cellserv01: Relative State of Charge: 99 %
cellserv01: Absolute state of charge: 21 %

dcli -l root -g /root/all_group '/opt/MegaRAID/MegAaCli/MegaCli64 -AdpBbuCmd -a0' > BBU.out

check ipmi:

dcli -g ~/cell_group -l root -t '{ > ipmitool sunoem cli
"show /SP/policy FLASH_ACCELERATOR_CARD_INSTALLED" | grep = ;
MegaCli64 -LDInfo -Lall -aALL | grep 'Current Cache Policy' ;
}' | tee /tmp/ExaCells.log

No related posts.