Oracle学习动态性能表

本视图列出系统上的每个事务处理所获得的所有锁。

V$LOCKED_OBJECT中的列说明：

XIDUSN：回滚段号
XIDSLOT：槽号
XIDSQN：序列号
OBJECT_ID：被锁对象ID
SESSION_ID：持有锁的sessionID
ORACLE_USERNAME：持有锁的Oracle 用户名
OS_USER_NAME：持有锁的操作系统 用户名
PROCESS：操作系统进程号
LOCKED_MODE：锁模式，值同上表1

示例：1.以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：
select object_id,session_id,locked_mode from v$locked_object;

select t2.username, t2.sid, t2.serial#, t2.logon_time
from v$locked_object t1, v$session t2
where t1.session_id = t2.sid order by t2.logon_time;

如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁：

alter system kill session 'sid,serial#';

 

 

Oracle 学习动态性能表 v$locked

V$LOCK这个视图列出Oracle 服务器当前拥有的锁以及未完成的锁或栓锁请求。如果你觉着session在等待等待事件队列那你应该检查本视图。如果你发现session在等待一个锁，那么按如下先后顺序：

使用V$LOCK找出session持有的锁。
使用V$SESSION找出持有锁或等待锁的session执行的sql语句。
使用V$SESSION_WAIT找出什么原因导致session持有锁堵塞。
使用V$SESSION获取关于持有锁的程序和用户的更多信息。

 

V$LOCK中的常用列

SID：表示持有锁的会话信息。
TYPE：表示锁的类型。值包括TM和TX等。
LMODE：表示会话等待的锁模式的信息。用数字0－6表示，和表1相对应。
REQUEST：表示session请求的锁模式的信息。
ID1,ID2：表示锁的对象标识。

公共锁类型

在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。

当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁，如下表1。

TX：行级锁，事务锁

在改变数据时必须是排它模式(mode 6)。每一个活动事务都拥有一个锁。它将在事务结束(commit/rollback)时释放。如果一个块包括的列被改变而没有ITL(interested transaction list)槽位(entries)，那么session将锁置于共享模式(mode 4)。当session获得块的ITL槽位时释放。当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。指出回滚段和事务表项。

按下列项以避免竞争：
避免TX－6类型竞争，需要根据您的应用而定。
避免TX－4类型竞争，可以考虑增加对象INITRANS参数值。

TM：表级锁

数据库执行任何DDL语句时必须是排它模式；例如alter table,drop table。执行像insert,update,delete这类DML语句时处于共享模式。它防止其它session对同一个对象同时执行ddl语句。任何对象拥有正被改变的数据，TM锁都将必须存在。锁指向对象。在TM队列避免竞争，可以考虑屏蔽对象表级锁，屏蔽表级锁防止对象执行任何ddl语句。

ST：空间事务锁

每个数据库(非实例)拥有一个ST锁。除了本地管理表空间，在space管理操作(新建或删除extents)时必须是排它模式。对象creation, dropping, extension, 以及truncation都处于这种锁。多数公共原因的争夺，是在磁盘排序(并非使用真正的临时表空间)或回滚段扩展或收缩。

按如下项以避免竞争：
使用真正的临时表空间(true temporary tablespaces)，利用临时文件。临时段在磁盘排序之后并不创建或删除。
使用本地管理表空间。
指定回滚段避免动态扩展和收缩，或使用自动undo management。
避免应用执行创建或删除数据库对象。

UL：用户定义锁

用户可以自定义锁。内容较多并与此节关系不大，略过。

V$LOCK中的连接列

Column                View                Joined Column(s) 
SID                   V$SESSION           SID
ID1, ID2, TYPE        V$LOCK              ID1, ID2, TYPE
ID1                   DBA_OBJECTS         OBJECT_ID
TRUNCID1/65536)       V$ROLLNAME          USN

