RAC数据库无法生成AWR信息

xsbuqun

现在一个项目有5套RAC数据库，配置一样：
操作系统：redhat 5.5  64bit
CRS       : 10.2.0.5
ORACLE: 10.2.0.5
节点数：2
内存：64G
SGA：32G
PGA:   8G
建库时间：2011-09-17

现在都在正常运营中。
目前只有一套库是正常生成AWR报告信息，有一套库时不时的能生成，其他的都不会生成，查询dba_hist_snapshot视图即可看出

对无法生成AWR信息的数据库，查看mmon进程和mmnl进程对应的trc文件及两个实例的后台进程，见附件
实例1中mmon的trc文件名为mmon_1.log，实例2中mmon的trc文件名为mmon_2.log
实例1中mmnl的trc文件名为mmnl_1.log，实例2中mmnl的trc文件名为mmnl_2.log
实例1中后台进程列表的文件名为ora_进程_1.txt，实例2中后台进程列表的文件名为ora_进程_2.txt

查询数据库当前的锁定对象，查询结果见附件（locked_objects_1.txt）

对集群做了个hanganalyze
SQL>  oradebug setmypid
Statement processed.
SQL> oradebug setinst all;
Statement processed.
SQL> oradebug -g def hanganalyze 4
生成文件见附件(hanganalyze_rac.trc)

dump出两个实例的 systemstate
alter session set events 'immediate trace name systemstate level 266';
实例1生成文件见附件(systemstate_266_1.trc)
实例2生成文件见附件(systemstate_266_1.trc)


现在如果把实例1中的m000进程杀掉，又会出现一个m000进程，再杀掉这个进程，那么实例2就会马上生成一个快照，实例1不会生成。但是下个小时又是这样，需要反复的杀才能让第二个实例生成快照，第一个一直没办法生成
实例2之前有重启过，最近实例1有重启
SQL> select instance_number,to_char(startup_time,'yyyy-mm-dd') from gv$instance;

