Skip to content

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

浅谈关于清理oracle监听log的方式以及考虑

listener log是一个比较有意思的东西,作为日常运维的一个点,多数的dba都知道清理的方式就是定期备份清下,而这小点子细挖下去会发现还是有些意思的。这里介绍几种日常的清理监听日志的方式以及关注点,我的观点是在做这方面清理的时候,日志有必要制定一个备份策略。

1.offline listener清理
这种方式主要是在停掉了监听或者直接停掉了业务数据库后,对listener.log进程mv或者backup的操作后新建listener.log,或者就是以清理文件内容的方式进行清理。

2.online listener清理
这种清理可以理解为在不影响业务的情况下清理log,这个以oracle角度来区分,区别在于是否禁止listener进程持续写日志上,关闭listener写日志命令如下:

LSNRCTL> set current_listener
LSNRCTL> set log_status off
--之后备分listener.log,清除log后恢复listener进程的日志记录,
LSNRCTL> set log_status on

那么这里在清除log的系统命令上有多种,这里介绍下linux下的3种以及windows上的1种

linux/unix平台:

2.1 cat /dev/null > 要清空的文件
例:

cat /dev/null > /u01/oracle/product/db/network/log/listener.log

2.2 echo “” > 要清空的文件
例:

echo "" > /u01/oracle/product/db/network/log/listener.log

2.3 cp /dev/null 要清空的文件
例:

cp /dev/null /u01/oracle/product/db/network/log/listener.log

以上三种清理都支持在线直接清理日志,可以不禁止listener进程持续写日志的情况下直接执行,只是在考虑点上在前面所说的是否禁止listener进程持续写日志。我日常使用2.1的方式,从系统效率上cp /dev/null的方式会优于其他2种。

Windows平台

2.4 @echo.> 要清空的文件
例:

@echo.> D:\oracle\listener.log

3.rename file方式清理

这个方法在10g之前的版本可以使用,在11g由于adr的设置需要禁止adr后才能够使用,否则会遭遇“TNS-01251: Cannot set trace/log directory under ADR”的错误。
登陆listener控制台,命令如下:

LSNRCTL>set current_listener LSNRCTL>set log_file
LSNRCTL>save_config

例:

LSNRCTL>set current_listener LISTENER1
LSNRCTL>set log_file listener1_1.log
LSNRCTL>save_config

当执行完set log_file这个命令后,系统更新listener.ora文件,同时生成新的listener日志,此后就可以对老的listener.log进行处理。这种方式在sun的solaris蹭遭遇过bug导致监听进程offline,所以使用时候注意平台。还有一个注意点就是在多个监听下分别对每个监听的日志进行清理时候需要分开执行,因为save_config会覆盖当前设置之前的其他监听的设置,导致前面的设置失效。

接连遭遇2波问题都是oracle hang

祸不单行.
1.故障1
半夜收到wang.rui电话,数据库hang住了一样,所有的redolog都是active,新加redo马上就会写完变成active状态,无论多大.
思路:
判断数据库是不是还活着,hang analyze.或者看归档的切换频率,检索告警看看有没有价值的信息
这类东西能让redo这么繁忙,一般都是大事务或者并发大事务,所以可以挖下归档看看操作
既然有观点2了,那么job和schedul是跑不掉检查的
看看数据库的等待事件以及session block情况(别问我为啥要看阻塞,嘿嘿)

故障1最终话费了大概前后几分钟,检测出来,是由于大事务被撤销,产生大量回滚,同时oracle产生了128个并行进程在恢复.这与参数fast_start_parallel_rollback有关,默认为low.由于大量并行的恢复,导致io瓶颈的产生,同时undo争用厉害,改为high是不行了,改为false后,所有开销马上下降.当然这里存在了一个疑问点,默认是low的情况下并行进程是数量应该是cpu_count*2,应该为64才对,为啥我这里128??

