我得到了这个问题
SQL> CREATE USER DEMO IDENTIFIED BY DEMO DEFAULT TABLESPACE USERS;
User created.
SQL> GRANT CONNECT, RESOURCE TO DEMO;
Grant succeeded.
SQL> GRANT UNLIMITED TABLESPACE TO DEMO;
Grant succeeded.
字符串
第一届会议:
SQL> CONNECT DEMO/DEMO
Connected.
SQL> CREATE TABLE D_LOCK(DIGIT NUMBER, STRING VARCHAR(10));
Table created.
INSERT INTO D_LOCK VALUES (1, 'ONE');
SQL>
1 row created.
INSERT INTO D_LOCK VALUES (2, 'TWO');
SQL>
1 row created.
SQL> COMMIT;
Commit complete.
SQL> UPDATE D_LOCK SET STRING='001' WHERE DIGIT=1;
1 row updated.
型
第二届会议:
SQL> CONNECT DEMO/DEMO
Connected.
SQL> delete from D_LOCK WHERE DIGIT=1;
型
<-第二个会话在等待第一个会话提交时挂起
几秒钟后,我提出了下一个请求:
SELECT
ash.snap_id,
ash.sample_time,
ash.blocking_session as ,
ash.blocking_session_serial#,
' -> ' as is_blocking,
ash.session_id as blocked_sid,
ash.session_serial# as blocked_serial,
ash.sql_id as blocked_sql_id,
sql.sql_text as blocked_sql_text,
ash.sql_opname as blocked_sql_opname,
ash.event as blocked_event,
round(ash.time_waited / 1000000) AS blocked_sec
FROM
dba_hist_active_sess_history ash,
v$sql sql
WHERE
blocking_session IS NOT NULL
AND ash.sql_id = sql.sql_id
and BLOCKING_SESSION_STATUS = 'VALID'
--and time_waited>0
ORDER BY
sample_id DESC;
型
但是字段blocked_sec为0。为什么?应该还有一个等待时间(几秒)。
1条答案
按热度按时间tmb3ates1#
dba_hist_active_sess_history
仅在ASH快照间隔(默认间隔为1小时)填充。这意味着将旧数据存储在磁盘上,以便永久驻留并保留一段时间(默认为8天)。相反,您应该通过查询v$active_session_history
来使用内存中的数据。此视图在每次轮询 Flink 时每秒更新一次,并尽可能长时间地保留在内存中,至少在快照将其写入磁盘之前,并且通常更长(通常为数小时)。另外,你可能不想使用
time_waited
。根据文档:如果采样时会话在CPU上,则为会话上次等待的事件的总等待时间;如果采样时会话正在等待,则为0
这与
v$session
的seconds_in_wait
不同,因为它正好相反:如果在CPU上,它应该显示0,如果在等待中,它应该显示非零。(因为session_state
被翻转为WAITING
)。(通常是亚秒)会不断地将其重置为0,即使它们是累积的时钟时间。ASH或任何其他轮询监视器将显示的值必须取决于它的一秒轮询捕获会话的精确微秒,使它很少毫无意义。此外,根据ASH的文档和一些测试,很明显它正在做一些不同的事情,即使它以某种方式使用了v$session
的值。无论如何,对于像你正在测试的TX争用,它将始终显示0。因此,
time_waited
在ASH数据的上下文中实际上没有意义。您想要的是计数行数。在v$active_session_history
中,一行等于一秒的时间,因此COUNT(*) secs
(您需要GROUP BY
您的其他属性)。在dba_hist_active_sess_history
中,一行等于(近似值,因为它只保留每10个记录)* 10 * 秒的时间,所以相乘:COUNT(*)*10 secs