怎么解決oracle丟失的是所有的redo日志組問題

本篇內(nèi)容主要講解“怎么解決oracle丟失的是所有的redo日志組問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“怎么解決oracle丟失的是所有的redo日志組問題”吧!

假設(shè)丟失的是所有的redo日志組，分下列幾種情況分別處理：

1.Oracle沒開歸檔，一致性關(guān)閉數(shù)據(jù)庫

2.Oracle沒開歸檔，非一致性關(guān)閉數(shù)據(jù)庫

3.Oracle開歸檔，一致性關(guān)閉數(shù)據(jù)庫

4.Oracle開歸檔，非一致性關(guān)閉數(shù)據(jù)庫

一：Oracle沒開歸檔，一致性關(guān)閉數(shù)據(jù)庫

我做實(shí)驗(yàn)的過程中有一個(gè)詭異的情況，我先把redo文件從操作系統(tǒng)層面都刪除了，但是數(shù)據(jù)庫正常創(chuàng)建表，insert數(shù)據(jù)，我理解的是當(dāng)你commit的時(shí)候，會(huì)觸發(fā)lgwr進(jìn)程從redo log buffer中涮新redo 到redo 文件中，但是redo文件已經(jīng)被刪除了，就會(huì)報(bào)錯(cuò)，但是他并沒有報(bào)錯(cuò)：

[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# ll

total 13697796

-rw-r----- 1 oracle oinstall 144916480 Apr 5 22:30 control01.ctl

-rw-r----- 1 oracle oinstall 2147491840 Apr 5 22:26 liuwenhe.dbf

-rw-r----- 1 oracle oinstall 52429312 Apr 5 22:26 redo01.log

-rw-r----- 1 oracle oinstall 52429312 Apr 5 22:29 redo03.log

-rw-r----- 1 oracle oinstall 4938801152 Apr 5 22:26 soe3.dbf

-rw-r----- 1 oracle oinstall 2469404672 Apr 5 22:26 soe.dbf

-rw-r----- 1 oracle oinstall 2705334272 Apr 5 22:26 sysaux01.dbf

-rw-r----- 1 oracle oinstall 786440192 Apr 5 22:26 system01.dbf

-rw-r----- 1 oracle oinstall 30416896 Oct 16 12:37 temp01.dbf

-rw-r----- 1 oracle oinstall 1073750016 Apr 5 22:26 temp.dbf

-rw-r----- 1 oracle oinstall 309338112 Apr 5 22:26 undotbs01.dbf

-rw-r----- 1 oracle oinstall 166469632 Apr 5 22:26 users01.dbf

刪除redo 文件

[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# rm *.log

再次查看，發(fā)現(xiàn)確實(shí)已經(jīng)沒有了redo文件

[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# ll

total 13595388

-rw-r----- 1 oracle oinstall 144916480 Apr 5 22:50 control01.ctl

-rw-r----- 1 oracle oinstall 2147491840 Apr 5 22:50 liuwenhe.dbf

-rw-r----- 1 oracle oinstall 4938801152 Apr 5 22:50 soe3.dbf

-rw-r----- 1 oracle oinstall 2469404672 Apr 5 22:50 soe.dbf

-rw-r----- 1 oracle oinstall 2705334272 Apr 5 22:50 sysaux01.dbf

-rw-r----- 1 oracle oinstall 786440192 Apr 5 22:50 system01.dbf

-rw-r----- 1 oracle oinstall 30416896 Oct 16 12:37 temp01.dbf

-rw-r----- 1 oracle oinstall 1073750016 Apr 5 22:41 temp.dbf

-rw-r----- 1 oracle oinstall 309338112 Apr 5 22:50 undotbs01.dbf

-rw-r----- 1 oracle oinstall 166469632 Apr 5 22:50 users01.dbf

SQL> create table t(int int);

Table created.

SQL> insert into t values (100);

1 row created.

SQL> commit;

SQL>alter system switch logfile;

System altered.

SQL> alter system checkpoint;

System altered.

有點(diǎn)理解不了!!!!問了下老師，才知道原來是打開的文件句柄還在，重啟之后就沒有了!就會(huì)報(bào)錯(cuò)

(體外話：也就是說rm這個(gè)文件了，但是這個(gè)文件實(shí)際上還是存在的，先說一下他的工作原理吧，然后我在把試驗(yàn)分享給大家， 工作原理其實(shí)也不難，這個(gè)工具需要在ext3或者ext4 的文件系統(tǒng)上才可以實(shí)現(xiàn)，因?yàn)閑xt3文件系統(tǒng)是日志型文件系統(tǒng)，ext3文件系統(tǒng)儲(chǔ)存信息的時(shí)候是由inode號和block塊存儲(chǔ)的。

神馬? 不知道什么是inode號?和block塊? 好吧，在說明白點(diǎn)，比如：一個(gè)分區(qū)比如一本書，那么block塊就是書每頁的內(nèi)容，而inode號 就是書的目錄，系統(tǒng)找文件的時(shí)候先找inode號 然后根據(jù)inode號去找硬盤上的block快信息，明白了吧!

在說一下刪除的原理吧。 當(dāng)硬盤上的一個(gè)文件刪除，其實(shí)沒有真正想象中的那樣在硬盤上清除掉的，他是把inode號和block塊的那個(gè)鏈子 斷開，但是真正的數(shù)據(jù)還是在硬盤上的，有沒有感覺在windos上刪除是那么快，沒考慮到這吧，當(dāng)你在刪除文件的地方重新復(fù)制了新文件，那時(shí)候才會(huì)把之前的文件覆蓋掉，也就是說刪除了沒有關(guān)系，千萬不要往那個(gè)位置放文件了)

因?yàn)閿?shù)據(jù)庫是一致性關(guān)閉的，也就是不需要實(shí)例恢復(fù)，也就不需要丟失的redo，所以可以直接刪除重建，當(dāng)然也可以recover database 來恢復(fù)丟失的redo,所以針對這種情況，有兩種恢復(fù)方式：

