ORACLE概要文件-- sql profile(一）

最新推荐文章于 2025-06-28 08:02:52 发布
原创 最新推荐文章于 2025-06-28 08:02:52 发布 · 3.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#oracle #sql profile #outline #tuning

本文介绍 Oracle 10g 中 SQL Profile 的使用方法及其与 Outline 的区别。通过具体案例展示如何生成和应用 SQL Profile 来优化 SQL 执行计划，并探讨 force_match 参数的影响。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

SQL PROFILE在ORACLE10g中引入，从官方文档和网络资料可以看出，SQL PROFILE的主要目的侧重于SQL优化，其底层的实现细节可能主要依赖于hint。与outline相比，个人人文SQLPROFILE侧重于为优化器提供辅助信息从而促使优化器选择最优的执行计划，而outline侧重于固化执行计划，两者的目的是有区别的。但是由于SQL PROFILE和OUTLINE的底层技术支持均为hint，因此sqlprofile也可以实现固化执行计划的目的。

我们知道oracle在执行sql语句时会尽力选择最优的执行计划，但是出于各个方面的平衡，oracle最终选择的执行计划未必是最优的。在这种情况下，oracle10g引入了自动调整优化器（AUTOMATIC TUNING OPTIMIZER），自动调整优化器作为优化器的一个扩展而存在。在正常环境下，oracle优化器会在最快的时间内获取执行计划，不会利用自动调整优化器。当我们需要调优某条sql语句时，我们将该语句提交给自动调优优化器，自动调优优化器会尽可能选择最优执行计划，而不会考虑选择该执行计划所花费的时间，甚至在某些情况下，自动调整优化器会进行what-if分析，或者实际的执行sql语句来验证执行计划的效率。

下面的图片展示了SQL PROFILE的生成和使用过程：


生成和管理SQL PROFILE可以通过DBMS_SQLTUNE或者企业管理器的图形界面，下面我们使用DBMS_SQLTUNE来演示SQL PROFILE的管理操作，聪明的你如果可以使用DBMS_SQLTUNE来管理SQLPROFILE，肯定也可以使用图形界面。

首先构建我们的测试环境

SQL> create table t1 as select object_id,object_name from dba_objects where rownum<=50000;

表已创建。

SQL> create table t2 as select * from dba_objects;

表已创建。

SQL> create index t2_idx on t2(object_id);

索引已创建。

SQL> exec dbms_stats.gather_table_stats(user,'t1',cascade=>true,method_opt=>'for all columns size 1');

PL/SQL 过程已成功完成。

SQL> exec dbms_stats.gather_table_stats(user,'t2',cascade=>true,method_opt=>'for all columns size 1');

PL/SQL 过程已成功完成。

用到的脚本 

SQL> !cat tune_last_statement.sql
declare
l_sql_id v$sql.sql_id%TYPE;
l_tuning_task varchar2(30);
begin
 select sql_id into l_sql_id from v$sql where sql_text like 'select t1.*,t2.owner from t1,t2 where t1.object_name%'  and rownum =1;
 l_tuning_task := dbms_sqltune.create_tuning_task(sql_id => l_sql_id);
 dbms_sqltune.execute_tuning_task(l_tuning_task);
 dbms_output.put_line(l_tuning_task);
end

在原始状态下的sql语句执行过程

SQL> select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' AND T1.object_id=t2.object_id;

已选择36行。


执行计划
----------------------------------------------------------
Plan hash value: 1838229974

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |  2500 |   100K|   370   (1)| 00:00:05 |
|*  1 |  HASH JOIN	   |	  |  2500 |   100K|   370   (1)| 00:00:05 |
|*  2 |   TABLE ACCESS FULL| T1   |  2500 | 75000 |    69   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| T2   | 75308 |   808K|   300   (1)| 00:00:04 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   2 - filter("T1"."OBJECT_NAME" LIKE '%T1%' AND "T1"."OBJECT_NAME" IS
	      NOT NULL)


统计信息
----------------------------------------------------------
	  0  recursive calls
	  1  db block gets
	317  consistent gets
	  0  physical reads
	  0  redo size
       2141  bytes sent via SQL*Net to client
	542  bytes received via SQL*Net from client
	  4  SQL*Net roundtrips to/from client
	  0  sorts (memory)
	  0  sorts (disk)
	 36  rows processed
这时候进行了全表扫描，逻辑读数量为317.

对sql语句进行调优

SQL> @tune_last_statement.sql
 11  /
任务_309

查看调优报告：

SQL> select dbms_sqltune.report_tuning_task('任务_309') as re from dual;

RE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : 任务_309
Tuning Task Owner  : EASY
Workload Type	   : Single SQL Statement
Scope		   : COMPREHENSIVE
Time Limit(seconds): 1800
Completion Status  : COMPLETED
Started at	   : 01/06/2014 23:36:02
Completed at	   : 01/06/2014 23:36:02

-------------------------------------------------------------------------------
Schema Name: EASY
SQL ID	   : 31hpx02tsna89
SQL Text   : select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%'
	     AND T1.object_id=t2.object_id

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  为此语句找到了性能更好的执行计划。

  Recommendation (estimated benefit: 76.77%)
  ------------------------------------------
  - 考虑接受推荐的 SQL 概要文件。
    execute dbms_sqltune.accept_sql_profile(task_name => '任务_309', task_owner
	    => 'EASY', replace => TRUE);

  Validation results
  ------------------
  已对 SQL profile 进行测试, 方法为执行其计划和原始计划并测量与计划相对应的执行统计信息。如果其中一个计划运行在很短的时间内就完成,
  则另一计划可能只执行了一部分。

			   Original Plan  With SQL Profile  % Improved
			   -------------  ----------------  ----------
  Completion Status:		COMPLETE	  COMPLETE
  Elapsed Time (s):		.022829 	  .013985      38.74 %
  CPU Time (s): 		.022696 	  .013897      38.76 %
  User I/O Time (s):		      0 		0
  Buffer Gets:			   1330 	      308      76.84 %
  Physical Read Requests:	      0 		0
  Physical Write Requests:	      0 		0
  Physical Read Bytes:		      0 		0
  Physical Write Bytes: 	      0 		0
  Rows Processed:		     36 	       36
  Fetches:			     36 	       36
  Executions:			      1 		1

  Notes
  -----
  1. the original plan 的统计信息是 10 执行的平均值。
  2. the SQL profile plan 的统计信息是 10 执行的平均值。

2- Alternative Plan Finding
---------------------------
  通过搜索系统的实时和历史性能数据找到了此语句的某些替代执行计划。

  The following table lists these plans ranked by their average elapsed time.
  See section "ALTERNATIVE PLANS SECTION" for detailed information on each
  plan.

  id plan hash	last seen	     elapsed (s)  origin	  note
  -- ---------- -------------------- ------------ --------------- ----------------
   1 1022743391  2014-01-06/22:56:07	    0.022 Cursor Cache

  Information
  -----------
  - 因为找不到原始计划的任何执行历史记录, SQL 优化指导无法确定这些执行计划中是否有一些执行计划优于原始计划。但是,
    如果您知道某个替代计划优于原始计划, 可以为该替代计划创建 SQL 计划基线。这将指示 Oracle 优化程序在将来优先于任何其他选择来选取它。
    execute dbms_sqltune.create_sql_plan_baseline(task_name => '任务_309',
	    owner_name => 'EASY', plan_hash_value => xxxxxxxx);

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original With Adjusted Cost
------------------------------
Plan hash value: 1838229974

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |    36 |  1476 |   370   (1)| 00:00:05 |
|*  1 |  HASH JOIN	   |	  |    36 |  1476 |   370   (1)| 00:00:05 |
|*  2 |   TABLE ACCESS FULL| T1   |    36 |  1080 |    69   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| T2   | 75308 |   808K|   300   (1)| 00:00:04 |
---------------------------------------------------------------------------

Predicate Information (identified by operation 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	     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|   1 |  NESTED LOOPS		     |	      |       |       | 	   |	      |
|   2 |   NESTED LOOPS		     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|*  3 |    TABLE ACCESS FULL	     | T1     |    36 |  1080 |    69	(2)| 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 by operation id):
---------------------------------------------------

   3 - filter("T1"."OBJECT_NAME" LIKE '%T1%' AND "T1"."OBJECT_NAME" IS NOT
	      NULL)
   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

-------------------------------------------------------------------------------
ALTERNATIVE PLANS SECTION
-------------------------------------------------------------------------------

Plan 1
------

  Plan Origin		      :Cursor Cache
  Plan Hash Value	      :1022743391
  Executions		      :12
  Elapsed Time		      :0.022 sec
  CPU Time		      :0.019 sec
  Buffer Gets		      :318
  Disk Reads		      :0
  Disk Writes		      :0

Notes:
  1. Statistics shown are averaged over multiple executions.

---------------------------------------------------------------------------------------
| Id  | Operation		     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	     |	      |  2500 |   100K|  5071	(1)| 00:01:01 |
|   1 |  NESTED LOOPS		     |	      |       |       | 	   |	      |
|   2 |   NESTED LOOPS		     |	      |  2500 |   100K|  5071	(1)| 00:01:01 |
|*  3 |    TABLE ACCESS FULL	     | T1     |  2500 | 75000 |    69	(2)| 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 by operation id):
---------------------------------------------------

   3 - filter("T1"."OBJECT_NAME" LIKE '%T1%' AND "T1"."OBJECT_NAME" IS NOT
	      NULL)
   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

