Oracle诊断案例-SGA与Swap之二

oracle

 

 

link:

http://www.eygle.com/case/sga2.htm

案例描述:

这是一个大型生产系统
问题出现时系统累计大量用户进程
用户请求得不到及时响应，新的进程不断尝试建立连接
连接数很快被用完

数据库版本:9.2.0.3
操作系统:Solaris8

 

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缺省是打开的

 

SQL> show parameter disk_a

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
disk_asynch_io boolean TRUE

 

针对此问题，我们停用了数据库的异步IO写入。

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

 

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中错误提示出现的原因

4.交换区问题

我们用top工具检查系统运行状况

 

# /usr/local/bin/top

last pid: 16899; load averages: 0.82, 0.81, 0.83 21: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 NICE SIZE RES STATE TIME CPU COMMAND
15751 oracle 11 44 0 6456M 6408M sleep 0:02 0.49% oracle
15725 oracle 11 58 0 6458M 6410M sleep 0:02 0.46% oracle
251 root 12 48 0 7096K 1944K sleep 126:00 0.45% picld
16540 oracle 11 58 0 6458M 6411M sleep 0:01 0.45% oracle
16766 root 1 43 0 3744K 2248K cpu/1 0:01 0.41% top
16408 oracle 11 58 0 6457M 6410M sleep 0:01 0.34% oracle
15989 oracle 11 58 0 6458M 6409M sleep 0:01 0.34% oracle
15919 oracle 11 58 0 6457M 6409M sleep 0:02 0.30% oracle
16404 oracle 11 58 0 6457M 6409M sleep 0:00 0.28% oracle
16327 oracle 11 55 0 6457M 6410M sleep 0:00 0.27% oracle
14870 oracle 11 58 0 6457M 6412M sleep 0:05 0.24% oracle
16851 oracle 11 35 0 6457M 6411M sleep 0:00 0.22% oracle
16467 oracle 11 58 0 6457M 6409M sleep 0:00 0.21% oracle
16163 oracle 11 58 0 6457M 6408M sleep 0:03 0.21% oracle
15159 oracle 11 58 0 6457M 6408M sleep 0:05 0.21% oracle

 

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
的原因

大量交换导致数据库性能急剧下降
进而导致用户请求得不到快速响应，堵塞、累积，直至数据库失去响应

 

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

此时，数据库减少了交换,达到了稳定运行,用户请求可以得到快速响应。

问题解决完成.

 

6.系统状态

调整后系统运行状况:

 

$ top last pid: 12745; load averages: 0.46, 0.79, 0.65 22:22:49228 processes: 227 sleeping, 1 on cpuCPU states: 92.3% idle, 5.0% user, 1.6% kernel, 1.1% iowait, 0.0% swapMemory: 8192M real, 3817M free, 4015M swap in use, 15G swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 12610 oracle 1 51 0 3511M 22M sleep 0:04 1.96% oracle 12595 oracle 1 48 0 3511M 22M sleep 0:03 0.92% oracle 12630 oracle 1 38 0 3511M 21M sleep 0:01 0.84% oracle 12614 oracle 1 46 0 3511M 22M sleep 0:01 0.64% oracle 12620 oracle 1 58 0 3511M 22M sleep 0:01 0.53% oracle 12709 oracle 1 48 0 3511M 21M sleep 0:00 0.45% oracle 265 root 11 38 0 7032K 1920K sleep 3:16 0.42% picld 12729 oracle 1 0 0 3511M 20M sleep 0:00 0.26% oracle 12741 oracle 1 58 0 2768K 1760K cpu/3 0:00 0.19% top 12745 oracle 1 44 0 3506M 16M sleep 0:00 0.17% oracle 12711 oracle 1 48 0 3506M 16M sleep 0:00 0.11% oracle 12738 oracle 1 43 0 3506M 16M sleep 0:00 0.06% oracle 7606 oracle 1 45 0 17M 6928K sleep 0:07 0.05% tnslsnr 12721 oracle 1 34 0 3506M 16M sleep 0:00 0.05% oracle 12723 oracle 1 53 0 3506M 16M sleep 0:00 0.05% oracle

该系统调整完以后，一直稳定运行至今.

 

一点总结:

这个案例和前面我提到的另外一个极其相似
同样都是SGA设置不当引起的数据库问题

本身并不复杂
这一类问题应该在数据库规划和建设阶段就避免掉.

其时，该问题对我更像是个心理测试
当所有老板都站在你背后的时候，你能否冷静快速的找到并解决问题.

关于SUN上的aiowait timed out 有很多总情况及诱因
我后面还有相应的案例说明 .

-Eygle

 

 

时间： 2025-01-21 16:05:56

Oracle诊断案例-SGA与Swap之二的相关文章

Oracle诊断案例-SGA与Swap之一

