首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >与时俱进:ASM内存管理与创建表空间之ORA-569错误解决

与时俱进:ASM内存管理与创建表空间之ORA-569错误解决

作者头像
数据和云
发布2018-03-06 11:58:35
1.2K0
发布2018-03-06 11:58:35
举报
文章被收录于专栏:数据和云数据和云

杨廷琨(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资源竞争导致的,往往山重水复之后,我们看到柳暗花明的还是最初的起点,很多学习的过程,就是如此。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-05-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据和云 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档