INSTANCE_NUMBER TO_CHAR(ST
--------------- ----------
              2 2012-12-28
              1 2013-03-06

并且用sys用户通过plsql developer登录时，会提示
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Dynamic Performance Tables not accessible,
Automatic Statistics disabled for this session

You can disable statistics in the preference menu,
or obtain select priviliges on the v$session,v$sesstat and v$statname tables
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

大家看看，问题出在哪了？

xsbuqun

这里是通过杀掉实例1的m000进程后，实例2生成的awr报告，见附件

Maclean Liu(刘相兵

select max(BEGIN_INTERVAL_TIME),INSTANCE_NUMBER from dba_hist_snapshot group by INSTANCE_NUMBER;

这个先查一下

xsbuqun

select max(BEGIN_INTERVAL_TIME),INSTANCE_NUMBER from dba_hist_snapshot group by INSTANCE_NUMBER;

MAX(BEGIN_INTERVAL_TIME)                 INSTANCE_NUMBER
---------------------------------------- ---------------
14-MAR-13 06.00.01.493 PM                              2

donyorcl001

曾经遇到过一个案例，mmon及其slave进程down，导致awr不能生成的案例。

Maclean Liu(刘相兵

                    Resource Holder State
    Enq WF-0000000F-00000000   282: waiting for 'gc cr request'
       
       
                    Resource Holder State
    Enq WF-0000000F-00000000   282: waiting for 'gc cr request'
       
       
          SO: 0x8565cec78, type: 4, owner: 0x8533e0558, flag: INIT/-/-/0x00
    (session) sid: 1534 trans: (nil), creator: 0x8533e0558, flag: (100051) USR/- BSY/-/-/-/-/-
              DID: 0001-011A-000008D8, short-term DID: 0001-011A-000008D9
              txn branch: (nil)
              oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
    service name: SYS$BACKGROUND
    waiting for 'gc cr request' wait_time=0, seconds since wait started=0
                file#=3, block#=ee33, class#=1
                blocking sess=0x(nil) seq=56648
    Dumping Session Wait History
     for 'cr request retry' count=1 wait_time=0.000006 sec
                file#=3, block#=ee33, =0
     for 'gc cr block lost' count=1 wait_time=1.525353 sec
                =3, =ee33, =1
     for 'cr request retry' count=1 wait_time=0.000014 sec
                file#=3, block#=ee33, =0
     for 'gc cr block lost' count=1 wait_time=0.938301 sec
                =3, =ee33, =1
     for 'cr request retry' count=1 wait_time=0.000017 sec
                file#=3, block#=ee33, =0
     for 'gc cr block lost' count=1 wait_time=0.920432 sec


执行以下下面几个命令 并处给输出 ，2个节点上的都需要

ifconfig -a

netstat -s
netstat -in        

xsbuqun

ifconfig等执行结果

xsbuqun

OMP-ACS-DB1 /oracle>cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
#Public
10.46.51.195   OMP-ACS-DB1 OMP-ACS-DB1.localdomain
10.46.51.197   OMP-ACS-DB2 OMP-ACS-DB2.localdomain
#Virtual
10.46.51.196   OMP-ACS-DB1-vip.localdomain    OMP-ACS-DB1-vip
10.46.51.198   OMP-ACS-DB2-vip.localdomain    OMP-ACS-DB2-vip
#Private
192.168.0.10   OMP-ACS-DB1-priv.localdomain   OMP-ACS-DB1-priv
192.168.0.11   OMP-ACS-DB2-priv.localdomain   OMP-ACS-DB2-priv

#Private
192.168.10.10   OMP-ACS-DB1-priv2.localdomain   OMP-ACS-DB1-priv2
192.168.10.11   OMP-ACS-DB2-priv2.localdomain   OMP-ACS-DB2-priv2

Maclean Liu(刘相兵

Udp:
    3377233701 packets received
    596617 packets to unknown port received.
    198 packet receive errors
    3410997744 packets sent


eth0      Link encap:Ethernet  HWaddr E4:1F:13:80:39:FD  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::e61f:13ff:fe80:39fd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4648778870 errors:1 dropped:0 overruns:0 frame:1

eth0       1500   0 4648781935      1      0      0 4606149813      0      0      0 BMRU


eth0  是private network interface 吗？

就这个信息看有部分 udp 丢包

做一个测试,找一张大表 从dba_segments 里， 大于1GB 但也别太大

set timing on;
先在1节点上  select count(*)  from 大表;

之后在2节点上  select count(*)  from 大表;

对比以下时间 ，可以的话 对上面做一个10046 level 8 trace

xsbuqun

表名                   表大小  记录条数    实例1执行时间                               实例2执行时间
TB_API_REQUEST_LOG     1.6G    1679045     300秒后通过杀进程终止(gc cr request)    00:01:05.66  
TB_COURTESY_LOG        370M    601398      00:00:11.13                             00:00:08.98   
TB_ARTICLE_CONTENT     690M    172813      200秒后通过杀进程终止(gc cr request)           00:00:15.92
TB_ERROR_LOG           600M    2959560            00:00:13.87                                                           00:00:00.98       

Maclean Liu(刘相兵

考虑检查网络设备 包括 NIC 和 交换机 ， 或者 考虑先停一个实例吧

不了峰

我也遇到过类似的问题
1.在手动收集awr报告,无法完成. 跟踪发现 产生大量cr request retry 等待事件.

2通过oswbb跟踪nestat -s 看到,发现如果
packet reassembles failed 这个值没有增加,awr报告就会收集得了.

最综我只做到一这层面, 网络方的说网络没有问题 ,交换机也没有错误日志.所以事情就这样挂着

xsbuqun

该怎么去检查网络，用什么方法，看哪些信息和指标?

Maclean Liu(刘相兵

xsbuqun 发表于 2013-3-21 20:02
该怎么去检查网络，用什么方法，看哪些信息和指标?

视乎不同的 操作系统 、网络设备 不同的查法。

黑盒测试的话： 找一个大的文件 使用问题 网络接口 在2边对传  并监控netstat 等信息，当然这样做 未必100%能模拟出问题来

还有就是做ping大包的 监控，部署一个ping大包的脚本

fzs731215

我以前遇到过类似问题，主要是和心跳网络有关，后来将心跳网络采用单独一台千兆交换机上，和生产网络隔离开，就ok了。

fzs731215

采用osw工具来测试网络

cargoo

遇到过核心交换机的模块有问题，看着是好的，但时不时出现瞬断

xsbuqun

现在在一个节点上查询一个分区表，按request_time 字段做的分区，每天一个分区
select count(1)from TB_ACCOUNT_INTERFACE_LOG_1
where request_time between to_date('20130306','yyyymmdd') and to_date('20130306','yyyymmdd')
一直在执行中，400多秒都没执行完，等待事件一直是gc cr multi block request
通过v$active_session_history视图统计该会话的事件
SELECT event,count(1) FROM v$active_session_history
where session_id=1161
group by event;

event                                         count(1)
----------------------------------------------
                                                  3
gc cr block lost                                 29
control file sequential read                   2
null event                                           1
enq: WF - contention                           2
gc cr multi block request                  122

通过netstat -s
发现packet reassembles failed增长很快
两次执行结果如下(间隔10秒左右)
OMP-ACS-DB1 /oracle>netstat -s | sed -n '1,15'p
Ip:
    3100491783 total packets received
    359 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    1201940984 incoming packets delivered
    2920347366 requests sent out
    1746 outgoing packets dropped
    118174 fragments dropped after timeout
    2441061215 reassemblies required
    543538738 packets reassembled ok
    50465402 packet reassembles failed
    577259781 fragments received ok
    2370410786 fragments created
Icmp:

OMP-ACS-DB1 /oracle>netstat -s | sed -n '1,15'p
Ip:
    3100580387 total packets received
    359 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    1202012312 incoming packets delivered
    2920409855 requests sent out
    1746 outgoing packets dropped
    118174 fragments dropped after timeout
    2441081839 reassemblies required
    543542086 packets reassembled ok
    50466193 packet reassembles failed
    577261427 fragments received ok
    2370416109 fragments created
Icmp:

这些可能是哪个地方出了问题，网络测试，ping没发现问题，2000次ping也没丢失1个

Maclean Liu(刘相兵

还是 交换机和网卡 这2块

xsbuqun

OMP-ACS-DB1 /oracle>ping -s 65500 192.168.0.11
PING 192.168.0.11 (192.168.0.11) 65500(65528) bytes of data.
65508 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=1.68 ms
65508 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=1.49 ms
65508 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=1.48 ms
65508 bytes from 192.168.0.11: icmp_seq=4 ttl=64 time=1.48 ms
65508 bytes from 192.168.0.11: icmp_seq=5 ttl=64 time=1.53 ms

Maclean Liu(刘相兵

光看一个ping 无意义的， 建议你换 个交换机试试

yobyin

我也遇到过一次，不过是OS 的bug ，升级了OS后就可以了，

xsbuqun

现在网络人员到机房看了看，把几条私有网络的网线水晶头按了按，有一台数据库服务器的 packet reassembles failed不再增长，其他的数据库服务器 packet reassembles failed数量还是增长的很厉害，现在换交换机很难(组长不太相信交换机的问题，且动起来也会比较麻烦)，项目组长怀疑水晶头出了问题，那几条网线长度约15米(数据库和交换机隔了2个机架，再加布线需要的长度)，网络人员怀疑是网线太长的原因，目前还在进一步处理中

不了峰

xsbuqun 发表于 2013-3-28 17:30
现在网络人员到机房看了看，把几条私有网络的网线水晶头按了按，有一台数据库服务器的 packet reassembles  ...

”有一台数据库服务器的 packet reassembles failed不再增长“
这台的awr能收了不？

关注～

xsbuqun

还不能生成awr，因为另外一台的 packet reassembles failed还在不断增长

xsbuqun

yobyin 发表于 2013-3-28 17:25
我也遇到过一次，不过是OS 的bug ，升级了OS后就可以了，

你的os是什么系统和版本，怎么升级的，说出来参考一下