温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Online Redo Log损坏处理的实验分析

发布时间:2021-11-03 17:48:31 来源:亿速云 阅读:112 作者:柒染 栏目:建站服务器

这期内容当中小编将会给大家带来有关Online Redo Log损坏处理的实验分析,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

Oracle核心文件包括:控制文件、数据文件和在线重做日志(Online Redo Log)。Online Redo LogControl File分别采用数据冗余的策略进行多重路径保护。无论是Control File还是Online Redo Log Group Member,都可以指定多个完全相同的文件对象,并且将其分布在不同的存储介质上。一旦发生介质故障,如硬盘介质故障,我们可以简单的使用其他存储位置的文件进行替换。

所以,即使是在正式的生产环境下,如果设置好适当的控制文件成员组和Online Redo Log组,Control FileOnline Redo Log损坏不可恢复的情况是不多见的。

但是,如果发生这样的场景,我们应该怎么进行处理呢?

 

1、实验环境和影响因素讨论

 

我们选择Oracle 10g环境进行实验。

 

 

SQL> select * from v$version;

 

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE        10.2.0.1.0         Production

 

 

--数据库处在归档模式下;

SQL> archive log list;

数据库日志模式            存档模式

自动存档             启用

存档终点            USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列     237

下一个存档日志序列   239

当前日志序列           239

 

 

SQL> select group#, archived, status, first_change# from v$log;

 

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#

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

         1 YES      INACTIVE               3567149

         2 YES      INACTIVE               3572305

         3 NO       CURRENT                3572332

 

 

在试验中,我们会在关闭数据库的时候删除Online Redo Log组成员文件。注意,在Windows环境下,由于操作系统的限制,我们是没有办法删除一个正在使用或者与实例相关的文件。

 

三个潜在因素可能会影响到最后结果,分别为:日志归档模式、关闭数据库方式和删除日志组状态。

 

日志归档模式表示Oracle是否对已经写完的online redo log member进行额外归档保存。保持一个连续的归档信息对Oracle的意义在于可以实现完全恢复complete recovery。在归档模式下,我们可以从一个过去的备份集开始,利用归档日志前推重演事务,最后应用到当前日志组,使之恢复到一个完全的恢复点上。如果日志已经归档,表示日志内容都已经写入到了数据文件中,状态必然是非Active状态。我们的实验中,数据文件并不是丢失的对象,所以已经写入数据文件的日志丢失并不会造成致命的影响。

 

关闭数据库方式在Oracle中有若干种,但是总的来说只有一致性关闭和非一致性关闭两个大类。一致性关闭表示Oracle在关闭数据库前,都要讲未写入的脏块写入到数据文件,控制文件和数据文件保持一致。一致性关闭条件下,Oracleopen阶段是不需要进行Instance Recovery过程的。非一致性关闭只有shutdown abort,同断电处理。非一致性关闭下Oracleopen阶段要进行instance recovery,这个过程需要redo log的配合。

 

删除日志状态。被删除的日志组是否是当前日志组也是一个重要因素。如果是当前日志组,就意味Oracle在启动状态需要进行读写该文件组。如果不是当前日志组被删除,也可能会有相同的问题,因为非当前日志组可能处在Active状态。

 

下面,我们分别进行实验。

 

2、完全关闭情况下非当前日志组删除

 

当前日志文件状态如下:

 

 

SQL> select group#, type, member from v$logfile;

 

    GROUP# TYPE    MEMBER

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

         3 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03A.LOG

         2 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG

         1 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG

         1 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG

         3 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03B.LOG

         2 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG

 

6 rows selected

 

 

当前日志组号为3,关闭数据库删除日志2组文件。

 

 

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

 

E:\oracle\product\10.2.0\oradata\orcl>rename REDO02A.LOG REDO02A.LOG_bak

 

E:\oracle\product\10.2.0\oradata\orcl>rename REDO02B.LOG REDO02B.LOG_bak

 

E:\oracle\product\10.2.0\oradata\orcl>dir

 驱动器 E 中的卷没有标签。

 卷的序列号是 7CD0-C497

 

 E:\oracle\product\10.2.0\oradata\orcl 的目录

 

2012-09-22  13:20    <DIR>          .

2012-09-22  13:20    <DIR>          ..

2012-09-22  12:04    <DIR>          CHANGETRACKING

2012-09-22  13:19         7,356,416 CONTROL01.CTL

2012-09-22  13:19         7,356,416 CONTROL02.CTL

2012-09-22  13:19         7,356,416 CONTROL03.CTL

2012-09-22  13:19       104,865,792 EXAMPLE01.DBF

2012-09-22  13:19        52,429,312 REDO01A.LOG

2012-09-22  13:19        52,429,312 REDO01B.LOG

2012-09-22  13:19        52,429,312 REDO02A.LOG_bak

2012-09-22  13:19        52,429,312 REDO02B.LOG_bak

2012-09-22  13:19        52,429,312 REDO03A.LOG

2012-09-22  13:19        52,429,312 REDO03B.LOG

2012-09-22  13:19       304,095,232 SYSAUX01.DBF

