查看Oracle执行计划的几种方法

一、通过PL/SQL Dev工具

1、直接File->New->Explain Plan Window，在窗口中执行sql可以查看计划结果。其中，Cost表示cpu的消耗，单位为n%，Cardinality表示执行的行数，等价Rows。

2、先执行 EXPLAIN PLAN FOR select * from tableA where paraA=1，再 select * from table(DBMS_XPLAN.DISPLAY)便可以看到oracle的执行计划了，看到的结果和1中的一样，所以使用工具的时候推荐使用1方法。

注意：PL/SQL Dev工具的Command window中不支持set autotrance on的命令。还有使用工具方法查看计划看到的信息不全，有些时候我们需要sqlplus的支持。

二、通过sqlplus

1．最简单的办法

Sql> set autotrace on

Sql> select * from dual;

执行完语句后，会显示explain plan 与 统计信息。

这个语句的优点就是它的缺点，这样在用该方法查看执行时间较长的sql语句时，需要等待该语句执行成功后，才返回执行计划，使优化的周期大大增长。如果不想执行语句而只是想得到执行计划可以采用：

Sql> set autotracetraceonly

这样，就只会列出执行计划，而不会真正的执行语句，大大减少了优化时间。虽然也列出了统计信息，但是因为没有执行语句，所以该统计信息没有用处，如果执行该语句时遇到错误，解决方法为：

