Oracle 11g 資料庫恢復-場景8:系統預設undo表空間資料檔案損壞,CLOSE狀態
--0.1 建立新的undo表空間(此時資料庫是OPEN狀態) sys@TESTDB11>create undo tablespace newundotbs datafile '/u01/app/oracle/oradata/TestDB11/newundotbs01.dbf' size 300m;
Tablespace created.
--0.2 檢視undo表空間 sys@TESTDB11>select tablespace_name, contents from dba_tablespaces;
TABLESPACE_NAME CONTENTS ------------------------------ --------- SYSTEM PERMANENT SYSAUX PERMANENT UNDOTBS1 UNDO TEMP TEMPORARY USERS PERMANENT EXAMPLE PERMANENT ROTBS PERMANENT NEWUNDOTBS UNDO --0.3 關庫 sys@TESTDB11>shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. --0.4 刪除預設undo表空間資料檔案 sys@TESTDB11>!rm /u01/app/oracle/oradata/TestDB11/undotbs01.dbf --嘗試啟動 sys@TESTDB11>startup ORACLE instance started.
Total System Global Area 855982080 bytes Fixed Size 2230792 bytes Variable Size 641730040 bytes Database Buffers 209715200 bytes Redo Buffers 2306048 bytes Database mounted. ORA-01157: cannot identify/lock data file 3 - see DBWR trace file ORA-01110: data file 3: '/u01/app/oracle/oradata/TestDB11/undotbs01.dbf'
--修改預設的undo表空間(此時不可以在例項上直接修改) sys@TESTDB11>alter system set undo_tablespace='NEWUNDOTBS'; alter system set undo_tablespace='NEWUNDOTBS' * ERROR at line 1: ORA-02097: parameter cannot be modified because specified value is invalid ORA-01219: database not open: queries allowed on fixed tables/views only
sys@TESTDB11>alter system set undo_tablespace = NEWUNDOTBS scope=spfile;
System altered. --再次重啟 sys@TESTDB11>startup mount force; ORACLE instance started.
Total System Global Area 855982080 bytes Fixed Size 2230792 bytes Variable Size 641730040 bytes Database Buffers 209715200 bytes Redo Buffers 2306048 bytes Database mounted. --檢視預設的undo表空間 sys@TESTDB11>show parameter undo_tablespace
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string NEWUNDOTBS
--離線開庫 sys@TESTDB11>alter database datafile 3 offline;
Database altered.
sys@TESTDB11>alter database open;
Database altered.
--還原,恢復 sys@TESTDB11>!cp /backup/inconsistent_backup/undotbs01.dbf /u01/app/oracle/oradata/TestDB11
sys@TESTDB11>recover datafile 3; ORA-00279: change 2654893 generated at 08/09/2013 21:27:06 needed for thread 1 ORA-00289: suggestion : /archive2/1_98_813665348.dbf ORA-00280: change 2654893 for thread 1 is in sequence #98
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 2660981 generated at 08/09/2013 22:19:48 needed for thread 1 ORA-00289: suggestion : /archive2/1_99_813665348.dbf ORA-00280: change 2660981 for thread 1 is in sequence #99
ORA-00279: change 2667783 generated at 08/10/2013 00:00:55 needed for thread 1 ORA-00289: suggestion : /archive2/1_100_813665348.dbf ORA-00280: change 2667783 for thread 1 is in sequence #100
ORA-00279: change 2679804 generated at 08/10/2013 03:00:28 needed for thread 1 ORA-00289: suggestion : /archive2/1_101_813665348.dbf ORA-00280: change 2679804 for thread 1 is in sequence #101
ORA-00279: change 2699110 generated at 08/10/2013 08:29:58 needed for thread 1 ORA-00289: suggestion : /archive2/1_102_813665348.dbf ORA-00280: change 2699110 for thread 1 is in sequence #102
ORA-00279: change 2725650 generated at 08/10/2013 10:27:18 needed for thread 1 ORA-00289: suggestion : /archive2/1_103_813665348.dbf ORA-00280: change 2725650 for thread 1 is in sequence #103
ORA-00279: change 2726122 generated at 08/10/2013 10:29:03 needed for thread 1 ORA-00289: suggestion : /archive2/1_104_813665348.dbf ORA-00280: change 2726122 for thread 1 is in sequence #104
ORA-00279: change 2726220 generated at 08/10/2013 10:32:28 needed for thread 1 ORA-00289: suggestion : /archive2/1_105_813665348.dbf ORA-00280: change 2726220 for thread 1 is in sequence #105
ORA-00279: change 2726249 generated at 08/10/2013 10:33:07 needed for thread 1 ORA-00289: suggestion : /archive2/1_106_813665348.dbf ORA-00280: change 2726249 for thread 1 is in sequence #106
Log applied. Media recovery complete.
--聯機 sys@TESTDB11>alter database datafile 3 online;
Database altered.
--再切換回來 sys@TESTDB11>alter system set undo_tablespace = undotbs1;
System altered. |
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/17013648/viewspace-1151914/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle單個資料檔案損壞,在Rman命令裡設定表空間、資料檔案offline方式來恢復最方便Oracle
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- oracle 普通表空間資料檔案壞塊Oracle
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- 【資料庫資料恢復】Oracle資料庫檔案出現壞塊報錯的資料恢復案例資料庫資料恢復Oracle
- u盤檔案損壞怎麼恢復資料 u盤恢復損壞資料的有效方法
- 【伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- 資料庫資料恢復—NTFS分割槽損壞如何恢復SqlServer資料庫資料資料庫資料恢復SQLServer
- 【北亞伺服器資料恢復】伺服器reiserfs檔案系統損壞的資料恢復案例伺服器資料恢復
- u盤檔案損壞怎麼恢復資料 u盤損壞無法讀取怎麼恢復資料
- 伺服器資料恢復-ext3檔案系統下oracle資料庫資料恢復案例伺服器資料恢復Oracle資料庫
- 資料庫資料恢復-SQL SERVER資料庫MDF (NDF)或LDF損壞如何恢復資料?資料庫資料恢復SQLServer
- Oracle資料庫不同損壞級別的恢復詳解Oracle資料庫
- Oracle案例11——Oracle表空間資料庫檔案收縮Oracle資料庫
- InterBase資料庫檔案損壞的修復方法資料庫
- 織夢資料庫配置檔案資料庫損壞:嘗試修復資料庫資料庫
- 【資料庫資料恢復】EXT3檔案系統下MYSQL資料庫恢復案例資料庫資料恢復MySql
- 【資料庫資料恢復】如何恢復Oracle資料庫truncate表的資料資料庫資料恢復Oracle
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- 【北亞資料恢復】伺服器raid陣列癱瘓導致ZFS檔案系統元檔案損壞的資料恢復資料恢復伺服器AI陣列
- oracle dg庫資料檔案空間不足Oracle
- MySQL 磁碟空間滿導致表空間相關資料檔案損壞故障處理MySql
- (Les16 執行資料庫恢復)-表空間恢復資料庫
- 達夢資料庫系統表空間資料檔案遷移過程資料庫
- 伺服器系統癱瘓系統損壞資料恢復伺服器資料恢復
- 【LINUX】Oracle資料庫 linux磁碟頭資料損壞修復LinuxOracle資料庫
- Oracle undo 表空間資料檔案丟失強制啟動資料庫(沒有未提交的事務)Oracle資料庫
- 伺服器Oracle資料庫損壞修復伺服器Oracle資料庫
- 【資料庫資料恢復】SQL Server資料庫磁碟空間不足的資料恢復案例資料庫資料恢復SQLServer
- system資料檔案頭損壞修復
- 【資料庫資料恢復】LINUX EXT3檔案系統下ORACLE資料庫誤操作導致資料丟失的資料恢復案例資料庫資料恢復LinuxOracle
- 學習這篇Oracle資料庫檔案壞塊損壞的恢復方法,擴充你的知識面Oracle資料庫
- MySQL InnoDB系統表空間資料檔案配置MySql
- Oracle臨時表空間檢視、新增臨時表空間資料檔案、修改預設臨時表空間 方法!Oracle
- PostgreSQL DBA(30) - Backup&Recovery#3(資料檔案損壞恢復)SQL
- 【伺服器資料恢復】raid5崩潰導致lvm資訊和VXFS檔案系統損壞的資料恢復案例伺服器資料恢復AILVM
- 資料底層損壞的恢復方法—拼碎片恢復資料
- 執行在容器中Postgres資料庫資料損壞後如何恢復?資料庫