方法一：直接clear相應(yīng)的redo日志組!也就是刪除重新建立!

SQL> shutdown immediate #一致性關(guān)閉

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1603411968 bytes

Fixed Size 2253664 bytes

Variable Size 1275071648 bytes

Database Buffers 318767104 bytes

Redo Buffers 7319552 bytes

Database mounted.

SQL> archive log list;

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 30641

Current log sequence 30642

清理刪除從新建立或者直接clear所有的redo 日志組，包括當(dāng)前狀態(tài)的和active狀態(tài)的redo 日志組!

SQL> alter database clear logfile group 1;

Database altered.

SQL> alter database clear logfile group 3;

Database altered.

SQL> alter database open ;

Database altered.

方法二：recover的方式恢復(fù)重做日志，我的實(shí)驗(yàn)過程中，有的時(shí)候這個(gè)方法會(huì)報(bào)錯(cuò)，如果報(bào)錯(cuò)那么就使用第一種方式恢復(fù)!

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 830930944 bytes

Fixed Size 2257800 bytes

Variable Size 536874104 bytes

Database Buffers 289406976 bytes

Redo Buffers 2392064 bytes

Database mounted.

SQL>

###恢復(fù)丟失的redo文件，但是需要open resetlogs之后才能自動(dòng)創(chuàng)建上!

SQL> recover database until cancel;

Media recovery complete.

SQL> alter database open resetlogs;

Database altered.

二：Oracle沒開歸檔，非一致性關(guān)閉數(shù)據(jù)庫

[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# rm -f *.log

SQL> shu abort ###非一致性關(guān)閉數(shù)據(jù)庫

ORACLE instance shut down.

這個(gè)時(shí)候嘗試使用前面的clear或者recover database都會(huì)報(bào)錯(cuò)，無法恢復(fù)，因?yàn)檫@個(gè)時(shí)候是需要做實(shí)例恢復(fù)的，那么什么時(shí)候需要實(shí)例恢復(fù)的判斷依據(jù)，請參考另一篇文章(Oracle原理-----關(guān)于oracle實(shí)例恢復(fù)的前滾和回滾的理解)，報(bào)錯(cuò)如下：

首先嘗試重建，當(dāng)你嘗試clear當(dāng)前的日志組的時(shí)候，會(huì)報(bào)錯(cuò)提示是需要的!!!因?yàn)榉且恢滦躁P(guān)閉確實(shí)需要使用丟失的active和current狀態(tài)的redo來實(shí)例恢復(fù)!

首先啟動(dòng)數(shù)據(jù)庫到mount狀態(tài)

SQL> alter database clear logfile group 3;

alter database clear logfile group 3

*

ERROR at line 1:

ORA-01624: log 3 needed for crash recovery of instance stdb59 (thread 1)

ORA-00312: online log 3 thread 1:

'/data/u01/app/oracle/oradata/stdb59/redo03.log'

然后嘗試recover database,結(jié)果肯定不可以，因?yàn)閷?shí)例恢復(fù)需要的redo已經(jīng)丟失!!

