Oracle固定执行计划之SQL PROFILE概要文件详解

1.  引子

Oracle系统为了合理分配和使用系统的资源提出了概要文件的概念。所谓概要文件,就是一份描述如何使用系统的资源(主要是CPU资源)的配置文件。将概要文件赋予某个数据库用户,在用户连接并访问数据库服务器时,系统就按照概要文件给他分配资源。

包括:

1、管理数据库系统资源。

利用Profile来分配资源限额,必须把初始化参数resource_limit设置为true默认是TRUE的。

2、管理数据库口令及验证方式。

默认给用户分配的是DEFAULT概要文件,将该文件赋予了每个创建的用户。但该文件对资源没有任何限制,因此管理员常常需要根据自己数据库系统的环境自行建立概要文件。

2.  概要文件限制

概要文件主要可以对数据库系统如下指标进行限制。

1)用户的最大并发会话数(SESSION_PER_USER)

2)每个会话的CPU时钟限制(CPU_PER_SESSION)

3)每次调用的CPU时钟限制,调用包含解析、执行命令和获取数据等等。(CPU_PER_CALL)

4)最长连接时间。一个会话的连接时间超过指定时间之后,Oracle会自动的断开连接(CONNECT_TIME)

5)最长空闲时间。如果一个会话处于空闲状态超过指定时间,Oracle会自动断开连接(IDLE_TIME)

6)每个会话可以读取的最大数据块数量(LOGICAL_READS_PER_SESSION)

7)每次调用可以读取的最大数据块数量(LOGICAL_READS_PER_CALL)

8)SGA私有区域的最大容量(PRIVATE_SGA)

概要文件对口令的定义和限制如下:

1)登录失败的最大尝试次数(FAILED_LOGIN_ATTEMPTS)

2)口令的最长有效期(PASSWORD_LIFE_TIME)

3)口令在可以重用之前必须修改的次数(PASSWORD_REUSE_MAX)

4)口令在可以重用之前必须经过的天数(PASSWORD_REUSE_TIME)

5)超过登录失败的最大允许尝试次数后,账户被锁定的天数

6)指定用于判断口令复杂度的函数名

在指定概要文件之后,DBA可以手工的将概要文件赋予每个用户。但是概要文件不是立即生效,而是要将初始化参数文件中的参数RESOURCE_LIMIT设置为TRUE之后,概要文件才会生效。

3.  SQL PROFILE

SQL PROFILE在ORACLE10g中引入,主要目的侧重于SQL优化,弥补了存储概要的缺点.

DBA可以使用SQL调整顾问(STA)或SQL访问顾问(SAA)来识别可以得到更好性能的SQL语句,

这些语句可以保存在SQL调整集、一个AWR快照或保存在当前的库缓存中,一旦识别出调整候选者, 这些顾问程序就开始分析捕获到的语句以期获得更好的性能,然后生成专用的语句扩展(就叫做SQL配置文件)并重写SQL语句以在执行期间获取更佳的性能。

与存储概要类似,一个SQL配置文件提供了使用更好的执行计划的能力(如果这个执行计

划是可用的),SQL配置文件也可以象存储概要一样分阶段执行,或限制到对特定会话才能执行该SQL配置文件,但是大多数重要的改进超过了存储概要.

SQLProfile对于一下类型语句有效:

SELECT语句;

UPDATE语句;

INSERT语句(仅当使用SELECT子句时有效);

DELETE语句;

CREATE语句(仅当使用SELECT子句时有效);

MERGE语句(仅当作UPDATE和INSERT操作时有效)。

另外,使用SQL Profile还必须有CREATE ANY SQL PROFILE、DROP ANY SQL PROFILE和ALTER ANY SQL PROFILE等系统权限。

4.  测试一

创建表

tpcc@TOADDB> create table t1 as selectobject_id,object_name from dba_objects where rownum<=50000;
Table created.
tpcc@TOADDB> create table t2 as select * fromdba_objects;
Table created.

创建索引:

tpcc@TOADDB> create index t2_idx on t2(object_id);
Index created.

收集统计信息:

tpcc@TOADDB> execdbms_stats.gather_table_stats(user,'t1',cascade=>true,method_opt=>'forall columns size 1');
PL/SQL procedure successfully completed.
tpcc@TOADDB> execdbms_stats.gather_table_stats(user,'t1',cascade=>true,method_opt=>'forall columns size 1');
PL/SQL procedure successfully completed.

执行无HINT的SQL

tpcc@TOADDB> set autotrace on
tpcc@TOADDB> select t1.*,t2.owner from t1,t2 wheret1.object_name like '%T1%' and t1.object_id=t2.object_id;
42 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1838229974
---------------------------------------------------------------------------
| Id | Operation  | Name | Rows | Bytes | Cost (%CPU)| Time   |
---------------------------------------------------------------------------
| 0| SELECT STATEMENT |  | 2500 | 97K| 498 (1)| 00:00:01 |
|* 1| HASH JOIN   |   | 2500 | 97K| 498 (1)| 00:00:01 |
|* 2| TABLE ACCESS FULL| T1 | 2500 | 72500 | 68 (0)| 00:00:01 |
| 3| TABLE ACCESS FULL| T2 | 92021 | 988K| 430 (1)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
 1-access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
 2- filter("T1"."OBJECT_NAME" LIKE '%T1%' AND"T1"."OBJECT_NAME" IS
    NOT NULL)
Statistics
----------------------------------------------------------
   1 recursive calls
   0 dbblock gets
  1789 consistent gets
   0 physical reads
   0 redosize
  2350 bytes sent via SQL*Net toclient
   573 bytes received via SQL*Net from client
   4 SQL*Net roundtrips to/from client
   0 sorts (memory)
   0 sorts (disk)
   42 rowsprocessed

执行带Hint的SQL

SQL>select /*+ use_nl(t1 t2) index(t2)*/ t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' and t1.object_id=t2.object_id;
42 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1022743391
---------------------------------------------------------------------------------------
| Id | Operation     | Name | Rows | Bytes | Cost (%CPU)|Time  |
---------------------------------------------------------------------------------------
| 0| SELECT STATEMENT  |   | 2500 | 97K| 5069   (1)|00:00:01 |
| 1| NESTED LOOPS      |   | 2500| 97K| 5069   (1)| 00:00:01 |
| 2| NESTED LOOPS      |   | 2500 | 97K| 5069   (1)| 00:00:01 |
|* 3| TABLE ACCESS FULL   | T1  | 2500 | 72500 | 68 (0)|00:00:01 |
|* 4| INDEX RANGE SCAN   |T2_IDX |  1 |  | 1 (0)| 00:00:01 |
| 5| TABLE ACCESS BY INDEX ROWID| T2  | 1 | 11 |  2  (0)|00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
 3- filter("T1"."OBJECT_NAME" LIKE '%T1%' AND"T1"."OBJECT_NAME" IS NOT
    NULL)
 4-access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
Statistics
----------------------------------------------------------
   1 recursive calls
   0 dbblock gets
   304 consistent gets
   24 physical reads
   0 redosize
  2350 bytes sent via SQL*Net toclient
   573 bytes received via SQL*Net from client
   4 SQL*Net roundtrips to/from client
   0 sorts (memory)
   0 sorts (disk)
   42 rowsprocessed

使用SQL PROFILE

查找执行SQL的SQL_ID

tpcc@TOADDB> select sql_id,sql_text from v$sqlwhere sql_text like '%t1.object_name%';
SQL_ID
-------------
SQL_TEXT
----------------------------------------------------------------------------------------------------
4zbqykx89yc8v
select t1.*,t2.owner from t1,t2 wheret1.object_name like '%T1%' and t1.object_id=t2.object_id
18bphz37dajq9
select /*+ use_nl(t1 t2) index(t2) */t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' and
t1.object_id=t2.object_id

运行存储过程如下:

var tuning_task varchar2(100);
DECLARE
 l_sql_id v$session.prev_sql_id%TYPE;
 l_tuning_task VARCHAR2(30);
 BEGIN
 l_sql_id:='4zbqykx89yc8v';
 l_tuning_task := dbms_sqltune.create_tuning_task(sql_id =>l_sql_id);
 :tuning_task:=l_tuning_task;
 dbms_sqltune.execute_tuning_task(l_tuning_task);
 dbms_output.put_line(l_tuning_task);
 END;
