怎么做样网站,需要网站开发,手机网站是怎么制作的,菏泽到濮阳问题背景#xff1a; 接用户问题报障#xff0c;应用服务出现大量会话堆积现象#xff0c;数据库锁堵塞严重#xff0c;需要协助进行问题定位和排除。
问题分析#xff1a; 登录到数据库服务器上#xff0c;首先查看一下数据库当前的等待事件情况#xff0c;通过gv$ses…问题背景 接用户问题报障应用服务出现大量会话堆积现象数据库锁堵塞严重需要协助进行问题定位和排除。
问题分析 登录到数据库服务器上首先查看一下数据库当前的等待事件情况通过gv$session视图可以看到当前会话存在大量的enq: TX - row lock contention行锁堵塞。 对应出现TX行锁堵塞情况需要分析一下TX行锁的堵塞链情况确认是否是同一个堵塞源还是多个不同的堵塞源对于同一个堵塞源引发的TX行锁问题需要重点去分析这个堵塞源的会话状态和操作行为是否存在问题比如有没有在执行长时间拿锁的操作语句的执行状态时间、会话的状态空闲还是活跃以及业务的事务执行逻辑。对于出现多条堵塞链和多个不同的堵塞源情况通常是由于数据库的性能问题、表索引的设计问题、业务的事务逻辑问题导致需要先分析整理堵塞链上的操作对象是否存在关联业务的执行逻辑是否存在关系再进一步分析堵塞产生的原因。 这里我们通过gv$session视图的blocking_session查询会话之间的堵塞链情况可以看到会话的堵塞源最终都指向了节点一实例的SID:855会话。 select *from (select a.inst_id, a.sid, a.serial#,a.sql_id,a.event,a.status,connect_by_isleaf as isleaf,sys_connect_by_path(a.SID||||a.inst_id, - ) tree,level as tree_levelfrom gv$session astart with a.blocking_session is not nullconnect by (a.sid||||a.inst_id) prior (a.blocking_session||||a.blocking_instance))where isleaf 1order by tree_level asc; 由于堵塞源都指向855会话因此这里我们只取其中一条堵塞链- 691 - 1001 - 3681 - 8551进行分析。 查看堵塞源SID 855的会话执行情况可以看到会话为LGWR进程状态为ACTIVE等待事件为rdbms ipc message。LGWR引发堵塞很有可能是LGWR进程无法及时完成日志写工作。 再继续往下查看堵塞链上的下一级会话SID 368可以看到会话为JDBC应用会话等待事件为log file switch (checkpoint incomplete)当前执行SQL为gyc4mt35nxs83可以看到当前会话是由于日志切换检查点未完成导致会话出现堵塞。 再继续查看下一级会话SID 100和69可以看到会话为JDBC应用会话等待事件为enq: TX - row lock contention当前执行SQL为gyc4mt35nxs83。 执行SQLgyc4mt35nxs83为UPDATE XXXX_TAB语句。 从这里我们可以确认整个堵塞链的发生原因由于LGWR进程日志切换检查点无法及时完成导致执行XXXX_TAB的UPDATE语句的会话出现等待进而引发后续的对该表的UPDATE会话出现TX锁堵塞。 从后台日志也可以看到有很多由于检查点未完成导致日志无法分配的信息那么数据库当前出现日志切换检查点未完成的原因是什么呢我们继续往下分析。 当前数据库REDO日志组的配置为1G*3组属于合理的日志组配置查看数据库的磁盘IO负载情况可以看到当前的磁盘IO负载非常繁忙IO util已经达到100%很明显当前数据库的IO写操作较多频繁触发检查点加上DBWR进程不断写数据最终导致日志切换由于检查点来不及完成出现等待。 检查数据库的写操作发现罪魁祸首原来是之前的TX锁执行语句gyc4mt35nxs83语句对千万级的分区进行全扫描加上服务器的磁盘为机械盘磁盘IO性能很快就被打满。 问题解决 1 跟应用确认当前的会话模块为非核心业务可以先将TX锁堵塞会话kill释放服务器IO资源避免影响其他业务模块。 2 先关闭引发TX锁的非核心业务模块待语句优化之后再进一步启动。 Tip:欢迎关注公众号勇敢牛牛的笔记超100的原创内容每周不定期更新数据库技术文章
