[转载]Oracle诊断案例-SGA与Swap之二(页 1) - 常用数据库类{ Database Security } - 巨人脚下[ Oracle ] - 邪恶八进制信息安全团队技术讨论组努力为祖国的信息安全撑起一片蓝天

pub!1c 2006-2-12 11:25

[转载]Oracle诊断案例-SGA与Swap之二

信息来源: 邪恶八进制信息安全团队
案例描述: 这是一个大型生产系统 问题出现时系统累计大量用户进程 用户请求得不到及时响应，新的进程不断尝试建立连接 连接数很快被用完 数据库版本:9.2.0.3 操作系统:Solaris8

pub!1c 2006-2-12 11:26

1.检查alert文件 日志中记录如下错误信息，说明磁盘异步IO出现问题: WARNING: aiowait timed out 2 times Tue Aug 26 15:33:32 2003 WARNING: aiowait timed out 2 times Tue Aug 26 15:33:34 2003 WARNING: aiowait timed out 2 times Tue Aug 26 15:33:36 2003 WARNING: aiowait timed out 2 times Tue Aug 26 15:33:38 2003 WARNING: aiowait timed out 2 times Tue Aug 26 15:33:43 2003 WARNING: aiowait timed out 1 times Tue Aug 26 15:33:46 2003 WARNING: aiowait timed out 1 times Tue Aug 26 15:33:49 2003 WARNING: aiowait timed out 1 times Tue Aug 26 15:33:51 2003 WARNING: aiowait timed out 1 times Tue Aug 26 15:33:52 2003 WARNING: aiowait timed out 1 times Tue Aug 26 15:33:53 2003 WARNING: aiowait timed out 1 times ............. 我们知道在SUN的某些版本上异步IO存在问题 而异步IO缺省是打开的 
<BLOCKQUOTE><PRE>代码:<HR><CODE>
 SQL> show parameter disk_a
 
 NAMETYPEVALUE
 ------------------------------------ ----------- ------------------------------
 disk_asynch_ioboolean'TRUE' </CODE><HR></PRE></BLOCKQUOTE> 针对此问题，我们停用了数据库的异步IO写入。

pub!1c 2006-2-12 11:26

2.共享内存问题 alert文件中还记录了以下错误信息: Tue Aug 26 21:37:40 2003 WARNING: EINVAL creating segment of size 0x0000000190400000 fix shm parameters in /etc/system or equivalent 该信息说明内核参数设置过小或者和SGA不匹配 我们检查system配置文件 $ cat /etc/system ....................... set shmsys:shminfo_shmmax=4096000000 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=200 set shmsys:shminfo_shmseg=200 set semsys:seminfo_semmap=1024 set semsys:seminfo_semmni=2048 set semsys:seminfo_semmns=2048 set semsys:seminfo_semmnu=2048 set semsys:seminfo_semume=200 set semsys:seminfo_semmsl=2048 我们发现最大共享内存设置仅有4G

pub!1c 2006-2-12 11:26

3.检查SGA设置 SQL*Plus: Release 9.2.0.3.0 - Production on 星期二 8月 26 21:46:35 2003 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.3.0 - Production SQL> show sga Total System Global Area 6695660272 bytes Fixed Size 740080 bytes Variable Size 2399141888 bytes Database Buffers 4294967296 bytes Redo Buffers 811008 bytes 我们发现SGA设置接近7G，这也就是步骤2中错误提示出现的原因

pub!1c 2006-2-12 11:27

