細節決定一切-多工控制檔案有感
1.首先檢視控制檔案情況
SQL> show parameter control
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
control_files string E:ORACLEPRODUCT10.2.0ORADATAORCLCONTRO
L03.CTL
2.shutdown immediate關閉資料庫,並且在相同目錄下增加控制檔案2, CONTROL02.CTL,同時修改pfile
內容如下:
*.control_files='E:oracleproduct10.2.0oradataorclCONTROL01.CTL,E:oracleproduct10.2.0oradataorclCONTROL02.CTL,E:oracleproduct10.2.0oradataorclCONTROL03.CTL'
3.用pfile啟動資料庫
SQL> startup pfile='e:pfile.ora'
ORACLE 例程已經啟動。
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 209718148 bytes
Database Buffers 394264576 bytes
Redo Buffers 7135232 bytes
ORA-00205: ??????????,??????,??????
遇到此類問題時,首先檢視alert日誌,當時有點懵,沒有第一時間想到檢視alert日誌
alert日誌內容:
Mon Feb 09 11:37:05 2009
ALTER DATABASE MOUNT
Mon Feb 09 11:37:05 2009
ORA-00202: control file: 'E:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL01.CTL,E:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL03.CTL'
ORA-27041: unable to open file
OSD-04002: 無法開啟檔案
O/S-Error: (OS 123) 檔名、目錄名或卷標語法不正確。
Mon Feb 09 11:37:05 2009
ORA-205 signalled during: ALTER DATABASE MOUNT...
alert提示'無法開啟檔案',這一般是OS層面的錯誤,當時懷疑以下兩點:
1)copy的檔案有問題
2)路徑與大小寫有關
但是,之後驗證與以上兩點無關.其實,如果仔細看alert日誌是能發現問題的,但是線索就這麼被忽略掉了.最後透過pub查到了問題原因,關鍵在pfile的內容:
以前的pfile內容:
*.control_files='E:oracleproduct10.2.0oradataorclCONTROL01.CTL,E:oracleproduct10.2.0oradataorclCONTROL02.CTL,E:oracleproduct10.2.0oradataorclCONTROL03.CTL'
修改後的pfile內容
*.control_files='E:oracleproduct10.2.0oradataorclCONTROL01.CTL','E:oracleproduct10.2.0oradataorclCONTROL02.CTL','E:oracleproduct10.2.0oradataorclCONTROL03.CTL'
關鍵在於引號,以前的pfile,引號('')中的內容看作一個控制檔案,所以oracle把'E:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL01.CTL,E:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL03.CTL'看作一個檔案,所以alert中報無法開啟檔案,如果認真觀察alert檔案是能發現這個問題的.
同時在pub上跟biti也學了一招,在拉庫前,先根據pfile建立spfile
SQL>create spfile from pfile='e:pfile.ora';
檔案已建立.
SQL>startup
ORACLE 例程已經啟動。
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 209718148 bytes
Database Buffers 394264576 bytes
Redo Buffers 7135232 bytes
資料庫裝載完畢。
資料庫已經開啟。
總結經驗教訓:
1.搞oracle要認真仔細,注意細節,這個問題認真分析1分鐘就能解決,如果不認真像我就搞了1個小時.代價是昂貴的.
2.多動腦筋,biti的方法讓人少走彎路.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9533994/viewspace-1017028/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 細節決定ERP專案啟動會的成敗
- 細節決定成敗!APP設計不容忽視的20個細節APP
- 多個控制檔案的建立
- ASM中多功控制檔案ASM
- Java集合詳解8:Java集合類細節精講,細節決定成敗Java
- 面試:黃金法則——細節決定成敗面試
- h5效能優化,細節決定結果。H5優化
- 一個MapReduce 程式示例 細節決定成敗(一)
- 【控制檔案】映象控制檔案
- COP4600 檔案系統實現細節
- 第十節:詳細講解一下Java多執行緒,隨機檔案Java執行緒隨機
- gdb多檔案設定斷點斷點
- 開發者談F2P模式:細節決定成敗模式
- 邦芒簡歷:求職簡歷細節決定成敗求職
- 細節決定成敗 MapReduce任務實戰 Map Join
- 細節決定成敗 MapReduce任務實戰 Reduce Join
- 細節決定成敗 MapReduce任務實戰 倒排索引索引
- 一個MapReduce 程式示例 細節決定成敗(五) :Partitioner
- Python讀書筆記:細節決定成敗(2)Python筆記
- Python讀書筆記:細節決定成敗(1)Python筆記
- 第五章 Vlookup函式示例-細節決定成敗函式
- 汪峰FIIL Diva智慧耳機究竟如何?細節決定成敗
- 如何讓程式設計師幸福工作:細節決定成敗程式設計師
- 一個MapReduce 程式示例 細節決定成敗(九):RawComparator
- 一個MapReduce 程式示例 細節決定成敗(八):TotalOrderPartitioner
- Oracle 控制檔案損壞解決方案Oracle
- C++多繼承的細節C++繼承
- Linux學習筆記 檔案讀寫小細節Linux筆記
- 控制檔案
- 細節決定成敗,不容忽視的10道Node面試題面試題
- 一個MapReduce 程式示例 細節決定成敗(六) :CombineFileInputFormatORM
- 一個MapReduce 程式示例 細節決定成敗(三) :Combiner
- 細節決定成敗——無CSS時網頁的可讀性CSS網頁
- 【Linux】關於Linux的部分細節與配置檔案Linux
- linux一切皆檔案之塊裝置檔案(四)Linux
- 製作ASM裝置下的多個控制檔案ASM
- [譯] 在 UNIX 中,一切皆檔案
- 軟體設計是怎樣煉成的(7)——細節決定成敗(詳細設計)