Oracle中表空间offline的三种参数对比案例

Oracle数据库管理中，对表空间操作是基础中的基础。其中，表空间Offline是我们经常接触的。同数据文件Offline一起，构成了Oracle维护数据一致性的重要体系结构。

一般我们比较常接触到的，就是直接的alter tablespace xxx offline操作。但是在实际中，针对表空间对应数据文件的不同情况，Oracle提供了三种offline的参数。同数据库关闭shutdown对应的若干种参数一样，不同的offline参数对应Oracle不同的行为，更引出后续不同的处理方法。

下面是Oracle11g官方文档关于表空间offline的相关解释说明：

*************************************************************************************************************

You may want to take a tablespace offline for any of the following reasons:

• To make a portion of the database unavailable while allowing normal access to the remainder of the database
• To perform an offline tablespace backup (even though a tablespace can be backed up while online and in use)
• To make an application and its group of tables temporarily unavailable while updating or maintaining the application
• To rename or relocate tablespace datafiles

希望使表空间offline的原因如下：

?使数据库的一部分不访问，同时允许正常访问数据库的其余部分

?要执行脱机表空间备份（即使可以在线并在使用中备份表空间）

?在更新或维护应用程序时，使应用程序及其一组表暂时不可用

?重命名或重新定位表空间数据文件

When a tablespace is taken offline, the database takes all the associated files offline.

当表空间脱机时，数据库会将所有关联的文件脱机。

You cannot take the following tablespaces offline:

• SYSTEM
• The undo tablespace
• Temporary tablespaces

SYSTEM、undo表空间、临时表空间不可以offline；

Before taking a tablespace offline, consider altering the tablespace allocation of any users who have been assigned the tablespace as a default tablespace. Doing so is advisable because those users will not be able to access objects in the tablespace while it is offline.

在使表空间脱机之前，请考虑将已分配表空间的任何用户的表空间分配更改为默认表空间。 这样做是可取的，因为这些用户在脱机时将无法访问表空间中的对象。

You can specify any of the following parameters as part of the ALTER TABLESPACE...OFFLINE statement:

Caution:

If you must take a tablespace offline, use the NORMAL clause (the default) if possible. This setting guarantees that the tablespace will not require recovery to come back online, even if after incomplete recovery you reset the redo log sequence using an ALTER DATABASE OPEN RESETLOGS statement.

如果必须使表空间脱机，请尽可能使用NORMAL子句（默认值）。 此设置保证表空间不需要恢复在线恢复，即使在不完全恢复后，使用ALTER DATABASE OPEN RESETLOGS语句重置重做日志序列。

Speify TEMPORARY only when you cannot take the tablespace offline normally. In this case, only the files taken offline because of errors need to be recovered before the tablespace can be brought online. Specify IMMEDIATE only after trying both the normal and temporary settings.

仅在不能使表空间正常脱机时指定TEMPORARY。 在这种情况下，只有在出现错误的情况下离线的文件需要在表空间上线之前恢复。 仅在尝试正常和临时设置之后才指定IMMEDIATE。

The following example takes the users tablespace offline normally:

ALTER TABLESPACE users OFFLINE NORMAL;

*************************************************************************************************************

通过以上官方文档的说明，将表空间进行Offline的命令很简单，就是alter tablespace xxx offline；根据不同的情况，可以使用三种参数进行命令修饰，分别为normal、temporary和immediate。三个命令分别对应了Offline过程的不同行为。

下面的实验中，我们通过具体的案例来区别三种命令参数的不同之处：

实验环境：

（注意：是否归档模式对于数据表空间和文件Offline行为至关重要！）

SYS@seiang11g>select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE 11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 - Production

SYS@seiang11g>archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /u01/app/oracle/arch

Oldest online log sequence 50

Next log sequence to archive 52

Current log sequence 52

示例一：归档模式下offline normal

创建表空间wjqtest，为了更加明显进行试验，该表空间由两个数据文件构成。

SYS@seiang11g>create tablespace wjqtest datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf' size 5M

2 extent management local uniform size 1M

3 segment space management auto;

Tablespace created.

SYS@seiang11g>

SYS@seiang11g>alter tablespace wjqtest add datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf' size 5M;

Tablespace altered.

SYS@seiang11g>select tablespace_name,status from dba_tablespaces where tablespace_name='WJQTEST';

TABLESPACE_NAME STATUS

------------------------------ ---------

WJQTEST ONLINE

