6、非归档情况Offline处理
上面的一系列讨论，都是在归档文件模式下进行的实验。如果在非归档情况下，我们面对的问题是不同的。
首先，非归档模式下，表空间可以进行normal offline操作。
SQL> alter database noarchivelog;
Database altered.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 22
Current log sequence 24
创建表空间，查看文件状态的。
SQL> create tablespace testtbs datafile size 10m extent management local uniform. size 1m segment space management auto;
Tablespace created
SQL> alter tablespace testtbs add datafile size 20m autoextend on;
Tablespace altered
SQL> select tablespace_name, status from dba_tablespaces where tablespace_name=’TESTTBS’;
TABLESPACE_NAME STATUS
—————————— ———
TESTTBS ONLINE
SQL> select file_name, status, online_status from dba_data_files where tablespace_name=’TESTTBS’;
FILE_NAME STATUS ONLINE_STATUS
——————– ——— ————-
/u01/app/oradata/ORA AVAILABLE ONLINE
11G/datafile/o1_mf_t
esttbs_94hsw8oo_.dbf
/u01/app/oradata/ORA AVAILABLE ONLINE
11G/datafile/o1_mf_t
esttbs_94hswx27_.dbf
正常Offline Tablespace。
SQL> alter tablespace testtbs offline normal;
Tablespace altered
SQL> select tablespace_name, status from dba_tablespaces where tablespace_name=’TESTTBS’;
TABLESPACE_NAME STATUS
—————————— ———
TESTTBS OFFLINE
SQL> select file_name, status, online_status from dba_data_files where tablespace_name=’TESTTBS’;
FILE_NAME STATUS ONLINE_STATUS
——————– ——— ————-
/u01/app/oradata/ORA AVAILABLE OFFLINE
11G/datafile/o1_mf_t
esttbs_94hsw8oo_.dbf
/u01/app/oradata/ORA AVAILABLE OFFLINE
11G/datafile/o1_mf_t
esttbs_94hswx27_.dbf
SQL> alter tablespace testtbs online;
Tablespace altered
在非归档模式下，单独对数据文件进行offline是不允许的。
SQL> alter database datafile ‘/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hsw8oo_.dbf’ offline;
alter database datafile ‘/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hsw8oo_.dbf’ offline
ORA-01145: 除非启用了介质恢复, 否则不允许立即脱机
试想一下，这个过程是可以理解的。Oracle认为：如果你将文件进行offline，与表空间不一致。那么，一旦文件online的时候，一定是需要进行recover来“追”上表空间中其他文件。这个过程就是需要连续的redo log来进行apply动作。
在非归档模式下，连续的操作redo log file是不容易拿到的。从Oracle理论上，也就认为说不可能拿到的。所以，这个时候，Oracle索性禁止这种操作行为。
那么，是不是非归档模式下，就不允许进行单独文件的offline了呢？不是的，只要你“允诺”说不会再回来。
通过后台，我们删除了数据文件。
—删除掉数据文件
[oracle@SimpleLinux ~]$ rm /u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf
[oracle@SimpleLinux ~]$
SQL> alter system checkpoint;
alter system checkpoint
此时，数据库发现故障，实例终止。注意：不同版本Oracle在这个问题上行为有一些差异。CKPT将实例终止。
Sun Sep 29 16:59:08 2013
Beginning global checkpoint up to RBA [0x18.ad3e.10], SCN: 1062240
Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ckpt_27311.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01116: error in opening database file 7
ORA-01110: data file 7: ‘/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf’
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ckpt_27311.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01116: error in opening database file 7
ORA-01110: data file 7: ‘/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf’
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
Sun Sep 29 16:59:08 2013
System state dump requested by (instance=1, sid=27311 (CKPT)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_diag_27299.trc
CKPT (ospid: 27311): terminating the instance due to error 1242
Dumping diagnostic data in directory=[cdmp_20130929165908], requested by (instance=1, sid=27311 (CKPT)), summary=[abnormal instance termination].
Instance terminated by CKPT, pid = 27311
—数据库终止
[oracle@SimpleLinux ~]$ ps -ef | grep pmon
oracle 27487 27404 0 17:00 pts/2 00:00:00 grep pmon
[oracle@SimpleLinux ~]$
我们将数据库启动到mount状态，之后可以offline drop文件。
—启动到mount状态。
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 376635392 bytes
Fixed Size 1345072 bytes
Variable Size 306186704 bytes
Database Buffers 62914560 bytes
Redo Buffers 6189056 bytes
Database mounted.
SQL> select file#, status, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;
FILE# STATUS RECOVER FUZZY CHECKPOINT_CHANGE#
———- ——- ——- —– ——————
1 ONLINE NO YES 1062240
2 ONLINE NO YES 1062240
3 ONLINE NO YES 1062240
4 ONLINE NO YES 1062240
5 ONLINE NO YES 1062240
6 ONLINE NO YES 1062240
7 ONLINE 0
7 rows selected
—直接offline不允许
SQL> alter database datafile 7 offline;
alter database datafile 7 offline
ORA-01145: 除非启用了介质恢复, 否则不允许立即脱机
—未打开情况下，表空间状态不明确
SQL> alter tablespace testtbs offline;
alter tablespace testtbs offline
ORA-01109: 数据库未打开
–Offline Drop
SQL> alter database datafile 7 offline drop;
Database altered
SQL> alter database open;
Database altered
SQL> drop tablespace testtbs;
Tablespace dropped
顾名思义，Offline Drop就是永久性的删除这个对象，也就不需要了。更不要提到重新回归online。
7、结论
最后，我们来总结一下Offline三种参数的情况。
offline normal：是最常用的场景，也是最不容易出问题的场景。Offline Normal的时候，Oracle会在表空间内部进行Check Point动作，保证表空间内部各个文件头上面的SCN一致，也就是数据一致。如果存在数据文件不能前推SCN，如已经Offline，的情况，offline normal失效报错。
offline temporary：比Normal要求略松的一种关闭模式。Temporary模式下，Oracle依然会去“尝试”统一表空间内部文件头的SCN号。如果数据文件可以统一，就进行Check Point动作，如果文件不能统一，操作也不会报错，只是将其状态标记为不一致。Temporary模式下Offline的表空间Online的时候，那些“有问题”的不一致文件，是需要进行media recovey的。没有问题，打入check point的数据文件，就不需要进行恢复动作。
offline immediate：最松的一种offline模式。Immediate模式下，Oracle不会进行check point动作，无论有无问题的Datafile，都会被设置为需要Recover过程。在重新online的时候，表空间就需要进行重新的全表空media recover。
在日常选择上，我们倾向严格的原则。因为非Normal方式的offline，都需要借助外部的redo log进行media recover动作。选择的顺序是normal，temporary和immediate。
Oracle表空间的Offline动作，是我们非常常用的一种日常维护操作手段。
