凡是会看到Note中有雷同下面这样的提示； Note------ SQL profile SYS_SQLPROF_0158283a9b920000 used for this statement SQL profile由工钱手工建设或在Automatic SQL Tunning阶段由SQL tuning advisor建设。

因为统计信息不包罗这些信息，DD)SYS_SQLPROF_01582d15092f0001CH# PARENT_HANDLE OBJECT_HANDLEPARSES H_PARSES EXECUTIONS FETCHES ROWS_PROCESSEDLIOSPIOSSORTSCPU_MSELA_MS USERS_EXECUTING----- ---------------- ---------------- ---------- ---------- ---------- ---------- -------------- ---------- ---------- ---------- ---------- ---------- ---------------0 0000000064618858 0000000063A0310813121016607.9998.6210Oracle 阐明背后做了什么 很诧异，orders， COUNT(*) AS C3 FROM ORDERS ORDERS WHERE (ORDERS.ORDER_DATE=TRUNC(SYSDATE@!，它看起来有如下的意思: 在优化器评估SQL时利用了特另外 工具 辅佐完成评估； 工具 改变了优化器原先的评估打算； 当看到这些信息，scope= COMPREHENSIVE，可是如何生存这些信息呢?不行能通过按期性的更新统计信息， ORDER_DATE[DATE，然后做出评估，所以，fmdd))) innerQuerySELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) opt_param(parallel_execution_enabled， false) result_cache */ COUNT(C1)FROM (SELECT /*+ qb_name(innerQuery) NO_INDEX_FFS( ORDERS) */ 1 AS C1 FROM ORDERS SAMPLE BLOCK(56.8182， scale_rows=10) */ 可能 /+ opt_estimate(index_scan，这种阐明对付大大都数据来说往旧事情得很好，评估时默认的cardinality将乘以这些数字，order_date上建设了索引，但实际环境中，数值2比数值5一样利用频繁)； 数据行漫衍匀称(好比假设：没有物理cluster可能数据排序)； 对付范畴数据是持续的， IDX_ORDERS_DT， false) result_cache */ COUNT(C1)FROM (SELECT /*+ qb_name(innerQuery) INDEX_FFS( ORDERS IDX_ORDERS_DT) */ 1 AS C1 FROM ORDERS SAMPLE BLOCK(59.5238， SCALE_ROWS=3.545138895e-05) */ C1， false) result_cache OPT_ESTIMATE(@innerQuery。

但优化器对范畴评估错误，剩余的2%的数据大概只会合在几个数据块中；不幸的是 收集统计信息时没有记录这些细节 ；这就激发一个问题，所以到了这里问题转变为什么可以补充或更正这些信息，反复多次运行旧的执行打算和新的执行打算，让优化器从头评估； 假如优化器评估出新的执行打算，fmdd))------------------------------------------------------------------------------- oracle通过阐明发明白问题。

C3FROM (SELECT /*+ qb_name(innerQuery) INDEX( ORDERS IDX_ORDERS_DT) */ COUNT(*) AS C1，7]Note------ SQL profile SYS_SQLPROF_01582d15092f0001 used for this statementSQL @sql 2061925043Show SQL text，10]，接着利用DBMS_SQLTUNE阐明SQL； var task_name varchar2(30)BEGIN:task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_text = select * from orders where order_date=trunc(sysdate，为什么阐明后优化器就能找出问题地址，好比对付一张大表，生成好的执行打算，how it work and what are SQL Profiles... 利用DBMS_XPLAN.DISPLAY阐明SQL执行打算， 不行制止的有违反法则的破例 ，直方图信息；换一种通俗的说法，oracle 以opt_estimate hints的名目生存cardinality信息； /+ opt_estimate(table， 优化器的问题 凡是优化器相信: 数据值漫衍匀称(好比假设：表列数据中。

为什么需要SQL Profile Why oracle need SQL Profiles。

distinct value，max/min value， 2) SEED(1) ORDERS) innerQuerySELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) opt_param(parallel_execution_enabled，数据库利用一个独立的工具(SQL Profile)生存SQL和这些(cardinality)信息，order_date)asselectlevel， ORDERS，fmdd))2- Using SQL Profile--------------------Plan hash value: 3364688013---------------------------------------------------------------------------------------------| Id | Operation| Name| Rows | Bytes | Cost (%CPU)| Time|---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT|| 18 | 234 |3 (0)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERS| 18 | 234 |3 (0)| 00:00:01 ||* 2 | INDEX RANGE SCAN| IDX_ORDERS_DT | 10 ||2 (0)| 00:00:01 |---------------------------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------2 - access(ORDER_DATE=TRUNC(SYSDATE@!，DD) 从trace文件阐明得出，这些信息包罗表行记录数，将耗损小的执行打算信息生存到SQL profile中， DATE 9999-01-01); 和正常利用的一样， exec dbms_sqltune.ACCEPT_SQL_PROFILE(TASK_NAME=:task_name); 再次执行SQL时。

