转：Oracle里几组重要的视图--v$sysstat，v$system_event，v$parameter v$system_parameter

按组分的几组重要的性能视图

1。System 的 over view

v$sysstat , v$system_event  , v$parameter,V$instance得到oracle_sid

2。某个session 的当前情况

v$process , v$session , v$session_wait  ,v$session_event ,  v$sesstat ---sid

3。SQL 的情况

v$sql , v$sqlarea , v$SQL_PLAN , V$SQL_PLAN_STATISTICS, v$sqltext_with_newlines

4. Latch / lock /ENQUEUE

v$latch , v$latch_children , v$latch_holder , v$lock ,V$ENQUEUE_STAT ,V$ENQUEUE_LOCK

5. IO 方面的

v$segstat , v$filestat , v$tempstat ,v$datafile , v$tempfile

6.shared pool / Library cache

v$Librarycache , v$rowcache , x$ksmsp

7.几个advice也不错

v$db_cache_advice , v$PGA_TARGET_ADVICE, v$SHARED_POOL_ADVICE

1 v$sysstat

按照OracleDocument中的描述，v$sysstat存储自数据库实例运行那刻起就开始累计全实例(instance-wide)的资源使用情况。

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：

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';
0.988405941846607

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)';
0.934634491323697

In-memory sort ratio：

该项显示内存中完成的排序所占比例。最理想状态下，在OLTP系统中，大部分排序不仅小并且能够完全在内存里完成排序

公式：sorts (memory) / ( sorts (memory) + sorts (disk) )
执行：
select a.value/(b.value+c.value) 
  from v$sysstat a,v$sysstat b,v$sysstat c 
  where a.name='sorts (memory)' and 
         b.name='sorts (memory)' and c.name='sorts (disk)';
1

Parse to execute ratio：

在生产环境，最理想状态是一条sql语句一次解析多数运行。

公式：1 - (parse count/execute count)
执行：
select 1-(a.value/b.value) 
  from v$sysstat a,v$sysstat b 
where a.name='parse count (total)' and b.name='execute count';
0.532090005755152

Parse CPU to total CPU ratio：

该项显示总的CPU花费在执行及解析上的比率。如果这项比率较低，说明系统执行了太多的解析。

公式：1 - (parse time cpu / CPU used by this session)
执行：
select 1-(a.value/b.value) 
  from v$sysstat a,v$sysstat b 
  where a.name='parse time cpu' and
         b.name='CPU used by this session';
0.813145773683555

Parse time CPU to parse time elapsed

通常，该项显示锁竞争比率。这项比率计算

是否时间花费在解析分配给CPU进行周期运算(即生产工作)。解析时间花费不在CPU周期运算通常表示由于锁竞争导致了时间花费

公式：parse time cpu / parse time elapsed
执行：
     select a.value/b.value 
  from v$sysstat a,v$sysstat b 
  where a.name='parse time cpu' and b.name='parse time elapsed';
0.124301502545635

从V$SYSSTAT获取负载间档(Load Profile)数据

　　负载间档是监控系统吞吐量和负载变化的重要部分，该部分提供如下每秒和每个事务的统计信息：logons cumulative, parse count (total), parse count (hard), executes, physical reads, physical writes, block changes, and redo size

　　被格式化的数据可检查'rates'是否过高，或用于对比其它基线数据设置为识别system profile在期间如何变化。例如，计算每个事务中block changes可用如下公式：

db block changes / ( user commits + user rollbacks )

执行：

select a.value/(b.value+c.value) 
  from v$sysstat a,v$sysstat b,v$sysstat c 
  where a.name='db block changes' and
         b.name='user commits' and c.name='user rollbacks';
401.471444568869

其它计算统计以衡量负载方式，如下：

l Blocks changed for each read：这项显示出block changes在block reads中的比例。它将指出是否系统主要用于只读访问或是主要进行诸多数据操作(如：inserts/updates/deletes)

公式：db block changes / session logical reads
执行：
   select a.value/b.value 
  from v$sysstat a,v$sysstat b 
  where a.name='db block changes' and 
         b.name='session logical reads' ;
0.0894529709078361
Rows for each sort：
公式：sorts (rows) / ( sorts (memory) + sorts (disk) )
执行：
  select a.value/(b.value+c.value) 
  from v$sysstat a,v$sysstat b,v$sysstat c 
  where a.name='sorts (rows)' and 
         b.name='sorts (memory)' and c.name='sorts (disk)';
