自动性能统计信息(一)(Automatic Performance Statistics)

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:     本章主要描述收集性能统计信息,主要包括以下主题:     ·统计信息收集概要     ·自动工作负载库概览     ·管理自动工作负载库     1、统计信息收集概要     为了有效诊断性能问题,统计信息必须得以访问。
    本章主要描述收集性能统计信息,主要包括以下主题:
    ·统计信息收集概要
    ·自动工作负载库概览
    ·管理自动工作负载库

    1、统计信息收集概要
    为了有效诊断性能问题,统计信息必须得以访问。Oracle数据库为系统、会话以及单个SQL语句生成许多类型的累积统计信息。Oracle数据库同样跟踪段和服务的累积统计信息。当在这些范围中任意一个范畴中分析一个性能问题时,你自然而然地查看你感兴趣的时间段的统计信息(δ值)。特别的,你会查看在一个时间段的起始与结束的时候一个统计信息的差异。
    统计信息的累积值通常可以通过动态性能视图进行访问,例如V$SESSTAT,V$SYSSTAT。注意,当数据库实例关闭后,动态性能视图中的累积值将被重置。自动工作负载库(AWR)自动为除会话级以外所有级别的统计信息保留累积值和δ值。这个过程在有规律的时间段内被重复执行,其结果被称为AWR快照。快照捕获的δ值则代表着相应时间段内每个统计信息的变化情况。
    “度量”是Oracle数据库收集的另一种类型的统计信息。度量被定义为某些累积统计信息改变的比率。比率可以用一系列单位来衡量,包括时间,事务或数据库调用。例如,每秒钟数据库调用次数就是一个度量。度量值可以从一些V$视图中找到,在这些V$视图中的度量值是一段非常小的时间间隔内的平均值,典型的如60s。度量值最近一段时间内的值可以通过V$视图获取,其中的一些数据同时也被AWR快照保留。
    Oracle收集的统计信息数据的第三种类型是采样数据。ASH采样器执行采样。ASH采样所有活动会话的当前状态。数据库将收集的数据放在内存中,你可以通过V$视图进行访问。拍摄AWR快照的时候同样将其写入永久存储中。
    诊断性能问题的一个有力工具是统计信息基线(baseline)的使用。统计信息基线是系统在负载高峰仍正常运行的时间段采集的统计信息等级(statistic rates)。通过将性能低下时段捕获的统计信息与所选择的基线对比,那些变化显著的地方很有可能就是问题的根源。
    AWR通过指定并保存一对AWR快照作为基线以支持捕获基线数据。仔细考虑你选择作为基线的时段;基线应该是系统负载高峰的一个良好体现。在将来,你可以将性能不佳的时段捕获的快照与这些基线做比较。
    OEM是推荐的用来观察动态性能视图中的实时数据和AWR历史表格中的历史数据的工具。OEM同样可以用作捕获与AWR数据相关的操作系统和网络统计信息数据。
    
    1.1 数据库统计信息
    数据库统计信息提供了数据库负载类型的信息和数据库使用的内部和外部资源的信息。本节描述一些重要的统计信息。
    
    1.1.1 等待事件
    等待事件是这样一类统计信息:它由服务器进程或线程引起,通常意味着一个进程或线程在继续处理“事情”之前必须等待某一个事件的完成。等待事件揭露了各种各样的可能影响性能的问题的症状,例如,闩的争用,缓冲区的争用,以及I/O的争用。
     为了简化等待事件的深入分析,等待事件被分类。类型包括:管理类(administrative)、应用类(application)、集群类(cluster)、提交类(commit)、并发类(concurrency)、配置类(configuration)、空闲类(idle)、网络类(network)、其它(other)、调度任务(scheduler)、系统I/O(system I/O)、用户I/O(user I/O)。
    等待事件的分类基于一个共同的解决等待事件相应问题的的方案。例如,独占TX锁通常属于应用类等待事件而HW锁通常属于配置类等待事件。
    下表包含了常见的类型的等待事件:
    应用类:行级锁或显式锁命令引起的锁等待
    提交类:提交事务后等待重做日志写好的确认
    空闲类:标识会话不活跃的等待事件,例如:SQL*Net message from client
    网络类:等待通过网络传输的数据
    用户I/O类:等待从磁盘读取数据块
     
     实例的等待事件统计信息包括前台和后台进程的统计信息。因为你一般会聚焦于调优前台活动,在相关的V$视图上,整个实例活动分为前台和后台统计信息,以便调优。
     V$SYSTEM_EVENT视图展示了实例前台活动和实例的统计信息数据。V$SYSTEM_WAIT_CLASS视图展示了前台和等待事件信息聚合成等待事件类型后的信息。V$SESSION_EVENT和V$SESSION_WAIT_CLASS展示了会话级别的等待事件和等待类型的统计信息。
     
      1.1.2 时间模型统计信息
     当调优Oracle数据库时,每一个数据库的组件都有其自身的统计信息。为了将系统作为一个整体来看待,拥有一个普遍的衡量尺度很必要。因此,大部分Oracle数据库报告从时间尺度来描述统计信息。此外,V$SESS_TIME_MODEL 和 V$SYS_TIME_MODEL视图提供了时间模型统计信息。使用这个普遍的时间度量可以帮助量化对数据库操作的影响。
     时间模型统计数据中最重要的是DB time。这个统计信息代表了花在数据库调用的总时间,并且是一个实例总体负载的一个导向标。它是所有会话的CPU时间与等待时间,不包括空闲等待事件(非空闲用户会话)的总和。
     DB time从实例启动时开始累积。因为DB time是通过综合所有非空闲用户会话的时间来计算的,所以存在DB time超过实例启动后实际流逝的时间。例如,一个实例运行了30分钟,有4个活跃的会话那么其DB time的值将近120分钟。
     调优Oracle系统的目标可以以减少用户花在执行某些数据库操作上的时间为起点,或者简单地减少DB time。其它时间模型统计信息提供了某些操作在时间尺度上的量化效果,例如登录操作、硬解析和软解析。

     1.1.3 Active session history
     V$ACTIVE_SESSION_HISTORY视图提供了实例的会话活动采样。Active sessions每秒采样一次,并存储在sga中的一个循环缓冲区。任何链接到数据库的、等待非空闲类等待事件的会话都可以看作一个Active session。这包括了采样时CPU上的所有会话。
     每个会话采样是一系列行,V$ACTIVE_SESSION_HISTORY视图会在每次采用中为每一个会话返回一行。最近的会话采样的行将最先返回。因为Active session存储在sga中的循环缓冲区,系统活动量(activity)越大,会话活动信息存储在循环缓冲区的时间就越短。这就意味着V$视图中的会话采样,或者说会话活动存储在V$视图中的时间,完全依赖于数据库的活跃性。
     作为AWR快照的一部分,V$ACTIVE_SESSION_HISTORY的内容同样也被记录到了磁盘中。因为在系统活动很多的时候该V$视图会产生大量的数据,因此通常只有一部分会话采样被写入磁盘。
     通过仅捕获活跃的会话,一系列可管理的数据以与工作直接相关的大小而不是系统允许的所有的会话的形式表现出来。使用ASH使你可以检查并执行对存在于V$ACTIVE_SESSION_HISTORY视图的当前数据与存在于DBA_HIST_ACTIVE_SESS_HISTORY视图的历史数据进行详尽的分析,这样避免了为了重现负载而收集额外的性能跟踪信息。ASH同时包含了捕获的每条SQL语句的执行计划信息。你可以通过这个信息找出哪条SQL语句占用了最多的SQL Elapsed time。ASH中的信息可以从多个角度来收集,包括:
    ·SQL语句的SQL标识符
    ·执行SQL语句的SQL执行计划标识符和SQL执行计划的哈希值
    ·SQL执行计划的信息
    ·对象编号、文件号、块号
    ·等待事件标识符和参数
     ·会话标识符和会话系列号
     ·模块和动作名
     ·会话的客户端标识符
     ·用户组号
    你可以收集指定的时间段内的ASH信息到报告中。
    Active session history采样同样适用于Active dg 物理standby实例以及Oracle ASM实例。在这些实例中,当前会话活动被收集和呈现在V$ACTIVE_SESSION_HISTORY视图中,但是不写入到磁盘中。

    1.1.4 系统和会话统计信息
    通过V$SYSSTAT和V$SESSTAT视图可以访问大量的系统和会话级别的累积的数据库统计信息。

    1.2 操作系统统计信息    
    操作系统统计信息提供了关于系统主要硬件组件的用量和性能信息,以及操作系统本身的性能。这类信息对于监控潜在的资源紧张很关键,例如CPU周期和物理内存,对于监控外围设备性能低下也很关键,例如磁盘驱动。
    操作系统统计信息是硬件和操作系统如何工作的一个指示。许多系统分析师通过安装更多的硬件来应对硬件资源短缺。这是对操作系统统计信息显示出来的一系列症状的比较保守的措施。最好的做法是将操作系统统计信息作为一个诊断工具,就像医生在诊断时使用体温计、脉搏率、病人的疼痛等作为判断的依据一样。为了更好的确定瓶颈,应当收集系统上所有要进行性能诊断的服务器的操作系统统计信息。
    操作系统统计信息包括下列类型:
    ·CPU统计信息
    ·虚拟内存统计信息
    ·磁盘I/O统计信息
    ·网络统计信息
    
    1.2.1 CPU统计信息
    CPU使用率在调优过程中是最重要的操作系统统计信息。需要获得整个系统的CPU使用率以及在多处理器环境中单个CPU的使用率。单个CPU的使用率可以用来探测单线程和可扩展性问题。
    大部分操作系统以消耗在用户空间或模式与内核空间或模式的形式来报告CPU使用率。这些额外的统计信息使得我们可以更好地分析到底CPU在被什么占用。
    在一个运行Oracle数据库的系统上,并且只有数据库一个应用运行着,系统将运行数据库的活动归为用户空间中。服务于数据库请求的活动(例如调度程序,同步,I/O,内存管理,进程/线程的建立与撤销)则运行在内核模式。在CPU满负荷运行的系统上,一个健康的Oracle数据库的运行通常占用65%——95%的用户空间。
    V$OSSTAT视图捕获数据库中机器级别的信息,这有助于你确定是否存在硬件级别的资源问题。V$SYSMETRIC_HISTORY视图显示列一个小时内的主机CPU使用率度量值,每隔一分钟显示一次CPU使用率的百分比值。V$SYS_TIME_MODEL视图提供了Oracle数据库的CPU使用率的统计信息。使用这些统计信息可以帮助你确定是Oracle数据库还是其它系统活动造成了CPU的问题。
    
    1.2.2 虚拟内存统计信息
    虚拟内存统计信息主要被用来作为确认系统中只有少量paging或swapping活动的检查手段。当paging或swapping发生时,系统性能会迅速下降并且无法预估下降的程度。
    单个进程内存统计信息可以检测由于程序无法回收进程堆占用的内存而导致的内存泄漏。这些统计信息对于确认在系统开机后达到一个稳定的状态时内存使用率没有增加十分必要。这个问题在位于中间层计算机的共享服务器上尤为突出,该层的会话可能处于持续地和用户交互的状态,会话完成但是没有完全回收。

    1.2.3 磁盘I/O统计数据
    因为数据库驻留在一系列磁盘上,所以I/O子系统的性能对于数据库的性能来说尤为重要。大多数操作系统提供了大量关于磁盘性能的统计信息。最重要的磁盘统计信息是当前相应时间和磁盘队列的长度。这些统计信息显示了磁盘是否运行良好或者磁盘是否负载过重。
    观测I/O系统的正常性能,单块读取的典型值一般在5——20毫秒之间,取决于硬件的使用。如果硬件的响应时间远远高于正常性能的值,那么说明性能很差或者过载。这是你的系统瓶颈。如果磁盘队列开始超过2,那么这个磁盘是潜在的系统瓶颈。
    Oracle数据库同样为数据库自身产生的I/O调用收集连续的I/O统计信息。在下面这些维度中,这些统计信息包括单块读、多块读和写操作:
    ·消费组:
    当Oracle数据库资源管理器启用,V$IOSTAT_CONSUMER_GROUP视图会捕获属于当前可用资源计划一部分的所有消费组的I/O统计信息。数据库每个小时采集累积统计信息并将其作为历史统计信息保存在AWR中。
    ·数据库文件
    数据库文件的I/O统计信息可以通过访问V$IOSTAT_FILE视图。
    ·数据库功能
    数据库功能(例如LGWR和DBWR)的I/O统计信息可以通过V$IOSTAT_FUNCTION视图获取。

    1.2.4 网络统计信息
    你可以像使用磁盘统计信息一样来使用网络统计信息以确定网络或网络接口是正常运行还是过载。在今天的网络应用中,网络潜在因素是实际用户响应时间的一个重要组成部分。因为这个原因,这些统计信息是一个至关重要的debug工具。
    Oracle数据库在V$IOSTAT_NETWORK视图中维护着一组网络I/O统计信息。

    1.2.5 操作系统数据采集工具
    下表列出UNIX上各种采集操作系统统计信息的工具,至于Windows,使用性能监视器工具。
    
