ORACLE windows驅動磁碟機代號自動變更導致oracle資料庫崩潰無法啟動
今天,接到貴陽同事申告,說機房意外斷電後資料庫起不來了,狀況如下:
看到啟動報錯,第一反應是歸檔路徑發生變更了,於是使用如下語句手工建立pfile檔案,檢視
CREATE pfile='c:\initorcl.ora' from spfile='D:\app\Administrator\product\11.2.0\dbhome_1\database\SPFILEMYDB.ORA';
開啟initorcl.ora檢視,果然不出所料: log_archive_dest_1 = "location=F:\backup\arch",經過查詢,發現原先在F盤的f:\backup\arch變成了i:\backup\arch
processes = 1000
memory_target = 26240M
control_files = "D:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTROL01.CTL"
control_files = "D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\ORCL\CONTROL02.CTL"
control_file_record_keep_time= 30
db_block_size = 8192
compatible = "11.2.0.0.0"
log_archive_dest_1 = "location=F:\backup\arch"
log_archive_format = "arch_%r_%t_%s.arc"
db_recovery_file_dest = "D:\app\Administrator\flash_recovery_area"
db_recovery_file_dest_size= 3912M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
session_cached_cursors = 3000
audit_file_dest = "D:\APP\ADMINISTRATOR\ADMIN\ORCL\ADUMP"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
deferred_segment_creation= FALSE
_optimizer_use_feedback = FALSE
diagnostic_dest = "D:\APP\ADMINISTRATOR"
於是,將錯就錯將pfile的log_archive_dest_1 的值改為 "location=I:\backup\arch",然後執行startup nomount pfile=c:\initorcl.ora,發現能夠startup nomount了,但是alter database open報錯:
SQL>alter database open;
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_3256.trc:
ORA-01157: cannot identify/lock data file 14 - see DBWR trace file
ORA-01110: data file 14: 'E:\BMI\TSP_DW_BILL_01.DBF'
ORA-27041: unable to open file
OSD-04002: 無法開啟檔案
O/S-Error: (OS 21) 裝置未就緒。
再檢視作業系統磁碟驅動磁碟機代號,發現系統裡沒有E、F盤,令人意外的是光碟機竟然使用了E盤:
經與系統負責人溝通確認,決定重啟伺服器後,修改驅動磁碟機代號後,然後再啟動資料庫,修改後的磁碟驅動磁碟機代號
(當然,E、F盤的磁碟機代號必須對應Oracle資料庫裡引數檔案、控制檔案對應的歸檔路徑、資料檔案所在磁碟磁碟機代號):
系統磁碟機代號修正後,啟動資料庫正常:
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 星期五 1月 6 10:45:46 2017
Copyright (c) 1982, 2010, Oracle. All rights reserved.
連線到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> archive log list;
資料庫日誌模式 存檔模式
自動存檔 啟用
存檔終點 F:\backup\arch
最早的聯機日誌序列 71586
下一個存檔日誌序列 71591
當前日誌序列 71591
SQL>
看到啟動報錯,第一反應是歸檔路徑發生變更了,於是使用如下語句手工建立pfile檔案,檢視
CREATE pfile='c:\initorcl.ora' from spfile='D:\app\Administrator\product\11.2.0\dbhome_1\database\SPFILEMYDB.ORA';
開啟initorcl.ora檢視,果然不出所料: log_archive_dest_1 = "location=F:\backup\arch",經過查詢,發現原先在F盤的f:\backup\arch變成了i:\backup\arch
processes = 1000
memory_target = 26240M
control_files = "D:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTROL01.CTL"
control_files = "D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\ORCL\CONTROL02.CTL"
control_file_record_keep_time= 30
db_block_size = 8192
compatible = "11.2.0.0.0"
log_archive_dest_1 = "location=F:\backup\arch"
log_archive_format = "arch_%r_%t_%s.arc"
db_recovery_file_dest = "D:\app\Administrator\flash_recovery_area"
db_recovery_file_dest_size= 3912M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
session_cached_cursors = 3000
audit_file_dest = "D:\APP\ADMINISTRATOR\ADMIN\ORCL\ADUMP"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
deferred_segment_creation= FALSE
_optimizer_use_feedback = FALSE
diagnostic_dest = "D:\APP\ADMINISTRATOR"
於是,將錯就錯將pfile的log_archive_dest_1 的值改為 "location=I:\backup\arch",然後執行startup nomount pfile=c:\initorcl.ora,發現能夠startup nomount了,但是alter database open報錯:
SQL>alter database open;
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_3256.trc:
ORA-01157: cannot identify/lock data file 14 - see DBWR trace file
ORA-01110: data file 14: 'E:\BMI\TSP_DW_BILL_01.DBF'
ORA-27041: unable to open file
OSD-04002: 無法開啟檔案
O/S-Error: (OS 21) 裝置未就緒。
再檢視作業系統磁碟驅動磁碟機代號,發現系統裡沒有E、F盤,令人意外的是光碟機竟然使用了E盤:
經與系統負責人溝通確認,決定重啟伺服器後,修改驅動磁碟機代號後,然後再啟動資料庫,修改後的磁碟驅動磁碟機代號
(當然,E、F盤的磁碟機代號必須對應Oracle資料庫裡引數檔案、控制檔案對應的歸檔路徑、資料檔案所在磁碟磁碟機代號):
系統磁碟機代號修正後,啟動資料庫正常:
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 星期五 1月 6 10:45:46 2017
Copyright (c) 1982, 2010, Oracle. All rights reserved.
連線到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> archive log list;
資料庫日誌模式 存檔模式
自動存檔 啟用
存檔終點 F:\backup\arch
最早的聯機日誌序列 71586
下一個存檔日誌序列 71591
當前日誌序列 71591
SQL>
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29357786/viewspace-2131992/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- HA異常導致oracle資料庫無法啟動Oracle資料庫
- oracle SGA設定過大導致資料庫無法啟動Oracle資料庫
- oracle資料庫開機自動啟動Oracle資料庫
- Oracle sysman.mgmt_jobs導致資料庫自動重啟Oracle資料庫
- windows開機自動啟動oracleWindowsOracle
- 4 配置Oracle資料庫自動啟動Oracle資料庫
- 歸檔問題導致的資料庫無法啟動資料庫
- 修改SQLNET.ORA導致資料庫無法啟動SQL資料庫
- ORACLE的歸檔空間滿導致的監聽故障資料庫無法啟動Oracle資料庫
- 由AIX系統故障導致系統重啟,使Oracle資料庫自動啟動例項AIOracle資料庫
- 設定Oracle資料庫開機自啟動Oracle資料庫
- mongoDB因root啟動關閉資料庫導致mongo普通使用者無法啟動MongoDB資料庫
- Oracle日常問題處理-資料庫無法啟動Oracle資料庫
- Oracle日常問題-資料庫無法啟動(案例二)Oracle資料庫
- asm磁碟組依賴導致資料庫自啟動報錯ASM資料庫
- Oracle lsnrctl 無法啟動Oracle
- oracle 10g rac資料庫不能自動啟動Oracle 10g資料庫
- 資料庫恢復狀態可能導致JOB無法自動執行資料庫
- 自動重新啟動oracle例項 for windowsOracleWindows
- windows下oracle自動啟動指令碼WindowsOracle指令碼
- SPFILE 錯誤導致資料庫無法啟動(ORA-01565)資料庫
- 微軟修復了導致 Outlook 啟動時崩潰的問題微軟
- LINUX開機自動啟動ORACLE資料庫和監聽指令碼LinuxOracle資料庫指令碼
- ORACLE 11.2.0.4 for solaris更換硬體後主機時間改變導致一節點叢集服務無法啟動Oracle
- win10行動硬碟無法顯示磁碟機代號怎麼恢復 win10無法顯示行動硬碟磁碟機代號解決方法Win10硬碟
- oracle開機自啟動Oracle
- 又一例SPFILE設定錯誤導致資料庫無法啟動資料庫
- Oracle Rac crs無法啟動Oracle
- oracle偵聽無法啟動Oracle
- RedHat(Linux) Oracle資料庫設定開機自啟動RedhatLinuxOracle資料庫
- AIX下自動啟動/停止Oracle資料庫AIOracle資料庫
- 自動重新啟動oracle監聽程式 for windowsOracleWindows
- Oracle 12.2應用PSU後資料庫無法啟動Oracle資料庫
- 【北亞伺服器資料恢復】raid5崩潰導致同友儲存無法啟動的資料恢復案例伺服器資料恢復AI
- 開機自動啟動ORACLE ON LinuxOracleLinux
- Windows 下處理資料庫無法啟動問題Windows資料庫
- 【故障處理】修改主機名導致oracle例項無法啟動暨如何修改hostnameOracle
- 【Oracle】Oracle 11.2.0.4版本Grid無法隨機啟動Oracle隨機