-------------------------------------------------------------------------------

从报告文件可以看出，自动调优优化器为我们生成了更优的执行计划，下面我们只需要接受它即可。 

SQL> exec dbms_sqltune.accept_sql_profile(task_name=>'任务_309',task_owner=>user,replace=>true,force_match=>true);

PL/SQL 过程已成功完成。

现在我们来看一下sql profile是否会其作用 

SQL>  select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' AND T1.object_id=t2.object_id;

执行计划
----------------------------------------------------------
Plan hash value: 1022743391

---------------------------------------------------------------------------------------
| Id  | Operation		     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|   1 |  NESTED LOOPS		     |	      |       |       | 	   |	      |
|   2 |   NESTED LOOPS		     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|*  3 |    TABLE ACCESS FULL	     | T1     |    36 |  1080 |    69	(2)| 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 by operation 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_01436cac2c3c0000" used for this statement

看来sql profile发挥作用了，从执行计划和note部分都可以看出。在来看一下相似的语句 

SQL>  select t1.*,t2.owner from t1,t2 where t1.object_name like '%T2%' AND T1.object_id=t2.object_id;

执行计划
----------------------------------------------------------
Plan hash value: 1022743391

---------------------------------------------------------------------------------------
| Id  | Operation		     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|   1 |  NESTED LOOPS		     |	      |       |       | 	   |	      |
|   2 |   NESTED LOOPS		     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|*  3 |    TABLE ACCESS FULL	     | T1     |    36 |  1080 |    69	(2)| 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 by operation id):
---------------------------------------------------

   3 - filter("T1"."OBJECT_NAME" LIKE '%T2%' AND "T1"."OBJECT_NAME" IS NOT
	      NULL)
   4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - SQL profile "SYS_SQLPROF_01436cac2c3c0000" used for this statement
