eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« DBA手记:共享内存无法正常释放的处理 | Blog首页 | 海量数据库设计经验与研究交流会 - 通知 »

DBA手记:RAC环境下Memory System Deconfigured

这是客户的一个Oracle9iR2 RAC数据库环境,数据库版本为Oracle 9.2.0.8,主机为IBM P55a小型机。最初客户集群环境运行稳定,后来一台主机出现硬件故障退出集群,问题出现在主机维修完毕之后,当故障主机重新加入现有环境运行,客户发现应用性能出现衰减,前端收费系统响应缓慢,反而不如一个节点工作时的性能。

首先可以看一下这个系统的逻辑读变化曲线,图1-10清晰地显示在17日左右系统变成单节点运行后,逻辑读有了一个双倍的攀升变化,非常线性和清晰:

dbanb103.png

1-10 系统的逻辑读变化曲线

现在的问题是,两个节点运行反而不如当初的单节点运行,那么很有可能是新恢复运行的节点存在问题。登录该主机首先使用vmstat来收集系统信息,从以下摘要数据可以看到,系统的内存消耗殆尽,Page In/Out较高,同时Wait较高:

p55a1#vmstat 2

System configuration: lcpu=4 mem=1840MB

kthr    memory              page              faults        cpu   

----- ----------- ------------------------ ------------ -----------

 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa

 0  0 802203  2591   0  22  51  64  247   0 600 3182 1434  3  1 91  5

 0  3 802477  2776   0  38 151 345 1606   0 629 2509 1270  1  1 87 10

 0  1 801897  3098   0 207  76   0    0   0 910 3306 1762  3  2 74 22

 0  0 802229  2549   0 131  92 193  692   0 2138 12989 6000 10  6 69 15

 3  0 801876  2812   0  71  26   0    0   0 953 5782 2145 10  2 79  8

 1  1 801877  2814   0 139  95 141  503   0 1095 6617 2810 12  3 70 14

 0  2 801887  2546   0 128   0   0    0   0 780 3566 1909  5  2 79 14

 0  2 801883  3042   0 150 284 401 4301   0 1079 3067 1820  3  2 56 39

 0  1 802061  2532   0 162   0   0    0   0 1191 5444 2630  2  2 81 14

 1  1 802060  3193   0  51 270 381 2387   0 704 2468 977  3  1 77 18

 1  3 802535  2827   0 256 201 338 2011   0 975 2808 1624 11  2 51 36

 0  4 802852  2606   0 263 221 287 1535   0 1181 3217 2044  5  2 51 42

 1  2 802455  2838   0 339 166 258 1154   0 1181 4040 2181 13  2 47 37

通过topas可以做进一步的诊断,从图1-11的输出中同样可以看到类似数据,系统的I/O Wait较高,Paging频繁,而磁盘hdisk5hdisk6Busy程度达到了近100%

dbanb104.png

1-11 执行topas命令的输出

 

这说明由于主机的交换频繁导致了I/O负荷升高,从而导致了数据库响应缓慢。那么为什么会出现这种问题呢?内存的紧张和交换频繁直接和数据库的内存使用有关。

登录数据库,查看一下SGA设置就能够明白问题的原因所在(见如下代码):

p55a1$sqlplus "/ as sysdba"

 

SQL*Plus: Release 9.2.0.8.0 - Production on Tue Dec 2 10:34:20 2008

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

SQL> show sga

 

Total System Global Area 2031584960 bytes

Fixed Size                   743104 bytes

Variable Size             956301312 bytes

Database Buffers         1073741824 bytes

Redo Buffers                 798720 bytes

我们注意到数据库的SGA设置,分配了大约2GB的内存,而根据如下系统显示,主机配置的内存也仅为2GB

System configuration: lcpu=4 mem=1840MB

看来问题的原因已经找到,由于数据库的SGA设置过高,导致了过高的内存消耗,使得系统在业务繁忙时段产生了大量的交换,影响了系统性能。那么解决这个问题的方式是要么降低SGA,要么扩展系统内存。

但是还有一个问题,为什么以前一切是正常的,而机器修复后反而出现了问题呢?其实系统除了维修并未做其他数据库参数方面的变更。

适当猜测加上询问客户和查看记录就发现了进一步的原因,那就是在维修之前该主机共有4GB内存,维修之后只剩下了2GB,而客户并未主动变更过,那么显然还有故障存在在主机上(虽然errpt并未显示任何警告)。

在机房通过笔记本连接P55A小型机后端的HMC1口,通过浏览器连接主机,发现根本原因所在,原来是有两个内存被Deconfigured了(见图1-12):

dbanb105.png

1-12 Memory Deconfigration

也就是说可能这两条内存出现了故障,或者可能是内存插槽有问题,导致2GB的内存未被加载,这才是这次故障的根本原因。通过联系硬件厂商,解决了内存故障后,数据库系统恢复正常。


历史上的今天...
    >> 2015-03-02文章:
    >> 2010-03-02文章:
           ORA-00600 3020 错误案例一则
    >> 2009-03-02文章:
    >> 2008-03-02文章:
    >> 2007-03-02文章:
    >> 2006-03-02文章:
           搜索引擎 雅虎搜索
    >> 2005-03-02文章:

无觅

By eygle on 2011-03-02 08:24 | Comments (5) | Case | 2738 |

5 Comments

跟看小说一下的精彩

"图1-10清晰地显示在17日左右系统变成单节点运行后,逻辑读有了一个双倍的攀升变化,非常线性和清晰:"
其中的单节点,是不是要写成双节点

hoho 我家这点老故事~~~

老大的案例真是反复啊,我记得几年前就有个内存的问题了吧


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com