2.故障2
清早收到数据库进程阻塞故障,原因不明,所有进程hang住.10205版本数据库linu平台.

检测发现cpu耗尽,内存耗用光,采集了一些os信息后重启恢复了系统,检测后来的信息发现有css的等待,数据库为单机,未采用grid,比较奇怪,跟踪后发现类似bug,Bug 10024824.怀疑大量session因为此bug被hang住把cpu耗光了….主要是发现oracle也没啥很异常的sql波动…准备打补丁.

遭遇scls_scr_create,bug 4632899

没啥说的,刚熬完通宵,客户数据库挂了,说是机器挂了,重启以后系统恢复了,尝试启动crsctl报错

Failure at scls_scr_create with code 1
 Internal Error Information:
 Category: 1234
 Operation: scls_scr_create
 Location: mkdir
 Other: Unable to make user dir
 Dep: 2

support描述与主机名大小写有关,solaris上的一个bug 4632899.而该主机主机名设置混乱,hostname和/etc/hosts下不一致,sysconfig/network的主机名也未设置!

该bug描述:

 

Bug 4632899  CSS does not start if hostname has capital letters  This note gives a brief overview of bug 4632899.
The content was last updated on: 14-OCT-2011
Click here for details of each of the sections below.

Affects:

Product (Component) Oracle Server (PCW)
Range of versions believed to be affected Versions BELOW 11.1
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

Fixed:

This issue is fixed in

Symptoms:

Related To:

  • (None Specified)

Description

CSS does not start on Solaris if the hostname is in upper case.

eg:
 The following errors might be noticed when using CRS scripts:
  Failure at scls_scr_create with code 1
  Category: 1234
  Operation: scls_scr_create
  Location: mkdir
  Other: Unable to make user dir
  Dep: 2

Workaround
  Change the hostname to from uppercase to lower case.

HOOKS PSE:A203 LIKELYAFFECTS XAFFECTS_10.2.0.1 XAFFECTS_V10020001 AFFECTS=10.2.0.1 XAFFECTS_10.2.0.2 XAFFECTS_V10020002 AFFECTS=10.2.0.2 XAFFECTS_10.2.0.3 XAFFECTS_V10020003 AFFECTS=10.2.0.3 XAFFECTS_10.2.0.4 XAFFECTS_V10020004 AFFECTS=10.2.0.4 XPRODID_5 PRODUCT_ID=5 PRODID-5 PCW XCOMP_PCW COMPONENT=PCW TAG_OPSM OPSM FIXED_10.2.0.4.CRS02 FIXED_10.2.0.5 FIXED_11.1.0.6
Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

References

Bug:4632899 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article

索引块上递归事务专用的itl slot争用的识别判断

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

由于itl争用主要是initrans不足(10g后今本不受此影响maxtrans失效),块空间不足原因引起,但是特殊的情况下的索引递归事务引起的itl争用的识别也是需要掌握的技术,虽然大量的递归情况较少见,但如何区分相比前面的2种情况就相对复杂点。主要的思路是根据索引块的itl信息来识别,因为上一篇中讲到在索引的枝节点上,有且只有一个ITL slot,它是用于当发生节点分裂的递归事务(Recursive Transaction)。在叶子节点上,第一条ITL Slot也是用于分裂的递归事务的。只要根据相关索引块的负责递归事务的itl事务槽的使用情况就可以判断争用的情况。

思路如下:
1.找出被阻塞的事务
2.根据阻塞的事务找到相关的回滚块以及相关事务起始回滚编号
3.根据回滚块的内容识别相关的索引块
4.dump出相关的索引块识别对应的itl争用情况

例子:

1.测试阻塞

session 1 更新61080块的100行

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

1 row updated.

commit;

session 2 更新61080块的200行

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

1 row updated.

commit;

session 3 更新61080块的300行

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

1 row updated.

session 4 更新61080块的400行

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

1 row updated.

session 5 更新61080块的500行hang住

2.找出被阻塞的事务以及相关回滚段信息