sql profile同样发挥了作用，这是为什么那？

大家可能注意到accept_sql_profile中的一个参数force_match,对！ 正是这个参数导致sql profile可以影响相似的sql语句。在继续下面的讨论之前，先来看一下v$sql中的两个字段

SQL> select sql_text,to_char(exact_matching_signature),to_char(force_matching_signature) from v$sql where sql_text like ' select t1.*,t2.owner from t1,t2 %';

SQL_TEXT				 TO_CHAR(EXACT_MATCHING_SIGNATURE)	  TO_CHAR(FORCE_MATCHING_SIGNATURE)
---------------------------------------- ---------------------------------------- ----------------------------------------
 select t1.*,t2.owner from t1,t2 where t 16954193673788994662			  3960696072677096522
1.object_name like '%T2%' AND T1.object_
id=t2.object_id

 select t1.*,t2.owner from t1,t2 where t 8975541025552400288			  3960696072677096522
1.object_name like '%T1%' AND T1.object_
id=t2.object_id

然后我们看一下sqlprofile到底存储了什么内容？ 

SQL> l
  1  SELECT so.signature,extractValue(value(h),'.') AS hint
  2  FROM sys.sqlobj$data od, sys.sqlobj$ so,
  3  table(xmlsequence(extract(xmltype(od.comp_data),'/outline_data/hint'))) h
  4  WHERE so.name = 'SYS_SQLPROF_01436cac2c3c0000'
  5  AND so.signature = od.signature
  6  AND so.category = od.category
  7  AND so.obj_type = od.obj_type
  8* AND so.plan_id = od.plan_id
