2. 程式人生 > 其它 >ORA-01113問題的簡單分析(r6筆記第3天)

ORA-01113問題的簡單分析(r6筆記第3天)

阿新 • • 發佈：2022-05-04

在啟動資料庫的時候,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的部分著實是需要關注的一個重點，這也是備份恢復的基石。

相關推薦

ORA-01113問題的簡單分析(r6筆記第3天)

在啟動資料庫的時候,open階段總是可能出現各種各樣的問題， 比如讓人膽戰心驚的錯誤。

alert日誌中的兩種ORA錯誤分析(r6筆記第21天)

今天在巡檢系統的時候，發現alert日誌中有兩種型別的ora錯誤。 Errors in file/U01/app/oracle/diag/rdbms/XX/XX/trace/xxdb_j002_20401.trc:

對一道if-else相關的程式題的簡單分析(r5筆記第45天)

今天同事在微信群裡提出了一個問題，看似是一個面試題。 大體的意思就是補充下面if條件使得輸出 Hello World

一次資料庫宕機問題的分析(r6筆記第5天)

今天來到辦公室，發現有一臺伺服器中的資料庫例項停掉了。這種情況真是意料之外，尤其是我還不是很熟悉這臺機器的服務。

gc伺服器慢的原因分析 (r6筆記第14天)

在工作環境中有一臺gc的伺服器，已經好幾年沒有動過了，上面安裝著gc的服務和資料庫，也就說gc裡面的HttpServer，資料庫,webcache都在這臺伺服器上。

Orabbix定製監控Oracle的簡單配置(r6筆記第26天)

Orabbix是在zabbix的基礎上提供的一套外掛,能夠提供對Oracle的監控功能真是術業有專攻，在Oracle層面zabbix希望也能夠走得更遠，所以對於Oracle的支援還是比較開放的，而對於Orabbix和zabbix server,zabbix agent的關

緩慢的update語句效能分析(r6筆記第61天)

最近處理一個問題的時候，先是收到DB time升高的報警，然後檢視DB time的情況發現，已經有近1000%的負載了。

system表空間不足的問題分析(r6筆記第66天)

很多事情見多了也就有了麻木的感覺，報警簡訊就是如此，每天總能收到不少的報警簡訊，可能很多時候就掃一眼，如果沒有嚴重的問題自己是不會情願開啟電腦處理的。

一則orabbix報警的分析(r6筆記第65天)

最近使用zabbix監控之後，都會在凌晨收到1臺數據庫伺服器的報警簡訊，報警的內容為: No data received from Orabbix

三封報警郵件的分析(r6筆記第95天)

今天收到3封報警郵件，從郵件內容中的報警情況來看，還是比較反常的。需要引起關注，找到原因處理。

關於ORA-00020問題的反思(r2筆記第3天）

今天在生產環境中檢視alert日誌，發現瞭如下的一段錯誤。這個錯誤確實沒有太多需要解釋的。很明顯就是因為sessionleak的經典問題。

關於ORA-01555的問題分析(r5筆記第87天)

今天開發的同事發給我一個問題，在執行某一個Job的時候丟擲了ORA錯誤，希望我們看看從資料庫層面能不能發現什麼。

記一次資料庫的分析和優化建議(r6筆記第24天)

資料庫的巡檢是DBA工作中的一部分，有時候我們還是希望能夠在巡檢的基礎上發現一些潛在的問題，把儘可能多的問題解決在初始階段。

通過定製orabbix監控分析潛在的Oracle問題 (r6筆記第32天)

在之前的部落格中分享過 簡單定製Orabbix監控項http://blog.itpub.net/23718752/viewspace-1769773/

關於奇怪的並行程序分析(一) (r6筆記第41天)

在使用orabbix進行監控的時候，得益於使用 實時DB time監控的選項，對於幾分鐘內的效能抖動也能夠狠容易的記錄下來，而且會把這個監控的結果基本真實反應出來，不會隨著兩個快照的間隔被平均，這樣效能問題的分析和排

關於ora-02391問題的總結(r6筆記第40天)

關於ORA問題的分析和解決其實是一個很好的學習思路，抓住一個每一個ORA錯誤，然後進一步分析一些原因，總結，總會有不一樣的收穫，還是那句話，任何問題背後都是有原因的。

關於奇怪的並行程序分析(三)(r6筆記第47天)

在前兩篇的基礎上，對於一個環境中存在的奇怪並行程序問題進行了初步的分析。

關於奇怪的並行程序分析(二) (r6筆記第46天)

前幾天的並行問題自己分析了下，也算有了一些進展，但是目前還沒有找到讓人信服的理由，有些讀者也比較關心這個問題，所以第二篇中會把自己的分析過程寫出來，第三篇中應該會對這個問題做一個了結。

gqlplus的簡單使用（r6筆記第43天)

使用sqlplus的時候如果命令敲錯之後，可能很多情況下需要重新再敲一遍，也可以用一些快捷方式，但是如果想檢視之前執行的sql語句,list選項就無能為力了，它只能夠列出上一條執行的sql語句。

兩條報警資訊的分析（第二篇)(r6筆記第71天)

還是繼續分析報警資訊的關聯，下面兩個看似沒有直接聯絡的報警資訊其實很有關聯。