如果是用户主生产环境，通常不会有用户会开启这个功能。 但如果是在ADG备库端，就会有不少客户选择开启这个功能，这可以有效补充误操作应急处置方法。今天给某客户做技术支持的时候，在现场遇到一个蛮有意思的问题： XTTS测试场景，库非常大，数据文件很多，远超db_files的默认值。 ...(more)

1.背景概述客户的监控告警频繁提示系统xx数据库死锁增长个数高于当前阈值_当前值1.00。 下面是详细的故障分析诊断过程，以及详细的解决方案描述。2.故障分析2.1 故障现象 登录到系统，从数据库到alert日志可以发现的确存在很多ORA-60的信息，截取部分如下：2020-04-23T19:32:00...(more)

环境：RHEL 7 + Oracle 19.5 RAC1.故障现象最近遇到客户的一套19c测试环境，在一次主机重启后发现集群无法启动，使用crsctl stat res -t -init查看集群启动阶段时发现直接报错如下信息：[grid@xxdb01-vip ~]$ crsctl stat res -t -init Oracle Clusterware infrastructure error...(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)