SQL> recover database until cancel;

ORA-00279: change 21959466 generated at 04/06/2019 21:15:45 needed for thread 1

ORA-00289: suggestion :

/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%

u_.arc

ORA-00280: change 21959466 for thread 1 is in sequence #2

Specify log: {<RET>=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: '/data/u01/app/oracle/oradata/stdb59/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: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'

那么針對這種情況，恢復(fù)的方式如下：

使用一個(gè)隱含參數(shù)_allow_resetlogs_corruption強(qiáng)制啟動(dòng)數(shù)據(jù)庫，設(shè)置此參數(shù)之后，在數(shù)據(jù)庫Open過程中，Oracle會(huì)跳過某些一致性檢查，從而使數(shù)據(jù)庫可能跳過不一致狀態(tài)，到達(dá)open數(shù)據(jù)庫的目的

SQL> create pfile='/home/oracle/pfile.ora' from spfile;

File created.

然后在/home/oracle/pfile.ora添加上

*._allow_resetlogs_corruption=true

SQL> startup mount pfile='/home/oracle/pfile.ora';

SQL> recover database until cancel; #恢復(fù)丟失的redo文件

ORA-00279: change 21959471 generated at 04/06/2019 22:34:01 needed for thread 1

ORA-00289: suggestion :

/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%

u_.arc

ORA-00280: change 21959471 for thread 1 is in sequence #2

Specify log: {<RET>=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: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'

ORA-01112: media recovery not started

幸運(yùn)的話就可以直接以resetlogs方式open數(shù)據(jù)庫了!

SQL> alter database open RESETLOGS;

Database altered.

如果遇到下面的錯(cuò)誤，那么你就得重建控制文件了：

SQL> alter database open RESETLOGS;

alter database open RESETLOGS

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [2662], [0], [21959484], [0],

[21959877], [4194545], [], [], [], [], [], []

Process ID: 13177

Session ID: 63 Serial number: 5

重建數(shù)據(jù)庫控制文件

1)直接使用如下alter database backup controlfile這種會(huì)報(bào)錯(cuò)

SQL> alter database backup controlfile to trace as '/data/u01/control_rebuild.trc';

alter database backup controlfile to trace as '/data/u01/control_rebuild.trc'

*

ERROR at line 1:

ORA-16433: The database must be opened in read/write mode.

2)還可以使用如下特定的格式來重建，

查詢數(shù)據(jù)庫的redo 信息：

SQL> select GROUP#,MEMBER from v$logfile;

GROUP# MEMBER

3 /data/u01/app/oracle/oradata/stdb59/redo03.log

1 /data/u01/app/oracle/oradata/stdb59/redo01.log

查詢數(shù)據(jù)庫的datafile信息

SQL> select MEMBER from v$logfile;

MEMBER

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

/data/u01/app/oracle/oradata/stdb59/redo03.log

/data/u01/app/oracle/oradata/stdb59/redo01.log

/data/u01/app/oracle/oradata/stdb59/redo04.log

/data/u01/app/oracle/oradata/stdb59/redo05.log

/data/u01/app/oracle/oradata/stdb59/redo06.log

/data/u01/app/oracle/oradata/stdb59/redo07.log

查出數(shù)據(jù)庫字符集：

SQL> select userenv('language') nls_lang from dual;

NLS_LANG

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

AMERICAN_AMERICA.AL32UTF8

然后編輯出創(chuàng)建控制文件的腳本：注意這里的的testdb57為數(shù)據(jù)庫(db_name),如果是adg轉(zhuǎn)換成的主庫，不要寫db_unique_name

CREATE CONTROLFILE REUSE DATABASE 'testdb57' NORESETLOGS ARCHIVELOG

MAXLOGFILES 50

MAXLOGMEMBERS 5

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 226

LOGFILE

GROUP 3 '/data/u01/app/oracle/oradata/stdb59/redo03.log' SIZE 50M,

GROUP 1 '/data/u01/app/oracle/oradata/stdb59/redo01.log' SIZE 50M

DATAFILE

'/data/u01/app/oracle/oradata/stdb59/system01.dbf',

'/data/u01/app/oracle/oradata/stdb59/sysaux01.dbf',

'/data/u01/app/oracle/oradata/stdb59/undotbs01.dbf',

'/data/u01/app/oracle/oradata/stdb59/users01.dbf',

'/data/u01/app/oracle/oradata/stdb59/liuwenhe.dbf',

