使用append+nologging引起恢复故障实验

Oracle的nologging属性是非常容易被滥用的。在我们之前的文章中，探讨过append+nologging对于Redo Log的影响。从文章的结论看：如

Oracle的nologging属性是非常容易被滥用的。在我们之前的文章中，探讨过append+nologging对于Redo Log的影响。从文章的结论看：如果我们使用append配合nologging，的确是可以减少Redo Log的生成的。
 
但是，这样做真的有好处吗？

希望减少Redo Log生成的思路无非是：Redo Log生成量少了，这样在LGWR写入的量就少了，从而带来的物理IO和日志切换动作就少了。但是，随着带来的问题是：日志少了真的没有问题吗？
 
Oracle Redo Log是数据库的重要对象，原始提出Redo Log的目的在于“日志在先，数据恢复”。从宏观上看，Redo Log是保证数据库事务一致性的手段。但更重要的是，Redo Log是数据库内部一致性、数据库完全恢复和高可用性组件（DG、OGG）的重要技术基础。
 
Redo Log是描述数据块变化的记录信息，，其中包括逻辑变化和物理变化。本篇就通过实验来确定Append+Nologging给备份还原带来的问题。

--------------------------------------分割线 --------------------------------------

相关阅读：

关于Redo Log的修改与重建

MySQL 5.6更人性化修改Redo Log事务日志文件大小

ORA-00314,RedoLog 损坏，或丢失处理方法

Oracle数据库级drop RedoLog并不危险

Oracle 联机重做日志文件(online Redo Log file) 详述

--------------------------------------分割线 --------------------------------------

1、环境准备和备份

 

我们选择Oracle 11gR2进行测试。为了保证一致性，我们首先进行一次热备份动作。

 

RMAN> backup database plus archivelog delete all input;

 

Starting backup at 10-DEC-13

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=38 device type=DISK

（篇幅原因，有省略……）

 

Starting Control File and SPFILE Autobackup at 10-DEC-13

piece handle=/u01/flash_recovery_area/WILSON/autobackup/2013_12_10/o1_mf_s_833787521_9bdo43ol_.bkp comment=NONE
 
Finished Control File and SPFILE Autobackup at 10-DEC-13

 

此时，配合归档模式，我们是可以实现完全恢复的。

 

RMAN> list backup;

 

List of Backup Sets

===================

 

BS Key  Type LV Size      Device Type Elapsed Time Completion Time

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

130    Full    1.31G      DISK        00:01:55    10-DEC-13     

        BP Key: 130  Status: AVAILABLE  Compressed: NO  Tag: TAG20131210T073642
 
        Piece Name: /u01/flash_recovery_area/WILSON/backupset/2013_12_10/o1_mf_nnndf_TAG20131210T073642_9bdo0djj_.bkp
 
  List of Datafiles in backup set 130

（篇幅原因，有省略……）

  SPFILE Included: Modification time: 10-DEC-13

  SPFILE db_unique_name: WILSON

  Control File Included: Ckp SCN: 5260073      Ckp time: 10-DEC-13

 

 

2、一次append+nologging动作

 

我们创建一张数据表T，将其nologging属性设置为Y。

 

SQL> create table t as select * from dba_objects where 1=0;

Table created

 

SQL> alter table t nologging;

Table altered

 

使用insert append插入数据。

 

SQL> insert /*+append*/ into t select * from dba_objects;

72768 rows inserted

 

SQL> commit;

Commit complete

 

 

3、启动恢复过程

 

如果此时发生系统故障，数据丢失，需要进行数据恢复动作。试图使用RMAN来进行完全恢复。

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area  849530880 bytes

Fixed Size                  1339824 bytes

Variable Size            511708752 bytes

Database Buffers          331350016 bytes

Redo Buffers                5132288 bytes

Database mounted.

 

启用RMAN恢复过程。

 

--Restore过程

RMAN> restore database;

 

Starting restore at 10-DEC-13

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

 

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

（篇幅原因，有省略……）

channel ORA_DISK_1: piece handle=/u01/flash_recovery_area/WILSON/backupset/2013_12_10/o1_mf_nnndf_TAG20131210T073642_9bdo0djj_.bkp tag=TAG20131210T073642
 
channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:07:05

Finished restore at 10-DEC-13

 

--Recover应用Redo Log

RMAN> recover database;

 

Starting recover at 10-DEC-13

using channel ORA_DISK_1

 

starting media recovery

media recovery complete, elapsed time: 00:00:12

 

Finished recover at 10-DEC-13

 

RMAN>

 

恢复过程没有明显的错误标志，恢复似乎是成功了。之后打开数据库。

 

RMAN> alter database open;

database opened

更多详情见请继续阅读下一页的精彩内容：