Skip to content

Oracle 排障配置与调整 - 8. page

Oracle10g版本后enq: TX – allocate ITL entry等待事件的根源以及解决思路

客户昨日一套核心系统有进程挂住，top等待事件为enq: TX – allocate ITL entry，判断为itl争用的原因，这方面以前做了不少测试并没有整理，这里顺便做个整理作为诊断手段用。该内容主要分为主要的三个部分：

一.itl的解释以及原理
二.数据块上的initrans不能扩展分配slot导致的itl争用测试
三.索引块上递归事务专用的itl slot争用的识别判断

 

一.ITL原理解释

ITL(Interested Transaction List)是Oracle数据块内部的一个组成部分，用来记录该块所有发生的事务，一个itl可以看作是一个记录，在一个时间，可以记录一个事务（包括提交或者未提交事务）。当然，如果这个事务已经提交，那么这个itl的位置就可以被反复使用了，因为itl类似记录，所以，有的时候也叫itl槽位。Oracle的每个数据块中都有一个或者多个事务槽，每一个对数据块的并发访问事务都会占用一个事务槽。 表和索引的事务槽ini_trans是1、max_trans是255，在oracle10g中，不能修改max_trans这个参数，因为oracle10g忽略了这个参数。如果一个事务一直没有提交，那么，这个事务将一直占用一个itl槽位，itl里面记录了事务信息，回滚段的嵌入口，事务类型等等。如果这个事务已经提交，那么，itl槽位中还保存的有这个事务提交时候的SCN号。如dump一个块，就可以看到itl信息：

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0006.002.0000158e  0x0080104d.00a1.6e  --U-  734  fsc 0x0000.6c9deff0
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

如果在并发量特别大的系统中，最好分配足够的itl个数（10g之前的版本），其实它并浪费不了太多的空间，或者，设置足够的pctfree，保证itl能扩展，但是pctfree有可能是被行数据给消耗掉的，如update可能一下占满块空间，所以，也有可能导致块内部的空间不够而导致itl等待，所以在通常情况下，10g版本后引起itl等待的原因往往是因为块的空间不足导致，并不是tran事务槽数量不足，在正常情况下2k的数据块最多可以拥有41个itl，4k数据块最多拥有83，8k最多用友169个itl（以itl 24byte为单位）。INITRANS不足的问题不会出现在索引数据块上，当发现没有足够空间分配ITL slot时，无论是枝点块还是叶子块，数据块会发生分裂(Index Block Split)。

有一种特殊情况也会引起ITL的等待，就是在索引上的递归事务itl争用，这种情况比较特殊。在索引的枝节点上，有且只有一个ITL slot，它是用于当发生节点分裂的递归事务(Recursive Transaction)。在叶子节点上，第一条ITL Slot也是用于分裂的递归事务的。在一个用户事务中，如果发生多次分裂，每一次分裂都是由一个单独的递归事务控制的，如果下层节点分裂导致其父节点分裂，它们的分裂则由同一个递归事务控制。当2个事务同时需要分裂一个枝节点或者叶子节点时，或者枝节点下的2个子节点分别被2个事务分裂，就会造成这种ITL等待。

 

2.数据块上的initrans不能扩展分配slot导致的itl争用测试

我们做个测试关于如果数据块没有空间留给itl slot扩展时候的测试，创建表luda，指定pctfree为0，同时指定initrans为1然后填满相关数据块，再对块满的数据进行更新模拟出itl的等待。
创建表luda，并指定pctfree为0，initrans为1

SQL> create table luda(a int) pctfree 0 initrans 1;

Table created.

 

插入大量数据

SQL> begin
2 for i in 1..20000 loop
3 insert into luda values(i);
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

SQL> commit ;

Commit complete.

 

SQL> select f,b,count(*) from (select dbms_rowid.rowid_relative_fno(rowid) f,dbms_rowid.rowid_block_number(rowid) b
2 from luda) group by f,b order by 3;