获取到 真实的实数信息 (最重要的好比，22]，7] 显然对付这样一张生意业务记录表， SQL @iUSERNAMEINST_NAMEHOST_NAMESID SERIAL# VERSION STARTED SPIDOPID CPIDSADDRPADDR-------------------- -------------------- ------------------------- ----- -------- ---------- -------- ---------- ----- --------------- ---------------- ----------------OPS$SYWUsydbsywu.com288 22197 11.2.0.4.0 20160421 1373646 3392:13120000000071FE0DA0 0000000072149F40碰到的问题 假设有这样一张雷同订单的表orders； create table orders(order_no，优化器利用了SQL Profile和新的执行打算， false) result_cache */ COUNT(C1)FROM (SELECT /*+ qb_name(innerQuery) NO_INDEX_FFS( ORDERS) */ 1 AS C1 FROM ORDERS SAMPLE BLOCK(56.8182，但有些初级此外信息丢失了 ，fmdd))) innerQuery/* SQL Analyze(156。

利用索引扫描的方法开销小于全表扫描。

ORDER_DATE[DATE，发生了新的执行打算，优化器会更真实的查察到表中的数据信息。

统计信息捕捉了表整体形状数据，DD)， orders。

fmdd))Column Projection Information (identified by operation id):-----------------------------------------------------------1 - ORDERS.ORDER_NO[NUMBER， scale_rows=0.001) */ 所以假如利用了SQL Profile。

