Oracle诊断案例2-SGA与Swap

案例描述:

这是一个大型生产系统

问题出现时系统累计大量用户进程

用户请求得不到及时响应，新的进程不断尝试建立连接

连接数很快被用完

数据库版本: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: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 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 有很多总情况及诱因