SYS@seiang11g>select file_name,status,online_status from dba_data_files where tablespace_name='WJQTEST';

FILE_NAME STATUS ONLINE_

-------------------------------------------------- --------- -------

/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf AVAILABLE ONLINE

/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf AVAILABLE ONLINE

SCOTT@seiang11g>create table wjqtest tablespace wjqtest as select * from dba_objects where rownum<1000;

Table created.

SCOTT@seiang11g>select count(*) from wjqtest;

COUNT(*)

----------

999

SYS@seiang11g>alter tablespace wjqtest offline normal;

Tablespace altered.

SYS@seiang11g>select tablespace_name ,status from dba_tablespaces where tablespace_name='WJQTEST';

TABLESPACE_NAME STATUS

------------------------------ ---------

WJQTEST OFFLINE

SYS@seiang11g>select file_name,status,online_status from dba_data_files where tablespace_name='WJQTEST';

FILE_NAME STATUS ONLINE_

-------------------------------------------------- --------- -------

/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf AVAILABLE OFFLINE

/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf AVAILABLE OFFLINE

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:19:22 2017

alter tablespace wjqtest offline normal

Completed: alter tablespace wjqtest offline normal

Tue Sep 26 13:19:22 2017

Starting background process SMCO

Tue Sep 26 13:19:22 2017

SMCO started with pid=31, OS id=6497

Tue Sep 26 13:19:30 2017

Checker run found 3 new persistent data failures

数据文件一个很重要的内容就是数据文件头的SCN号。我们知道，如果完全关闭数据库或者check point的时候，Oracle是要保证控制文件和数据文件头的SCN一致。

SYS@seiang11g>select file#, status, recover, fuzzy, checkpoint_change# from v$datafile_header;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE#

---------- ------- --- --- ------------------

1 ONLINE NO YES 1860869

2 ONLINE NO YES 1860869

3 ONLINE NO YES 1860869

4 ONLINE NO YES 1860869

5 ONLINE NO YES 1860869

6 ONLINE NO YES 1860869

7 ONLINE NO YES 1860869

8 OFFLINE 0

9 OFFLINE 0

9 rows selected.

SYS@seiang11g>

SYS@seiang11g>select file#,checkpoint_change#,online_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE#

---------- ------------------ --------------

1 1860869 925702

2 1860869 925702

3 1860869 925702

4 1860869 925702

5 1860869 951158

6 1860869 0

7 1860869 0

8 1862009 0

9 1862009 0

9 rows selected.

RMAN> list failure all;

using target database control file instead of recovery catalog

List of Database Failures

=========================

Failure ID Priority Status Time Detected Summary

---------- -------- --------- ------------- -------

254 HIGH OPEN 26-SEP-17 Tablespace 9: 'WJQTEST' is offline

222 HIGH OPEN 26-SEP-17 One or more non-system datafiles are offline

如果是正常的offline normal，是可以直接online回正常的表空间。

SYS@seiang11g>alter tablespace wjqtest online;

Tablespace altered.

SYS@seiang11g>select file#, status, recover, fuzzy, checkpoint_change# from v$datafile_header;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE#

---------- ------- --- --- ------------------

1 ONLINE NO YES 1860869

2 ONLINE NO YES 1860869

3 ONLINE NO YES 1860869

4 ONLINE NO YES 1860869

5 ONLINE NO YES 1860869

6 ONLINE NO YES 1860869

7 ONLINE NO YES 1860869

8 ONLINE NO YES 1862119

9 ONLINE NO YES 1862119

9 rows selected.

SYS@seiang11g>

SYS@seiang11g>select file#,checkpoint_change#,online_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE#

---------- ------------------ --------------

1 1860869 925702

2 1860869 925702

3 1860869 925702

4 1860869 925702

5 1860869 951158

6 1860869 0

7 1860869 0

8 1862119 1862119

9 1862119 1862119

9 rows selected.

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:21:47 2017

alter tablespace wjqtest online

Completed: alter tablespace wjqtest online

RMAN> list failure all;

no failures found that match specification

在数据库正常情况下，出于对性能考虑数据文件头SCN号是不能维持一致的。我们使用offline normal之后，各个数据文件头SCN相同。所以，offline normal特性是在offline的时候，要在表空间所有文件上打check point，只要能够打上SCN号，offline normal是可以正常完成的。也就是说，offline normal是表空间各个文件一致性的关闭。

示例二：归档模式下offline temporary

