一个电话, 打破深夜的安静9月20日晚上10点刚完结外地一个要点项目为期2周的现场支撑, 从机场回家的路上, 一阵短促的铃声惊醒了租借车上昏昏欲睡的我, 多年的作业经历告诉我这么晚来电一定是出事了, 接起电话, 是KS。KS正在跟一个国内要害客户数据库国产化代替项目, 该项目中心事务体系由Oracle替换为金仓数据库KingbaseES, 项目前期运用适配和测验稳步推动, 依据方案, 整个体系将于9月21日晚上10点发动上线, 并于22日早上8点前悉数完结。以保证22日客户上班时间可以正常运用, 并能顺畅支撑事务高峰期。KS是合作运用开发项目团队正在为项目上线做最终的测验和验证的技术支撑人员, 他急迫地表明, 在项目团队在进行一次压力模仿测验时, 当数据库并发衔接超700, 体系中某一个事务流程的操作呈现显着卡顿, 再对该事务流程某项操作并发再添加时, 乃至呈现了数据库中止服务。上线在即, 忽然发现此类问题, 显着这是严重危险, 该项目是客户方案要点打造的国产化标杆项目, 本次待上线事务体系是客户一切部分职工每天必用的体系, 客户上上下下对该项目都十分重视, 项目准时上线是必需求完结的使命。经过快速巡检和体系检查, 并结合过往那个经历, KS开端判别这不是简略的体系问题, 因而找到了我。初见端倪,

却几尽溃散9月20日晚上11点挂了电话, 我立马赶到项目所在地, 客户、集成商和金仓三方的的项目负责人均在现场, 项目上线在即, 现场的状况让KS交流起来稍显语无伦次, 尽管如此, 我仍是清楚地感触到了集成商和客户的忧虑。问题的焦灼程度及现场巨大的压力告诉我, 我的判别和处理结果直接影响项目的顺畅交给和客户信息体系国产化的决心。我快速进入作业状况,

开端检查数据库的各项参数和相关日志文件、目标, 一起仔细剖析了下测验时的首要场景特色。首要捉住以下问题体现作为根因剖析的抓手：测验中, 事务查询十分慢。监控数据库, 从操作体系层观察到体系许多IO, CPUIO等候到达40%, IO巨细超越500MB/s。聚集该现象开端承认引发IO的进程：依据iotop承认发生大IO的进程都是kingbase进程, 问题指向数据库, 怀疑是部分SQL存在功用问题, 导致数据库IO过大。可是怎么精承认位数据库等候工作成了一个难题, 首要依照以往经历我想到经过查询sys_stat_activity字典承认, 可是sys_stat_activity只能查询当时时间点的数据, 后来我又选用一些其他办法企图搜集一些信息, 可是这些信息涣散、维度有限, 不足以支撑问题的快速定位, 一时间我堕入苍茫。时间立刻到了第二天, 一边是我不知道该怎么获取更多协助定位问题的数据信息, 另一边是客户差不多每过半小时过来问询一次处理发展, 后来爽性坐在咱们死后看着咱们处理问题。无形的压力接二连三, 不断加快的心跳似乎是在呼叫：谁来挽救我！！！山穷水尽, 要害问题方便的处理9月21日清晨1点数不清是第多少次安慰完客户, 我逼迫自己坚持镇定, 心想不能这么相持下去, 得快点找到打破口。所以我重整精力, 敏捷在大脑中回放、整理、发掘, 寻觅打破办法。忽然我想到前一阵产品内部训练说到的产品新才能, 可以经过东西KSH和KWR别离对数据库的会话前史和各种负载信息进行搜集, 并能快速生成陈述, 赶忙和相关搭档了解了下现场的版别状况和运用办法, 并承认现场版别现已具有相关才能。所以测验先运用KSH东西进行剖析, 皇天不负有心人, 总算在拂晓到来前, 迎来了“柳岸花明”：。1.经过KSH周期性搜集数据库的等候工作信息, 展示当时及曩昔一段时间的体系等候工作状况。
       2.检查KSH陈述, 我发现了“BufFileWrite”等候工作份额极高, 该等候工作表明进程正在等候将BUFFER内容写出到文件。“BufFileWrite”等候工作,

