恢复带有丢失redo在线重做日志的ORACLE数据库

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:[email protected]

 

背景

我遇到一个情况,需要从一个旧的在线备份恢复(由于RMAN “KEEP” 命令的问题) ,缺少保持恢复一致性所需要的归档重做日志备份/文件,客户不关心备份时改变的数据,他们感兴趣的是在线备份开始之前检查一些很旧的数据。

使用时间轴可视化方案(不按比例):

  |——-|——————|———|——————|

  t0      t1                 t2        t3                 t4

          数据添加                                  当前

客户认为一些数据已经损坏,但是不确认什么时候,但是知道不是最近发生的 ,所以flashback技术不是一个选择,因此他们想要一个数据库恢复到临时服务器,作为遥远过去的时间t1

一个在线() 备份在t2 t3 之间被采用,被认为是足够旧,与t1足够近,但是问题是所有的归档重做日志备份丢失,客户确认在线备份期间他们感兴趣的某些数据没有改变。

那么问题是:没有必要的重做数据来保持在线备份的一致性 (t2 t3时间之间) ,当在线备份开始时,我们是否还能打开数据库从开始之前提取数据?  官方回答是” – 数据库必须保持一致性才能打开。并与联机备份一起重做流对备份数据文件一致性是至关重要的,因此重做流中没有重做载体,文件就不能保持彼此间的一致性,因此就不能打开数据库,但是非官方,不受支持的回答是可以完成。

本文涵盖了不受支持,非官方的方法打开一致性损坏的数据库,以便可以提取某些数据。

其他方案可导致同样的情况,基本上这个技术可以在任何时间打开 Oracle数据库,当数据文件不能保持一致性时。

Demo设置

为了说明必要的步骤,我已设置叫做NONCDB 的测试12c 非容器数据库,并模拟用户事务,我在后台使用另一台电脑的Swingbench订单输入(SOE)的基准运行轻工作量。

在开始任何备份和恢复之前,我添加了两个简单的表到SCOTT模式和一些行代表数据(C2列的 “OLD DATA”):

SQL> create table scott.parent (c1 int, c2 varchar2(16), constraint parent_pk primary key (c1)) tablespace users;

Table created.

SQL> create table scott.child (c1 int, c2 varchar2(16), foreign key (c1) references scott.parent(c1)) tablespace soe;

Table created.

SQL> insert into scott.parent values(1, ‘OLD DATA 001’);

1 row created.

SQL> insert into scott.parent values(2, ‘OLD DATA 002’);

1 row created.

SQL> insert into scott.child  values(1, ‘OLD DETAILS A’);

1 row created.

SQL> insert into scott.child  values(1, ‘OLD DETAILS B’);

1 row created.

SQL> insert into scott.child  values(1, ‘OLD DETAILS C’);

1 row created.

SQL> insert into scott.child  values(2, ‘OLD DETAILS D’);

1 row created.

SQL> commit;

Commit complete.

SQL>

注意我添加了一个PK-FK参照完整性约束,放置每个表,是一个不同的表空间,因此他们可能在不同时间进行备份。

这些第一项表示从时间t1旧数据

在线备份

下一步是执行在线备份。为了模拟的目的,我稍微调整步骤,尝试反映在备份运行过程中,我的表中的数据被修改真实的情况,所以我的步骤是:

  • 对除USERS表空间之外的所有数据文件运行在线备份。
  • 添加更多的数据到测试表(因此将要到达CHILD表的数据在SOE 表空间备份之后,到达PARENT表的数据在USERS表空间备份之前)
  • 记录当前归档重做日志,然后删除以模拟丢失的重做数据。
  • 备份 USERS表空间。
  • 添加一些后备份数据到测试表。

真正在RMAN执行的是下列命令:

$ rman

Recovery Manager: Release 12.1.0.2.0 – Production on Thu Feb 26 15:59:36 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

RMAN> connect target

connected to target database: NONCDB (DBID=1677380280)

RMAN> backup datafile 1,2,3,5;

