由一条报警信息发现的一系列问题(r7笔记第67天)-白红宇的个人博客

发布日期：2021-06-30 13:32:50 浏览次数：3 分类：技术文章

本文共 1196 字，大约阅读时间需要 3 分钟。

今天看到一条报警短信，提示是某个表空间的问题。

0?wx_fmt=png

而DB time的情况呢，印象中么有报负载突然暴增的短信报警。 0?wx_fmt=png

	Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	1.2	1.7	0.03	0.07
DB CPU(s):	0.6	0.8	0.01	0.03
Redo size:	11,675,379.4	16,550,679.0
Logical reads:	88,012.5	124,764.0
Block changes:	67,547.0	95,752.7
Physical reads:	2,804.4	3,975.4
Physical writes:	1,236.4	1,752.7
User calls:	17.7	25.1

可以看出redo的生成量还是不少，查看top等待事件，发现近一半多的DB time在DB CPU上，那么剩下的加起来还不到60%，可见还是很可能是sql执行时间过长导致了DB time的计算出现二来一些偏差。

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
DB CPU		2,081		48.72
db file scattered read	403,937	247	1	5.78	User I/O
db file sequential read	40,286	159	4	3.72	User I/O
enq: RO - fast object reuse	3,259	150	46	3.51	Application
log file switch (checkpoint incomplete)	295	121	409	2.83	Configuration

查看top sql的情况如下：

Elapsed Time (s)	Executions	%Total	%CPU	%IO	SQL Module	SQL Text
2,334.45	1	54.65	74.10	14.43	DBMS_SCHEDULER	DECLARE job BINARY_INTEGER := ...
311.81	6	7.30	48.02	63.04	DBMS_SCHEDULER	SELECT COUNT(DISTINCT CN) FROM...
228.24	6	5.34	70.22	31.59	JDBC Thin Client	select total from ( select STA...

Deleted Oracle managed file /U01/app/oracle/oradata/test/arch/testX/archivelog/2016_01_01/o1_mf_1_180672_c8d4j7df_.arc

转载地址：https://jeanron100.blog.csdn.net/article/details/102507274 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！

关于作者

喝酒易醉，品茶养心，人生如梦，品茶悟道，何以解忧？唯有杜康！

-- 愿君每日到此一游！