ORACLE调整SGA_TARGET值耗费时间长案例

在一数据库版本为（标准版）Oracle Database 10g Release 10.2.0.4.0 - 64bit Production 的服务器上调整 sga_target时，遇到命令执行了非常久都没有执行完成的异常情况，觉得非常诧异、不解，因为一般调整sga_targt命令非常快速，检查了告警日志，并没有任何异常错误，等了好几分钟都没有执行完成，于是执行了CTRL+C命令结束了SQL命令，具体过程如下：

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Sep 3 22:35:59 2016

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 8G
sga_target                           big integer 6G

SQL>
SQL> alter system set sga_target=8g scope=both;

^Calter system set sga_target=8g scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-01013: user requested cancel of current operation



SQL>
SQL>

 

后面检查时，在$ORACLE_BASE/admin/$ORACLE_SID/bdump目录下发现scm2_mmon_16798.trc跟踪文件，在里面看到大量“SGA POLICY: Cache below reserve request pending 1”这里错误信息

/u01/app/oracle/admin/SCM2/bdump/scm2_mmon_16798.trc
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      xxxxxxxxx
Release:        2.6.32-200.13.1.el5uek
Version:        #1 SMP Wed Jul 27 21:02:33 EDT 2011
Machine:        x86_64
Instance name: SCM2
Redo thread mounted by this instance: 1
Oracle process number: 11
Unix process pid: 16798, image: xxxxxx (MMON)

*** 2016-09-03 22:36:49.845
*** SERVICE NAME:(SYS$BACKGROUND) 2016-09-03 22:36:49.836
*** SESSION ID:(931.1) 2016-09-03 22:36:49.836
SGA POLICY: Cache below reserve getting from component1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
*** 2016-09-03 22:37:19.880
SGA POLICY: Cache below reserve getting from component1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
*** 2016-09-03 22:37:49.892
SGA POLICY: Cache below reserve getting from component1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
SGA POLICY: Cache below reserve request pending 1
*** 2016-09-03 22:38:19.909

 

当时查了一下资料，觉得有可能与db_cache_size被手工设定有关（这个参数被同事手工设置过），当时检查了一下V$SGA_RESIZE_OPS，发现并没有SGA组件重定义大小的操作失败的记录。由于这个不是急于调整，手头还有正事处理，于是当时就搁置下来。

 

今天晚上去检查、处理时，居然无法重现这个错误了， 调整sga_target_size一下子就成功了，没法重现这个错误了，于是我又特意检查了一下V$SGA_RESIZE_OPS,发现期间出现了shared pool 收缩， DEFAULT buffer cache的增长， 还有一个DEFAULT buffer cache的增长从2016-09-03 22:45:21持续到了2016-09-04 21:13:26，而且状态为INACTIVE。

 

后面分析了这个时间段的ASH报告，发现这个时间点出现了“SGA: allocation forcing component growth”等待事件，

The SGA: allocation forcing component growth indicates that you can Automatic Memory Management (AMM) turned-on

This is an AMM message indicating that the size of sga_target or memory_target is too small, causing excessive AMM resize operations.

The solution is to turn off AMM and allocate your own db_cache_size and shared_pool_size and un-setting sga_target and memory_target.

分析至此，能确定一些东西：当调整SGA_TARGET大小时，操作系统的内存也会将内存里面用作cache或buffers的部分数据踢出内存， 另外，由于che_size和shared_pool_size等SGA相关组件大小剧烈调整，导致了SGA: allocation forcing component growth等待事件，导致SQL语句耗费了非常长的时间。由于当时SQL执行时间长，我取消了调整sga_target的SQL语句