运维日记|那些年你可能会踩的坑—xtts篇

客户：迁移做的咋样啦？

工程师：马上好了。

客户：好了没啊？

工程师：不好意思，失败了？！

大家在做数据库迁移的时候难免会碰到这各种问题，我们不保证每一次的迁移都能顺利完成，只能尽量少踩坑，下面小编给大家介绍几个oracle xtts迁移防坑知识点。

在讲防坑技巧之前首先罗列部分在做xtts迁移之前的前置条件，在做迁移之前一定要仔细检查条件是否都满足，因为任何一步没检查到位很可能会对你的迁移工作造成不必要的麻烦！

1.源端不能是windows

2.源库的版本必须大于10.2

3.源库的compatible参数不能大于目标端

4.源库和目标库字符集需要保持一致

5.目标端db_files参数必须大于源端

6.源库和生产必须处于归档模式

7.源库的rman配置中DEVICE TYPE DISK不能设置为 COMPRESSED

8.要迁移的表空间数据文件必须都是online的或者不包括 offline数据文件

9.排除系统表空间，避免冲突并检查业务表空间是否自包含

10.源库和目标库db block size必须一致

防坑点一

编辑xtt.properties文件，表空间书写格式问题，特别是数据库表空间数量非常多的时候，一定要注意，表空间名字都要书写在同一行，不得自行换行！也不可以有任何空格！

格式一：

格式二：

格式三：

各位看官觉得哪种格式是正确的？

无论写成什么样子，他只认第一行的表空间名字，所以在编辑的时候一定要写成一行，也不要有任何空格。如果书写错了在做增量备份恢复的时候是不会报任何错误的，因为对于相关表空间来说，他确实增量成功了，但是在最后元数据导入的时候就会报数据文件不一致，所以最简单的方法是去检查xttsnewdatafiles.txt里面的表空间数量是否与生产查询出来的一致。

防坑点二

xtts发明的目的就是为了加快迁移速度，这里很重要的一个点就是打开块跟踪。打开块跟踪可以大大缩短执行增量备份时间。alter database enable block change tracking using file '/rman/trace.log';但是迁移结束后记得要关闭块跟踪。alter database disable block change tracking;

防坑点三

生产是裸设备，如果rman copy时候，数据文件加了“.dbf”那么，在增量恢复的时候需要编辑xttnewdatafiles.txt，否则恢复的时候会提示找不到数据文件。文件系统忽略此步骤，解决方法如下：

防坑点四

nfs不要挂一级目录。

like this：

正确挂载方式：

原因是AIX上如果断开的NFS 挂载点会导致 Oracle instance hang 住。

防坑点五

最后一次增量之前确认生产有无新增数据文件，如果没有跟甲方dba充分沟通，在迁移过程中甲方DBA可能会在不告知你的情况下增加数据文件，所以最后一次增量之前，一定要确认是否有新增数据文件，如果有新增文件，那么就要手工convert新增数据文件。

防坑点六

延迟段创建参数：

ALTER SYSTEM SET deferred_segment_creation=FALSE SCOPE=SPFILE SID='*';

我们在优化数据库参数时可能会关闭延迟段创建，因为参数为true会导致10g客户端exp导出11g 文件无法导出空表等现象。

但是关闭延迟段创建可能会导致导入元数据失败，特别是数据库含有大量压缩表的情况下，故在迁移过程中我们不建议关闭延迟段创建。

防坑点七

并行数

前面说过打开块跟踪可以提升增量备份速度，加上并行那是如虎添翼。但是这里要注意一点，增量备份的时候生产还在使用中，如果生产I/O性能差的话会直接影响业务。故还得结合实际硬件资源合理调整并行数量。

参考文档：

? Database Will Not Mount: ORA-15025, ORA-27041, 'Permission denied', ORA-15081 (Doc ID 1378747.1)

? How to check and fix file permissions on Grid Infrastructure environment (Doc ID 1931142.1)

以上是小编在进行跨平台迁移过程中总结出的经验，希望对大家有所帮助。不知道大家在做xtts时有没有踩过坑呢？欢迎留言交流。