#
在VM Manager中搜索VM Server時出現(xiàn)這個錯誤。
按照VM Server以及VM Manager后,通過指定IP地址,讓VM Manager自動尋找VM Server,結(jié)果JOB運行報錯,詳細(xì)的錯誤信息為:
Job Construction Phase
----------------------
begin()
Appended operation 'Discover Manager Server Discover'tb to object 'OVM Foundry : Discover Manager'.
commit()
Completed Step: COMMIT
Objects and Operations
----------------------
Object (IN_USE): [Server] 35:38:33:39:31:34:43:4e:47:31:33:30:53:37:33:42 (server2.zihexin.com)
Object (IN_USE): [DiscoverManager] OVM Foundry : Discover Manager
Operation: Discover Manager Server Discover
Job Running Phase at 18:05 on Fri, Nov 25, 2011
----------------------------------------------
Job Participants: []
Actioner
--------
Starting operation 'Discover Manager Server Discover' on object 'OVM Foundry : Discover Manager'
Setting Context to model only in job with id=1322215534120
Job Internal Error (Operation)com.oracle.ovm.mgr.api.exception.FailedOperationException: OVMAPI_4010E Attempt to send command: discover_server to server: 10.0.10.171 failed. OVMAPI_4004E Server Failed Command: discover_server, Status:
Fri Nov 25 18:05:34 CST 2011
Fri Nov 25 18:05:34 CST 2011
at com.oracle.ovm.mgr.action.ActionEngine.sendCommandToServer(ActionEngine.java:474)
at com.oracle.ovm.mgr.action.ActionEngine.sendDiscoverCommand(ActionEngine.java:283)
at com.oracle.ovm.mgr.action.ServerAction.getServerInfo(ServerAction.java:95)
at com.oracle.ovm.mgr.discover.ovm.ServerBasicDiscoverHandler.query(ServerBasicDiscoverHandler.java:131)
at com.oracle.ovm.mgr.discover.ovm.ServerBasicDiscoverHandler.query(ServerBasicDiscoverHandler.java:61)
at com.oracle.ovm.mgr.discover.ovm.DiscoverHandler.execute(DiscoverHandler.java:50)
at com.oracle.ovm.mgr.discover.DiscoverEngine.handleDiscover(DiscoverEngine.java:435)
at com.oracle.ovm.mgr.discover.DiscoverEngine.discoverNewServer(DiscoverEngine.java:345)
at com.oracle.ovm.mgr.discover.DiscoverEngine.discoverServer(DiscoverEngine.java:265)
at com.oracle.ovm.mgr.op.manager.DiscoverManagerServerDiscover.action(DiscoverManagerServerDiscover.java:48)
at com.oracle.ovm.mgr.api.job.JobEngine.operationActioner(JobEngine.java:191)
at com.oracle.ovm.mgr.api.job.JobEngine.objectActioner(JobEngine.java:257)
at com.oracle.ovm.mgr.api.job.InternalJobDbImpl.objectCommitter(InternalJobDbImpl.java:1019)
at com.oracle.odof.core.AbstractVessel.invokeMethod(AbstractVessel.java:223)
at com.oracle.odof.core.BasicWork.invokeMethod(BasicWork.java:136)
at com.oracle.odof.command.InvokeMethodCommand.process(InvokeMethodCommand.java:100)
at com.oracle.odof.core.BasicWork.processCommand(BasicWork.java:81)
at com.oracle.odof.core.TransactionManager.processCommand(TransactionManager.java:751)
at com.oracle.odof.core.WorkflowManager.processCommand(WorkflowManager.java:395)
at com.oracle.odof.core.WorkflowManager.processWork(WorkflowManager.java:453)
at com.oracle.odof.io.AbstractClient.run(AbstractClient.java:42)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.oracle.ovm.mgr.api.exception.IllegalOperationException: OVMAPI_4004E Server Failed Command: discover_server, Status:
Fri Nov 25 18:05:34 CST 2011
at com.oracle.ovm.mgr.action.ActionEngine.sendAction(ActionEngine.java:752)
at com.oracle.ovm.mgr.action.ActionEngine.sendCommandToServer(ActionEngine.java:470)
... 24 more
FailedOperationCleanup
----------
Starting failed operation 'Discover Manager Server Discover' cleanup on object 'OVM Foundry : Discover Manager'
Complete rollback operation 'Discover Manager Server Discover' completed with direction=OVM Foundry : Discover Manager
Rollbacker
----------
Objects To Be Rolled Back
-------------------------
Object (IN_USE): [Server] 35:38:33:39:31:34:43:4e:47:31:33:30:53:37:33:42 (server2.zihexin.com)
Object (IN_USE): [DiscoverManager] OVM Foundry : Discover Manager
Completed Step: ROLLBACK
Job failed commit (internal) due to OVMAPI_4010E Attempt to send command: discover_server to server: 10.0.10.171 failed. OVMAPI_4004E Server Failed Command: discover_server, Status:
Fri Nov 25 18:05:34 CST 2011
Fri Nov 25 18:05:34 CST 2011
com.oracle.ovm.mgr.api.exception.FailedOperationException: OVMAPI_4010E Attempt to send command: discover_server to server: 10.0.10.171 failed. OVMAPI_4004E Server Failed Command: discover_server, Status:
Fri Nov 25 18:05:34 CST 2011
Fri Nov 25 18:05:34 CST 2011
at com.oracle.ovm.mgr.action.ActionEngine.sendCommandToServer(ActionEngine.java:474)
at com.oracle.ovm.mgr.action.ActionEngine.sendDiscoverCommand(ActionEngine.java:283)
at com.oracle.ovm.mgr.action.ServerAction.getServerInfo(ServerAction.java:95)
at com.oracle.ovm.mgr.discover.ovm.ServerBasicDiscoverHandler.query(ServerBasicDiscoverHandler.java:131)
at com.oracle.ovm.mgr.discover.ovm.ServerBasicDiscoverHandler.query(ServerBasicDiscoverHandler.java:61)
at com.oracle.ovm.mgr.discover.ovm.DiscoverHandler.execute(DiscoverHandler.java:50)
at com.oracle.ovm.mgr.discover.DiscoverEngine.handleDiscover(DiscoverEngine.java:435)
at com.oracle.ovm.mgr.discover.DiscoverEngine.discoverNewServer(DiscoverEngine.java:345)
at com.oracle.ovm.mgr.discover.DiscoverEngine.discoverServer(DiscoverEngine.java:265)
at com.oracle.ovm.mgr.op.manager.DiscoverManagerServerDiscover.action(DiscoverManagerServerDiscover.java:48)
at com.oracle.ovm.mgr.api.job.JobEngine.operationActioner(JobEngine.java:191)
at com.oracle.ovm.mgr.api.job.JobEngine.objectActioner(JobEngine.java:257)
at com.oracle.ovm.mgr.api.job.InternalJobDbImpl.objectCommitter(InternalJobDbImpl.java:1019)
at sun.reflect.GeneratedMethodAccessor1001.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.oracle.odof.core.AbstractVessel.invokeMethod(AbstractVessel.java:223)
at com.oracle.odof.core.BasicWork.invokeMethod(BasicWork.java:136)
at com.oracle.odof.command.InvokeMethodCommand.process(InvokeMethodCommand.java:100)
at com.oracle.odof.core.BasicWork.processCommand(BasicWork.java:81)
at com.oracle.odof.core.TransactionManager.processCommand(TransactionManager.java:751)
at com.oracle.odof.core.WorkflowManager.processCommand(WorkflowManager.java:395)
at com.oracle.odof.core.WorkflowManager.processWork(WorkflowManager.java:453)
at com.oracle.odof.io.AbstractClient.run(AbstractClient.java:42)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.oracle.ovm.mgr.api.exception.IllegalOperationException: OVMAPI_4004E Server Failed Command: discover_server, Status:
Fri Nov 25 18:05:34 CST 2011
at com.oracle.ovm.mgr.action.ActionEngine.sendAction(ActionEngine.java:752)
at com.oracle.ovm.mgr.action.ActionEngine.sendCommandToServer(ActionEngine.java:470)
... 24 more
----------
End of Job
----------
由于關(guān)鍵性信息確實,所以無法判斷導(dǎo)致錯誤的原因。即使是在metalink或GOOGLE中查詢,也得不到任何有價值的信息。
雖然在VM Manager中得不到有意義的信息,但是在VM Server上,卻可以得到更詳細(xì)的信息,通過檢查var/log/ovs-agent.log文件,獲取到下面的信息:
[2011-04-16 13:21:46 25970] ERROR (OVSAgentServer:108) Unauthorized access attempt from ('10.0.10.173', 59424)!
Traceback (most recent call last):
File "/opt/ovs-agent-3.0/OVSAgentServer.py", line 103, in do_POST
auth(username, password)
File "/opt/ovs-agent-3.0/OVSAgentServer.py", line 42, in auth
raise Exception('Authorization failed: user does not exist or password error.')
Exception: Authorization failed: user does not exist or password error.
[2011-04-16 13:21:46 25970] INFO (OVSAgentServer:169) code 403, message Unauthorized access attempt from ('10.0.10.173', 59424)!
這次信息就明確多了,顯然是由于VM Manager中配置的密碼不正確所致,在VM Server上修改oracle用戶密碼:
[root@server2 ~]# ovs-agent-passwd oracle
Password:
Again:
在搜索VM Server時使用這里修改的密碼,VM Manager成功的發(fā)現(xiàn)了VM Server信息。
簡單描述一下Oracle VM Server的安裝過程。
需要注意,VM 3.0以上版本才支持升級操作,因此在VM 2.2沒有辦法升級到當(dāng)前版本,安裝VM 3.0將會刪除服務(wù)器上所有的數(shù)據(jù)。
將VM Server的光盤放入,并從光盤啟動服務(wù)器。
在啟動界面直輸入Enter開始安裝過程:
Oracle會提示是否監(jiān)測截至,這里可以直接SKIP跳過;
鍵盤選擇:選擇us;
然后是版權(quán)聲明,選擇Accept后,開始正式的安裝步驟;
如果服務(wù)器上沒有系統(tǒng),那么會直接進(jìn)入后面的分區(qū)階段,否則會提示重裝系統(tǒng)還是在原有系統(tǒng)上升級;
選擇ReInstall后,會顯示當(dāng)前系統(tǒng)磁盤分區(qū)信息,首先選擇準(zhǔn)備進(jìn)行系統(tǒng)安裝的分區(qū),然后選擇Remove tb all partitions and create a new default partition layout,Oracle在格式化分區(qū)之前會要求再次確認(rèn),并詢問是否預(yù)覽分區(qū)空間詳細(xì)配置,可以完全按照默認(rèn)推薦值安裝,因此這里可以跳過,也可以進(jìn)入到分區(qū)空間修改頁面進(jìn)行自定義的修改;
隨后選擇Boot Loader配置,選擇Master Boot Record;
然后選擇一個管理網(wǎng)絡(luò)接口,手工輸入IP和掩碼,在下一個頁面輸入網(wǎng)關(guān)、DNS信息,接著是主機名信息;
配置服務(wù)器所在時區(qū),配置中找不到北京,可以設(shè)置Asia/Shanghai代替;
分別輸入Agent密碼和root密碼后,安裝操作完成,這是會提示整個安裝的日志文件的位置。
在重啟界面選擇REBOOT,完成整個安裝過程。
啟動后,進(jìn)入Oracle VM Server 3.0控制臺界面,可以通過Alt + F2進(jìn)入linux的登錄界面。至此VM Server安裝完成。
客戶的10.2.0.4 RAC for Hp-un環(huán)境碰到了這個錯誤。
錯誤信息為:
Wed Feb 29 19:42:05 2012
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_11261.trc:
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM TB
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:42:05 2012
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_32036.trc:
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:42:05 2012
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_5935.trc:
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:42:05 2012
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_5026.trc:
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:42:05 2012
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_7620.trc:
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:42:08 2012
Trace dumping is performing id=[cdmp_20120229194207]
Wed Feb 29 19:42:17 2012
Trace dumping is performing id=[cdmp_20120229194217]
這個ORA-600[qersqCloseRem-2]錯誤非常罕見, TB MOS上居然沒有任何記載。不過從錯誤信息進(jìn)行進(jìn)一步的分析,這個錯誤發(fā)生在遠(yuǎn)端數(shù)據(jù)庫的訪問異常。
檢查進(jìn)一步的詳細(xì)信息:
*** 2012-02-29 19:42:05.564
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [qersqCloseRem-2], [Invalid Handle], [], [], [], [], [], []
ORA-02068: following severe error from WEBDB.COM
ORA-03113: end-of-file on communication channel
Current SQL statement for this session:
SELECT ACCESS_LOG_SEQUENCE.NEXTVAL@WEBDB.COM FROM DUAL
----- PL/SQL Call Stack -----
object line object
handle number name
0x39b5c3720 5 ECOMMERCE.P_USER_AT
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FBFFF4370 ? 7FBFFF43D0 ?
7FBFFF4310 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FBFFF4370 ? 7FBFFF43D0 ?
7FBFFF4310 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FBFFF4370 ? 7FBFFF43D0 ?
7FBFFF4310 ? 000000000 ?
.
.
.
0059DF200 ? 683F6E400000001 ?
main()+116 call opimai_real() 000000002 ? 7FBFFFF4E0 ?
000000004 ? 7FBFFFF478 ?
0059DF200 ? 683F6E400000001 ?
__libc_start_main() call main() 000000002 ? 7FBFFFF4E0 ?
+219 000000004 ? 7FBFFFF478 ?
0059DF200 ? 683F6E400000001 ?
_start()+42 call __libc_start_main() 0007139F8 ? 000000002 ?
7FBFFFF628 ? 0052B4BD0 ?
000000000 ? 000000002 ?
--------------------- Binary Stack Dump ---------------------
從詳細(xì)TRACE分析,在問題發(fā)生時刻,正在通過數(shù)據(jù)庫鏈讀取遠(yuǎn)端序列的值。而此時出現(xiàn)的ORA-3113通信錯誤,多半與遠(yuǎn)端數(shù)據(jù)庫狀態(tài)異常有關(guān)。
檢查遠(yuǎn)端數(shù)據(jù)庫的告警日志,果然發(fā)現(xiàn)在問題出現(xiàn)時刻,數(shù)據(jù)庫狀態(tài)異常并最終導(dǎo)致了實例重啟:
Wed Feb 29 19:39:29 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:39:30 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:40:01 2012
WARNING: inbound connection timed out (ORA-3136)
.
.
.
Wed Feb 29 19:43:28 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:28 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:28 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:28 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:29 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:29 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:29 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:29 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:43:30 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:45:26 2012
PMON failed to acquire latch, see PMON dump
Wed Feb 29 19:46:32 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:46:33 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:46:34 2012
PMON failed to acquire latch, see PMON dump
Wed Feb 29 19:46:40 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:46:43 2012
WARNING: inbound connection timed out (ORA-3136)
Wed Feb 29 19:46:44 2012
Errors in file /opt/app/oracle/admin/orcl/bdump/orcl1_asmb_14614.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Wed Feb 29 19:46:44 2012
ASMB: terminating instance due to error 15064
Wed Feb 29 19:46:44 2012
System state dump is made for local instance
System State dumped to trace file /opt/app/oracle/admin/orcl/bdump/orcl1_diag_14555.trc
Wed Feb 29 19:46:47 2012
Shutting down instance (abort)
License high water mark = 1623
Wed Feb 29 19:46:49 2012
Instance terminated by ASMB, pid = 14614
Wed Feb 29 19:46:52 2012
Instance terminated by USER, pid = 3684
顯然遠(yuǎn)端數(shù)據(jù)庫狀態(tài)異常是這個ORA-600錯誤的直接原因。
基于版本的重定義
Oracle 11g R2增加了一個強大的新工具,它可以檢出應(yīng)用程序數(shù)據(jù)庫對象的任一版本,不是所有數(shù)據(jù)庫對象都支持版本化管理,但私有的同義詞,視圖和幾乎所有的PL/SQL對象,包括存儲過程、函數(shù)、類型、類型主體、包、包主體和觸發(fā)器,版本化管理的真正好處是簡化了部署一個修改版本的應(yīng)用程序代碼到生產(chǎn)數(shù)據(jù)庫,如果部署時遇到一系列的錯誤,可以很容易地將所有影響的對象回滾到上一個版本。
消除了閃回數(shù)據(jù)歸檔上的DDL限制
在前一篇文章中,我深入研究了Oracle 11g R1的新特性“閃回數(shù)據(jù)歸檔(Flashback Data Archive,F(xiàn)BDA)”,它也被稱為“全部召回(Total Recall)”,它只捕獲變化的數(shù)據(jù),將這些數(shù)據(jù)放在一套特殊的對象中,它們構(gòu)成了FBDA,當(dāng)用戶通過閃回版本查詢(Flashback Versions query)查詢表的歷史記錄時,Oracle將會直接從數(shù)據(jù)庫的UNDO表空間返回最近變化的數(shù)據(jù),從FBDA返回更舊的數(shù)據(jù)。
雖然這個特性很好,但在早期版本中也有很多限制,包括增加、修改、重命名、刪除表的列、truncate表、修改表的約束、以及修改分區(qū)表的分區(qū)規(guī)范,在Oracle 11g R2中,這些限制全部沒有了,對于更復(fù)雜的DDL操作,如使用DBMS_REDEFINITION包重定義已經(jīng)存儲到FBDA的基礎(chǔ)表,Oracle 11g R2提供了新的DBMS_FLASHBACK_ARCHIVE包,存儲過程DISASSOCIATE_FBA將會把基礎(chǔ)表從FBDA中分離出來,一旦請求的改變完成,存儲過程REASSOCIATE_FBA會被用來重新關(guān)聯(lián)修改的表和基礎(chǔ)表。
按需創(chuàng)建分段
在之前的版本中,使用CREATE TABLE語句創(chuàng)建表時,會同時自動創(chuàng)建表的初始段,從Oracle 11gR2開始,這個默認(rèn)的行為有所變化,創(chuàng)建表時不會創(chuàng)建初始段,直到有數(shù)據(jù)插入到這個表。此外,任何依賴于該表的索引或LOB段也不會創(chuàng)建,直到有數(shù)據(jù)插入才會創(chuàng)建,表的SEGMENT CREATION DEFERRED存儲屬性指定了這個默認(rèn)行為,但可以使用SEGMENT CREATION IMMEDIATE屬性覆蓋它。
不可用索引大小歸零
在重新載入大表時,比如一個有上百萬行的數(shù)據(jù)倉庫事實表,要提高這種表的加載速度,最簡單的辦法是將該表上的所有索引置為不可用,在數(shù)據(jù)加載完畢后,在重建這些索引,Oracle 11g R2認(rèn)可了這一做法,并采取了實質(zhì)性的措施,tb當(dāng)索引被標(biāo)記為不可用時,它會自動刪除所有索引段。
小結(jié)
Oracle 11g R2延續(xù)了自O(shè)racle 10g以來令人稱道的自我管理,自我調(diào)整,自我治愈的特性,這個新版本提供了太多的新特性,有些是遲來的功能,有些是革新,Oracle DBA可以借助這些新特性提高工作效率,成為一名真正的“信息工程師”。
2009年9月Oracle公司發(fā)布了期待已久的Oracle 11g R2,本系列文章將給讀者一一揭開新版本中的新特性,并會介紹企業(yè)如何利用這些新特性將現(xiàn)有的Oracle 9i,10g,11g R1升級到Oracle 11g R2.
經(jīng)歷了難以忍受的長時間等待,Oracle公司突然在9月1發(fā)布了Oracle 11g R2,我不得不承認(rèn)Oracle的保密工作做得多么好,我相信Oracle公司選擇這個時候發(fā)布時為了刺激參加Oracle OpenWorld 2009大會的人興奮和期待。
經(jīng)過四處搜索Oracle 11g R2新特性文檔,并體驗了新的OUI(Oracle通用安裝程序),創(chuàng)建了我的第一個單實例RAC后,我總結(jié)一下Oracle 11g R2中我最喜歡的五大新特性。在后面的文章中我將陸續(xù)介紹其它新特性,請鎖定本系列文章。
NO.1 隨處可見的集群
在以前的版本中,Oracle Clusterware必須要獨立地安裝在它自己的ORACLE HOME中,并且也只能在RAC環(huán)境下使用,這一切在Oracle 11g R2得到徹底顛覆,因為在這個版本中支持安裝Oracle網(wǎng)格基礎(chǔ)架構(gòu),而且只需要一個獨立的ORACLE HOME,它包括了Oracle Clusterware和Oracle自動存儲管理(ASM)。通過升級后的Oracle通用安裝程序安裝了網(wǎng)格基礎(chǔ)架構(gòu)后,你將會看到一個全新的功能和服務(wù)矩陣,我簡單地列舉幾個吧:
單實例RAC(Oracle重啟):聽起來似乎自相矛盾,但Oracle 11g R2擴(kuò)展了Oracle Clusterware的功能,為任何單實例提供了高可用特性,本質(zhì)上是將數(shù)據(jù)庫變成了單實例RAC數(shù)據(jù)庫。Oracle 11g R2中的Oracle重啟特性幫助Oracle網(wǎng)格基礎(chǔ)架構(gòu)的高可用服務(wù)控制服務(wù)器重啟時哪一個監(jiān)聽器,ASM實例和數(shù)據(jù)庫應(yīng)該啟動,它完全取代了過去DBA們經(jīng)常用到的DBSTART腳本。同樣,當(dāng)單個數(shù)據(jù)庫實例崩潰或其它異常終止時,Oracle重啟功能會自動監(jiān)測失效的實例,并自動重啟它,就好像是在一個真實的RAC環(huán)境中一樣。
SRVCTL升級:如果你管理過舊版本的RAC環(huán)境,你可能已經(jīng)熟悉了RAC環(huán)境中的維護(hù)工具SRVCTL,在11g R2中,該工具被擴(kuò)展了,現(xiàn)在可以管理單實例RAC,以及監(jiān)聽器和ASM實例。
集群時間同步服務(wù):Oracle 11g R2現(xiàn)在需要在所有RAC節(jié)點上配置時間同步,如果你曾經(jīng)經(jīng)歷過某個節(jié)點被驅(qū)逐出RAC集群配置,你一定知道其難度有多大,特別是兩個服務(wù)器的時間不同步和日志文件的時間戳不同步時,Oracle之前的版本借助系統(tǒng)提供的網(wǎng)絡(luò)時間協(xié)議(NTP)同步所有節(jié)點時間,但這需要連接到互聯(lián)網(wǎng)上的標(biāo)準(zhǔn)時間服務(wù)器,作為NTP的替代者,Oracle 11g R2提供了一個新的集群時間同步服務(wù),確保集群中的所有節(jié)點的時間都保持一致。
網(wǎng)格即插即用:在以前的版本中,配置RAC最復(fù)雜的部分是確定和設(shè)置所有節(jié)點都需要用到的公共ip地址,私有ip地址和虛擬ip地址。為了簡化RAC的安裝,Oracle 11g R2提供了一個全新的網(wǎng)格名稱服務(wù)(GNS),它和域名服務(wù)器協(xié)作,處理每個網(wǎng)格組件的ip地址分配,當(dāng)集群環(huán)境跨越多個數(shù)據(jù)庫時這個新特性極其有用。
干凈地卸載RAC組件:如果你曾經(jīng)嘗試過刪除多個節(jié)點上的所有RAC痕跡,那一定會鐘情于這項新特性,在Oracle 11g R2中,所有安裝和配置助手,特別是Oracle通用安裝程序(OUI),數(shù)據(jù)庫配置助手(DBCA)和網(wǎng)絡(luò)配置助手(NETCA),都得到了增強,當(dāng)需要卸載RAC組件時,可以保證卸得干干凈凈。
NO.2 ASM加入了集群
Oracle 11g R2 ASM充滿了許多吸引人的新特性,對于初學(xué)者來說,ASM和Oracle 11g R2 Clusterware安裝在同一個Oracle Home下,因此消除了之前推薦的冗余Oracle Home安裝方法,并且ASM也從DBCA脫離出來了,有了專門的自動存儲管理配置助手(ASMCA)。下面是我認(rèn)為最有趣的ASM新特性:
智能化數(shù)據(jù)布局:在之前的版本中,要配置ASM磁盤可能需要存儲管理員的參與,需要配置磁盤I/O子系統(tǒng),Oracle 11g R2提供了ASM分配單元,可以直接受益于磁盤外緣柱面,獲得更快的速度,可以將數(shù)據(jù)文件,重做日志文件和控制放在磁盤外緣獲得更好的性能。
EM支持工作臺擴(kuò)展:在這個版本中對Oracle 11g R1引入到企業(yè)管理控制臺中的自動診斷倉庫(ADR)進(jìn)行了擴(kuò)展,包括支持ASM診斷,將所有診斷信息打包直接發(fā)送給Oracle技術(shù)支持,以便獲得更快速的ASM性能問題解決方案。
ASMCMD增強:自動存儲管理命令行實用工具(ASMCMD)也獲得了不少增強,包括:
1)啟動和停止ASM實例;
2)備份,恢復(fù)和維護(hù)ASM實例的服務(wù)器參數(shù)文件(spfile);
3)實用iostat監(jiān)控ASM磁盤組的性能;
4)維護(hù)新的ASM集群文件系統(tǒng)(ACFS)中的磁盤卷,目錄和文件存儲,我的下一個話題就是它。
NO.3 ACFS – 一個強健的集群文件系統(tǒng)
Oracle之前也發(fā)布過集群文件系統(tǒng)(OCFS),之后又發(fā)布了增強版OCFS2,它讓Oracle RAC實例可以通過共享存儲讀寫數(shù)據(jù)庫文件,重做日志文件和控制文件。
此外,OCFS也允許RAC數(shù)據(jù)庫的Oracle集群注冊文件(OCR)和表決磁盤存儲在集群文件系統(tǒng)中,在Oracle 10g R2中,這個需求被取消了,OCR文件和表決磁盤可以存儲在裸設(shè)備或裸塊設(shè)備中,如果你曾經(jīng)在原始設(shè)備上丟失過這些文件的所有副本,你一定了解要恢復(fù)它們是多么繁瑣,因此,在Oracle 11g R2中,將不再支持將這些文件存儲在裸設(shè)備上。
為了提高這些關(guān)鍵文件的存活能力,Oracle 11g R2正式引入了一種新的集群文件系統(tǒng),稱之為ASM集群文件系統(tǒng)(ACFS),在RAC環(huán)境中,ACFS可以為OCR文件和表決磁盤提供更好的保護(hù),它允許創(chuàng)建五份OCR文件副本,tb之前的集群文件系統(tǒng)僅允許保存兩份OCR文件,一個主OCR,一個鏡像OCR,但ACFS不適合單獨的RAC環(huán)境,除此之外,幾乎所有與操作系統(tǒng)和數(shù)據(jù)相關(guān)的文件都可以從ACFS的安全性和文件共享特性受益。
動態(tài)卷管理器:Oracle 11g R2提供了一個新的ASM動態(tài)卷管理器(ADVM)來配置和維護(hù)存儲在ACFS文件系統(tǒng)中的文件,使用ADVM可以在ASM磁盤組內(nèi)構(gòu)建一個ADVM卷設(shè)備,管理存儲在ADVM卷設(shè)備中的文件,以及按需調(diào)整ADVM卷設(shè)備空間大小,最重要的是,因為ADVM是構(gòu)建在ASM文件系統(tǒng)架構(gòu)之上的,可以保證存儲在這些卷中的文件受到良好的保護(hù),不會出現(xiàn)意外丟失,因為ASM提供了類似RAID的磁盤陣列的功能。
文件訪問控制:使用傳統(tǒng)的Windows風(fēng)格訪問控制列表(ACL)或Unix/Linux下的用戶/組/其它訪問權(quán)限風(fēng)格為ACFS目錄和文件授予讀,寫和執(zhí)行權(quán)限,可以通過圖形化的企業(yè)管理控制臺或命令行程序ASMCMD管理ACFS目錄和文件安全。
文件系統(tǒng)快照(FSS):Oracle 11g R2通過它的文件系統(tǒng)快照(FSS)功能可以對ACFS文件系統(tǒng)執(zhí)行快照,一個快照是所選ACFS文件系統(tǒng)的一個只讀副本,對相同的ACFS,它會自動保留63個獨立的ACFS快照,當(dāng)某個ACFS文件被不經(jīng)意地更新,刪除或其它危險操作時,這個特性非常有用,利用11g R2企業(yè)管理控制臺或ACFS acfsutil命令行工具可以找出該文件合適的版本并執(zhí)行恢復(fù)。
NO.4 改善的軟件安裝和打補丁過程
我發(fā)現(xiàn)作為一名DBA壓力最大的活就是給Oracle數(shù)據(jù)庫打補丁了,如果補丁可能會引入對數(shù)據(jù)庫有害的行為,我不得不花費大量的時間和精力來確定和審核,因此我對Oracle 11g R2中提供的新功能感到很歡喜。
集群驗證實用程序集成:從Oracle 10g開始引入了集群驗證實用程序(CVU),現(xiàn)在已經(jīng)完全集成到Oracle通用安裝程序(OUI)和其它配置助手(如DBCA,DBUA)中了。
零停機修補的集群:當(dāng)為Oracle集群打補丁時,Oracle 11g R2在一個不合適的位置升級方式應(yīng)用補丁,這意味著會有兩個Oracle Home,其中一個專門用來存放補丁的,但一次只能激活一個Oracle Home,在Oracle 11g R2中不用再為升級全部關(guān)閉Oracle集群了,實現(xiàn)真正的零停機打補丁。
NO.5 DBMS_SCHEDULER升級
古老的DBMS_SCHEDULER包得到了徹底的更新,DBA經(jīng)常使用這個包來調(diào)度作業(yè)。
文件監(jiān)視器:以前的版本無法在批處理過程中檢測大多數(shù)觸發(fā)事件,如檢測一個文件抵達(dá)某個目錄,在Oracle 11g R2中,使用新的文件監(jiān)視器可以緩解這個問題,一旦預(yù)期的文件抵達(dá)目錄,DBMS_SCHEDULER現(xiàn)在就可以檢測到了,并在新的對象類型SCHEDULER_FILEWATCHER_RESULT中注冊它的到來,它通過新的CREATE_FILE_WATCHER存儲過程向DBMS_SCHEDULER發(fā)送一個信號觸發(fā)作業(yè)。
內(nèi)置的email通知:無論何時,DBMS_SCHEDULER調(diào)度任務(wù)啟動、失敗或完成時,任務(wù)的狀態(tài)可以立即通過email發(fā)送出去,雖然在以前的版本中也能實現(xiàn)這個功能,但要么調(diào)用DBMS_MAIL存儲過程,要么調(diào)用DBMS_SMTP存儲過程,現(xiàn)在這個功能合并到DBMS_SCHEDULER中了。
遠(yuǎn)程作業(yè):DBMS_SCHEDULER現(xiàn)在允許DBA在遠(yuǎn)程數(shù)據(jù)庫上創(chuàng)建和調(diào)度作業(yè),現(xiàn)在我終于可以在生產(chǎn)庫PROD03上通過DBMS_SCHEDULER調(diào)用生產(chǎn)庫DBMS_SCHEDULER上的存儲過程執(zhí)行任務(wù)了,這意味著我現(xiàn)在可以在一臺數(shù)據(jù)庫上集中tb創(chuàng)建和維護(hù)調(diào)度任務(wù)了。
多作業(yè)目標(biāo):最后,現(xiàn)在可以在多個數(shù)據(jù)庫實例上同時調(diào)度DBMS_SCHEDULER任務(wù)了,在RAC環(huán)境中,這個特性非常有用,因為我可以利用多個數(shù)據(jù)庫實例將長時間運行任務(wù)分成幾部分,分別在不同的數(shù)據(jù)庫實例上執(zhí)行更小的任務(wù)。
使用IBM DB2 for z/OS和DB2 for Linux,UNIX和Windows (LUW),那就沒有問題,下面讓我們一起回顧一下什么時候使用XML存儲,以及如何自定義XML存儲的一些最佳實踐吧!
為了形象地說明,我將使用一個XML文檔,內(nèi)容如下:
- <order OrderID="9001" OrderDate="2009-10-18">>
- <customerID>26914</customerID>
- <item id="LK-486">
- <name>Magictb Potion</name>
- <size>300ml</size>
- <price>19.99</price>
- </item>
- <item id="VF-145">
- <name>Crystal Ball, Deluxe</name>
- <color>crystal clear</color>
- <price>295.00</price>
- </item>
- </order>
它展示了一個包括訂單ID,日期,客戶ID和其它條目的訂單XML文檔,注意有些條目的描述方式有所不同,如size和color。我們假設(shè)需要在DB2中管理許多與此類似的XML文檔。
如何拆分和重組XML
我在另一篇文章“15個DB2 pureXML性能最佳實踐”中談到了你應(yīng)該明智地選擇文檔的粒度,實際上就是要將存儲在DB2中的XML文檔與應(yīng)用程序的業(yè)務(wù)邏輯對象和主要的訪問粒度匹配。
在我們的例子中,假設(shè)訂單變化非常頻繁,訂單內(nèi)的條目讀取,添加或刪除是最關(guān)鍵的操作,需要最佳的性能,在這種情況下,你可以考慮將訂單文檔拆分,將每一個條目作為一個獨立的文檔存儲到DB2表的每一行中,這個存儲方法(與原來的完整存儲訂單文檔的方法相比)的好處是它使得操作所存儲的數(shù)據(jù)更容易,更快速:
可以使用單行讀取檢索一個條目,不用從一個完整的訂單文檔中抽取條目了;
可以通過刪除表中的行簡單地從訂單中刪除一個條目,不再需要操作完整的訂單文檔;
可以迅速插入一個新條目到訂單中,這時也不需要操作完整的訂單文檔。
這種輕松添加和移除訂單條目的功能在DB2 9 for z/OS中尤其有價值,因為這個版本不支持在現(xiàn)有XML文檔中添加或刪除元素。
下面的代碼顯示了一個表的定義,以及拆分一個訂單文檔的INSERT語句,相關(guān)的列分別存儲訂單ID,客戶ID,訂單日期和一個條目流水號。
- CREATE TABLE items(ordID INTEGER, custID INTEGER,
- odate DATE, seqNo INTEGER, item XML);
- INSERT INTO items(ordID, custID, odate, seqno, item)
- SELECT T.ordID, T.custID, T.odate, T.seqno, XMLDOCUMENT( T.item)
- FROM
- XMLTABLE('$d/order/item' PASSING cast(? AS XML) "d"
- COLUMNS
- ordID INTEGER PATH '../@OrderID',
- custID INTEGER PATH '../customerID'
- odate DATE PATH '../@OrderDate',
- seqNo FOR ORDINALITY,
- item XML PATH '.') AS T;
條目信息是以XML格式存儲的,因為條目可能有不同的元素和屬性,如:
- ORDID CUSTID ODATE SEQNO ITEM
-
- 9001 26914 10/18/2009 1 <item id="LK-486">
- <name>Magic Potion</name>
- <size>300ml</size>
- <price>19.99</price>
- </item>
- 9001 26914 10/18/2009 2 <item id="VF-145">
- <name>Crystal Ball, Deluxe</name>
- <color>crystaltb clear</color>
- <price>295.00</price>
- </item>
- 2 record(s) selected.
INSERT語句包括一個XMLTABLE函數(shù),這個函數(shù)從輸入XML文檔抽取插入items表中的值,它將會拆分輸入XML文檔,生成獨立條目的文檔。XMLTABLE函數(shù)包括一個參數(shù),通過它,應(yīng)用程序可以傳遞一個訂單文檔,使用XPath表達(dá)式$d/order/item,XMLTABLE函數(shù)為輸入文檔的每一個條目生成一行數(shù)據(jù),然后抽取訂單ID,客戶ID和訂單日期,特殊的列定義FOR ORDINALITY為產(chǎn)生的每一行打上編號。XMLDOCUMENT函數(shù)確保每一個條目片段可以作為一個獨立的XML文檔插入。
上面的代碼顯示了使用INSERT語句插入XML文檔后items表中的數(shù)據(jù),下面的代碼顯示了如何重建原始的訂單文檔,XMLELEMENT和XMLATTRIBUTES函數(shù)使用items表中相關(guān)列的值構(gòu)建的頂部文檔,XMLAGG函數(shù)組合所有條目,最后形成一個完整的訂單文檔。注意,XMLAGG在seqno列上包括一個可選的ORDER BY子句,這樣可以確保還原后的訂單文檔和原始文檔中的條目顯示順序是一致的。
- SELECT XMLELEMENT(name "order",
- XMLATTRIBUTES(ordID AS "OrderID", odate as "OrderDate"),
- XMLELEMENT(name "customerID", custID)
- XMLAGG(item ORDER BY seqno) )
- FROM items
- WHERE ordID = 9001
- GROUP BY ordID, odate, custID;
使用生成列
DB2 9.7 for LUW中新的IBM DB2 pureXML特性允許你與數(shù)據(jù)庫分區(qū)功能(Database Partitioning Feature,DPF),范圍分區(qū)表和多維集群(MDC)表一起使用XML列,但分區(qū)或集群鍵必須由相關(guān)的列組成。前面你已經(jīng)看到了如何使用INSERT和XMLTABLE從XML文檔抽取值到相關(guān)的列中,你可以使用這些關(guān)聯(lián)列對表進(jìn)行分區(qū)或集群。如果你更喜歡在程序中使用簡單的INSERT語句,并且不知道如何抽取數(shù)據(jù)時,那你可以考慮使用一個生成的列。
DB2 9.7在用戶定義函數(shù)(UDF)中支持XML參數(shù),允許你定義生成的列,使用插入的XML文檔中的值自動填充。下面的代碼顯示了一個UDF,它接受一個XML文檔作為輸入,如前面例子中的訂單文檔,這個UDF使用XMLCAST和XMLQUERY函數(shù)抽取輸入文檔的OrderDate屬性:
- CREATE FUNCTION extractDate(doc XML)
- RETURNS DATE
- LANGUAGE SQL CONTAINS SQL
- NO EXTERNAL ACTION DETERMINISTIC
- RETURN XMLCAST(XMLQUERY('$d/order/@OrderDate'
- PASSING doc AS "d") AS DATE);
你可以在SELECT查詢和其它SQL語句中使用這個UDF,但也要定義一個生成列,對于下面的示例,假設(shè)檢索和插入完整的訂單是最關(guān)鍵的操作,在這種情況下,完整地存儲訂單文檔是最好的選擇。下面的代碼定義了一個使用XML列存儲訂單的表,并自動抽取訂單日期填充到關(guān)聯(lián)的列(odate)中。一條INSERT語句現(xiàn)在可以簡單地插入一個XML文檔到order列中,不需要考慮抽取值到關(guān)聯(lián)列中:
- CREATE TABLE orders(
- order XML,
- odate DATE GENERATED ALWAYS AS (extractDate(order)));
如果你連續(xù)不斷地存儲許多訂單,可能需要對舊訂單進(jìn)行歸檔,這個時候使用范圍分區(qū)是最好的選擇,下面的代碼顯示了表order2是通過按odate列的值進(jìn)行分區(qū)的,odate列則產(chǎn)生自XML列,同樣,你可以使用生成的列作為分區(qū)數(shù)據(jù)庫的分配鍵,也可以作為MDC表的集群鍵:
- CREATE TABLE order2(
- order XML,
- odate DATE GENERATED ALWAYS AS (extractDate(order)) NOT NULL)
- PARTITION BY RANGE (odate)
- (PART q109 STARTING('01-01-2009') ENDING ('03-31-2009') INCLUSIVE,
- PART q209 ENDING ('06-30-2009') INCLUSIVE,
- PART q309 ENDING ('09-30-2009') INCLUSIVE,
- PART q409 ENDING ('12-31-2009') INCLUSIVE);
控制XML存儲
自定義XML存儲有許多好處,將大型XML文檔拆分成多個小文檔,將會使操作XML數(shù)據(jù)變得更加容易和高效,使用UDF定義生成列可以簡化XML值抽取到關(guān)聯(lián)列,使用生成列還可以幫助你管理分區(qū)數(shù)據(jù)庫,范圍分區(qū)表,或MDC表中的XML。
原文出處:http://www.ibm.com/developerworks/data/library/dmmag/DMMag_2009_Issue3/Tips/index.html
原文名:Customizing XML storage in DB2
作者:Matthias Nicola
Oracle 9i上使用自動管理回滾的錯誤,簡單記錄一下。
錯誤信息為:
Sat May 12 21:54:17 2012
Errors in file /oracle/app/admin/prmdb/bdump/prmdb2_smon_483522.trc:
ORA-01595: error freeing extent (2) of rollback segment (19))
ORA-01594: attempt to wrap into rollback segment (19) extent (2) which is being freed
數(shù)據(jù)庫環(huán)境為9208 RAC for Aix,tb跟進(jìn)MOS文檔With AUM Enabled ORA-01594 and ORA-01595 Found in the alert.log [ID 280151.1]的描述,導(dǎo)致問題的原因是在自動回滾管理系統(tǒng)中,如果SMON在嘗試收縮一個回滾段時,有新的事務(wù)導(dǎo)致回滾段需要擴(kuò)展,那么這個回收的操作就會報錯。因此,可以認(rèn)為這是一個正常的信息,而非是錯誤提示,可以簡單的忽略這個問題。
Oracle在10g中已經(jīng)解決了這個問題,在9i中,可以嘗試添加更多的回滾空間來解決問題。
客戶的數(shù)據(jù)庫出現(xiàn)ORA-600錯誤,錯誤函數(shù)為1265。
數(shù)據(jù)庫版本為10.2.0.4 for Linux,錯誤信息為:
Fri Aug 26 22:00:11 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
Fri Aug 26 22:00:13 2011
Errors in file /opt/app/oracletb/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
Fri Aug 26 22:00:13 2011
Trace dumping is performing id=[cdmp_20110826220013]
Fri Aug 26 22:00:14 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-06512: at "USER1.P_PRO", line 5
ORA-04088: error during execution of trigger 'USER1.P_PRO'
Fri Aug 26 22:00:15 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-06512: at "USER1.P_PRO ", line 5
ORA-04088: error during execution of trigger 'USER1.P_PRO'
ORA-06512: at "USER1.U_PRO ", line 25
Fri Aug 26 22:00:17 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-02067: transaction or savepoint rollback required
Fri Aug 26 22:00:18 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl1_ora_16655.trc:
ORA-00600: internal error code, arguments: [17281], [600], [0x2E134EEC0], [], [], [], [], []
ORA-00600: internal error code, arguments: [1265], [0x42180EA78], [], [], [], [], [], []
ORA-02067: transaction or savepoint rollback required
這個錯誤是ORA-600[1265]錯誤引發(fā)的,隨后還出現(xiàn)了ORA-600[17281]、ORA-4088和ORA-2067錯誤。其中ORA-2067的描述為:
$ oerr ora 2067
02067, 00000, "transaction or savepoint rollback required"
// *Cause: A failure (typically a trigger or stored procedure with multiple
// remote updates) occurred such that the all-or-nothing execution
// of a previous Oracle call cannot be guaranteed.
// *Action: rollback to a previous savepoint or rollback the transaction
// and resubmit.
從這個描述和Oracle的報錯信息不難判斷,Oracle在通過觸發(fā)器更新遠(yuǎn)端表時引發(fā)了這個600錯誤。
根據(jù)Oracle的MOS文檔Bug 5655419 Distributed transaction hits ORA-600:[1265] or ORA-600:[k2gget: downgrade] in 10.2的描述,這個錯誤和分布式事務(wù)有關(guān),確認(rèn)影響的版本就是當(dāng)前環(huán)境的10.2.0.4。這個錯誤的產(chǎn)生一般與窗口維護(hù)有關(guān),可以看到問題的發(fā)生時刻恰好是22點,從這個時刻開始,Oracle進(jìn)入維護(hù)窗口,進(jìn)行空間回收統(tǒng)計信息收集等后臺工作,顯然就是因為窗口的變化導(dǎo)致了這個錯誤的產(chǎn)生。
Oracle在11.1.0.6中FIXED了這個bug。除了版本升級外,可以考慮將包含分布式事務(wù)修改的程序放到遠(yuǎn)離時間窗口改變時間。
客戶數(shù)據(jù)庫10.1.0.4碰到這個ORA-600錯誤。
詳細(xì)錯誤信息為:
Sat Feb 4 13:04:31 2006
ALTER DATABASE MOUNT
Sat Feb 4 13:04:31 2006
Errors in file /oracle/admin/orcl/bdump/orcl_ckpt_122986.trc:
ORA-00600: internal error code, arguments: [kccida_kccsgfsz], [], [], [], [], [], [], []
Sat Feb 4 13:04:32 2006
Errors in file /oracle/admin/orcl/bdump/orcl_ckpt_122986.trc:
ORA-00600: internal error code, arguments: [kccida_kccsgfsz], [], [], [], [], [], [], []
Sat Feb 4 13:04:32 2006
CKPT: terminating instance tb due to error 470
Instance terminated by CKPT, pid = 122986
查詢MOS發(fā)現(xiàn)和文檔Alter Database Mount Returns ORA-3113 And ORA-600 [kccida_kccsgfsz] [ID 315112.1]描述的問題一致。導(dǎo)致問題的原因是客戶在遷移或斷電等因素導(dǎo)致控制文件和數(shù)據(jù)文件的格式不兼容。
在下次重啟時,告警日志中出現(xiàn)的下面的信息也說明了這一點:
Sat Feb 4 13:20:15 2006
alter database mount
Sat Feb 4 13:20:15 2006
Controlfile identified with block size 16384
顯然導(dǎo)致這個問題的原因和客戶之前的恢復(fù)或遷移操作有關(guān)。如果如bug所述,數(shù)據(jù)庫是直接從其他平臺拷貝到當(dāng)前環(huán)境下,那么正確的方法肯定是通過邏輯備份EXP/EXPDP進(jìn)行數(shù)據(jù)庫的遷移。
而如果和當(dāng)前的情況類似,由于異常導(dǎo)致控制文件的損壞,可以考慮從備份中進(jìn)行恢復(fù)或直接重建控制文件。
碰到一個有意思的問題,如果分區(qū)表執(zhí)行過SET UNUSED操作,那么是否還可以進(jìn)行分區(qū)的EXCHANGE操作。
一個簡單的測試就可以說明這個問題:
SQL> create table t_part_unused
2 (id number, name varchar2(30), other varchar2(30))
3 partition by range (id)
4 (partition p1 values less than (10),
5 partition pmax values less than (maxvalue));
Table created.
SQL> insert into t_part_unused
2 select rownum, table_name, 'abc'
3 from user_tables;
48 rows created.
SQL> commit;
Commit complete.
SQL> alter table t_part_unused set unused (other);
Table altered.
SQL> desc t_part_unused
Name Null? Type
---------------------------------------- -------- ------------------------
ID NUMBER
NAME VARCHAR2(30)
SQL> create table t_temp_unused as
2 select *
3 from t_part_unused
4 where 1 = 2;
Table created.
SQL> desc t_temp_unused
Name Null? Type
---------------------------------------- -------- ------------------------
ID NUMBER
NAME VARCHAR2(30)
SQL> alter table t_part_unused
2 exchange partition p1
3 with table t_temp_unused;
with table t_temp_unused
*
ERROR at line 3:
ORA-14097: column type or size mismatch in ALTER tb TABLE EXCHANGE PARTITION
SQL> alter table t_temp_unused add (other varchar2(30));
Table altered.
SQL> alter table t_part_unused
2 exchange partition p1
3 with table t_temp_unused;
with table t_temp_unused
*
ERROR at line 3:
ORA-14096: tables in ALTER TABLE EXCHANGE PARTITION must have the same number of columns
SQL> alter table t_temp_unused set unused (other);
Table altered.
SQL> alter table t_part_unused
2 exchange partition p1
3 with table t_temp_unused;
Table altered.
很明顯執(zhí)行了SET UNUSED操作后的表,和普通的表是存在區(qū)別的,這種區(qū)別導(dǎo)致要求進(jìn)行EXCHANGE的表必須同樣執(zhí)行SET UNUSED操作,否則就無法執(zhí)行EXCHANGE的操作。
當(dāng)目標(biāo)表中不包含SETE UNUSED的列時,EXCHANGE操作會出現(xiàn)ORA-14097的錯誤,而如果把列添加到目標(biāo)表,則會報錯ORA-14096,必須在目標(biāo)表同樣對列執(zhí)行SET UNUSED操作,才能通過EXCHANGE之前的檢查。
其實這也不難理解,執(zhí)行SET UNUSED命令后,數(shù)據(jù)字典雖然發(fā)生了改變,但是tb表上的數(shù)據(jù)并沒有刪除,而EXCHANGE操作只是將兩個段的數(shù)據(jù)字典進(jìn)行互換,因此如果目標(biāo)表上缺少SET UNUSED列,是無法執(zhí)行EXCHANGE操作的。
解決問題的方法有兩個,第一個就是例子中展示的可以在目標(biāo)表上建立列然后同樣的執(zhí)行SET UNUSED操作;另外的一個方法就是對于SET UNUSED列執(zhí)行DROP COLUMN操作,徹底刪除該列。