F B COUNT(*)
---------- ---------- ----------
1 61101 200
1 61093 734
1 61089 734
1 61095 734
1 61085 734
1 61099 734
1 61074 734
1 61077 734
1 61080 734
1 61092 734
1 61100 734
1 61083 734
1 61091 734
1 61097 734
1 61098 734
1 61075 734
1 61076 734
1 61078 734
1 61081 734
1 61084 734
1 61087 734
1 61096 734
1 61079 734
1 61094 734
1 61088 734
1 61090 734
1 61082 734
1 61086 734

 

插入20018条数据后可以发现该表有26个数据块，填满了除了61101块意外的其他数据块。
接着导出已经填满的数据块61074.

SQL> alter system dump datafile 1 block 61074;

System altered.

 

Block header dump: 0x0040ee92
Object id on Block? Y
seg/obj: 0xcb0a csc: 0x00.bb6a1 itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.020.0000013b 0x0080078c.013c.3a --U- 734 fsc 0x0000.000bb765
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
--可以发现initrans为1的情况下默认是有2个事务槽，itc=2
data_block_dump,data header at 0xd7fe45c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x0d7fe45c
bdba: 0x0040ee92
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xbf8

avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734 offs=0

 

块满的情况测试slot的分配，根据前面的查询结果我们知道单个块的存储行数为734行，也可以通过dump中的nrow=734得知，所以我们在这部测试中依次更新第100，200，300行的数据。

session 1 更新第100行的数据：

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61074
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=100;

1 row updated.

 

session 2更新第200行的数据：

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61074
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=200;

1 row updated.

 

session 3更新第300行的数据，session3的sid为158，并且在执行过程中session 3 hang住：

SQL> select sid from v$mystat where rownum=1;

SID
----------
158

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61074
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=300;
--此时进程hang住
 

alter system dump datafile 1 block 61074；

 

Block header dump: 0x0040ee92
Object id on Block? Y
seg/obj: 0xcb0a csc: 0x00.bb97e itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0003.014.00000159 0x008006bb.01f1.12 ---- 1 fsc 0x0000.00000000
0x02 0x0005.00e.0000013c 0x0080083c.014b.20 ---- 1 fsc 0x0000.00000000
--通过此时的dump我们也可以发现原先为被占用的2个事务槽已经被占用而且事务未提交。
data_block_dump,data header at 0xd77645c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x0d77645c
bdba: 0x0040ee92
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xbf8
avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734 offs=0

 

 
--查询158进程的等待事件为itl的相关等待事件enq: TX - allocate ITL entry
SQL> select sid,event from v$session where sid=158;

SID EVENT
---------- ----------------------------------------------------------------
158 enq: TX - allocate ITL entry

从以上验证了空间不足的情况下会导致itl无法分配引起enq: TX – allocate ITL entry等待事件的产生。

接下来测试块不满的情况，在表luda中目前有数据的块为26个，其中块号为61101的块只有200条数据，只占用该块30%的空间，为了测试需要对61101号块采用4个session分别对第10，20，30，40行进行更新：

session 1：

 

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61101
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=10;

1 row updated.

 

 

session2：

 

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61101
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=20;

1 row updated.

 

session3：

 

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61101
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=30;

1 row updated.

 

session4：

SQL> update luda set a=a
2 where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=61101
3 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=40;

1 row updated.

 

以上4个session都没有遇到阻塞，导出61101号块可以发现该块有4个itl slot，自动扩展了2个slot，验证了在空间足够的情况下itl slot会自动扩展。

SQL> alter system dump datafile 1 block 61101;

System altered.

 

--

Block header dump: 0x0040eead
Object id on Block? Y
seg/obj: 0xcb0a csc: 0x00.bc003 itc: 4 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0003.014.00000159 0x008006bb.01f1.13 ---- 1 fsc 0x0000.00000000
0x02 0x0009.016.0000013b 0x0080075c.0143.37 ---- 1 fsc 0x0000.00000000
0x03 0x0005.00e.0000013c 0x0080083c.014b.21 ---- 1 fsc 0x0000.00000000
0x04 0x0002.026.00000139 0x00800130.00fc.09 ---- 1 fsc 0x0000.00000000
--itc=4，在61101块上存在4条未提交的事务，分别是我们刚才执行的sesson1-4.

