亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

  免費注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
最近訪問板塊 發(fā)新帖
查看: 2310 | 回復(fù): 0
打印 上一主題 下一主題

[數(shù)據(jù)庫] 使用_allow_resetlogs_corruption打開無歸檔日志rman備份庫 [復(fù)制鏈接]

論壇徽章:
8
數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-04-29 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-04-30 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-05-13 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-05-15 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-05-19 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-05-20 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-06-02 06:20:00數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2016-06-05 06:20:00
跳轉(zhuǎn)到指定樓層
1 [收藏(0)] [報告]
發(fā)表于 2016-06-02 15:27 |只看該作者 |倒序瀏覽
使用_allow_resetlogs_corruption打開無歸檔日志rman備份庫

rman還原恢復(fù)操作

--還原數(shù)據(jù)庫

RMAN> restore database;

--恢復(fù)數(shù)據(jù)庫

RMAN> recover database;



Starting recover at 2012-03-08 21:20:45

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=65 device type=DISK



starting media recovery



RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 03/08/2012 21:20:47

RMAN-06053: unable to perform media recovery because of missing log

RMAN-06025: no backup of archived log for thread 1 with sequence 2936 and starting SCN of 25991695 found to restore

RMAN-06025: no backup of archived log for thread 1 with sequence 2935 and starting SCN of 25991652 found to restore

RMAN-06025: no backup of archived log for thread 1 with sequence 2934 and starting SCN of 25991649 found to restore

……………………

RMAN-06025: no backup of archived log for thread 1 with sequence 2902 and starting SCN of 25991156 found to restore

這里報日志缺少,實際上是備份的數(shù)據(jù)庫文件后,沒有備份歸檔日志,歸檔日志全部丟失

進行不完全恢復(fù)

SQL> recover database until cancel;

ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf

ORA-00280: change 25991194 for thread 1 is in sequence #2902





Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'





ORA-01112: media recovery not started





SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

查看相關(guān)SCN

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;



     FILE# TO_CHAR(CHECK

---------- -------------

         1      25992214

         2      25992214

         3      25992214

         4      25992214

         5      25992214

         6      25992214

         7      25992214

         8      25992214

         9      25992214

        10      25992214

        11      25992214



     FILE# TO_CHAR(CHECK

---------- -------------

        13      25992214

        14      25992214



13 rows selected.



SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;



     FILE# ONLINE_ TO_CHAR(CHANG

---------- ------- -------------

         1 ONLINE       25991194

         2 ONLINE       25991194

         3 ONLINE       25991194

         4 ONLINE       25991194

         5 ONLINE       25991194

         6 ONLINE       25991194

         7 ONLINE       25991194

         8 ONLINE       25991194

         9 ONLINE       25991194

        10 ONLINE       25991194

        11 ONLINE       25991194



     FILE# ONLINE_ TO_CHAR(CHANG

---------- ------- -------------

        13 ONLINE       25991194

        14 ONLINE       25991194



13 rows selected.



SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;



     FILE# TO_CHAR(CHECK

---------- -------------

         1      25991194

         2      25991194

         3      25991194

         4      25991194

         5      25991194

         6      25991194

         7      25991194

         8      25991194

         9      25991194

        10      25991194

        11      25991194



     FILE# TO_CHAR(CHECK

---------- -------------

        13      25991194

        14      25991194



13 rows selected.



--發(fā)現(xiàn)數(shù)據(jù)文件scn和控制文件不一致,重建控制文件,然后查詢相關(guān)scn

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;



     FILE# TO_CHAR(CHECK

---------- -------------

         1      25991194

         2      25991194

         3      25991194

         4      25991194

         5      25991194

         6      25991194

         7      25991194

         8      25991194

         9      25991194

        10      25991194

        11      25991194



     FILE# TO_CHAR(CHECK

---------- -------------

        13      25991194

        14      25991194



13 rows selected.



SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;



     FILE# ONLINE_ TO_CHAR(CHANG

---------- ------- -------------

         1 ONLINE       25991194

         2 ONLINE       25991194

         3 ONLINE       25991194

         4 ONLINE       25991194

         5 ONLINE       25991194

         6 ONLINE       25991194

         7 ONLINE       25991194

         8 ONLINE       25991194

         9 ONLINE       25991194

        10 ONLINE       25991194

        11 ONLINE       25991194



     FILE# ONLINE_ TO_CHAR(CHANG

---------- ------- -------------

        13 ONLINE       25991194

        14 ONLINE       25991194



13 rows selected.



SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;



     FILE# TO_CHAR(CHECK

---------- -------------

         1      25991194

         2      25991194

         3      25991194

         4      25991194

         5      25991194

         6      25991194

         7      25991194

         8      25991194

         9      25991194

        10      25991194

        11      25991194



     FILE# TO_CHAR(CHECK

---------- -------------

        13      25991194

        14      25991194



13 rows selected.

--此時所有scn均一致

嘗試打開數(shù)據(jù)庫

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'





SQL> recover database using backup controlfile until cancel;

ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1

ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf

ORA-00280: change 25991194 for thread 1 is in sequence #2902





Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'





ORA-01112: media recovery not started



SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

使用隱含參數(shù)打開數(shù)據(jù)庫

SQL> create pfile='/tmp/pfile' from spfile;



File created.



-------/tmp/pfile中加上----------

_allow_resetlogs_corruption= TRUE

---------------------------------



SQL> startup mount pfile='/tmp/pfile' force

ORACLE instance started.



Total System Global Area  622149632 bytes

Fixed Size                  2230912 bytes

Variable Size             419431808 bytes

Database Buffers          192937984 bytes

Redo Buffers                7548928 bytes

Database mounted.

SQL> alter database open resetlogs;



Database altered.



SQL> select open_mode from v$database;



OPEN_MODE

--------------------

READ WRITE

總結(jié)
這次的試驗沒有多少實際意義,但是可以說明幾個問題:
1.所有的數(shù)據(jù)文件的scn都一致,甚至和控制文件的也一致,數(shù)據(jù)庫不一定可以open成功
(懷疑是數(shù)據(jù)文件中的scn大于data header scn)
2.對于這樣的問題,如果使用bbed修改所有數(shù)據(jù)文件header的scn不知道是否可以解決
3.如果rman只備份了數(shù)據(jù)文件而沒有任何一個歸檔日志,數(shù)據(jù)庫通過隱含參數(shù)還是可以open,搶救數(shù)據(jù)
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復(fù)

  

北京盛拓優(yōu)訊信息技術(shù)有限公司. 版權(quán)所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關(guān)心和支持過ChinaUnix的朋友們 轉(zhuǎn)載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP