• 与wait for a undo record相关的系统卡死


         今天下班之前同事过来找我寻求帮助,说是某客户的ORACEL数据库服务器从昨天起就开始很奇怪,一个语句执行很慢很慢,好像整个系统都卡住了。

         问题1:请问最近应用系统有更新过程序吗?答:没有更新。
         问题2:请问最近数据库有过什么配置变更吗?答:没变更。
         问题3:存储相关的有什么施工吗?答:也没有。
         " OK,那么我们就一起检查检查是什么情况吧!"
          一登陆系统,发现操作系统真的不是一般的卡,连开个文件夹什么的都响应很慢。打开任务管理器观察情况,发现CPU的负荷并不是很高,内存占用也正常,看来这个界面无法满足咱的要求了。
          继续打开控制面板里面的“性能”窗口,可以看到红线跟蓝线都正常,但是绿线确几乎一致保持在最高点形成一条直线。看来问题主要是出现在IO上了,这样的IO实在是太夸张了。接下来,我们一起寻找IO高的原因吧。
          通过SQL DEVELPER连接上数据库,查看V$SESSION中wait_class#<>6的会话,发现wait for a undo record事件一直都出现在结果中,这是一个很不正常的情况,并且是同一个会话一直长时间保持。嘿,这玩意到底在干嘛?哦,原来是一只有东西在回滚,而且因为开启了并行,导致直接把所有的资源都抢占光了,其他东东什么都不用干了。。。
          怎么办?继续查找资料,有人说可以关掉并行,这样就不会出现强烈的资源竞争导致系统直接卡死的情况了。处理过程具体如下:
            1、shutdown immediate --关闭数据库
            2、startup nomount      --启动到nomount模式
            3、alter system set fast_start_parallel_rollback = FALSE scope=spfile  --关闭并行回滚
            4、shutdown immediate  --关闭数据库
            5、startup                       --重启数据库
          再次检查性能状况,发现IO还是偏高,但是系统已经不至于说卡到连动个鼠标都难的情况了。初步判断,应该是因为并行导致回滚的进程占用了绝大部分的资源,机器根本无法去“理睬”其他的操作了。
  • 相关阅读:
    正则表达式匹配
    最长回文子串
    无重复字符的最长子串
    n个骰子的点数之和
    关于模型选择
    最小堆
    kmeans++
    Dijkstra 算法
    mapreduce中获取输入文件的路径
    mapreduce数据不平衡时的处理方法
  • 原文地址:https://www.cnblogs.com/o0JSP/p/3511904.html
Copyright © 2020-2023  润新知