data_block_dump,data header at 0xe17048c
===============
tsiz: 0x1f70
hsiz: 0x1a2
pbl: 0x0e17048c
bdba: 0x0040eead
76543210
flag=--------
ntab=1
nrow=200
frre=-1
fsbo=0x1a2
fseo=0x1957
avsp=0x16c6
tosp=0x16c6
0xe:pti[0] nrow=200 offs=0

 

以上测试说明了在Oracle10g以来，itl的争用事件产生在数据块上主要是受块空间的影响，如果大量事务在相关block上执行操作但是当块无法满足分配事务槽，则会产生itl相关争用。
下一节主要是区分是索引块还是表数据块的争用. http://www.ludatou.com/?p=1920

Buffer cache Data access tuning Database Instance tuning Oracle Oracle 排障配置与调整 performance tuning 浅谈oracle技术系列 等待事件 | Guang Cai Li |

11g r2 模拟OCR和voting disk不可用，完整恢复过程，以及一些注意事项

环境：RHEL5.8 RAC 11.2.0.3.0

1：查看ORC和voting disk信息：

In 11g Release 2 your voting disk data is automatically backed up in the OCR whenever there is a configuration change.
所以恢复时恢复备份OCR即可，这里和10g是不同的，不需要备份voting disk，备份OCR即可

2：使用cluvfy 工具检查OCR完整性
[grid@rac1 ~]$ cluvfy comp ocr -n all
Verifying OCR integrity
Checking OCR integrity…

Checking the absence of a non-clustered configuration…
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc”…
OCR config file “/etc/oracle/ocr.loc” check successful
Disk group for ocr location “+CRSDATA” available on all the nodes

NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck’ as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

3：使用ocrcheck检测OCR内容的完整性
[grid@rac1 ~]$ ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSDATA
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check bypassed due to non-privileged user –如果使用root用户执行ocrcheck时，会显示Logical corruption check succeeded

4：检测voting disk的信息
[grid@rac1 ~]$ crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. ONLINE 2b1bd0c122584f5abf72033b2b2d26bd (/dev/asm-b_crs) [CRSDATA]
2. ONLINE 2bc03776cdd94f5cbfb9165c473fdb0e (/dev/asm-c_crs) [CRSDATA]
3. ONLINE 3b43c39513a64f2dbf7083a9510ada89 (/dev/asm-d_crs) [CRSDATA]
Located 3 voting disk(s).

从上面看出，OCR和voting disk都位于+CRSDATA磁盘组 ，注意+CRSDATA磁盘组还有ASM的启动参数文件，ASM启动是根据磁盘头的kfdhdb.spfile指向ASM上的此磁盘的UA NUMBER从而读取spfile文件

5：手动备份一份OCR信息：
[root@rac1 grid]# ocrconfig -export /tmp/ocr_20130717.dmp
[root@rac1 grid]# ll /tmp/ocr_20130717.dmp -h
-rw——- 1 root root 102K Jul 17 14:45 /tmp/ocr_20130717.dmp

6：查看OCR自动备份信息
[grid@rac1 ~]$ ocrconfig -showbackup

rac1 2013/07/16 15:45:24 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr
rac2 2013/07/16 08:13:38 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup01.ocr
rac2 2013/07/16 04:14:09 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup02.ocr
rac2 2013/07/16 00:14:38 /u01/app/11.2.0.3/grid/cdata/ad-cluster/day.ocr
rac2 2013/07/07 04:40:11 /u01/app/11.2.0.3/grid/cdata/ad-cluster/week.ocr
PROT-25: Manual backups for the Oracle Cluster Registry are not available

7：保存一份ASM参数文件，如果提前没保存，可以到$CRS_HOME/dbs/init.ora获取一份，后面此启动参数的详细内容

[grid@rac1 dbs]$ sqlplus / as sysasm

SQL> create pfile=’/tmp/asm_pfile_130717.txt’ from spfile;

File created.

8：破坏保存OCR信息的磁盘组+CRSDATA
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-b_crs bs=1024 count=1000
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-c_crs bs=1024 count=1000

9：破坏了磁盘b和c后，都检测通过，没报错，在rac1和rac2停止crs
[root@rac1 dev]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’
CRS-2673: Attempting to stop ‘ora.crsd’ on ‘rac1’
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on ‘rac1’
…………………
CRS-4133: Oracle High Availability Services has been stopped.

