本案例来自两年前深圳某客户两节点rac的一次生产故障,现象是大面积的gc buffer busy acquire导致业务瘫痪。
首先查看1节点awr头部信息和load profile 继续阅读
本案例来自两年前深圳某客户两节点rac的一次生产故障,现象是大面积的gc buffer busy acquire导致业务瘫痪。
首先查看1节点awr头部信息和load profile 继续阅读
本案例是福建某客户一套待上线系统,操作系统版本为AIX 7.2 ,集群版本为12.2。几天前2节点GI突然重启,由于是比较重要的待上线系统,所以需要仔细一下分析原因。 继续阅读
此次案例来自西安某客户的一次sql优化,对于优化本身并不复杂,但是发现了一个比较有趣的问题,就是索引范围扫描以及回表都有使用多块读的方式。下面来看看具体案例。 继续阅读
某省电力系统的一个4节点rac,2节点在早上的时候crash。 继续阅读
某银行的某系统rac数据库版本19.6,二节点的mmon slave进程一直在报ORA-01000,导致awr、ash等等很多MMON的功能收到了影响。 继续阅读
某银行ods系统的一体机(数据库版本为19.8)上,由于某个存储节点掉了4块盘,磁盘处于offline状态,在超过了”_asm_disk_repair_time”时间内没有online,被磁盘组自动drop force,之后在drop disk rebalance未完成的情况下,将4块盘重新加入了磁盘组,由于担心rebalance影响ods跑批业务,所以在跑批阶段中断rebalance操作,在空闲时重新发起rebalance,反复启停rebalance很多次,但是在某一次中断rebalance之后,发现rebalance就再也无法启动了。 继续阅读
在18年的一次恢复中,遇到了一个非常棘手的case,客户环境一套rac cdb中原本存在10个pdb在同一个ASM磁盘组中,误删除了其中6个pdb,并且使用了including datafiles子句。 继续阅读
在做异常恢复的时候,有时候会需要推进scn,网上已经有了非常多的相关资料,常见的scn推进方法比如12c之前的oradebug ,12.2之后的event 21307096等等,那么如果要恢复12.1的数据库该如何推进scn呢? 继续阅读
近期大量的客户数据库软件被注入恶意代码,导致数据库无法启动,报错ORA-00600: internal error code, arguments: [16703], [1403], [20],大致的原因和预防措施可参考下面文章:http://www.eygle.com/archives/2018/07/recover_ora-600_16703.html 继续阅读
今天某交管客户出现登录异常,应用反馈无法登录数据库。数据库版本为11.2.0.4,patch版本没注意,先暂时不关注。使用客户提供的异常用户测试登录发现确实会hang住。 继续阅读