Starting backup at 26-FEB-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=46 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00005 name=/u01/app/oracle/oradata/NONCDB/datafile/SOE.dbf

input datafile file number=00001 name=/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_system_b2k8dsno_.dbf

input datafile file number=00002 name=/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_sysaux_b2k8f3d4_.dbf

input datafile file number=00003 name=/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_undotbs1_b2k8fcdm_.dbf

channel ORA_DISK_1: starting piece 1 at 26-FEB-15

channel ORA_DISK_1: finished piece 1 at 26-FEB-15

piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T155942_bgz9ol3g_.bkp tag=TAG20150226T155942 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:11:16

Finished backup at 26-FEB-15

Starting Control File and SPFILE Autobackup at 26-FEB-15

piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/autobackup/2015_02_26/o1_mf_s_872698259_bgzb0647_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 26-FEB-15

RMAN> alter system switch logfile;

Statement processed

RMAN> commit;

Statement processed

RMAN> alter system switch logfile;

Statement processed

RMAN> insert into scott.parent values (3, ‘NEW DATA 003’);

Statement processed

RMAN> insert into scott.child  values (3, ‘NEW DETAILS E’);

Statement processed

RMAN> commit;

Statement processed

RMAN> select sequence# from v$log where status=’CURRENT’;

SEQUENCE#

———-

        68

RMAN> alter system switch logfile;

Statement processed

RMAN> alter database backup controlfile to ‘/tmp/controlfile_backup.bkp’;

Statement processed

RMAN> backup datafile 4;

Starting backup at 26-FEB-15

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00004 name=/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_users_b2k8gf7d_.dbf

channel ORA_DISK_1: starting piece 1 at 26-FEB-15

channel ORA_DISK_1: finished piece 1 at 26-FEB-15

piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T165814_bgzdrpmk_.bkp tag=TAG20150226T165814 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 26-FEB-15

Starting Control File and SPFILE Autobackup at 26-FEB-15

piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/autobackup/2015_02_26/o1_mf_s_872701095_bgzdrrrh_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 26-FEB-15

RMAN> alter database backup controlfile to ‘/tmp/controlfile_backup.bkp’;

Statement processed

RMAN> insert into scott.parent values (4, ‘NEW DATA 004’);

Statement processed

RMAN> insert into scott.child  values (4, ‘NEW DETAILS F’);

Statement processed

RMAN> commit;

Statement processed

RMAN> exit

Recovery Manager complete.

$

注意在上面的步骤中,自从我使用Oracle 数据库 12c ,我能够从RMAN 执行正常的 SQL 命令这是RMAN 12c 的一个新功能。

损坏备份

现在我将要通过移动保持备份一致性所需要的一个归档重做日志来损坏备份:

SQL> set pages 999 lines 120 trims on tab off

SQL> select ‘rm ‘||name stmt from v$archived_log where sequence#=68;

STMT

————————————————————————————————————————

rm /u01/app/oracle/fast_recovery_area/NONCDB/archivelog/2015_02_26/o1_mf_1_68_bgzcnv04_.arc

SQL> !rm /u01/app/oracle/fast_recovery_area/NONCDB/archivelog/2015_02_26/o1_mf_1_68_bgzcnv04_.arc

SQL>

最后我将移动OLD数据来模拟数据丢失(代表 t4):

SQL> select * from scott.parent order by 1;

        C1 C2

———- —————-

         1 OLD DATA 001

         2 OLD DATA 002

         3 NEW DATA 003

         4 NEW DATA 004

SQL> select * from scott.child order by 1;

        C1 C2

———- —————-

         1 OLD DETAILS A

         1 OLD DETAILS B

         1 OLD DETAILS C

         2 OLD DETAILS D

         3 NEW DETAILS E

         4 NEW DETAILS F

6 rows selected.

SQL> delete from scott.child where c2 like ‘OLD%’;

4 rows deleted.

SQL> delete from scott.parent where c2 like ‘OLD%’;

