說明oracle dba手記chapter網(wǎng)名Yangtingkun

案例分析

（網(wǎng)（網(wǎng)現(xiàn)任云和恩墨CTO，ITPUB論壇Orace數(shù)據(jù)庫管理版版主。204年曾參與編寫了《Orace數(shù)據(jù)庫性能優(yōu)化》一書，27年被Oracle公司授予ACE稱號，喜歡研究Orace相關(guān)的技術(shù)問題，他的技術(shù)博客上積累了1500多篇Oracle相關(guān)的技術(shù)文章。個人技術(shù)博ASM技術(shù)是Oracle自10g版開始引入的一項新的管理技術(shù)，由于ASM推出的時間，用戶應(yīng)用有限，在使用上遇到的問題就可能很多，本章用于介紹在實踐中遇到的一些ASM問ASM實例連接之ORA-1012錯誤分本案例是 環(huán)境的測試數(shù)據(jù)庫上執(zhí)行導(dǎo)入數(shù)據(jù)的操作時出現(xiàn)錯誤，導(dǎo)入會話長時間沒有響應(yīng)。通SQL>SELECTSID,EVENTFROMV$SESSION_WAITSQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132logfileswitch(archiving數(shù)據(jù)庫RAC環(huán)境的方式選擇了ASM。由于是測試環(huán)境，所以并沒有給ASM分配太大的空間，同時為了歸檔和備份的方便，將歸檔日志也放到了ASM中。產(chǎn)生問題的原因很明顯：由于歸檔日志不斷地產(chǎn)生，導(dǎo)致ASM磁盤組的空間耗盡，因此新的歸檔無法產(chǎn)生，整個數(shù)據(jù)庫處于掛起狀態(tài)。本來認為這是個小問題，根據(jù)文件系統(tǒng)的使用經(jīng)驗，只要清除掉一些歸檔日志，將空間出來就可以了。于是通過rman將所有的歸檔日志刪除。不過這時奇怪的事情發(fā)生了，成功刪除所有的歸檔日志后，問題仍然沒有解決。SQL>SQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132logfileswitch(archivingSQL>altersystemswitch再次檢查會話的等待信息，發(fā)現(xiàn)仍然在等待歸檔的完成。由于OSQL>altersystemswitch沒有想到這個操作也一直處于等待中難道是ASM中的空間并沒有被。于是在當(dāng)前節(jié)點——也就是rac環(huán)境的節(jié)點1——啟動dbca，本打算查看ASM的配置，沒想到出現(xiàn)了以下的報錯信息：DBCADBCAcouldnotstartuptheASMinstanceconfiguredonthisnode.ToproceedwithASMmanagementyouneedtheASMinstancetobeupandrunning.DoyouwanttorecreatetheASMinstanceonthenode?RAC環(huán)境一直是在ASM上運行的。到現(xiàn)在為止，除了數(shù)據(jù)庫處于等待歸檔的狀態(tài)外并無任何的異常，要是ASM實例，那么實例1應(yīng)該也無法才對。從操作系統(tǒng)上檢查ASM實例的狀態(tài)如下：SQL>$ps-ef|grep10Apr130:0210Apr130:0210Apr130:0310Apr130:0810Apr130:0010Apr130:00從操作系統(tǒng)上看，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行出現(xiàn)錯誤ORA-01012:notlogged果然ASM實例出現(xiàn)了問題。在節(jié)點1上，已經(jīng)沒有辦法連接到ASM1實例并執(zhí)行管理操作了。既然節(jié)點1上沒有辦法連接ASM實例，那么是否能在節(jié)點2上連接上ASM實例呢。測試發(fā)現(xiàn)節(jié)點2上不僅可以連接ASM實例，而且根據(jù)查詢結(jié)果，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 看來現(xiàn)在不只是數(shù)據(jù)庫歸檔空間被占滿，而且進一步導(dǎo)致了節(jié)點1上的ASM實例出現(xiàn)了故障，即使磁盤組有了足夠的空間，數(shù)據(jù)庫的實 也無法完成歸檔操作，從而使得整個實例都被掛起既然節(jié)點1無法正常工作，那么看看節(jié)點2是否存在同樣的問題，嘗試在節(jié)點2上執(zhí)行日志切換：SQL>SELECTINSTANCE_NAMEFROMSQL>ALTERSYSTEMSWITCH系統(tǒng)已節(jié)點2上執(zhí)行日志切換沒有任何問題，看來問題只發(fā)生在節(jié)點1的ASM實例上。初步懷疑是空間用完導(dǎo)致ASM實例出現(xiàn)了這個問題。最簡單的方式莫過于將節(jié)點1上的ASM實例重啟。但是這勢必導(dǎo)致實例1上所雖然這是一個測試數(shù)據(jù)庫且這個數(shù)據(jù)庫是一個RAC環(huán)境，重啟一個實例的影響并不大。但是如果是正式環(huán)境，重啟實例就不是小事情了，況且我并不想損失已經(jīng)進行了一半的導(dǎo)入工作。于是想嘗試通過其他的方法解決無法歸檔的問題，待導(dǎo)入工作完成后再重啟實例。登錄節(jié)點1上的實例：SQL>SETPAGES100LINESSQL>SELECTINSTANCE_NAMEFROMV$INSTANCE;SQL>SHORAMETER觀察歸檔的相關(guān)信息，雖然改變數(shù)據(jù)庫的歸檔模式要重啟數(shù)據(jù)庫，不過可以通過修改歸檔相關(guān)的初始化參數(shù)的方法來解決這個問題。由于LOG_ARCHIVE_MIN_SUCCEED_DEST參數(shù)設(shè)置為1，因此可以通過添加第二歸檔路徑的方式來解決歸檔路徑一無法使用的問題。由于實例2沒有歸檔的問題，因此可以僅修改當(dāng)前SQL>SQL>ALTERSYSTEMSETLOG_ARCHIVE_DEST_2='LOCATION=/data/oracle/oradata/testrac'SCOPE=MEMORYSID='testrac1';系統(tǒng)已修改后，查詢會話狀態(tài)發(fā)現(xiàn)剛才一直處于等待狀態(tài)的altersystemswitchlogfile命令已經(jīng)執(zhí)行完畢，而且所SQL>altersystemswitch系統(tǒng)已更改。 SQL>SELECTSID,EVENTFROMV$SESSION_WAITWHERESID=132;SIDEVENT132SQL*Netmoredatafrom至此，問題基本上已經(jīng)解決，只須等到導(dǎo)入工作完成后，重啟節(jié)點1的數(shù)據(jù)庫和ASM實例就可以了。問題出現(xiàn)的時候只是通過V$SESSION_WAIT視圖和數(shù)據(jù)庫前臺報錯信息進行了分析。問題解決后，檢查ASM和實例1上的alert文件，這兩個文件中包含的報錯信息也明確地說明了是由于ASM故障導(dǎo)致的問題：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的問題導(dǎo)致了歸檔的錯誤。從這個問題看，感覺ASM的Bug還是多了一點。雖然通過當(dāng)前更改歸檔路徑的方法，解決了實例1上無法歸檔的問題，但是ASM實例無法建立新連接的問題仍然沒有解決。目前找不到不重啟ASM實例就能解決問題的方法，而ASM給人的感覺是還不太透明。在解決了這次碰到的ASM錯誤后，沒過多長時間又碰到了相同的現(xiàn)象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行出現(xiàn)錯誤ORA-01012:notlogged 實例的問題現(xiàn)象和前面碰到的基本一致，不過這次發(fā)生故障的節(jié)點問題的現(xiàn)象和上次的十分相似：首先是歸檔到ASM上報錯，嘗試用DBCA登錄檢查ASM的使用情況，DBCA的報錯信息也和前一次完全一樣。而從ASM的alert文件中也找到了大量的告警信息WARNING:allocationfailureondiskDISK_0000forfile384xnum 根據(jù)上次的經(jīng)驗，我登錄了ASM實例，結(jié)果意外地發(fā)現(xiàn)了另一個ORA-00020:超出最大進程數(shù) 這個錯誤是上次沒有出現(xiàn)過的，莫非進程數(shù)已經(jīng)超過了數(shù)據(jù)庫的限制$$ps-ef|grepASM|grep-vgrep|wc檢查ASM實例啟動日志沒有看到啟動時加載的PROCESSES參數(shù)，說明PROCESSES參數(shù)設(shè)置是默認值。過了一段時間，發(fā)現(xiàn)可以正常登錄ASM實例。查詢PROCESSES初始化參數(shù)，發(fā)現(xiàn)ASM實例的設(shè)置果是SQL>shorameter 01102$ps-ef|grepASM|grep-vgrep|wc–l這時可以登錄ASM實例，說明ASM實例上的有些進程了，檢查ASM啟動的進程數(shù)，$ps-ef|grepASM|grep-vgrep|wc–l根據(jù)這個現(xiàn)象可以確定，這次的問題是由于ASM實例上的進程數(shù)超過初始化參數(shù)PROCESSES的設(shè)置而了解到問題的根源，解決起來就很容易了。修改ASM實例的啟動初始化參數(shù)，給PROCESSES參數(shù)設(shè)置一個較大的值，就可以避免這種情況的產(chǎn)生。不過這也說明了一個問題，Oracle給出的大部分默認參數(shù)的值都偏小，須要用戶建立數(shù)據(jù)庫時手工調(diào)整，ASM實例的參數(shù)也不例外。問題到現(xiàn)在為止還沒有結(jié)束，因為正常情況下，ASM實例是不會有如此多的連接和進程的，須要找到是什么原因?qū)е翧SM產(chǎn)生了大量的連接。首先通過操作系統(tǒng)命令檢查$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這里僅僅是一個測試庫，而且當(dāng)前除了系統(tǒng)的進程外，只有幾個進程在支持rman備份的操作，沒有其他人連接到這個數(shù)據(jù)庫。為什么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行根據(jù)ASM實例上V$SESSION上的PROCESS列，找到連接到ASM實例的操作系統(tǒng)進程。上面的查詢列出了所有非ASM實例進程對應(yīng)的操作系統(tǒng)進程?？梢钥吹剑^大部分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實例的進程，也就是當(dāng)前查詢的進程；另一個是節(jié)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這兩個會話在備份時出現(xiàn)了錯誤，等待了很久都無法自動結(jié)束，最后是通過Ctrl+\強制結(jié)束的。會話異常結(jié)束后，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問題是由于歸檔進程無法創(chuàng)建新的歸檔日志文件而導(dǎo)致的。檢查實例1上的alert文件，發(fā)現(xiàn)問題產(chǎn)生時出現(xiàn)了大量的錯誤：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磁盤組空間耗盡、歸檔失敗開始的。現(xiàn)在檢查失敗歸檔的進程號，發(fā)現(xiàn)就是19969和19995這兩個進程。顯然，Oracle在不斷重試歸檔的過程中出現(xiàn)了一些錯誤，導(dǎo)致歸檔進程連接到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解決問題的最好方法是重啟數(shù)據(jù)庫實例和ASM。如果暫時無法重啟可以按照前面給出的方法另外設(shè)立一個歸檔目的地。不過對于這個特殊 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,系統(tǒng)已SQL>ALTERSYSTEMKILLSESSION'34,系統(tǒng)已SQL>ALTERSYSTEMKILLSESSION'14,系統(tǒng)已更改并通過操作系統(tǒng)命令清除剛才rman失敗造成的兩個進程bash-2.03$bash-2.03$kill-9bash-2.03$kill-9無論是清除Oracle實例的進程23709，還是清除23768進程所對應(yīng)的ASM實例進程28631都可等待一段時間 自動清除所有的進程，數(shù)據(jù)庫恢復(fù)正常bash-2.03$bash-2.03$ps-ef|grepASM|grep-vgrep|wc–lASM空間擴展故障由于RAC的測試環(huán)境空間不足，因此規(guī)劃給ASM擴展空間，然而在給ASM添加新的磁盤空間時又出現(xiàn)空間擴展的操作步驟如下：在RAC環(huán)境的節(jié)點1上啟動了DBCA工具來管理ASM設(shè)備。由于新增的設(shè)備在ASM圖形界面下看不到因此在節(jié)點1上通過root用戶將設(shè)備的權(quán)限授予了操作系統(tǒng)上的Oracle這時，從圖形界面的候選磁盤中已經(jīng)可以看到這些設(shè)備了。通過圖形界面將設(shè)備加到了磁盤組中。但是這個操作了兩個錯誤：分別是ORA-15032和ORA-15075。首先看看在Oracle文檔上是如何描述這兩個錯誤的ORA-15032:notallalterationsCause:AtleastoneALTERDISKGROUPactionAction:ChecktheothermessagesissuedalongwiththissummaryORA-15075:disk(s)arenotvisiblecluster-wideCause:TERDISKGROUPADDDISKcommandspecifiedadiskthatcouldnotbediscoveredbyoneormorenodesinaRACclusterconfiguration.Action:DeterminewhichdisksarecausingtheproblemfromtheGV$OSM_DISKfixedview.Checkoperatingsystempermissionsforthedeviceandthestoragesub-systemconfigurationoneachnodeinaRACclusterthatcannotidentifythedisk.其實ORA-15075錯誤中的信息已經(jīng)足夠明顯了。根據(jù)這個錯誤進行分析應(yīng)該就能很快找到問題的原因。這個錯誤導(dǎo)致了奇怪的現(xiàn)象：根據(jù)錯誤信息判斷，操作已經(jīng)失敗了，但是檢查發(fā)現(xiàn)這些設(shè)備 ASM配置中已經(jīng)可見了當(dāng)正在檢查這兩個錯誤信息時，同事告訴我節(jié)點2上的實例連不上通過操作系統(tǒng)命令檢查發(fā)現(xiàn)數(shù)據(jù)庫實例2已經(jīng)關(guān)閉了，不過這個節(jié)點上的ASM實例仍然存在。這個現(xiàn)象很奇怪：對ASM的操作引起的錯誤，當(dāng)前ASM實例沒有出錯，卻有另外一個數(shù)據(jù)庫實例被關(guān)閉。檢查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=嘗試重啟系統(tǒng)，看看會產(chǎn)生何種錯誤信$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文件中已經(jīng)明顯包含了導(dǎo)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的磁盤組已經(jīng)DISMOUNT了，不過由于當(dāng)時對ASM還不熟悉，所以對ASM的信息沒有過多關(guān)注，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錯誤信息，想當(dāng)然地認為這是導(dǎo)致問題的原因。其實如果查看隨后的啟動報錯信息就可以看出問題：ORA-15077:couldnotlocateASMinstanceservingarequireddiskgroup。Oracle文檔對這個ORA-15077:ORA-15077:couldnotlocateASMinstanceservingarequiredCause:TheinstancefailedtoperformthespecifiedoperationbecauseitcouldnotlocatearequiredASMinstance.Action:StartanASMinstanceandmounttherequired不幸的由于此前剛剛碰到一個Bug，這個Bug的關(guān)鍵報錯信息恰好也是ORA-17503:ksfdopn:2Failedtoopenfile+DISK/testrac/spfiletestrac.ora。于是忽略了以上的關(guān)鍵信息，而把關(guān)注點轉(zhuǎn)移到Bug上，并認為這次碰并嘗試使用本地pfile文件啟動數(shù)據(jù)庫ORACLE例程已經(jīng)啟動。TotalSystemGlobalFixedVariableDatabaseRedoORA-00205:?????????,??????,出現(xiàn)了報錯后，又一次被誤導(dǎo)，去檢查ORA-00205報錯信ORA-00205:errorinidentifyingcontrolfile,checkalertlogformoreinfoCause:ORA-00205:errorinidentifyingcontrolfile,checkalertlogformoreinfoCause:Thesystemcouldnotfindacontrolfileofthespecifiednameandsize.Action:CheckthatALLcontrolfilesareonlineandthattheyarethesamefilesthatthecreatedatcoldstart直到發(fā)現(xiàn)控制文件本身并沒有問題——實例1一直正常運行。這時才自己“誤入歧途仔細檢查所有的報錯信息以及導(dǎo)致錯誤產(chǎn)生的原因——添加磁盤組的操作，終于發(fā)現(xiàn)了問題的真正原因：當(dāng)時在給設(shè)備的時候，只在節(jié)點1進行了，而沒有在節(jié)點2進行，因此節(jié)點1上的DBCA配置的ASM實例可以成功地將設(shè)備加到磁盤組中，而在節(jié)點2上同樣的操作由于缺少權(quán)限，導(dǎo)致了磁盤組DISMOUNT，最終導(dǎo)致了數(shù)據(jù)庫實例的關(guān)閉。于是在節(jié)點2上對設(shè)備進行，重啟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:未裝載數(shù)據(jù)ORACLE例程已經(jīng)關(guān)閉$srvctlstopasm- $srvctlstartasm- $sqlplus"/asSQL*PlusRelease.0Productionon星期四3月2917:55:172007Copyright(c)1982,2005,Oracle.s.SQL>startupTotalSystemGlobalArea2147483648bytesFixed 2030296Variable 469763368Database 1660944384Redo 14745600本來很簡單的一個問題卻大費周折。這個教訓(xùn)說明解決問題的時候須冷靜地分析和判斷，否則很容易被一些其他的信息干擾而誤入歧途，從而導(dǎo)致在解決問題時走上彎路。ASM創(chuàng)建表空間之ORA-569錯誤在一個測試數(shù)據(jù)庫上創(chuàng)建表空間出現(xiàn)了ORA-569錯誤。由于環(huán)境比較復(fù)雜，首先簡單描述一下數(shù)據(jù)庫環(huán)境信息。這個測試環(huán)境安裝的是Oracle1106forSolaris10sparc64bit的RAC環(huán)境，使用ASM作為共享數(shù)據(jù)文件的機制。在RAC環(huán)境的一個節(jié)點上還建立了一個單實例的數(shù)據(jù)庫，并把這個數(shù)據(jù)庫的數(shù)據(jù)文件也放到了ASM實上在這個單實例數(shù)據(jù)庫上添加新的表空間錯，代碼如下：SQL>selectfile_namefromdba_data_files;SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m;createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m*第1行出現(xiàn)錯誤ORA-01119:創(chuàng)建數(shù)據(jù)庫文件'+DATA/test/datafile/test01.dbf'時出錯ORA-17502ksfdcre4未能創(chuàng)建文件+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.文檔雖然對問題進行了描述，不過從對錯誤信息和問題描述中看不出導(dǎo)致問題的真正原因查詢了一下Metalink，從中找到了一些關(guān)于ORA-569的錯誤說明。不過這些問題都和當(dāng)前錯誤有很大的不同：大部分出現(xiàn)這個錯誤的同時都會伴隨ORA-600錯誤和ORA-4031錯誤?？磥斫柚鶰etalink解決這個問題的希望落空，只能自己想辦法前面已經(jīng)提到當(dāng)前環(huán)境比較復(fù)雜，這個節(jié)點上啟動了兩個實例。一個是單實例的數(shù)據(jù)庫，另一個 數(shù)據(jù)庫中的一個節(jié)點，而且兩個數(shù)據(jù)庫的數(shù)據(jù)文件都在相同 磁盤組中問題都有兩面性，環(huán)境復(fù)雜也有復(fù)雜的好處，現(xiàn)在有一個簡單的方法可以確定到底是數(shù)據(jù)庫產(chǎn)生的問題還是ASM實例導(dǎo)致的問題：只需要登錄RAC實例，執(zhí)行類似的添加表空間的操作，就可檢查是否會出現(xiàn)相同的錯誤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數(shù)據(jù)庫裝載完畢數(shù)據(jù)庫已經(jīng)打開SQL>CREATETABLESPACETESTDATAFILE'+DATA/ractest/datafile/test01.dbf'SIZE4096M;CREATETABLESPACETESTDATAFILE'+DATA/ractest/datafile/test01.dbf'SIZE4096M*第1行出現(xiàn)錯誤ORA-01119:創(chuàng)建數(shù)據(jù)庫文件'+DATA/ractest/datafile/test01.dbf'時出錯ORA-17502ksfdcre4未能創(chuàng)建文件+DATA/ractest/datafile/test01.dbfORA-00569:Failedtoacquireglobalenqueue.ORA-00569:Failedtoacquireglobal相同的錯誤產(chǎn)生了，說明問題多半與ASM實例的狀態(tài)有關(guān)系。登錄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實例可以用來檢查的動態(tài)視圖太少了，從現(xiàn)有的視圖也看不到什么特別的地方。實在沒有什么太好的查錯辦法，只能重啟數(shù)據(jù)庫和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實例已關(guān)閉SQLstartupASMTotalSystemGlobalFixedVariableASMASMdiskgroupsbash-3.00$exportORACLE_SID=testbash-3.00$sqlplus"/assysdba"SQL>startupORACLE例程已經(jīng)啟動SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m;createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size4096m*第1行出現(xiàn)錯誤ORA-01119:創(chuàng)建數(shù)據(jù)庫文件'+DATA/test/datafile/test01.dbf'時出錯ORA-17502ksfdcre4未能創(chuàng)建文件+DATA/test/datafile/test01.dbfORA-00569:Failedtoacquireglobalenqueue.ORA-00569:Failedtoacquireglobal可以看到重啟ASM實例后問題仍然出現(xiàn)。不過ASM實例也是在兩個節(jié)點上同時運行的，莫非是在另一個節(jié)點的ASM實例出現(xiàn)了問題：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數(shù)據(jù)庫，執(zhí)行CREATETABLESPACE語句bash-3.00$bash-3.00$exportORACLE_SID=testbash-3.00$sqlplus"/assysdba"SQL>setpages100lines120SQL>createtablespacetestdatafile'+DATA/test/datafile/test01.dbf'size表空間看來問題果然和ASM實