'/data/u01/app/oracle/oradata/stdb59/soe.dbf',

'/data/u01/app/oracle/oradata/stdb59/soe3.dbf'

CHARACTER SET AL32UTF8;

然后直接將數(shù)據(jù)庫啟動(dòng)到nomount狀態(tài)，執(zhí)行創(chuàng)建腳本即可

SQL> startup nomount pfile='/home/oracle/pfile.ora';

ORACLE instance started.

Total System Global Area 1603411968 bytes

Fixed Size 2253664 bytes

Variable Size 1275071648 bytes

Database Buffers 318767104 bytes

Redo Buffers 7319552 bytes

CREATE CONTROLFILE REUSE DATABASE 'testdb57' NORESETLOGS ARCHIVELOG

MAXLOGFILES 50

MAXLOGMEMBERS 5

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 226

LOGFILE

GROUP 3 '/data/u01/app/oracle/oradata/stdb59/redo03.log' SIZE 50M,

GROUP 1 '/data/u01/app/oracle/oradata/stdb59/redo01.log' SIZE 50M

DATAFILE

'/data/u01/app/oracle/oradata/stdb59/system01.dbf',

'/data/u01/app/oracle/oradata/stdb59/sysaux01.dbf',

'/data/u01/app/oracle/oradata/stdb59/undotbs01.dbf',

'/data/u01/app/oracle/oradata/stdb59/users01.dbf',

'/data/u01/app/oracle/oradata/stdb59/liuwenhe.dbf',

'/data/u01/app/oracle/oradata/stdb59/soe.dbf',

'/data/u01/app/oracle/oradata/stdb59/soe3.dbf'

CHARACTER SET AL32UTF8;

Control file created.

然后使用oradebug推進(jìn)內(nèi)存中scn號,以便于執(zhí)行后面的recover來恢復(fù)丟失的redo文件，因?yàn)閞ecover的過程會(huì)讀取內(nèi)存中scn。注意 alter session set events '10015 trace name adjust_scn level 10';這種方式在11.2.0.4已經(jīng)失效了

(題外話：我們先聊聊Oracle的SCN。在數(shù)據(jù)庫內(nèi)部，SCN是一個(gè)單向遞增的數(shù)字編號，控制文件、數(shù)據(jù)文件、在線Redo日志、歸檔日志和備份集合中，都包括這個(gè)數(shù)字編號。在內(nèi)部文件中，SCN是通過Base和Wrap兩個(gè)部分進(jìn)行保存。Base是SCN編號的基礎(chǔ)位，是通過32位二進(jìn)制位進(jìn)行保存。一旦超過這32位長度，系統(tǒng)會(huì)自動(dòng)在Wrap進(jìn)位。也就是說，Wrap表示的超過4G個(gè)數(shù)的進(jìn)位次數(shù))

SQL> oradebug poke 0x06001AE70 4 0x001B7740

oradebug 推進(jìn)scn號，poke命令中，第一位參數(shù)是對應(yīng)寫入的內(nèi)存位數(shù)，第二位參數(shù)是寫入長度，第三位參數(shù)是寫入取值。默認(rèn)寫入取值是10進(jìn)制，我們在這里指定寫入16進(jìn)制(0x開頭)，每一個(gè)取值段，用8個(gè)16進(jìn)制對應(yīng)，對應(yīng)到數(shù)字位數(shù)是4位

首先查出數(shù)據(jù)庫的控制文件中的scn號

SQL> select file#, checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#

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

1 21959486

2 21959486

3 21959486

4 21959486

5 21959486

6 21959486

7 21959486

7 rows selected.

SQL> oradebug setmypid

Statement processed.

SQL> oradebug DUMPvar SGA kcsgscn_

kcslf kcsgscn_ [06001AE70, 06001AEA0) = 014F14A2 00000001 00000000 00000000 000000EB 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000

SQL> oradebug poke 0x06001AE70 4 21959486

BEFORE: [06001AE70, 06001AE74) = 00000000

AFTER: [06001AE70, 06001AE74) = 014F133E

