测试rman transport tablespace命令时遇着的小问题~~

windows平台下的oracle 10.2.0.1测试transport tablespace创建可传输表空间

E:oracleScriptbackup>set oracle_sid=jssweb

E:oracleScriptbackup>rman target /

连接到目标数据库: JSSWEB (DBID=3402005373)

RMAN> transport tablespace jssweb

2> tablespace destination 'd:backuptd'

3> auxiliary destination 'd:backupad'

4> ;

看，不需要太复杂，就是这么简单。

使用目标数据库控制文件替代恢复目录

RMAN-05026: 警告: 假定以下表空间集适用于指定的时间点

表空间列表要求具有 UNDO 段

表空间 SYSTEM

表空间 UNDOTBS1

使用 SID='gEDa' 创建自动实例

供自动实例使用的初始化参数:

db_name=JSSWEB

compatible=10.2.0.1.0

db_block_size=8192

db_files=200

db_unique_name=tspitr_JSSWEB_gEDa

large_pool_size=1M

shared_pool_size=110M

#No auxiliary parameter file used

db_create_file_dest=d:backupad

control_files=d:backupad/cntrl_tspitr_JSSWEB_gEDa.f

启动自动实例 JSSWEB

...

...

内存脚本的内容:

{

# set the until clause

set until scn 1672677;

# restore the controlfile

restore clone controlfile;

# mount the controlfile

sql clone 'alter database mount clone database';

# archive current online log for tspitr to a resent until time

sql 'alter system archive log current';

# avoid unnecessary autobackups for structural changes during TSPITR

sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';

}

正在执行内存脚本

正在执行命令: SET until clause

..

...

sql 语句: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;

释放的通道: ORA_AUX_DISK_1

内存脚本的内容:

{

# generated tablespace point-in-time recovery script

# set the until clause

set until scn 1672677;

# set an omf destination filename for restore

set newname for clone datafile 1 to new;

...

...

# make the controlfile point at the restored datafiles, then recover them

recover clone database tablespace "JSSWEB", "SYSTEM", "UNDOTBS1", "SYSAUX" delete archivelog;

alter clone database open resetlogs;

# PLUG HERE the creation of a temporary tablespace if export fails due to lack

# of temporary space.

# For example in Unix these two lines would do that:

#sql clone "create tablespace aux_tspitr_tmp

# datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K";

}

正在执行内存脚本

正在执行命令: SET until clause

正在执行命令: SET NEWNAME

...

...

介质恢复完成, 用时: 00:00:10

完成 recover 于 19-11月-07

数据库已打开

内存脚本的内容:

{

#mark read only the tablespace that will be exported

sql clone "alter tablespace JSSWEB read only";

# create directory for datapump export

sql clone "create or replace directory STREAMS_DIROBJ_DPDIR as ''

d:backuptd''";

# export the tablespaces in the recovery set

host 'expdp userid="/@(DESCRIPTION=(ADDRESS=(PROTOCOL=beq)(PROGRAM=oracle)(ARGV0=oraclegEDa)(ARGS=^

'(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))^')(ENVS=^'ORACLE_SID=gEDa^'))(CONNECT_DATA=(SID=g

EDa))) as sysdba" transport_tablespaces=

JSSWEB dumpfile=

dmpfile.dmp directory=

STREAMS_DIROBJ_DPDIR logfile=

explog.log';

}

正在执行内存脚本

sql 语句: alter tablespace JSSWEB read only

...

...

主机命令完成

/*

The following command may be used to import the tablespaces.

Substitute values for and .

impdp directory= dumpfile= 'dmpfile.dmp' transport_datafiles= d:backuptdJSS

WEB.DBF

*/

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

-- Start of sample PL/SQL script for importing the tablespaces

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

-- creating directory objects

CREATE DIRECTORY STREAMS$DIROBJ$1 AS 'd:backuptd';

...

...

DROP DIRECTORY STREAMS$DIROBJ$DPDIR;

删除自动实例

关闭自动实例

Oracle 实例已关闭

自动实例已删除

删除自动实例

自动实例已删除

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: tranport tablespace 命令 (在 11/19/2007 15:23:45 上) 失败

ORA-27056: 无法删除文件

OSD-04024: 无法删除文件。

O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。

莫明其妙报了这个错误，网上多方搜索也没能找着原因，后来在metalink中找到一篇文章，介绍说O/S-Error: (OS 32)通常跟windows平台有关，尝试换用linux平台执行...........一切正常！幸好从linux平台的执行日志中能够看出，报错是在删除辅助实例文件时，此时传输集已经生成了，不会影响我们后续操作。那我们就手工删除这些文件好了，基本上就是auxiliary destination参数指定路径下的文件，干脆直接连这个目录也删掉。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7607759/viewspace-22296/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7607759/viewspace-22296/