主题：RAC某节点v$asm_disk查询hang分析处理

环境：Oracle 11.2.0.3 RAC

故障描述：RAC环境2个节点，节点1查询v$asm_disk正常返回结果，节点2查询v$asm_disk就会一直hang，查询会话对应event是ASM file metadata operation.

1.初步判断

首先连接节点1，查询v$asm_disk没有问题：

  1. --节点1查询v$asm_disk都没有问题
  2. SQL> show parameter name
  3. SQL> select path from v$asm_disk;
  5. PATH
  6. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  7. /dev/oracleasm/disks/DATADISK
  8. /dev/oracleasm/disks/FRADISK
  9. /dev/oracleasm/disks/CRSDISK1
  10. /dev/oracleasm/disks/CRSDISK3
  11. /dev/oracleasm/disks/CRSDISK2

然后连接节点2，查询v$asm_disk就一直hang

  1. SQL> select path from v$asm_disk;
  2. hang住一直无结果返回..

故障重现，确认客户描述故障现场属实。

既然是hang住，自然去查该会话的等待事件是什么？是否有阻塞会话？

  1. SQL> select sid, serial#, inst_id, sql_id, event, p1,p2,p3, machine, username, blocking_session from gv$session where wait_class# <> 6;
  3.        SID    SERIAL#    INST_ID SQL_ID        EVENT                                       P1         P2         P3 MACHINE              USERNAME                       BLOCKING_SESSION
  4. ---------- ---------- ---------- ------------- ----------------------------------- ---------- ---------- ---------- -------------------- ------------------------------ ----------------
  6.       289      33911          2 b5tshv0auyqm0 ASM file metadata operation               6229          9          0 newdb2               SYS

发现等待事件是“ASM file metadata operation”，BLOCKING_SESSION为空，表明并没有阻塞会话。

此时查了下MOS，初步怀疑是asm_diskstring配置有问题，或是对应的磁盘权限有什么异常。但实际排查并未发现异常。

