第十章-从statspack到ADDM

第十章-从statspack到ADDM

10.1STATSPACK概述

10.1.1数据库参数修改

为了能够顺利安装和运行statspack，可能需要设置以下两个系统参数

n         Job_queue_processes

为了能够建立自动任务，指向数据收集，该参数需要大于0.可以在初始化参数文件中修改这个参数修改（重启后依然有效），该参数可以在系统级动态修改（重启失效）

SQL> alter system set Job_queue_processes=6;

在9i后，如果使用spfile，可以指定修改范围，如both，这样修改在当前及数据库重启之后都保持有效

SQL> alter system set Job_queue_processes=6 scope=both;

n         Timed_statistics

设置该参数为True时，oracle将实时收集操作系统的计时信息，这些信息可被用来显示时间等统计信息，优化数据库和SQL语句。

10.1.2安装statspack

SQL>@spcreate

10.1.3spcreate的内容

10.1.4测试statspack

运行statspack.snap可以产生系统快照，运行两次，然后执行spreport.sql就可以生成基于两个时间点的报告。

SQL> excute statspack.snap

SQL> excute statspack.snap

SQL> @spreport.sql

10.1.5规划自动任务

使用spauto.sql来定义自动任务

 

10.1.6生成分析报告

调用spreport.sql可以生成分析报告

10.1.7移除定时任务

移除一个定时任务，可以如下操作

SQL> select job.log_user,priv_user,last_date,next_data,interval from user_jobs;

SQL> execute dbms_job.remove(‘22’);

10.1.8删除历史数据

删除stats$snapshot数据表中的相应数据，其他表中的数据会相应地级连删除：

10.1.9其他重要脚本

n         通过导出保存以及共享数据

n         删除数据

n         Oracle 92中新增的脚本

10.1.10调整statspack的收集门限

Statspack有两种类型收集选项：级别（level）和门限（threshold），其中级别用于控制收集数据的类型，门限用于设置收集的数据的阀值。

Statspack共有以下5类快照级别level，默认级别时level5

n         Level0：包含一般性能统计数据，如等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等。

n         level5：较之前级别增加了SQL语句信息，除了包括level0的所有内容，还包括SQL语句的收集，收集结果记录在stat$sql_summary中。

n         level6：从9i中开始引入，除了包含级别低的所有信息外，增加了SQL执行几乎部分信息

n          level7：从9i中开始引入，除了包含级别低的所有信息外，还增加了段级统计信息收集。

n         Level10：增加parent/children latch信息统计

可以通过statspack包修改缺省的级别设置：

SQL>excute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);

通过这样的设置，以后的收集级别都将是0级，如果只是向本次改变收集级别，可以忽略i_modify_parameter参数。

门限信息存储在stats$ statspack_parameter表中，各种门限说明如下：

n         Excutions_th:这是SQL语句执行的数量（默认值是100）

n         Disk_reads_tn:这是SQL语句执行的磁盘读入数量（默认值是1000）

n         Parse_calls_th:这是SQL语句执行的解析调用的数量（默认值是1000）

n         Buffer_gets_th:这是SQL语句执行的缓冲区获取的数量（默认值是10000）

任何一个门限值超过以上参数就会产生一条记录，通过调用statspack.modify_statspack_parameter函数就可以改变门限的默认值，例如：

SQL>excute statspack.modify_statspack_parameter(i_buffer_gets_th=>100000,i_disk_reads_th=>100000);

10.1.11 ORA-00001错误解决

这个错误一般是由于主键冲突导致的，通常的解决方法是可以禁用或删除唯一性约束，然后再创建一个非唯一性索引。

10.2statspack报告各部分说明

10.2.1 第一部分：数据库概要信息

报表开头部分是数据库概要信息，包含数据库的一些基本信息（数据库名称、版本号、主机等信息）和采样信息、数据库的Cache信息

n         首先是数据库名称、dbid等信息

n         接下来是数据库采样时段信息，这一部分记录了数据库采样的时间，以及采样点数。

n         Cache信息，这一部分列举了数据库的内存分配信息。

10.2.2第二部分：负载概要信息

n         SYSDIF函数

Statspack中的这些数据差值都时通过一个内部函数SYSDIF来获得的。

n         Redo size信息

在负载概要信息中首先出现的时redo size信息 单位为bytes：

n         逻辑读信息

逻辑读时指以任何模式进行数据块读取的逻辑读请求次数。

10.2.3第三部分：实例效率百分比

n         Buffer命中率

Buffer命中率来表示当进行数据访问时，在内存中找到数据的百分比，这个比率越高说明物理I/O就越少，所以通常期望这个比率是100%；如果这个比率过低，通常意味着buffer cache可能设置得过低，大量读操作都需要通过物理I/O访问来完成。

n         内存排序率

如果内存排序率过低，那么一定要引起注意，找到引发磁盘排序的SQL，看能否通过优化降低其磁盘排序，从而提高系统的性能。

n         软解析率

这个比率通常应该在99%以上。

n         执行分析比率

该值小于0通常说明shared pool 设置或效率存在问题，造成反复解析，reparse可能较严重或者可能同snapshot有关，如果该值为负值或者极低，通常说明数据库性能存在问题

n         分析CPU与分析时间比率(parse cpu to parse elapsd%)