2 rows deleted.

SQL> commit;

Commit complete.

SQL>

尝试复原和恢复

现在我们试着从一个辅助系统上的备份中恢复,因此我们可以观察我们是否可以提取旧数据。

复制所有的文件之后,第一件要做的事是按正常尝试恢复:

$ rman target=/

Recovery Manager: Release 12.1.0.2.0 – Production on Mon Mar 2 08:40:12 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup nomount;

Oracle instance started

Total System Global Area    1577058304 bytes

Fixed Size                     2924832 bytes

Variable Size                503320288 bytes

Database Buffers            1056964608 bytes

Redo Buffers                  13848576 bytes

RMAN> restore controlfile from ‘/tmp/controlfile_backup.bkp’;

Starting restore at 02-MAR-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=12 device type=DISK

channel ORA_DISK_1: copied control file copy

output file name=/u01/app/oracle/oradata/NONCDB/controlfile/o1_mf_b2k8d9nq_.ctl

output file name=/u01/app/oracle/fast_recovery_area/NONCDB/controlfile/o1_mf_b2k8d9v5_.ctl

Finished restore at 02-MAR-15

RMAN> alter database mount;

Statement processed

released channel: ORA_DISK_1

RMAN> restore database;

Starting restore at 02-MAR-15

Starting implicit crosscheck backup at 02-MAR-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=12 device type=DISK

Crosschecked 4 objects

Finished implicit crosscheck backup at 02-MAR-15

Starting implicit crosscheck copy at 02-MAR-15

using channel ORA_DISK_1

Crosschecked 2 objects

Finished implicit crosscheck copy at 02-MAR-15

searching for all files in the recovery area

cataloging files…

cataloging done

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/NONCDB/datafile/o1_mf_system_b2k8dsno_.dbf

channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/NONCDB/datafile/o1_mf_sysaux_b2k8f3d4_.dbf

channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/NONCDB/datafile/o1_mf_undotbs1_b2k8fcdm_.dbf

channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/NONCDB/datafile/SOE.dbf

channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T155942_bgz9ol3g_.bkp

channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T155942_bgz9ol3g_.bkp tag=TAG20150226T155942

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:46

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/NONCDB/datafile/o1_mf_users_b2k8gf7d_.dbf

channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T165814_bgzdrpmk_.bkp

channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/NONCDB/backupset/2015_02_26/o1_mf_nnndf_TAG20150226T165814_bgzdrpmk_.bkp tag=TAG20150226T165814

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 02-MAR-15

RMAN>

注意它确实从 SOE USERS表空间复原数据文件,但是我们知道它们彼此之间是不一致的。

尝试恢复应该因为缺少一致性需要的重做向我们发出错误:

RMAN> recover database;

Starting recover at 02-MAR-15

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 67 is already on disk as file /u01/app/oracle/fast_recovery_area/NONCDB/archivelog/2015_02_26/o1_mf_1_67_bgzcn05f_.arc

archived log for thread 1 with sequence 69 is already on disk as file /u01/app/oracle/fast_recovery_area/NONCDB/archivelog/2015_02_26/o1_mf_1_69_bgzdqo9n_.arc

Oracle Error:

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: ‘/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_system_bh914cx2_.dbf’

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

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

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

RMAN-03002: failure of recover command at 03/02/2015 08:44:21

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

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

RMAN>

正如预想的那样,我们收到严重的ORA-01547, ORA-01194, ORA-01110 错误,意味着我们没有足够的重做来完成恢复。

尝试恢复

现在是局面的症结所在,我们坚信最有经验的数据库管理员应该熟悉常见的不一致错误:

Oracle Error:

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: ‘/u01/app/oracle/oradata/NONCDB/datafile/o1_mf_system_bh914cx2_.dbf’

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

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

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

RMAN-03002: failure of recover command at 03/02/2015 08:44:21

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

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

