【Oracle生产运维】数据库服务器负载过高异常排查处理

本文主要是介绍【Oracle生产运维】数据库服务器负载过高异常排查处理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

说明

在Oracle数据库运维工作中,经常会遇到Oracle数据库服务器平均负载(load average)突然异常升高,如果放任不管,严重的情况下会出现数据库宕机、服务器重启等重大故障。因此,当发现数据库服务器平均负载异常高的时候,必须予以重视,并立即开展处理工作。

很多刚工作或者是没这方面处理经验的同学可能遇到这种情况就会开始慌张,不知从何下手,无法快速定位出引起负载异常的原因。

下面介绍我在工作中常用的排查思路供大家参考。截图的结果皆在实验环境中截取,与实际生产环境有较大出入,只作为操作演示。

1 负载过高现象

巡检发现、监控平台或者在操作系统中执行命令,显示load average值异常过高。

Linux常用的load average监控命令:

[oracle@oracle11g ~]# sar -q 1 5

此命令可以查看当前的平均负载,以及一分钟以来、五分钟以来和十五分钟以来的平均负载。

引起Oracle数据库服务器负载异常增高的原因有很多不同情况,以下是比较常见的情况:

  • 大量排序、SQL解析、慢SQL引起CPU过高;
  • 大量直接路径读、全表扫描、并发读写引起IO繁忙。

2 确认高负载类型

需要确认负载突然异常增高是CPU还是IO或者共同引起的,缩小问题范围,为下一步定位具体原因做准备。

登录数据库服务器,切换到orace用户。

2.1 检查平均负载

[oracle@oracle11g ~]$ sar -q 1 5
Linux 2.6.32-642.el6.x86_64 (oracle11g)         06/09/2024      _x86_64_        (1 CPU)05:34:11 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
05:34:12 AM         0       382      0.49      0.43      0.47
05:34:13 AM         0       382      0.49      0.43      0.47
05:34:14 AM         0       382      0.49      0.43      0.47
05:34:15 AM         0       382      0.49      0.43      0.47
05:34:16 AM         0       382      0.49      0.43      0.47
Average:            0       382      0.49      0.43      0.47

说明:

  • runq-sz:运行队列,也就是等待运行的进程数;
  • plist-sz:进程创建的总数,包括线程;
  • ldavg-1:最后1分钟的平均负载;
  • ldavg-5:最后5分钟的平均负载;
  • ldavg-15:最后15分钟的平均负载。

如果runq-sz值很高,表明可能是CPU资源使用率过高引起的,若值低可能是IO过高引起的。

这里只是一个初步判断,需要执行下面的命令确认猜测。

2.2 检查CPU使用率

1)执行top命令查看所有进程的cpu和内存使用情况

[oracle@oracle11g ~]$ top -c

image.png

主要观察排在前几位的进程的%CPU,一般当负载异常时,前面两三个进程的%CPU会在100%。

top命令也可以看到平均负载load average的情况。

2)执行iostat命令查看CPU平均利用率

image.png

说明:

  • %user:用户空间的cpu使用率;
  • %idle:空闲的cpu。

如果%idle过高,说明CPU使用率过高。

2.3 检查I/O传送速率

1)查看IO等待

%iowait为CPU等待IO的百分比,如果非常高,则说明IO有瓶颈。

[oracle@oracle11g ~]$ iostat -c 1 5
Linux 2.6.32-642.el6.x86_64 (oracle11g)         06/09/2024      _x86_64_        (1 CPU)avg-cpu:  %user   %nice %system %iowait  %steal   %idle0.05    0.00    0.16    0.10    0.00   99.70avg-cpu:  %user   %nice %system %iowait  %steal   %idle0.00    0.00    1.01    0.00    0.00   98.99avg-cpu:  %user   %nice %system %iowait  %steal   %idle0.00    0.00    0.00    0.00    0.00  100.00avg-cpu:  %user   %nice %system %iowait  %steal   %idle0.00    0.00    1.00    1.00    0.00   98.00avg-cpu:  %user   %nice %system %iowait  %steal   %idle0.00    0.00    0.00    1.02    0.00   98.98

2)查看IO速率

[oracle@oracle11g ~]$ sar -b 1 5
Linux 2.6.32-642.el6.x86_64 (oracle11g)         06/09/2024      _x86_64_        (1 CPU)05:42:33 AM       tps      rtps      wtps   bread/s   bwrtn/s
05:42:34 AM     12.12      4.04      8.08    129.29     97.98
05:42:35 AM     12.12      0.00     12.12      0.00    114.14
05:42:36 AM      8.08      0.00      8.08      0.00     97.98
05:42:37 AM     15.15      4.04     11.11    129.29    130.30
05:42:38 AM     43.43      7.07     36.36    226.26    502.02
Average:        18.18      3.03     15.15     96.97    188.48

说明:

  • tps:每秒钟的I/O操作总数。这个值如果持续很高,可能表明磁盘I/O非常繁忙;
  • rtps:每秒钟的读操作数。高读操作数可能表明有大量的数据被读取;
  • wtps:每秒钟的写操作数。高写操作数可能表明有大量的数据被写入;
  • bread/s:每秒钟从物理设备读入的数据量,单位为 块/s。块的大小通常为512字节;
  • bwrtn/s:每秒钟向物理设备写入的数据量,单位为 块/s;
  • rb/c 和 wb/c:分别是每次读取和写入操作的平均块数。如果这个值很低,可能表明有许多小的I/O请求,这可能导致磁盘性能问题。

3 定位问题,找出引起高负载的SQL语句

Oracle数据库问题的大部分原因基础都是由SQL语句引起的。

假设经过上面的排查,确定为CPU使用率高引起的高负载,下面通过几个脚本定位到引起CPU使用率过高的SQL语句。

3.1 直接找到引起高负载的TOP SQL

登录数据库,检查近xx分钟的资源使用率(CPU、IO)TOP5的SQL:

SQL>
select ash.sql_id,sum(decode(ash.session_state,'on cpu',1,0)) "cpu",sum(decode(ash.session_state,'waiting',1,0)) -sum(decode(ash.session_state,'waiting',decode(en.wait_class,'user i/o',1,0),0)) "wait",sum(decode(ash.session_state,'waiting',decode(en.wait_class,'user i/o',1,0),0)) "io",sum(decode(ash.session_state,'on cpu',1,1)) "total"from v$active_session_history ash,v$event_name enwhere sql_id is not null and en.event#=ash.event# and ash.sample_time > sysdate -&min/(24*60)group by ash.sql_idorder by sum(decode(ash.session_state,'on cpu',1,1)) desc;

根据sql_id找到对应的sql_text:

SQL> select SQL_TEXT from v$sqltext where sql_id = '&sql_id' order by piece;

3.2 根据进程号找出SQL

前面查看cpu负载的时候使用了top命令,输出的信息中就包含有进程号PID,根据这个PID可以定位到具体是哪条SQL语句。

image.png

将异常的PID代入Oracle的几个常用的性能视图:

SQL>
set long 999999999999999999
set pages 200
select st.sql_id,st.sql_testfrom v$sqltext st,v$session se,v$process pwhere st.sql_id = se.sql_idand se.paddr = p.addrand p.spid = '&PID'order by st.piece;

得到的sql_test即为引起CPU高负载的SQL语句。

3.3 根据等待事件判断找出SQL

此方法需要对常见的等待事件比较熟悉。

查看当前正在执行的会话和相应等待事件:

SQL>
set lines 300
col machine for a20
col username for a20
col event for a30
col program for a25
col state for a10
select inst_id,sid,serial#,sql_id,sql_hash_value shv,event,username,program,machine,blocking_instance bi,blocking_session bs,seconds_in_wait wait_mfrom gv$sessionwhere (event not like '%dbms%' and event not like '%gcs remote%' and event not like '%mon timer%'and event not like '%SQL Net%' and event not like '%Streams AQ%' and event not like '%jobq slave wait%'and event not like '%ASM background timer%' and event not like '%DIAG idle wait%'and event not like '%VKTM logical idle Wait%' and event not like '%ges remote message%' and event not like '%Space Manager slave idle wait%' and event not like '%class slave wait%' and event not like '%wait for unread  message on broadcast channel%' and event not like '%pmon timer%')and status = 'ACTIVE' and wait_class != 'idle'and sql_id is not null   order by event,sql_id desc; 

主要看出现大量重复的sql_id和event。

注意,当同时存在大量与CPU和IO相关的等待事件时,应根据前面排查的结果侧重分析。即,当明确了是CPU问题时,就应带看CPU相关的等待事件对应的sql_id。

3.4 查看ASH或AWR报告

生成ASH报告或AWR报告需要将快照时间段设置在高负载期间。

当负载异常持续事件是短时间(10-20分钟)时,生成ASH报告。当负载异常持续事件是长时间(1小时以上)时,生成AWR报告。

分析报告也是需要对等待事件比较熟悉,此处就不对ASH报告和AWR报告的分析方法做说明,请自行查阅资料。

报告生成方法:

------ASH
# su - oracle
$ cd
$ sqlplus / as sysdba
SQL> @?/rdbms/admin/ashrpt.sql------AWR
# su - oracle
$ cd
$ sqlplus / as sysdba
SQL> @?/rdbms/admin/awrrpt.sql

报告生成的目录在oracle用户家目录下。

4 问题处理

找出引起高负载的问题SQL语句后,反馈给业务或应用或开发进行检查处理,同时也需要配合他们进行分析。

这篇关于【Oracle生产运维】数据库服务器负载过高异常排查处理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1050486

相关文章

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

服务器集群同步时间手记

1.时间服务器配置(必须root用户) (1)检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 (2)修改ntp配置文件 [r

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

NameNode内存生产配置

Hadoop2.x 系列,配置 NameNode 内存 NameNode 内存默认 2000m ,如果服务器内存 4G , NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列,配置 Nam

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

【生成模型系列(初级)】嵌入(Embedding)方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入(Embedding)方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节:嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”,它将文本中的单词或短语转换成计算机能够理解的数学形式,即向量。 正如翻译机将一种语言

【Linux 从基础到进阶】Ansible自动化运维工具使用

Ansible自动化运维工具使用 Ansible 是一款开源的自动化运维工具,采用无代理架构(agentless),基于 SSH 连接进行管理,具有简单易用、灵活强大、可扩展性高等特点。它广泛用于服务器管理、应用部署、配置管理等任务。本文将介绍 Ansible 的安装、基本使用方法及一些实际运维场景中的应用,旨在帮助运维人员快速上手并熟练运用 Ansible。 1. Ansible的核心概念

Linux服务器Java启动脚本

Linux服务器Java启动脚本 1、初版2、优化版本3、常用脚本仓库 本文章介绍了如何在Linux服务器上执行Java并启动jar包, 通常我们会使用nohup直接启动,但是还是需要手动停止然后再次启动, 那如何更优雅的在服务器上启动jar包呢,让我们一起探讨一下吧。 1、初版 第一个版本是常用的做法,直接使用nohup后台启动jar包, 并将日志输出到当前文件夹n

Thymeleaf:生成静态文件及异常处理java.lang.NoClassDefFoundError: ognl/PropertyAccessor

我们需要引入包: <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-thymeleaf</artifactId></dependency><dependency><groupId>org.springframework</groupId><artifactId>sp

深入理解数据库的 4NF:多值依赖与消除数据异常

在数据库设计中, "范式" 是一个常常被提到的重要概念。许多初学者在学习数据库设计时,经常听到第一范式(1NF)、第二范式(2NF)、第三范式(3NF)以及 BCNF(Boyce-Codd范式)。这些范式都旨在通过消除数据冗余和异常来优化数据库结构。然而,当我们谈到 4NF(第四范式)时,事情变得更加复杂。本文将带你深入了解 多值依赖 和 4NF,帮助你在数据库设计中消除更高级别的异常。 什么是