10G新特性 - AWR

最新推荐文章于 2020-06-29 17:09:43 发布

转载最新推荐文章于 2020-06-29 17:09:43 发布 · 92 阅读

使用10G新特性来收集数据库性能统计和度量数据来分析和调优。显示数据的确切执行时间，以及保存的会话消息。
　　10G的性能分析新特性
　　当数据库发生了性能问题时，如何去定位？比较常用的方法是采用一个既定的模式：处理诸如“是不是同一问题的再现？”、“能否在某一特殊时间段发生？”、“两个问题之间能否具有联系？”等问题，这样通常能得到一个比较好的诊断结果。做为一个DBA，你可能使用一个第三方或者本人开发的工具来收集数据库运行期间的精细统计数据，并从中得到性能度量数据。你需要将这些发生问题时的度量数据与当前数据进行比较。重现以前的时间能使现在的问题变得明朗。因而，持续的收集相关统计数据对于性能分析来说十分重要。在某些情况下，在处理收集统计数据这方面的问题上有本人内置的工具——statspack。虽然在某些情况下的做用非常大，但它缺乏处理性能问题所必须的健壮性。提供了一个标志性的改进特性：自动工做量存储（Automatic Workload Repository AWR）。AWR是随着数据库一起被安装的，它不只能收集统计数据，还能从统计数据中分析出度量数据。
　　通过运行$ORACLE_HOME/rdbms/admin目录下的awrrpt.sql能够生产AWR从统计和度量数据中分析演讲。这个分析演讲最能体现出AWR的性能分析能力。这个脚本看起来很像statspack，它会列出所有可用的AWR快照并要求输入两个特定的快照编号做为一个间隔段。它能产生两种类型的输出：文本格式（除了AWR统计消息外和statspack演讲基本类似）和默认的格式（通过超连接等方式来提供一个友好的界面）。下面来运行以下这个脚本，对它产生的分析演讲及AWR的性能分析能力做一个认识。