如果session在等待锁，这可被用于找出session持有的锁。可被用于找出DML锁类型的被锁对象(type='TM')，可被用于找出行级事务锁(TYPE='TX')使用中的回滚段，不过需要通过V$TRANSACTION连接查询得到。

 

表1 Oracle的TM锁类型

锁模式

锁描述

解释

SQL操作

0

none

1

NULL

空

Select

2

SS(Row-S)

行级共享锁，其他对象只能查询这些数据行

Select for update、Lock for update、Lock row share

3

SX(Row-X)

行级排它锁，在提交前不允许做DML操作

Insert、Update、Delete、Lock row share

4

S(Share)

共享锁

Create index、Lock share

5

SSX(S/Row-X)

共享行级排它锁

Lock share row exclusive

6

X(Exclusive)

排它锁

Alter table、Drop table、Drop index、Truncate table 、Lock exclusive

数字越大锁级别越高, 影响的操作越多。一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。select ... from ... for update; 是2的锁。

当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select...for update操作。insert / update / delete ... ; 是3的锁。       

没有commit之前插入同样的一条记录会没有反应,因为后一个3的锁会一直等待上一个3的锁,我们必须释放掉上一个才能继续工作。

创建索引的时候也会产生3,4级别的锁。locked_mode为2,3,4不影响DML(insert,delete,update,select)操作,但DDL(alter,drop等)操作会提示ora-00054错误。有主外键约束时 update / delete ... ; 可能会产生4,5的锁。DDL语句时是6的锁。

如果出现了锁的问题,某个DML操作可能等待很久没有反应。当你采用的是直接连接数据库的方式，也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num 来终止用户连接，因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。

示例：

我按照自己的理解演示的TX,TM锁如下：

1.create table TMP1(col1 VARCHAR2(50));--创建临时表
2.select * from v$lock; --关掉当前锁信息
3.select * from tmp1 for update; --加锁
4.select * from v$lock; --看看现在的锁列表，是不是多了两条记录。Type分别为tx,tm，对照表1。
5.新开一个连接，然后
select * from tmp1 for update; --呵呵，等待状态了吧
select * from v$lock; --又新增了两条记录，其它一条type=tx,lmode=0
7.查看当前被锁的session正在执行的sql语句
SQL> select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ a.username, a.machine, a.sid, a.serial#, a.last_call_et "Seconds", b.id1, c.sql_text "SQL"
from v$session a, v$lock b, v$sqltext c
where a.username is not null and a.lockwait = b.kaddr 
and c.hash_value =a.sql_hash_value
8.将之前的for update语句commit或者rollback，然后新开连接的session拥有锁。有兴趣的朋友还可以试试两条for update的时候，关闭先执行的那个窗口，看看oracle会给出什么样的响应。

这一节是我在自整理v$系列视图以来花费时间和精力最多的一个，我反复看了document，又从网上搜索了各种资料实际使用案例等，就是不开窍。这一节至今我也仍未有把握说尽在掌握，所以在上述文字中除了例子，我如实贴出了收集来的内容，未加任何自我理解，就是担心万一我的理解有误，会对其它浏览本文的人造成困扰。同时我把在收集过程中自我感觉对理解v$lock可能有帮助的资料地址列出，供有心人参考：

Oracle数据库中的锁机制研究
http://soft.zdnet.com.cn/software_zone/2007/0208/377403.shtml

DB2和 Oracle的并发控制（锁）比较
http://www.ibm.com/developerworks/cn/db2/library/techarticles/dm-0512niuxzh/

Itpub论坛的oracle专题深入讨论区也有一篇非常精彩的讨论，地址如下：

我对ORACLE数据锁的一点体会
http://www.itpub.net/270059.html

 

oracle动态性能表 v$process      

本视图包含当前系统oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。在某些情况下非常有用：

1.如果数据库瓶颈是系统资源(如：cpu,内存)，并且占用资源最多的用户总是停留在某几个服务进程，那么进行如下诸项：

