一套12C的数据库2节点RAC集群，节点2被down了，查看alertlog，报错如下： 2021-06-16T01:26:16.516936+08:00 Thread 2 advanced to log sequence 8611 (LGWR switch) Current log# 4 seq# 8611 mem# 0: +DATA/CB2QDB/ONLINELOG/group_4.305.992195801 Current log# 4 seq# 8611 mem# 1: +DATA/CB2QDB/ONLIN…

(接上文) https://liking.site/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ https://liking.site/2021/06/10/大量事务并发回滚彻底堵塞数据库2/ https://liking.site/2021/06/11/大量事务并发回滚彻底堵塞数据库3/ 根据oratop的top等待事件排名，包括累积排名和实时排名，这个"wait for a undo record"已经成为了目标等待事件，是否它阻塞了正常的前滚事务呢？ 根据MOS的搜索结果，当…

(接上文) https://liking.site/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ https://liking.site/2021/06/10/大量事务并发回滚彻底堵塞数据库2/ 在后续的故障定位时，有人根据如下日志，认为是归档空间满，导致了数据库挂死。 实际不然，这个FAL报错，只是到DG的归档由于其他原因导致了报错，日志也写在了主库alertlog文件，并非是主库归档失败，对主库并无其他影响，仅仅是写了一个日志而已。事后我的详细排查也印证了这一点，当天中午12:00和18:00分别有…

(接上文) https://liking.site/2021/06/09/大量事务并发回滚彻底堵塞数据库1/ 在数次停库、起库的过程当中，遭遇过部分实例起在其他节点的情况，如下。 srvctl start instance -d jkdb -i jkdb1 发现实例1起在了2号节点 srvctl stop instance -d jkdb -i jkdb1 srvctl start instance -d jkdb -i jkdb3 实例3起在了3号节点 srvctl start instance -d jkdb …

这是一个历时5个多小时的故障处理过程，值得认真记录、反思。 事后详查发现，数据库16:00之前就出现大量锁表情况，16:07运维支撑群有用户反映系统慢，直到反馈系统彻底没法用了。下图显示，实际14:00以后就开始出现了较多的锁表情况。 只是，14:00-16:00期间由于只是后台执行任务的锁表，并未明显影响到客户感知，相关的一线业务还可正常进行。 但是当这些执行失败的定时任务一个接着一个，反复重复执行，从而导致大量锁死时，会怎样呢？这会把整个库搞瘫痪。 相关的等待事件涉及到了大量的row cache lock、gc…

昨天在查看一个adg备库时，偶然发现了一个oracle的大坑，就是审计日志文件(*.aud)过多的问题，在adump目录下竟然有接近500万个aud文件，经查阅资料得知，所有以sysdba用户访问数据库的情况，都会记录一个aud文件在adump目录下，即使audit_trail设置为none，也会记录aud文件。 这样的话，当某些情况频繁以sysdba登录数据库的话，经年累月的定时任务，会导致这个路径下积压大量的aud文件，可想而知，严重情况会导致inode占满，导致OS故障，后果不堪设想。 我们知道默认情况数据库…

一个SQL查询很慢，查看执行计划出现了较多的“BITMAP CONVERSION FROM ROWIDS”，如下所示。 SQL_ID 1x9rd10ykjvjd, child number 0 ------------------------------------- select t.*, t.LIMIT_TIME - SYSDATE AS nowNumber, t.LIMIT_TIME - SYSDATE - i.manual_task_limit / 24 AS limitNumber from USER_W…

19.9 ADG环境，查看Flash Recovery Area Usage发现FLASHBACK LOG占用了90%多的FRA空间，而ARCHIVED LOG仅占用不到10%，这还了得，这是一个繁忙的生产环境，一般是不需要长时间的Flash Back的，得想办法清理一下，以免影响归档。【注：其实是不会影响归档的，具体的实践观察见后】 如下是清理前的占用情况: FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID …

一体机的19c新数据库，由于项目人员修改undo，导致出现有的pdb无法open的情况： 2021-01-26T12:03:43.957991+08:00 PDBAPP(3):Endian type of dictionary set to little PDBAPP(3):Undo initialization recovery: err:0 start: 2574325 end: 2574327 diff: 2 ms (0.0 seconds) 2021-01-26T12:03:44.456447+08:00 …

■2021-01-14 15:07 存储开始出现问题，主数据库2个节点(node1、node2)均报共享存储'I/O error' -------node1 alert 2021-01-14T15:07:24.122930+08:00 WARNING: Write Failed. group:1 disk:3 AU:81 offset:2022912 size:4096 path:/dev/asmdisks/su001_lun04 incarnation:0xf0f0720e asynchronous result…