当然,我们必须绝对肯定,我们没有在别处丢失的重做例如在磁盘的RMAN 备份片或恢复归档日志备份的磁带上或者也可能仍旧在一个当前在线重做日志上。在进行之前,数据库管理员应该探讨所有可能的选项,以某种形式提取丢失的重做载体,但是如果我们足够确认下列情况,我们可以继续操作:

  • 我们一定不会在其他地方发现丢失的重做。
  • 我们一定需要在在线备份开始前提取数据。
  • 在线备份期间一定不会修改数据。

不完全恢复之后当尝试打开数据库时,最首先检查的自然是SQLPlus 数据文件的模糊性和PIT (时间点):

SQL> select fuzzy, status, checkpoint_change#,

  2         to_char(checkpoint_time, ‘DD-MON-YYYY HH24:MI:SS’) as checkpoint_time,

  3         count(*)

  4    from v$datafile_header

  5   group by fuzzy, status, checkpoint_change#, checkpoint_time

  6   order by fuzzy, status, checkpoint_change#, checkpoint_time;

FUZZY STATUS  CHECKPOINT_CHANGE# CHECKPOINT_TIME        COUNT(*)

—– ——- —————— ——————– ———-

NO    ONLINE              647929 26-FEB-2015 16:58:14          1

YES   ONLINE              551709 26-FEB-2015 15:59:43          4

SQL>

返回了两行,不是所有的都有FUZZY=NO 的事实说明出现了一个问题,在可以使用RESETLOGS 选项打开数据库之前需要更多的重做。

但是我们的问题是没有那个重做,我们不顾一切地急切打开数据库。

无一致性恢复

再一次,无一致性恢复不受支持,只有在万不得已时进行使用。

打开数据处于一致性状态的数据库是相当简单的,我们只需要设置 “_allow_resetlogs_corruption” 隐藏的初始化参数 ,暂时设置撤销管理为手动”:

SQL> alter system set “_allow_resetlogs_corruption”=true scope=spfile;

System altered.

SQL> alter system set undo_management=’MANUAL’ scope=spfile;

System altered.

SQL> shutdown abort;

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1577058304 bytes

Fixed Size                  2924832 bytes

Variable Size             503320288 bytes

Database Buffers         1056964608 bytes

Redo Buffers               13848576 bytes

Database mounted.

SQL>

现在,是不是将打开数据库? 答案还是: “可能不会”. 进行尝试我们会得到:

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00600: internal error code, arguments: [2663], [0], [551715], [0], [562781], [], [], [], [], [], [], []

Process ID: 4538

Session ID: 237 Serial number: 5621

SQL>

看起来很好, 对不对?  实际上情况不是那么糟糕。

简单来说,ORA-00600 错误意味着在数据库SCN 之前数据文件有一个记录的SCN ,当前数据库SCN 被作为第三个参数显示(在这个例子中的 551715) ,数据文件SCN 被作为第五个参数显示 (这个例子中的 562781).  因此差异就是:

562781 – 551715 = 11066

在这个例子中,这不是太大的差距。但是在真正的系统中,差距可能会很大,同时,如果多个数据文件在当前SCN之前,你有望看到更多ORA-00600 错误。

解决该问题的方法相当简单: 前滚当前 SCN 直到它超过数据文件SCN。每次启动时数据库会自动生成很多内部事务,因此前滚数据库SCN的方式是简单地执行重复关闭和启动,取决于差距的大小,可能有必要重复地关闭中止和启动ORA-00600的第5和第3个参数之间的差距将每次降低,但是差距最终会减少至零,数据库将会打开:

SQL> connect / as sysdba

Connected to an idle instance.

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 1577058304 bytes

Fixed Size                  2924832 bytes

Variable Size             503320288 bytes

Database Buffers         1056964608 bytes

Redo Buffers               13848576 bytes

Database mounted.

Database opened.

SQL>

现在假设我们想要查询或输出旧数据,我们应该做的第一件事是使用一个新的撤销表空间切换回自动撤销管理:

