資料庫突然當機無法open的問題及解決
測試的資料庫有一天突然當機,然後無法正常open了,這個問題雖然過去了一段時間,也在這兒總結一把。
從alert日誌中的資訊如下。
Fri Jan 10 16:09:42 2014
Archived Log entry 6837 added for thread 1 sequence 6863 ID 0x19db56aa dest 1:
Fri Jan 10 16:12:59 2014
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_lgwr_2432.trc:
ORA-19502: write error on file "/oravl04/oradata/FETABP2/cntrl_1.dbf", block number 1191 (block size=16384)
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 28: No space left on device
Additional information: -1
Additional information: 131072
LGWR (ospid: 2432): terminating the instance due to error 19502
Fri Jan 10 16:13:01 2014
System state dump requested by (instance=1, osid=2432 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc
Non critical error ORA-48913 caught while writing to trace file "/oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [5242880] reached
Writing to the above trace file is disabled for now on...
Instance terminated by LGWR, pid = 2432
Fri Jan 10 16:32:32 2014
從上可以看到,資料庫遇到了io問題,並且空間也不夠了,直接當機了。
先mount上再說,別直接拿過來就open,可能一些恢復問題讓自己的誤操作弄的更復雜了。如果生產環境,那影響就更大了。需要先做詳細的判斷再動手。
由於這個是測試環境先來演示一下錯誤。
alter database open
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_ora_4780.trc:
ORA-10873: file 1 needs to be either taken out of backup mode or media recovered
ORA-01110: data file 1: '/oravl04/oradata/FETABP2/SYSTEM_1.dbf'
ORA-10873 signalled during: alter database open...
Fri Jan 10 17:02:26 2014
檢視資料庫狀態。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
檢視資料檔案的scn情況
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1.3605E+13
2 1.3605E+13
3 1.3605E+13
4 1.3605E+13
5 1.3605E+13
6 1.3605E+13
7 1.3605E+13
8 1.3605E+13
9 1.3605E+13
10 1.3605E+13
11 1.3605E+13
11 rows selected.
顯示不清楚,先格式化再看看。
SQL> col checkpoint_change# format 99999999999999999
SQL> /
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13605259062393
2 13605259062399
3 13605259062404
4 13605259062411
5 13605259062416
6 13605259062422
7 13605259062411
8 13605259062411
9 13605259062411
10 13605259062411
11 13605259062411
11 rows selected.
可以看到有很多不一致。
檢視資料庫檔案頭的scn情況,情況類似。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13605259062393
2 13605259062399
3 13605259062404
4 13605259062411
5 13605259062416
6 13605259062422
7 13605259062411
8 13605259062411
9 13605259062411
10 13605259062411
11 13605259062411
如果是這個狀態,可能是有對資料庫做了什麼其他的操作,檢視熱備份的情況
這下揪到問題了。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 ACTIVE 1.3605E+13 08-JAN-14
2 ACTIVE 1.3605E+13 08-JAN-14
3 ACTIVE 1.3605E+13 08-JAN-14
4 ACTIVE 1.3605E+13 08-JAN-14
5 ACTIVE 1.3605E+13 08-JAN-14
6 ACTIVE 1.3605E+13 08-JAN-14
7 ACTIVE 1.3605E+13 08-JAN-14
8 ACTIVE 1.3605E+13 08-JAN-14
9 ACTIVE 1.3605E+13 08-JAN-14
10 ACTIVE 1.3605E+13 08-JAN-14
11 ACTIVE 1.3605E+13 08-JAN-14
從日誌裡面翻看熱備份的情況,連續好幾天都沒有end backup的命令出現,可見io的那個問題和這個也有一定的關係。
先修復一下。
用下面的sql生成修復語句。
select 'alter tablespace '||name|| ' end backup;' from v$tablespace where ts# in (select ts# from v$datafile where file# in (select file# from v$backup));
從alert日誌中的資訊如下。
Fri Jan 10 16:09:42 2014
Archived Log entry 6837 added for thread 1 sequence 6863 ID 0x19db56aa dest 1:
Fri Jan 10 16:12:59 2014
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_lgwr_2432.trc:
ORA-19502: write error on file "/oravl04/oradata/FETABP2/cntrl_1.dbf", block number 1191 (block size=16384)
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 28: No space left on device
Additional information: -1
Additional information: 131072
LGWR (ospid: 2432): terminating the instance due to error 19502
Fri Jan 10 16:13:01 2014
System state dump requested by (instance=1, osid=2432 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc
Non critical error ORA-48913 caught while writing to trace file "/oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [5242880] reached
Writing to the above trace file is disabled for now on...
Instance terminated by LGWR, pid = 2432
Fri Jan 10 16:32:32 2014
從上可以看到,資料庫遇到了io問題,並且空間也不夠了,直接當機了。
先mount上再說,別直接拿過來就open,可能一些恢復問題讓自己的誤操作弄的更復雜了。如果生產環境,那影響就更大了。需要先做詳細的判斷再動手。
由於這個是測試環境先來演示一下錯誤。
alter database open
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_ora_4780.trc:
ORA-10873: file 1 needs to be either taken out of backup mode or media recovered
ORA-01110: data file 1: '/oravl04/oradata/FETABP2/SYSTEM_1.dbf'
ORA-10873 signalled during: alter database open...
Fri Jan 10 17:02:26 2014
檢視資料庫狀態。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
檢視資料檔案的scn情況
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1.3605E+13
2 1.3605E+13
3 1.3605E+13
4 1.3605E+13
5 1.3605E+13
6 1.3605E+13
7 1.3605E+13
8 1.3605E+13
9 1.3605E+13
10 1.3605E+13
11 1.3605E+13
11 rows selected.
顯示不清楚,先格式化再看看。
SQL> col checkpoint_change# format 99999999999999999
SQL> /
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13605259062393
2 13605259062399
3 13605259062404
4 13605259062411
5 13605259062416
6 13605259062422
7 13605259062411
8 13605259062411
9 13605259062411
10 13605259062411
11 13605259062411
11 rows selected.
可以看到有很多不一致。
檢視資料庫檔案頭的scn情況,情況類似。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13605259062393
2 13605259062399
3 13605259062404
4 13605259062411
5 13605259062416
6 13605259062422
7 13605259062411
8 13605259062411
9 13605259062411
10 13605259062411
11 13605259062411
如果是這個狀態,可能是有對資料庫做了什麼其他的操作,檢視熱備份的情況
這下揪到問題了。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 ACTIVE 1.3605E+13 08-JAN-14
2 ACTIVE 1.3605E+13 08-JAN-14
3 ACTIVE 1.3605E+13 08-JAN-14
4 ACTIVE 1.3605E+13 08-JAN-14
5 ACTIVE 1.3605E+13 08-JAN-14
6 ACTIVE 1.3605E+13 08-JAN-14
7 ACTIVE 1.3605E+13 08-JAN-14
8 ACTIVE 1.3605E+13 08-JAN-14
9 ACTIVE 1.3605E+13 08-JAN-14
10 ACTIVE 1.3605E+13 08-JAN-14
11 ACTIVE 1.3605E+13 08-JAN-14
從日誌裡面翻看熱備份的情況,連續好幾天都沒有end backup的命令出現,可見io的那個問題和這個也有一定的關係。
先修復一下。
用下面的sql生成修復語句。
select 'alter tablespace '||name|| ' end backup;' from v$tablespace where ts# in (select ts# from v$datafile where file# in (select file# from v$backup));
生成的命令如下。
alter tablespace system end backup;
.....
修復了一部分,檢視備份表。可以看到好多狀態都發生了改變。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 1.3605E+13 08-JAN-14
2 NOT ACTIVE 1.3605E+13 08-JAN-14
3 ACTIVE 1.3605E+13 08-JAN-14
4 NOT ACTIVE 1.3605E+13 08-JAN-14
5 NOT ACTIVE 1.3605E+13 08-JAN-14
6 NOT ACTIVE 1.3605E+13 08-JAN-14
7 NOT ACTIVE 1.3605E+13 08-JAN-14
8 NOT ACTIVE 1.3605E+13 08-JAN-14
9 NOT ACTIVE 1.3605E+13 08-JAN-14
10 NOT ACTIVE 1.3605E+13 08-JAN-14
11 NOT ACTIVE 1.3605E+13 08-JAN-14
11 rows selected.
修復完成後,可以看到狀態都是not active的了。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 1.3605E+13 08-JAN-14
2 NOT ACTIVE 1.3605E+13 08-JAN-14
3 NOT ACTIVE 1.3605E+13 08-JAN-14
4 NOT ACTIVE 1.3605E+13 08-JAN-14
5 NOT ACTIVE 1.3605E+13 08-JAN-14
6 NOT ACTIVE 1.3605E+13 08-JAN-14
7 NOT ACTIVE 1.3605E+13 08-JAN-14
8 NOT ACTIVE 1.3605E+13 08-JAN-14
9 NOT ACTIVE 1.3605E+13 08-JAN-14
10 NOT ACTIVE 1.3605E+13 08-JAN-14
11 NOT ACTIVE 1.3605E+13 08-JAN-14
再次檢視scn的情況。
SQL> select file#,checkpoint_change# from v$datafile
2
SQL> /
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13607479649688
2 13607479649688
3 13607479649688
4 13607479649688
5 13607479649688
6 13607479649688
7 13607479649688
8 13607479649688
9 13607479649688
10 13607479649688
11 13607479649688
檢視資料檔案頭的情況。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13607479649688
2 13607479649688
3 13607479649688
4 13607479649688
5 13607479649688
6 13607479649688
7 13607479649688
8 13607479649688
9 13607479649688
10 13607479649688
11 13607479649688
確認沒問題了,開啟資料庫。
SQL> alter database open;
Database altered.
alter tablespace system end backup;
.....
修復了一部分,檢視備份表。可以看到好多狀態都發生了改變。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 1.3605E+13 08-JAN-14
2 NOT ACTIVE 1.3605E+13 08-JAN-14
3 ACTIVE 1.3605E+13 08-JAN-14
4 NOT ACTIVE 1.3605E+13 08-JAN-14
5 NOT ACTIVE 1.3605E+13 08-JAN-14
6 NOT ACTIVE 1.3605E+13 08-JAN-14
7 NOT ACTIVE 1.3605E+13 08-JAN-14
8 NOT ACTIVE 1.3605E+13 08-JAN-14
9 NOT ACTIVE 1.3605E+13 08-JAN-14
10 NOT ACTIVE 1.3605E+13 08-JAN-14
11 NOT ACTIVE 1.3605E+13 08-JAN-14
11 rows selected.
修復完成後,可以看到狀態都是not active的了。
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 NOT ACTIVE 1.3605E+13 08-JAN-14
2 NOT ACTIVE 1.3605E+13 08-JAN-14
3 NOT ACTIVE 1.3605E+13 08-JAN-14
4 NOT ACTIVE 1.3605E+13 08-JAN-14
5 NOT ACTIVE 1.3605E+13 08-JAN-14
6 NOT ACTIVE 1.3605E+13 08-JAN-14
7 NOT ACTIVE 1.3605E+13 08-JAN-14
8 NOT ACTIVE 1.3605E+13 08-JAN-14
9 NOT ACTIVE 1.3605E+13 08-JAN-14
10 NOT ACTIVE 1.3605E+13 08-JAN-14
11 NOT ACTIVE 1.3605E+13 08-JAN-14
再次檢視scn的情況。
SQL> select file#,checkpoint_change# from v$datafile
2
SQL> /
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13607479649688
2 13607479649688
3 13607479649688
4 13607479649688
5 13607479649688
6 13607479649688
7 13607479649688
8 13607479649688
9 13607479649688
10 13607479649688
11 13607479649688
檢視資料檔案頭的情況。
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 13607479649688
2 13607479649688
3 13607479649688
4 13607479649688
5 13607479649688
6 13607479649688
7 13607479649688
8 13607479649688
9 13607479649688
10 13607479649688
11 13607479649688
確認沒問題了,開啟資料庫。
SQL> alter database open;
Database altered.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1100756/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫突然當機的問題及分析資料庫
- ajax資料無法更新問題原因及解決
- 掉電無法啟動資料庫問題解決資料庫
- 伺服器增加記憶體後無法重啟資料庫的問題及解決伺服器記憶體資料庫
- 一次資料庫無法登陸的問題及排查資料庫
- 一次資料庫無法登陸的"問題"及排查資料庫
- 解決sqlserver資料庫單一使用者無法刪除的問題SQLServer資料庫
- “無法刪除資料庫,因為該資料庫當前正在使用” – 解決方法資料庫
- goland中npm無法使用的問題及解決方法GoLandNPM
- sqlplus無法啟動的問題及解決SQL
- 安裝mysql資料庫及問題解決方法MySql資料庫
- 資料併發操作帶的的問題及解決辦法
- 一次資料庫當機問題的分析資料庫
- 解決無法使用VI的問題
- 一條sql語句導致的資料庫當機問題及分析SQL資料庫
- 一條sql語句“導致”的資料庫當機問題及分析SQL資料庫
- IDEA中Lombok無法生效的問題及解決方法IdeaLombok
- memory_target設定不當導致資料庫無法啟動的問題資料庫
- Oracle資料庫基本知識及問題解決(轉)Oracle資料庫
- 本機資料庫資料庫鏈無法訪問遠端資料庫資料庫
- 使用BBED修改檔案頭解決資料庫Open驗證問題(下)資料庫
- 使用BBED修改檔案頭解決資料庫Open驗證問題(上)資料庫
- Oracle資料庫頻繁歸檔問題的解決辦法Oracle資料庫
- discuz資料庫搬家,改密碼後無法訪問解決辦法資料庫密碼
- 庫存批次存在非法字元,無法操作問題的解決.字元
- 解決主機板擋板無法安裝的問題
- 資料庫變慢了的分析及解決辦法資料庫
- 解決Centos無法yum源的問題CentOS
- Windows無法顯示隱藏資料夾之問題解決Windows
- 解決Mysql資料庫插入資料出現問號(?)的解決辦法MySql資料庫
- 解決Oracle 9.2.0.6版本資料庫由於ORA-07445當機問題Oracle資料庫
- gmail無法訪問問題解決--FGWAI
- 資料庫shutdown之後無法啟動的問題資料庫
- PUBLIC資料庫鏈無法刪除的問題(二)資料庫
- PUBLIC資料庫鏈無法刪除的問題(一)資料庫
- 解決IBM DATA STUDIO無法連線資料庫問題,JDBC驅動不顯示問題。IBM資料庫JDBC
- 安裝資料庫和資料庫解決問題資料庫
- 解決hive資料庫 插入資料很慢的問題Hive資料庫