今天在做一些演示的时候，在虚拟机上装了两套数据库软件，10g和11g的。还是在演示普通数据文件迁移的时候还是碰到了一些意料之外的问题，从当时的情况来看感觉还是比较诡异的，所以马上切换到另外一套环境去试验就没有任何问题了。对于这个问题事后进行了分析，发现还是一些简单常规的错误，自己还是对一些细节没有掌握好，
本来对于普通数据文件的迁移流程是很简单的，在数据库open状态就可以迁移，
基本步骤如下：
alter tablespace xxxx offline;
cp datafiles
alter tablespace xxx rename sourcexxxxx to targetxxxxx;
alter tablespace xxxxx online;
结果在11g的环境演示的时候，自己为了图省事，想offline更快些，就直接用了offline immediate的选项。
SQL> alter tablespace data offline immediate;
Tablespace altered.
然后敲了下面的命令尝试拷贝数据文件，但是抛出的错误看起来满高深的，其实就是最后的单引号导致的。
SQL> !cp /u02/ora11g/oradata/TEST/disk4/data01.dbf /u02/ora11g/oradata/TEST/disk3/data01.dbf'
/bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 1: syntax error: unexpected end of file
[ora11g@oel1 ~]$ cp /u02/ora11g/oradata/TEST/disk4/data01.dbf /u02/ora11g/oradata/TEST/disk3/data01.dbf
[ora11g@oel1 ~]$ orasql
然后直接拷贝数据文件
SQL> alter tablespace data rename datafile '/u02/ora11g/oradata/TEST/disk4/data01.dbf' to '/u02/ora11g/oradata/TEST/disk3/data01.dbf';
Tablespace altered.
然后开始做online操作，这也是一个常规操作，但是抛出了下面的错误。
SQL> alter tablespace data online;
alter tablespace data online
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/disk3/data01.dbf'
这个时候从日志来看是数据文件需要介质恢复。
结果想马上把问题修好，就直接用了recover database，结果从错误来看就更有些玄妙了。
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 1 - file is in use or recovery
ORA-01110: data file 1: '/u02/ora11g/oradata/TEST/disk5/system01.dbf'
似乎这个时候恢复还是一个看似不能完成的任务，果断放弃这个环境，切换到10g的环境，老老实实的做了一遍文件的迁移，这次就没有任何问题了。
步骤如下：
SQL> select tablespace_name from user_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS
TEMP
SQL> create tablespace data datafile '/u02/ora11g/oradata/TEST/disk3/data01.dbf' size 10M;
Tablespace created.
SQL> alter tablespace data offline;
Tablespace altered.
SQL> !cp /u02/ora11g/oradata/TEST/disk3/data01.dbf /u02/ora11g/oradata/TEST/disk4/data02.dbf
SQL> alter tablespace data rename datafile '/u02/ora11g/oradata/TEST/disk3/data01.dbf' to '/u02/ora11g/oradata/TEST/disk4/data02.dbf';
Tablespace altered.
SQL> alter tablespace data online;
Tablespace altered.
从整个过程来看，唯一的不同之处就在于出问题的那个环境我使用了offline immediate选项
从官方查看offline的这几个选项，可以看到还是有很大的不同，默认使用的是normal选项。
OFFLINE NORMAL Specify NORMAL to flush all blocks in all data files in the tablespace out of the system global area (SGA). You need not perform media recovery on this tablespace before bringing it back online. This is the default.
OFFLINE TEMPORARY If you specify TEMPORARY, then Oracle Database performs a checkpoint for all online data files in the tablespace but does not ensure that all files can be written. Files that are offline when you issue this statement may require media recovery before you bring the tablespace back online.
OFFLINE IMMEDIATE If you specify IMMEDIATE, then Oracle Database does not ensure that tablespace files are available and does not perform a checkpoint. You must perform media recovery on the tablespace before bringing it back online.
所以在自己使用offline immediate的时候，这个时候还没有做checkpoint，如果要使用online选项的时候，还是需要做recover操作。
大体明白了这么多，那么怎么修复呢，
SQL> alter tablespace data online;
alter tablespace data online
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/disk4/data02.dbf'
SQL> recover datafile 4;
Media recovery complete.
SQL> alter tablespace data online;
Tablespace altered.
或者说在一些关键的操作的时候还是最好能够做checkpoint，也就是使用默认的offline normal选项。
这是一个很简单很基础的问题，但是在特定时间里可能就没有意识到，看来还是需要不断巩固，多做练习：）