oracle 性能
学习Oracle动态性能表-(3)-V$SYSSTAT
按照 OracleDocument中的描述， v$sysstat存储自数据库实例运行那刻起就开始累计全实例 (instance-wide)的资源使用情况。
类似于 v$sesstat ，该视图存储下列的统计信息：
1>.事件发生次数的统计 (如： user commits)
2>.数据产生，存取或者操作的 total列 (如： redo size)
3>.如果 TIMED_STATISTICS值为 true,则统计花费在执行操作上的总时间 (如： CPU used by this session)
v$sysstat 视图常用列介绍：
l STATISTIC#: 标识
l NAME: 统计项名称
l VALUE: 资源使用量
该视图还有一列 class-统计类别但极少会被使用，各类信息如下：
1 代表事例活动
2 代表 Redo buffer活动
4 代表锁
8 代表数据缓冲活动
16 代表 OS活动
32 代表并行活动
64 代表表访问
128 代表调试信息
注意： Statistic#的值在不同版本中各不相同，使用时要用 Name做为查询条件而不要以 statistic#的值做为条件。
使用 v$sysstat 中的数据
该视图中数据常被用于监控系统性能。如 buffer cache命中率、软解析率等都可从该视图数据计算得出。
该视图中的数据也被用于监控系统资源使用情况，以及系统资源利用率的变化。正因如此多的性能数据，检查某区间内系统资源使用情况可以这样做，在一个时间段开始时创建一个视图数据快照，结束时再创建一个，二者之间各统计项值的不同 (end value - begin value)即是这一时间段内的资源消耗情况。这是 oracle工具的常用方法，诸如 Statspack以及 BSTAT/ESTAT都是如此。
为了对比某个区间段的数据，源数据可以被格式化（每次事务，每次执行，每秒钟或每次登陆），格式化后数据更容易从两者中鉴别出差异。这类的对比在升级前，升级后或仅仅想看看一段时间内用户数量增长或数据增加如何影响资源使用方面更加实用。
你也可以使用 v$sysstat数据通过查询 v$system_event视图来检查资源消耗和资源回收。
V$SYSSTAT 中的常用统计
V$SYSSTAT中包含多个统计项，这部分介绍了一些关键的 v$sysstat统计项，在调优方面相当有用。下列按字母先后排序：
数据库使用状态的一些关键指标：
l CPU used by this session：所有 session的 cpu占用量，不包括后台进程。这项统计的单位是百分之 x秒 .完全调用一次不超过 10ms
l db block changes：那部分造成 SGA中数据块变化的 insert,update或 delete操作数 这项统计可以大概看出整体数据库状态。在各项事务级别，这项统计指出脏缓存比率。
l execute count：执行的 sql语句数量 (包括递归 sql)
l logons current：当前连接到实例的 Sessions。如果当前有两个快照则取平均值。
l logons cumulative：自实例启动后的总登陆次数。
l parse count (hard)：在 shared pool中解析调用的未命中次数。当 sql语句执行并且该语句不在 shared pool或虽然在 shared pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条 sql语句原文与当前存在的相同，但查询表不同则认为它们是两条不同语句，则硬解析即会发生。硬解析会带来 cpu和资源使用的高昂开销，因为它需要 oracle在 shared pool中重新分配内存，然后再确定执行计划，最终语句才会被执行。
l parse count (total)：解析调用总数，包括软解析和硬解析。当 session执行了一条 sql语句，该语句已经存在于 shared pool并且可以被使用则产生软解析。当语句被使用 (即共享 ) 所有数据相关的现有 sql语句 (如最优化的执行计划 )必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。
l parse time cpu：总 cpu解析时间 (单位： 10ms)。包括硬解析和软解析。
l parse time elapsed：完成解析调用的总时间花费。
l physical reads： OS blocks read数。包括插入到 SGA缓存区的物理读以及 PGA中的直读这项统计并非 i/o请求数。
l physical writes：从 SGA缓存区被 DBWR写到磁盘的数据块以及 PGA进程直写的数据块数量。
l redo log space requests：在 redo logs中服务进程的等待空间，表示需要更长时间的 log switch。
l redo size： redo发生的总次数 (以及因此写入 log buffer)，以 byte为单位。这项统计显示出 update活跃性。
l session logical reads：逻辑读请求数。
l sorts (memory) and sorts (disk)： sorts(memory)是适于在 SORT_AREA_SIZE(因此不需要在磁盘进行排序 )的排序操作的数量。 sorts(disk)则是由于排序所需空间太大， SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算 in-memory sort ratio。
l sorts (rows): 列排序总数。这项统计可被 'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。
l table fetch by rowid：使用 ROWID返回的总列数 (由于索引访问或 sql语句中使用了 'where rowid=&rowid'而产生 )
l table scans (rows gotten)：全表扫描中读取的总列数
l table scans (blocks gotten)：全表扫描中读取的总块数，不包括那些 split的列。
l user commits + user rollbacks：系统事务起用次数。当需要计算其它统计中每项事务比率时该项可以被做为除数。例如，计算事务中逻辑读，可以使用下列公式： session logical reads / (user commits + user rollbacks)。
注： SQL语句的解析有软解析 soft parse与硬解析 hard parse之说，以下是 5个步骤：
1：语法是否合法 (sql写法 )
2：语义是否合法 (权限，对象是否存在 )
3：检查该 sql是否在公享池中存在
-- 如果存在 ,直接跳过 4和 5,运行 sql. 此时算 soft parse
4：选择执行计划
5：产生执行计划
-- 如果 5个步骤全做 ,这就叫 hard parse.
注意物理 I/O
oracle报告物理读也许并未导致实际物理磁盘 I/O操作。这完全有可能因为多数操作系统都有缓存文件，可能是那些块在被读取。块也可能存于磁盘或控制级缓存以再次避免实际 I/O。 Oracle报告有物理读也许仅仅表示被请求的块并不在缓存中。
由 V$SYSSTAT 得出实例效率比 (Instance Efficiency Ratios)
下列是些典型的 instance efficiency ratios 由 v$sysstat数据计算得来，每项比率值应该尽可能接近 1：
l Buffer cache hit ratio ：该项显示 buffer cache大小是否合适。
公式： 1-((physical reads-physical reads direct-physical reads direct (lob)) / session logical reads)
执行：
select 1 -((a. value -b. value -c. value )/d. value )
from v$sysstat a,v$sysstat b,v$sysstat c,v$sysstat d
where a. name = 'physical reads' and
b. name = 'physical reads direct' and
c. name = 'physical reads direct (lob)' and
d. name = 'session logical reads' ;
l Soft parse ratio ：这项将显示系统是否有太多硬解析。该值将会与原始统计数据对比以确保精确。例如，软解析率仅为 0.2则表示硬解析率太高。不过，如果总解析量 (parse count total)偏低，这项值可以被忽略。
公式： 1 - ( parse count (hard) / parse count (total) )
执行：
select 1 -(a. value /b. value )
from v$sysstat a,v$sysstat b
Where a. name = 'parse count (hard)' and b. name = 'parse count (total)' ;