【问题标题】：Oracle Database 10g VIEW performanceOracle 数据库 10g 查看性能
【发布时间】：2010-10-08 06:26:19
【问题描述】：

我的一个 Oracle 数据库中有一个视图执行时间过长。当语句运行时，它似乎并没有停止。

我们是否可以验证此视图的性能，或者我们如何检查语句会话是否“挂起”？

谢谢， N2EE

更新

我意识到问题出在视图中的基础查询上。感谢 Edwin 的自动跟踪修复。

【问题讨论】：

标签： sql oracle plsql oracle10g views

【解决方案1】：

根据快照 ID 生成 AWR 报告

有两个 sql 脚本来创建 AWR 报告。 1.awrrpt.sql 如果我们只有一个 Oracle 数据库，则运行 awrrpt.sql sql 脚本。

awrrpti.sql 如果我们有多个 Oracle 实例（如 RAC），则运行 awrrpti.sql 脚本，以便我们可以创建特定实例来创建 awr 报告。

AWR 报告 sql 脚本的位置 $ORACLE_HOME/rdbms/admin

【讨论】：

【解决方案2】：

假设问题出在底层查询，性能问题可能是因为使用的表尚未分析。
您可以使用DBMS_STATS 包更新Oracle 的表信息，然后查看查询速度是否有所提高。

【讨论】：

【解决方案3】：

您的查询执行很可能很慢。

您可以使用解释计划查看查询在数据库中的执行情况。

如果您有 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

如果其中一个资源非常高，它可以重写查询和/或添加索引到您正在使用的表。

【讨论】：

【解决方案4】：

您是在谈论创建或替换现有视图（即执行 CREATE OR REPLACE VIEW... 语句）还是从视图中进行选择。

在前一种情况下，可能是某个会话将其锁定。例如，如果有人通过视图进行更新或删除，您将无法替换它。根据您的版本，您可以通过检查 v$session 的“BLOCKING_SESSION”列来查看拦截器。

在后一种情况下，慢的不是视图，而是查询。观点几乎无关紧要。检查解释计划（最好使用 DBMS_XPLAN.DISPLAY_CURSOR 和来自 v$sql 的 sql_id），看看它在做什么。 v$session_longops 可能会给出一个指针。

【讨论】：

【解决方案5】：

您需要查看构成视图的查询的性能。最好的方法是对视图使用的 sql 语句做一个解释计划。这将表明它是否在进行全表扫描或其他一些不太理想的行为。调整查询，您的视图应该运行得更好。

【讨论】：