给客户处理数据库故障的过程分享

    12月9日上午接到销售人员电话，说某客户的数据故障，业务都停了，让我去处理一下。急忙从公司赶往客户那边，好在离公司不太远，6站地铁就到了。到了客户那边，赶紧与那边的DBA简单地沟通了一下，了解到他们的库是运行在WINDOW 2008 标准版上的Oracle 11gR1，已经配置了DG，出问题的是主库，早上上班的时候发现业务系统无法连接到数据库，监听也hang死。

    我到那边的时候，他们的DBA已经对库执行过了shutdown并重启过了，但是发现业务系统仍然无法正常使用，查看监听状态，并没有实例的服务被注册到监听，并且SQLPLUS连接数据库提示权限不足。查看后发现，原来是因为Windows上Oracle实例的服务没有启动（默认为手动启动方式），启动数据库后就能顺利进入SQLPLUS了，服务也被PMON进程注册到监听了。至此，业务系统其实也就正常了，能通过监听访问数据库了。

    仅重启下数据库，无法访问数据库的问题就解决了？到底是什么原因造成的呢？通过分析alert日志，发现主要是再凌晨1点12分开始报error的：

Tue Dec 09 01:12:50 2014

kkjcre1p: unable to spawn jobq slave process 

Errors in file d:\oracle\diag\rdbms\msa\msa\trace\msa_cjq0_5336.trc:

略…

Tue Dec 09 01:24:09 2014

Timed out trying to start process m001.

Tue Dec 09 01:26:14 2014

kkjcre1p: unable to spawn jobq slave process 

Errors in file d:\oracle\diag\rdbms\msa\msa\trace\msa_cjq0_5336.trc:  

略…

Tue Dec 09 01:39:27 2014

Timed out trying to start process m000.

Suspending MMON action 'DDE MMON action to schedule async action slaves' for 82800 seconds  

略…

Tue Dec 09 08:47:55 2014

kkjcre1p: unable to spawn jobq slave process 

Errors in file d:\oracle\diag\rdbms\msa\msa\trace\msa_cjq0_5336.trc:

Tue Dec 09 08:49:17 2014

Stopping background process SMCO

Tue Dec 09 08:49:48 2014

Background process SMCO not dead after 30 seconds

Killing background process SMCO

Stopping background process FBDA

Shutting down instance: further logons disabled

Stopping background process QMNC

Stopping background process MMNL

Stopping background process MMON

Shutting down instance (immediate)

License high water mark = 565

All dispatchers and shared servers shutdown

Tue Dec 09 08:49:58 2014

kkjcre1p: unable to spawn jobq slave process, slot 0, error 1089

Stopping background process CJQ0

Tue Dec 09 08:50:24 2014 --执行关闭数据库的时间

ALTER DATABASE CLOSE NORMAL

Tue Dec 09 08:50:24 2014

SMON: disabling tx recovery

SMON: disabling cache recovery

Tue Dec 09 08:50:25 2014

Shutting down archive processes

Archiving is disabled

Tue Dec 09 08:50:25 2014

ARCH shutting down

ARC2: Archival stopped

Tue Dec 09 08:50:25 2014

ARCH shutting down

Tue Dec 09 08:50:25 2014

ARCH shutting down

ARC1: Archival stopped

ARC3: Archival stopped

Thread 1 closed at log sequence 39723

Successful close of redo thread 1

Completed: ALTER DATABASE CLOSE NORMAL

ALTER DATABASE DISMOUNT

Completed: ALTER DATABASE DISMOUNT

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Archive process shutdown avoided: 0 active

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Archive process shutdown avoided: 0 active

Tue Dec 09 08:50:30 2014

Stopping background process VKTM: 

System State dumped to trace file d:\oracle\diag\rdbms\msa\msa\trace\msa_ora_5912.trc

略…

Tue Dec 09 10:55:07 2014     --重新启动数据库的时间

Starting ORACLE instance (normal)

根据提示信息：kkjcre1p: unable to spawn jobq slave process ，可以了解到是系统无法生成job相关的进程而出错的，有几种可能：

1、参数job_queue_processes（设置过小）

2、参数session和processes（设置的会话数及连接数不能满足业务需求）

3、参数pga_aggregate_target（被耗尽）

4、OS资源被耗尽，如virtual memory    

通常默认安装数据库，给的process值是150，而实际的业务环境可能需要的值远比这个要高。因此，需要调整该参数。通常还会伴随“ORA-00020: maximum number of processes (150) exceeded”的错误一起出现。重启数据库后，暂时也没有继续报该错误，所以暂时没有调整该参数。

