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

1.2自动工作负载库(AWR)概览
   
AWR收集、处理并维护性能统计信息以用来侦测问题和自我调优。这些数据同时存储在内存和数据库中。收集的数据既可以呈现在报告中,又可以从视图中查询。
    AWR收集的统计信息包括:
    ·决定对数据库段的访问和使用量的统计信息的对象统计信息
    ·关于活动的基于时间消耗量的时间模型统计信息,可访问V$SYS_TIME_MODEL和V$SESS_TIME_MODEL视图
    ·收集在V$SYSSTAT和V$SESSTAT视图中的一些系统和会话统计信息
    ·基于一些指标如elapsed time和CPU time,造成了系统最高的负载的SQL语句
    ·ASH统计信息,展示了 最近会话活动的历史信息
    
    默认可以使用AWR收集数据库统计信息,并由参数STATISTICS_LEVEL控制。AWR要能收集统计信息,该参数必须被设置为 typical或all。该参数默认值是typical。将该参数值设置为basic会禁用许多Oracle数据库特性,包括AWR,因此不建议这么做。如果该参数设置为basic,你仍然可以通过DBMS_WORKLOAD_REPOSITORY包手动捕获AWR统计信息。然而,因为很多内存收集的系统统计信息——例如段的统计信息和内存指导统计信息会被禁用,这时候AWR捕获的信息就不是完整的了。

    1.2.1快照
    快照是ADDM在特定时间段内收集一系列历史数据,用来进行性能对比。默认情况下,Oracle数据库每个小时自动产生一个快照并将统计信息保存在工作负载库中8天。你也可以手动生成快照,但通常没有这个必要 。在 快照间隔内的数据会交由自动数据库诊断监视器(ADDM)分析。
    基于对系统负载产生的影响,AWR通过比较不同快照来确定捕获哪些SQL语句。这样减少了必须捕获的SQL语句数量。
    
    1.2.2 基线
    基线包含了一个特定时间段内性能数据,保存在基线中的数据用作出现性能问题时与对应时间段内的性能数据对比。包含在基线中的快照被排除在AWR清理过程之外,会一直保存。
    Oracle数据库中有几类可用的基线:    
    ·固定基线
    ·移动窗口基线
    ·基线模板
    
    1.2.2.1 固定基线
    固定基线对应一个由你指定的固定的、连续的过去的时间段。在创建一个固定基线之前,仔细考虑你选择作为基线的时间段,因为基线应该代表着系统运行在最优的级别。在将来,你可以将基线与其它基线或在性能低下的时段捕获的快照做比较以分析随着事件流逝性能的下降问题。
    
    1.2.2.2
    移动窗口基线
    移动窗口基线对应着AWR保留周期内所有的AWR数据。当使用自适应阈值的时候,移动窗口基线很有用,这是因为数据库可以使用整个AWR保留周期内的所有AWR数据来计算度量阈值的值。
    Oracle数据库自动维护系统定义的移动窗口基线。系统定义的移动窗口基线的默认的窗口大小是当前AWR保留周期,默认是8天。如果你打算 使用自适应阈值,可以考虑使用一个更大的移动窗口——例如30天——以准确计算出阈值的值。你可以调整移动窗口基线的大小,通过将移动窗口的值改为AWR保留时间相等或更小的值就行。因此,要增加移动窗口的大小,你首先要做的就是增加相应的AWR保留时间。
    
    1.2.2.3 基线模板
    你可以使用基线模板来为将来的一个连续的时段创建基线。有两种基线模板:单个基线模板和重复基线模板。
    你可以使用单个基线模板来为将来单个连续时段创建基线。这个技术对于你事先知道你将要在将来哪个时段捕获数据很有帮助。例如,你想捕获在即将到来的周末进行的系统测试时候的AWR数据。这种情况下,你可以创建一个单个基线模板来自动捕获测试时的数据。
    你可以使用重复基线模板来建立并删除基于重复时间日程的基线。这在你想让Oracle数据库在一个连续的基础上自动捕获连续时间段内的数据时很有用。例如,你想在每个月的每周一早上捕获AWR数据。这种情况下,你可以为每周一这个重复的日程安排建立一个重复基线模板来自动创建基线,同时在指定过期间隔的基础上自动移除旧的基线,例如一个月。

    1.2.3 自适应阈值
    自适应阈值使你以最小化管理代价来监控和侦测性能问题。自适应阈值可以使用由移动窗口基线中捕获的度量值衍生而来的统计信息来自动设置报警和关键报警阈值。当系统性能随着时间的演进,这些以周为单位进行计算的阈值的统计信息可能会产生新的阈值。除了每周重新计算这些阈值,自适应阈值还会基于时间段工作负载模式来为一天或一周内不同时段计算不同的阈值。
    例如,许多数据库支持白天联机事务处理,晚上批处理。每个事务的响应时间这个度量对于白天的联机事务处理性能下降问题很有价值。然而,一个有用的oltp阈值对于批处理来收未免太低,批处理运行长时间的事务是很常见的。因此,一个合适的oltp阈值会在晚上执行批处理的时候频繁触发错误的性能报警。自适应阈值能够检测到这种工作负载模式并自动为白天和晚上分别设置不同的阈值。
    有两种自适应阈值:
    最大值百分比:阈值的值从移动窗口基线中的数据观察到的多个最大值的百分比计算而来。
    重要性等级:阈值的值根据统计信息的百分比设定,统计信息的百分比代表了基于移动窗口基线的观测值与阈值相比不寻常的程度。指定下列值之一为百分比:
    high(.95):100次中只有5次超过期望值
    very high(.99):100次中只有1次超过期望值
    severe(.999):1000次中只有1次超过期望值
    extreme(.9999):10000次中只有1次超过期望值

    注:当你指定severe或extreme时,Oracle数据库执行一个内部计算来设定阈值。在某些情况下,Oracle数据库无法通过基线中的数据来设置这些阈值的值,同时不会设置重要性级别阈值。
    如果你没有按照预期收到报警,同时你指定了severe或extreme的重要性级别阈值,那么你可以尝试着把重要性级别设置的低一点,例如very high或high。作为替代,你也可以设置最大值百分比阈值而不是重要性级别阈值。如果你改变阈值后发现你收到了太多的报警,你可以尝试着提高发生的次数来设置报警以减少报警次数。

    最大值百分比阈值在系统处于高峰工作负载时很有用,并且你想在当前工作负载量接近或超过先前最大值时发出报警。那些具体值未知但是具有明确的限制的度量对于这些设置来说的好的候选。例如,每秒产生的redo这个度量是一个典型的最大值百分比阈值的候选者。
    重要性级别阈值对于当系统正常运行时显示出的统计上稳定状态,当系统性能低下时则波动很大的度量很有用。例如,在调整的很好的oltp系统上,每个事务的平均响应时间度量应该是很稳定的,但当出现性能问题时则会波动得非常厉害。重要性级别阈值专门用于产生不寻常的度量值和不寻常的系统性能问题的情况的报警。
    注:管理基线度量的主要接口是OEM,要为基线度量创建一个自适应阈值,请使用OEM。

    1.2.4 空间消耗
    AWR消耗的空间取决于下面几个因素:
    ·在任何给定的时段中系统中的活跃会话数
    ·快照的间隔
    快照的间隔决定了拍摄快照的频率。一个小的快照间隔会增加频率,如此增加了AWR收集的数据量。
    ·历史数据保留时间
    保留时间决定了在数据被清理之前会保留多久。一个较长的保留时间会增加AWR的消耗。
    
    默认情况下,快照每小时拍摄一次并保留8天。根据默认的设置,一个平均10个并发活跃会话的系统大约需要200到300MB的空间来存放AWR数据。可以该笔那默认的快照间隔和保留时间。
    AWR占用的空间可以通过增加快照间隔和减少快照保留时间来减少。当减少保留时间时,注意有一个Oracle数据库自管理的特性依赖于AWR数据来正常工作。缺少足够的数据会影响这些组件和特性的有效性和准确性,包括:
    ·自动数据库诊断 监视器
    ·SQL调优指导
    ·undo指导
    ·段指导
    如果可能的话,Oracle建议你将AWR保留时间设置的足够长,至少足够来捕获一个完整的工作负载周期的数据。如果你的系统工作负载循环周期是一周,例如工作日进行oltp周末进行批处理,你不需要改变默认的AWR保留时间。然而如果你的系统是在每个月月末的时候经历一次高峰负载,那么你最高 将保留时间设置为1个月。
    在意外情况下,你可以关闭自动快照收集功能,只要把快照间隔设置为0即可。在这种情况下,工作负载和统计数据的自动收集功能被关闭,很多Oracle数据自管理的功能无法使用。此外,你无法手动创建快照。因为这个原因,Oracle强烈建议不要关闭自动快照收集功能。