(1）在要分析的用户下：

Sqlplus>@ ?

dbmsadminutlxplan.sql

(2) 用sys用户登陆

Sqlplus>@ ?sqlplusadminplustrce.sql

…… …… 余下全文

TOAD中查看SQL的执行计划

一、TOAD中查看SQL的执行计划：

1、点击工具栏上120救护车图标按钮

2、快捷键Ctrl+E

3、菜单View-Explain plan

二、如果是默认安装TOAD，在查看执行计划时会报一个错：

ORA-02404: 未找到指定的计划表

稍微研究了一下，解决这个问题基本上有3个方案：

1、最直接的解决方案：直接创建TOAD所需要的计划表，该脚本在%oracle_home%\rdbms\admin\utlxplan.sql中，不过该脚本是创建PLAN_TABLE表，表结构一样，改名为TOAD_PLAN_TABLE 即可。如下：

CREATE TABLE TOAD_PLAN_TABLE (

STATEMENT_ID VARCHAR2 (32),

TIMESTAMP DATE,

REMARKS VARCHAR2 (80),

OPERATION VARCHAR2 (30),

OPTIONS VARCHAR2 (30),

OBJECT_NODE VARCHAR2 (128),

OBJECT_OWNER VARCHAR2 (30),

OBJECT_NAME VARCHAR2 (30),

OBJECT_INSTANCE NUMBER,

OBJECT_TYPE VARCHAR2 (30),

SEARCH_COLUMNS NUMBER,

ID NUMBER,

COST NUMBER,

PARENT_ID NUMBER,

POSITION NUMBER,

CARDINALITY NUMBER,

OPTIMIZER VARCHAR2 (255),

…… …… 余下全文

ORACLE中查看执行计划及SQL TRACE

有三种方法：

1. Explain plan

SQL>explain plan for select * from aa;

查看结果：

SQL>select * from table(dbms_xplan.display());

2.Autotrace

SQL>set timing on --记录所用时间

SQL>set autotrace traceonly --自动记录执行计划

然后执行SQL语句即可。

3.SQL_TRACE

ORACLE SQL_TRACE

“SQL TRACE”是Oracle提供的用于进行SQL跟踪的手段，是强有力的辅助诊断工具。在日常的数据库问题诊断和解决中，“SQL TRACE”是非常常用的方法。

一般，一次跟踪可以分为以下几步：

1、界定需要跟踪的目标范围，并使用适当的命令启用所需跟踪。

2、经过一段时间后，停止跟踪。此时应该产生了一个跟踪结果文件。

3、找到跟踪文件，并对其进行格式化，然后阅读或分析。

本文就“SQL TRACE”的这些使用作简单探讨，并通过具体案例对SQL_TRACE的使用进行说明。

一、“SQL TRACE”的启用。

(A)SQL_TRACE说明

SQL_TRACE可以作为初始化参数在全局启用，也可以通过命令行方式在具体session启用。

1． 在全局启用

在参数文件(pfile/spfile)中指定: SQL_TRACE = true

在全局启用SQL_TRACE会导致所有进程的活动被跟踪，包括后台进程及所有用户进程，这通常会导致比较严重的性能问题，所以在生产环境中要谨慎使用。

提示: 通过在全局启用SQL_TRACE，我们可以跟踪到所有后台进程的活动，很多在文档中的抽象说明，通过跟踪文件的实时变化，我们可以清晰的看到各个进程之间的紧密协调。

…… …… 余下全文

Oracle中查看已执行sql的执行计划

上一篇 / 下一篇 2008-09-12 10:54:07 / 个人分类：原创笔记

查看( 771 ) / 评论( 8 ) / 评分( 15 / 0 )

有时候我们可能会希望查看一条已经执行过的sql的执行计划，常用的方式有两种：a,set autotrace后再重新执行一遍，不过重新执行可能会浪费时间，而且有些语句也不允许(例如修改操作的语句)，或者查询v$sql_plan视图，但v$视图的可读性又不是那么好，这里提供一个新方式，通过dbms_xplan.display_cursor来获取执行过的sql的执行计划。

首先看看该函数的语法：

DBMS_XPLAN.DISPLAY_CURSOR(

sql_id IN VARCHAR2 DEFAULT NULL,

child_number IN NUMBER DEFAULT NULL,

format IN VARCHAR2 DEFAULT 'TYPICAL');

由上可知，我们至少需要找到执行过sql的sql_id，该参数可以从v$sql视图中找到。

下面，举个例子吧，执行一个简单查询：

SQL> select count(0) from cat_product cp,cat_drug cd where cp.medical_id=cd.id;

COUNT(0)

----------

118908

如果我们想获取该语句的实际执行计划，通过下列步骤：

1、查询v$sql视图，找到该语句的sql_id(注意哟，必须要确保你要查询的sql语句还在shared pool)： SQL> select sql_id from v$sql where sql_text=

2 'select count(0) from cat_product cp,cat_drug cd where cp.medical_id=cd.id';

…… …… 余下全文

看懂执行计划

例子1

以AdventureWorks的DatabaseLog查询为例：

SELECT * FROM [AdventureWorks2008R2].[dbo].[DatabaseLog]

? Cached plan size – how much memory the plan generated by this query will take up in stored procedure cache. This is a useful number when investigating cache performance issues because you'll be able to see which plans are taking up more memory.

? Estimated Operator Cost – we've already seen this as the percentage cost in Figure 1.

? Estimated Subtree Cost – tells us the accumulated optimizer cost assigned to this step and all previous steps, but remember to read from right to left. This number is meaningless in the real world, but is a mathematical evaluation used by the query optimizer to determine the cost of the operator in question; it represents the amount of time that the optimizer thinks this operator will take.

…… …… 余下全文

对于SqlServer的优化来说，可能优化查询是很常见的事情。关于数据库的优化，本身也是一个涉及面比较的广的话题， 首先，打开【SQL Server Management Studio】，输入一个查询语句看看SqlServer是如何显示查询计划的吧。 select v.OrderID, v.CustomerID, v.CustomerName, v.OrderDate, v.SumMoney, v.Finished

from OrdersView

as v

where v.OrderDate >= '2010-12-1' and v.OrderDate < '2011-12-1'; 其中，OrdersView是一个视图，其定义如下：

SELECT dbo.Orders.OrderID, dbo.Orders.CustomerID,

dbo.Orders.OrderDate,

dbo.Orders.SumMoney, dbo.Orders.Finished,

ISNULL(dbo.Customers.CustomerName, N'') AS CustomerName FROM dbo.Orders LEFT OUTER JOIN

dbo.Customers ON dbo.Orders.CustomerID =

dbo.Customers.CustomerID

对于前一句查询，SqlServer给出的查询计划如下（点击工具栏上的【显示估计的执行计划】按钮）：

从这个图，我们至少可以得到3个有用的信息：

1. 哪些执行步骤花费的成本比较高。显然，最右边的二个步骤的成本是比较高的。

2. 哪些执行步骤产生的数据量比较多。对于每个步骤所产生的数据量， SqlServer的执行计划是用【线条粗细】来表示的，因此也很容易地从分辨出来。

…… …… 余下全文

? Table Scan(表扫描)：如果看到这个信息，就说明数据表上没有聚集索引，或者查询优化器

没有使用索引来查找。意即资料表的每一行都被检查到。如果资料表相对较小的话，表扫描可以非常快速，有时甚至快过使用索引。

因此，当看到有执行表扫描时，第一件要做的事就是看看数据表有多少数据行。如果不是太多的话，那么表扫描可能提供了最好的总体效能。但如果数据表大的话，表扫描就极可能需要长时间来完成，查询效能就大受影响。在这种情况下，就需要仔细研究，为数据表增加一个适当的索引用于这个查询。

假设你发现某查询使用了表扫描，有一个合适的非聚集索引，但它没有用到。这意味着什么呢？为什么这个索引没有用到呢？如果需要获得的数据量相对数据表大小来说非常大，或者数据选择性不高(意味着同一个字段中重复的值很多)，表扫描经常会比索引扫描快。例如，如果一个数据表有10000个数据行，查询返回1000行，如果这个表没有聚集索引的话，那么表扫描将比使用一个非聚集索引更快。或者如果数据表有10000个数据行，且同一个字段(WHERE条件句有用到这个字段)上有1000笔重复的数据，表扫描也会比使用非聚集索引更快。

查看图形执行计划上的数据表上的弹出式窗口时，请注意”预估的资料行数(Estimated Row Count)”。这个数字是查询优化器作出的多少个数据行会被返回的最佳推测。如果执行了表扫描且”预估的数据行数”数值很高的话，就意味着返回的记录数很多，查询优化器认为执行表扫描比使用可用的非聚集索引更快。

? Index Seek(索引查找)：索引查找意味着查询优化器使用了数据表上的非聚集索引来查找数

据。性能通常会很快，尤其是当只有少数的数据行被返回时。

? Clustered Index Seek(聚集索引查找)：这指查询优化器使用了数据表上的聚集索引来查

找数据，性能很快。实际上，这是SQL Server能做的最快的索引查找类型。

…… …… 余下全文