(或者可以把21959486轉(zhuǎn)換成16進(jìn)制，然后再修改

SQL> select to_char(21959486, 'XXXXXXXXXXX') from dual;

TO_CHAR(2195

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

14F133E

SQL> oradebug poke 0x06001AE70 4 0x14F133E

BEFORE: [06001AE70, 06001AE74) = 00000000

AFTER: [06001AE70, 06001AE74) = 014F133E)

再次查看確實(shí)已經(jīng)變成了014F133E(對應(yīng)10進(jìn)制是21959486)

SQL> oradebug DUMPvar SGA kcsgscn_

kcslf kcsgscn_ [06001AE70, 06001AEA0) = 014F133E 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000

然后執(zhí)行recover進(jìn)行不完全恢復(fù)：

SQL> recover database until cancel;

ORA-00279: change 21959486 generated at 04/06/2019 23:52:28 needed for thread 1

ORA-00289: suggestion :

/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_07/o1_mf_1_2_%

u_.arc

ORA-00280: change 21959486 for thread 1 is in sequence #2

Specify log: {<RET>=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: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'

ORA-01112: media recovery not started

SQL> alter database open resetlogs;

Database altered.

至此恢復(fù)成功!

三：oracle開歸檔，一致性關(guān)閉

這種情況是同情況1，不需要做實(shí)例恢復(fù)，所以可以直接刪除從新或者recover所有的redo組即可，

方法一：直接clear相應(yīng)的redo日志組!也就是刪除重新建立!

SQL> shutdown immediate #一致性關(guān)閉

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1603411968 bytes

Fixed Size 2253664 bytes

Variable Size 1275071648 bytes

Database Buffers 318767104 bytes

Redo Buffers 7319552 bytes

Database mounted.

清理刪除從新建立或者直接clear所有的redo 日志組，包括當(dāng)前狀態(tài)的和active狀態(tài)的redo 日志組!

SQL> alter database clear logfile group 1;

Database altered.

SQL> alter database clear logfile group 3;

Database altered.

SQL> alter database open ;

Database altered.

方法二：recover的方式恢復(fù)重做日志，我的實(shí)驗(yàn)過程中，有的時(shí)候這個(gè)方法會(huì)報(bào)錯(cuò)，如果報(bào)錯(cuò)那么就使用第一種方式恢復(fù)!

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 830930944 bytes

Fixed Size 2257800 bytes

Variable Size 536874104 bytes

Database Buffers 289406976 bytes

Redo Buffers 2392064 bytes

Database mounted.

SQL>

###恢復(fù)丟失的redo文件，但是需要open resetlogs之后才能自動(dòng)創(chuàng)建上!

SQL> recover database until cancel;

Media recovery complete.

SQL> alter database open resetlogs;

Database altered.

四：開歸檔，非一致性關(guān)閉;

這種情況，只能借助歸檔日志做不完全恢復(fù)!

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC

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

STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME

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

1 1 39 52428800 512 1 YES

INACTIVE 4318162327 20-APR-19 4318209770 20-APR-19

3 1 40 52428800 512 1 NO

CURRENT 4318209770 20-APR-19 2.8147E+14

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 39

Next log sequence to archive 40

Current log sequence 40

刪除redo log文件

[oracle@testdb59 stdb59]$ rm -f *.log

然后非一致性關(guān)閉

SQL> shu abort

ORACLE instance shut down.

解決過程：

SQL> startup mount

ORACLE instance started.

Total System Global Area 1603411968 bytes

Fixed Size 2253664 bytes

Variable Size 1275071648 bytes

Database Buffers 318767104 bytes

Redo Buffers 7319552 bytes

Database mounted.

###恢復(fù)丟失的redo文件，但是需要open resetlogs之后才能自動(dòng)創(chuàng)建上!

SQL> recover database until cancel;

Media recovery complete.

嘗試resetlog方式打開，如果報(bào)錯(cuò)如下，那么還得借助隱含參數(shù)_allow_resetlogs_corruption;

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: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'

使用一個(gè)隱含參數(shù)_allow_resetlogs_corruption強(qiáng)制啟動(dòng)數(shù)據(jù)庫，設(shè)置此參數(shù)之后，在數(shù)據(jù)庫Open過程中，Oracle會(huì)跳過某些一致性檢查，從而使數(shù)據(jù)庫可能跳過不一致狀態(tài)，到達(dá)open數(shù)據(jù)庫的目的

SQL> create pfile='/home/oracle/pfile.ora' from spfile;

File created.

然后在/home/oracle/pfile.ora添加上

*._allow_resetlogs_corruption=true

SQL> startup mount pfile='/home/oracle/pfile.ora';

SQL> alter database open RESETLOGS;

Database altered.

然后一致性關(guān)閉數(shù)據(jù)庫，去掉隱含參數(shù)_allow_resetlogs_corruption，重啟數(shù)據(jù)庫!

到此，相信大家對“怎么解決oracle丟失的是所有的redo日志組問題”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！