SQL> /

		 SIGNATURE HINT
-------------------------- ------------------------------------------------------------------------------------------
       3960696072677096522 OPT_ESTIMATE(@"SEL$1", TABLE, "T1"@"SEL$1", SCALE_ROWS=0.0144)
       3960696072677096522 OPTIMIZER_FEATURES_ENABLE(default)

让我们删除sql profile，重新创建并设置force_match为false，

SQL> exec dbms_sqltune.drop_sql_profile('SYS_SQLPROF_01436cac2c3c0000');

PL/SQL 过程已成功完成。

SQL> exec dbms_sqltune.accept_sql_profile(task_name=>'任务_309',task_owner=>user,replace=>true,force_match=>false);

PL/SQL 过程已成功完成。

SQL> set autotrace traceonly explain
SQL> select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' AND T1.object_id=t2.object_id;

执行计划
----------------------------------------------------------
Plan hash value: 1022743391

---------------------------------------------------------------------------------------
| Id  | Operation		     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|   1 |  NESTED LOOPS		     |	      |       |       | 	   |	      |
|   2 |   NESTED LOOPS		     |	      |    36 |  1476 |   141	(1)| 00:00:02 |
|*  3 |    TABLE ACCESS FULL	     | T1     |    36 |  1080 |    69	(2)| 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 by operation 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_01436d001cfe0001" used for this statement

SQL> select t1.*,t2.owner from t1,t2 where t1.object_name like '%T2%' AND T1.object_id=t2.object_id;

执行计划
----------------------------------------------------------
Plan hash value: 1838229974

---------------------------------------------------------------------------
| Id  | Operation	   | Name | Rows  | Bytes | Cost (%CPU)| Time	  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |	  |  2500 |   100K|   370   (1)| 00:00:05 |
|*  1 |  HASH JOIN	   |	  |  2500 |   100K|   370   (1)| 00:00:05 |
|*  2 |   TABLE ACCESS FULL| T1   |  2500 | 75000 |    69   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| T2   | 75308 |   808K|   300   (1)| 00:00:04 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   2 - filter("T1"."OBJECT_NAME" LIKE '%T2%' AND "T1"."OBJECT_NAME" IS
	      NOT NULL)
我们看到对于相似的sql语句，sql profile不会发生作用

在来看看关于signatrue的内容

SQL> select sql_text,to_char(exact_matching_signature),to_char(force_matching_signature) from v$sql where sql_text like 'select t1.*,t2.owner from t1,t2 %';

SQL_TEXT				 TO_CHAR(EXACT_MATCHING_SIGNATURE)	  TO_CHAR(FORCE_MATCHING_SIGNATURE)
---------------------------------------- ---------------------------------------- ----------------------------------------
select t1.*,t2.owner from t1,t2 where t1 8975541025552400288			  3960696072677096522
.object_name like '%T1%' AND T1.object_i
d=t2.object_id

select t1.*,t2.owner from t1,t2 where t1 16954193673788994662			  3960696072677096522
.object_name like '%T2%' AND T1.object_i
d=t2.object_id

SQL> l
  1  SELECT so.signature,extractValue(value(h),'.') AS hint
  2  FROM sys.sqlobj$data od, sys.sqlobj$ so,
  3  table(xmlsequence(extract(xmltype(od.comp_data),'/outline_data/hint'))) h
  4  WHERE so.name = 'SYS_SQLPROF_01436d001cfe0001'
  5  AND so.signature = od.signature
  6  AND so.category = od.category
  7  AND so.obj_type = od.obj_type
  8* AND so.plan_id = od.plan_id
SQL> /

			 SIGNATURE HINT