时间: 2024-08-02 06:03:39

自动性能统计信息(二)(Automatic Performance Statistics)的相关文章

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

    本章主要描述收集性能统计信息,主要包括以下主题:     ·统计信息收集概要     ·自动工作负载库概览     ·管理自动工作负载库     1.统计信息收集概要     为了有效诊断性能问题,统计信息必须得以访问.Oracle数据库为系统.会话以及单个SQL语句生成许多类型的累积统计信息.Oracle数据库同样跟踪段和服务的累积统计信息.当在这些范围中任意一个范畴中分析一个性能问题时,你自然而然地查看你感兴趣的时间段的统计信息(δ值).特别的,你会查看在一个时间段的起始与结束的时候

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

1.3 管理自动工作负载库(AWR)本节讲述如何管理AWR,包含以下主题:     ·管理快照     ·管理基线     ·管理基线模板     ·传输自动工作负载库数据     ·使用自动工作负载库视图     ·生成AWR报告     ·生成AWR对比报告     ·生成ASH报告     ·使用ASH报告 1.3.1 管理快照     默认情况下,Oracle数据库每小时生成一个快照,并将统计信息保留在工作负载库中8天.必要时,你可以使用DBMS_WORKLOAD_REPOSITORY程

Oracle 判断 并 手动收集 统计信息 脚本

