在第一篇中分享了关于备库报警邮件的剖析，发明很多问题都是一环扣一环.
起初是通过监控主库中的v$dataguard_status发明备库中可能存在一些问题，成果逐渐剖析，发明是由备库的crontab触发了备库的定时read-only和online状况，（即只读和运用日志，10gR2的环境），而这些症结信息都是从数据库的alert日志中发明的，但是问题还没有完，才刚刚开端，由于发明备库中居然有ORA-1652: unable to extend temp segment by 128 in tablespace的毛病，这在备库中着实是很奇异的，备库在read-only状况时会有甚么样的sql语句对temp消费如此之大？通过比较主备库发明，主库仅仅为32G，而备库却有近98G大小，而且从历史记载来看，这个毛病一致存在，也算是一个历史遗留问题吧。
起初是通过监控主库中的v$da
阅读背景：
备库报警邮件的分析案例（二)
来源：互联网
分享到：