1>.找出资源进程
2>.找出它们的session,你必须将进程与会话联系起来。
3>.找出为什么session占用了如此多的资源

2.SQL跟踪文件名是基于服务进程的操作系统进程ID。要找出session的跟踪文件，你必须将session与服务进程联系起来。
3.某些事件，如rdbms ipc reply，鉴别session进程的Oracle进程ID在等什么。要发现这些进程在做什么，你必须找出它们的session。
4.你所看到的服务器上的后台进程(DBWR,LGWR,PMON等)都是服务进程。要想知道他们在做什么，你必须找到他们的session。

V$PROCESS中的常用列
ADDR：进程对象地址
PID：oracle进程ID
SPID：操作系统进程ID

V$PROCESS中的连接列
Column View Joined Column(s) 
ADDR V$SESSION PADDR

示例：
1.查找指定系统用户在oracle中的session信息及进程id，假设操作系统用户为：junsansi
select s.sid,s.SERIAL#, s.username,p.spid
from v$session s, v$process p
where s.osuser = 'junsansi'
and s.PADDR = p.ADDR

2.查看锁和等待
SELECT /*+ rule */
lpad(' ', decode(l.xidusn, 0, 3, 0)) || l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#,p.spid
FROM v$locked_object l, dba_objects o, v$session s, v$process p
WHERE l.object_id = o.object_id
AND l.session_id = s.sid and s.paddr = p.addr
ORDER BY o.object_id, xidusn DESC

附注：
　　在linux环境可以通过ps查看进程信息包括pid,windows中任务管理器的PID与v$process中pid不能一一对应，这块在oracleDocument中也没有找到介绍，后来google了一下，有资料介绍说是由于windows是多线程服务器,每个进程包含一系列线程。这点于unix等不同，Unix每个Oralce进程独立存在，在Nt上所有线程由Oralce进程衍生。
　　要在windows中显示oracle相关进程pid，我们可以通过一个简单的sql语句来实现。
SELECT s.SID, p.pid, p.spid signaled, s.osuser, s.program
FROM v$process p, v$session s
WHERE p.addr = s.paddr;

SID PID SIGNALED OSUSER PROGRAM 
1 2 2452 SYSTEM ORACLE.EXE 
2 3 2460 SYSTEM ORACLE.EXE 
3 4 2472 SYSTEM ORACLE.EXE 
4 5 2492 SYSTEM ORACLE.EXE 
5 6 2496 SYSTEM ORACLE.EXE 
6 7 2508 SYSTEM ORACLE.EXE 
7 8 2520 SYSTEM ORACLE.EXE 
8 9 2524 SYSTEM ORACLE.EXE 
10 12 1316 JSSjunsansi PlSqlDev.exe 
9 13 3420 JSSjunsansi PlSqlDev.exe 
13 14 660 JSSjunsansi PlSqlDev.exe

还可以通过和 v$bgprocess 连接查询到后台进程的名字： 
SELECT s.SID SID, p.spid threadid, p.program processname, bg.NAME NAME
FROM v$process p, v$session s, v$bgprocess bg
WHERE p.addr = s.paddr
AND p.addr = bg.paddr
AND bg.paddr <> '00';

SID THREADID PROCESSNAME NAME 
1 2452 ORACLE.EXE PMON 
2 2460 ORACLE.EXE DBW0 
3 2472 ORACLE.EXE LGWR 
4 2492 ORACLE.EXE CKPT 
5 2496 ORACLE.EXE SMON 
6 2508 ORACLE.EXE RECO 
7 2520 ORACLE.EXE CJQ0 
8 2524 ORACLE.EXE QMN0