Offline Normal是一种比较理想的情况。在很多时候，Offline一个Tablespace的时候，并不能执行成功。比如，在offline操作的时候，如果此时有正在进行的对表空间对象的DDL和DML操作，offline可能会受到影响。此外，如果一个表空间中有数据文件已经被Offline过了，我们正常是不能够进行offline normal的。此时，我们就需要使用temporary。

我们首先将表空间的其中一个数据文件offline。

SYS@seiang11g>alter database datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf' offline;

Database altered.

注意：这个操作是在Archivelog模式下才能进行。如果是在非归档模式下，直接offline表空间中的一个数据文件会出现ORA-01145的错误如下所示:
SYS@seiang11g>alter database datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf' offline;
alter database datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf' offline
*
ERROR at line 1:
ORA-01145: offline immediate disallowed unless media recovery enabled

SYS@seiang11g>!oerr ora 01145
01145, 00000, "offline immediate disallowed unless media recovery enabled"
// *Cause: ALTER TABLESPACE ... OFFLINE IMMEDIATE or ALTER DATABASE DATAFILE
// ... OFFLINE is only allowed if database is in ARCHIVELOG mode.
// *Action:Take tablespace offline normally or shutdown abort. Reconsider your
// backup strategy. You could do this if you were archiving your logs.

要想对数据文件脱机，必须在归档模式下，这是Oracle自动保护的一种措施，防止在非归档模式下对数据文件脱机，造成数据丢失。

解决办法：
可以在非归档模式下，
使用alter database datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf ' offline for drop；语句将数据文件脱机，drop并不会删除物理文件。如果没有使用alter system switch logfile;切换日志文件组，那么可以采用recover datafile XXX;来恢复，并联机。如果已切换日志文件组并清空了里面的内容，这个数据文件就不能再恢复联机，永远处于recover状态（可以通过v$datafile视图查看)。所以如果在实际的生产环境中，尽量在归档模式下做脱机数据文件操作。

SYS@seiang11g>

SYS@seiang11g>select tablespace_name,status from dba_tablespaces where tablespace_name='WJQTEST';

TABLESPACE_NAME STATUS

------------------------------ ---------

WJQTEST ONLINE

观察表空间和数据文件状态，发现被offline的数据文件状态为Recover。

SYS@seiang11g>select file_name,status,online_status from dba_data_files where tablespace_name='WJQTEST';

FILE_NAME STATUS ONLINE_

-------------------------------------------------- --------- -------

/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf AVAILABLE RECOVER

/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf AVAILABLE ONLINE

看到的文件recover状态，就表明如果需要这个文件回到Online状态，需要进行Recover。此时，Online状态表空间下的几个文件状态是不一致的。

注意，Oracle维持数据文件一致性，是一个动态一致性的过程。如果某一个文件或者对象临时性的退出了这个一致性机制，就表示这个文件或者对象已经不一致。如果该对象希望回归到原有的一致性体系里面，就需要进行Recover。Oracle进行Recover手段就需要借助于连续的redo log文件。

尝试使用offline normal表空间

SYS@seiang11g>alter tablespace wjqtest offline normal;

alter tablespace wjqtest offline normal

*

ERROR at line 1:

ORA-01191: file 8 is already offline - cannot do a normal offline

ORA-01110: data file 8: '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf'

SCOTT@seiang11g>create table tb_test tablespace wjqtest as select * from dba_objects where 1=0;

Table created.

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:26:53 2017

alter tablespace wjqtest offline normal

ORA-1191 signalled during: alter tablespace wjqtest offline normal...

Tue Sep 26 13:26:53 2017

Checker run found 1 new persistent data failures

正常normal offline已经不能成功了。此时可以使用temporary参数。

SYS@seiang11g>alter tablespace wjqtest offline temporary;

Tablespace altered.

SYS@seiang11g>

SYS@seiang11g>select tablespace_name,status from dba_tablespaces where tablespace_name='WJQTEST';

TABLESPACE_NAME STATUS

------------------------------ ---------

WJQTEST OFFLINE

SYS@seiang11g>

SYS@seiang11g>select file_name,status,online_status from dba_data_files where tablespace_name='WJQTEST';

FILE_NAME STATUS ONLINE_

-------------------------------------------------- --------- -------

/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf AVAILABLE RECOVER

/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf AVAILABLE OFFLINE

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:30:01 2017

alter tablespace wjqtest offline temporary

Completed: alter tablespace wjqtest offline temporary

Tue Sep 26 13:30:15 2017

Checker run found 2 new persistent data failures

