wait_event

最新推荐文章于 2024-07-03 17:30:25 发布

BaldwinSu

最新推荐文章于 2024-07-03 17:30:25 发布

阅读量592

点赞数 1

CC 4.0 BY-SA版权

分类专栏： warehouse_11gR2 文章标签：数据库 wait event

本文链接：https://blog.csdn.net/sudahai102448567/article/details/113994779

warehouse_11gR2 专栏收录该内容

28 篇文章

订阅专栏

本文章为网络笔记，看了warehouse老师的视频受益匪浅，更是感觉自己技术太过初级，特写了本笔记，方便以后反复学习！
如有任何不妥，请发邮件至102448567@qq.com删除文章！
关于warehouse：
http://blog.itpub.net/19602/viewspace-1059211/
11gR2视频第四版 7_05_wait_event
几种报告类型：

ash: Active Session History 活动的历史会话
awr: Auto Workload Repository 自动负载信息库
addm: Auto Database Diagnostic Monitoring 自动数据库诊断监控

操作系统要是负载非常高的话就要先看进程(top)，要是Oracle的负载非常高的话就要先看session
waitevent:有些session不能获得某一种资源无法进行下去，不能执行了，一直在那等着，其实背后他就是隐藏一个waitevent或者是一种现象，第一时间查下面这个视图

v$session_wait

SELECT *
     FROM v$session_wait
    WHERE wait_class <> 'Idle'
 没有或者很快就消失了没有关系，主要是长时间存在的等待事件

在这里插入图片描述
实验模拟
session 1

SQL> select * from t1;

	ID NAME 		       AGE
---------- -------------------- ----------
	11 erha 			31
	 2 lisi 			22
	 3 bb				20
	 4 zhaoliu			20

SQL> update t1 set id = 1 where name = 'erha';

1 row updated.
不提交

session 2

SQL> update t1 set age = 30 where name = 'erha';
一直在等待

诊断过程：
1.

下图中的SID是被阻塞的session(最重要)
wait_class:类别
state:状态
seconds_in_wait:等待的时间

在这里插入图片描述
2.分析这个sid

SELECT *
     FROM v$session
    WHERE sid = '10';

state是active的说明是有事务的
在这里插入图片描述
在v$lock中通过lockwait查是TYPE锁，请求的模式是REQUEST

sid 10正在被实例1上的138号session阻塞

虽然138是inactive(status)但是TADDR不为空说明还有事务没有提交

通过PREV_SQL_ID在v$sql中可以查看是哪个sql没有提交
在这里插入图片描述
session 3
kill掉阻塞其他session的session

SQL> alter system kill session '138,9';

System altered.

session 2
自动update了

SQL> update t1 set age = 30 where name = 'erha';

1 row updated.

session 1
要执行一个语句才会报下面的提示

SQL> select * from t1;
select * from t1
*
ERROR at line 1:
ORA-00028: your session has been killed

等待事件视图，每一个等待事件都有三个参数，等待事件不一样参数表示的意义不一样还有的没有参数

v$event_name

在这里插入图片描述
P1TEXT是文本描述
P1是十进制的值
P1RAW是十六进制数的值

以enq: TX - row lock contention为例，P2跟undo相关，P3的值是序号，对于该等待事件P1、P2、P3合起来就是一个事务，是阻塞这个138 session的事务
在这里插入图片描述

当系统很慢的时候首先要看v$session_wait有没有wait_class不为Idle的等待事件，有等待事件而且等待时间很长的时候就可以从这个等待事件入手分析，每一个等待事件背后都一种现象

v$system_event当系统可用的时候性能可接受的时候主要的等待事件
可以按照TOTAL_WAITS（总的等待次数）、TIME_WAITED（总的等待时间）、AVERAGE_WAIT（平均等待时间）排序

SELECT *
            FROM v$system_event
           ORDER BY total_waits DESC

等待次数最多的是rdbms ipc message
在这里插入图片描述
这里面没记录啥信息，查一下官方文档

此事件是空闲事件没有影响

The background processes (LGWR, DBWR, LMS0) use this event to indicate
that they are idle and are waiting for the foreground processes to
send them an IPC message to do some work.

Wait Time: Up to 3 seconds. The parameter timeout shows the true sleep
time.