现场测试工程师在半夜电话反馈：在新建的小测试库做XTTS流程验证，遇到错误： ```shell ERROR at line 1: ORA-20001: TABLESPACE(S) IS READONLY OR, OFFLINE JUST CONVERT, COPY ORA-06512: at lin
xtts的配置文件，有很多注释不想直接去掉的情况下，想清楚的看到目前设置了哪些参数，可以用grep过滤查看： `grep -vE '^#|^$' xtt.properties` 效果如下： ```shell [oracle@db11gcas xtt]$ grep -vE '^#|^$' xtt.pr
重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。 换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。 而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的
通常选择XTTS做迁移的数据库都不会太小的，至少都是几T、几十T这样的规模，这种级别的数据量原有空间不够用，所以在迁移过程临时用作存放迁移数据库备份文件的空间也是需要提前考虑规划的问题。 最近就有客户有这样场景，数据库的数据量已经达到了60T+，也是优先选择XTTS的方案做U2L迁移测试。 至于这个
项目测试组又反馈一个问题，XTTS执行全量备份速度慢，影响测试进度。 实际算了下，平均速度才150MB/s.. 这个速度在客户生产环境的确是不够看，首先询问是否开了并行，开了多少？ 回复是说有开32个并行，在xtt.properties配置文件中指定的。 另外也注意在RMAN中show all的配置
在上篇《[XTTS系列之四：迷迷糊糊的并行度](https://www.cnblogs.com/jyzhao/p/17525723.html)》验证之后，就让测试组在RMAN配置中设置好正确的并行。然后重新将备份任务执行，平均速度直接由之前的150MB/s提升为1200MB/s。优化效果非常明显，速
如果是用户主生产环境，通常不会有用户会开启这个功能。 但如果是在ADG备库端，就会有不少客户选择开启这个功能，这可以有效补充误操作应急处置方法。 今天给某客户做技术支持的时候，在现场遇到一个蛮有意思的问题： XTTS测试场景，库非常大，数据文件很多，远超db_files的默认值。 在表空间元数据导入