　　AWR的使用
　　首先来了解一下AWR是如何设想的，并了解一下它的构造。基本上来说，AWR应该是一个Oracle用来收集性能相关统计数据并从中得出性能度量数据来追踪潜在问题的内置工具。和statspack不一样，AWR的快照消息是由一个新的后台进程MMON及其线程来每隔一个小时自动收集的。为了节省空间，这些收集的数据会在7天后自动清除。快照收集的频次和保留时间都是能够被用户修改的。能够通过以下脚本查看当前的设置： SQL> select snap_interval, retention from dba_hist_wr_control;
　　　SNAP_INTERVAL RETENTION
　　　------------------- -------------------
　　　+00000 01:00:00.0 +00007 00:00:00.0
　　这个结果表明当前的快照是每隔一个小时收集一次，并且会被保留7天。要改变这个设置，比如需要设置成每隔半小时收集一次，并且只保留3天，能够使用以下语句（参数的单位都是分）： SQL> begin
　　　2 dbms_workload_repository.modify_snapshot_settings (
　　　3 interval => 30,
　　　4 retention => 3*24*60
　　　5 );
　　　6 end;
　　　SQL> select snap_interval, retention from dba_hist_wr_control;
　　　SNAP_INTERVAL RETENTION
　　　------------------- -------------------
　　　+00000 00:30:00.0 +00003 00:00:00.0
　　AWR使用多个表来存储收集的统计数据，它们都被放置在SYS这个方案中，存储在一个新的特殊表空间SYSAUX上，并且以WRM$_*和WRH$_*的格式存储。前面一种格式的表存储诸如数据库检查和采集的快照等元数据消息，而后面一种格式的表存储了实际收集的统计数据（M表示“Metadata元数据”，H表示“Historical历史”）。另外还有多个以“DBA_HIST_”为前缀，由这些表构造出的视图。你能够利用这些视图写出本人的性能分析工具。这些视图的命名与它相关的表间接相关。比如，视图DBA_HIST_SYSMETRIC_SUMMAY是以表WRH$_SYSMETRIC_SMMURY为基础构造的。
　　AWR的历史消息表捕捉了比statspack多得多的消息，包括表空间的使用情况、文件系统的使用情况、以至操做系统的统计消息。能够用以下语句从数据字典中得到这些表的完整列表： select view_name from user_views where view_name like 'DBA\_HIST\_%' escape '\';
　　视图DBA_HIST_METRIC_NAME定义了AWR收集的重要度量数据、它们所属哪个组以及他们实在哪个单元被收集的。下面是一条记录例子： DBID : 4133493568
　　　GROUP_ID : 2
　　　GROUP_NAME : System Metrics Long Duration
　　　METRIC_ID : 2075
　　　METRIC_NAME : CPU Usage Per Sec
　　　METRIC_UNIT : CentiSeconds Per Second
　　这个数据显示了一个隶属于 “系统长期度量数据”的度量数据组中的“每秒的厘秒数”单元的“CPU每秒使用情况”的度量项。这条记录能够和其他表如“DBA_HIST_SYSMETRIC_SUMMARY”联合查询来起做用： SQL> select begin_time, intsize, num_interval, minval, maxval, average,
　　　standard_deviation sd
　　　from dba_hist_sysmetric_summary where metric_id = 2075;
　　　BEGIN INTSIZE NUM_INTERVAL MINVAL MAXVAL AVERAGE SD
　　　----- ---------- ------------ ------- ------- -------- ----------
　　　11:39 179916 30 0 33 3 9.81553548
　　　11:09 180023 30 21 35 28 5.91543912
　　　… …
　　这显示的是以厘秒为单位的CPU消耗时间。在分析数据中的标准偏差（Standard Deviation SD）能够协助我们来确定平均数据图能否反映实际工组负荷。在第一条记录中，平均值是每秒钟CPU消耗3厘秒，而标准偏差是9.81，这说明平均为3并没有反映出实际工做负荷。在第二条记录中，平均值是28，而标准偏差是5.9，所以这条记录更具代表性。这种类型的消息有助于协助理解在性能度量中的几个环境参数的做用。　使用这些统计数据
　　上面我们了解了AWR是如何收集统计数据的，下面就来了解以下如何利用这些数据。大多数性能问题并非孤立的，但是也不要相信哪些能够找出问题的最终根源的流言。让我们来做一个典型的调优练习：你发觉系统变得很慢，决定检查一下等待事件。通过检查发觉，“缓存忙等待（buffer busy wait）”非常高。如何处理这个问题呢？具有几种可能：可能是索引的单一增长引起的；某张表饱和了，需要立即转载一个数据块到内存中；以及其他的原因引起的。在任何情况下，你都需要先定位出发生问题的段。如果它是一个索引段，你能够决定能否重建索引、把索引改为相反键索引、或者将索引转换为在Oracle 10G特有的哈希分区索引。如果是一张表，能够考虑修改表的存储参数使它密度降低，或者将它转移到一个自动段空间管理的表空间上去。你的这些计划、措施一般都是系统的，并且是基于你对各种事件的了解和你在处理这些问题所积累的经验。想向一下，如果这些事情是由机器驱动来完成——这个驱动能捕捉度量数据并且在基于预先定义的逻辑能演绎出可能的计划、措施，那么你的工做不是能变得很轻松吗？
　　现在Oracle 10G就提供了这样的驱动，它就是自动数据库诊断监视器（Automatic Database Diagnostic Monitor ADDM）。ADDM使用AWR收集的数据来达到那样的效果。在上述的例子中，ADDM能够发觉发生了buffer busy waits，找出适当的数据来检查在哪个段上面发生的，计算出它的本来数据和混合数据，并最终为DBA提供处理办法。每当AWR收集了一个快照数据，ADDM就会检查这些度量数据，并产生出相应建议。因而，你就拥有了一个全天候工做的机器人DBA来为你分析数据、提前为你给出建议，让你由更多的时间来关心战略问题。通过使用新的10G企业管理器平台——DB Home——能够查看ADDM的建议和AWR存储的数据。你能够从管理界面的导航器上查看AWR的演讲、负荷数据以及快照消息。将来能够安装更多组件来在更多细节上来检查ADDM。
　　你还能够指定在特定条件下产生告警消息。这些告警，如服务器产生的告警（Server Generated Alerts），会被推入一个高级队列。在任意一个客户端上能够监听这个队列。一种客户端就是10G企业管理器，在上面能够显著的显示出告警消息。
　　时间模型
　　当你遇到一个性能问题时，首先想起降低哪个响应时间呢？你当然希望能消除或降低引起问题的最终因素的时间。但是你怎么才能知道时间被消耗在哪呢——不是等待，而是实际的工做时间？
　　Oracle 10G引见了使用时间模型来通过不同途径定位时间消耗。整个系统的时间消耗被记录在视图V$SYS_TIME_MODEL中。下面是一个对这个视图查询的结果： STAT_NAME VALUE
　　　------------------------------------- --------------
　　　DB time 58211645
　　　DB CPU 54500000
　　　background cpu time 254490000
　　　sequence load elapsed time 0
　　　parse time elapsed 1867816
　　　hard parse elapsed time 1758922
　　　sql execute elapsed time 57632352
　　　connection management call elapsed time 288819
　　　failed parse elapsed time 50794
　　　hard parse (sharing criteria) elapsed time 220345
　　　hard parse (bind mismatch) elapsed time 5040
　　　PL/SQL execution elapsed time 197792
　　　inbound PL/SQL rpc elapsed time 0
　　　PL/SQL compilation elapsed time 593992
　　　Java execution elapsed time 0
　　　bind/define call elapsed time 0
　　注意DB Time这个统计项，它表明了自从实例启动后数据库消耗的时间。重新运行查询这个视图的语句，数据库消耗时间的数据将和之前不同。通过一轮调优，再做同样的分析，能够看出调优后的DB Time的改变，通过和第一的数据比较发生的变化，能够检查调优对于数据库时间产生的影响。除了数据库时间，视图V$SYS_TIME_MODEL还能显示其他很多统计数据，如消耗在不同类型的语句分析（Parsing）上的时间，以至PL/SQL的编译时间。
　　这个视图显示的整个系统的时间模型。但是你可能对更细粒度上的视图感兴趣：会话级的时间模型。视图V$SESS_TIME_MODEL能显示在会话级捕捉到的时间统计数据。这些数据统计的是当前的会话，包括所有的活动的和不活动的都可见。多出的字段SID表明了所统计的会话的SID。
　　在Oracle的以前版本，这些数据根本无法获取到，需要用户从各种其他数据中猜测出来。在Oracle 10g中，获取这些数据几乎是小菜一碟。活动会话历史
　　视图V$SESSION在oracle 10G中被增强了，其中最有价值的一项增强就是包括了等待时间和他们持续的时间，而不需要通过V$SESSION_WAIT来查看了。然而，因为这个视图很少反映出真实的时间值，所以一些重要消息就丢失了。例如，如果你从这个视图中查询看能否具有某个会话在等待某个非空闲的事件，而如果这个事件的数据具有问题，你将无法找到你想要的东西，因为等待事件必须依赖于你所查询到的时间数据。Oracle 10G的另一个特性活动会话历史（Active Session History ASH）和AWR类似，将会话的性能统计数据存储在一个缓存中以便于将来的分析。但是，和AWR不一样的是，这些数据的存储并非永久的存储在表当中，而是具有内存当中，能够通过视图V$ACTIVE_SESSION_HISTORY来查到。这些数据每秒中被收集一次，并且只有哪些活动的会话才会被收集。随着时间的推进，老的数据被移出、新的数据被收集到内存，如此循环。为了找到有多少会话在等待某些事件，能够使用以下脚本： select session_id||','||session_serial# SID, n.name, wait_time,
　　　time_waited
　　　from v$active_session_history a, v$event_name n
　　　where n.event# = a.event#
　　这条语句的执行结果能够显示出事件的名称和花费了多少事件等待。增加ASH的字段能够帮你对某个特定的等待事件进行深入定位。例如，如果这些会话等待的事件中有一个是buffer busy wait，那就必须再做适当的诊断来定位是在哪个段上发生了等待事件。你能够通过将ASH视图中的CURRENT_OBJ#字段与DBA_OBJECTS连接查询来查到发生问题的段。
　　ASH还记录了并行查询服务的会话消息，这些消息对于诊断并行查询的等待事件很有用。如果记录的是并行查询的从进程的消息，协同服务会话的SID会被表示在QC_SESSION_ID字段中。字段SQL_ID记录了产生等待事件的SQL语句的ID，通过将它与视图V$SQL联合查询，能够找出这个令人讨厌的SQL语句。CLIENT_ID能够使在如web应用这样的共享用户环境中更容易定位是哪个客户端，这个字段能够通过存储过程DBMS_SESSION.SET_IDENTIFIER来设置。
　　既然ASH的消息如此有价值，那么不是把它的数据像AWR一样永久的存储起来不是更好吗？MMON进程会将这些消息存储到磁盘以服务于AWR表，并且能够通过视图DBA_HIST_ACTIVE_SESS_HISTORY来查询。
　　手工收集
　　在默认情况下，这些快照消息是自动收集的。但是你也能够随时手工收集。所有的AWR的功能都能够通过包DBMS_WORKLOAD_REPOSITORY来实现。要产生一个快照，只需执行：exec dbms_workload_repository.create_snapshot就能够了。
　　这样会立即产生一个快照记录在表WRM$_SNAPSHOT中，并且在典型（TYPICAL）级别上收集度量数据。如果需要收集更细的统计数据，能够在上述存储过程执行时设定参数FLUSH_LEVEL为ALL。统计数据的删除也是自动的，但也能够通过执行存储过程drop_snapshot_range()来手工删除。
　　基准线
　　一个典型的性能调优过程时从收集一个度量数据集的基准线开始，然后调整，再收集另一个基准线集。通过比较这两个基准数据集来观察调整产生的效果。在AWR中，能够通过已经具有的多个快照做处理来进行类似的推理。假设一个名叫apply_interest的显著产生性能压力的进程在下午1：00到3：00之间运行，相应的快照ID是从56到59，我们能够用以下存储过程为这些快照定一个名叫apply_interest_1的基准线： exec dbms_workload_repository.create_baseline(56,59,’apply_interest_1’);
　　这一操做标识了从56到59的快照做为名为“apply_interest_1”的基准线的一部分。
　　用以下语句检查已经具有的基准线： SQL> select * from dba_hist_baseline;
　　　DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID
　　　---------- ------------- -----------
　　　4133493568 1 apply_interest_1 56 59
　　经过一些调优步骤，我们再创建另外一个基准线，名叫“apply_interest_2”，并比较与仅与两个基准线相关的快照的度量数据。像这样将一些快照独立成这样一些基准线能协助了解性能调优产生的效果。分析完毕后，能够通过调用存储过程drop_baselin()来删除这些基准线，而快照还是会被保留。同样的，当清除规则需要清除掉旧的快照消息时，与这些旧快照消息相关的基准线不会被清除，以便于以后的进一步深入分析。