我在我的一个 Oracle 数据库中有一个视图,该视图执行时间太长。当语句运行时,它似乎并没有停止。
无论如何我们可以验证这个视图的性能,或者我们如何检查语句会话是否“挂起”?
谢谢, N2EE
更新
我意识到问题出在视图中的基础查询上。感谢 Edwin 的自动跟踪修复。
您的查询的执行很可能很慢。
您可以使用解释计划查看查询如何在数据库中执行。
如果您有 SQL*Plus,您可以使用以下语句轻松完成此操作:
set autotrace traceonly
然后输入查询,您将获得查询的统计信息,如下所示:
SQL> set autotrace traceonly
SQL> select * from o_drops;
4461 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 3820245448
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4287 | 280K| 11 (10)| 00:00:01 |
| 1 | TABLE ACCESS FULL| O_DROPS | 4287 | 280K| 11 (10)| 00:00:01 |
-----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
333 consistent gets
48 physical reads
0 redo size
337057 bytes sent via SQL*Net to client
2316 bytes received via SQL*Net from client
299 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4461 rows processed
如果其中一项资源非常高,则可以重写查询和/或向您正在使用的表添加索引。
您需要查看构成视图的查询的性能。最好的方法是对视图使用的 sql 语句做一个解释计划。这将表明它是否进行全表扫描或其他一些不太理想的行为。调整查询,您的视图应该运行得更好。
您是在谈论创建或替换现有视图(即执行 CREATE OR REPLACE VIEW... 语句)还是从视图中进行选择。
在前一种情况下,可能是某个会话将其锁定。例如,如果有人通过视图进行更新或删除,您将无法替换它。根据您的版本,您可以通过检查 v$session 的“BLOCKING_SESSION”列来查看拦截器。
在后一种情况下,慢的不是视图,而是查询。观点几乎无关紧要。检查解释计划(最好使用带有来自 v$sql 的 sql_id 的 DBMS_XPLAN.DISPLAY_CURSOR),看看它在做什么。v$session_longops 可能会给出一个指针。
假设问题是底层查询,性能问题可能是因为使用的表尚未分析。
您可以使用DBMS_STATS包来更新 Oracle 的有关表的信息,然后查看查询速度是否有所提高。
根据快照 ID 生成 AWR 报告
有两个 sql 脚本来创建 AWR 报告。1. awrrpt.sql 如果我们只有一个 Oracle 数据库,则运行 awrrpt.sql sql 脚本。
Location of AWR report sql script $ORACLE_HOME/rdbms/admin