oracle     link: http://www.eygle.com/case/sga1.htm 案例描述: 用户报告,服务器启动一段时间以后,无法建立数据库连接重新启动几分钟以后,再次无法连接 系统无法正常使用. 1.登陆系统 SunOS 5.8 login: rootPassword: Last login: Tue Mar 23 13:56:59 from 172.16.31.41Sun Microsystems Inc. SunOS 5.8 Generic Patch Octobe

Oracle诊断案例----如何捕获问题SQL解决过度CPU消耗问题

oracle|解决|问题 Oracle诊断案例----如何捕获问题SQL解决过度CPU消耗问题 --使用vmstat,top等辅助解决Oracle数据库性能问题 Last Updated: Sunday, 2004-10-24 0:37 Eygle       问题描述:开发人员报告系统运行缓慢,影响用户访问. 1.登陆数据库主机 使用vmstat检查,发现CPU资源已经耗尽,大量任务位于运行队列: bash-2.03$ vmstat 3 procs memory page disk fault

Oracle诊断案例-Job任务停止执行

oracle|执行 Oracle诊断案例-Job任务停止执行 Last Updated: Saturday, 2004-11-20 12:47 Eygle         昨天接到研发人员报告,数据库定时任务未正常执行,导致某些操作失败. 开始介入处理该事故.系统环境:SunOS DB 5.8 Generic_108528-21 sun4u sparc SUNW,Ultra-4 Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

Oracle诊断案例-Job任务停止执行[最终版]

oracle|执行 Oracle诊断案例-Job任务停止执行 Last Updated: Friday, 2004-11-26 9:48 Eygle         昨天接到研发人员报告,数据库定时任务未正常执行,导致某些操作失败. 开始介入处理该事故.系统环境:SunOS DB 5.8 Generic_108528-21 sun4u sparc SUNW,Ultra-4 Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production 1.首

Oracle诊断案例-Spfile案例一则

oracle Oracle诊断案例-Spfile案例一则   link: http://www.eygle.com/case/spfile.htm 情况说明:系统:SUN Solaris8数据库版本:9203问题描述:工程人员报告,数据库在重新启动时无法正常启动.检查发现UNDO表空间丢失.问题诊断及解决过程如下:   1. 登陆系统检查alert.log文件 检查alert.log文件是通常是我们诊断数据库问题的第一步 SunOS 5.8 login: rootPassword: Last l

Oracle诊断案例-Sql

oracle link: http://www.eygle.com/case/sql_trace_1.htm 问题描述: 这是帮助一个公司的诊断案例.应用是一个后台新闻发布系统. 症状是,通过连接访问新闻页是极其缓慢通常需要十数秒才能返回. 这种性能是用户不能忍受的. 操作系统:SunOS 5.8数据库版本:8.1.7 1.检查并跟踪数据库进程 诊断时是晚上,无用户访问在前台点击相关页面,同时进行进程跟踪 查询v$session视图,获取进程信息   SQL> select sid,serial

Oracle诊断案例：Job任务停止执行

摘要: 本文通过一次Oracle Job任务异常案例诊断,分析其原因及解决过程,从内部揭示Oracle Job任务调度及内部计时机制. 问题及环境 接到研发人员报告,数据库定时任务未正常执行,导致某些操作失败. 开始介入处理该事故. 系统环境: 以下为引用的内容: SunOS DB 5.8 Generic_108528-21 sun4u sparc SUNW,Ultra-4Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production 解决过

《Oracle性能优化与诊断案例精选》导读

前言 Oracle性能优化与诊断案例精选数据驱动,成就未来最近两年来,很多朋友经常会问我,接下来会不会继续写书,会写一本什么样的书. 其实我也一直在思考,什么样的作品能够以最小的篇幅带来超越时间的价值,尽可能地帮助那些准备进入和刚刚进入这个领域的广大技术人员. 本书缘起2015年年底,我在成都和老熊聊天的时候,忽然有了一个想法,如果我能够将云和恩墨的专家团队聚集起来,让每个人都把自己最宝贵的经验方法.经典案例呈现出来,那累计超过100年的从业经验一定可以帮助很多人更深层次地了解数据库技术. 于是

《Oracle性能优化与诊断案例精选》——第2章 回首向来萧瑟处，也无风雨也无晴

第2章 回首向来萧瑟处,也无风雨也无晴 Oracle性能优化与诊断案例精选--我的十年Oracle DBA奋斗路(侯圣文) 题记 迄今为止,我觉得这辈子最幸运的两件事,一件是遇见了我太太,另一件就是结识了Oracle.没有早一步也没有晚一步,刚巧赶上了,在最适合谈恋爱的年纪谈了一场没有分手的恋爱,在最适合干事业的年纪做了一份不曾放弃的事业.