使用temporary参数实现了Offline。但是对于那个提前进行offline的数据文件，状态依然是recover。猜想，Temporary Offline的过程是一种不一致的关闭。

查看视图v$datafile和v$datafile_header反映了控制文件和数据文件头中文件SCN号的记录。在offline normal的时候，我们看到了各个文件的一致性。在进行offline normal的时候，Oracle是打入了一个check point（内部），来同步各个文件的文件头SCN。

在使用Temporary的时候，视图状态如何呢？

SYS@seiang11g>select file#, status, recover, fuzzy, checkpoint_change# from v$datafile_header;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE#

---------- ------- --- --- ------------------

1 ONLINE NO YES 1860869

2 ONLINE NO YES 1860869

3 ONLINE NO YES 1860869

4 ONLINE NO YES 1860869

5 ONLINE NO YES 1860869

6 ONLINE NO YES 1860869

7 ONLINE NO YES 1860869

8 OFFLINE YES YES 1862119

9 OFFLINE NO NO 1862456

9 rows selected.

SYS@seiang11g>

SYS@seiang11g>select file#,checkpoint_change#,online_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE#

---------- ------------------ --------------

1 1860869 925702

2 1860869 925702

3 1860869 925702

4 1860869 925702

5 1860869 951158

6 1860869 0

7 1860869 0

8 1862119 1862119

9 1862456 1862119

9 rows selected.

控制文件和数据文件头上面两个文件的SCN编号不相同，说明在一个表空间内部文件的SCN号是不一致的。

说明：在Temporary Offline的时候，一些"有问题"的数据文件和"没问题"的数据文件状态是可以不一样。"没问题"的数据文件之间SCN号是一致。

如果此时直接Online表空间的话会报错ORA-01113和ORA-01110。

SYS@seiang11g>alter tablespace wjqtest online;

alter tablespace wjqtest online

*

ERROR at line 1:

ORA-01113: file 8 needs media recovery

ORA-01110: data file 8: '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf'

在online的时候，Oracle一定会去online一个"一致"的表空间。此时，它会发现表空间内部SCN的不一致。根据提示，我们需要手工进行文件恢复。

SYS@seiang11g>recover datafile 8;

Media recovery complete.

SYS@seiang11g>alter tablespace wjqtest online;

Tablespace altered.

online成功了，在alert 日志中看到了进行media recovery中使用的redo log apply乃至archived redo log apply过程。注意：此时我们只恢复了datafile 6。

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:34:05 2017

ALTER DATABASE RECOVER datafile 8

Media Recovery Start

Serial Media Recovery started

Recovery of Online Redo Log: Thread 1 Group 1 Seq 52 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/OraDB11g/redo01.log

Media Recovery Complete (seiang11g)

Completed: ALTER DATABASE RECOVER datafile 8

SYS@seiang11g>select file#, status, recover, fuzzy, checkpoint_change# from v$datafile_header;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE#

---------- ------- --- --- ------------------

1 ONLINE NO YES 1860869

2 ONLINE NO YES 1860869

3 ONLINE NO YES 1860869

4 ONLINE NO YES 1860869

5 ONLINE NO YES 1860869

6 ONLINE NO YES 1860869

7 ONLINE NO YES 1860869

8 ONLINE NO YES 1863020

9 ONLINE NO YES 1863020

9 rows selected.

SYS@seiang11g>

SYS@seiang11g>select file#,checkpoint_change#,online_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE#

---------- ------------------ --------------

1 1860869 925702

2 1860869 925702

3 1860869 925702

4 1860869 925702

5 1860869 951158

6 1860869 0

7 1860869 0

8 1863020 1862119

9 1863020 1862119

示例三：归档模式下offline immediate

首先对表空间中的一个数据文件进行offline，然后再对相应的表空间进行offline，就会出现报错ORA-01191和ORA-01110

SYS@seiang11g>alter database datafile '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf' offline;

Database altered.

SYS@seiang11g>

SYS@seiang11g>alter tablespace wjqtest offline;

alter tablespace wjqtest offline

*

ERROR at line 1:

ORA-01191: file 8 is already offline - cannot do a normal offline

ORA-01110: data file 8: '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf'

此处使用offline immediate操作。

SYS@seiang11g>alter tablespace wjqtest offline immediate;

Tablespace altered.

SYS@seiang11g>

SYS@seiang11g>select file#, status, recover, fuzzy, checkpoint_change# from v$datafile_header;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE#

---------- ------- --- --- ------------------

1 ONLINE NO YES 1863090