两个节点asm实例的参数设置都一样；对应目录下的磁盘等权限等也一致。

  1. 两个节点asm实例的参数设置都一样
  1. --节点1：
  2. SQL> show parameter asm
  4. NAME                                 TYPE        VALUE
  5. ------------------------------------ ----------- ------------------------------
  6. asm_diskgroups                       string      DATADG, FRADG, CRSDG_NEW
  7. asm_diskstring                       string      /dev/oracleasm/disks/*
  8. asm_power_limit                      integer     1
  9. asm_preferred_read_failure_groups    string
  10. SQL> 
  12. --节点2 一样的：
  13. SQL> show parameter asm
  15. NAME                                 TYPE        VALUE
  16. ------------------------------------ ----------- ------------------------------
  17. asm_diskgroups                       string      DATADG, FRADG, CRSDG_NEW
  18. asm_diskstring                       string      /dev/oracleasm/disks/*
  19. asm_power_limit                      integer     1
  20. asm_preferred_read_failure_groups    string
  1. 对应目录下的磁盘等权限等也一致
  1. [grid@newdb1 ~]$ ls -l /dev/oracleasm/disks/
  2. total 0
  3. brw-rw---- 1 grid asmadmin 253, 11 Jan 29 15:05 CRSDISK1
  4. brw-rw---- 1 grid asmadmin 253,  9 Jan 29 15:05 CRSDISK2
  5. brw-rw---- 1 grid asmadmin 253, 10 Jan 29 15:05 CRSDISK3
  6. brw-rw---- 1 grid asmadmin 253, 14 Jan 29 15:05 DATADISK
  7. brw-rw---- 1 grid asmadmin 253, 13 Jan 29 15:05 FRADISK
  8. [grid@newdb1 ~]$ 
  10. [grid@newdb2 ~]$ ls -l /dev/oracleasm/disks/
  11. total 0
  12. brw-rw---- 1 grid asmadmin 253, 21 Jan 29 15:05 CRSDISK1
  13. brw-rw---- 1 grid asmadmin 253, 18 Jan 29 15:05 CRSDISK2
  14. brw-rw---- 1 grid asmadmin 253, 19 Jan 29 15:05 CRSDISK3
  15. brw-rw---- 1 grid asmadmin 253, 22 Jan 29 15:05 DATADISK
  16. brw-rw---- 1 grid asmadmin 253, 20 Jan 29 15:05 FRADISK

2.深入分析

在故障节点2上使用oradebug获取short_stack以及SSD 266，然后进行深入分析。

首先获取上面289,33911会话的spid：

select p.spid

from v$process p, v$session s

where p.addr = s.paddr

and s.sid = &sid

and s.serial# = &serial;

  1. SQL> select p.spid
  2.   2    from v$process p, v$session s
  3.   3   where p.addr = s.paddr
  4.   4     and s.sid = &sid
  5.   5     and s.serial# = &serial;
  6. Enter value for sid: 289
  7. old   4:    and s.sid = &sid
  8. new   4:    and s.sid = 289
  9. Enter value for serial: 33911
  10. old   5:    and s.serial# = &serial
  11. new   5:    and s.serial# = 33911
  13. SPID
  14. ------------------------
  15. 8763
  17. SQL> !ps -ef|grep 8763
  18. oracle    8763  8762  0 16:31 ?        00:00:00 oraclenewdb2 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
  19. grid      9639     1  0 16:35 ?        00:00:00 oracle+ASM2_user8763_newdb2 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
  20. oracle   12022  9750  0 16:43 pts/2    00:00:00 /bin/bash -c ps -ef|grep 8763
  21. oracle   12024 12022  0 16:43 pts/2    00:00:00 grep 8763

然后使用oradebug 跟踪8763进程，获取short_stack和SSD 266：

  1. SQL> oradebug setospid 8763
  2. Oracle pid: 68, Unix process pid: 8763, image: oracle@newdb2 (TNS V1-V3)
  3. SQL> oradebug unlimit
  4. Statement processed.
  5. SQL> oradebug short_stack
  6. ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-read()+14<-ntpfprd()+115<-nsbasic_brc()+376<-nsbrecv()+69<-nioqrc()+485<-ttcdrv()+1461<-nioqwa()+61<-upirtrc()+1385<-kpurcsc()+98<-kpuexec()+10807<-OCIStmtExecute()+39<-kfdDskTableCb4Db()+4492<-kfdDskTableCbInternal()+301<-kfdDskTableCb()+56<-qerfxFetch()+2210<-rwsfcd()+103<-qerhjFetch()+3187<-opifch2()+2995<-kpoal8()+2939<-opiodr()+916<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+253<-_start()+36
  7. SQL> oradebug dump systemstate 266
  8. Statement processed.
  9. SQL> oradebug tracefile_name
  10. /home/app/oracle/diag/rdbms/newdg/newdb2/trace/newdb2_ora_8763.trc
  11. SQL>

从获取到的trc文件中，并没有找到有用的线索。至此问题陷入僵局。

3.峰回路转

回过头来想之前的解决过程，发现虽然查询v$asm_disk这类操作是在db层，但是本质确实asm实例的管理资源，去查asm实例是否有阻塞呢？

  1. --ASM INSTANCE
  2. set lines 350 trimspool on pages 300
  4. select sid, state, event, seconds_in_wait, blocking_session
  5. from   v$session
  6. where  blocking_session is not null
  7. or sid in (select blocking_session
  8.            from   v$session
  9.            where  blocking_session is not null)
  10. order by sid;

在故障节点2的asm实例上查询：

  1. SQL> set lines 350 trimspool on pages 300
  2. SQL>
  3. SQL> select sid, state, event, seconds_in_wait, blocking_session
  4.   2  from   v$session
  5.   3  where  blocking_session is not null
  6.   4  or sid in (select blocking_session
  7.   5             from   v$session
  8.   6             where  blocking_session is not null)
  9.   7  order by sid;
  11.        SID STATE               EVENT                                                            SECONDS_IN_WAIT BLOCKING_SESSION
  12. ---------- ------------------- ---------------------------------------------------------------- --------------- ----------------
  13.        128 WAITING             enq: DD - contention                                                      542311             1702
  14.        380 WAITING             enq: DD - contention                                                     2159938             1702
  15.        442 WAITING             enq: DD - contention                                                     2159098             1702
  16.        506 WAITING             enq: DD - contention                                                     2158258             1702
  17.        569 WAITING             enq: DD - contention                                                      713509             1702
  18.        632 WAITING             enq: DD - contention                                                     2156578             1702
  19.        695 WAITING             enq: DD - contention                                                     2155738             1702
  20.        758 WAITING             enq: DD - contention                                                     1108924             1702
  21.        821 WAITING             enq: DD - contention                                                     2142990             1702
  22.        884 WAITING             enq: DD - contention                                                     2139901             1702
  23.        947 WAITING             enq: DD - contention                                                     2136286             1702
  24.       1010 WAITING             enq: DD - contention                                                     2078621             1702
  25.       1073 WAITING             enq: DD - contention                                                     1845020             1702
  26.       1135 WAITING             GPnP Get Item                                                            2161258
  27.       1136 WAITING             enq: DD - contention                                                     1844671             1702
  28.       1199 WAITING             enq: DD - contention                                                     1844394             1702
  29.       1263 WAITING             enq: DD - contention                                                     1844065             1702
  30.       1325 WAITING             enq: DD - contention                                                     1843549             1702
  31.       1388 WAITING             enq: DD - contention                                                     1471932             1702
  32.       1451 WAITING             enq: DD - contention                                                     1641694             1702
  33.       1514 WAITING             enq: DD - contention                                                     1641426             1702
  34.       1577 WAITING             enq: DD - contention                                                     1572189             1702
  35.       1640 WAITING             enq: DD - contention                                                     1501765             1702
  36.       1702 WAITING             rdbms ipc reply                                                                0             1135
  37.       1703 WAITING             enq: DD - contention                                                      896552             1702
  38.       1765 WAITING             enq: DD - contention                                                     2161018             1702
  39.       1766 WAITING             enq: DD - contention                                                      893474             1702
  40.       1829 WAITING             enq: DD - contention                                                       11782             1702
  41.       1892 WAITING             enq: DD - contention                                                        5041             1702
  42.       1955 WAITING             enq: DD - contention                                                        3357             1702
  44. 30 rows selected.

果然看到很多阻塞，EVENT为"enq: DD - contention"的都是被1702会话阻塞，而1702会话又是被1135会话阻塞，1135会话的event是"GPnP Get Item"。

看两个会话的详细信息：

  1. select sid,
  2.        SERIAL#,
  3.        sql_id,
  4.        event,
  5.        MACHINE,
  6.        PROGRAM,
  7.        username,
  8.        blocking_session from   v$session where sid = 1702; 
  10. select sid,
  11.        SERIAL#,
  12.        sql_id,
  13.        event,
  14.        MACHINE,
  15.        PROGRAM,
  16.        username,
  17.        blocking_session from   v$session where sid = 1135;

结果如下：

  1. SQL> select sid,
  2.   2         SERIAL#,
  3.   3         sql_id,
  4.   4         event,
  5.   5         MACHINE,
  6.   6         PROGRAM,
  7.   7         username,
  8.   8         blocking_session from   v$session where sid = 1702; 
  10.        SID    SERIAL# SQL_ID        EVENT                                                            MACHINE                                                          PROGRAM                                       USERNAME                BLOCKING_SESSION
  11. ---------- ---------- ------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ------------------------------------------------ ------------------------------ ----------------
  12.       1702      15127 b8a2pdbq3p2mj rdbms ipc reply                                                  newdb2                                                           oracle@newdb2 (TNS V1-V3)                     SYS                                         1135
  14. SQL>  select sid,
  15.   2         SERIAL#,
  16.   3         sql_id,
  17.   4         event,
  18.   5         MACHINE,
  19.   6         PROGRAM,
  20.   7         username,
  21.   8         blocking_session from   v$session where sid = 1135; 
  23.        SID    SERIAL# SQL_ID        EVENT                                                            MACHINE                                                          PROGRAM                                       USERNAME                BLOCKING_SESSION
  24. ---------- ---------- ------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ------------------------------------------------ ------------------------------ ----------------
  25.       1135          1               GPnP Get Item                                                    newdb2                                                           oracle@newdb2 (RBAL)

找到最终的原因：GPnP Get Item .

4.解决问题

有了上面的信息，再次查询MOS就可以匹配到
- Diskgroup Mount Hangs with RBAL Waiting on 'GPnP Get Item' and 'enq: DD - contention' (文档 ID 1375505.1)
- "crsctl check cluster -all" command gives CRS-4404, CRS-4405 errors (文档 ID 1392934.1)

参照MOS解决方案：

  1. Use the following command as root on Compute Node 3 to identify the current gpnpd.bin process:

    ps -ef | grep gpnpd.bin

This will give you an output similar to:

ps -ef | grep pnp

oracle 31422 1 0 2011 ? 00:05:40 /u01/app/11.2.0.2/grid/bin/gpnpd.bin

Please note the process ID number of the current gpnpd.bin process. In this example, = 31422

  1. Use the following command on Compute Node 3 to stop the current gpnpd.bin process:

    kill -HUP

    for example, kill -HUP 31422

  2. After a few moments, gpnpd.bin should be automatically restarted by GI, run the command from step # 1 to verify that a new gpnpd.bin process exists

实际操作如下：

  1. [root@newdb2 dev]# ps -ef | grep gpnpd.bin
  2. grid      9835     1  0  2017 ?        00:23:19 /home/app/11.2.0/grid/bin/gpnpd.bin
  3. root     26300 28772  0 17:43 pts/0    00:00:00 grep gpnpd.bin
  4. [root@newdb2 dev]# kill -HUP  9835
  5. You have mail in /var/spool/mail/root
  6. [root@newdb2 dev]#
  7. [root@newdb2 dev]# ps -ef | grep gpnpd.bin
  8. grid     26740     1  1 17:45 ?        00:00:00 /home/app/11.2.0/grid/bin/gpnpd.bin
  9. root     26762 28772  0 17:45 pts/0    00:00:00 grep gpnpd.bin
  10. [root@newdb2 dev]# su - grid
  11. [grid@newdb2 ~]$ sqlplus / as sysasm
  13. SQL*Plus: Release 11.2.0.3.0 Production on Mon Jan 29 17:46:02 2018
  15. Copyright (c) 1982, 2011, Oracle.  All rights reserved.
  17. Connected to:
  18. Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
  19. With the Real Application Clusters and Automatic Storage Management options
  21. SQL> set lines 350 trimspool on pages 300
  22. SQL>
  23. SQL> select sid, state, event, seconds_in_wait, blocking_session
  24.   2  from   v$session
  25.   3  where  blocking_session is not null
  26.   4  or sid in (select blocking_session
  27.   5             from   v$session
  28.   6             where  blocking_session is not null)
  29.   7  order by sid;
  31. no rows selected
  33. SQL> select path from v$asm_disk;
  35. PATH
  36. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  37. /dev/oracleasm/disks/FRADISK
  38. /dev/oracleasm/disks/DATADISK
  39. /dev/oracleasm/disks/CRSDISK3
  40. /dev/oracleasm/disks/CRSDISK2
  41. /dev/oracleasm/disks/CRSDISK1
  43. SQL>

至此，故障节点的ASM实例的阻塞消失，再次验证查询v$asm_disk已经恢复正常，故障算是完美解决。

后记：

  • 1.实际上起初的解决思路出现偏差，ASM的问题就应该直接从ASM实例找原因，而之前都是在DB层分析，自然没有得到好的结果。这一点很值得自己反思。
  • 2.最开始接到这个case是建议找停机时间直接重启节点2，这个方案简单粗暴且不需要深入分析问题，从最终解决方案看到，这种方法也是可以解决问题的。但恰恰由于客户坚持不能重启，反倒因此而学到了更多的技能点。

RAC某节点v$asm_disk查询hang分析处理的更多相关文章

  1. Oracle Hang分析--转载

    1. 数据库hang的几种可能性 oracle 死锁 或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住,比如大量的DX锁. 通常来说,我们所指的系统hang住,是指应用无响 ...

  2. RAC 某节点不可用时，对应VIP是否可用

    实验环境:RHEL 6.5 + GI 11.2.0.4 + Oracle 11.2.0.4 验证:RAC 某节点不可用时,其对应VIP是否可用?是否可用于连接数据库? [grid@jyrac2 ~]$ ...

  3. Mysql慢查询和慢查询日志分析

     Mysql慢查询和慢查询日志分析   众所周知,大访问量的情况下,可添加节点或改变架构可有效的缓解数据库压力,不过一切的原点,都是从单台mysql开始的.下面总结一些使用过或者研究过的经验,从配置以 ...

  4. [转]Oracle hang分析

    hanganalyze是ORACLE的一款性能诊断工具,这个款工具是从oracle 8.0.6开始可用,在oracle数据库出现严重的性能问题的时候它可以帮助你定位问题所在. 1.首先说说hangan ...

  5. Druid：一个用于大数据实时处理的开源分布式系统——大数据实时查询和分析的高容错、高性能开源分布式系统

    转自:http://www.36dsj.com/archives/28590 Druid 是一个用于大数据实时查询和分析的高容错.高性能开源分布式系统,旨在快速处理大规模的数据,并能够实现快速查询和分 ...

  6. Hudi 数据湖的插入，更新，查询，分析操作示例

    Hudi 数据湖的插入,更新,查询,分析操作示例 作者:Grey 原文地址: 博客园:Hudi 数据湖的插入,更新,查询,分析操作示例 CSDN:Hudi 数据湖的插入,更新,查询,分析操作示例 前置 ...

  7. [NHibernate]N+1 Select查询问题分析

    目录 写在前面 文档与系列文章 N+1 Select查询问题分析 总结 写在前面 在前面的文章(延迟加载,立即加载)中都提到了N+1 Select的问题,总觉得理解的很不到位,也请大家原谅,这也是为什 ...

  8. MySQL 慢查询日志分析及可视化结果

    MySQL 慢查询日志分析及可视化结果 MySQL 慢查询日志分析 pt-query-digest分析慢查询日志 pt-query-digest --report slow.log 报告最近半个小时的 ...

  9. Oracle 11g RAC 第二节点root.sh执行失败后再次执行root.sh

    Oracle 11g RAC 第二节点root.sh执行失败后再次执行root.sh前,要先清除之前的crs配置信息 # /u01/app/11.2.0/grid/crs/install/rootcr ...

随机推荐

  1. svn conflict 冲突解决

    1. 同一处修改文件冲突 开发人员都知道代码管理工具是开发中一个必不可少的工具,这里也不废话详细介绍了.不管你个人喜欢git还是svn还是其他,但还有一大部分公司在使用svn做代码管理工具.这里详细介 ...

  2. MapReduce工作原理流程简介

    在MapReduce整个过程可以概括为以下过程: 输入 --> map --> shuffle --> reduce -->输出 输入文件会被切分成多个块,每一块都有一个map ...

  3. win10安装Tensorflow

    win10安装Tensorflow 前提: 保证你的pip>=8.1版本 否则利用python -m pip install -U pip  进行升级,或下载pip源文件 确定你的显卡是否支持c ...

  4. 【AC自动机】Lougu P3796

    题目描述 有NNN个由小写字母组成的模式串以及一个文本串TTT.每个模式串可能会在文本串中出现多次.你需要找出哪些模式串在文本串TTT中出现的次数最多. 输入输出格式 输入格式: 输入含多组数据. 每 ...

  5. SLAVE为什么一直不动了

    导读 遇到SLAVE延迟很大,binlog apply position一直不动的情况如何排查? 问题描述 收到SLAVE延迟时间一直很大的报警,于是检查一下SLAVE状态(无关状态我给隐去了):   ...

  6. 扒一扒offsetleft，srollleft，pagex，clientx，postion().left等精确位置的获取与理解

    先上个pc端和手机端的图:   说明:上面的属性,都是in这个div的属性值.我是点击的in这个div的左上角,所以pageX.pageY是40. HTML: <div class=" ...

  7. HashSet源码阅读

    HashSet的实现基于HashMap 看几个简单的初始化方法 public HashSet() { map = new HashMap<>(); } public HashSet(Col ...

  8. 转- 在ubuntu下安装Nginx

    一. 安装包安装 1.1 安装Nginx $sudo apt-get install nginx Ubuntu安装之后的文件结构大致为: 所有的配置文件都在/etc/nginx下,并且每个虚拟主机已经 ...

  9. Windows10 环境下安装 ElasticSearch

    环境与版本 操作系统:windows 10 Elasticsearch 版本:6.1.1 Java 版本:9.0.1 ik 分词器版本:6.1.1 安装步骤 前置要求 操作系统中需要安装有 java ...

  10. Android基础_ContentProvider组件

    一.了解Contentprovider组件 1.1Contentprovider是数据的提供者,Android四大组件之一,程序之间数据共享的接口 1.2activity系统中对数据的访问限制十分严格 ...