我们知道通过设置nologging选项。能够加快oracle的某些操作的运行速度，这在运行某些维护任务时是非常实用的，可是该选项也非常危急，假设使用不当，就可能导致数据库发生ORA-26040错误。
首先。构造使用环境。
SQL> select tablespace_name,logging,force_logging from dba_tablespaces; TABLESPACE_NAME LOGGING FOR ------------------------------ --------- --- SYSTEM LOGGING NO UNDOTBS1 LOGGING NO SYSAUX LOGGING NO TEMP NOLOGGING NO USERS LOGGING NO LOGGING LOGGING NO 6 rows selected.
SQL> show user USER is "LOGGING" SQL> select table_name,logging from user_tables; TABLE_NAME LOG ------------------------------ --- SOURCE YES NOLOG NO NOLOG1 NO
我们使用create table table_name nologging as select * from user_tables创建了表nolog和nolog1。在创建表之前，先使用rman进行全库的备份，表创建完毕后，关闭数据库，并使用备份来恢复，结果例如以下：
[oraten@yue bdump]$ rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on 星期四 11月 13 17:21:02 2014
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ORATEN (DBID=3658365464, not open)
RMAN> list backup;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
97 Full 565.31M DISK 00:00:41 2014-11-12 09:34:45
BP Key: 65 Status: AVAILABLE Compressed: NO Tag: TAG20141112T093404
Piece Name: /home/app/oraten/flash_recovery_area/ORATEN/backupset/2014_11_12/o1_mf_nnndf_TAG20141112T093404_b65g8fc3_.bkp
List of Datafiles in backup set 97
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1276159 2014-11-12 09:34:04 /home/app/oraten/oradata/oraten/system01.dbf
2 Full 1276159 2014-11-12 09:34:04 /home/app/oraten/oradata/oraten/undotbs01.dbf
3 Full 1276159 2014-11-12 09:34:04 /home/app/oraten/oradata/oraten/sysaux01.dbf
4 Full 1276159 2014-11-12 09:34:04 /home/app/oraten/oradata/oraten/users01.dbf
5 Full 1276159 2014-11-12 09:34:04 /home/app/oraten/oradata/oraten/logging01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
98 Full 6.86M DISK 00:00:02 2014-11-12 09:34:52
BP Key: 66 Status: AVAILABLE Compressed: NO Tag: TAG20141112T093404
Piece Name: /home/app/oraten/flash_recovery_area/ORATEN/backupset/2014_11_12/o1_mf_ncsnf_TAG20141112T093404_b65g9vx2_.bkp
Control File Included: Ckp SCN: 1276545 Ckp time: 2014-11-12 09:34:50
SPFILE Included: Modification time: 2014-11-12 09:14:00
RMAN> restore database;
Starting restore at 2014-11-13 17:21:19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/app/oraten/oradata/oraten/system01.dbf
restoring datafile 00002 to /home/app/oraten/oradata/oraten/undotbs01.dbf
restoring datafile 00003 to /home/app/oraten/oradata/oraten/sysaux01.dbf
restoring datafile 00004 to /home/app/oraten/oradata/oraten/users01.dbf
restoring datafile 00005 to /home/app/oraten/oradata/oraten/logging01.dbf
channel ORA_DISK_1: reading from backup piece /home/app/oraten/flash_recovery_area/ORATEN/backupset/2014_11_12/o1_mf_nnndf_TAG20141112T093404_b65g8fc3_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/app/oraten/flash_recovery_area/ORATEN/backupset/2014_11_12/o1_mf_nnndf_TAG20141112T093404_b65g8fc3_.bkp tag=TAG20141112T093404
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 2014-11-13 17:21:45
RMAN> recover database;
Starting recover at 2014-11-13 17:21:50
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 53 is already on disk as file /home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_53_b65gj7m2_.arc
archive log thread 1 sequence 54 is already on disk as file /home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_54_b65kj77p_.arc
archive log thread 1 sequence 55 is already on disk as file /home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_13/o1_mf_1_55_b68w6tft_.arc
archive log filename=/home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_53_b65gj7m2_.arc thread=1 sequence=53
media recovery complete, elapsed time: 00:00:14
Finished recover at 2014-11-13 17:22:05
RMAN> alter database open;
database opened
RMAN>
alert 文件里的内容例如以下：
Thu Nov 13 17:21:20 CST 2014 Full restore complete of datafile 5 /home/app/oraten/oradata/oraten/logging01.dbf. Elapsed time: 0:00:00 checkpoint is 1276159 Full restore complete of datafile 4 /home/app/oraten/oradata/oraten/users01.dbf. Elapsed time: 0:00:00 checkpoint is 1276159 last deallocation scn is 672889 Full restore complete of datafile 2 /home/app/oraten/oradata/oraten/undotbs01.dbf. Elapsed time: 0:00:01 checkpoint is 1276159 last deallocation scn is 1252646 Full restore complete of datafile 3 /home/app/oraten/oradata/oraten/sysaux01.dbf. Elapsed time: 0:00:03 checkpoint is 1276159 last deallocation scn is 842824 Thu Nov 13 17:21:41 CST 2014 Full restore complete of datafile 1 /home/app/oraten/oradata/oraten/system01.dbf. Elapsed time: 0:00:10 checkpoint is 1276159 last deallocation scn is 399219 Thu Nov 13 17:21:51 CST 2014 alter database recover datafile list clear Thu Nov 13 17:21:51 CST 2014 Completed: alter database recover datafile list clear Thu Nov 13 17:21:51 CST 2014 alter database recover datafile list 1 , 2 , 3 , 4 , 5 Completed: alter database recover datafile list 1 , 2 , 3 , 4 , 5 Thu Nov 13 17:21:51 CST 2014 alter database recover if needed start Media Recovery Start parallel recovery started with 2 processes ORA-279 signalled during: alter database recover if needed start ... Thu Nov 13 17:21:51 CST 2014 alter database recover logfile '/home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_53_b65gj7m2_.arc' Thu Nov 13 17:21:51 CST 2014 Media Recovery Log /home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_53_b65gj7m2_.arc Thu Nov 13 17:21:52 CST 2014 Recovery of Online Redo Log: Thread 1 Group 3 Seq 54 Reading mem 0 Mem# 0: /home/app/oraten/oradata/oraten/redo03.log Thu Nov 13 17:21:54 CST 2014 Recovery of Online Redo Log: Thread 1 Group 1 Seq 55 Reading mem 0 Mem# 0: /home/app/oraten/oradata/oraten/redo01.log Thu Nov 13 17:21:59 CST 2014 Recovery of Online Redo Log: Thread 1 Group 2 Seq 56 Reading mem 0 Mem# 0: /home/app/oraten/oradata/oraten/redo02.log Thu Nov 13 17:22:02 CST 2014 Media Recovery Complete (oraten) Completed: alter database recover logfile '/home/app/oraten/flash_recovery_area/ORATEN/archivelog/2014_11_12/o1_mf_1_53_b65gj7m2_.arc' Thu Nov 13 17:22:11 CST 2014 alter database open Thu Nov 13 17:22:11 CST 2014 LGWR: STARTING ARCH PROCESSES ARC0 started with pid=21, OS id=6628 Thu Nov 13 17:22:11 CST 2014 ARC0: Archival started ARC1: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC1 started with pid=22, OS id=6630 Thu Nov 13 17:22:12 CST 2014 Thread 1 opened at log sequence 56 Current log# 2 seq# 56 mem# 0: /home/app/oraten/oradata/oraten/redo02.log Successful open of redo thread 1 Thu Nov 13 17:22:12 CST 2014 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Thu Nov 13 17:22:12 CST 2014 ARC0: Becoming the 'no FAL' ARCH ARC0: Becoming the 'no SRL' ARCH Thu Nov 13 17:22:12 CST 2014 ARC1: Becoming the heartbeat ARCH Thu Nov 13 17:22:12 CST 2014 SMON: enabling cache recovery Thu Nov 13 17:22:12 CST 2014 Successfully onlined Undo Tablespace 1. Thu Nov 13 17:22:12 CST 2014 SMON: enabling tx recovery Thu Nov 13 17:22:12 CST 2014 Database Characterset is AL32UTF8 Opening with internal Resource Manager plan replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=23, OS id=6632 Thu Nov 13 17:22:12 CST 2014 db_recovery_file_dest_size of 2048 MB is 28.34% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Thu Nov 13 17:22:13 CST 2014 Completed: alter database open从上面我们看出。一切正常，数据库成功恢复了。可是：
SQL> conn logging/logging
Connected.
SQL> select * from nolog;
select * from nolog
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 44)
ORA-01110: data file 5: '/home/app/oraten/oradata/oraten/logging01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
数据库报错，看来恢复成功并不一定数据库就是正常的。
再看一下，日志的的dump内容，
[oraten@yue udump]$ strings oraten_ora_10509.trc | grep oad Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry Direct Loader invalidate block range redo entry看来日志中对nologging是有记录的，在rman恢复时，会依据记录将某些块设置为逻辑损坏。