客户端连接数据库报如下错误：

show parameter processes;
然后
更改系统连接数
alter system set processes=1000 scope=spfile;
下面是具体的操作步骤与说明

问题描述：客户端连接数据库报错
ORA-12516: TNS: 监听程序无法找到匹配协议栈的可用句柄

解决过程：
1。查看当前会话数、processes和sessions值，发现session数和2个参数的值已经非常逼近
SQL*Plus: Release 10.2.0.1.0 - Production on 星期一 10月 9 15:50:21 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
已连接。
SQL> select count(*) from v＄session;
COUNT(*)
----------
45
SQL> show parameter processes
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 50
SQL> show parameter sessions
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
java_max_sessionspace_size integer 0
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
logmnr_max_persistent_sessions integer 1
sessions integer 60
shared_server_sessions integer
2。修改processes和sessions值
SQL> alter system set processes=300 scope=spfile;
系统已更改。
SQL> alter system set sessions=300 scope=spfile;
系统已更改。
3。查看processes和sessions参数，但更改并未生效
SQL> show parameter processes
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 50
SQL> show parameter sessions
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
java_max_sessionspace_size integer 0
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
logmnr_max_persistent_sessions integer 1
sessions integer 60
shared_server_sessions integer
4。重启数据库，使更改生效
SQL> shutdown immediate
SQL> startup
SQL> show parameter processes
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 300
SQL> show parameter sessions
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
java_max_sessionspace_size integer 0
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
logmnr_max_persistent_sessions integer 1
sessions integer 335
shared_server_sessions integer
最后测试加大连接数到50，100都没报ORA-12516错误。
有的时候我们需要调整oracle数据库的最大链接数，而这个链接数的调整是在oacle下的dbs目
录下init.ora文件中调整的。
ORACLE的连接数(sessions)与其参数文件中的进程数(process)有关，它们的关系如下：
sessions=(1.1*process+5)
但是我们增加process数时，往往数据库不能启动了。这因为我们还漏调了一个unix系统参数：
它是核心参数中的semmns,这是unix系统的信号量参数。每个process会占用一个信号量。semmns
调整后，需要重新启动unix操作系统，参数才能生效。不过它的大小会受制于硬件的内存或ORACLE
SGA。范围可从200——2000不等。
但是，Processes的修改不仅应该调整init.ora文件中的参数，而且应该调整OS的内核
参数，象AIX,HPUX,Solaris,SCO,UNIXWare都是这样，OS的调整是需要重新启动的，而且这个参数
的设置不能简单按照多少个终端要连到这个服务器上而定，
最关键是考虑会有多少同时连上的session（在使用一些共享连接的中间件时，一般就不需要太大），
当然还要考虑一些Oracle的后台进程，还有一些系统维护工作需要多一些连接等。
我的atmp大前置机器上对oracle调整的时候，其使用的是unixware操作系统，在做链接数调整
的时候，要先对核心参数进行调整。
核心主要相关的参数的调整如下：
SHMMAX 1000000000
SHMMIN 1
SHMMNI 200
SHMSEG 15
SEMMNI 1000
SEMMSL 300
SEMMNS 230
SEMOPM 20
其中semmni,semmns,semmsl要加大，至少要比processes大18 ；
SEMMNI（10，10000；150）：指定在核心中信号识别的数量。这是可以在任意给定时间被激活的唯
一信号设置数量。缺省值是150。最大值由系统自动调整产生。
SEMMSL（25，300；150）：指定每个信号识别中信号量的最大值。缺省值是25。
SEMMNS 除最大db外的所有db 的PROCESSES之和+2*最大db的PROCESSES+10*实例数。如3个实例进
程数分别为100、100、200，则=（100+100）+2*200+10*3=630
SEMOPM（10,20；10）:指定在每个系统调用semop中能够被执行的信号操作量的最大值。
缺省值是10。
SHMMAX（131072，1073741824；524288）：指定了共享内存部分大小的最大值。
等于0.5×物理内存字节数
SHMMNI（10，1000；100）：指定了系统范围内共享内存标识的最大值。
SHMSEG（6，15；6）：指定了与每个进程相关连的共享内存块（或标识）的数量。缺省值是6。与每
个进程相关连的共享内存块的最大值与进程拥有的未使用空间有关。因此，尽管一个进程拥有少于
SHMSEG数值的共享内存块，它也有可能因为其有限的空间而不能与其它进程相联系。
init.ora中调整为：
processes = 50 # SMALL
#processes = 100 # MEDIUM
# processes = 200 # LARGE
其中的processes就是要调整的最大连接数的数目，我们只要调整这个参数就可以了，其它的参数可
以保持默认值。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/rongdajian/archive/2009/10/22/4711748.aspx

怎样查看oracle当前的连接数呢？只需要用下面的SQL语句查询一下就可以了。

select * from v$session where username is not null

select username,count(username) from v$session where username is not null group by username #查看不同用户的连接数

select count(*) from v$session   #连接数

Select count(*) from v$session where status='ACTIVE'　#并发连接数

show parameter processes   #最大连接

alter system set processes = value scope = spfile;重启数据库   #修改连接

1。查看当前会话数、processes和sessions值，发现session数和2个参数的值已经非常逼近

SQL> conn / as sysdba已连接。

SQL> select count(*) from v$session;

SQL> show parameter processes;

SQL> show parameter sessions;

2。修改processes和sessions值

SQL> alter system set processes=300 scope=spfile;

系统已更改。

SQL> alter system set sessions=300 scope=spfile;

系统已更改。

 

    3。查看processes和sessions参数，但更改并未生效

 

4。重启数据库，使更改生效

SQL> shutdown immediate

SQL> startup

