2017-04-30 DBA日记，由于大量换页，swap空间不足系统挂起

背景：

今天，接到用户反馈，数据库DB1连接不上，需我进行排查及恢复，经过初步诊断后，发现在09:28分由于swap空间不足令操作系统挂起，数据库没有响应，采用紧急恢复手段，重启操作系统，恢复使用。

问题：

是什么原因令操作系统的swap空间不足呢？

分析：

1）当前的SWAP空间是16G,物理内存是64G，数据库分配约59G

2）故障发生时，当前数据库进行了什么操作呢？

Top Service/Module               DB/Inst: ODRPT/odrpt  (Apr 30 09:25 to 09:26)

Service        Module                  % Activity Action               % Action

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

SYS$USERS      DBMS_SCHEDULER                86.71 JOB$_1785776             3.47

                                                  JOB$_1785793             3.47

                                                JOB$_1785794             3.47

SYS$BACKGROUND UNNAMED                        6.36 UNNAMED                  6.36

SYS$USERS      PL/SQL Developer               3.47 SQL Window - ??        3.47

   plsqldev.exe                   3.47 UNNAMED                  3.47

Top User Events                  DB/Inst: ODRPT/odrpt  (Apr 30 09:25 to 09:26)

                                                                                   Avg Active

Event                               Event Class        % Event      Sessions

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

CPU + Wait for CPU                  CPU                  45.66      13.17

db file scattered read              User I/O             33.53       9.67

read by other session               User I/O              6.36       1.83

db file sequential read             User I/O              2.31       0.67

local write wait                User I/O              2.31       0.67

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

                                         Distinct            Avg Active

SQL Command Type                             SQLIDs % Activity   Sessions

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

INSERT                                           23      76.88      22.17

SELECT                                            3       7.51       2.17

TRUNCATE TABLE                                    3       5.78       1.67

CREATE INDEX                                      1       2.89       0.83

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

Top Call Types                   DB/Inst: ODRPT/odrpt  (Apr 30 09:25 to 09:26)

Call Type                                     Count % Activity Avg Active

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

FETCH                                            6       3.47       1.00

V8 Bundled Exec                                    6       3.47       1.00

LOB/FILE operations                              6       3.47       1.00

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

3)以上是故障发生前一分钟的数据库活动概总，从上面的信息看，insert 是占大比，会不会就是这个原因呢？还是28原则呢？只是由于一些不起眼，一小部份的操作导致呢？

结果用户反馈，在时间段正值放假，应该没有人在工作才的，但是从数据库收集到的信息，除了每日跑的后台作业，还有人为操作，所以我这部份人为操作系好值得怀疑。

4）与用户沟通得如下人为操作内容：

5）进一步细查,会话的PGA分配,语句如下：

col sample_id format a30

col sql_id format a20

col event format a30

col program format a30

col module format a15

col sql_opname format a15

col wait_calss format a10

col sample_time format a22

select to_char(sample_time,'YYYY-MM-DD,HH24:MI:SS') sample_time,sql_id,user_id,sql_opname,event,wait_class,

program,module,round(pga_allocated/1024/1024,2) pga_allocated

from dba_hist_active_sess_history a

where a.sample_time  between to_date('2017-05-01 09:00:00','YYYY-MM-DD HH24:MI:SS')

AND to_date('2017-05-01 9:30:00','YYYY-MM-DD HH24:MI:SS')

AND A.instance_number=1

order by pga_allocated desc;

发现在同一时刻有多个会话分配的PGA在1G以上。

6）根据5返回的SQL ID，返查SQL语句，并通过生成sql语句的执行计划，初步评估操纵数据量。

7) 从6的结果可以得知大部份SQL语句所操纵数据量在2G左右，甚至有些还达到32G

8) 所以目前的内存容间是不足以容纳这部份的数据量，最终发生大量换页，导致系统挂起。

结论：

1. 重构数据运算的算法，优化程序代码

    2. 增加系统资源，内存，SWAP空间。