第七十一期五一，休息？

好不容易，熬过万恶的6天班来到了五一假期，想着好好休息，顺便把绝地幸存者给通关（优化稀烂，更新后好了一点）
结果X8那套库连着两条出问题（虽然覆盖这台维护的新合同还没签下来，但是影响生产了就要处理吧），搞得假期充满了烦躁。

1 备份

先说后面发生的那个问题，是NBU存储满了，定期的归档日志备份没有执行，也就没有删除已备份的归档日志，造成了FRA满了，归档卡住引起数据库不可用。好的一点是8点不到发生而且是五一当天，影响不是太大，连到服务器执行：

rman target /
RMAN> delete archivelog all completed before 'sysdate-0.5';

归档日志删除过程中数据库就恢复正常了，这个就没啥好分析的了。

2 两个DDL

这是五一假期第一天出现的问题（游戏打的正嗨时！），当时是数据库出现性能问题了，大概发生时间是14:00-14:30，通知到我这登陆到服务器已经14:50之后了，正在查看问题发现故障时段出现了大量的library cache lock、cursor: pin S wait on X和row cache lock：
在这里插入图片描述
同时通过问题时段AWR报表中Top Blocking Sessions段落进行排查：

发现顶级锁会话是一条create table as select的DDL语句。

这条语句在EM的SQL记录中也在问题时段同时执行了两条，只不过另一条是从2点开始的，接近2点半就失败了。
根据前一张图，排查到3点的时候数据库再次出现性能问题，和2点到2点半的情况一致，是两条相同的create table as select DDL语句在同时执行引起的，随即在3点08分的样子干掉实例1运行的，session_id为4131，session_serial#为48217的会话，数据库随即恢复正常。
后续排查发现出现问题的语句执行了4小时以上，3点新发起的语句后面也执行了超过1小时没有完成，而根据业务方反馈，这条语句已执行1年以上，第一次出现问题。

3 问题处理

业务场景
业务需求每一个小时会对全量的基站数据进行刷新，出现问题的语句为其中一步，前面还CTAS了几张临时表用于数据刷新。由于该任务是通过SQL脚本与crontab实现，所以没有异常处置，当任务异常时，后面的任务仍然会继续执行，从而导致两条相同CTAS DDL语句冲突引起大面积数据库等待，出现性能问题。
只不过这里发现第一个异常任务执行开始后，后面前2小时几乎没啥影响，分析应该为后续语句快速失败了，第三个小时和第四个小时就出现了问题。业务方在出现问题后就暂停了这个任务，由非即时数据支撑生产。
语句排查
首先先看看这条语句的情况：

-- sql_id: 3na6qqz08x159
create table temp_ponptp_sp as
select 
	e.city_id,e.county_name,
	b.g1000_flag,
	e.zh_label cell_name,
	d.zh_label cover_area,
	c.related_olt olt_name,
	c.olt_neport_pon_m olt_port,
	d.all_port_num,d.zyfg_sbkydks
from
	rms_trans_neport a,
	temp_ponptp_cardtype b, --临时表
	rms_splitter c,
	rms_area_cell d,
	rms_wcell e
where
	a.related_ne=b.olt_id
	and a.related_card=b.card_int
	and a.card_type=b.card_type
	and a.stateflag=0
	and b.olt_name=c.related_olt
	and a.old_name=c.olt_neport_pon_m
	and c.city_id=b.city_id
	and c.stateflag=0
	and c.cover_area=d.zh_label
	and c.city_id=d.city_id
	and d.stateflag=0
	and e.zh_label=d.zyfg_ssxq
	and e.city_id=d.city_id
	and e.stateflag=0

结合SQL Monitor：
在这里插入图片描述

排查出该语句在RMS_WCELL表的索引RMS_WCELL_III索引上花费最多。随即排查该索引：
在这里插入图片描述
回头看看语句，涉及RMS_WCELL列的筛选顺序为zh_label、city_id、stateflag，而复合索引第一列为CITY_ID，初步排查为zh_label列并未走索引。随即反馈业务方，开发直接在zh_label列建立了索引，再次执行，2分半即完成，对应的SQL Monitor如下：
在这里插入图片描述
从执行计划各项细节来看，各表的活动花费比例正常，同时IO执行也正常。
完成SQL优化后，业务方也对任务进行了调整，添加了异常检测与告警，避免任务同时执行。

4 问题排查

其实library cache lock、cursor: pin S wait on X和row cache lock等待的分析相对比较简单，数据库在某些操作过程中会产生一系列锁，即是用于确保SQL执行顺序，也是数据一致性的保证。两条相同的CTAS，保持了相同的建表对象，同时执行过程中会维护一系列redo和undo信息（同时也会冲突），一系列复合的原因造成了性能问题。
而语句本身的性能问题，才是我客户最关心的问题，其实在我看来，相较于一年前上线时，数据库的数据量和压力都提升了不少。也许在原来的数据量情况下，原有的索引是可以跑出结果的，量变引发质变，现有的数据量却无法用原有索引高效执行。
回到三十二期说过的，数据库管理是一个持续的过程，其实这系列语句还有很多地方需要优化，还有不少全表扫，同时也希望能不走nest loop。
插播一下：阿三的英语啊，真是不得行，听不懂，而且处理问题的态度主要也是“卡BUG”（就是看个大概，然后去匹配BUG，懒得去就事论事），SR中的反馈分析基本都是我的分析过程，明天上班了，转回国内。