SQL> create undo tablespace UNDOTBS2 datafile size 50M;

Tablespace created.

SQL> alter system set undo_tablespace=’UNDOTBS2′ scope=spfile;

System altered.

SQL> alter system set undo_management=’AUTO’ scope=spfile;

System altered.

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 1577058304 bytes

Fixed Size                  2924832 bytes

Variable Size             503320288 bytes

Database Buffers         1056964608 bytes

Redo Buffers               13848576 bytes

Database mounted.

Database opened.

SQL>

最后打开了数据库 (尽管数据是不连贯的) ,也查询了数据:

SQL> select * from scott.parent;

        C1 C2

———- —————-

         1 OLD DATA 001

         2 OLD DATA 002

         3 NEW DATA 003

SQL> select * from scott.child;

        C1 C2

———- —————-

         1 OLD DETAILS A

         1 OLD DETAILS B

         1 OLD DETAILS C

         2 OLD DETAILS D

SQL>

正如我们看到的, 所有在备份开始之前(t2之前)数据 ( “OLD”开始的行)是可用的,只有部分备份期间(C1=3行处)插入的数据,如我们预料的那样是我们的数据不一致。

我们已经看到能够选择数据,我们也可以输出它:

$ expdp scott/tiger dumpfile=DATA_PUMP_DIR:OLD_DATA.dmp nologfile=y

Export: Release 12.1.0.2.0 – Production on Mon Mar 2 09:39:11 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

Starting “SCOTT”.”SYS_EXPORT_SCHEMA_02″:  scott/******** dumpfile=DATA_PUMP_DIR:OLD_DATA.dmp nologfile=y

Estimate in progress using BLOCKS method…

Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 640 KB

Processing object type SCHEMA_EXPORT/USER

Processing object type SCHEMA_EXPORT/SYSTEM_GRANT

Processing object type SCHEMA_EXPORT/ROLE_GRANT

Processing object type SCHEMA_EXPORT/DEFAULT_ROLE

Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

Processing object type SCHEMA_EXPORT/TABLE/TABLE

Processing object type SCHEMA_EXPORT/TABLE/COMMENT

Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

Processing object type SCHEMA_EXPORT/STATISTICS/MARKER

. . exported “SCOTT”.”CHILD”                             5.570 KB       4 rows

. . exported “SCOTT”.”PARENT”                            5.546 KB       3 rows

Master table “SCOTT”.”SYS_EXPORT_SCHEMA_02″ successfully loaded/unloaded

******************************************************************************

Dump file set for SCOTT.SYS_EXPORT_SCHEMA_02 is:

  /u01/app/oracle/admin/NONCDB/dpdump/OLD_DATA.dmp

Job “SCOTT”.”SYS_EXPORT_SCHEMA_02″ successfully completed at Mon Mar 2 09:39:46 2015 elapsed 0 00:00:34

$

在这一点上,我们要么查询,要么提取关键旧数据这是这次演习的角度,我们应该立即丢弃还原的数据库,记住有可能包括在内部表中的数据不一致,因此不应该被用于超出查询或提取该数据。该恢复数据库的频繁死机或其他怪异行为应该在预料之中,因此进入,获取数据,出来,处理掉数据!

结论

如果紧急情况需要采取紧急的措施,如果你处于上述详细描述的情况下,你需要数据,丢失了必要的重做载体,不关心备份期间修改的相关数据,然后有选择。

大多数数据库管理员应该熟悉一致性需要更多的重做错误堆栈:

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

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

他们可能也有点熟悉“_allow_resetlogs_corruption” 隐藏初始化参数 ,但是不让产生的ORA-00600 错误影响恢复尝试不能成功进行:

ORA-00600: internal error code, arguments: [2663], [0], [551715], [0], [562781], [], [], [], [], [], [], []

这个错误是可以克服的,数据库仍旧可能是打开的,因此可以查询或提取必要的数据。

注释: 该过程可以使用Oracle Database 10g, Oracle Database 11g Oracle Database 12c进行测试。


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *