问题描述
嗨,团队,
运行SQL时不能理解几件事。我正在运行SQL,其中有大约700万条记录的完整扫描表。
如果我检查gv $ sql,它有很高的数字,如果IO。几乎100百万。
我的问题是:
1.我可以看到3个查询在相同类型的数据库上运行,消耗更多的IOs并且不返回任何行。它继续执行。大IO会消耗所有共享池区域并使应用程序变慢吗?(因为我在其他应用程序中遇到了由于大型IO而导致的应用程序慢的问题,但它没有100百万,只有数千,但我仍然面临增加的非活动会话,需要反弹应用程序服务器实例。)但是我在这个应用程序中没有遇到这样的问题。
2.无法理解缓冲区获取和SGA之间的连接以及应用程序缓慢问题。
运行SQL时不能理解几件事。我正在运行SQL,其中有大约700万条记录的完整扫描表。
如果我检查gv $ sql,它有很高的数字,如果IO。几乎100百万。
我的问题是:
1.我可以看到3个查询在相同类型的数据库上运行,消耗更多的IOs并且不返回任何行。它继续执行。大IO会消耗所有共享池区域并使应用程序变慢吗?(因为我在其他应用程序中遇到了由于大型IO而导致的应用程序慢的问题,但它没有100百万,只有数千,但我仍然面临增加的非活动会话,需要反弹应用程序服务器实例。)但是我在这个应用程序中没有遇到这样的问题。
2.无法理解缓冲区获取和SGA之间的连接以及应用程序缓慢问题。
专家解答
v $ sql是 * 累积 * 数据,因此您也需要检查执行列。
回答你的问题
1) * 返回的 * 行数在这里实际上没有轴承。如果我查询10亿行表,但没有返回行... 我仍然扫描10亿行。
大I/O通常不会消耗缓冲区缓存,因为如果我们认为需要进行大扫描,我们将做所谓的 “直接读取”,它从文件直接到会话的专用区域并绕过缓冲区缓存。即使它是一个很小的对象 (但仍然是 “较大” 的) 块,很少被读取,也会迅速从缓冲区缓存中老化,同时保留更多的活动块。
2) 除了更简单的链接 (即 “努力”) 之外,实际上没有直接的链接。如果您在运行SQL时必须消耗大量资源 (物理IO,或缓冲区获取,或CPU或任何其他有限的资源),那么无论谁或任何正在运行该SQL的人都可能会体验到这种缓慢。
SQL> drop table t purge;
Table dropped.
SQL> create table t as select * from dba_objects;
Table created.
SQL>
SQL>
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL> select executions, buffer_gets from v$sql
2 where sql_text like 'select max(created)%';
EXECUTIONS BUFFER_GETS
---------- -----------
1 1529
1 row selected.
SQL>
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL> select max(created) from t;
MAX(CREAT
---------
23-MAR-17
1 row selected.
SQL>
SQL> select executions, buffer_gets from v$sql
2 where sql_text like 'select max(created)%';
EXECUTIONS BUFFER_GETS
---------- -----------
6 9129
1 row selected.
SQL>
SQL>
SQL>
回答你的问题
1) * 返回的 * 行数在这里实际上没有轴承。如果我查询10亿行表,但没有返回行... 我仍然扫描10亿行。
大I/O通常不会消耗缓冲区缓存,因为如果我们认为需要进行大扫描,我们将做所谓的 “直接读取”,它从文件直接到会话的专用区域并绕过缓冲区缓存。即使它是一个很小的对象 (但仍然是 “较大” 的) 块,很少被读取,也会迅速从缓冲区缓存中老化,同时保留更多的活动块。
2) 除了更简单的链接 (即 “努力”) 之外,实际上没有直接的链接。如果您在运行SQL时必须消耗大量资源 (物理IO,或缓冲区获取,或CPU或任何其他有限的资源),那么无论谁或任何正在运行该SQL的人都可能会体验到这种缓慢。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




