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
更多详情见请继续阅读下一页的精彩内容：