Component UNIX Tool

CPU

sar, vmstat, mpstat, iostat

Memory

sar, vmstat

Disk

sar, iostat

Network

netstat



    1.3 破译统计信息
     当一开始研究性能数据,你可以通过研究你的统计信息来得出初步结论。一个确认你对统计信息的解译是正确的方法是交叉验证其它统计信息。这可以确认一个统计信息或事件是否是真的目标。同时,因为前台活动是可调整的,在分析后台统计信息之前最好先分析前台活动的统计信息。
     一些常见陷阱在下面章节将进行讨论:
     ·命中率
     当进行调优的时候,常见的一个做法就是计算一下比率来确定是否存在问题。这样的比率包括buffer cache命中率,软解析命中率,还有闩命中率。不要将这些比率作为确定是否存在性能瓶颈的决定性因素。相反的,将它们作为参考因素。为了鉴别是否存在性能瓶颈,需要进一步检查其它相关的信息。
     ·等待事件及实时统计信息
     在实例级别将参数TIMED_STATISTICS设置为true,除了available wait counts以外,可以让数据库为等待事件收集等待的时间。这个数据库对于比较一个事件总的等待时间与数据收集之间总的流逝时间非常有用。例如,如果一个等待事件在两个小时的时段内一共占用了30s,那么对于深入这个事件几乎没什么作用,尽管这个等待事件可能按等待时间排序排在第一。然而,如果这个事件在45分钟的时段内占了30分钟,那么这个等待事件就值得进一步深入。
     注:如果初始化参数STATISTICS_LEVEL设置为true或者typical,那么数据库会自动收集实时统计信息。如果STATISTICS_LEVEL设置为BASIC,那么你必须将TIMED_STATISTICS设置为ture来收集实时统计信息。需要注意的是将STATISTICS_LEVEL设置为BASIC会禁用许多自动化的特性,因此不建议这么做。
    如果你显示设置了