CREATE OR REPLACE PROCEDURE SchameB.PRC_GATHER_STATS AUTHID CURRENT_USER IS BEGIN SYS.DBMS_STATS.GATHER_TABLE_STATS('SchName', 'TableName', CASCADE => TRUE); END; /   select owner,table_name,last_analyzed,num_rows from dba_tables where owner='SYSTEM'

oracle 数据库统计信息收集

Statistic 对Oracle 是非常重要的. 它会收集数据库中对象的详细信息,并存储在相应的数据字典里. 根据这些统计信息, optimizer 可以对每个SQL 去选择最好的执行计划. 在9i 及之前的版本,在选择执行计划的时候会根据RBO(Rule-BasedOptimization)或者CBO来分析. 10g及以后版本只支持CBO(Cost-BasedOptimization).  优化器收集的统计信息包括如下内容:             1)Table statistics   

Greenplum 自动统计信息收集 - 暨统计信息不准引入的broadcast motion一例

标签 PostgreSQL , Greenplum , 统计信息 , 自动统计信息 , broadcast motion , 执行计划 背景 数据库执行计划的好坏,与数据库的SQL优化器息息相关.Greenplum有两套优化器,legacy query optimizer 与 ORCA. 这两个优化器都是CBO优化器,都需要依赖统计信息,如果统计信息不准确,可能生成的执行计划就不准确. 例如我们有一个这样的QUERY,发现怎么跑都跑不出来. 观察执行计划,发现有一个节点用到了broadcast

MS SQL 统计信息浅析上篇

统计信息概念     统计信息是一些对象,这些对象包含在表或索引视图中一列或多列中的数据分布有关的统计信息.数据库查询优化器使用这些统计信息来估计查询结果中的基数或行 数. 通过这些基数估计,查询优化器可以生成高质量的执行计划. 例如,查询优化器可以使用基数估计选择索引查找运算符而不是耗费更多资源的索引扫描运算符,从而提高查询性能.[参考MSDN]     其实如果你以前没有接触过统计信息,你可以将其看做是数据库为了得到最优的执行计划,统计数据库里面表.索引等对象的一些数据,例如表的记录数.所有

第十二章——SQLServer统计信息(3)——发现过期统计信息并处理

原文:第十二章--SQLServer统计信息(3)--发现过期统计信息并处理 前言:         统计信息是关于谓词中的数据分布的主要信息源,如果不知道具体的数据分布,优化器不能获得预估的数据集,从而不能统计需要返回的数据.         在创建列的统计信息后,在DML操作如insert.update.delete后,统计信息就会过时.因为这些操作更改了数据,影响了数据分布.此时需要更新统计信息.         在高活动的表中,统计信息可能几个小时就会过时.对于静态表,可能几个星期才会过

第十二章——SQLServer统计信息(2)——非索引键上统计信息的影响

原文:第十二章--SQLServer统计信息(2)--非索引键上统计信息的影响 前言:         索引对性能方面总是扮演着一个重要的角色,实际上,查询优化器首先检查谓词上的统计信息,然后才决定用什么索引.一般情况下,默认会在创建索引时,索引列上均创建统计信息.但是不代表在非索引键上的统计信息对性能没有用.         如果表上的所有列都有索引,那么将会是数据库负担不起,同时也不是一个好想法,包括谓词中用到的所有列加索引同样也不是好方法.因为索引会带来负载.因为需要空间存放索引,且每个D

第十二章——SQLServer统计信息(1)——创建和更新统计信息

原文:第十二章--SQLServer统计信息(1)--创建和更新统计信息 简介: 查询的统计信息: 目前为止,已经介绍了选择索引.维护索引.如果有合适的索引并实时更新统计信息,那么优化器会选择有用的索引供查询之用,因为SQLServer优化器是基于开销的优化.当在where和on上的列上的数据需要显示在结果集的时候,如果有实时的统计信息,优化器会选择最好的执行方式,因为优化器会从统计信息中获得这些数据的明细情况. 在创建索引的时候,SQLServer就会在索引列上创建统计信息.简单来说,统计信息