确认itl阻塞:

SQL> select s.sid, s.event, s.row_wait_obj#
  2  from v$session s where s.sid=151;

       SID EVENT                          ROW_WAIT_OBJ#
---------- ------------------------------ -------------
       148 enq: TX - allocate ITL entry              -1

确认对应的阻塞事务的回滚相关信息,可以发现阻塞事务对应的回滚在2号数据文件的2109数据块中,起始的回滚记录是0x2e(46的16进制)

SQL> select l.sid req_session, s.sid lock_session, l.lmode, l.request, t.xidusn, t.xidslot, t.start_ubafil, t.start_ubablk, t.start_ubarec
  2  from v$lock l, v$transaction t, v$session s
  3  where l.type = 'TX'
  4  and trunc(id1/power(2,16)) = t.xidusn
  5  and l.id2 = t.xidsqn
  6  and id1 - power(2,16)*trunc(id1/power(2,16)) = t.xidslot
  7  and t.addr = s.taddr
  8  and l.request = 4;

REQ_SESSION LOCK_SESSION      LMODE    REQUEST     XIDUSN    XIDSLOT START_UBAFIL START_UBABLK START_UBAREC
----------- ------------ ---------- ---------- ---------- ---------- ------------ ------------ ------------
        148          159          0          4          5         26            2         2109           46

dump出2号数据文件的2109号数据块

SQL> alter system dump datafile 2 block 2109;

System altered.

确认相关对象的object_id

SQL> select object_name,object_id,data_object_id from dba_objects where object_name in ('LUDA','IDX_TEST') and owner='SYS';

OBJECT_NAME                               OBJECT_ID DATA_OBJECT_ID
---------------------------------------- ---------- --------------
IDX_TEST                                      51980          51980
LUDA                                          51978          51978

分析2号数据文件的2109号数据块dump文件,从Rec #0x2e部分开始到结束只有0x2e此条与对象号51980,51978相关回滚记录

*-----------------------------
* Rec #0x2e  slt: 0x1a  objn: 51978(0x0000cb0a)  objd: 51978  tblspc: 0(0x00000000)
*       Layer:  11 (Row)   opc: 1   rci 0x00
Undo type:  Regular undo    Begin trans    Last buffer split:  No
Temp Object:  No
Tablespace Undo:  No
rdba: 0x00000000
*-----------------------------
uba: 0x0080083d.014b.2d ctl max scn: 0x0000.000bb362 prv tx scn: 0x0000.000bb37b
txn start scn: scn: 0x0000.000bcdc1 logon user: 0
 prev brb: 8388917 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x04  ver: 0x01
op: L  itl: xid:  0x0002.010.0000013b uba: 0x00800051.0100.3c
                      flg: C---    lkc:  0     scn: 0x0000.000bcd90
KDO Op code: URP row dependencies Disabled
  xtype: XAxtype KDO_KDOM2 flags: 0x00000080  bdba: 0x0040ee98  hdba: 0x0040ee91
itli: 1  ispac: 0  maxfr: 4863
tabn: 0 slot: 400(0x190) flag: 0x2c lock: 0 ckix: 71
ncol: 1 nnew: 1 size: 0
Vector content:
col  0: [ 3]  c2 31 06

End dump data blocks tsn: 1 file#: 2 minblk 2109 maxblk 2109

从bdba地址分析可以获得当前更新对象对luda,前面更新提交的1条语句的部分就是luda的61080号块。

SQL> select dbms_utility.data_block_address_file(TO_NUMBER('0040ee98', 'XXXXXXXX')) file_id,
  2  dbms_utility.data_block_address_block(TO_NUMBER('0040ee98', 'XXXXXXXX')) block_id from dual;

   FILE_ID   BLOCK_ID
---------- ----------
         1      61080

在回滚信息中没有发现索引块类型,事务对象只有objno为51978的luda表,类似的索引对象也是用此方法分析。