86.1900138446878

2 v$system_event

本视图概括了实例各项事件的等待信息。v$session_wait显示了系统的当前等待项，v$system_event则提供了自实例启动后各个等待事件的概括。常用于获取系统等待信息的历史影象。而通过两个snapshot获取等待项增量，则可以确定这段时间内系统的等待项。

V$SYSTEM_EVENT中的常用列

　　l EVENT:等待事件名称

　　l TOTAL_WAITS：此项事件总等待次数

　　l TIME_WAITED：此项事件的总等待时间(单位：百分之一秒)

　　l AVERAGE_WAIT：此项事件的平均等待用时(单位：百分之一秒)(time_waited/total_waits)

　　l TOTAL_TIMEOUTS：此项事情总等待超时次数

示例：
1.查看系统的各项等待，按总耗时排序
SELECT event,total_waits waits,total_timeouts timeouts,
       time_waited total_time,average_wait avg
  FROM V$SYSTEM_EVENT
 ORDER BY 4 DESC;

SQL*Net message from client

rdbms ipc message

DIAG idle wait

Space Manager: slave idle wait

SQL*Net message from client等待事件不一定就可以被忽略,也不一定就是因为网络问题。

在每次的database call之间就存在着SQL*Net message from client等待事件,也是作者所说的一种between database call等待事件,当出现大量的不必要的database call的时候,虽然单独的每个SQL*Net message from client等待事件时间间隔很短,但大量的database call累计起来导
致SQL*Net message from client成为分析案例的最主要的等待事件,显然这里的SQL*Net message from client等待时间导致response time很大,它显然不能被忽略不计,它也不是因为网络问题,而是因为存在大量不必要的database call，作者的解决方案就是：通过使用绑定变量,将parse移到循环外部,以及使用array fetch,bulk insert等减少database call的次数,从而减少response time

比如，通过checkpoint completed、log file switch（checkpoint incomplete）可以查看检查点进程的性能。通过log file parallel write、log file switch completed可以查看联机重做日志文件的性能。通过log file switch（archiving needed）事件可以检查归档进程的性能。

找出瓶颈：

1。通过Statspack列出空闲事件。

2。检查不同事件的等待时间开销。

3。检查每条等待记录的平均用时，因为某些等待事件(比较log file switch completion)可能周期性地发生，但发生时却造成了严重的性能损耗。

select sid,event,P1TEXT,state from v$session_wait where event not in ('SQL*Net message from client');

查询一下当前系统的进程数量

[root@oracle12c ~]# ps -ef|grep ora|wc -l

83

[root@oracle12c ~]# ps -ef|grep ora|wc -l

83

   select sid,event,p1,p1text from v$session_wait;

3 v$parameter v$system_parameter

这两个视图列出的各参数项名称以及参数值。V$PARAMETER显示执行查询的session的参数值。V$SYSTEM_PARAMETER视图则列出实例的参数值。

例如，下列查询显示执行查询的session的SORT_AREA_SIZE参数值：

V$PARAMETER中的常用列：

　　l NAME：参名

　　l VALUE：参值(session或实例)

　　l ISDEFAULT：参值是否默认值

　　l ISSES_MODIFIABLE：此参数是否session级可修改

　　l ISSYS_MODIFIABLE：此参数在实例启动后是否可由实例修改

　　l ISMODIFIED：自实例启动起，参值是否被修改，如果被修改，session级或是实例(系统)级修改(如果执行一条alter session,则值将被MODIFIED，如果执行的是alter system，则值为SYS_MODIFIED)

　　l ISADJUSTED：

　　l DESCRIPTION：参数简要描述

　　l UPDATE_COMMENT：由dba提供的参数说明

使用v$parameter以及v$system_parameter数据：

在调优期间通过查询v$parameter以确认当前参数设置。例如，如果buffer cache hit ratio较低，那么通过查询DB_BLOCK_BUFFERS(或DB_CACHE_SIZE)可以明确当前的buffer cache大小。

 SELECT name, value, isdefault, isses_modifiable, issys_modifiable, ismodified
  FROM V$PARAMETER
 WHERE name = 'sort_area_size';

前例显示了SORT_AREA_SIZE初始参数在实例启动时并非初始值，不过被session修改回了初始值。

注意：当查询v$parameter时要注意，如果你想查看实例参数，要查询v$system_parameter。