(篇幅原因,省略部分内容……

              16 个文件  3,178,867,712 字节

               3 个目录 204,274,311,168 可用字节

 

 

重新启动数据库,之后Oraclemountopen阶段报错,因为不能找到控制文件中定义的日志文件。

 

 

SQL> startup

ORACLE 例程已经启动。

 

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             155192244 bytes

Database Buffers          440401920 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'

 

SQL> select open_mode from v$database;

 

OPEN_MODE

----------

MOUNTED

 

 

一般情况下,如果是完全关闭场景,我们是可以保证Oracleonline redo log中所有的内容写入到了数据文件,并且保持一致。

 

对非当前日志成员组,如果被误删除了,没有过多的问题,只是需要重建就好了。

 

 

SQL> alter database clear logfile group 2;

数据库已更改。

 

--完全开启,没有数据损失。

SQL> alter database open;

数据库已更改。

 

 E:\oracle\product\10.2.0\oradata\orcl 的目录

 

2012-09-22  13:23    <DIR>          .

2012-09-22  13:23    <DIR>          ..

2012-09-22  12:04    <DIR>          CHANGETRACKING

2012-09-22  13:20         7,356,416 CONTROL01.CTL

2012-09-22  13:20         7,356,416 CONTROL02.CTL

2012-09-22  13:20         7,356,416 CONTROL03.CTL

2012-09-22  13:19       104,865,792 EXAMPLE01.DBF

2012-09-22  13:23    <DIR>          ONLINELOG

2012-09-22  13:19        52,429,312 REDO01A.LOG

2012-09-22  13:19        52,429,312 REDO01B.LOG

2012-09-22  13:23        52,429,312 REDO02A.LOG

2012-09-22  13:19        52,429,312 REDO02A.LOG_bak

2012-09-22  13:23        52,429,312 REDO02B.LOG

2012-09-22  13:19        52,429,312 REDO02B.LOG_bak

2012-09-22  13:19        52,429,312 REDO03A.LOG

2012-09-22  13:19        52,429,312 REDO03B.LOG

(篇幅原因,部分省略……

              18 个文件  3,283,726,336 字节

               4 个目录 204,164,952,064 可用字节

 

 

 

Oracleclear log后,重新创建了日志文件。

 

 

3、完全关闭情况下当前日志组删除

 

如果是完全关闭情况下当前日志组删除,我们应该怎么处理?

 

 

SQL> select group#, archived, status, first_change# from v$log;

 

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#

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

         1 YES      INACTIVE               3567149

         2 NO       CURRENT                3576416

         3 YES      INACTIVE               3572332

 

SQL> select group#, type, member from v$logfile;

 

    GROUP# TYPE    MEMBER

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

         3 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03A.LOG

         2 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG

         1 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG

         1 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG

         3 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03B.LOG

         2 ONLINE  E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG

 

6 rows selected

 

SQL> shutdown immediate;

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

 

 

删除日志组成员,重新启动。

 

 

E:\oracle\product\10.2.0\oradata\orcl>rename REDO02A.LOG REDO02A.LOG_bak

E:\oracle\product\10.2.0\oradata\orcl>rename REDO02B.LOG REDO02B.LOG_bak

 

SQL> startup

ORACLE 例程已经启动。

 

Total System Global Area  603979776 bytes

Fixed Size                  1250380 bytes

Variable Size             159386548 bytes

Database Buffers          436207616 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'

 

 

使用Clear方法进行恢复尝试。

 

 

SQL> alter database clear logfile group 2;

alter database clear logfile group 2

*

1 行出现错误:

ORA-00350: 日志 2 (实例 orcl 的日志, 线程 1) 需要归档

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'

ORA-00312: 联机日志 2 线程 1:

'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'

 

 

当前日志中内容需要归档,所以不能直接进行clear log操作。笔者猜想:如果这里是非归档模式,是否就可以成功了?事实的确如此,下面为插入的实验过程。

 

--当前日志组为1

SQL> alter database clear logfile group 1;

Database altered.

 

SQL> alter database open;

Database altered.

 

SQL> select open_mode from v$database;

 

OPEN_MODE

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

READ WRITE

 

 

 

当前数据文件是一致性的。

 

 

SQL> select ts#, checkpoint_change#, last_change# from v$datafile;

 

       TS# CHECKPOINT_CHANGE# LAST_CHANGE#

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

         0            3577306      3577306

         1            3577306      3577306

         2            3577306      3577306

         4            3577306      3577306

         6            3577306      3577306

 

 

可以用recoverOracle进行虚拟的恢复动作,恢复到最后的状态。

 

 

SQL> recover database until cancel;

完成介质恢复。

SQL> alter database open;

alter database open

*

1 行出现错误:

ORA-01589: 要打开数据库则必须使用 RESETLOGS NORESETLOGS 选项

 

SQL> alter database open resetlogs;

 

数据库已更改。

 

 

虽然是until cancel,但是却没有数据会损失。只是在open的时候,需要使用resetlog模式重新开启一个新的朝代。

 

 

SQL> select open_mode, current_scn from v$database;

 

OPEN_MODE  CURRENT_SCN

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

READ WRITE     3577513

 

 

SQL> select group#, archived, status, first_change#,sequence# from v$log;

 

    GROUP# ARCHIVED STATUS           FIRST_CHANGE#  SEQUENCE#

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

         1 NO       CURRENT                3577308          2

         2 YES      INACTIVE               3577307          1

         3 YES      UNUSED                       0          0

 

结论:对于一致性关闭条件下,如果online日志组出现问题,即使发生文件丢失,也不会有数据丢失的情况,因为数据文件是一致的。

上述就是小编为大家分享的Online Redo Log损坏处理的实验分析了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注亿速云行业资讯频道。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI