trackbacks-1
--v$session_wait视图中的p1、p2、p3表示等待事件的具体含义，如果Wait Event是db file scattered read,那么p1=file_id/p2=block_id/p3=blocks,然后通过dba_extents即可
确定出热点对象.
--如果是latch free的话,那么p2为闩锁号,它指向v$latch.
--求等待事件及其对应的latch
col event format a32;
col name format a32;
select sid,event,p1 as "p1 as file_id", p2 as "p2 as block_id/latch", p3 as "p3 as blocks",l.name
&from v$session_wait sw,v$latch l
&where event not like '%SQL%' and event not like '%rdbms%' and event not like '%mon%' and sw.p2 = l.latch#(+);
--求等待事件及其热点对象
col owner format a18;
col segment_name format a32;
col segment_type format a32;
select owner, segment_name, segment_type from dba_extents
&where file_id = &file_id and &block_id between block_id and block_id + &blocks - 1;
--综合以上两条SQL,同时显示latch及热点对象(速度较慢)
select sw.sid, event, l.name, de.segment_name from v$session_wait sw, v$latch l, dba_extents de
&where event not like '%SQL%' and event not like '%rdbms%' and event not like '%mon%'
&and sw.p2 = l.latch#(+) and sw.p1 = de.file_id(+) and p2 between de.block_id and de.block_id + de.blocks - 1;
--如果是非空闲等待事件,通过等待会话的SID可以求出该会话在执行的SQL
select sql_text from v$sqltext_with_newlines st, v$session se
& where st.address = se.sql_address and st.hash_value = se.sql_hash_value and se.sid = &wait_
阅读(...) 评论()oracle数据库阻塞检查处理方法
oracle数据库阻塞检查处理方法
----------------------------
数据库阻塞检查处理方法 当应用服务器发生阻塞时(特别是集群1)，应先按下面方法检查数据库，以判明应用服务器阻塞是否由数据库阻塞引起。如果 select * from dba_waiters 有输出，转 阻塞情形A ；如果 SELECT * FROM v$session_wait WHERE event LIKE 'library%' 有输出，转 阻塞情形B ；ELSE 马上联系DBA。阻塞情形A：1、查看dba_waitersselect * from dba_waiters 发现有大量的等待session。如果无输出，数据库应没有问题。2、查看等待事件情况select p.spid pid,s.sid,s.SERIAL#,s.username,event,w.p1,w.P1TEXT,w.p2,w.P2TEXT,w.p3,w.P3TEXT,sq.SQL_TEXT,w.WAIT_TIME,w.SECONDS_IN_WAIT,w.STATEfrom v$session_wait w, v$session s, v$process p, v$sql sqwhere event not like 'SQL%' and w.sid = s.sid and s.paddr = p.addr ands.SQL_ADDRESS = sq.ADDRESS and s.SQL_HASH_VALUE = sq.HASH_VALUE发现有大量EVENT列的值是enqueue的记录。3、查看锁等待情况SELECT lpad(' ', DECODE(request, 0, 0, 1)) || sid sess,id1,id2,lmode,request,typeFROM V$LOCKWHERE id1 IN (SELECT id1 FROM V$LOCK WHERE lmode = 0)ORDER BY id1, request检查是否存在lmode为3的记录，发现session 441把持着一个个DML级的三级锁(存在一条sess=441,lmode=3的记录)4、查看sid 为441的session情况，记录以下输出并发出到公告版：select p.SPID, s.*from v$session s, v$process pwhere sid in (441) and p.ADDR = s.PADDRSPID SID SERIAL#439查看该session的用户名、机器名、程序名、执行的sql等信息：SELECT a.username,a.machine,a.program,a.sid,a.serial#,a.status,c.piece,c.sql_textFROM v$session a,v$sqltext cWHERE a.sid = &SID&and a.sql_address=c.address(+)ORDER BY c.piece查看该session锁住的对象：select b.object_name, a.* from v$locked_object a, dba_objects bwhere session_id = &SID& and a.object_id = b.object_idand a.locked_mode = 3--查看是否有其他进程block这些进程select * from dba_waiters WHERE waiting_session IN (XXX)--查看这些session在等待什么事件SELECT * FROM v$session_wait WHERE sid IN (XXX)SQL*Net message from client 为 等待和客户端的通讯5、杀掉sid为441的sessionalter system kill session '441,47439';(其中441,47439分别是第四步查出的SID和SERIAL#的值)6、如果第五步不成功，就需要在操作系统下终止进程。kill -9 26358 (其中26358 是第四步查出SPID的值)处理完成后，select * from dba_waiters无记录返回，数据库恢复正常。阻塞情形B：[一、分析解决过程]1。查询发现数据库中有大量的library cache pin等待SELECT * FROM v$session_wait WHERE event LIKE 'library%'SID SEQ# EVENT P1TEXT P149 10781 library cache pin75 60508 library cache pin71 56470 library cache pin...2。分析library cache pin在等待的对象，发现是p_zs_bdsp_gbSELECT kglnaown "Owner", kglnaobj "Object",sw.P1RAWFROM x$kglob p,v$session_wait swWHERE p.kglhdadr=sw.P1RAW and sw.SID=987db_zgxt p_zs_bdsp_gb AC77103。随便选等待中的一个session，查找引起library cache pin等待的session。发现其他session都在等待173SELECT s.sid, kglpnmod "Mode", kglpnreq "Req"FROM x$kglpn p, v$session s,V$SESSION_WAIT SWWHERE p.kglpnuse=s.saddrAND P.kglpnhdl=sw.P1RAW AND Sw.SID=987 order by mode descSID Mode Req173 3 0692 0 2...4。查找173的等待情况，发现它也是在等待library cache pin。SELECT * FROM v$session_wait WHERE sid= 173173 5502 library cache pin handle address
AC77105。继续查找是哪个session引起173的等待，发现是121SELECT s.sid, kglpnmod "Mode", kglpnreq "Req"FROM x$kglpn p, v$session s,V$SESSION_WAIT SWWHERE p.kglpnuse=s.saddrAND P.kglpnhdl=sw.P1RAW AND Sw.SID=173121 2 0173 0 36。查找121的session等待情况，发现它是在等待SQL*Net message from client，这是客户端和服务器之间的通讯。因此可判定121是引起一系列等待的原因。SID SEQ# EVENT P1TEXT P1 P1RAW121 22946 SQL*Net message from client7。查看121session的情况select p.spid,s.* from v$session s ,v$process p where s.paddr=p.addr and S.sid in (121)08D 89 8 40 DB_ZGXT 2
CDA0 ACTIVE DEDICATED 40 DB_ZGXT weblogic app028。在操作系统中发现25645进程（也即是121session）已经运行了6个多小时。[db2:oracle2]prstatPID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP25645 oracle2 24G 13G cpu194 0 0 6:16:02 2.3% oracle/29946 oracle2 24G 13G sleep 60 0 0:24:33 2.1% oracle/29。杀掉session 121后，应用恢复正常。SQL& alter system kill session '121,89';alter system kill session '121,89'*ERROR at line 1:ORA-00031: session marked for kill[db2:oracle2]kill -9 25645------------------------------------------------------------------------------------ 查找使用了什么语句，这个不一定有用(对于等待commit/rollback)-- 的操作失效select st.SQL_TEXTfrom v$sqltext st,v$session siwhere st.ADDRESS = si.SQL_ADDRESSand st.HASH_VALUE = si.SQL_HASH_VALUEand si.SID in ()order by st.PIECE------------------------------------------------------------ 查找锁的类型、锁住的对象select distinct lk.TYPE,lk.LMODE,do.owner || '.' || do.object_namefrom v$lock lk,v$locked_object lo,dba_objects dowhere do.object_id = lo.OBJECT_IDand lo.SESSION_ID = lk.SIDand lk.SID in ()
---------数据恢复 oracle数据库恢复专家
QQ:9417901 网站：-----PLSQL执行sql的几种方法_百度知道
PLSQL执行sql的几种方法
plsql很方便我们执行sql。下面就简单介绍我常用的几种（当然每次svn的分支也可以ant脚本自动执行某个文件下的所以sql文件）首先打开plsq的命令窗口1）执行sql文件（可以把需要执行的sql放一个文件中）输入@'' 在单引号中输入sql文件的路径既可，比如D:\db下的jbpm.oracle.sql文件，见下图（sql文件内容是select * from system_menu r where r.menu_name='销售订单' ;） 2）导入dmp文件。导入dmp文件前先删除对应的user（下面以test_user为例）drop user test_$ impdp system/test123@SYSTEM directory=data_pump_dir schemas=test_user dumpfile=date.DMP REMAP_SCHEMA=test_user:test_userTABLE_EXISTS_ACTION=replace logfile=imp.alter user test_user identified by ）当需要重新从正式版数据库到数据到测试版时，我们需要重启测试版服务器或者kill掉应用程序服务器（比如tomcat）的session连接v$session 这张表可以查找到连接 oracle 数据库的应用程序基本信息。因此可以通过该表来kill掉相应程序的session如果你想kill到连接到用户 test_user ，可以执行下面的sql： select * from v$session r where r.USERNAME=‘test_user’ ;然后kill对应的session'就行了，参考下面的截图： 比如你要kill 第一条；就执行下面的sql ： alter system kill session '21,77' ; //因为sid, serial#.这2列很唯一的。 下面补充一些连接oracle的应用程序信息和oracle 操作 session 情况。 1.查找到连接 oracle 数据库的应用程序基本信息。 select sid, serial#,username, --连接用户名program, --应用程序名machine, --机器名osuser, --操作系统用户logon_time --登录时间from v$ 2.如何查看session级的等待事件？当我们对数据库的性能进行调整时，一个最重要的参考指标就是系统等待事 件。$system_event,v$session_event,v$session_wait这三个视图里记录的就是系统级和session级的等待 事件，通过查询这些视图你可以发现数据库的一些操作到底在等待什么？是磁盘I/O，缓冲区忙，还是插锁等等。通过如下sql你可以查询你的每个应用程序到底在等待什么，从而针对这些信息对数据库的性能进行调整。Select s.username,s.program,s.status,se.event,se.total_waits,se.total_timeouts,se.time_waited,se.average_waitfrom v$session s, v$session_event seWhere s.sid=se.sid And se.event not like 'SQl*Net%' And s.status ='ACTIVE'And s.username is not null 3.oracle中查询被锁的表并释放session SELECT A.OWNER,A.OBJECT_NAME,B.XIDUSN,B.XIDSLOT,B.XIDSQN,B.SESSION_ID,B.ORACLE_USERNAME, B.OS_USER_NAME,B.PROCESS, B.LOCKED_MODE, C.MACHINE,C.STATUS,C.SERVER,C.SID,C.SERIAL#,C.PROGRAMFROM ALL_OBJECTS A,V$LOCKED_OBJECT B,SYS.GV_$SESSION CWHERE ( A.OBJECT_ID = B.OBJECT_ID ) AND (B.PROCESS = C.PROCESS ) ORDER BY 1,2释放session Sql:alter system killsession'sid,serial#'alter systemkillsession'379,21132'alter systemkillsession'374,.查看占用系统io较大的session SELECT se.sid,se.serial#,pr.SPID,se.username,se.status,se.terminal,se.program,se.MODULE,se.sql_address,st.event,st.p1text,si.physical_reads,si.block_changesFROM v$session se, v$session_wait st,v$sess_io si,v$process prWHERE st.sid=se.sid AND st.sid=si.sid AND se.PADDR=pr.ADDR AND se.sid&6 AND st.wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC5.找出耗cpu较多的session select a.sid,spid,status,substr(a.program,1,40) prog,a.terminal,osuser,value/60/100 valuefrom v$session a,v$process b,v$sesstat cwhere c.statistic#=12 and c.sid=a.sid and a.paddr=b.addr order by value desc6.另外oracle是否运行可以用sql语句查出：select status from v$其中,status可能返回三种值：open(数据库打开），mount(数据库已经加载，但还没有打开），started(数据库进程已经启动，但是还没有加载），这个数据字典可以在数据库没有打开的情况下查询，但是需要用sys用户执行。反应时间，请求数需要具体说明到底是那个参数。你可以参考字典;v$status,v$session(看当前有多少个连接用户等).
其他类似问题
为您推荐：
您可能关注的推广
plsql的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
read by other session等待事件
下载积分：900
内容提示：read by other session等待事件
文档格式：TXT|
浏览次数：2|
上传日期： 21:58:11|
文档星级：
该用户还上传了这些文档
read by other session等待事件
官方公共微信Oracle动态性能视图v$session_wait&&&v$session_event
这是一个寻找性能瓶颈的关键视图。它提供了任何情况下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字段有四种含义sWaiting：SESSION正等待这个事件。
Waited unknown
time：由于设置了timed_statistics值为false，导致不能得到时间信息。表示发生了等待，但时间很短。
Wait short time：表示发生了等待，但由于时间非常短不超过一个时间单位，所以没有记录。
Waited knnow time：如果session等待然后得到了所需资源，那么将从waiting进入本状态。
2.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&&&&&&&
1.列出当前系统的等待事件
这个按事件和wait_time的分组查询列出下列的信息：
多数的session都是空闲事件如：SQL*Net message from client, pipe get, PMON
session的cpu占用可以通过上次session的非等待事件大致算出，除此问题外：看起来多数session没有在等待什么事情(难道他们都在干活？)但其最后等待事件都是SQL*Net
message from client。
2.列出指定ID的等待事件
select * from v$session_wait t where t.sid=2677
3.应用p1,p2,p3进行等待事件的分析
v$session_wait视图的列代表的缓冲区忙等待事件如下：
P1―与等待相关的数据文件的全部文件数量。
P2―P1中的数据文件的块数量。
P3―描述等待产生原因的代码。
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 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。
块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。
200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。
Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。
220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。
230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。
231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束。
V$SESSION_EVENT
本视图记录了每个session的每一项等待事件。由上文所知V$SESSION_WAIT显示了session的当前等待事件，而V$SESSION_EVENT则记录了session自启动起所有的事件。
V$SESSION_EVENT中的常用列
SID：session标识
EVENT：session等待的事件
TOTAL_WAITS：此session当前事件的总等待数
TIME_WAITED：此session总等待时间(单位，百分之一秒)
AVERAGE_WAIT：此session当前事件平均等待时间(单位，百分之一秒)
TOTAL_TIMEOUTS：等待超时次数
其它用法与V$SESSION_WAIT相似，不详述了
的等待事件是衡量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也有非常详尽的描述，在此就不多费口舌了。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}