2 ONLINE NO YES 1863090

3 ONLINE NO YES 1863090

4 ONLINE NO YES 1863090

5 ONLINE NO YES 1863090

6 ONLINE NO YES 1863090

7 ONLINE NO YES 1863090

8 OFFLINE YES YES 1863090

9 OFFLINE YES YES 1863090

9 rows selected.

SYS@seiang11g>

SYS@seiang11g>select file#,checkpoint_change#,online_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE#

---------- ------------------ --------------

1 1863090 925702

2 1863090 925702

3 1863090 925702

4 1863090 925702

5 1863090 951158

6 1863090 0

7 1863090 0

8 1863090 1862119

9 1863090 1862119

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:40:52 2017

alter tablespace wjqtest offline immediate

Completed: alter tablespace wjqtest offline immediate

immediate和temporary相似地方是：在"有问题"数据文件存在的情况下，表空间依然可以进行Offline操作。但是区别是，Oracle在immediate参数情况下，就不会给任何数据文件进行check point统一SCN动作了。这种方法类似于shutdown abort。无论文件是不是有问题，Oracle都不进行检查和统一动作。

有一个细节需要注意，就是v$datafile_header中的recover列。在normal参数的时候，这个列是不显示的，也就是表示这个问题不需要关注和理睬。在tempory模式下，只有那些"有问题"文件才会被标注为YES，也就是需要进行Recover。其他没问题的文件状态为NO，也就是不需要进行recover。上面的案例证明了这点。

在immediate参数情况下，所有文件状态都是YES，表示无论好坏，都要进行recover。

下面尝试online动作。

SYS@seiang11g>alter tablespace wjqtest online;

alter tablespace wjqtest online

*

ERROR at line 1:

ORA-01113: file 8 needs media recovery

ORA-01110: data file 8: '/u01/app/oracle/oradata/OraDB11g/wjqtest01.dbf'

SYS@seiang11g>

SYS@seiang11g>recover datafile 8;

Media recovery complete.

依然不行，需要将所有的文件都recover一遍，索性直接recover表空间

SYS@seiang11g>alter tablespace wjqtest online;

alter tablespace wjqtest online

*

ERROR at line 1:

ORA-01113: file 9 needs media recovery

ORA-01110: data file 9: '/u01/app/oracle/oradata/OraDB11g/wjqtest02.dbf'

SYS@seiang11g>recover tablespace wjqtest;

Media recovery complete.

[oracle@seiang11g trace]$ tail -f alert_seiang11g.log

Tue Sep 26 13:42:44 2017

Checker run found 1 new persistent data failures

Tue Sep 26 13:43:04 2017

ALTER DATABASE RECOVER datafile 8

Media Recovery Start

Serial Media Recovery started

Recovery of Online Redo Log: Thread 1 Group 1 Seq 52 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/OraDB11g/redo01.log

Media Recovery Complete (seiang11g)

Completed: ALTER DATABASE RECOVER datafile 8

alter tablespace wjqtest online

ORA-1113 signalled during: alter tablespace wjqtest online...

Tue Sep 26 13:44:43 2017

ALTER DATABASE RECOVER tablespace wjqtest

Media Recovery Start

Serial Media Recovery started

Recovery of Online Redo Log: Thread 1 Group 1 Seq 52 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/OraDB11g/redo01.log

Media Recovery Complete (seiang11g)

Completed: ALTER DATABASE RECOVER tablespace wjqtest

总结

我们来总结一下Offline三种参数的情况。
（1）offline normal：是最常用的参数，也最不容易出问题。Offline Normal的时候，Oracle会在表空间内部进行Check Point动作，保证表空间内部各个文件头上面的SCN一致，也就是数据一致。如果存在数据文件不能前推SCN，如已经Offline，的情况，offline normal失效报错。

（2）offline temporary：比Normal要求略松的一种关闭模式。Temporary模式下，Oracle依然会去"尝试"统一表空间内部文件头的SCN号。如果数据文件可以统一，就进行Check Point动作，如果文件不能统一，操作也不会报错，只是将其状态标记为不一致。Temporary模式下Offline的表空间Online的时候，那些"有问题"的不一致文件，是需要进行media recovey的。没有问题，打入check point的数据文件，就不需要进行恢复动作。

（3）offline immediate：最松的一种offline模式。Immediate模式下，Oracle不会进行check point动作，无论有无问题的Datafile，都会被设置为需要Recover过程。在重新online的时候，表空间就需要进行重新的全表空media recover。