/ 

TASK_114

PL/SQL procedure successfully completed.

查看task的名字

tpcc@TOADDB> print tuning_task;
TUNING_TASK
----------------------------------------------------------------------------------------------------
TASK_114

查看执行报告

set long 99999
col comments format a200
SELECT dbms_sqltune.report_tuning_task(:tuning_task)COMMENTS FROM dual;
COMMENTS
----------------------------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name : TASK_114
Tuning Task Owner : TPCC
Workload Type : Single SQL Statement
Scope     : COMPREHENSIVE
Time Limit(seconds): 1800
Completion Status : COMPLETED
Started at   : 03/06/2016 05:27:21
Completed at  : 03/06/2016 05:27:24
-------------------------------------------------------------------------------
Schema Name: TPCC
SQL ID   : 4zbqykx89yc8v
SQL Text : select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%'
    and t1.object_id=t2.object_id
-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------
1- SQL Profile Finding (see explain planssection below)
--------------------------------------------------------
 Apotentially better execution plan was found for this statement.
 Recommendation (estimated benefit: 83.08%)
 ------------------------------------------
 -Consider accepting the recommended SQL profile.
 executedbms_sqltune.accept_sql_profile(task_name => 'TASK_114',
    task_owner =>'TPCC', replace => TRUE);
 Validation results
 ------------------
 TheSQL profile was tested by executing both its plan and the original plan
 andmeasuring their respective execution statistics. A plan may have been
 only partially executed if the other could be run to completion in lesstime.
        Original Plan With SQL Profile % Improved
        ------------- ---------------- ----------
 Completion Status:    COMPLETE  COMPLETE
 Elapsed Time (s):   .012865 .004556  64.58 %
 CPUTime (s):     .0124  .0045  63.7%
 User I/O Time (s):      0     0
 Buffer Gets:        1787    302  83.1%
 Physical Read Requests:   0     0
 Physical Write Requests:   0     0
 Physical Read Bytes:     0     0
 Physical Write Bytes:    0     0
 Rows Processed:    42     42
 Fetches:        42     42
 Executions:       1     1
 Notes
 -----
 1.Statistics for the original plan were averaged over 10 executions.
 2.Statistics for the SQL profile plan were averaged over 10 executions.
-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------
1- Original With Adjusted Cost
------------------------------
Plan hash value: 1838229974
---------------------------------------------------------------------------
| Id | Operation  | Name | Rows | Bytes | Cost (%CPU)| Time   |
---------------------------------------------------------------------------
| 0| SELECT STATEMENT |  | 42 | 1680 | 498 (1)| 00:00:01 |
|* 1| HASH JOIN   |   | 42 | 1680 | 498 (1)| 00:00:01 |
|* 2| TABLE ACCESS FULL| T1 | 42 | 1218 | 68 (0)| 00:00:01 |
| 3| TABLE ACCESS FULL| T2 | 92021 | 988K| 430 (1)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
 1-access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
 2- filter("T1"."OBJECT_NAME" LIKE '%T1%' AND"T1"."OBJECT_NAME" IS
    NOT NULL)
2- Using SQL Profile
--------------------
Plan hash value: 1022743391
---------------------------------------------------------------------------------------
| Id | Operation     | Name | Rows | Bytes | Cost (%CPU)|Time  |
---------------------------------------------------------------------------------------
| 0| SELECT STATEMENT  |   | 42 | 1680 | 152 (0)|00:00:01 |
| 1| NESTED LOOPS      |   | 42 | 1680 | 152 (0)| 00:00:01 |
| 2| NESTED LOOPS      |   | 42 | 1680 | 152 (0)| 00:00:01 |
|* 3| TABLE ACCESS FULL   | T1  | 42 | 1218 | 68 (0)| 00:00:01 |
|* 4| INDEX RANGE SCAN   |T2_IDX |  1 |  | 1 (0)| 00:00:01 |
| 5| TABLE ACCESS BY INDEX ROWID| T2  | 1 | 11 |  2  (0)|00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
 3- filter("T1"."OBJECT_NAME" LIKE '%T1%' AND"T1"."OBJECT_NAME" IS NOT
    NULL)
 4-access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
