说明oracle dba手记chapter网名Yangtingkun

案例分析

（网（网现任云和恩墨CTO，ITPUB论坛Orace数据库管理版版主。204年曾参与编写了《Orace数据库性能优化》一书，27年被Oracle公司授予ACE称号，喜欢研究Orace相关的技术问题，他的技术博客上积累了1500多篇Oracle相关的技术文章。个人技术博ASM技术是Oracle自10g版开始引入的一项新的管理技术，由于ASM推出的时间，用户应用有限，在使用上遇到的问题就可能很多，本章用于介绍在实践中遇到的一些ASM问ASM实例连接之ORA-1012错误分本案例是 环境的测试数据库上执行导入数据的操作时出现错误，导入会话长时间没有响应。通SQL>SELECTSID,EVENTFROMV$SESSION_WAITSQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132logfileswitch(archiving数据库RAC环境的方式选择了ASM。由于是测试环境，所以并没有给ASM分配太大的空间，同时为了归档和备份的方便，将归档日志也放到了ASM中。产生问题的原因很明显：由于归档日志不断地产生，导致ASM磁盘组的空间耗尽，因此新的归档无法产生，整个数据库处于挂起状态。本来认为这是个小问题，根据文件系统的使用经验，只要清除掉一些归档日志，将空间出来就可以了。于是通过rman将所有的归档日志删除。不过这时奇怪的事情发生了，成功删除所有的归档日志后，问题仍然没有解决。SQL>SQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132logfileswitch(archivingSQL>altersystemswitch再次检查会话的等待信息，发现仍然在等待归档的完成。由于OSQL>altersystemswitch没有想到这个操作也一直处于等待中难道是ASM中的空间并没有被。于是在当前节点——也就是rac环境的节点1——启动dbca，本打算查看ASM的配置，没想到出现了以下的报错信息：DBCADBCAcouldnotstartuptheASMinstanceconfiguredonthisnode.ToproceedwithASMmanagementyouneedtheASMinstancetobeupandrunning.DoyouwanttorecreatetheASMinstanceonthenode?RAC环境一直是在ASM上运行的。到现在为止，除了数据库处于等待归档的状态外并无任何的异常，要是ASM实例，那么实例1应该也无法才对。从操作系统上检查ASM实例的状态如下：SQL>$ps-ef|grep10Apr130:0210Apr130:0210Apr130:0310Apr130:0810Apr130:0010Apr130:00从操作系统上看，ASM实例似乎工作得很正常。那么到底是什么问题呢，看来必须连接到ASM实例上才能找到答案：bash-2.03$exportORACLE_SID=+ASM1bash-2.03$sqlplus"/assysdba"SQL*PlusRelease.0Productionon星期一4月1616:02:422007Copyright(c)1982,2006,Oracle.s.SQL>SELECT*FROMV$ASM_DISKGROUP;SELECT*FROMV$ASM_DISKGROUP*第1行出现错误ORA-01012:notlogged果然ASM实例出现了问题。在节点1上，已经没有办法连接到ASM1实例并执行管理操作了。既然节点1上没有办法连接ASM实例，那么是否能在节点2上连接上ASM实例呢。测试发现节点2上不仅可以连接ASM实例，而且根据查询结果，ASM磁盘组尚有40GB的剩余空间。这显然是归档删除后的空间。bash-2.03$exportORACLE_SID=+ASM2bash-2.03$sqlplus"/assysdba"SQL*PlusRelease.0Productionon星期一4月1616:08:332007Copyright(c)1982,2006,Oracle.s.连接到OracleDatabase10gEnterpriseEditionRelease.0-64bitProductionWiththePartitioning,RealApplicationClusters,OLAPandDataMiningoptionsSQL>SETPAGES100LINES120SQL>COLNAMEFORMATSQL>SELECTGROUP_NUMBER,NAME,TOTAL_MB,FREE_MBFROMV$ASM_DISKGROUP;GROUP_NUMBERNAME 1 看来现在不只是数据库归档空间被占满，而且进一步导致了节点1上的ASM实例出现了故障，即使磁盘组有了足够的空间，数据库的实 也无法完成归档操作，从而使得整个实例都被挂起既然节点1无法正常工作，那么看看节点2是否存在同样的问题，尝试在节点2上执行日志切换：SQL>SELECTINSTANCE_NAMEFROMSQL>ALTERSYSTEMSWITCH系统已节点2上执行日志切换没有任何问题，看来问题只发生在节点1的ASM实例上。初步怀疑是空间用完导致ASM实例出现了这个问题。最简单的方式莫过于将节点1上的ASM实例重启。但是这势必导致实例1上所虽然这是一个测试数据库且这个数据库是一个RAC环境，重启一个实例的影响并不大。但是如果是正式环境，重启实例就不是小事情了，况且我并不想损失已经进行了一半的导入工作。于是想尝试通过其他的方法解决无法归档的问题，待导入工作完成后再重启实例。登录节点1上的实例：SQL>SETPAGES100LINESSQL>SELECTINSTANCE_NAMEFROMV$INSTANCE;SQL>SHORAMETER观察归档的相关信息，虽然改变数据库的归档模式要重启数据库，不过可以通过修改归档相关的初始化参数的方法来解决这个问题。由于LOG_ARCHIVE_MIN_SUCCEED_DEST参数设置为1，因此可以通过添加第二归档路径的方式来解决归档路径一无法使用的问题。由于实例2没有归档的问题，因此可以仅修改当前SQL>SQL>ALTERSYSTEMSETLOG_ARCHIVE_DEST_2='LOCATION=/data/oracle/oradata/testrac'SCOPE=MEMORYSID='testrac1';系统已修改后，查询会话状态发现刚才一直处于等待状态的altersystemswitchlogfile命令已经执行完毕，而且所SQL>altersystemswitch系统已更改。 SQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132SQL*Netmoredatafrom至此，问题基本上已经解决，只须等到导入工作完成后，重启节点1的数据库和ASM实例就可以了。问题出现的时候只是通过V$SESSION_WAIT视图和数据库前台报错信息进行了分析。问题解决后，检查ASM和实例1上的alert文件，这两个文件中包含的报错信息也明确地说明了是由于ASM故障导致的问题：MonApr1612:33:17WARNING:allocationfailureondiskDISK_0004forfile400xnum2147483648MonApr1612:33:182007WARNING:allocationfailureondiskDISK_0038forfile400xnum445MonApr1612:33:192007WARNING:allocationfailureondiskDISK_0038forfile400xnum445MonApr1612:37:512007WARNING:allocationfailureondiskDISK_0019forfile400xnum2147483648MonApr1615:01:122007WARNING:allocationfailureondiskDISK_0006forfile400xnum2147483648MonApr1615:23:232007StartingORACLEinstance(normal)MonApr1615:26:052007StartingORACLEinstance(normal)MonApr1615:30:532007ProcessPZ99died,seeitstracefileProcessPZ99died,seeitstracefileMonApr1615:31:112007ProcessPZ99died,seeitstraceProcessPZ99died,seeitstracefileMonApr1615:58:342007StartingORACLEinstance以下代码是ASM的报错信息，了ASM分配空间失败ORACLEInstancetestrac1-ArchivalErrorMonApr1612:33:242007ORA-16014:log1sequence#85notarchived,noavailableORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.258.618591139'ORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.259.618591145'MonApr1612:33:242007Errorsinfile/data/oracle/admin/testrac/bdump/testrac1_arc1_5191.trc:ORA-16014:log1sequence#85notarchived,noavailabledestinationsORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.258.618591139'ORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.259.618591145'而alert文件中的报错信息则说明是ASM的问题导致了归档的错误。从这个问题看，感觉ASM的Bug还是多了一点。虽然通过当前更改归档路径的方法，解决了实例1上无法归档的问题，但是ASM实例无法建立新连接的问题仍然没有解决。目前找不到不重启ASM实例就能解决问题的方法，而ASM给人的感觉是还不太透明。在解决了这次碰到的ASM错误后，没过多长时间又碰到了相同的现象bash-2.03$exportORACLE_SID=+ASM1bash-2.03$sqlplus"/assysdba"SQL*PlusRelease.0Productionon星期一4月1616:02:422007Copyright(c)1982,2006,Oracle.s.SQL>SELECT*FROMV$ASM_DISKGROUP;SELECT*FROMV$ASM_DISKGROUP*第1行出现错误ORA-01012:notlogged 实例的问题现象和前面碰到的基本一致，不过这次发生故障的节点问题的现象和上次的十分相似：首先是归档到ASM上报错，尝试用DBCA登录检查ASM的使用情况，DBCA的报错信息也和前一次完全一样。而从ASM的alert文件中也找到了大量的告警信息WARNING:allocationfailureondiskDISK_0000forfile384xnum 根据上次的经验，我登录了ASM实例，结果意外地发现了另一个ORA-00020:超出最大进程数 这个错误是上次没有出现过的，莫非进程数已经超过了数据库的限制$$ps-ef|grepASM|grep-vgrep|wc检查ASM实例启动日志没有看到启动时加载的PROCESSES参数，说明PROCESSES参数设置是默认值。过了一段时间，发现可以正常登录ASM实例。查询PROCESSES初始化参数，发现ASM实例的设置果是SQL>shorameter 01102$ps-ef|grepASM|grep-vgrep|wc–l这时可以登录ASM实例，说明ASM实例上的有些进程了，检查ASM启动的进程数，$ps-ef|grepASM|grep-vgrep|wc–l根据这个现象可以确定，这次的问题是由于ASM实例上的进程数超过初始化参数PROCESSES的设置而了解到问题的根源，解决起来就很容易了。修改ASM实例的启动初始化参数，给PROCESSES参数设置一个较大的值，就可以避免这种情况的产生。不过这也说明了一个问题，Oracle给出的大部分默认参数的值都偏小，须要用户建立数据库时手工调整，ASM实例的参数也不例外。问题到现在为止还没有结束，因为正常情况下，ASM实例是不会有如此多的连接和进程的，须要找到是什么原因导致ASM产生了大量的连接。首先通过操作系统命令检查$ps-ef|grepASM|grep-voracle10May140:00oracle10May140:05oracle10May140:00oracle10Jun090:00oracle10May140:03oracle10May140:11oracle10May140:00oracle10May140:08asm_oracle10May140:00oracle10May140:01oracle1Jun090:00oracle1108011079017:54:43? 0:00oracle+ASM1$ps-ef|grepASM|grep-vgrep|wc-l这里仅仅是一个测试库，而且当前除了系统的进程外，只有几个进程在支持rman备份的操作，没有其他人连接到这个数据库。为什么ASM实例上会有这么多的会话呢，接着登录ASM实例进行检查：bash-2.03$exportORACLE_SID=+ASM1bash-2.03$sqlplus"/assysdba"SQL*PlusRelease.0Productionon星期一6月1118:21:232007Copyright(c)1982,2006,Oracle.s.SQL>selectcount(*)fromv$session;SQL>selectcount(*)fromv$process;SQL>selectdistinctprocessfromv$sessionwhereusernameisnotnull;已选择6行SQL>selectprocess,count(*)fromv$sessionwhereusernameisnotnullgroupbyprocess; 1 已选择6行根据ASM实例上V$SESSION上的PROCESS列，找到连接到ASM实例的操作系统进程。上面的查询列出了所有非ASM实例进程对应的操作系统进程。可以看到，绝大部分Oracle的会话是19969和19995这下面依次分$ps-ef|grep11234|grep-voracle1124611234018:21:23? oracle112348887018:21:23 0:00sqlplus/as$ps-ef|grep19620|grep-voracle 10Jun01 0:06这两个进程一个是通过SQLPLUS连接到ASM实例的进程，也就是当前查询的进程；另一个是节TESTRAC1连接到ASM实例的进程$ps-ef|grep23709|grep-voracle23709 10Jun07? 0:56oracletestrac1$ps-ef|grep23768|grep-voracle23768 10Jun07? 0:39oracletestrac1$sqlplus"/asSQL>gram,module,client_info,eventfromv$sessions,v$processpwherepaddr=p.addrandspidin(23709,23768); ode1(TNSV1-V3)backupfulldatafilermanchannel=c1controlfileparallelwriteode1(TNSV1-V3)backupfulldatafilermanchannel=c2controlfileparallel这两个会话在备份时出现了错误，等待了很久都无法自动结束，最后是通过Ctrl+\强制结束的。会话异常结束后，Oracle并没有将资源完全。$ps-ef|grep19969|grep-voracle 10Jun010:48$ps-ef|grep19995|grep-voracle 10Jun01$ps-ef|grep19969|grep-voracle 10Jun010:48$ps-ef|grep19995|grep-voracle 10Jun01 0:18进行的居然是Oracle问题是由于归档进程无法创建新的归档日志文件而导致的。检查实例1上的alert文件，发现问题产生时出现了大量的错误：SatJun910:08:28ARCH:Archivalstopped,erroroccurred.WillcontinueretryingSatJun910:08:282007ORACLEInstancetestrac1-ArchivalErrorSatJun910:08:282007ORA-16014:log1sequence#307notarchived,noavailableORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.258.618591139'ORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.259.618591145'SatJun910:08:282007Errorsinfile/data/oracle/admin/testrac/bdump/testrac1_arc0_19969.trc:ORA-16014:log1sequence#307notarchived,noavailabledestinationsORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.258.618591139'ORA-00312:onlinelog1thread1:'+DISK/testrac/onlinelog/group_1.259.618591145'显然错误是从ASM磁盘组空间耗尽、归档失败开始的。现在检查失败归档的进程号，发现就是19969和19995这两个进程。显然，Oracle在不断重试归档的过程中出现了一些错误，导致归档进程连接到ASM实例的Errorsinfile/data/oracle/admin/testrac/bdump/testrac1_arc0_19969.trc:ORA-00313:openfailedformembersofloggroup2ofthread1ORA-00312:onlinelog2thread1:ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/onlinelog/group_2.260.618591151ORA-00020:umnumberofprocesses()exceededTueJun1209:29:04UnexpectedcommunicationfailurewithASMORA-00020:umnumberofprocesses()exceededUnexpectedcommunicationfailurewithASMinstance:ORA-00020:umnumberofprocesses()exceededTueJun1209:29:052007Errorsinfile/data/oracle/admin/testrac/bdump/testrac1_arc0_19969.trc:ORA-00313:openfailedformembersofloggroup1ofthread1ORA-00312:onlinelog1thread1:ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/onlinelog/group_1.259.618591145ORA-00020:umnumberofprocesses()exceededORA-00312:onlinelog1thread1:ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/onlinelog/group_1.258.618591139ORA-00020:umnumberofprocesses()exceeded解决问题的最好方法是重启数据库实例和ASM。如果暂时无法重启可以按照前面给出的方法另外设立一个归档目的地。不过对于这个特殊 ORA- 错误，还可以采用如下的方法清除异常的会话和进程SQL>selectcount(*)fromv$session;SQL>select'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||2fromv$sessionwhereprocessin(19995,19969);ALTERSYSTEMKILLSESSION'12,ALTERSYSTEMKILLSESSION'34,ALTERSYSTEMKILLSESSION'14,ALTERSYSTEMKILLSESSION'33,ALTERSYSTEMKILLSESSION'13,已选择19行SQL>ALTERSYSTEMKILLSESSION'12,系统已SQL>ALTERSYSTEMKILLSESSION'34,系统已SQL>ALTERSYSTEMKILLSESSION'14,系统已更改并通过操作系统命令清除刚才rman失败造成的两个进程bash-2.03$bash-2.03$kill-9bash-2.03$kill-9无论是清除Oracle实例的进程23709，还是清除23768进程所对应的ASM实例进程28631都可等待一段时间 自动清除所有的进程，数据库恢复正常bash-2.03$bash-2.03$ps-ef|grepASM|grep-vgrep|wc–lASM空间扩展故障由于RAC的测试环境空间不足，因此规划给ASM扩展空间，然而在给ASM添加新的磁盘空间时又出现空间扩展的操作步骤如下：在RAC环境的节点1上启动了DBCA工具来管理ASM设备。由于新增的设备在ASM图形界面下看不到因此在节点1上通过root用户将设备的权限授予了操作系统上的Oracle这时，从图形界面的候选磁盘中已经可以看到这些设备了。通过图形界面将设备加到了磁盘组中。但是这个操作了两个错误：分别是ORA-15032和ORA-15075。首先看看在Oracle文档上是如何描述这两个错误的ORA-15032:notallalterationsCause:AtleastoneALTERDISKGROUPactionAction:ChecktheothermessagesissuedalongwiththissummaryORA-15075:disk(s)arenotvisiblecluster-wideCause:TERDISKGROUPADDDISKcommandspecifiedadiskthatcouldnotbediscoveredbyoneormorenodesinaRACclusterconfiguration.Action:DeterminewhichdisksarecausingtheproblemfromtheGV$OSM_DISKfixedview.Checkoperatingsystempermissionsforthedeviceandthestoragesub-systemconfigurationoneachnodeinaRACclusterthatcannotidentifythedisk.其实ORA-15075错误中的信息已经足够明显了。根据这个错误进行分析应该就能很快找到问题的原因。这个错误导致了奇怪的现象：根据错误信息判断，操作已经失败了，但是检查发现这些设备 ASM配置中已经可见了当正在检查这两个错误信息时，同事告诉我节点2上的实例连不上通过操作系统命令检查发现数据库实例2已经关闭了，不过这个节点上的ASM实例仍然存在。这个现象很奇怪：对ASM的操作引起的错误，当前ASM实例没有出错，却有另外一个数据库实例被关闭。检查alert文件如下$tail-500alert*Listofnodes:ThuMar2917:25:36SUCCESS:diskDISK_0017(17.)addedtodiskgroupDISKSUCCESS:diskDISK_0018(18.)addedtodiskgroupDISKSUCCESS:diskDISK_0019(19.)addedtodiskgroupDISKSUCCESS:diskDISK_0020(20.)addedtodiskgroupDISKSUCCESS:diskDISK_0021(21.)addedtodiskgroupDISKSUCCESS:diskDISK_0022(22.)addedtodiskgroupDISKThuMar2917:29:452007SUCCESS:diskgroupDISKwasdismountedSUCCESS:diskgroupDISKwasdismountedThuMar2917:29:462007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:ORA-00202:controlfile:'+DISK/testrac/control01.ctl'ORA-15078:ASMdiskgroupwasforciblydismountedThuMar2917:29:462007LMON:terminatinginstanceduetoerror204ThuMar2917:29:462007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_pmon_2754.trc:ORA-00204:errorinreading(block,#blocks)ofcontrolfileThuMar2917:29:46SystemstatedumpismadeforlocalinstanceThuMar2917:29:462007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_1_2797.trc:ORA-00204:errorinreading(block,#blocks)ofcontrolfileThuMar2917:29:46Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_0_2793.trc:ORA-00204:errorinreading(block,#blocks)ofcontrolfileSystemStatedumpedtotracefile/data/oracle/admin/testrac/bdump/testrac2_diag_2756.trcThuMar2917:29:472007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_j001_677.trc:ORA-00204:控制文件时出错(块,#块)ThuMar2917:29:47ErrorsinfileORA-00204:控制文件时出错(块,#块)ThuMar2917:29:472007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_rbal_2982.trc:ORA-00204:errorinreading(block,#blocks)ofcontrolfileThuMar2917:29:52InstanceterminatedbyLMON,pid=尝试重启系统，看看会产生何种错误信$sqlplus"/asSQL*PlusRelease.0Productionon星期四3月2917:36:072007Copyright(c)1982,2005,Oracle.s.已连接到空闲SQL>ORA-01078:failureinprocessingsystemORA-01565:errorinidentifyingfile'+DISK/testrac/spfiletestrac.ora'ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/spfiletestrac.oraORA-15077:couldnotlocateASMinstanceservingarequireddiskgroupSQL>shutdownORA-01034:ORACLEnotORA-27101:sharedmemoryrealmdoesnotexistSVR4Error:2:Nosuchfileordirectory其实这时alert文件中已经明显包含了导SUCCESS:diskgroupDISKwasdismountedSUCCESS:diskgroupDISKwasdismountedThuMar2917:29:462007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:ORA-00202:controlfile:'+DISK/testrac/control01.ctl'ORA-15078:ASMdiskgroupwasforciblydismountedThuMar2917:29:462007Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:ORA-00204:errorinreading(block35,#blocks1)ofcontrolfileORA-00202:controlfile:'+DISK/testrac/control01.ctl'ORA-15078:ASMdiskgroupwasforciblydismountedASM的磁盘组已经DISMOUNT了，不过由于当时对ASM还不熟悉，所以对ASM的信息没有过多关注，Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_j001_677.trc:ORA-00204:控制文件时出错(块,#块)ThuMar2917:29:47Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_j000_3675.trc:ORA-00204:控制文件时出错(块,#块)ThuMar2917:29:47Errorsinfile/data/oracle/admin/testrac/bdump/testrac2_rbal_2982.trc:ORA-00204:errorinreading(block,#blocks)ofcontrolfileThuMar2917:29:52InstanceterminatedbyLMON,pid=看到这个ORA-204错误信息，想当然地认为这是导致问题的原因。其实如果查看随后的启动报错信息就可以看出问题：ORA-15077:couldnotlocateASMinstanceservingarequireddiskgroup。Oracle文档对这个ORA-15077:ORA-15077:couldnotlocateASMinstanceservingarequiredCause:TheinstancefailedtoperformthespecifiedoperationbecauseitcouldnotlocatearequiredASMinstance.Action:StartanASMinstanceandmounttherequired不幸的由于此前刚刚碰到一个Bug，这个Bug的关键报错信息恰好也是ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/spfiletestrac.ora。于是忽略了以上的关键信息，而把关注点转移到Bug上，并认为这次碰并尝试使用本地pfile文件启动数据库ORACLE例程已经启动。TotalSystemGlobalFixedVariableDatabaseRedoORA-00205:?????????,??????,出现了报错后，又一次被误导，去检查ORA-00205报错信ORA-00205:errorinidentifyingcontrolfile,checkalertlogformoreinfoCause:ORA-00205:errorinidentifyingcontrolfile,checkalertlogformoreinfoCause:Thesystemcouldnotfindacontrolfileofthespecifiednameandsize.Action:CheckthatALLcontrolfilesareonlineandthattheyarethesamefilesthatthecreatedatcoldstart直到发现控制文件本身并没有问题——实例1一直正常运行。这时才自己“误入歧途仔细检查所有的报错信息以及导致错误产生的原因——添加磁盘组的操作，终于发现了问题的真正原因：当时在给设备的时候，只在节点1进行了，而没有在节点2进行，因此节点1上的DBCA配置的ASM实例可以成功地将设备加到磁盘组中，而在节点2上同样的操作由于缺少权限，导致了磁盘组DISMOUNT，最终导致了数据库实例的关闭。于是在节点2上对设备进行，重启ASM实例，问题解决$su-SunMicrosystemsInc.SunOS5.8 GenericPatchOctober2001#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s1#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s3#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s4#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s5#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s6#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s7#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s1#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s3#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s4#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s5#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s6#chownoracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s7$sqlplus"/assysdba"SQL>shutdownORA-01507:未装载数据ORACLE例程已经关闭$srvctlstopasm- $srvctlstartasm- $sqlplus"/asSQL*PlusRelease.0Productionon星期四3月2917:55:172007Copyright(c)1982,2005,Oracle.s.SQL>startupTotalSystemGlobalArea2147483648bytesFixed 2030296Variable 469763368Database 1660944384Redo 14745600本来很简单的一个问题却大费周折。这个教训说明解决问题的时候须冷静地分析和判断，否则很容易被一些其他的信息干扰而误入歧途，从而导致在解决问题时走上弯路。ASM创建表空间之ORA-569错误在一个测试数据库上创建表空间出现了ORA-569错误。由于环境比较复杂，首先简单描述一下数据库环境信息。这个测试环境安装的是Oracle1106forSolaris10sparc64bit的RAC环境，使用ASM作为共享数据文件的机制。在RAC环境的一个节点上还建立了一个单实例的数据库，并把这个数据库的数据文件也放到了ASM实上在这个单实例数据库上添加新的表空间错，代码如下：SQL>selectfile_namefromdba_data_files;SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m;createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m*第1行出现错误ORA-01119:创建数据库文件'+DATA/test/datafile/test01.dbf'时出错ORA-17502ksfdcre4未能创建文件+DATA/test/datafile/test01.dbfORA-00569:Failedtoacquireglobalenqueue.ORA-00569:Failedtoacquireglobal这个错误很少见，查了一下Oracle的报错文档的描述ORA-00569:FailedtoacquireglobalCause:Apriorerroroccurredononeoftheinstancesinthecluster.Typicallyerrorsarecausedbysharedpoolresourcecontention.Action:Checkforandresolvepriorerrorsonallinstancesinthecluster.Ifthereispoolresourcecontention,increasetheSHARED_POOL_SIZE,DML_LOCKS,PROCESSES,TRANSACTIONS,CLUSTER_DATABASE_INSTANCESandPARALLEL_MAX_SERVERSinitializationparameters.文档虽然对问题进行了描述，不过从对错误信息和问题描述中看不出导致问题的真正原因查询了一下Metalink，从中找到了一些关于ORA-569的错误说明。不过这些问题都和当前错误有很大的不同：大部分出现这个错误的同时都会伴随ORA-600错误和ORA-4031错误。看来借助Metalink解决这个问题的希望落空，只能自己想办法前面已经提到当前环境比较复杂，这个节点上启动了两个实例。一个是单实例的数据库，另一个 数据库中的一个节点，而且两个数据库的数据文件都在相同 磁盘组中问题都有两面性，环境复杂也有复杂的好处，现在有一个简单的方法可以确定到底是数据库产生的问题还是ASM实例导致的问题：只需要登录RAC实例，执行类似的添加表空间的操作，就可检查是否会出现相同的错误bash-3.00$exportORACLE_SID=ractest1bash-3.00$sqlplus"/assysdba"SQL*Plus:Release.0-Productionon星 2月1817:12:422009Copyright(c)1982,2007,Oracle.s SQL>startupTotalSystemGlobalFixedVariableDatabaseRedo数据库装载完毕数据库已经打开SQL>CREATETABLESPACETESTDATAFILE'+DATA/ractest/datafile/test01.dbf'SIZE4096M;CREATETABLESPACETESTDATAFILE'+DATA/ractest/datafile/test01.dbf'SIZE4096M*第1行出现错误ORA-01119:创建数据库文件'+DATA/ractest/datafile/test01.dbf'时出错ORA-17502ksfdcre4未能创建文件+DATA/ractest/datafile/test01.dbfORA-00569:Failedtoacquireglobalenqueue.ORA-00569:Failedtoacquireglobal相同的错误产生了，说明问题多半与ASM实例的状态有关系。登录ASM实例进行简单的bash-3.00$exportORACLE_SID=+ASM1bash-3.00$sqlplus"/assysdba"SQL*Plus:Release.0-Productionon 2月1817:33:12Copyright(c)1982,2007,Oracle. SQL>setpages100linesSQL>selectinstance_name,statusfromv$instance; 由于ASM实例可以用来检查的动态视图太少了，从现有的视图也看不到什么特别的地方。实在没有什么太好的查错办法，只能重启数据库和ASM实例，再次检查问题：bash-3.00$exportORACLE_SID=testbash-3.00$sqlplus"/assysdba"SQL>shutdownimmediateSQL>bash-3.00$exportORACLE_SID=ractest1SQL>shutdownimmediateSQL>bash-3.00$exportORACLE_SID=+ASM1bash-3.00$sqlplus"/assysdba"SQL>shutdownimmediate^CORA-01013:userrequestedcancelofcurrentoperationSQL>CONN/ASSYSDBASQLshutdownabortASM实例已关闭SQLstartupASMTotalSystemGlobalFixedVariableASMASMdiskgroupsbash-3.00$exportORACLE_SID=testbash-3.00$sqlplus"/assysdba"SQL>startupORACLE例程已经启动SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m;createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m*第1行出现错误ORA-01119:创建数据库文件'+DATA/test/datafile/test01.dbf'时出错ORA-17502ksfdcre4未能创建文件+DATA/test/datafile/test01.dbfORA-00569:Failedtoacquireglobalenqueue.ORA-00569:Failedtoacquireglobal可以看到重启ASM实例后问题仍然出现。不过ASM实例也是在两个节点上同时运行的，莫非是在另一个节点的ASM实例出现了问题：bash-3.00$exportORACLE_SID=+ASM2bash-3.00$sqlplus"/assysdba"SQL*PlusRelease.0Productionon星期四2月1916:38:382009Copyright(c)1982,2007,Oracle.s.SQL>setpages100linesSQL>selectinstance_name,statusfromv$instance; bash-3.00$srvctlstopinstance-dractest-iractest2bash-3.00$srvctlstopasm-nser2bash-3.00$bash-3.00$srvctlstopinstance-dractest-iractest2bash-3.00$srvctlstopasm-nser2bash-3.00$srvctlstartasm-n再次登录test数据库，执行CREATETABLESPACE语句bash-3.00$bash-3.00$exportORACLE_SID=testbash-3.00$sqlplus"/assysdba"SQL>setpages100lines120SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size表空间看来问题果然和ASM实