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

简介: 1.2自动工作负载库(AWR)概览    AWR收集、处理并维护性能统计信息以用来侦测问题和自我调优。这些数据同时存储在内存和数据库中。收集的数据既可以呈现在报告中,又可以从视图中查询。
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强烈建议不要关闭自动快照收集功能。

相关文章
|
存储 Oracle 关系型数据库
Oracle优化07-分析及动态采样-DBMS_STATS 包
Oracle优化07-分析及动态采样-DBMS_STATS 包
135 0
Oracle优化07-分析及动态采样-DBMS_STATS 包
|
存储 关系型数据库 MySQL
本机表'performance_schema''???' 结构错误
本机表'performance_schema''???' 结构错误
203 0
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
|
SQL 监控 关系型数据库
参数performance_schema设置最佳实践
最早开源MySQL从5.5开始支持performance_schema(下文简称PFS),又在后续版本不断持续完善、优化,PFS已经成为了性能诊断优化的利器,使SQL问题、锁等待事件等比较清晰地展现出来,但打开PFS也会带来相应的性能成本,本篇就来看下PFS相比其他工具及不打开PFS的性能差异。
参数performance_schema设置最佳实践