ITPub博客

本文主要解决OGG复制进程报ORA-01438错误

本文主要测试logminer进行数据挖掘的三种方法，每种方法适用的环境不一样，故针对每一种方法进行实验。第一种方法为：设置数据库参数utl_file_dir，使用文本文件，但需要重启数据库，才可以真正进行数据挖掘。第二种方法为不需要设置utl_file_dir参数，进行在线日志挖掘。第三种方法为：怕影响生产环境，将相关日志拷贝到测试环境，进行日志挖掘。

本文主要针对OGG抽取进程延时，进行参数调整，问题追踪，使用logminer对相关事务进行分析等操作，最终定位到问题原因。

使用expdp导出数据，使用query进行数据过滤，报ORA-31693 ORA-29913 ORA-01861错误，经仔细查看，发现过滤条件的格式同表的不一致，导致的报错

本文主要解决goldengate目标端比源端多一个字段，且不为空时，如何利用goldengate的sqlexec功能，将序列的值，写到相关字段上。

本文主要解决awr占用sysaux表空间太大，如何进行空间回收，释放sysaux表空间

使用expdp导出时，报ORA-31626 ORA-31633 ORA-00955 ，经查看，是由于以前有人使用相同的JOB名称，且没有正常终止JOB引起的

在RAC中新建ASM磁盘组，发现两个节点的磁盘组信息不一致，创建磁盘组没有任何错误，查看ASM实例日志发现ERROR: failed to update diskgroup resource ora.OCR_NEW.dg 错误，

本文主要是通过查看OGG复制进程延迟40小时执行的SQl，根据SQLID、SQL执行计划、执行时间、表的数据量、占用的空间等来判断出执行计划异常，通过查询原因，发现表的数据为0，但逻辑读太高，导致SQl执行太慢，达2秒一条，通过降级表的水位线，SQL性能提升达几千倍

使用expdp导出数据，报ORA-31693、ORA-02354、ORA-01466错误，经检查，有可能是对表做了相关DDL操作，引起的。

使用rman删除归档日志，发现报ORA-15028，手动进行删除，报相同的错误，故进行详细原因查找

本文主要是在将索引重新新建到其它表空间，发现分区表的索引重建时报ORA-14086错误

某核心业务系统临时表空间100%，经详查，发现是由于业务系统使用dbms_lob存储过程且是长连接，最终导致临时表空间达到100%

本文主要是解决Undo表空间使用率100%，但数据库的alert没有任何报UNDO不足的情况，故针对此问题进行详细分析，发现是由于统计信息过期导致的。

DBA关闭所有数据库实例，但未关闭OGG，重启OGG所有进程，抽取进程，MGR进程、大部分复制进程都恢复正常，但还有几个进程的Time Since Chkpt 时间一直处于增加，等待一个小时，重启MGR及相关进程，进行观察；等待15小时，发现Time Since Chkpt还是处于增加状态，OGG没有应用任何数据，故认定由于数据库重启，导致OGG的REPLICAT进程异常，处于假死状态。

业务系统需要更换SSD存储设备，需要将所有的磁盘替换掉。更换数据磁盘、OCR 、表决磁盘后，在节点1重启集群进行验证，发现数据库实例的资源状态为OFFLINE，使用集群命令servctl也不能启动，报ORA-15017: diskgroup "OCR" cannot be mounted

本文至于解决ORA-1652告警的一种情况，即在巡检时发现ORA-1652，但当前临时表空间使用率为100%。或告警发生，来不及查询临时表空间正在执行的SQL，问题现象已经消失，如何通过ASH历史信息进行追溯，来找到真正耗尽临时表空间的SQL

使用impdp导入数据，报ORA-31693 ORA-29913 ORA-00001 ORA-06512 ORA-04088

本文主要根据Transaction recovery: lock conflict caught and ignored 告警信息，查看对应的事务信息及对象

本文主要是解决在不停止数据库任何业务的情况下，无检修窗口，如何进行OGG的抽取进程合并，并保证数据的不丢失；并验证抽取进程合并后的性能，经验证，发现OGG的抽取进程性能提升了许多倍。