现场测试工程师在半夜电话反馈：在新建的小测试库做XTTS流程验证，遇到错误：ERROR at line 1: ORA-20001: TABLESPACE(S) IS READONLY OR, OFFLINE JUST CONVERT, COPY ORA-06512: at line 284 先了解具体阶段： 具体是最后表空间read only后,执行最后一次增量备份就会报这个...(more)

在上篇《XTTS系列之四：迷迷糊糊的并行度》验证之后，就让测试组在RMAN配置中设置好正确的并行。然后重新将备份任务执行，平均速度直接由之前的150MB/s提升为1200MB/s。优化效果非常明显，速度直接提升了8倍。但是由于用户的数据库存在大文件表空间，当执行到大文件表空间时，速度又...(more)

项目测试组又反馈一个问题，XTTS执行全量备份速度慢，影响测试进度。 实际算了下，平均速度才150MB/s.. 这个速度在客户生产环境的确是不够看，首先询问是否开了并行，开了多少？回复是说有开32个并行，在xtt.properties配置文件中指定的。 另外也注意在RMAN中show all的配置是默认...(more)

通常选择XTTS做迁移的数据库都不会太小的，至少都是几T、几十T这样的规模，这种级别的数据量原有空间不够用，所以在迁移过程临时用作存放迁移数据库备份文件的空间也是需要提前考虑规划的问题。最近就有客户有这样场景，数据库的数据量已经达到了60T+，也是优先选择XTTS的方案做U2...(more)

本系列的定位是对XTTS及相关技术进行深入的学习研究。作为本系列的开篇，本着实用性的原则，我先把一次实际生产环境U2L的迁移实战实施方案进行提炼简化，旨在能清楚说明该如何使用XTTS这种解决方案来进行U2L迁移，先达到可以跟着做下来的初级目标，如果有兴趣再去深入研究相关细节...(more)

重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。而在这类XTTS的迁移项目中,我认为bct的技术是至关重...(more)