[root@rac2 dev]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’
CRS-2673: Attempting to stop ‘ora.crsd’ on ‘rac1’
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on ‘rac1’
…………………
CRS-4133: Oracle High Availability Services has been stopped.

[root@rac1 dev]# ps -ef |grep ora_
root 16189 32265 0 16:26 pts/0 00:00:00 grep ora_
[root@rac1 dev]# ps -ef |grep asm_
root 16195 32265 0 16:26 pts/0 00:00:00 grep asm_

10:再启动CRS,报错
[root@rac1 dev]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

[root@rac1 ~]# tail -50f /u01/app/11.2.0.3/grid/log/rac1/alertrac1.log

[cssd(16559)]CRS-1637:Unable to locate configured voting file with ID 2b1bd0c1-22584f5a-bf72033b-2b2d26bd; details at (:CSSNM00020:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.947
[cssd(16559)]CRS-1637:Unable to locate configured voting file with ID 2bc03776-cdd94f5c-bfb9165c-473fdb0e; details at (:CSSNM00020:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.947
[cssd(16559)]CRS-1705:Found 1 configured voting files but 2 voting files are required, terminating to ensure data integrity; details at (:CSSNM00021:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.948
[cssd(16559)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:16.073
[cssd(16559)]CRS-1603:CSSD on node rac1 shutdown by user.

ocrcheck检测报错：
[root@rac1 dev]# ocrcheck
PROT-602: Failed to retrieve data from the cluster registry
PROC-26: Error while accessing the physical storage

11：强制关闭CRS:
[root@rac1 dev]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’

[root@rac1 dev]# crsctl stop crs -f
CRS-2797: Shutdown is already in progress for ‘rac1’, waiting for it to complete
CRS-2797: Shutdown is already in progress for ‘rac1’, waiting for it to complete
CRS-4133: Oracle High Availability Services has been stopped.

12：以独占模式启动rac1
[root@rac1 dev]# crsctl start crs -excl -nocrs
CRS-4123: Oracle High Availability Services has been started.
CRS-2672: Attempting to start ‘ora.mdnsd’ on ‘rac1’
CRS-2676: Start of ‘ora.mdnsd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.gpnpd’ on ‘rac1’
CRS-2676: Start of ‘ora.gpnpd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cssdmonitor’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.gipcd’ on ‘rac1’
CRS-2676: Start of ‘ora.cssdmonitor’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.gipcd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cssd’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.diskmon’ on ‘rac1’
CRS-2676: Start of ‘ora.diskmon’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.cssd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.drivers.acfs’ on ‘rac1’
CRS-2679: Attempting to clean ‘ora.cluster_interconnect.haip’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.ctssd’ on ‘rac1’
CRS-2681: Clean of ‘ora.cluster_interconnect.haip’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cluster_interconnect.haip’ on ‘rac1’
CRS-2676: Start of ‘ora.ctssd’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.drivers.acfs’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.cluster_interconnect.haip’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.asm’ on ‘rac1’
CRS-2676: Start of ‘ora.asm’ on ‘rac1’ succeeded

12：创建CRSVOTEDISK磁盘组以及spfile

[grid@rac1 ~]$ asmcmd

ASMCMD> ls
空的

[grid@rac1 ~]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 17 16:58:18 2013

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL> show parameter spfile
NAME TYPEVALUE
———————————— ———– ——————————
spfile string

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’, ‘/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;
create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’, ‘/dev/asm-d_crs’
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15033: disk ‘/dev/asm-d_crs’ belongs to diskgroup “CRSDATA” –这里报错是因为asm-d_crs没清除磁盘头信息

清除asm-d_crs磁盘头信息
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-d_crs bs=1024 count=1000

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0′;

Diskgroup created.

SQL> create spfile=’+CRSVOTEDISK’ from pfile=’/tmp/asm_pfile_130717.txt’;

File created.

SQL> quit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Real Application Clusters and Automatic Storage Management options
[grid@rac1 ~]$ asmcmd
ASMCMD> ls
CRSVOTEDISK/
ASMCMD> ls CRSVOTEDISK
ad-cluster/
ASMCMD> ls CRSVOTEDISK/ad-cluster/
ASMPARAMETERFILE/
ASMCMD> ls CRSVOTEDISK/ad-cluster/ASMPARAMETERFILE
REGISTRY.253.821034567

13：Restore OCR from backup:
将原磁盘组+CRSDATA改为新建立的磁盘组 +CRSVOTEDISK
[root@rac1 dev]# vim /etc/oracle/ocr.loc

ocrconfig_loc=+CRSVOTEDISK
local_only=FALSE

[root@rac1 dev]# ocrconfig -restore /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr

可以看到增加了一个OCRFILE文件夹
ASMCMD> ls CRSVOTEDISK/ad-cluster
ASMPARAMETERFILE/
OCRFILE/
ASMCMD> ls CRSVOTEDISK/ad-cluster/OCRFILE -l
Type Redund Striped Time Sys Name
OCRFILE MIRROR COARSE JUL 17 17:00:00 Y REGISTRY.255.821036449
ASMCMD> ls CRSVOTEDISK/ad-cluster/ASMPARAMETERFILE -l
Type Redund Striped Time Sys Name
ASMPARAMETERFILE MIRROR COARSE JUL 17 17:00:00 Y REGISTRY.253.821034567

检测成功
[root@rac1 dev]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSVOTEDISK
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

14：Restore the Voting Disk:

[root@rac1 dev]# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. OFFLINE 2b1bd0c122584f5abf72033b2b2d26bd () []
2. OFFLINE 2bc03776cdd94f5cbfb9165c473fdb0e () []
3. ONLINE 3b43c39513a64f2dbf7083a9510ada89 (/dev/asm-d_crs) [CRSDATA]
Located 3 voting disk(s).

[root@rac1 dev]# crsctl replace votedisk +CRSVOTEDISK
CRS-4602: Failed 27 to add voting file 5818c2c531394f45bff13c5a7532c8d4.
CRS-4602: Failed 27 to add voting file 1ce0436528624faabf7d4a1dd8dc978a.
CRS-4602: Failed 27 to add voting file 09def2b244af4f42bf13679a8aa0ff73.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failed to replace voting disk group with +CRSVOTEDISK.
CRS-4000: Command Replace failed, or completed with errors.

这里报错是一开始asm-d_crs没清除磁盘头信息导致的

======================================== 到这里恢复voting disk失败了 ，下面重新开始再次尝试恢复============
下面恢复时要注意：

crsctl start crs -excl -nocrs 启动后，马上关闭ASM,不要立刻创建create diskgroup CRSVOTEDISK磁盘组，再使用参数启动ASM

不然创建磁盘组时可能会收入如下报错：

例如：（下面的操作看看就好了，直到 ：下面开始再次恢复操作）

[grid@rac1 ~]$ sqlplus / as sysasm
SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;
create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15031: disk specification ‘/dev/asm-d_crs’ matches no disks
ORA-15014: path ‘/dev/asm-d_crs’ is not in the discovery set
ORA-15031: disk specification ‘/dev/asm-c_crs’ matches no disks
ORA-15014: path ‘/dev/asm-c_crs’ is not in the discovery set
ORA-15031: disk specification ‘/dev/asm-b_crs’ matches no disks
ORA-15014: path ‘/dev/asm-b_crs’ is not in the discovery set –这里找不到设备应该也是和下面的情况是一样的，没指定扫描的路径

SQL> col PATH for a50
SQL> select group_number, disk_number, mount_status, header_status, path from v$asm_disk;
no rows selected
说明没识别出磁盘 ，这里为什么没磁盘现在是搞明白了，因为参数里面根本没设置

SQL> show parameter asm

NAME TYPE VALUE
———————————— ———– ——————————
asm_diskgroups stringDATA —这里使用默认参数文件启动时是空的，正常情况也不会显示保存OCR磁盘组名的
asm_diskstring string/dev/asm* —这里使用默认参数文件启动时是空的，没指定扫描的路径
asm_power_limit integer1
asm_preferred_read_failure_groups string

所以为了保险起见，应该crsctl start crs -excl -nocrs 启动后，马上关闭ASM,不要立刻创建create diskgroup CRSVOTEDISK磁盘组，再使用参数启动ASM
SQL> startup pfile=’/tmp/asm_pfile_130717.txt’;

[grid@rac1 ~]$ cat /tmp/asm_pfile_130717.txt
+ASM1.__oracle_base=’/u01/app/grid’#ORACLE_BASE set from in memory value
+ASM1.asm_diskgroups=’DATA’#Manual Mount
+ASM2.asm_diskgroups=’DATA’#Manual Mount
*.asm_diskstring=’/dev/asm*’
*.asm_power_limit=1
*.diagnostic_dest=’/u01/app/grid’
*.instance_type=’asm’
*.large_pool_size=12M
*.remote_login_passwordfile=’EXCLUSIVE’

这里再查下v$asm_disk就可以查询到磁盘，也可以顺利的创建磁盘组了。。。。。。。。。。，就是因为没立刻关闭ASM,使用修改好的参数文件，创建磁盘组时一直提示找不到磁盘，耽误了半天时间

下面开始再次恢复操作：

关闭crs后再启动
[root@rac1 dev]# crsctl stop crs
[root@rac1 dev]# crsctl start crs -excl -nocrs
[root@rac1 dev]# crsctl query css votedisk
Located 0 voting disk(s).

关闭rac1上的ASM，再使用参数文件启动ASM，创建CRS磁盘组，创建spfile

[grid@rac1 ~]$ sqlplus / as sysasm

SQL>shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup pfile=’/tmp/asm_pfile_130717.txt’;
ASM instance started

SQL> col path for a50
SQL> set linesize 130
SQL> select group_number, disk_number, mount_status, header_status, path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU PATH
————————————– ———— —————- ——————————
0 0 CLOSED MEMBER /dev/asm-e_data
0 3 CLOSED CANDIDATE /dev/asm-b_crs
0 2 CLOSED CANDIDATE /dev/asm-c_crs
0 1 CLOSED CANDIDATE /dev/asm-d_crs

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;

Diskgroup created.

SQL> create spfile=’+CRSVOTEDISK ‘ from pfile=’/tmp/asm_pfile_130717.txt’;

File created.

SQL> quit

恢复crs
[root@rac1 dev]# ocrconfig -restore /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr

恢复voting disk

[root@rac1 dev]# crsctl replace votedisk +CRSVOTEDISK

Successful addition of voting disk 1b00b0ec4e504f7fbf1f8d20fbbfaa4b.
Successful addition of voting disk 5a3b646433124fdcbf23c3c290de7fe3.
Successful addition of voting disk 5d27d80b96d74f09bf1756be6dee387f.
Successfully replaced voting disk group with +CRSVOTEDISK .
CRS-4266: Voting file(s) successfully replaced

检测
[root@rac1 ~]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSVOTEDISK
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

[root@rac1 ~]# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. ONLINE 1b00b0ec4e504f7fbf1f8d20fbbfaa4b (/dev/asm-b_crs) [CRSVOTEDISK ]
2. ONLINE 5a3b646433124fdcbf23c3c290de7fe3 (/dev/asm-c_crs) [CRSVOTEDISK ]
3. ONLINE 5d27d80b96d74f09bf1756be6dee387f (/dev/asm-d_crs) [CRSVOTEDISK ]
Located 3 voting disk(s).

停止crs以正常方式启动：
[root@rac1 ~]# crsctl stop crs
[root@rac1 ~]# crsctl start crs

此时，crs和voting disk已经完成恢复，但要注意修改rac2上的/etc/oracle/ocr.loc里面的ocrconfig_loc=+CRSVOTEDISK ，不然启动报错：

[/u01/app/11.2.0.3/grid/bin/oraagent.bin(19510)]CRS-5019:All OCR locations are on ASM disk groups [CRSDATA], and none of these disk groups are mounted. Details are at “(:CLSN00100:)” in “/u01/app/11.2.0.3/grid/log/rac1/agent/ohasd/oraagent_grid/oraagent_grid.log”.
2013-07-18 00:10:33.678
[/u01/app/11.2.0.3/grid/bin/oraagent.bin(19510)]CRS-5019:All OCR locations are on ASM disk groups [CRSDATA], and none of these disk groups are mounted. Details are at “(:CLSN00100:)” in “/u01/app/11.2.0.3/grid/log/rac1/agent/ohasd/oraagent_grid/oraagent_grid.log”.
2013-07-18 00:11:03.614

[root@rac2 ~]# crsctl start crs

[root@rac1 ~]# crs_stat -t
Name Type Target State Host
————————————————————
ora.CRSDATA.dg ora….up.type ONLINE OFFLINE
ora.DATA.dg ora….up.type ONLINE ONLINE rac1
ora….ER.lsnr ora….er.type ONLINE ONLINE rac1
ora….N1.lsnr ora….er.type ONLINE ONLINE rac1
ora.asm ora.asm.type ONLINE ONLINE rac1
ora.chris.db ora….se.type ONLINE ONLINE rac1
ora.cvu ora.cvu.type ONLINE ONLINE rac1
ora.gsd ora.gsd.type OFFLINE OFFLINE
ora….network ora….rk.type ONLINE ONLINE rac1
ora.oc4j ora.oc4j.type ONLINE ONLINE rac1
ora.ons ora.ons.type ONLINE ONLINE rac1
ora….SM1.asm application ONLINE ONLINE rac1
ora….C1.lsnr application ONLINE ONLINE rac1
ora.rac1.gsd application OFFLINE OFFLINE
ora.rac1.ons application ONLINE ONLINE rac1
ora.rac1.vip ora….t1.type ONLINE ONLINE rac1
ora….SM2.asm application ONLINE ONLINE rac2
ora….C2.lsnr application ONLINE ONLINE rac2
ora.rac2.gsd application OFFLINE OFFLINE
ora.rac2.ons application ONLINE ONLINE rac2
ora.rac2.vip ora….t1.type ONLINE ONLINE rac2
ora….ry.acfs ora….fs.type ONLINE ONLINE rac1
ora.scan1.vip ora….ip.type ONLINE ONLINE rac1

Grid and Cluster Oracle 排障配置与调整 Oracle恢复 数据技术 | Guang Cai Li | |   OCR RAC

最近买房,忙着打了一堆证明~~所以blog短暂没有更新.

这个错误是昨天一个客户把兄弟单位的错误转过来的,这里感谢客户对我的信任.由于是生产,当时因为丢失了11w条数据,后来我远程给恢复完成后,客户工程师在调试过程中遭遇12537,该错误伴随Linux Error 29,当时电话交流时候初步判断网络出现回路,而经过一翻查验,问题确实出在Oracle网络上.

首先查证Oracle监听报错如下:

oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 03-SEP-2014 17:09:56 Copyright (c) 1991, 2009, Oracle. All rights reserved.

Starting /opt/ora11g/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...

TNS-12537: TNS:connection closed
TNS-12560: TNS:protocol adapter error
TNS-00507: Connection closed
Linux Error: 29: Illegal seek

Oracle DB的alert log报错如下:

Wed Sep 03 17:08:01 2014
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x2F518C2, nttaddr2bnd()+2158] [flags: 0x0, count: 1]
Errors in file /opt/ora11g/diag/rdbms/jcls/JCLS/trace/JCLS_d000_7563.trc  (incident=9683):
ORA-07445: exception encountered: core dump [nttaddr2bnd()+2158] [SIGSEGV] [ADDR:0x0] [PC:0x2F518C2] [Address not mapped to object] []

经过以上的信息,作为trouble shooting的需求是应该对trace进行进一步分析的,但从排障以及及时恢复生产的角度,客户的紧迫度已到了一个比较崩神经的地步了,所以我还是从个人判断的角度检查了网路可能出现回路的几个地方查验,首先就是ip的设置如下:

hosts文件内容

oracle@localhost ~]$
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
8.0.1.152   localhost

network内容：

oracle@localhost ~]$
NETWORKING=yes
HOSTNAME=localhost

按照自己的思路才检查就发现了问题所在了,主机名localhost冲突,而上面告警日志的07445的内存错误也初步怀疑是和该网络回路有关.

使用ping localhost时候会发现返回数据包的ip地址为127.0.0.1,这是这个错误的问题错在,而真实的情况是应该由8.0.1.152ip返回数据包,这里主要为hostname 设置出错.

[oracle@localhost ~]$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.030 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.030 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.030 ms

这里的处理办法为将8.0.1.152的ip对于的hostname改为对于的hostname(比如oradbhost01),然后更改network文件下的hostname,并通过命令hostname更新内存中的hostname,重启网络和修改监听的hostname并重启监听,问题可以得到解决.

TNS-12537 Linux Error: 29: Illegal seek

Oracle数据库版本支持结束时间表以及数据库版本发行时间表

数据库版本支持时间表：

 
大版本
（点击查看详情）		 当前补丁集 下一补丁集 标准服务结束日期 扩展服务结束日期 注释
12.1.0.X 无 12.1.0.2 – – 基版本为 12.1.0.1。
11.2.0.X 11.2.0.4 无 2015年1月 2018年1月
扩展服务第一年（2015年1月到2016年1月）的费用取消		 基版本为 11.2.0.1。
11.2.0.4 为 11.2 的最终补丁集
11.2 每一个补丁集都是完整安装程序包 – 详见 Note:1189783.1
11.2.0.1 在2011年9月13日后停止提供新的补丁
11.2.0.2 在2013年10月31日后停止提供新的补丁
11.2.0.3 在2015年8月27日后停止提供新的补丁 – 详见 Note:742060.1
11.1.0.X 11.1.0.7 无 2012年8月 2015年8月 基版本为 11.1.0.6。
11.1.0.7 是 11.1 的最终补丁集
10.2.0.X 10.2.0.5 无 2010年7月 2013年7月
自2013年8月至2015年7月提供有限的扩展服务。详见 “Oracle Software Technical Support Policies”

Extended Support 部分.

 10.2.0.5 是 10.2 的最终补丁集。免费的扩展服务在2011年7月31日结束。
在此之后只有有限的平台会继续提供补丁

– 特定平台结束日期详见Note:742060.1
10.1.0.X 10.1.0.5 无 2009年1月 2012年1月 10.1.0.5 是 10.1 的最终补丁集。
10.1 的扩展服务已经结束 – 详见 Note:761713.1
9.2.0.X 9.2.0.8 无 2007年7月 2010年7月
自2010年7月至2012年7月提供有限的扩展服务。
详见这里		 9.2.0.8 是 9.2 的最终补丁集。
免费的扩展服务在2008年7月31日结束。 详见 Note:392222.1

 

数据库版本停止更新时间表：

版本 结束日期 特例*
11.2.0.4 2018年1月31日
HP-UX Itanium: 停止提供补丁日期为2020年12月。 从2018年2月1日起只提供严重程度为1级的修复（不会再发布新的 PSU 和 CPU） 。
11.2.0.3 2015年8月27日
11.2.0.2 2013年10月31日 结束日期比正常晚
11.2.0.1 2011年9月13日
对于 Exadata 结束日期为2012年4月30日
11.1.0.7 2015年8月31日7
HP-UX Itanium – 结束日期为2015年12月。从2015年9月1日起只提供严重程度为1级的修复（不会再发布新的 PSU 和 CPU）。
11.1.0.6 2009年9月18日
10.2.0.5 2015年7月31日7
所有平台  – 标准 Extended Support 在2013年7月31日结束。在2013年8月至2015年7月间，提供有限支持的 Extended Support，日起只提供严重程度为1级的修复（不会再发布新的 PSU 和 CPU）。详见Oracle Software Technical Support Policies.
HP-UX, Linux, 和 Windows Itanium – 结束日期为2015年12月。从2013年8月1日起只提供严重程度为1级的修复（不会再发布新的 PSU 和CPU）。
10.2.0.4 2011年7月31日5
10.2.0.3 2009年2月22日
IBM Linux on Power
2009年4月9日
IBM Linux on System z
 2009年5月16日
Microsoft Windows Itanium (64-bit)
 2009年5月2日
HP Tru64 UNIX
 2009年5月20日
10.1.0.4 2007年1月30日

 
Database Oracle Oracle 排障配置与调整 数据技术 | Guang Cai Li |