Parse time cpu 代表在进行SQL解析的过程中所消耗的CPU时间；而parse time elapsed则代表整个SQL解析所消耗的时间。整个比率的期望值是100%，如果该值达到100%那么说明SQL的解析时间都消耗在CPU上，而不是浪费在其他等待上；如果分析时间远远大于cpu时间，则说明在其他方面可能存在竞争或等待，比如获得字典信息的物理I/O访问等。

10.2.4第四部分：数据库的响应时间

通常响应时间是用户衡量系统性能的重要指标，响应时间由两部分组成，一部分是服务时间，一部分是等待时间，在这里服务时间是指花在CPU上的时间；等待时间是花费在等待事件上的总的时间。

10.2.5第五部分：详细信息

10.3整理分析结果

10.3.1物理读写IO操作

10.3.2buffer命中率

10.4最重要的九大性能视图

n         和session相关的主要视图v$session->v$session_wait

v$session视图记录了当前连接session的信息，这些信息包括用户名、连接主机、session正在执行的SQL的SQL_ADDRESS、SQL_HASH_VALUE等，非常详尽。v$session_wait则记录了当前连接session正在等待的资源信息。在10g中，oracle将v$session_wait视图的内容并入v$session视图。

n         和session级统计信息相关的视图有v$sessstat->v$sysstat

v$sysstat视图记录了session的统计信息，这些统计信息包括诸如session的逻辑数据读取、物理数据读取、排序操作等。v$sessstat收集的信息同时会累计进入v$sysstat视图，v$sessstat视图记录的是整个数据库系统的统计信息。

通过v$sysstat可以对当前连接运行的session信息进行获取和分析；通过v$sysstat则可以对数据库启动以来的运行状况获得整体印象。

n         和等待事件相关的主要视图v$session_event->v$system_event

v$session_event记录了当前连接session的等待事件，这些信息最终被累计进入v$system_event视图，v$system_event记录的是整个数据库系统自数据库启动以来的等待信息汇总。

 

最后列举下eygle对这个问题的答案

n         v$session->v$session_wait = oracle 10g v$session

n         v$sysstat

n         v$system_event

n         v$process

n         v$sql

n         v$sqltext

n         v$lock

n         v$latch_children

n         v$bh

10.5               session历史信息的记录

10.6               ASH新特性的引入

从10g开始，oracle引入了ASH新特性，也就是活动session历史信息记录。

10.6.1 ASH概述

ASH以v$session为基础，每秒采样一次，记录活动会话等待的事件。因为记录所有会话的活动是非常昂贵的，所以不活动的会话不会被采样，采样工作由后台进程MMNL来完成。

是否启用ASH功能，受一个内部隐含参数控制：

SQL>@GetHparDes.sql

而采样时间同样由另一个内部隐含参数决定：

SQL>@GetHparDes.sql

10.6.2ASH报告

生成ASH报告主要可以通过两种方式

n         脚本方式

n         EM图像方式

10.7自动负载信息库（AWR）的引入

内存中记录的ASH信息始终是有限的，为了保存历史数据，这些信息最终需要写入磁盘。这些历史信息的存储，引出了oracle 10g的另外一个新特性：自动负载信息库。

10.7.1AWR概述

AWR缺省地被安装到oracle 10g数据库中，用于收集关于该特定数据库的操作统计信息和其他统计信息。Oracle以固定的时间间隔为其所有重要统计信息和负载信息执行一次快照，并将这些快照存储在AWR中，这些信息在AWR中保留给定的时间，然后清除。

AWR的采样间隔及信息保留等信息可以通过dba_hist_wr_control视图查询得到：

AWR的行为受到数据库另外一个重要初始化参数STATISTICS的影响，该参数有以下3个可选项

n         BASIC：设置为BASIC时，AWR的统计信息收集和所有自我调整的特性都被关闭

n         TYPICAL:设置为TYPICAL时，数据库收集部分统计信息，这些信息为典型的数据库监控需要，是数据库的缺省设置

n         ALL：所有可能的统计信息都被收集

 

10.7.2AWR报告的生成

根据AWR记录的数据，我们可以通过报告来展现这些信息。报告可以通过运行脚本生成类似statspack report的AWR报告，也可以通过package直接输出。脚本位于$ORACLE_HOME/rdbms/admin/awrrpt.sql,报表可以通过两种形式输出：TEXT和HTML。

10.7.3AWR报告的分析

10.7.4通过EM生成AWR报告

10.8自动数据库诊断监控（ADDM）的引入

有了这个AWR数据仓库后，oracle 10g引入了另外一个功能：自动数据库诊断监控程序。通过ADDM，oracle试图使数据库的维护、管理和优化工作变得更加自动和简单。

10.8.1ADDM概述

ADDM可以定期检查数据库的状态，根据内建的专家系统，自动确定潜在的数据库性能瓶颈，并提供调整措施和建议。由于这一切都是内建在oracle数据库系统之内的，其执行效率很高，几乎不影响数据库的总体性能。对于一个运行的数据库系统，在诊断时ADDM首先分析整个系统，然后给出诊断概要，接着ADDM或者会直接建议调整或者推荐你进一步向其他科目的专家“问诊”。

10.8.2ADDM报告的生成

ADDM的诊断报告可以通过脚本调用来生成，该脚本位于$ORACLE_HOME/rdbms/admin/addmrpt.sql

10.8.3使用EM生成ADDM报告

10.9理解等待事件