---------------------------------- ------------------------------------------------------------------------------------------
	       8975541025552400288 OPT_ESTIMATE(@"SEL$1", TABLE, "T1"@"SEL$1", SCALE_ROWS=0.0144)
	       8975541025552400288 OPTIMIZER_FEATURES_ENABLE(default)

我想到这里大家应该都明白了，当force_match为true时，sql profile适合sql语句的force_match_signature项匹配的，而当force_match取值false时，sql profile是和sql语句的extract_match_signature相匹配的。

另为有一点，当我们创建sqlprofile后，可以放心删除tuning_task,已创建的sql profile不会受影响。


实战:oracle sql profile
yangzhawen
01-14 6401
************************************************************ 第一部分：profile概念 ************************************************************ Oracle数据库10g使用了一个叫做SQL配置文件的新方法弥补了存储概要的缺点， DBA可以使用SQL
oracle 固定执行计划(一）之 sql_profile
chengcheng的博客
10-11 8026
到oracle11G 时，已经有三种方式来固定执行计划了 1.10G以前用的是存储大纲 2.10G多了一种，sql_profile 3.11G又多了sql plan management 今天先讲讲sql_profile，其他两种后面再补上 1.先创建一张测试表， SQL> create table emp as select * from scott.emp; Table
Oracle固定执行计划之SQL PROFILE概要文件详解
01-21
1.  引子 Oracle系统为了合理分配和使用系统的资源提出了概要文件的概念。所谓概要文件，就是一份描述如何使用系统的资源(主要是CPU资源)的配置文件。将概要文件赋予某个数据库用户，在用户连接并访问数据库服务器时，系统就按照概要文件给他分配资源。 包括: 1、管理数据库系统资源。 利用Profile来分配资源限额，必须把初始化参数resource_limit设置为true默认是TRUE的。 2、管理数据库口令及验证方式。 默认给用户分配的是DEFAULT概要文件，将该文件赋予了每个创建的用户。但该文件对资源没有任何限制，因此管理员常常需要根据自己数据库系统的环境自行建立概要文件。 2. 
25.Oracle深度学习笔记——SQL PROFILE概要文件
热门推荐
badman250的专栏
03-08 3万+
25.Oracle深度学习笔记——SQL PROFILE概要文件  欢迎转载，转载请标明出处： 1.  引子 Oracle系统为了合理分配和使用系统的资源提出了概要文件的概念。所谓概要文件，就是一份描述如何使用系统的资源(主要是CPU资源)的配置文件。将概要文件赋予某个数据库用户，在用户连接并访问数据库服务器时，系统就按照概要文件给他分配资源。 包括: 1、管理数据库系统资源。 利用P
如何在 Oracle 中配置和使用 SQL Profiles 来优化查询性能？
最新发布
weixin_45422672的博客
06-28 671
在 Oracle 数据库中，SQL Profile 是通过 SQL Tuning Advisor 生成的优化对象，用于为特定 SQL 语句提供补充统计信息以改进执行计划。注：对于 OLAP 类复杂查询，SQL Profile 的效果通常比 OLTP 场景更显著。建议在应用变更后重新评估 Profile 的有效性。报告中将包含是否推荐创建 SQL Profile 的建议。
Oracle固定SQL的执行计划(一)---SQL Profile
weixin_33859504的博客
02-28 202
我们都希望对于所有在Oracle数据库中执行的SQL，CBO都能产生出正确的执行计划，但实际情况却并非如此，由于各种各样的原因(比如目标SQL所涉及的对象的统计信息的不准确，或者CBO内部一些成本计算公式的先天缺陷等)，导致有时CBO产生效率不高、甚至是错误的执行计划。特别是CBO对目标SQL所产生的初始执行计划是正确的，后来由于某种原因(比如统计信息的变更等)而导致CBO重...
Oracle数据库之OracleC12--用户概要文件profile
也许是我送你哦
05-06 1940
1、在CDB中查询数据库中有多少个profile： SQL> select distinct profile from dba_profiles; PROFILE -------------------------------------------------------------------------------- ORA_STIG_PROFILE DEFAULT 2、查看指定的...
优化资源分配：Oracle SQL PROFILE概要文件详解
Oracle固定执行计划中的SQL PROFILE概要文件是一种关键的数据库配置机制，它帮助管理员有效地管理和分配数据库资源。概要文件是一个配置文件，主要用于描述用户如何使用CPU资源，特别是对于并发会话、CPU时钟限制、...
【2024亲测无坑】Oracle--19C在Centos7上的静默安装（rpm版）
数据库学习ing
06-14 1778
然后 yum localinstall oracle-database-preinstall-19c-1.0-1.el7.x86_64.rpm。配置好后source一下 ：source /home/oracle/.bash_profile。如果不是OEL平台，首先要下载对应平台的RPM，我用的是RedHat 7.4，下载链接地址，命令：/etc/init.d/oracledb_ORCLCDB-19c configure。第一次执行未必可以成功，我的提示少了依赖库。19c的RPM包下载链接，
oracle10g新特性-sql profile
weixin_34364071的博客
09-14 114
如果因为sql语句执行计划不稳定导致查询速度慢，可以考虑使用sql profile。具体的就不多写了，直接查看该链接http://chenxy.blog.51cto.com/729966/747014
Oracle SQL Profile及SPM使用
dba笔记
06-25 1825
IT数据库行业小学生，记录日常工作中数据库知识及一些故障案例，如有不对请指正，欢迎关注小编，小编微信xh870545795,优快云:dba_notes一、区别 我们知道oracle稳定执行计划有两种方式，一种是使用SQL profile（oracle 10g以前通常使用这种方式），还有一种是SPM(SQL Plan Management,oracle 11g推出的新功能)，两者的主要...
ORACLE_PROFILE的使用详解
10-12
ORACLE_PROFILE的使用详解;Oracle数据库审计功能的使用
SQL概要文件--转自老熊的BLOG
cixiangmi4927的博客
01-17 347
转帖，原文见：http://www.laoxiong.net/sql-profiles-partii.html#comment-1098Oracle 11g从发布到现在，也有几个年头了。而在国内来说，Oracle 10g仍然是主...
oracle sql profile(Manual)使用。
cuizu4125的博客
12-11 312
以下模拟如何在不改变sql文本的情况下使用sql profile来改变其执行计划，以期达到优化的目的。 sql profile分Manual ,AUTO两类，先介绍Manual方式的创建。 使用Manual的sql ...
Oracle SQL Profile：优化查询性能的神奇“魔法棒”
JiekeXu的博客
03-31 946
请务必注意，随着表数据的增长或索引的创建或删除，执行计划可能会使相同的 SQL Profile 发生变化。随着表数据的增长，或者随着索引的创建或删除，SQL Profile 的计划也会发生变化。如果语句在 SQL 计划基线中有多个计划，则 SQL Profile 文件非常有用，因为它使优化程序能够在基线中选择成本最低的计划。在此示例中，计划位于语句的 SQL 计划基线中。全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
Oracle 使用 sql profile 固定执行计划
Ahern_的博客
01-02 1216
Oracle 10g之前有outlines,10g之后 sql profile。如果针对非绑定变量的sql,outlines则效果不佳，不建议使用。4、创建sql profile(SQLPROFILE_01)5、查看是否使用 sql profile。2、获取新sql的sql_id。
oracle概要文件
贾世鑫的博客
05-25 936
connect sys/12345678 as sysdba 使用概要文件 创建一个概要文件，仅用于限制用户对一下资源的使用 1.不限制用户建立的并发会话数 2.每个会话中，不限制用户使用的cpu时间 3.单个会话中的持续时间不能超过三小时 4.会话中的持续空闲时间不能超过5min 5.单个会话在SGA中分配的内存了不能超过60KB； CREATE PROF
oracle固定执行计划1-sql profile
fanzhuozhuo的博客
03-05 1435
oracle固定执行计划SQL Profileautomatic类型的sql profile SQL Profile 1、SQL profile在Oracle 10g引入 2、通过为特定的SQL文本指定优化器的一些信息，从而引导优化器生成更为合理的SQL执行计划。达到不修改SQL文本就可以改变并指定执行计划的目的。 3、通常和SQL Tuning Advisor一起用 4、也可以手工设置 automatic类型的sql profile 1、构造测试环境： session 1： conn scott/tige
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值