一般意味着进程在进行写临时文件操作。走到这儿现已很显着了, 可以承认是由于特定的SQL导致了体系的IO问题。接下来便是要找到这个“元凶巨恶”, 即承认问题SQL并对其进行优化。3.承认问题SQL：再次剖析KSH陈述, 找到等候“BufFileWrite”工作的SQL, 承认问题SQL如下：4.剖析优化SQL：可以看到SQL采纳hashjoin, 而hash操作引发的磁盘写, 是引发许多磁盘IO的原因。去掉hint后, 履行方案如下：可以看到, 去掉hint之后, SQL选用索引扫描了, 不光IO削减了许多, 速度也更快了。5.跟运用开发人员交流后, 承认是前期适配时, 由于测验环境数据量较少, 经过加hint（/*+set(enable_nestloopOFF)*/）, 可以获得更快的功用。
       而现在模仿出产环境测验时, 测验数据量成倍添加, hint不再适用。6.修正SQL：和谐运用开发人员修正SQL, 再次验证。9月21日清晨4点承认经过修正, 数据库不再有IO问题, 压测下, 之前呈现的卡死现象也未在呈现。
       “排雷”举动, 保证无忧上线完善的配套东西将我从问题的泥潭中挽救, 让问题定位和处理的速度得到了飞速提高, 客户总算露出了笑脸。为了保证后续上线的顺畅, 我和现场的搭档不敢放松, 忧虑还会有潜在的危险, 因而决议再进行一遍“排雷”举动。由于有东西的加持, 让咱们有决心能在几小时内完结之前或许几天都完结不了的工作。9月21日清晨5点说干就干, 运用开发商继续进行对事务进行压测, 咱们在事务运转过程中, 选用各类巡检手法, 合作运用KWR对数据库状况开端进行全面检测, 以排查或许还未被发现的“雷区”, 公然, 在继续的测验和监控过程中, 早上大约7点多, 我发现体系CPU运用率此刻十分高, 但IO正常, 显着这不太正常。这下心又说到了嗓子眼, 我赶忙打开新一轮的排查：1.先承认最耗CPU的进程：运用top指令, 检查最耗费CPU资源的进程, 承认这些进程都是kingbase进程。2.承认数据库等候工作：检查数据库的KWR陈述, 承认数据库的时间都花在CPU上, 没有显着的等候工作。从这些现象可以揣度进程状况是正常的, 特定SQL功用欠安, 耗费许多CPU资源。3.精承认位SQL：KWR东西也供给了TOPSQL功用, 可以依据CPU、IO、履行时间对SQL进行排序。关于当时问题, 经过检查“TopSQLByElaspsedTime”章节, 可以快速承认出最耗费CPU的SQL。。4.SQL功率剖析：完好的SQL有4次调用了以上的子查询, 并且子查询用到了窗口函数, 窗口函数是最耗费CPU资源的。这部分关于功用的耗费如下：5.可以看到, 这部分简略的查询需求768ms, 4次调用一共需求3秒。因而可以考虑经过提取公共表达式（CTE）, 整条SQL可以削减时间2秒左右。经过提取SQL的公共表达式, 将以上的子查询提取到CTE。9月21日上午10点修正完SQL后, 再次运转KWR, 承认以上SQL功用问题得以处理。接下来, 一切都比较顺畅, 但咱们依然不敢放松警觉, 时间重视数据库的运转状况, 好在有KWR和KSH能协助咱们快速进行相关数据的搜集, 协助咱们做到心中有数, 一起经过搜集的数据, 运用数据库自带的确诊东西——KDDM, 对陈述进行阶段性剖析, 进一步确诊功用问题, 为开发商又供给了一些优化主张,

比方下面的索引主张：1.KDDM针对如下SQL给出了索引主张。2.剖析履行方案：从初始的履行方案看,

履行功率十分低。3.KDDM优化主张：主张创立o.f_creattime索引4.依据KDDM的主张, 创立索引后的履行方案如下：5.可以看到, 依据KDDM主张, 创立索引后, SQL的履行功率提高了500倍。经过24小时的奋战, 客户的事务体系顺畅上线, 并经过运用高峰期, 跟着客户宣告项目上线成功, 项目组的房间里响起了火热的掌声, 掌声既是对整体项目成员的感谢,

也是对金仓产品和金仓人的必定。而我最要感谢的是咱们研制团队为咱们DBA供给的数据搜集和确诊东西, 帮咱们从冗杂的数据中提炼出价值信息, 让咱们可以更高效轻松地面临现场优化问题。走出客户大楼, 吸一口北京秋天清冽的空气, 这24小时不是结尾, 数据库国产化之路还会遇到许多扎手问题, 可是作为人大金仓的一员, 我有决心, 咱们将经过不断打造产品才能, 为用户发明更多的价值。