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

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的修改与重建 http://www.linuxidc.com/Linux/2014-04/100799.htmMySQL 5.6更人性化修改Redo Log事务日志文件大小 http://www.linuxidc.com/Linux/2014-02/97135.htmORA-00314,RedoLog 损坏，或丢失处理方法 http://www.linuxidc.com/Linux/2013-09/90646.htmOracle数据库级drop RedoLog并不危险 http://www.linuxidc.com/Linux/2013-08/88852.htmOracle 联机重做日志文件（online Redo Log file）详述 http://www.linuxidc.com/Linux/2013-06/86290.htm--------------------------------------分割线 --------------------------------------1、环境准备和备份我们选择Oracle 11gR2进行测试。为了保证一致性，我们首先进行一次热备份动作。 RMAN> backup database plus archivelog delete all input; Starting backup at 10-DEC-13current log archivedallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=38 device type=DISK（篇幅原因，有省略……） Starting Control File and SPFILE Autobackup at 10-DEC-13piece 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 sysdbaConnected to an idle instance.SQL> startup mount;ORACLE instance started. Total System Global Area 849530880 bytesFixed Size 1339824 bytesVariable Size 511708752 bytesDatabase Buffers 331350016 bytesRedo Buffers 5132288 bytesDatabase mounted. 启用RMAN恢复过程。 --Restore过程RMAN> restore database; Starting restore at 10-DEC-13allocated channel: ORA_DISK_1channel ORA_DISK_1: SID=18 device type=DISK channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile（s） to restore from backup setchannel 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 1channel ORA_DISK_1: restore complete, elapsed time: 00:07:05Finished restore at 10-DEC-13 --Recover应用Redo LogRMAN> recover database; Starting recover at 10-DEC-13using channel ORA_DISK_1 starting media recoverymedia recovery complete, elapsed time: 00:00:12 Finished recover at 10-DEC-13 RMAN> 恢复过程没有明显的错误标志，恢复似乎是成功了。之后打开数据库。 RMAN> alter database open;database opened更多详情见请继续阅读下一页的精彩内容： http://www.linuxidc.com/Linux/2014-05/101281p2.htm

使用Procwatcher监控Oracle数据库锁定ContentionOracle 11g 手工不完全恢复相关资讯 redo log append nologging

Oracle 11g的Redo Log和Archive （昨 06:56）
管理REDO LOG记录（07/20/2015 20:58:10）
删除redo log group or member （04/25/2013 09:09:20）

archive log文件大小与redo log文（07/23/2015 16:50:33）
关于redo log的修改与重建（04/26/2014 10:13:55）
如何重新配置redo log 的位置（04/25/2013 09:08:01）

本文评论查看全部评论（0）