XDB SGA initialization等待事件诊断

1. 故障说明

告警短信发来信息,OGG的归档目录使用已经超过50%,登录发现,确实如此。

2. ogg删归档脚本说明

当前OGG的归档删除策略是跟据OGG抽取进程的Recovery Checkpoint来删除的,不启用BR,脚本如下:

$ cat /gg/purge_archXnew.sh
#!/bin/sh

####################################################
##
## Purge Archive Log For OGG
##    
## Usage:
##   1.You must modify the variable in the file
##     GGHOME EXTNAME ARCHPATH
##   2.Call Method :  
##     /gg/purge_archXnew.sh <thread>
##     for example: /gg/purge_archXnew.sh 1
## 
## PeiZhengfeng 2014.10.13
## hthorizion
## 
## Platform for Unix/Linux
##
####################################################

GGHOME=/gg
EXTNAME=ex_xx
ARCHPATH=/archgg/xxxxx
THREAD=$1

##--------------------------------------
## Parameter : 
##    $1   Extract Name
##    $2   Thread
##--------------------------------------
getchseqX()
{
  cd $GGHOME
  echo "info $1,showch"| /gg/ggsci | sed 's/^[ ]\{1,\}//;s/[ ]\{1,\}$//g' \
| awk '$1~/^Recovery/ && $2~/Checkpoint/ {for (i=1;i<=2;i++) {getline;print}}' \
| xargs -n6 | sed -e 's/[Thread #:|Sequence #:]/ /g'| awk -F " " '{print $1" "$2}' \
| grep ^$2 | awk -F " " '{print $2}'
}

logseq=`getchseqX $EXTNAME $THREAD`
logseq=` expr $logseq - 1 `
echo $logseq

rman target / <<EOF
delete noprompt archivelog until sequence $logseq  thread $THREAD like '$ARCHPATH/%' ;
exit

<<EOF

调用方法是在crontab里建两条如下内容:

0,20,40 * * * * . /home/oracle/.bash_profile;sh /gg/purge_archXnew.sh 1
0,20,40 * * * * . /home/oracle/.bash_profile;sh /gg/purge_archXnew.sh 2

删除RAC的两个节点的归档。

说明一下:配置了两个归档目录,一个归档目录给备份使用,归档直接备份,另一个归档目录OGG使用,归档删除由OGG决定。

3. crontab脚本不删除归档的原因

在数据库主机上的每个节点,都部署了杀长事务的脚本,为了安全考虑,该脚本不杀Oracle后台进程。
crontab脚本不删除归档了,表明OGG抽取进程的Recovery Checkpoint不往下走了,一般问题如下:

a.碰到后台进程长事务,杀长事务的脚本不杀后台进程
b.已经杀了会话,但需要长时间的回滚
c.挂起的分布式事务
d.某些异常原因,死事务不在回滚,抽取进程就是不跳过,需要手工跳过

检查发现,正好是第一条,后台进程m001有长事务

SQL> select a.ADDR,a.START_TIME,a.flag,b.program,b.username,b.sid, b.status,
  2         a.XIDUSN, a.XIDSLOT, a.XIDSQN 
  3  from v$session b ,v$transaction a 
  4  where a.ses_addr=b.saddr
  5  order by start_time desc;

ADDR             START_TIME                 FLAG PROGRAM               USERNAME  SID STATUS   XIDUSN XIDSLOT XIDSQN
---------------- -------------------- ---------- --------------------- -------- ---- -------- ------ ------- ------
00000029BED7D1F8 11/08/16 16:07:41       4199939 JDBC Thin Client      XXX_APP  7452 INACTIVE    593      12 265745
00000029C1EFCF48 11/08/16 16:07:28       4199939 JDBC Thin Client      XXX_APP  7526 INACTIVE    536      38 331207
00000029BEDDD950 11/08/16 16:07:23       4199939 JDBC Thin Client      XXX_APP  6356 INACTIVE    601       5 259960
00000029BB1076F0 11/08/16 16:07:22       4199939 JDBC Thin Client      XXX_APP  7588 INACTIVE    580      26 261219
00000029BEF61FD0 11/08/16 15:34:49       4199939 JDBC Thin Client      XXXXXXXX 6810 INACTIVE    643      11 171730
00000029BB208F88 11/08/16 15:31:04       4199939 JDBC Thin Client      XXXXXXXX 6050 INACTIVE    519      16 275325
00000029BCEEFF70 11/08/16 15:24:49       4199939 JDBC Thin Client      XXXXXXXX 7823 INACTIVE    621      47 243326
00000029C2F02220 11/08/16 15:14:49       4199939 JDBC Thin Client      XXXXXXXX 8270 INACTIVE    561      31 282062
00000029C1DA5928 11/08/16 15:04:49       4199939 JDBC Thin Client      XXXXXXXX 8418 INACTIVE    605       5 287960
00000029C1D66120 11/08/16 14:34:38       4199939 JDBC Thin Client      XXX_APP  6835 INACTIVE    524      21 269672
00000029BCF397A0 11/08/16 13:21:09       4199939 JDBC Thin Client      XXXXXXXX 6377 INACTIVE    637      47 285486
......
00000029C1D177C8 11/06/16 08:01:03       4199939 JDBC Thin Client      XXX_APP  7001 INACTIVE    589      38 205527
00000029C1E4F078 11/05/16 23:16:43      67116579 oracle@xxxxx02 (m001)          8273 ACTIVE      590       6 236583

其中m001进程是MMON的Slave进程,主要用于执行MMON分派的管理任务,如AWR快照、ADDM分析等,这个进程是可以在操作系统上杀的。

检查这个后台进程的等待事件,发现是XDB SGA initialization,

  SID USERNAME PROGRAM               MACHINE SQL_ID        SQL_CHILD_NUMBER EVENT                  STATUS P1 LAST_CALL_ET
 ---- -------- --------------------- ------- ------------- ---------------- ---------------------- ------ -- ------------
 8273          oracle@xxxxx02 (m001) xxxxx02                              0 XDB SGA initialization ACTIVE  0       233696

4. XDB SGA initialization等待事件的说明

根据 Session Hang with Wait Event “XDB SGA initialization” (文档 ID 1347989.1)

调用UTL_SMTP.open_connection,导致会话hang在XDB SGA initialization等待。
前期这个数据库因为安全检查,确实动过UTL_SMTP包的权限,具体如下:

revoke execute on utl_file from public;
revoke execute on DBMS_RANDOM from public;
revoke execute on UTL_HTTP from public;
revoke execute on UTL_SMTP from public;
revoke execute on UTL_TCP from public;

1347989.1解释,造成hang的原因是数据库启动时,LD_LIBRARY_PATH / LIBPATH / SHLIB_PATH等的环境变量设置有问题。
这个数据库在安全检查时,需要将remote_login_passwordfile设置为NONE,必须要重启数据库。
所以问题的原因可能是这两点:
a.动了UTL_SMTP包的权限
b.数据库重启时,环境变量不正确

5. 解决问题

将UTL_SMTP包的权限恢复,将m001进程杀掉,先让OGG的抽取进程Recovery Checkpoints下去,进而可以把归档清掉。
杀掉后又马上重新创建了m001进程,还是挂在XDB SGA initialization等待。

找了个合适的时间,将节点2数据库重启(当前是RAC环境,只有节点2的m001进程hang,所以只重启节点2)。
重启后,XDB SGA initialization等待没再出现。

关于紫砂壶

感悟技术人生
此条目发表在OWI分类目录,贴了标签。将固定链接加入收藏夹。