4.交换区问题 我们用top工具检查系统运行状况 
<BLOCKQUOTE><PRE>代码:<HR><CODE>
 # /usr/local/bin/top
 
 last pid: 16899;load averages:0.82,0.81,0.8321:49:05
 1230 processes:1228 sleeping, 1 running, 1 on cpu
 CPU states: 50.1% idle,7.4% user,8.6% kernel, 33.9% iowait,0.0% swap
 Memory: 8192M real, 118M free, 12G swap in use, 11G swap free
 
 PID USERNAME THR PRI NICESIZERES STATETIMECPU COMMAND
 15751 oracle11440 6456M 6408M sleep0:020.49% oracle
 15725 oracle11580 6458M 6410M sleep0:020.46% oracle
 251 root12480 7096K 1944K sleep126:000.45% picld
 16540 oracle11580 6458M 6411M sleep0:010.45% oracle
 16766 root1430 3744K 2248K cpu/10:010.41% top
 16408 oracle11580 6457M 6410M sleep0:010.34% oracle
 15989 oracle11580 6458M 6409M sleep0:010.34% oracle
 15919 oracle11580 6457M 6409M sleep0:020.30% oracle
 16404 oracle11580 6457M 6409M sleep0:000.28% oracle
 16327 oracle11550 6457M 6410M sleep0:000.27% oracle
 14870 oracle11580 6457M 6412M sleep0:050.24% oracle
 16851 oracle11350 6457M 6411M sleep0:000.22% oracle
 16467 oracle11580 6457M 6409M sleep0:000.21% oracle
 16163 oracle11580 6457M 6408M sleep0:030.21% oracle
 ' 15159 oracle11580 6457M 6408M sleep0:050.21% oracle' </CODE><HR></PRE></BLOCKQUOTE> Memory: 8192M real, 118M free, 12G swap in use, 11G swap free 我们发现系统仅有8G RAM,物理内存仅有118M可用 现在SWAP区使用了12G 我们初步作出以下判断: SGA设置过大(将近7G)导致运行时产生大量交换 大量SWAP交换进而引发磁盘问题 这也就应该是我们第一步看到 WARNING: aiowait timed out 1 times 的原因 大量交换导致数据库性能急剧下降 进而导致用户请求得不到快速响应，堵塞、累积，直至数据库失去响应

pub!1c 2006-2-12 11:27

5.解决方案 此问题主要是由于SGA设置不当引起，我们马上缩小了SGA设置: SQL> show sga Total System Global Area 3591870848 bytes Fixed Size 735616 bytes Variable Size 1442840576 bytes Database Buffers 2147483648 bytes Redo Buffers 811008 bytes 此时，数据库减少了交换,达到了稳定运行,用户请求可以得到快速响应。 问题解决完成.

pub!1c 2006-2-12 11:27

6.系统状态 调整后系统运行状况: 
<BLOCKQUOTE><PRE>代码:<HR><CODE>
 $ top
 
 last pid: 12745;load averages:0.46,0.79,0.6522:22:49
 228 processes: 227 sleeping, 1 on cpu
 CPU states: 92.3% idle,5.0% user,1.6% kernel,1.1% iowait,0.0% swap
 Memory: 8192M real, 3817M free, 4015M swap in use, 15G swap free
 
 PID USERNAME THR PRI NICESIZERES STATETIMECPU COMMAND
 12610 oracle1510 3511M22M sleep0:041.96% oracle
 12595 oracle1480 3511M22M sleep0:030.92% oracle
 12630 oracle1380 3511M21M sleep0:010.84% oracle
 12614 oracle1460 3511M22M sleep0:010.64% oracle
 12620 oracle1580 3511M22M sleep0:010.53% oracle
 12709 oracle1480 3511M21M sleep0:000.45% oracle
 265 root11380 7032K 1920K sleep3:160.42% picld
 12729 oracle100 3511M20M sleep0:000.26% oracle
 12741 oracle1580 2768K 1760K cpu/30:000.19% top
 12745 oracle1440 3506M16M sleep0:000.17% oracle
 12711 oracle1480 3506M16M sleep0:000.11% oracle
 12738 oracle1430 3506M16M sleep0:000.06% oracle
 7606 oracle145017M 6928K sleep0:070.05% tnslsnr
 12721 oracle1340 3506M16M sleep0:000.05% oracle
 '12723 oracle1530 3506M16M sleep0:000.05% oracle' </CODE><HR></PRE></BLOCKQUOTE> 该系统调整完以后，一直稳定运行至今.

pub!1c 2006-2-12 11:27

小编一点总结: 这个案例和前面我提到的另外一个极其相似 同样都是SGA设置不当引起的数据库问题 本身并不复杂 这一类问题应该在数据库规划和建设阶段就避免掉. 其时，该问题对我更像是个心理测试 当所有老板都站在你背后的时候，你能否冷静快速的找到并解决问题. 关于SUN上的aiowait timed out 有很多总情况及诱因 我后面还有相应的案例说明 .

页: [1]

邪恶八进制信息安全团队技术讨论组's Archiver

[转载]Oracle诊断案例-SGA与Swap之二