-------------------------------------------------------------------------------

接受分析建议

报告中给出了执行方法,如上红色部分

接受报告的建议,验证一下如下:

tpcc@TOADDB> execute dbms_sqltune.accept_sql_profile(task_name=> 'TASK_114',task_owner => 'TPCC', replace => TRUE);
PL/SQL procedure successfully completed.

执行测试

再执行原先命令如下:

tpcc@TOADDB> select t1.*,t2.owner from t1,t2 wheret1.object_name like '%T1%' and t1.object_id=t2.object_id;
42 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1022743391
---------------------------------------------------------------------------------------
| Id | Operation     | Name | Rows | Bytes | Cost (%CPU)|Time  |
---------------------------------------------------------------------------------------
| 0| SELECT STATEMENT  |   | 42 | 1680 | 152 (0)|00:00:01 |
| 1| NESTED LOOPS      |   | 42| 1680 | 152 (0)|00:00:01 |
| 2| NESTED LOOPS      |   | 42 | 1680 | 152 (0)| 00:00:01 |
|* 3| TABLE ACCESS FULL   | T1  | 42 | 1218 | 68 (0)| 00:00:01 |
|* 4| INDEX RANGE SCAN   |T2_IDX |  1 |  | 1 (0)| 00:00:01 |
| 5| TABLE ACCESS BY INDEX ROWID| T2  | 1 | 11 |  2  (0)|00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
 3- filter("T1"."OBJECT_NAME" LIKE '%T1%' AND"T1"."OBJECT_NAME" IS NOT
    NULL)
 4-access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
Note
-----
 - SQL profile"SYS_SQLPROF_01534b8309b90000" used for this statement
 - this is an adaptive plan
Statistics
----------------------------------------------------------
   35 recursive calls
   0 dbblock gets
   317 consistent gets
   1 physical reads
   0 redosize
  2350 bytes sent via SQL*Net toclient
   573 bytes received via SQL*Net from client
   4 SQL*Net roundtrips to/from client
   1 sorts (memory)
   0 sorts (disk)
   42 rowsprocessed

启用了PROFILE,PS:如果执行中多加几个空格,并不会影响PROFILE的生效的。

5.  维护操作

禁用命令
如下:

begin
dbms_sqltune.alter_sql_profile(
name   => 'SYS_SQLPROF_01534b8309b90000',
attribute_name => 'status',
value   => 'disabled');
end;
/

启用命令
如下:

begin
dbms_sqltune.alter_sql_profile(
name   => 'SYS_SQLPROF_01534b8309b90000',
attribute_name => 'status',
value   => 'enabled');
end;
/

查看使用的PROFILE

如下:

SQL>SELECT task_name,status FROMUSER_ADVISOR_TASKS ;

删除PROFILE

BEGIN
 DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'SYS_SQLPROF_01534b8309b90000');
END; 

总结

以上所述是小编给大家介绍的Oracle固定执行计划之SQL PROFILE概要文件 ,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!

(0)

