ORA-01113問題的簡單分析
在啟動資料庫的時候,open階段總是可能出現各種各樣的問題，
比如讓人膽戰心驚的錯誤。
ORA-01113: file 1 needs media recovery
自己留意了一下，其實還是有蠻多的場景會出現這個問題，有些細節可能沒有注意到就會出現這個問題，
比如我們重建控制檔案的時候。
在重建控制檔案之前做了shutdown abort的操作。
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "TEST10G" NORESETLOGS NOARCHIVELOG
.....
26 '/u02/oracle/oradata/data02.dbf'
27 CHARACTER SET US7ASCII
28 ;
Control file created.
嘗試啟動資料庫的時候就會丟擲這個錯誤。
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/oracle/oradata/TEST10G/disk5/system01.dbf'
其實這個時候簡單分析一下就會明白，上次是shutdown abort的方式，則對應的檢查點資訊無法寫入資料檔案，在open階段smon會做這個校驗。
開始在後臺做資料的前滾，然後應用redo日誌的資料，對某些操作做相應的回滾。
從下面的地方可以看出 last_change#沒有任何值，表明上次斷電重啟後檢查點資訊沒有寫入。
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 858940
2 858940
3 858940
4 858940
5 858940
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 858940
2 858940
3 858940
4 858940
5 858940
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
858939
這個時候嘗試恢復資料庫，再次觀察，則相應的檢查點資訊就做了校正。
SQL> recover database;
Media recovery complete.
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
858939
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 859017 859017
2 859017 859017
3 859017 859017
4 859017 859017
5 859017 859017
SQL> alter database open;
Database altered.
資料庫啟動之後，last_change#的值又迴歸零。等待稍後的檢查點寫入。
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 879019
2 879019
3 879019
4 879019
5 879019
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
879019
其實這個過程中，恢復的基準就是檢查點，也就是SCN.
當然在有些操作依賴於歸檔模式，介質恢復還是依賴於一些歸檔檔案的。
像在非歸檔模式嘗試下面的操作就不可行。
SQL> alter tablespace data offline immediate;
alter tablespace data offline immediate
*
ERROR at line 1:
ORA-01145: offline immediate disallowed unless media recovery enabled
SQL> alter tablespace data begin backup;
alter tablespace data begin backup
*
ERROR at line 1:
ORA-01123: cannot start online backup; media recovery not enabled
這個時候還是啟用歸檔。
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
Database mounted.
SQL> alter database archivelog ;
Database altered.
SQL> alter database open;
Database altered.
如果在歸檔模式中，使用熱備份，需要宣告begin backup,為了能夠修復在熱備份過程中可能產生的分裂資料塊。
SQL> alter tablespace data begin backup;
Tablespace altered.
這個時候停庫就會拋錯。
SQL> shutdown immediate;
ORA-01149: cannot shutdown - file 5 has online backup set
ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf'
如果發生斷電現象，則在重啟的時候出現ORA-01113: file 5 needs media recovery就需要明辨這個錯誤背後的意思
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf'
其實碰到這個錯誤，還是需要結合多種場景來考慮，比如檢視是否熱備份已經正常完成，之前的操作是什麼樣的？
SQL> desc v$backup
Name Null? Type
----------------------------------------- -------- ----------------------------
FILE# NUMBER
STATUS VARCHAR2(18)
CHANGE# NUMBER
TIME DATE
SQL> select *from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 0
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 0
5 ACTIVE 879352 20-JUL-15
可以從SCN的地方看出和重建控制檔案的場景還是存在一定的差別。
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 879275
2 879275
3 879275
4 879275
5 879352
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 879275
2 879275
3 879275
4 879275
5 879352
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
879275
明白了問題，修復就很容易了，果斷結束熱備份。
SQL> alter tablespace data end backup;
Tablespace altered.
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 879275
2 879275
3 879275
4 879275
5 879352
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
879275
這個時候啟動資料庫就沒有問題了。
SQL> alter database open;
Database altered.
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
899361
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 899361
2 899361
3 899361
4 899361
5 899361
SQL> alter tablespace data begin backup;
Tablespace altered.
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf'
SQL> recover datafile 5;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL> select *from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 0
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 0
5 NOT ACTIVE 899488 20-JUL-15
總之解決問題就行，SCN的部分著實是需要關注的一個重點，這也是備份恢復的基石。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1742631/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 關於兩個簡單問題的分析
- 停止MySQL服務hang的問題簡單分析(一）MySql
- jsf取值的簡單問題JS
- 簡單的素數問題(C++)C++
- 用簡單的方法解決問題
- ORA-01113,ORA-01110的簡單解決
- 容災切換中的資料庫當機問題簡單分析（一）資料庫
- 一個applet的簡單問題APP
- 簡單分析MySQL 一則慢日誌監控誤報問題MySql
- tcp 實現簡單http 問題TCPHTTP
- 簡單問題，封裝和框架！封裝框架
- 問一個關於oracle8的簡單的問題！Oracle
- Android Studio Profiler Memory （記憶體分析工具）的簡單使用及問題Android記憶體
- 簡單分析AutoIt指令碼的反編譯和程式碼格式化問題指令碼編譯
- iOS FTPManager的簡單使用及常見問題iOSFTP
- HBase-Region太多的問題簡單總結
- 海量資料查詢問題--簡單的理解
- Resin的中文問題最簡單的解決方法
- hdu5365 簡單幾何問題
- 簡單問題複雜著解決
- 簡單的UrlDns鏈分析DNS
- 簡單探討sum()函式返回null的問題函式Null
- 求一個JS問題更簡單的寫法JS
- freebsd簡單漢化終結篇[解決了簡單漢化的所有問題(轉)
- 簡單問題：JAVA物件的淺複製，有一個疑問！Java物件
- 一個ORA-00600問題的簡單分析(r12筆記第18天)筆記
- 【問題處理】ORA-01113 file xxx need media recovery
- ExplosionField簡單分析
- Spring原始碼分析（三）手寫簡單的IOC容器和解決迴圈依賴問題Spring原始碼
- 對一道if-else相關的程式題的簡單分析
- Centos 系統簡單排查流量異常問題CentOS
- php簡單演算法 - 肇事車輛問題PHP演算法
- NodeJS require路徑問題簡單介紹NodeJSUI
- hadoop 執行期間偶發的各種問題積累（簡單問題不展示）Hadoop
- mr原理簡單分析
- SSRF漏洞簡單分析
- 簡單陰影分析
- Dubbo原理簡單分析