DB_CACHE_ADVICE, TIMED_STATISTICS, 或 TIMED_OS_STATISTICS,或者在pfile中指定了对应的值,或者使用了alter system或alter session语句,那么这些显示设置的值会覆盖掉由STATISTICS_LEVEL衍生的参数值。

     ·将Oracle数据库统计信息与其它因素比较
     当查看统计信息的时候,将一些会影响统计信息是否有价值的因素考虑在内是重要的。这些因素包括用户负载和硬件性能。如果你在一个主机硬件是64节点的计算上,系统上有2000个用户,那么就算在45分钟内有30分钟都在等待一个事件也不见得就是系统存在问题的暗示。
    ·没有实时统计信息的等待事件
     如果TIMED_STATISTICS为false,那么一个事件的总的等待时间是不知道的。因此,这个时候只能按等待事件等待的次数来进行排序。尽管等待次数最多的等待事件可能暗示着潜在的性能瓶颈,但它们可能不是主要的性能瓶颈。存在这样一种情况,一个事件有着相当大的请求次数,但是等待时间却很小。这种情况的对立面同样存在:一个事件只有很少的等待次数,但是等待时间却占据了总时间相当大的一部分。没有等待时间来做对比,很难确定一个等待事件究竟是不是问题所在。
     ·空闲等待事件
     Oracle数据库使用一些等待事件来表示一些Oracle服务器进程是否处于空闲状态。一般来说,这些等待事件对于诊断性能问题没有任何价值,在检查等待事件的时候 应将它们排除在外。
     ·计算类统计信息
     当解译计算类统计信息(例如rates,标准化后的事务统计信息,ratios),将计算统计信息与实际统计信息数目进行交叉验证十分重要。这确认了衍生的比率是否真的是问题所在:小的统计信息加起来通常会让一个不同寻常的比率大打折扣。例如,在初始的检查中,软解析的比率达到50% ,这通常是一个潜在的调优的区域。如果,然而,在数据收集的间隔内仅有一个硬解析和一个软解析,这样软解析的比率就将是50%,尽管统计信息统计出来显示这不是一个值得关注的区域。在这种情况下,因为原始统计信息数目太少,比率此时就不是问题所在。


     2、AWR概览
    见《自动性能统计信息(二)》



相关文章
|
存储 Oracle 关系型数据库
Oracle优化07-分析及动态采样-DBMS_STATS 包
Oracle优化07-分析及动态采样-DBMS_STATS 包
135 0
Oracle优化07-分析及动态采样-DBMS_STATS 包
|
SQL 关系型数据库 MySQL
Influx Sql系列教程二:retention policy 保存策略
retention policy这个东西相比较于传统的关系型数据库(比如mysql)而言,是一个比较新的东西,在将表之前,有必要来看一下保存策略有什么用,以及可以怎么用
275 0
Influx Sql系列教程二:retention policy 保存策略
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
|
SQL 监控 关系型数据库
参数performance_schema设置最佳实践
最早开源MySQL从5.5开始支持performance_schema(下文简称PFS),又在后续版本不断持续完善、优化,PFS已经成为了性能诊断优化的利器,使SQL问题、锁等待事件等比较清晰地展现出来,但打开PFS也会带来相应的性能成本,本篇就来看下PFS相比其他工具及不打开PFS的性能差异。
参数performance_schema设置最佳实践