与时俱进：ASM内存管理与创建表空间之ORA-569错误解决
杨廷琨（yangtingkun）
云和恩墨 CTO
高级咨询顾问，Oracle ACE总监，ITPUB Oracle数据库管理版版主
在一个测试数据库上创建表空间出现了ORA-569错误。由于环境比较复杂，首先简单描述一下数据库环境信息。这个测试环境安装的是Oracle 11g for Solaris 10 sparc 64bit的RAC环境，使用ASM作为共享数据文件的存储机制。
在RAC环境的一个节点上还建立了一个单实例的数据库，并把这个数据库的数据文件也放到了ASM实例上。
在这个单实例数据库上添加新的表空间时报错，代码如下：
SQL> select file_namefrom dba_data_files;
FILE_NAME
------------------------------------------------------------------------------
+DATA/test/datafile/system.533.668281219
+DATA/test/datafile/sysaux.534.668281227
+DATA/test/datafile/undotbs1.535.668281229
+DATA/test/datafile/users.537.668281241
SQL> create tablespacetest datafile '+DATA/test/datafile/test01.dbf' size 4096m;
create tablespace testdatafile '+DATA/test/datafile/test01.dbf' size 4096m
*
第 1 行出现错误:
ORA-01119: 创建数据库文件'+DATA/test/datafile/test01.dbf' 时出错
ORA-17502: ksfdcre: 4未能创建文件+DATA/test/datafile/test01.dbf
ORA-00569: Failed to acquire global enqueue.
这个错误很少见，查了一下Oracle的官方报错文档的描述：
ORA-00569: Failed toacquire global enqueue.
Cause: A prior error occurred on one of the instances in the cluster. Typically errors are caused by shared pool resource contention.
Action: Check for and resolve prior errors on all instances in the cluster. If there is shared pool resource contention, increase the SHARED_POOL_SIZE,DML_ LOCKS, PROCESSES, TRANSACTIONS, CLUSTER_DATABASE_INSTANCES and PARALLEL_MAX_SERVERS initialization parameters.
文档虽然对问题进行了描述，不过从对错误信息和问题描述中看不出导致问题的真正原因。
查询了一下MOS，从中找到了一些关于ORA-569的错误说明。不过这些问题都和当前错误有很大的不同：大部分出现这个错误的同时都会伴随ORA-600错误和ORA-4031错误。
看来借助Metalink解决这个问题的希望落空，只能自己想办法了。
前面已经提到当前环境比较复杂，这个节点上启动了两个实例。一个是单实例的数据库，另一个是RAC数据库中的一个节点，而且两个数据库的数据文件都存储在相同的ASM磁盘组中。
问题都有两面性，环境复杂也有复杂的好处，现在有一个简单的方法可以确定到底是数据库产生的问题还是ASM实例导致的问题：只需要登录RAC实例，执行类似的添加表空间的操作，就可检查是否会出现相同的错误。
bash-3.00$ export ORACLE_SID=ractest1
bash-3.00$ sqlplus "/as sysdba"
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 1603887104 bytes
数据库装载完毕。
数据库已经打开。
SQL> CREATE TABLESPACETEST DATAFILE '+DATA/ractest/datafile/test01.dbf' SIZE 4096M;
CREATE TABLESPACE TESTDATAFILE '+DATA/ractest/datafile/test01.dbf' SIZE 4096M
*
第 1 行出现错误:
ORA-01119: 创建数据库文件'+DATA/ractest/datafile/test01.dbf' 时出错
ORA-17502: ksfdcre: 4未能创建文件+DATA/ractest/datafile/test01.dbf
ORA-00569: Failed to acquire global enqueue.
相同的错误产生了，说明问题多半与ASM实例的状态有关系。登录ASM实例进行简单的检查：
bash-3.00$ export ORACLE_SID=+ASM1
bash-3.00$ sqlplus "/as sysdba"
SQL> set pages 100 lines 120
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
-------------------------------- ------------------------
+ASM1 STARTED
由于ASM实例可以用来检查的动态视图太少了，从现有的视图也看不到什么特别的地方。实在没有什么太好的查错办法，只能重启数据库和ASM实例，再次检查问题：
bash-3.00$ export ORACLE_SID=test
bash-3.00$ sqlplus "/as sysdba"
SQL> shutdown immediate
SQL> exit
bash-3.00$ export ORACLE_SID=ractest1
SQL> shutdown immediate
SQL> exit
bash-3.00$ export ORACLE_SID=+ASM1
bash-3.00$ sqlplus "/as sysdba"
SQL> shutdown immediate
^CORA-01013: user requestedcancel of current operation
SQL> CONN / AS SYSDBA
已连接。
SQL> shutdown abort
ASM 实例已关闭
SQL> startup
ASM 实例已启动
Total System Global Area 284008448 bytes
ASM diskgroups mounted
bash-3.00$ export ORACLE_SID=test
bash-3.00$ sqlplus "/as sysdba"
SQL> startup
ORACLE 例程已经启动。
数据库装载完毕。
数据库已经打开。
SQL> create tablespacetest datafile '+DATA/test/datafile/test01.dbf' size 4096m;
create tablespace testdatafile '+DATA/test/datafile/test01.dbf' size 4096m
*
第 1 行出现错误:
ORA-01119: 创建数据库文件'+DATA/test/datafile/test01.dbf' 时出错
ORA-17502: ksfdcre: 4未能创建文件+DATA/test/datafile/test01.dbf
ORA-00569: Failed toacquire global enqueue.
可以看到重启ASM实例后问题仍然出现。不过ASM实例也是在两个节点上同时运行的，莫非是在另一个节点的ASM实例出现了问题：
bash-3.00$ export ORACLE_SID=+ASM2
bash-3.00$ sqlplus "/as sysdba"
SQL> set pages 100 lines 120
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
-------------------------------- ------------------------
+ASM2 STARTED
检查ASM实例未发现异常，尝试重启ASM实例：
bash-3.00$ srvctl stop instance-d ractest -i ractest2
bash-3.00$ srvctl stop asm -n ser2
bash-3.00$ srvctl start asm -n ser2
再次登录test数据库，执行CREATE TABLESPACE语句：
bash-3.00$ export ORACLE_SID=test
bash-3.00$ sqlplus "/as sysdba"
SQL> set pages 100 lines 120
SQL> create tablespace test datafile '+DATA/test/datafile/test01.dbf' size 4096m;
表空间已创建。
看来问题果然和ASM实例状态不正常有关。
检查ASM实例2的alert文件，发现在运行CREATE TABLESPACE语句对应的时间点出现了ORA-4031错误：
Errors in file /data/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_lmd0_3099.trc (incident=2412):
ORA-04031: unable toallocate 3512 bytes of shared memory ("shared pool","unknown object","sgaheap(1,0)","ges enqueues")
Incident details in:/data/oracle/diag/asm/+asm/+ASM2/incident/incdir_2412/+ASM2_lmd0_3099_i2412.trc
Trace dumping is performingid=[cdmp_20090218155005]
WARNING: ran out of sharedpool for GES enqueue object.
Errors in file /data/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_lmd0_3099.trc (incident=2413):
ORA-04031: unable toallocate 3512 bytes of shared memory ("shared pool","unknown object","sgaheap(1,0)","ges enqueues")
Incident details in:/data/oracle/diag/asm/+asm/+ASM2/incident/incdir_2413/+ASM2_lmd0_3099_i2413.trc
Trace dumping is performingid=[cdmp_20090218155013]
前面ORA-569报错再加上这个ORA-4031报错，现在已经和Metalink里面的问题描述一致了，而且这个ORA-4031报错信息也很明显，问题在于分配全局队列资源时出现了错误。
检查ASM实例的sga，发现：
SQL> show sga
Total System Global Area 284008448 bytes
Fixed Size 2087944 bytes
Variable Size 256754680 bytes
ASM Cache 25165824 bytes
对于同时支持多个数据库实例的ASM实例而言，200MB的SGA显然太小了，和大部分其他Oracle默认参数一样，默认的ASM实例参数也是偏小的。
前面的文中还描述过：由于ASM实例的PROCESS参数太小导致ASM实例无法登录的问题。因此在选择ASM作为产品数据库的存储方式时，就要求ASM实例在建立时就要仔细地设置，很多的默认参数须要调整后才能满足正式环境的需要，使用一项技术，就要尊重一项技术。
在MOS后来补充的以下文档上，明确提出了关于ASM的SGA配置建议：
Things to Consider Before Upgrading to 11.2.0.3 Grid Infrastructure/ASM [ID 1363369.1]
其中指出：自11.2.0.3开始，由于初始化参数Processes的缺省值上升为“CPU Cores * 80 +40”，缺省的MEMORY_TARGET参数可能不足够，尤其是当CPU cores较多或者ASM磁盘组较多时，可能会导致ORA-4031错误，推荐增加ASM的MEMORY_TARGET至少到1536M。原文引用如下：
ASM memory_max_target and memory_target
In 11.2.0.3, init.ora parameter "processes" will be default to "available CPU cores * 80 + 40". As the default value for "memory_target" is based on "processes", it can be insufficient if there's large number of CPU cores or large number of diskgroups which could cause issues (i.e. GI stack fails to stop with ORA-04031 etc), it's recommended to increase the value of memory_max_target and memory_target before upgrading to 11.2.0.3(does not apply to 10g ASM):
Log in to ASM:
SQL> show parameter memory_target
If the value is smaller than 1536m, issue the following:
SQL> alter system set memory_max_target=4096m scope=spfile;
SQL> alter system set memory_target=1536m scope=spfile;
The number 1536m has proven to be sufficient for most environment, the change will not be effective until next restart.
此时我们再回头看看ORA-00569错误的提示：
ORA-00569: Failed toacquire global enqueue.
Cause: A prior error occurred on one of the instances in the cluster. Typically errors are caused by shared pool resource contention.
Action: Check for and resolve prior errors on all instances in the cluster. If there is shared pool resource contention, increase the SHARED_POOL_SIZE,DML_ LOCKS, PROCESSES, TRANSACTIONS, CLUSTER_DATABASE_INSTANCES and PARALLEL_MAX_SERVERS initialization parameters.
这里已经提到的ORA-00569典型的是由于Shared Pool资源竞争导致的，往往山重水复之后，我们看到柳暗花明的还是最初的起点，很多学习的过程，就是如此。
搜索 盖国强（Eygle）微信号：eeygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
关注本微信（OraNews）回复关键字获取 2016YHEMSZ ,云和恩墨大讲堂深圳交流会； 2016GOPSZ,2016深圳全球运维大会PPT； DBALife,"DBA的一天"精品海报大图； 12cArch,“Oracle 12c体系结构”精品海报； DBA01，《Oracle DBA手记》第一本下载； YunHe，“云和恩墨大讲堂”案例文档下载；