相关推荐

  • Oracle基础:通过sqlplus执行sql语句后的结果进行判断

    这篇文章介绍一下如何对sqlplus执行的sql语句结果进行判断. 环境准备 使用Oracle的精简版创建docker方式的demo环境,详细可参看: https://www.jb51.net/article/153533.htm 常见问题 在sqlplus中执行sql语句,如果直接使用命令行的方式调用时会碰到两个问题: 问题1: 需要进行交互性的输入 问题2:结果的判断不能通过返回值来确认 解决方式 在脚本调用里,解决方式如下 问题1可以通过前文提到的Here Document来解决. 问题2

  • sql – Oracle中匿名TABLE/VARRAY类型示例详解

    前言 本文主要介绍的是关于sql Oracle匿名TABLE/VARRAY类型的相关内容,在Oracle中,我有时会创建一些这样的结构 SELECT * FROM TABLE(STRINGS('a', 'b', 'c')) SELECT * FROM TABLE(NUMBERS(1, 2, 3)) 显然,我可以为上述声明我自己的类型.我可以在TABLE和VARRAY之间进行选择.例如: CREATE TYPE STRINGS AS TABLE OF VARCHAR2(100); CREATE T

  • Oracle带输入输出参数存储过程(包括sql分页功能)

    记录一下,免得以后忘记了又要到处去找. begin /*这里不能直接执行select语句但可以直接执行update.delete.insert语句*/ end里面不能接执行select语句,声明会话级临时表必须有"execute immediate 'TRUNCATE TABLE 表名';"这一句不然其他的session无法drop(TRUNCATE TABLE 表名 必须在 'drop table 表名' 这一句前执行) create or replace procedure p_D

  • Oracle基础多条sql执行在中间的语句出现错误时的控制方式

    多条sql执行时如果在中间的语句出现错误,后续会不会直接执行,如何进行设定,以及其他数据库诸如Mysql是如何对应的,这篇文章将会进行简单的整理和说明. 环境准备 使用Oracle的精简版创建docker方式的demo环境,详细可参看: https://www.jb51.net/article/153533.htm 多行语句的正常执行 对上篇文章创建的两个字段的学生信息表,正常添加三条数据,详细如下: # sqlplus system/liumiao123@XE <<EOF > desc

  • PHP基于pdo的数据库操作类【可支持mysql、sqlserver及oracle】

    本文实例讲述了PHP基于pdo的数据库操作类.分享给大家供大家参考,具体如下: 工作中需要操作sqlserver.oracle都是使用的这个类,当时是在别人的基础上改进了,现在分享下 <?php class Pdodb{ protected $pdo; protected $res; protected $config; /*构造函数*/ function __construct($config){ $this->Config = $config; $this->connect(); }

  • Oracle查询sql错误信息的控制和定位

    在sqlplus中执行的sql出错之后应该如何处理和对应,多行sql语句或者存储过程的信息如何进行错误定位,这篇文章将结合实例进行简单地说明. 环境准备 使用Oracle的精简版创建docker方式的demo环境,详细可参看: https://www.jb51.net/article/153533.htm 如何进行错误定位 场景: 假如有3行insert的sql语句,中间一行出错之后,后续继续执行的情况下,如何定位到第二行? dbms_utility.format_error_backtrace

  • 使用SQL语句查询MySQL,SQLServer,Oracle所有数据库名和表名,字段名

    MySQL中查询所有数据库名和表名 查询所有数据库 show databases; 查询指定数据库中所有表名 select table_name from information_schema.tables where table_schema='database_name' and table_type='base table'; 查询指定表中的所有字段名 select column_name from information_schema.columns where table_schema

  • oracle sql语言模糊查询--通配符like的使用教程详解

    oracle在Where子句中,可以对datetime.char.varchar字段类型的列用Like子句配合通配符选取那些"很像..."的数据记录,以下是可使用的通配符: %   零或者多个字符 _    单一任何字符(下划线) \     特殊字符 oracle10g以上支持正则表达式的函数主要有下面四个: 1,REGEXP_LIKE :与LIKE的功能相似 2,REGEXP_INSTR :与INSTR的功能相似 3,REGEXP_SUBSTR :与SUBSTR的功能相似 4,RE

  • 安装SQL Server 2016出错提示:需要安装oracle JRE7 更新 51(64位)或更高版本问题的解决方法

    错误提示原因:安装时检测出电脑没有安装JDK,而且是版本7(其他版本不行) 解决方法:先进下面这个网站安装JDK,安装好后配置环境变量,然后重新安装SQL Server 2016即可 http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html 先勾选接受协议,然后开始下载 我的电脑系统是Windows x64,所以下载的是红线框起来的,具体下载哪个看自己的电脑

  • Python3连接SQLServer、Oracle、MySql的方法

    环境: python3.4 64bit pycharm2018社区版 64bit Oracle 11 64bit SQLServer· Mysql 其中三种不同的数据库安装在不同的服务器上,通过局域网相连 步骤1:在pycharm上安装相应的包,可通过pip或者其他方式 步骤2:import这些包 import pymysql,pymssql,cx_Oracle #导入数据库相关包 步骤3: db_sqls = pymssql.connect(host='192.168.10.172',port

随机推荐