在Windows上调整SGA大小遭遇ora-27100、ora-27102错误的处理方法

今天早上去一公司合作伙伴那里，协助处理他们某客户的数据库性能问题，那个库是Oracle 10.2.0.1的，前台业务系统是政府某机构查询系统，碰到的问题是首页展示很慢，与之相关的SQL语句查询结果须要跑59s多。而其它页面相关模块的查询都仅仅须要几秒就能够出结果了。

碰到数据库性能问题通常从两个方面着手调整：

1. 内存參数调整

2. SQL语句优化

因此。首先就查看了该库的SGA參数，发现仅仅分配了1.2G。而数据库server的物理内存为8G，显然这个值太小了。拉了一份AWR报告，显示shared pool仅仅分配到了200多M。简直少的令人发指。这个数据库是执行在Windows 2003 Enterprise x64上面的，因此应该不存在SGA不能超过1.7G的限制，于是对SGA參数进行调整，目标是调整到OS物理内存的50%。即SGA=4G。

因为開始并未设置过sga_max_size的值，所以当调整实例sga_target为某个固定的值再重新启动后，假设sga_target的值大于sga_max_size的值。那么sga_max_size的值就会随着sga_target自己主动添加为同样的值，反之，则不会变。此时这2个值都是1200M。虽然sga_target是动态參数。但此时是不同意调大的，当我们须要设置sga_target=4G。就超过了sga_max_size的值，数据库会报错，所以，要调大SGA。还必须先改动sga_max_size，而该參数是静态參数。也就意味着须要停库。中午向客户申请了20分钟的停机时间，然后着手对该參数进行调整。

依次运行下面命令：

SQL> alter system set sga_max_size=4G scope=spfile;

SQL> shutdown immediate

当再次启动数据库的时候。碰到了问题。报了ora-27102: out of memory

SQL> startup

ORA-27102: out of memory

OSD-00022: Message 22 not found;  product=RDBMS; facility=SOSD

O/S-Error: (OS 8) Not enough storage is available to process this command.

SQL>

之后不管是关闭或者启动数据库，哪怕仅仅是启动到mount，都会报ora-27100错误：

SQL> shutdown immediate;

ORA-01034: ORACLE not available

ORA-27101: shared memory realm does not exist

SQL> startup;

ORA-27100: shared memory realm already exists

SQL>

看来是设置sga_max_size=4G，造成了oracle占用OS内存过大，导致数据库无法启动，这里比較纳闷。为何设置SGA为物理内存的50%也会报错呢？Windows又不像Linux/Unix那样，还有个maxshmall的限制

因为是在spfile中改动的sga_max_size的值。如今数据库却无法启动了。因为还未进入到oracle实例。spfile也无法再次改动回来，相当于spfile被人为地损坏了。更糟糕的是，之前改动參数值的时候，忘记先生成一个pfile作为备份了，这可麻烦了。还好測试库上有一个相同10g实例，于是生成一个pfile，然后改动当中的路径及实例名为生产库的值后进行替换，复制到生产库的%ORACLE_HOME/database以下，再用这个pfile来启动数据库

SQL> startup pfile=E:\oracle\app\product\10.2.0\db_1\database\initnt.ora;

ORA-27100: shared memory realm already exists

错误依旧存在，难道数据库就这样无法启动了嘛？当然不会。这但是生产库，停了以后业务就都挂了，眼看20分钟的停机时间就要到了。

事实上，在windows上执行的oracle实例有一点特殊，假设启动数据库实例时。因为sga_max_size设置过大而造成实例启动失败，虽然把实例启动。但此时仍然会有一个错误的实例存在。因而会导致shutdown immediate及shutdown abort都关闭不了。也无法startup，始终会报ora-27100。这是由于在缺省安装时，oracle实例的服务（oracleSERVICESID）会在windows启动时自己主动启动，且每次启动服务时，都会自己主动用默认的spfile启动实例（假设存在的话）。因此就导致了一直出现ora-27100的内存错误。

知道了这个机制，那么再处理之前的内存错误就非常easy了，先把错误的那个spfile删除掉。然后停止oracle实例对应的服务，再又一次把服务起来，再用pifle启动数据库就可以

SQL> startup pfile=E:\oracle\app\product\10.2.0\db_1\database\initnt.ora;

这次数据库不在报ora-27100了，可是仍然会报ora-27102，这是怎么了。来来回回出现同样的问题，后来通过一次次的尝试，最终发现了一个事实，就是在pfile中设置成2G、3G时。再用之前的方法启动数据库，数据库都能够正常启动，只有设置成4G时，就会出现ora-27102。

仅仅能接受这个现实了。

于是就把sga_max_size设置为3G，sga_target也调整为3G，好歹也是比之前1G要多了2倍了。又一次启动数据库之后，再用pfile又一次创建了一个正确的spfile，调整SGA的任务算是完毕了

SQL> alter system set sga_target=3G scope=both;

SQL> create spfile from pfile;

SQL> shutdown immediate;

SQL> startup    --用spfile再次启动数据库（推荐）

SGA增大之后，因为是採用10g的自己主动内存管理，shared pool的值也得到了对应的添加，对于跑SQL语句而言是有极大优点的

调整完内存參数后。如今就要对对应的SQL语句来调整，因为SQL语句我并没有拿到，仅仅能凭回顾说一下大致的情况。这个首页调用的SQL语句是个视图，视图中另一个由存储过程生成的视图，用了半连接的in进行多表连接，查看了运行计划发现，2个视图中的子查询的多表连接都採用了union的方式。询问了一下，此处并无排序的需求。因此建议改成了union all，能够避免排序操作。另外视图中连接的这些表（共3个），无一例外地都是走了Full Table Scan，即全表扫描。没有一个用到索引，显然这不太合理。通过在一个查询字段”currentstate“上建立索引后，再次查询发现，该条语句单独跑的时候。cost马上从原来的800多减少到了200多。以此类推，我建议了他们在对应的查询列上建立索引，来优化这条SQL语句。优化思路提出来了，详细的优化过程由他们自己完毕。

总结：

再次强调一下，数据库性能问题，先从双方面着手。一是调整数据库參数（查看内存參数设置是否合理等）。二是对SQL语句进行调整（优化）。分析运行计划。查看索引是否被高效地利用起来。另外须要结合AWR报告分析数据库是否负载过高（DB Time过高）。存在性能瓶颈（TOP 5 event）,命中率过低（Buffer Hit%、Library Hit%过低）等不利因素。