由于重启数据库后故障基本已经解决，于是顺便诊断一下数据库，看看有没有什么其他方面的隐患。客户的数据库运行在Windows 2008标准版上，物理内存其实是64G，但是只能被识别到32G，浪费了32G！微软还挺坑爹的啊！

再看一下数据库内存分配情况，即使OS能用到32G内存，而MEMORY_MAX_TARGET和MEMORY_TARGET只给了6G，由于采用了11g的新特性AMM，那么自然SGA也最多只有6G了，而当SGA占用了全部分配的内存，PGA不就分配不到内存了么？于是对调整之前的2个参数值为10G，调整完的值如下：

SQL> set line 130

SQL> col component for a25

SQL> select component,current_size,max_size,user_specified_size from v$memory_dynamic_component

COMPONENT                 CURRENT_SIZE   MAX_SIZE USER_SPECIFIED_SIZE

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

shared pool                 2013265920 2013265920                   0

large pool                    67108864   67108864                   0

java pool                    402653184  402653184                   0

streams pool                         0          0                   0

SGA Target                  6710886400 6710886400                   0

DEFAULT buffer cache        4093640704 4227858432                   0

KEEP buffer cache                    0          0                   0

RECYCLE buffer cache                 0          0                   0

DEFAULT 2K buffer cache              0          0                   0

DEFAULT 4K buffer cache              0          0                   0

DEFAULT 8K buffer cache              0          0                   0

DEFAULT 16K buffer cache             0          0                   0

DEFAULT 32K buffer cache             0          0                   0

Shared IO Pool                       0          0                   0

PGA Target                  4026531840 4294967296                   0

ASM Buffer Cache                     0          0                   0

16 rows selected.

SGA达到了6G左右，db buffer cache与shared pool的比值也差不多达到了2：1，PGA也分配到了4G左右

SQL> show parameter sga

NAME                                 TYPE                   VALUE

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

lock_sga                             boolean                FALSE

pre_page_sga                         boolean                FALSE

sga_max_size                         big integer            10G

sga_target                           big integer            0

SQL> show parameter pga

NAME                                 TYPE                   VALUE

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

_pga_max_size                        big integer            432520K

pga_aggregate_target                 big integer            0

SQL> show parameter memory

NAME                                 TYPE                   VALUE

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

hi_shared_memory_address             integer                0

memory_max_target                    big integer            10G

memory_target                        big integer            10G

shared_memory_address                integer                0

SGA_TARGET=0为禁用SGA自动内存管理

之前的AWR报告中db buffer cache只给分配了450M左右，而shared pool则有4G左右，11g的AMM的副作用是：可能会使shared pool越来越大，而db buffer cache可用内存则减少（总SGA不变的情况下）

    

6G左右的SGA中，很大一部分都分配给了shared pool，db buffer cache只得到了448M

修改MEMORY_MAX_SIZE和MEMROY_TARGET为10G后：

由于之前MEMORY_MAX_SIZE和MEMORY_SIZE只给了6G，即采用AMM管理SGA和PGA，那么当SGA接近6G时，PGA基本上就只能获得非常少了，也就符合了之前第3条,PGA耗尽时造成了之前的“unable to spawn...”的错误。调整了SGA后与客户的DBA沟通了一下，让他后续要观察db buffer cache和shared pool这2个参数的值，尤其是注意之前的现象是否会重现（shared pool一直变大，db buffer cache一直变小），否则就要禁用掉AMM，即设置MEMORY_TARGET=0，然后手动设置这2个内存池的大小，把它们固定死。其实对于OS为32G内存而言，MEMORY_TARGET给10G已经算是保守的了，给一半（16G）其实也不过分，具体还是看业务需求，如果没有因SGA内存过少引起的性能瓶颈出现，那么就无需调整。

故障解决完之后，顺便查看了一下DG配置是否正常时，发现主库归档能顺利传递到备库，在主库切几次归档，也都能传过去，但是备库的归档却没有自动应用，而此时MRP进程是启动的。直接执行alter database recover managed standby database cancel;就直接hang在那里。只有把备库关闭并重启，并重新启动redo apply后，归档才顺利应用。这个问题也挺奇葩的，之前用shutdown immediate楞是卡在那里半天，备库也关不了。由于备库本来就是同步主库归档，并且一般是不会open的，于是直接用了shutdown abort来关闭，才片刻把备库关闭掉了。

另外，在检查数据库时还发现，客户这里的库居然只配置了DG而已，连RMAN备份策略都没做，实在有点说不过去啊，核心业务库怎么能只做个DG就完事了呢，容灾平台固然重要，但基本的备份恢复策略也不应该丢嘛。于是直接和他们的DBA说了，应该尽快部署RMAN备份策略，这样才能保障数据库的安全性，数据丢了能及时恢复回来。