SQL> show parameter processes

     SQL> show parameter sessions

数据库连接池概述：  s-}q # j  
数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。对数据库连接的管理能显著影响到整个应用程序的伸缩性和健壮性，影响到程序的性能指标。数据库连接池正是针对这个问题提出来的。  q!.l%@y K  
数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。 d+MD2?`Q   
数据库连接池在初始化时将创建一定数量的数据库连接放到连接池中，这些数据库连接的数量是由最小数据库连接数来设定的。无论这些数据库连接是否被使用，连接池都将一直保证至少拥有这么多的连接数量。连接池的最大数据库连接数量限定了这个连接池能占有的最大连接数，当应用程序向连接池请求的连接数超过最大连接数量时，这些请求将被加入到等待队列中。数据库连接池的最小连接数和最大连接数的设置要考虑到下列几个因素：  ./ ,bSh  
1) 最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费； %< xf j xr  
2) 最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。 [ Ylf  }/W  
3) 如果最小连接数与最大连接数相差太大，那么最先的连接请求将会获利，之后超过最小连接数量的连接请求等价于建立一个新的数据库连接。不过，这些大于最小连接数的数据库连接在使用完不会马上被释放，它将被放到连接池中等待重复使用或是空闲超时后被释放。

V$SEGSTAT

本视图实时监控段级(segment-level)统计项，支持oracle9ir2及更高版本

V$SEGSTAT中的常用列

l         TS#：表空间标识

l         OBJ#：字典对象标识

l         DATAOBJ#：数据对象标识

l         STATISTIC_NAME：统计项名称

l         STATISTIC#：统计项标识

l         VALUE：统计项值

V$SEGSTAT中的连接列

Column                             View                                         Joined Column(s)

--------------                         -----------------------                           ------------------------

TS#                                   V$TABLESPACE                         TS#

OBJ#                                  ALL_OBJECTS                           OBJECT_ID

示例：

1.查询指定对象的统计

select * from v$segstat where ts# = 11

   and obj# = (select object_id fromuser_objects

                where object_name = 'TMPTABLE1'and wner = 'JSS')

V$SEGMENT_STATISTICS

　　这是一个友好的视图，支持Oracle9ir2及更高版本。实时监测段级(segment-level)统计项，可用于鉴定性能问题源于表或索引

V$SEGMENT_STATISTICS中的列

l         OWNER：对象所有者

l         OBJECT_NAME：对象名称

l         SUBOBJECT_NAME：子对象名称

l         TABLESPACE_NAME：对象所在表空间

l         TS#：表空间标识

l         OBJ#：字典对象标识

l         DATAOBJ#：数据对象标识

l         OBJECT_TYPE：对象类型

l         STATISTIC_NAME：统计项名称

l         STATISTIC#：统计项标识

l         VALUE：统计项值

基本与上相同，只是信息更加详细，不再赘述。

V$SESSION_LONGOPS

本视图显示运行超过6秒的操作的状态。包括备份，恢复，统计信息收集，查询等等。

要监控查询执行进展状况，你必须使用cost-based优化方式，并且：

l         设置TIMED_STATISTICS或SQL_TRACE参数值为true。

l         通过ANALYZE或DBMS_STATS数据包收集对象统计信息。

你可以通过DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS过程添加application-specific长运行操作信息到本视图。关于DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS的更多信息可以浏览：Oracle Supplied PL/SQL Packages and Types Reference。

V$SESSION_LONGOPS列说明

l         SID：Session标识

l         SERIAL#：Session串号

l         OPNAME：操作简要说明

l         TARGET：操作运行所在的对象

l         TARGET_DESC：目标对象说明

l         SOFAR：至今为止完成的工作量

l         TOTALWORK：总工作量

l         UNITS：工作量单位

l         START_TIME：操作开始时间

l         LAST_UPDATE_TIME：统计项最后更新时间

l         TIME_REMAINING：预计完成操作的剩余时间(秒)

l         ELAPSED_SECONDS：从操作开始总花费时间(秒)

l         CONTEXT：前后关系

l         MESSAGE：统计项的完整描述

l         USERNAME：执行操作的用户ID

l         SQL_ADDRESS：用于连接查询的列

l         SQL_HASH_VALUE：用于连接查询的列

l         QCSID：

示例：

找一较大表，确认该表查询将超过6秒，哎呀让它快咱没把握，让它慢这可是我的强项啊~~

SQL> set timing on

SQL> create table ttt as select level lv,rownum rn from dual connect by level<10000000;   --创建一个临时表

Table created

Executed in 19.5 seconds

SQL> commit;

Commit complete

Executed in 0 seconds

SQL> select * from (select * from ttt order by lv desc) where rownum<2;    --执行一个费时的查询

        LV         RN

---------- ----------

   9999999    9999999

Executed in 9.766 seconds   --哈哈，成功超过6秒

SQL> select sid,opname,sofar,totalwork,units,sql_hash_value from v$session_longops;      ----看看v$session_longops中是不是已经有记录了

       SID OPNAME                                                                SOFAR TOTALWORK UNITS                            SQL_HASH_VALUE

---------- ---------------------------------------------------------------- ---------- ---------- -------------------------------- --------------

        10 Table Scan                                                            47276      47276 Blocks                               2583310173

Executed in 0.047 seconds

SQL> select a.sql_text from v$sqlarea a,v$session_longops b where a.HASH_VALUE=b.SQL_HASH_VALUE;   --通过hash_value联系查询出刚执行的查询语句。

SQL_TEXT

--------------------------------------------------------------------------------

select * from (select * from ttt order by lv desc) where rownum<2

Executed in 0.063 seconds

Ps:itpub论坛的fenng版版数年前有篇文章描述了v$sessin_longops的来源，有兴趣的朋友可以研究研究：

http://www.dbanotes.net/database/vsession_longops.html

V$PROCESS

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

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

l         找出资源进程

l         找出它们的session,你必须将进程与会话联系起来。

l         找出为什么session占用了如此多的资源

2.         SQL跟踪文件名是基于服务进程的操作系统进程ID。要找出session的跟踪文件，你必须将session与服务进程联系起来。

3.         某些事件，如rdbms ipc reply，鉴别session进程的Oracle进程ID在等什么。要发现这些进程在做什么，你必须找出它们的session。

4.         你所看到的服务器上的后台进程(DBWR,LGWR,PMON等)都是服务进程。要想知道他们在做什么，你必须找到他们的session。

V$PROCESS中的常用列

l         ADDR：进程对象地址

l         PID：oracle进程ID

l         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

ORDERBY o.object_id, xidusn DESC

3.        

附注：

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

还可以通过和 v$bgprocess 连接查询到后台进程的名字：

SELECT s.SID SID, p.spid threadid, p.program processname, bg.NAMENAME

FROM v$process p, v$session s, v$bgprocess bg

WHERE p.addr = s.paddr

   AND p.addr = bg.paddr

   AND bg.paddr <> '00';

V$FILESTAT

　　本视图记录各文件物理I/O信息。如果瓶颈与I/O相关，可用于分析发生的活动I/O事件。V$FILESTAT显示出数据库I/O的下列信息(不包括日志文件)：

l         物理读写数

l         块读写数

l         I/O读写总耗时

　　以上数值自实例启动即开始记录。如果获取了两个快照，那么二者之间的差异即是这一时间段内活动I/O统计。

V$FILESTAT中的常用列：

l         FILE#：文件序号；

l         PHYRDS：已完成的物理读次数；

l         PHYBLKRD：块读取数；

l         PHYWRTS：DBWR完成的物理写次数；

l         PHYBLKWRT：写入磁盘的块数；

V$FILESTAT注意项：

l         因为multiblock读调用，物理读数和数据块读数有可能不同；

l         因为进程直写，物理写和数据块写也可能不一致；

l         Sum(physical blocks read) 近似于v$sysstat中的physical reads；

l         Sum(physical blocks written) 近似于v$sysstat中的physical writes；

l         数据读(由缓存读比直读好)由服务进程处理。从buffer cache写只能由DBWR进行，直写由服务进程处理。

V$FILESTAT中的连接列

Column                             View                                          Joined Column(s)

-----------                                   -------------------------                  -------------------------

FILE#                                 DBA_DATA_FILES                     FILE_ID

FILE#                                 V$DATAFILE                            FILE#

示例：

1.获得数据文件物理读写和数据块读写信息：

select df.tablespace_name name,

       df.file_name       "file",

       f.phyrds           pyr,

       f.phyblkrd         pbr,

       f.phywrts          pyw,

       f.phyblkwrt        pbw

from v$filestat f, dba_data_files df where f.file# = df.file_id

orderby df.tablespace_name;

注意：尽管oracle记录的读写次数非常精确，但如果数据库运行在Unix文件系统(UFS)有可能不能表现真实的磁盘读写，例如，读次数可能并非真实的磁盘读，而是UFS缓存。不过裸设备的读写次数应该是比较精准的。

(1)-V$SESSION_WAIT

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

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

V$SESSION_WAIT中的常用列

l         SID: session标识

l         EVENT: session当前等待的事件，或者最后一次等待事件。

l         WAIT_TIME: session等待事件的时间(单位，百分之一秒)如果本列为0，说明session当前session还未有任何等待。

l         SEQ#: session等待事件将触发其值自增长

l         P1, P2, P3: 等待事件中等待的详细资料

l         P1TEXT, P2TEXT, P3TEXT: 解释说明p1,p2,p3事件

附注：

1.State字段有四种含义﹕

(1)Waiting：SESSION正等待这个事件。

(2)Waited unknown time：由于设置了timed_statistics值为false，导致不能得到时间信息。表示发生了等待，但时间很短。

(3)Wait short time：表示发生了等待，但由于时间非常短不超过一个时间单位，所以没有记录。

(4)Waited knnow time：如果session等待然后得到了所需资源，那么将从waiting进入本状态。

2.Wait_time值也有四种含义：

(1)值>0：最后一次等待时间(单位：10ms)，当前未在等待状态。

(2)值=0：session正在等待当前的事件。

(3)值=-1：最后一次等待时间小于1个统计单位，当前未在等待状态。

(4)值=-2：时间统计状态未置为可用，当前未在等待状态。

3.Wait_time和Second_in_wait字段值与state相关:

(1)如果state值为Waiting，那么wait_time值无用。Second_in_wait值是实际的等待时间(单位：秒)。

(2)如果state值为Wait unknow time，那么wait_time值和Second_in_wait值都无用。

(3)如果state值为Wait short time，那么wait_time值和Second_in_wait值都无用。

(4)如果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 GROUPBY event ORDERBYcount(*);

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的分组查询列出下列的信息：

l         多数的session都是空闲事件如：SQL*Net message from client, pipe get, PMON timer等。

l         session的cpu占用可以通过上次session的非等待事件大致算出，除此问题外：看起来多数session没有在等待什么事情(难道他们都在干活？)但其最后等待事件都是SQL*Net message from client。

2.列出指定ID的等待事件

select * from v$session_wait where sid=100;

3.应用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扫描找到当前块，但块中的更改开始并且没有结束。

(2)-V$SESSION_EVENT

　　本视图记录了每个session的每一项等待事件。由上文所知V$SESSION_WAIT显示了session的当前等待事件，而V$SESSION_EVENT则记录了session自启动起所有的事件。

V$SESSION_EVENT中的常用列

l         SID：session标识

l         EVENT：session等待的事件

l         TOTAL_WAITS：此session当前事件的总等待数

l         TIME_WAITED：此session总等待时间(单位，百分之一秒)

l         AVERAGE_WAIT：此session当前事件平均等待时间(单位，百分之一秒)

l         TOTAL_TIMEOUTS：等待超时次数

其它用法与V$SESSION_WAIT相似，不详述了

附注：

Oracle的等待事件是衡量Oracle运行状况的重要依据及指标。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100个等待事件。在Oracle 8.0中这个数目增加到了大约150个，在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。主要有两种类别的等待事件，即空闲(idle)等待事件和非空闲(non-idle)等待事件。

关于空闲事件和非空闲事件目前通过google可以搜索到非常多详尽的相关信息，同时

Oracle Database Performance Tuning Guide and Reference中关于Wait Events也有非常详尽的描述，在此就不多费口舌了。不过我在itpub论坛看到有热心人整理的chm格式非空闲事件说明，有兴趣的朋友可以下载，链接如下：

非空闲事件说明

详见：http://www.itpub.net/728733.html

V$SESSION

　　在本视图中，每一个连接到数据库实例中的session都拥有一条记录。包括用户session及后台进程如DBWR，LGWR，arcchiver等等。

V$SESSION中的常用列

V$SESSION是基础信息视图，用于找寻用户SID或SADDR。不过，它也有一些列会动态的变化，可用于检查用户。如例：

SQL_HASH_VALUE，SQL_ADDRESS：这两列用于鉴别默认被session执行的SQL语句。如果为null或0，那就说明这个session没有执行任何SQL语句。PREV_HASH_VALUE和PREV_ADDRESS两列用来鉴别被session执行的上一条语句。

STATUS：这列用来判断session状态是：

l         Achtive：正执行SQL语句(waiting for/using a resource)

l         Inactive：等待操作(即等待需要执行的SQL语句)

l         Killed：被标注为删除

下列各列提供session的信息，可被用于当一个或多个combination未知时找到session。

Session信息

l         SID：SESSION标识，常用于连接其它列

l         SERIAL#：如果某个SID又被其它的session使用的话则此数值自增加(当一个       SESSION结束，另一个SESSION开始并使用了同一个SID)。

l         AUDSID：审查session ID唯一性，确认它通常也用于当寻找并行查询模式

l         USERNAME：当前session在oracle中的用户名。

Client信息

数据库session被一个运行在数据库服务器上或从中间服务器甚至桌面通过SQL*Net连接到数据库的客户端进程启动，下列各列提供这个客户端的信息

l         OSUSER：客户端操作系统用户名

l         MACHINE：客户端执行的机器

l         TERMINAL：客户端运行的终端

l         PROCESS：客户端进程的ID

l         PROGRAM：客户端执行的客户端程序

要显示用户所连接PC的 TERMINAL、OSUSER，需在该PC的ORACLE.INI或Windows中设置关键字TERMINAL，USERNAME。

Application信息

调用DBMS_APPLICATION_INFO包以设置一些信息区分用户。这将显示下列各列。

l         CLIENT_INFO：DBMS_APPLICATION_INFO中设置

l         ACTION：DBMS_APPLICATION_INFO中设置

l         MODULE：DBMS_APPLICATION_INFO中设置

下列V$SESSION列同样可能会被用到：

l         ROW_WAIT_OBJ#

l         ROW_WAIT_FILE#

l         ROW_WAIT_BLOCK#

l         ROW_WAIT_ROW#

V$SESSION中的连接列

Column                                                            View                                              Joined Column(s)

SID             V$SESSION_WAIT,,V$SESSTAT,,V$LOCK,V$SESSION_EVENT,V$OPEN_CURSOR                 SID

(SQL_HASH_VALUE, SQL_ADDRESS)                  V$SQLTEXT, V$SQLAREA, V$SQL    (HASH_VALUE, ADDRESS)

(PREV_HASH_VALUE, PREV_SQL_ADDRESS)     V$SQLTEXT, V$SQLAREA, V$SQL    (HASH_VALUE, ADDRESS)

TADDR                                                             V$TRANSACTION                                    ADDR

PADDR                                                              V$PROCESS                                             ADDR

示例：

1.查找你的session信息

SELECT SID, OSUSER, USERNAME, MACHINE, PROCESS

FROM V$SESSION WHERE audsid = userenv('SESSIONID');

2.当machine已知的情况下查找session

SELECT SID, OSUSER, USERNAME, MACHINE, TERMINAL

FROM V$SESSION

WHERE terminal = 'pts/tl'AND machine = 'rgmdbs1';

3.查找当前被某个指定session正在运行的sql语句。假设sessionID为100

select b.sql_text

from v$session a,v$sqlarea b

where a.sql_hash_value=b.hash_valueand a.sid=100

寻找被指定session执行的SQL语句是一个公共需求，如果session是瓶颈的主要原因，那根据其当前在执行的语句可以查看session在做些什么。

V$SQLTEXT

　　本视图包括Shared pool中SQL语句的完整文本，一条SQL语句可能分成多个块被保存于多个记录内。

　　注：V$SQLAREA只包括头1000个字符。

V$SQLTEXT中的常用列

l         HASH_VALUE：SQL语句的Hash值

l         ADDRESS：sql语句在SGA中的地址

l         SQL_TEXT：SQL文本。

l         PIECE：SQL语句块的序号

V$SQLTEXT中的连接列

Column                                          View                                    Joined Column(s)

HASH_VALUE, ADDRESS         V$SQL, V$SESSION            HASH_VALUE, ADDRESS

HASH_VALUE. ADDRESS         V$SESSION                          SQL_HASH_VALUE, SQL_ADDRESS

示例：已知hash_value:3111103299，查询sql语句：

select * from v$sqltext

where hash_value='3111103299'

orderby piece

V$SQLAREA

　　本视图持续跟踪所有shared pool中的共享cursor，在shared pool中的每一条SQL语句都对应一列。本视图在分析SQL语句资源使用方面非常重要。

V$SQLAREA中的信息列

l         HASH_VALUE：SQL语句的Hash值。

l         ADDRESS：SQL语句在SGA中的地址。

这两列被用于鉴别SQL语句，有时，两条不同的语句可能hash值相同。这时候，必须连同ADDRESS一同使用来确认SQL语句。

l         PARSING_USER_ID：为语句解析第一条CURSOR的用户

l         VERSION_COUNT：语句cursor的数量

l         KEPT_VERSIONS：

l         SHARABLE_MEMORY：cursor使用的共享内存总数

l         PERSISTENT_MEMORY：cursor使用的常驻内存总数

l         RUNTIME_MEMORY：cursor使用的运行时内存总数。

l         SQL_TEXT：SQL语句的文本（最大只能保存该语句的前1000个字符）。

l         MODULE,ACTION：使用了DBMS_APPLICATION_INFO时session解析第一条cursor时的信息

V$SQLAREA中的其它常用列

l         SORTS: 语句的排序数

l         CPU_TIME: 语句被解析和执行的CPU时间

l         ELAPSED_TIME: 语句被解析和执行的共用时间

l         PARSE_CALLS: 语句的解析调用(软、硬)次数

l         EXECUTIONS: 语句的执行次数

l         INVALIDATIONS: 语句的cursor失效次数

l         LOADS: 语句载入(载出)数量

l         ROWS_PROCESSED: 语句返回的列总数

V$SQLAREA中的连接列

Column                                          View                                                               Joined Column(s)

HASH_VALUE, ADDRESS         V$SESSION                                                     SQL_HASH_VALUE, SQL_ADDRESS

HASH_VALUE, ADDRESS         V$SQLTEXT, V$SQL, V$OPEN_CURSOR   HASH_VALUE, ADDRESS

SQL_TEXT                                   V$DB_OBJECT_CACHE                               NAME

示例：

1.查看消耗资源最多的SQL：

SELECT hash_value, executions, buffer_gets, disk_reads, parse_calls

FROM V$SQLAREA

WHERE buffer_gets > 10000000OR disk_reads > 1000000

ORDERBY buffer_gets + 100 * disk_reads DESC;

2.查看某条SQL语句的资源消耗：

SELECT hash_value, buffer_gets, disk_reads, executions, parse_calls

FROM V$SQLAREA

WHERE hash_Value = 228801498AND address = hextoraw('CBD8E4B0');

(1) v$sql

　　一条语句可以映射多个cursor,因为对象所指的cursor可以有不同用户(如例1)。如果有多个cursor(子游标)存在，在V$SQLAREA为所有cursor提供集合信息。

　　在个别cursor上，v$sql可被使用。该视图包含cursor级别资料。当试图定位session或用户以分析cursor时被使用。

　　PLAN_HASH_VALUE列存储的是数值表示的cursor执行计划。可被用来对比执行计划。PLAN_HASH_VALUE让你不必一行一行对比即可轻松鉴别两条执行计划是否相同。

V$SQL中的列说明：

l         SQL_TEXT：SQL文本的前1000个字符

l         SHARABLE_MEM：占用的共享内存大小(单位：byte)

l         PERSISTENT_MEM：生命期内的固定内存大小(单位：byte)

l         RUNTIME_MEM：执行期内的固定内存大小

l         SORTS：完成的排序数

l         LOADED_VERSIONS：显示上下文堆是否载入，1是0否

l         OPEN_VERSIONS：显示子游标是否被锁，1是0否

l         USERS_OPENING：执行语句的用户数

l         FETCHES：SQL语句的fetch数。

l         EXECUTIONS：自它被载入缓存库后的执行次数

l         USERS_EXECUTING：执行语句的用户数

l         LOADS：对象被载入过的次数

l         FIRST_LOAD_TIME：初次载入时间

l         INVALIDATIONS：无效的次数

l         PARSE_CALLS：解析调用次数

l         DISK_READS：读磁盘次数

l         BUFFER_GETS：读缓存区次数

l         ROWS_PROCESSED：解析SQL语句返回的总列数

l         COMMAND_TYPE：命令类型代号

l         OPTIMIZER_MODE：SQL语句的优化器模型

l         OPTIMIZER_COST：优化器给出的本次查询成本

l         PARSING_USER_ID：第一个解析的用户ID

l         PARSING_SCHEMA_ID：第一个解析的计划ID

l         KEPT_VERSIONS：指出是否当前子游标被使用DBMS_SHARED_POOL包标记为常驻内存

l         ADDRESS：当前游标父句柄地址

l         TYPE_CHK_HEAP：当前堆类型检查说明

l         HASH_VALUE：缓存库中父语句的Hash值

l         PLAN_HASH_VALUE：数值表示的执行计划。

l         CHILD_NUMBER：子游标数量

l         MODULE：在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_MODULE设置的模块名称。

l         ACTION：在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_ACTION设置的动作名称。

l         SERIALIZABLE_ABORTS：事务未能序列化次数

l         OUTLINE_CATEGORY：如果outline在解释cursor期间被应用，那么本列将显示出outline各类，否则本列为空

l         CPU_TIME：解析/执行/取得等CPU使用时间(单位，毫秒)

l         ELAPSED_TIME：解析/执行/取得等消耗时间(单位，毫秒)

l         OUTLINE_SID：outline session标识

l         CHILD_ADDRESS：子游标地址

l         SQLTYPE：指出当前语句使用的SQL语言版本

l         REMOTE：指出是否游标是一个远程映象(Y/N)

l         OBJECT_STATUS：对象状态(VALID or INVALID)

l         IS_OBSOLETE：当子游标的数量太多的时候，指出游标是否被废弃(Y/N)

(2)-V$SQL_PLAN

　　本视图提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。

　　通常，本视图提供的信息与打印出的EXPLAIN PLAN非常相似，不过，EXPLAIN PLAN显示的是理论上的计划，并不一定在执行的时候就会被使用，但V$SQL_PLAN中包括的是实际被使用的计划。获自EXPLAIN PLAN语句的执行计划跟具体执行的计划可以不同，因为cursor可能被不同的session参数值编译(如，HASH_AREA_SIZE)。

V$SQL_PLAN中数据可以：

l         确认当前的执行计划

l         鉴别创建表索引效果

l         寻找cursor包括的存取路径(例如，全表查询或范围索引查询)

l         鉴别索引的选择是否最优

l         决定是否最优化选择的详细执行计划(如，nested loops join)如开发者所愿。

　　本视图同时也可被用于当成一种关键机制在计划对比中。计划对比通常用于下列各项发生改变时：

l         删除和新建索引

l         在数据库对象上执行分析语句

l         修改初始参数值

l         从rule-based切换至cost-based优化方式

l         升级应用程序或数据库到新版本之后

　　如果之前的计划仍然在(例如，从V$SQL_PLAN选择出记录并保存到oracle表中供参考)，那么就有可能去鉴别一条SQL语句在执行计划改变后性能方面有什么变化。

注意：

Oracle公司强烈推荐你使用DBMS_STATS包而非ANALYZE收集优化统计。该包可以让你平行地搜集统计项，收集分区对象(partitioned objects)的全集统计，并且通过其它方式更好的调整你的统计收集方式。此处，cost-based优化器将最终使用被DBMS_STATS收集的统计项。浏览Oracle9i Supplied PL/SQL包和类型参考以获得关于此包的更多信息。

不过，你必须使用ANALYZE语句而非DBMS_STATS进行统计收集，不涉及cost-based优化器，就像：

·使用VALIDATE或LIST CHAINED ROWS子句

·在freelist blocks上收集信息。

V$SQL_PLAN中的常用列：

除了一些新加列，本视图几乎包括所有的PLAN_TABLE列，那些同样存在于PLAN_TABLE中的列拥有相同的值：

l         ADDRESS：当前cursor父句柄位置

l         HASH_VALUE：在library cache中父语句的HASH值。

ADDRESS和HASH_VALUE这两列可以被用于连接v$sqlarea查询 cursor-specific 信息。

l         CHILD_NUMBER：使用这个执行计划的子cursor数

列ADDRESS,HASH_VALUE以及CHILD_NUMBER可被用于连接v$sql查询子cursor信息。

l         OPERATION: 在各步骤执行内部操作的名称，例如：TABLE ACCESS

l         OPTIONS: 描述列OPERATION在操作上的变种，例如：FULL

l         OBJECT_NODE: 用于访问对象的数据库链接database link 的名称对于使用并行执行的本地查询该列能够描述操作中输出的次序。

l         OBJECT#: 表或索引对象数量

l         OBJECT_OWNER: 对于包含有表或索引的架构schema 给出其所有者的名称

l         OBJECT_NAME: 表或索引名

l         OPTIMIZER: 执行计划中首列的默认优化模式；例如，CHOOSE。比如业务是个存储数据库，它将告知是否对象是最优化的。

l         ID: 在执行计划中分派到每一步的序号。

l         PARENT_ID: 对ID 步骤的输出进行操作的下一个执行步骤的ID。

l         DEPTH: 业务树深度(或级)。

l         POSITION: 对于具有相同PARENT_ID 的操作其相应的处理次序。

l         COST: cost-based方式优化的操作开销的评估，如果语句使用rule-based方式，本列将为空。

l         CARDINALITY: 根据cost-based方式操作所访问的行数的评估。

l         BYTES: 根据cost-based方式操作产生的字节的评估，。

l         OTHER_TAG: 其它列的内容说明。

l         PARTITION_START: 范围存取分区中的开始分区。

l         PARTITION_STOP: 范围存取分区中的停止分区。

l         PARTITION_ID: 计算PARTITION_START和PARTITION_STOP这对列值的步数

l         OTHER: 其它信息即执行步骤细节，供用户参考。

l         DISTRIBUTION: 为了并行查询，存储用于从生产服务器到消费服务器分配列的方法

l         CPU_COST: 根据cost-based方式CPU操作开销的评估。如果语句使用rule-based方式，本列为空。

l         IO_COST: 根据cost-based方式I/O操作开销的评估。如果语句使用rule-based方式，本列为空。

l         TEMP_SPACE: cost-based方式操作(sort or hash-join)的临时空间占用评估。如果语句使用rule-based方式，本列为空。

l         ACCESS_PREDICATES: 指明以便在存取结构中定位列，例如，在范围索引查询中的开始或者结束位置。

l         FILTER_PREDICATES: 在生成数据之前即指明过滤列。

CONNECT BY操作产生DEPTH列替换LEVEL伪列，有时被用于在SQL脚本中帮助indent PLAN_TABLE数据

V$SQL_PLAN中的连接列

　　列ADDRESS,HASH_VALUE和CHILD_NUMBER被用于连接V$SQL或V$SQLAREA来获取cursor-specific信息，例如，BUFFER_GET,或连接V$SQLTEXT获取完整的SQL语句。

Column View                                                            Joined                 Column(s)

ADDRESS, HASH_VALUE                                    V$SQLAREA    ADDRESS, HASH_VALUE

ADDRESS,HASH_VALUE,CHILD_NUMBER      V$SQL       ADDRESS,HASH_VALUE,CHILD_NUMBER

ADDRESS, HASH_VALUE                                    V$SQLTEXT      ADDRESS, HASH_VALUE

确认SQL语句的优化计划

　　下列语句显示一条指定SQL语句的执行计划。查看一条SQL语句的执行计划是调整优化SQL语句的第一步。这条被查询到执行计划的SQL语句是通过语句的HASH_VALUE和ADDRESS列识别。分两步执行：

1.SELECT sql_text, address, hash_value FROM v$sql

WHERE sql_text like '%TAG%';

SQL_TEXT   ADDRESS HASH_VALUE

-------- -------- ----------

          82157784 1224822469

2.SELECT operation, options, object_name, cost FROM v$sql_plan

WHERE address = '82157784' AND hash_value = 1224822469;

OPERATION            OPTIONS       OBJECT_NAME        COST

-------------------- ------------- ------------------ ----

SELECT STATEMENT                                         5

SORT

    AGGREGATE

      HASH JOIN                                          5

      TABLE ACCESS   FULL          DEPARTMENTS           2

       TABLE ACCESS   FULL          EMPLOYEES             2

按照OracleOnlineBook中的描述，v$sesstat存储session从login到logout的详细资源使用统计。

　　类似于v$sysstat,该视图存储下列类别的统计：

l         事件发生次数的统计，如用户提交数。

l         数据产生，存取或者操作的total列(如：redo size)

l         执行操作所花费的时间累积，例如session CPU占用(如果TIMED_STATISTICS值为true)

注意：

如果初始参数STATISTICS_LEVEL被设置为TYPICAL或ALL，时间统计被数据库自动收集如果STATISTICS_LEVEL被设置为BASIC，你必须设置TIMED_STATISTICS值为TRUE以打开收集功能。

如果你已设置了DB_CACHE_ADVICE,TIMED_STATISTICS或TIMED_OS_STATISTICS，或在初始参数文件或使用ALTER_SYSTEM或ALTER SESSION，那么你所设定的值的值将覆盖STATISTICS_LEVEL的值。

v$sysstat和v$sesstat差别如下：

n         v$sesstat只保存session数据，而v$sysstat则保存所有sessions的累积值。

n         v$sesstat只是暂存数据，session退出后数据即清空。v$sysstat则是累积的，只有当实例被shutdown才会清空。

n         v$sesstat不包括统计项名称，如果要获得统计项名称则必须与v$sysstat或v$statname连接查询获得。

v$sesstat可被用于找出如下类型session：

n         高资源占用

n         高平均资源占用比(登陆后资源使用率)

n         默认资源占用比(两快照之间)

在V$SESSTAT中使用统计

　　多数v$sesstat中的统计参考是v$sysstat描述的子集，包括session logical reads, CPU used by this session, db block changes, redo size, physical writes, parse count (hard), parse count (total), sorts (memory), and sorts (disk).

V$SESSTAT常用列说明

n         SID：session唯一ID

n         STATISTIC#：资源唯一ID

n         VALUE：资源使用

示例1：下列找出当前session中最高的logical和Physical I/O比率.

　　下列SQL语句显示了所有连接到数据库的session逻辑、物理读比率(每秒)。logical和physical I/O比率是通过自登陆后的时间消耗计算得出。对于sessions连接到数据库这种长周期操作而言也许不够精确，不过做个示例却足够了。

先获得session逻辑读和物理读统计项的STATISTIC#值：

SELECTname, statistic#

FROM V$STATNAME

WHEREnameIN ('session logical reads','physical reads') ;

NAME                           STATISTIC#

------------------------------ ----------

session logical reads                   9

physical reads                         40

通过上面获得的STATISTIC#值执行下列语句：

SELECT ses.sid

     , DECODE(ses.action,NULL,'online','batch')          "User"

     , MAX(DECODE(sta.statistic#,9,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Log IO/s"

     , MAX(DECODE(sta.statistic#,40,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Phy IO/s"

     , 60*24*(sysdate-ses.logon_time)                    "Minutes"

FROM V$SESSION ses

    , V$SESSTAT sta

WHERE ses.status     = 'ACTIVE'

AND sta.sid        = ses.sid

AND sta.statistic# IN (9,40)

GROUP BY ses.sid, ses.action, ses.logon_time

ORDER BY

        SUM( DECODE(sta.statistic#,40,100*sta.value,sta.value) )

      / greatest(3600*24*(sysdate-ses.logon_time),1) DESC;

SID User   Log IO/s Phy IO/s Minutes

----- ------ -------- -------- -------

1951 batch       291    257.3       1

470 online    6,161     62.9       0

730 batch     7,568     43.2     197

2153 online    1,482     98.9      10

2386 batch     7,620     35.6      35

1815 batch     7,503     35.5     26

1965 online    4,879     42.9      19

1668 online    4,318     44.5       1

1142 online      955     69.2      35

1855 batch       573     70.5       8

1971 online    1,138     56.6       1

1323 online    3,263     32.4       5

1479 batch     2,857     35.1       3

421 online    1,322     46.8      15

2405 online      258     50.4       8

示例2：又例如通过v$sesstat和v$statname连接查询某个SID各项信息。

select a.*,b.name

from v$sesstat a,v$statname b

where a.sid=10and a.statistic#=b.statistic#;

(2)-v$mystat

　　本视图是v$sesstat的一个子集，返回当前session的统计项。当通过触发器审计session资源使用，可以使用v$mystat来捕获资源使用，这将比直接扫描v$sesstat的列要节省资源的多。

按照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)

执行：

select1-((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) )

执行：

select1-(a.value/b.value)

from v$sysstat a,v$sysstat b

Wherea.name='parse count (hard)'and b.name='parse count (total)';

l         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

wherea.name='sorts (memory)'and

         b.name='sorts (memory)'andc.name='sorts (disk)';

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

公式：1 - (parse count/execute count)

执行：

select1-(a.value/b.value)

from v$sysstat a,v$sysstat b

where a.name='parse count (total)'and b.name='execute count';

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

公式：1 - (parse time cpu / CPU used by this session)

执行：

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

l         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'andc.name='user rollbacks';

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

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

l         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)'andc.name='sorts (disk)';

V$SQLTEXT中的常用列

HASH_VALUE：SQL语句的Hash值
ADDRESS：sql语句在SGA中的地址
SQL_TEXT：SQL文本。
PIECE：SQL语句块的序号

V$SQLTEXT中的连接列
Column      View      Joined Column(s)
HASH_VALUE, ADDRESS   V$SQL, V$SESSION   HASH_VALUE, ADDRESS
HASH_VALUE. ADDRESS   V$SESSION    SQL_HASH_VALUE, SQL_ADDRESS

示例：已知hash_value:3111103299，查询sql语句：
select * from v$sqltext
where hash_value='3111103299'
order by piece

本视图持续跟踪所有shared pool中的共享cursor，在shared pool中的每一条SQL语句都对应一列。本视图在分析SQL语句资源使用方面非常重要。

V$SQLAREA中的信息列

HASH_VALUE：SQL语句的Hash值。
ADDRESS：SQL语句在SGA中的地址。
这两列被用于鉴别SQL语句，有时，两条不同的语句可能hash值相同。这时候，必须连同ADDRESS一同使用来确认SQL语句。
PARSING_USER_ID：为语句解析第一条CURSOR的用户
VERSION_COUNT：语句cursor的数量
KEPT_VERSIONS：
SHARABLE_MEMORY：cursor使用的共享内存总数
PERSISTENT_MEMORY：cursor使用的常驻内存总数
RUNTIME_MEMORY：cursor使用的运行时内存总数。
SQL_TEXT：SQL语句的文本（最大只能保存该语句的前1000个字符）。
MODULE,ACTION：使用了DBMS_APPLICATION_INFO时session解析第一条cursor时的信息

V$SQLAREA中的其它常用列

SORTS: 语句的排序数
CPU_TIME: 语句被解析和执行的CPU时间
ELAPSED_TIME: 语句被解析和执行的共用时间
PARSE_CALLS: 语句的解析调用(软、硬)次数
EXECUTIONS: 语句的执行次数
INVALIDATIONS: 语句的cursor失效次数
LOADS: 语句载入(载出)数量
ROWS_PROCESSED: 语句返回的列总数

V$SQLAREA中的连接列
Column      View         Joined Column(s)
HASH_VALUE, ADDRESS   V$SESSION       SQL_HASH_VALUE, SQL_ADDRESS
HASH_VALUE, ADDRESS   V$SQLTEXT, V$SQL, V$OPEN_CURSOR HASH_VALUE, ADDRESS
SQL_TEXT     V$DB_OBJECT_CACHE     NAME

示例：
1.查看消耗资源最多的SQL：
SELECT hash_value, executions, buffer_gets, disk_reads, parse_calls
FROM V$SQLAREA
WHERE buffer_gets > 10000000 OR disk_reads > 1000000
ORDER BY buffer_gets + 100 * disk_reads DESC;

2.查看某条SQL语句的资源消耗：
SELECT hash_value, buffer_gets, disk_reads, executions, parse_calls
FROM V$SQLAREA
WHERE hash_Value = 228801498 AND address = hextoraw('CBD8E4B0');

1、shutdown normal 
   正常方式关闭数据库。


2、shutdown immediate 
   立即方式关闭数据库。 
   在SVRMGRL中执行shutdown immediate，数据库并不立即关闭， 
   而是在Oracle执行某些清除工作后才关闭（终止会话、释放会话资源）， 
   当使用shutdown不能关闭数据库时，shutdown immediate可以完成数据库关闭的操作。 

3、shutdown abort 
   直接关闭数据库，正在访问数据库的会话会被突然终止， 
   如果数据库中有大量操作正在执行，这时执行shutdown abort后，重新启动数据库需要很长時間

--------------------------------------------------------

shutdown abort 的时候，跟kill 进程是一样的效果
数据库立即关闭，这个时候文件状态可能不一致
因为正常关闭数据库会同步校验各文件，使得重新启动的时候文件时间点一致并且不用进行崩溃恢复

若检查点信息一致，则做崩溃恢复
若检查点信息不一致（正好在更新文件头）则需要做介质恢复

这些问题都好处理，最怕的问题是这个时候系统有大量IO，结果这样造成写的突然中断，碰巧造成文件块的逻辑坏块，那麻烦比较大一些，尤其是系统表空间的block损坏


虽然shutdown abort 出错的几率很小，1000个人可能只有一个人碰到，但是我们还是要小心。
正确的处理流程是，shutdown immediate ,若数据库迟迟不能down下来，在os上观察IO状况，几乎没有io的时候，另开一窗口shutdown  abort ，几乎不会出问题了

按照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统计项，在调优方面相当有用。下列按字母先后排序：

 

数据库使用状态的一些关键指标：

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

 

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

 

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

 

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

 

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

 

 

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

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

 

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