使用netbackup進行資料庫恢復案例
在BIOS中進行操作和設定,調整了資料磁碟的狀態;然後進入作業系統可以正常識別資料磁碟,資料庫也可以啟動到open狀態.
資料庫啟動後,發現有部分資料檔案的狀態為recover,需要進行資料庫的恢復.
下面是資料庫恢復的步驟:[@more@]
1.恢復前狀態:
SQL>select file#,name,status,checkpoint_change# from v$datafile
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
......
18 /oracle/oradata/gcwzdb/mm_basic10.dbf ONLINE 144032510
19 /oradata/gcwzdb/mm_basic11.dbf RECOVER 143638963
20 /oradata/gcwzdb/mm_basic12.dbf RECOVER 143663968
21 /oradata/gcwzdb/mm_basic13.dbf RECOVER 143663968
22 /oradata/gcwzdb/test03.dbf RECOVER 143663968
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
23 /oradata/gcwzdb/test04.dbf RECOVER 143663968
24 /oradata/gcwzdb/test05.dbf RECOVER 143663968
25 /oradata/gcwzdb/test06.dbf RECOVER 143663968
......
28 rows selected.
NOTE: 28個資料檔案中有7個資料檔案都處於RECOVER狀態
2.關閉資料庫,然後啟動到mount狀態,進行資料庫恢復.
SQL>shutdown immediate;
SQL>start mount;
SQL>recover datafile 19;
ORA-00279: change 143638963 generated at 11/11/2011 18:40:54 needed for thread
1
ORA-00289: suggestion : /oradata/archivelog/1_8674_684702199.dbf
ORA-00280: change 143638963 for thread 1 is in sequence #8674
Specify log: {
3.使用netbackup,從磁帶庫中恢復從1_8674_*.dbf開始的歸檔日誌
run{
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
restore archivelog from sequence 8673;
release channel ch00;}
allocated channel: ch00
channel ch00: sid=535 devtype=SBT_TAPE
channel ch00: Veritas NetBackup for Oracle - Release 6.5 (2007072323)
Starting restore at 18-NOV-11
channel ch00: starting archive log restore to default destination
channel ch00: restoring archive log
archive log thread=1 sequence=8673
channel ch00: restoring archive log
archive log thread=1 sequence=8674
channel ch00: restoring archive log
archive log thread=1 sequence=8675
channel ch00: restoring archive log
.....
channel ch00: starting archive log restore to default destination
channel ch00: restoring archive log
archive log thread=1 sequence=8701
channel ch00: restoring archive log
archive log thread=1 sequence=8702
channel ch00: reading from backup piece al_6963_1_767528670
channel ch00: restored backup piece 1
piece handle=al_6963_1_767528670 tag=TAG20111118T102430
channel ch00: restore complete, elapsed time: 00:00:45
Finished restore at 18-NOV-11
released channel: ch00
4.因為是多個檔案需要recover,所以想透過整個庫的recover來完成多個檔案的恢復,結果失敗.
SQL> recover database until cancel;
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01245: offline file 19 will be lost if RESETLOGS is done
ORA-01110: data file 19: '/oradata/gcwzdb/mm_basic11.dbf'
5.逐個恢復狀態為recovery的資料檔案.
SQL> recover datafile 19;
ORA-00279: change 143638963 generated at 11/11/2011 18:40:54 needed for thread
1
ORA-00289: suggestion : /oradata/archivelog/1_8674_684702199.dbf
ORA-00280: change 143638963 for thread 1 is in sequence #8674
Specify log: {
AUTO
Log applied.
Media recovery complete.
單個檔案recover完成後,狀態由recover變成offline,而且此時的checkpoint_change#號沒有變化(只有等到資料庫open以後才會修改)
SQL>select file#,name,status,checkpoint_change# from v$datafile;
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
1 /oracle/oradata/gcwzdb/system01.dbf SYSTEM 144032510
......
17 /oracle/oradata/gcwzdb/mm_basic09.dbf ONLINE 144032510
18 /oracle/oradata/gcwzdb/mm_basic10.dbf ONLINE 144032510
19 /oradata/gcwzdb/mm_basic11.dbf OFFLINE 143660438
20 /oradata/gcwzdb/mm_basic12.dbf RECOVER 143663968
21 /oradata/gcwzdb/mm_basic13.dbf RECOVER 143663968
22 /oradata/gcwzdb/test03.dbf RECOVER 143663968
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
23 /oradata/gcwzdb/test04.dbf RECOVER 143663968
......
28 rows selected.
SQL> recover datafile 20;
ORA-00279: change 143638963 generated at 11/11/2011 18:40:54 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8674_684702199.dbf
ORA-00280: change 143638963 for thread 1 is in sequence #8674
Specify log: {
auto
ORA-00279: change 143663968 generated at 11/11/2011 23:05:07 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8675_684702199.dbf
ORA-00280: change 143663968 for thread 1 is in sequence #8675
ORA-00278: log file '/oradata/archivelog/1_8674_684702199.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
SQL> recover datafile 21;
ORA-00279: change 143638963 generated at 11/11/2011 18:40:54 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8674_684702199.dbf
ORA-00280: change 143638963 for thread 1 is in sequence #8674
Specify log: {
auto
ORA-00279: change 143663968 generated at 11/11/2011 23:05:07 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8675_684702199.dbf
ORA-00280: change 143663968 for thread 1 is in sequence #8675
ORA-00278: log file '/oradata/archivelog/1_8674_684702199.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
......
SQL> recover datafile 25;
ORA-00279: change 143638963 generated at 11/11/2011 18:40:54 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8674_684702199.dbf
ORA-00280: change 143638963 for thread 1 is in sequence #8674
Specify log: {
auto
ORA-00279: change 143663968 generated at 11/11/2011 23:05:07 needed for thread 1
ORA-00289: suggestion : /oradata/archivelog/1_8675_684702199.dbf
ORA-00280: change 143663968 for thread 1 is in sequence #8675
ORA-00278: log file '/oradata/archivelog/1_8674_684702199.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
6. online所有狀態為offline的資料檔案
SQL> select file#,name,status,checkpoint_change# from v$datafile;
......
20 /oradata/gcwzdb/mm_basic12.dbf OFFLINE 143667621
21 /oradata/gcwzdb/mm_basic13.dbf OFFLINE 143667626
22 /oradata/gcwzdb/test03.dbf OFFLINE 143667629
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
23 /oradata/gcwzdb/test04.dbf OFFLINE 143667632
24 /oradata/gcwzdb/test05.dbf OFFLINE 143667635
25 /oradata/gcwzdb/test06.dbf OFFLINE 143667638
......
28 rows selected.
SQL> alter database datafile 19 online;
Database altered.
SQL> alter database datafile 20 online;
Database altered.
SQL> alter database datafile 21 online;
Database altered.
SQL> alter database datafile 22 online;
Database altered.
SQL> alter database datafile 23 online;
Database altered.
SQL> alter database datafile 24 online;
Database altered.
SQL> alter database datafile 25 online;
Database altered.
這些資料檔案雖然online,但因為資料庫處於mount狀態,所以沒有做checkpoint,還是自己恢復的時間點
SQL> select file#,name,status,checkpoint_change# from v$datafile;
......
18 /oracle/oradata/gcwzdb/mm_basic10.dbf ONLINE 144032510
19 /oradata/gcwzdb/mm_basic11.dbf ONLINE 143660438
20 /oradata/gcwzdb/mm_basic12.dbf ONLINE 143667621
21 /oradata/gcwzdb/mm_basic13.dbf ONLINE 143667626
22 /oradata/gcwzdb/test03.dbf ONLINE 143667629
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
23 /oradata/gcwzdb/test04.dbf ONLINE 143667632
24 /oradata/gcwzdb/test05.dbf ONLINE 143667635
25 /oradata/gcwzdb/test06.dbf ONLINE 143667638
26 /oradata/gcwzdb/mm_basic14.dbf ONLINE 144032510
......
28 rows selected.
7. 開啟資料庫(open db)
SQL> alter database open;
Database altered.
SQL> select file#,name,status,checkpoint_change# from v$datafile;
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
......
18 /oracle/oradata/gcwzdb/mm_basic10.dbf ONLINE 144032511
19 /oradata/gcwzdb/mm_basic11.dbf ONLINE 144032511
20 /oradata/gcwzdb/mm_basic12.dbf ONLINE 144032511
21 /oradata/gcwzdb/mm_basic13.dbf ONLINE 144032511
22 /oradata/gcwzdb/test03.dbf ONLINE 144032511
FILE# NAME STATUS CHECKPOINT_CHANGE#
---------- --------------------------------------------- --------------- ------------------
23 /oradata/gcwzdb/test04.dbf ONLINE 144032511
24 /oradata/gcwzdb/test05.dbf ONLINE 144032511
25 /oradata/gcwzdb/test06.dbf ONLINE 144032511
......
資料庫open以後,所有資料檔案的CHECKPOINT_CHANG
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/32980/viewspace-1056393/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【資料庫資料恢復】SAP資料庫資料恢復案例資料庫資料恢復
- 【資料庫資料恢復】Sql Server資料庫資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】Oracle資料庫誤truncate table的資料恢復案例資料庫資料恢復Oracle
- 【資料庫資料恢復】linux系統下MYSQL資料庫資料恢復案例資料庫資料恢復LinuxMySql
- 【資料庫資料恢復】sql server資料庫連線失效的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】SqlServer資料庫無法讀取的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- 伺服器資料恢復—透過拼接資料庫碎片恢復SqlServer資料庫資料的資料恢復案例伺服器資料恢復資料庫SQLServer
- 資料庫資料恢復—附加資料庫錯誤823的SQL Server資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】SQL Server資料庫磁碟空間不足的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】ASM磁碟組掉線的Oracle資料庫資料恢復案例資料庫資料恢復ASMOracle
- Vsan資料恢復—Vsan資料恢復案例資料恢復
- 【Vsan資料恢復】Vsan資料恢復案例資料恢復
- 【資料庫資料恢復】ASM例項不能掛載的Oracle資料庫資料恢復案例資料庫資料恢復ASMOracle
- 【資料庫資料恢復】MongoDB資料庫服務啟動失敗的資料恢復案例資料庫資料恢復MongoDB
- 【北亞資料恢復】sqlserver資料庫被加密的資料恢復案例分享資料恢復SQLServer資料庫加密
- 【資料庫資料恢復】EXT3檔案系統下MYSQL資料庫恢復案例資料庫資料恢復MySql
- 【資料庫資料恢復】斷電導致Oracle資料庫資料丟失的資料恢復案例資料庫資料恢復Oracle
- 帝國cms如何進行恢復資料庫教程資料庫
- 資料庫資料恢復—無備份，binlog未開啟的Mysql資料庫資料恢復案例資料庫資料恢復MySql
- 【資料庫資料恢復】無法啟動MongoDB服務的資料恢復案例資料庫資料恢復MongoDB
- DM7使用DMRAMN對多次故障恢復後使用不同資料庫的歸檔進行恢復資料庫
- 資料庫資料恢復—MongoDB資料庫檔案丟失，啟動報錯的資料恢復案例資料庫資料恢復MongoDB
- 【oracle資料庫資料恢復】誤操作導致的資料庫誤刪除的資料恢復案例Oracle資料庫資料恢復
- 【資料庫資料恢復】華為雲ECS網站伺服器mysql資料庫資料恢復案例資料庫資料恢復網站伺服器MySql
- 【資料庫資料恢復】突然斷電造成Syabse資料庫無法啟動的資料恢復案例資料庫資料恢復
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- 資料庫資料恢復——Windows無法啟動MongoDB服務的資料恢復案例資料庫資料恢復WindowsMongoDB
- 【資料庫資料恢復】Oracle ASM例項無法掛載的資料恢復案例資料庫資料恢復OracleASM
- 如何進行Oracle資料庫不完全恢復RBOracle資料庫
- 【VSAN資料恢復】VSAN儲存資料恢復案例資料恢復
- 【伺服器資料恢復】Vsan資料恢復案例伺服器資料恢復
- 寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復 寶塔mysql資料庫恢復資料庫MySql
- MongoDB案例分享：如何使用oplog恢復資料MongoDB
- MSSQL資料庫資料恢復案例:ndf檔案大小變為0KB恢復資料SQL資料庫資料恢復
- 【資料庫資料恢復】mdb_catalog.wt檔案丟失的MongoDB資料恢復案例資料庫資料恢復MongoDB
- 北亞企安資料恢復-XSAN資料恢復案例資料恢復
- 伺服器資料恢復-ESX SERVER資料恢復案例伺服器資料恢復Server
- 【伺服器資料恢復】SUN SOLARIS資料恢復案例伺服器資料恢復