Cardinality) 提供这些真实的实数信息给优化器， TABLE，cast(sysdate-level/24 as date) fromdualconnect by level=5E5;SQL @desc ordersNameNull? Type------------------------------- -------- ----------------------------1ORDER_NONUMBER2ORDER_DATEDATE 生存订单信息， 2) SEED(1) ORDERS WHERE ( ORDERS.ORDER_DATE IS NOT NULL)) innerQuerySELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) opt_param(parallel_execution_enabled，user_name = user。

C2。

最后比拟机能； 假如优化器试运行得出的功效为: 优化器评估后发生了新的执行打算； 新的执行打算比旧的执行打算机能耗损更小，最终决解了碰到的问题，7] 2 - ORDERS.ROWID[ROWID， 优化器信任收集的统计信息， 4294967295 AS C2， 什么是SQL Profile 通过上面的尝试概略将SQL Profile界说为： 为特定SQL建设和生存执行打算信息； 利用实际运行时的数据来辅佐优化器为特定的SQL评估和生成更好的执行打算； 首先通过dbms_sqltune.create_tunning_task建设任务汇报数据库存在问题的可以改进的SQL， task_owner = OPS$SYWU，DD)-------------------------------------------------------------------------------FINDINGS SECTION (1 finding)-------------------------------------------------------------------------------1- SQL Profile Finding (see explain plans section below)-------------------------------------------------------- A potentially better execution plan was found for this statement. Recommendation (estimated benefit: 98.78%) ------------------------------------------ - Consider accepting the recommended SQL profile.execute dbms_sqltune.accept_sql_profile(task_name =orders_tuning_task， select * from orders where order_date=trunc(sysdate，为了测试这个问题，DD);SQL_ID 3zcvw1pxfcypm，较量体贴的是这个工具(SLQ profile)是什么?它做了什么?是否真的需要它?带着这些疑问进修和摸索，大幅晋升机能； 则表白优化器证明旧的评估对付特定的SQL是错误的，DD)Plan hash value: 3364688013---------------------------------------------------------------------------------------------------------------------------------------| Id | Operation| Name| Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers |---------------------------------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT||1 |||3 (100)||10 |00:00:00.01 |6 || 1 | TABLE ACCESS BY INDEX ROWID| ORDERS|1 |18 | 234 |3 (0)| 00:00:01 |10 |00:00:00.01 |6 ||* 2 | INDEX RANGE SCAN| IDX_ORDERS_DT |1 |10 ||2 (0)| 00:00:01 |10 |00:00:00.01 |3 |---------------------------------------------------------------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id):-------------------------------------------------------------1 - SEL$1 / ORDERS@SEL$1 2 - SEL$1 / ORDERS@SEL$1Outline Data------------- /*+BEGIN_OUTLINE_DATAIGNORE_OPTIM_EMBEDDED_HINTSOPTIMIZER_FEATURES_ENABLE(11.2.0.4)DB_VERSION(11.2.0.4)ALL_ROWSOUTLINE_LEAF(@SEL$1)INDEX_RS_ASC(@SEL$1 ORDERS@SEL$1 (ORDERS.ORDER_DATE))END_OUTLINE_DATA */Predicate Information (identified by operation id):---------------------------------------------------2 - access(ORDER_DATE=TRUNC(SYSDATE@!，实际当天的记录数据只占全表数据量的4.1%阁下，0) */ select * from orders where order_date=trunc(sysdate， cascade = true); 当系统查询当天的生意业务记录时发明优化器利用全表扫描，该表按期收集了统计信息； exec dbms_stats.gather_table_stats(user，oracle会将这些信息生存供今后利用。

并比拟两个执行打算，新的执行打算改进90%+的机能，fmdd))Column Projection Information (identified by operation id):-----------------------------------------------------------1 - ORDERS.ORDER_NO[NUMBER， ， replace = TRUE); Validation results ------------------ The SQL profile was tested by executing both its plan and the original plan and measuring their respective execution statistics. A plan may have been only partially executed if the other could be run to completion in less time.Original Plan With SQL Profile % Improved------------- ---------------- ---------- Completion Status:COMPLETECOMPLETE Elapsed Time (s):.041546.00013299.68 % CPU Time (s):.029895.000199.66 % User I/O Time (s):.015204.00003299.78 % Buffer Gets:328498.78 % Physical Read Requests:450100 % Physical Write Requests:00 Physical Read Bytes:10682368983099.9 % Physical Write Bytes:00 Rows Processed:1010 Fetches:1010 Executions:11 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: 1275100350----------------------------------------------------------------------------| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| Time|----------------------------------------------------------------------------| 0 | SELECT STATEMENT || 18 | 234 | 130 (26)| 00:00:02 ||* 1 | TABLE ACCESS FULL| ORDERS | 18 | 234 | 130 (26)| 00:00:02 |----------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------1 - filter(ORDER_DATE=TRUNC(SYSDATE@!，没有漏缺。

一些初级的数据被阐明出，发明如下信息； SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) opt_param(parallel_execution_enabled， ORDER_DATE[DATE。

child number 0-------------------------------------select * from orders where order_date=trunc(sysdate，level 12;exec DBMS_SQLTUNE.execute_tuning_task(task_name = :task_name); 阐明功效； col REPORT_TUNING format a200selectdbms_sqltune.report_tuning_task(:task_name) REPORT_TUNINGfromdual;REPORT_TUNING----------------------------------------------------------------------------------------------------------------------GENERAL INFORMATION SECTION-------------------------------------------------------------------------------Tuning Task Name : orders_tuning_taskTuning Task Owner : OPS$SYWUWorkload Type: Single SQL StatementScope: COMPREHENSIVETime Limit(seconds): 60Completion Status : COMPLETEDStarted at: 11/07/2016 21:43:25Completed at: 11/07/2016 21:43:27-------------------------------------------------------------------------------Schema Name: OPS$SYWUSQL ID: 9ybj4xdc5hsrbSQL Text : select * from orders where order_date=trunc(sysdate，task_name = orders_tuning_task);END;/ 执行阐明； alter session set events 10046 trace name context forever，这个操纵在11G或今后的版本中可以通过Automatic SQL Tuning在对most active SQL 阐明时建设；然后运行dbms_sqltune.execute_tuning_task评估。

22]，并非索引扫描； -------------------------------------------------------------------------------------------------------------------------------| Id | Operation| Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Reads |-------------------------------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT ||1 ||| 130 (100)||10 |00:00:00.23 |329 | 323 ||* 1 | TABLE ACCESS FULL| ORDERS |1 | 496K| 6302K| 130 (26)| 00:00:02 |10 |00:00:00.23 |329 | 323 |-------------------------------------------------------------------------------------------------------------------------------Query Block Name / Object Alias (identified by operation id):-------------------------------------------------------------1 - SEL$1 / ORDERS@SEL$1Outline Data------------- /*+BEGIN_OUTLINE_DATAIGNORE_OPTIM_EMBEDDED_HINTSOPTIMIZER_FEATURES_ENABLE(11.2.0.4)DB_VERSION(11.2.0.4)ALL_ROWSOUTLINE_LEAF(@SEL$1)FULL(@SEL$1 ORDERS@SEL$1)END_OUTLINE_DATA */Predicate Information (identified by operation id):---------------------------------------------------1 - filter(ORDER_DATE=TRUNC(SYSDATE@!。

create index idx_orders_dt on orders(order_date); 在生意业务中大概常常碰到某些原因导致生意业务延期的环境，此时核心都会合在trace文件了；阐明trace文件，进一步，time_limit = 60，这个进程包罗三个主要步调: 动态采样阐明表数据， child cursors and execution stats for SQL hash value 2061925043 child OPS$SYWU@sydb_111 reportHASH_VALUE CH# PLAN_HASH SQL_TEXTSQL_PROFILE---------- ----- ---------- -------------------------------------------------------------------------------------------------------------- ------------------------------20619250430 3364688013 select * from orders where order_date=trunc(sysdate。

98%的数据大概以随机的方法分派在整个段中(segment)， orders，已经有的统计信息不能完全有效的辅佐优化器生成正确的执行打算， 2) SEED(1) ORDERS WHERE (ORDERS.ORDER_DATE=TRUNC(SYSDATE@!，而且改进机能问题只需要同意利用SQL Profile即可；然后答允数据库利用SQL Profile，开拓人员添加了将来某一天这样的日期值测试；这里用一个清晰的时间来取代将来的日期； INSERT INTO ORDERS VALUES (-1。

oracle做了如下的操纵: 动态采样阐明全表数据(无索引)； 动态采样阐明表中非空数据(无索引)； 用全表扫描的方法动态采样阐明相关的数据； 用索引扫描的方法动态采样阐明相关的数据； 比拟旧的和新的执行打算； Oracle比拟旧的和新的执行打算后。

让优化器面临这种特定的SQL时可以评估正确，。