ASM下传送表空间的问题

lujiaguai · 发表于 2016-7-20 12:53:26

唐SIR：
目的地数据库在ASM里，传送表空间的时候，“胳膊”无法复制到ASM内，怎么办？

botang · 发表于 2016-7-20 17:39:17

上课提到，先在文件系统上。以后rman进去。

lujiaguai · 发表于 2016-7-28 15:44:57

我是如下做的，过程对不对？
1，修改闪回区路径到+DATA
2 , RMAN下：backup as copy tablespace **
3 , alter tablespace ** offline
4 , alter database rename file ** to  **
5 , alter tablespace ** online
6,  alter tablespace ** read write
7,  修改闪回区路径回到 +FRA

这样做结果是正确的，但是第1步有一个修改闪回区路径的问题
真实环境如果这样做，会导致第2到6步这个过程中，数据库的归档日志等闪回区信息写入到+data中
再修改回+fra以后，fra上会出现归档日志断点，甚至也可能影响闪回，这么理解对不对？

如果确实会有这样的问题，那么生产环境怎么做是正确的，有没有更好的办法？

admin · 发表于 2016-7-28 16:39:18

迁移一般在mount时做。即使open做，日志也没有断点。如果觉得+data不统一，可以再用backup as copy archivelog sequence xxx delete input来解决。另外建议使用等价的set newname配上switch database to copy命令上更简洁些。手机上回复的，不知说清没。

lujiaguai · 发表于 2016-7-28 17:34:09

不是迁移，只是传送表空间，为了把“胳膊”放进ASM，目标数据库mount的代价太大了。
为何不会有日志断点？库在open下，原来的归档日志去了FRA。
那么在修改闪回区为data期间，如果产生归档日志，此时就会去data/orcl/archivelog/2016_07_28。ASM目录会有归档日志，比如sequence 4,5,6
但同时FRA/ORCL/achivelog/2016_07_28也有内容，比如sequence1,2,3
这个时候切回FRA以后，fra上的归档就变成sequence 1，2，3，7，8，9 就断了。

如果用delete input来处理，等于就是备份了一下，但备份之后，依然会有一个set newname 的过程，然后才切回闪回区到fra。
这个过程哪怕时间很短，也有可能再次有归档日志产生。

前面做文件系统到ASM迁移的时候，没有这样的问题，因为库是停掉做的。
但现在为了传送表空间，放进ASM，做了2次，感觉只要闪回区放在data，保持一段时间，难免会有归档日志进来。

我的理解是不是有错？

lujiaguai · 发表于 2016-7-29 09:18:55

补充一下，我试过，用backup as copy tablespace * format '+data'，是可以把表空间的镜像拷贝放进 +DATA/ORCL/DATAFILE的
这样的话，可以不需要修改闪回区的默认路径。

botang · 发表于 2016-7-29 09:52:34

本帖最后由 botang 于 2016-7-29 09:55 编辑

lujiaguai 发表于 2016-7-28 17:34
不是迁移，只是传送表空间，为了把“胳膊”放进ASM，目标数据库mount的代价太大了。
为何不会有日志断点？ ...

为何不会有日志断点？库在open下，原来的归档日志去了FRA。
那么在修改闪回区为data期间，如果产生归档日志，此时就会去data/orcl/archivelog/2016_07_28。ASM目录会有归档日志，比如sequence 4,5,6
但同时FRA/ORCL/achivelog/2016_07_28也有内容，比如sequence1,2,3
这个时候切回FRA以后，fra上的归档就变成sequence 1，2，3，7，8，9 就断了。

复制代码

这个没有丢失，控制文件会知道456去了+DATA

当然可以用“format"语法了，当时是ASM迁移，干脆改db_recovery_file_dest。如果只拷贝一两个文件，建议用"backup as copy ... format ..."

如果用delete input来处理，等于就是备份了一下，但备份之后，依然会有一个set newname 的过程，然后才切回闪回区到fra。
这个过程哪怕时间很短，也有可能再次有归档日志产生。

复制代码

改正确 db_recovery_file_dest后，再慢慢转移路径不对的归档日志。

在巴厘岛图蓝奔自由号沉船潜水后, 给你回的喔-：）

lujiaguai · 发表于 2016-7-29 10:40:26

感谢唐SIR，看得出心情不错

我这两天挣扎在数据仓库的实验及笔记整理上，过程漫长而痛苦

lujiaguai · 发表于 2016-8-1 15:30:38

重现了这个过程
1，backup as copy tablespace tbs01 format '+data'

2，switch diatafile 7 to copy;
结果提示：datafile 7 switched to datafile copy "+DATA/orcl/datafile/tbs02.268.918745707"

只要这2条命令，就可以把文件系统下的tbs01表空间转移到asm内。
执行后，v#datafile已经是正确的
然后再上线，读写，在trace空间文件出来看来一下，也是正确识别到ASM内的文件名的。

这是不是代表 set newname的动作可以不需要做？？