Eygle大师写了一段sql脚本getsql.sql，用来获取指定pid正在执行的sql语句，在此也附注上来。
REM getsql.sql
REM author eygle
REM 在windows上,已知进程ID,得到当前正在执行的语句
REM 在windows上,进程ID为16进制,需要转换,在UNIX直接为10进制
SELECT /*+ ORDERED */
sql_text
FROM v$sqltext a
WHERE (a.hash_value, a.address) IN (
SELECT DECODE (sql_hash_value,
0, prev_hash_value,
sql_hash_value
),
DECODE (sql_hash_value, 0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.paddr = (SELECT addr
FROM v$process c
WHERE c.spid = TO_NUMBER ('&pid', 'xxxx')))
ORDER BY piece ASC

 

 

oracle动态性能表 v$session_wait     

这是一个寻找性能瓶颈的关键视图。它提供了任何情况下session在数据库中当前正在等待什么(如果session当前什么也没在做，则显示它最后的等待事件)。当系统存在性能问题时，本视图可以做为一个起点指明探寻问题的方向。

　　V$SESSION_WAIT中，每一个连接到实例的session都对应一条记录。

V$SESSION_WAIT中的常用列

SID: session标识
EVENT: session当前等待的事件，或者最后一次等待事件。
WAIT_TIME: session等待事件的时间(单位，百分之一秒)如果本列为0，说明session当前session还未有任何等待。
SEQ#: session等待事件将触发其值自增长
P1, P2, P3: 等待事件中等待的详细资料
P1TEXT, P2TEXT, P3TEXT: 解释说明p1,p2,p3事件

附注：
1.State字段有四种含义﹕
Waiting：SESSION正等待这个事件。
Waited unknown time：由于设置了timed_statistics值为false，导致不能得到时间信息。表示发生了等待，但时间很短。
Wait short time：表示发生了等待，但由于时间非常短不超过一个时间单位，所以没有记录。
Waited knnow time：如果session等待然后得到了所需资源，那么将从waiting进入本状态。

Wait_time值也有四种含义：
值>0：最后一次等待时间(单位：10ms)，当前未在等待状态。
值=0：session正在等待当前的事件。
值=-1：最后一次等待时间小于1个统计单位，当前未在等待状态。
值=-2：时间统计状态未置为可用，当前未在等待状态。

3.Wait_time和Second_in_wait字段值与state相关:
如果state值为Waiting，那么wait_time值无用。Second_in_wait值是实际的等待时间(单位：秒)。
如果state值为Wait unknow time，那么wait_time值和Second_in_wait值都无用。
如果state值为Wait short time，那么wait_time值和Second_in_wait值都无用。
如果state值为Waiting known time，那么wait_time值就是实际等待时间(单位：秒)，Second_in_wait值无用。

V$SESSION_WAIT中的连接列

Column View Joined Column(s) 
SID V$SESSION SID

示例：
1.列出当前系统的等待事件
SELECT event,
sum(decode(wait_time,0,1,0)) "Curr",
sum(decode(wait_time,0,0,1)) "Prev",
count(*)"Total"
FROM v$session_wait GROUP BY event ORDER BY count(*);
EVENT Prev Curr Tot
--------------------------------------------- ---- ----- -----
PL/SQL lock timer 0 1 1
SQL*Net more data from client 0 1 1
smon timer 0 1 1
pmon timer 0 1 1
SQL*Net message to client 2 0 2
db file scattered read 2 0 2
rdbms ipc message 0 7 7
Enqueue 0 12 12
pipe get 0 12 12
db file sequential read 3 10 13
latch free 9 6 15
SQL*Net message from client 835 1380 2215

这个按事件和wait_time的分组查询列出下列的信息：
多数的session都是空闲事件如：SQL*Net message from client, pipe get, PMON timer等。
session的cpu占用可以通过上次session的非等待事件大致算出，除此问题外：看起来多数session没有在等待什么事情(难道他们都在干活？)但其最后等待事件都是SQL*Net message from client。

列出指定ID的等待事件
select * from v$session_wait where sid=100;

应用p1,p2,p3进行等待事件的分析
v$session_wait视图的列代表的缓冲区忙等待事件如下： 
P1—与等待相关的数据文件的全部文件数量。 
P2—P1中的数据文件的块数量。 
P3—描述等待产生原因的代码。 
例：select p1 "File #", p2 "Block #", p3 "Reason Code"
　　from v$session_wait
　　where event = 'buffer busy waits';
如果以上查询的结果显示一个块在忙等待，以下的查询将显示这一块的名称和类型：
select owner, segment_name, segment_type
　from dba_extents
　where file_id = &P1　and &P2 between block_id and block_id + blocks -1;

　　我们也可以查询dba_data_files以确定等待的文件的file_name，方法是使用v$session_wait中的P1。 
　　从v$session_wait中查询P3(原因编码)的值可以知道session等待的原因。原因编码的范围从0到300，下列为部分编码所代表的事项： 
0 块被读入缓冲区。 
100 我们想要NEW(创建)一个块，但这一块当前被另一session读入。 
110 我们想将当前块设为共享，但这一块被另一session读入，所以我们必须等待read()结束。 
120 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。 
130 块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。 
200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。 
210 Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。 
220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。 
230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。 
231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束。

 

 

oracle动态性能表  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视图常用列介绍：STATISTIC#: 标识
NAME: 统计项名称
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统计项，在调优方面相当有用。下列按字母先后排序：

数据库使用状态的一些关键指标：
CPU used by this session：所有session的cpu占用量，不包括后台进程。这项统计的单位是百分之x秒.完全调用一次不超过10ms
db block changes：那部分造成SGA中数据块变化的insert,update或delete操作数 这项统计可以大概看出整体数据库状态。在各项事务级别，这项统计指出脏缓存比率。
execute count：执行的sql语句数量(包括递归sql)
logons current：当前连接到实例的Sessions。如果当前有两个快照则取平均值。
logons cumulative：自实例启动后的总登陆次数。
parse count (hard)：在shared pool中解析调用的未命中次数。当sql语句执行并且该语句不在shared pool或虽然在shared pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条sql语句原文与当前存在的相同，但查询表不同则认为它们是两条不同语句，则硬解析即会发生。硬解析会带来cpu和资源使用的高昂开销，因为它需要oracle在shared pool中重新分配内存，然后再确定执行计划，最终语句才会被执行。
parse count (total)：解析调用总数，包括软解析和硬解析。当session执行了一条sql语句，该语句已经存在于shared pool并且可以被使用则产生软解析。当语句被使用(即共享) 所有数据相关的现有sql语句(如最优化的执行计划)必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。
parse time cpu：总cpu解析时间(单位：10ms)。包括硬解析和软解析。
parse time elapsed：完成解析调用的总时间花费。
physical reads：OS blocks read数。包括插入到SGA缓存区的物理读以及PGA中的直读这项统计并非i/o请求数。
physical writes：从SGA缓存区被DBWR写到磁盘的数据块以及PGA进程直写的数据块数量。
redo log space requests：在redo logs中服务进程的等待空间，表示需要更长时间的log switch。
redo size：redo发生的总次数(以及因此写入log buffer)，以byte为单位。这项统计显示出update活跃性。
session logical reads：逻辑读请求数。
sorts (memory) and sorts (disk)：sorts(memory)是适于在SORT_AREA_SIZE(因此不需要在磁盘进行排序)的排序操作的数量。sorts(disk)则是由于排序所需空间太大，SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算in-memory sort ratio。
sorts (rows): 列排序总数。这项统计可被'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。
table fetch by rowid：使用ROWID返回的总列数(由于索引访问或sql语句中使用了'where rowid=&rowid'而产生)
table scans (rows gotten)：全表扫描中读取的总列数
table scans (blocks gotten)：全表扫描中读取的总块数，不包括那些split的列。
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';

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

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

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

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

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

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

其它计算统计以衡量负载方式，如下：
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' ;

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