<P></P><P>[face=黑体]关于oracle实例学习 Oracle实例学习的目的在于学习工具和为了共享信息或者复杂的事件，进程，程序以及一系列相关联事件的知识。本篇所介绍的每一种实例学习都是笔者自己所遇到过的。 每一种实例学习包括一种技能水平评级。这种评级（它标示了读者的技能水平）应该会在实例学习中与一些信息相关。 评级为： 专家级：对subject matter有很多的经验。 中间级：对subject matter有一些经验。 初学者级：对subject matter 有一点了解 实例学习抽象 这个案例学习使用了一个来自于实际的服务请求的追踪文件为了分析10053追踪文件的论证方法。请注意，设计10053追踪文件是为了帮助开发者的和支持个人诊断优化程序的问题并能为每一个补丁集和释放做出改变。我们的这种实例学习的intent并没有为10053追踪文件提供一个可以理解的论述，但是却显示了追踪文件是如何由oracle工程师所使用的。在这个过程中，我们也会获得CBO是如何知道查询成本的，并最终如何执行这个计划的。指出由CBO所使用的算法是很重要的来评估有一个版本到另一个版本查询成本的变化。 我们的任务是分析坏的计划和确定的CBO如何计算成本，以更便宜的，但有缺陷的计划。在某些点上，我们将比较都10053痕迹，但主要集中在如何坏计划的计算成本。良好的计划，基本上是一个坏的计划（在被认为是没有索引）较短的版本。 研究10053的原因通常是理解为什么CBO做出了决定。 10053将有助于回答这个问题：“为什么不使用我的索引？”或相关的，“为什么选择CBO的全表扫描（FTS）？”。 10053是通常不开始寻找调整的机会 - 执行计划和TKPROF有更好的在这方面的信息;10053更深层次的原因决心用最好的地方。 实例历史 这种情况是一个unhinted SQL语句（选择涉及3方式加入）将超过9小时，与“NO_INDEX”暗示将在不到4分钟完成的声明与执行。分区表和正在使用并行查询。此外，客户已设置“OPTIMIZER_INDEX_CACHING”70（原因不明，但我们可以打赌，这大概是因为他们没有计划，他们很喜欢）。此参数有单块指数的I / O的成本降低了70％的效果。 获得了10053的痕迹都unhinted（“坏”）计划，并暗示（“好”）计划。这两个计划之间的主要区别是坏计划的所有嵌套循环联接，采用的最内层加入索引全扫描（不索引快速全扫描）操作有内部的行来源。良好的计划使用索引快速全扫描（IFF）操作作为内部资料来源哈希联接 这里的原始跟踪文件是坏的计划。请注意，此案例研究是非常敏感的变化，可能会出现在未来的10053跟踪文件。一般来说，后来跟踪文件的版本应该更容易阅读和“预分析工作”一节中需要较少的努力。 前期的分析工作 跳转到跟踪文件的分析之前，我们必须做出一些意见和派生的一些因素，CBO将使用计算其成本。有时，这些参数和因素的价值，将提供有关为什么一个特定的计划是竞争的计划，选择良好的初步迹象。 收集事件10053跟踪文件，使用以下语法在sqlplus中： SQL> connect / as sysdbaSQL> oradebug setmypidSQL> oradebug unlimitSQL> oradebug event 10053 trace name context forever, level 1SQL> ...enter your query here...SQL> oradebug event 10053 trace name context offSQL> oradebug tracefile_name/chia/web/admin/PTAV3/udump/ptav3_ora_15365.trc  "oradebug tracefile_name" 的输出将会指向10053追踪文件 确认被跟踪查询 这是一个重要的步骤，因为我们要确保我们正在研究相关查询跟踪。找到的SQL跟踪文件名为“QUERY”的部分，并确保它是正确的。在版本10g中，查询的部分是在跟踪结束时没有绑定变量是在查询中，否则，它会在开始跟踪。 要注意跟踪与查询有关。有时可以很容易误以为在跟踪结束，属于跟踪如下（可能发生在10g中，没有在SQL结合）查询。  B) 感兴趣的参数： OPTIMIZER_FEATURES_ENABLE = 9.2.0 _OPTIMIZER_PERCENT_PARALLEL = 101 OPTIMIZER_INDEX_CACHING = 70 此参数会影响使用索引的原始成本(100 - optimizer_index_caching)/100。因此，在这种情况下，它会降低索引读取成本，使用这个因素：（100 - 70）/ 100= 0.3或1/3左右。这意味着什么，他们本来是1/3的成本指数成本将乘以0.3。请注意索引的I / O成本计算从“BLEVEL”，“LEAF_BLOCKS”，和“CLUF”（聚类因子）的值，此参数只影响部分成本的由BLEVEL和LEAF_BLOCKS贡献。 CLUF影响成本的访问表，并没有由OPTIMIZER_INDEX_CACHING折现。 OPTIMIZER_INDEX_COST_ADJ = 99 这个参数将用于扩展索引访问的运作成本，通过分数： optmizer_index_cost_adj / 100.  在这里，它可能是99/100或者0.99.这个参数会影响所有的索引成本，甚至是这些所用的连接 OPTIMIZER_DYNAMIC_SAMPLING = 1 此参数用于控制如何积极CBO的动态采样，给它大约需要花费访问路径的基数和选择性的信息依赖。设置为1，它基本上只样品，如果统计数字是从查询中的表失踪。 _OPTIMIZER_COST_MODEL = CHOOSE 如果设置为CHOOSE，在系统统计被收集了情况下，那么CBO会使用新的CPU模式。如果设置为了I/O，它会使用旧的成本模型来忽略CPU成本。 DB_FILE_MULTIBLOCK_READ_COUNT = 64 此参数可控制执行全表或索引扫描的成本。此参数值更高，将导致CBO的全部费用表或索引扫描便宜。值是通过使用一个固定的公式（当OPTIMIZER_COST_MODEL= IO）或从实际系统收集的统计数据计算的缩放因素CBO的缩小。 _CPU_TO_IO = 0 (default) 此参数用于扩展CPU周期来为I / O成本计算使用的CPU和I / O成本构成整体成本的目的。如果设置为0，默认值，CBO将使用一个内部的固定值，或从收集到的数据与系统的统计数据（其中包括CPU速度，单块I / O时间，多块I / O时间，得出一个值平均数在多块的I / O读取的块）。为了验证成本，CBO是考虑到CPU成本，这是重要的，以确定哪些CBO是使用这个值。  C) 由CBO计算CPU到I/O的比率 为了确定由CBO使用的_CPU_TO_IO being 值，必须要在10053中找到一个条目来显示每一种数据：CPU cost, I/O cost, combined cost。我们也可以通过在CBO内部计算来获知这三个值然后把他们应用到与他们相关联的公式中。 _CPU_TO_IO 这个值一直都通过10053保持不变并且对于任何的计算都是相同的，所以对于任何条目显示的这三个部分都是可用的。有一点需要记住，选择一个与CPU和I/O成本更高的值，因为值更高，衍生因子更加精准。 4.查找索引快速全（论坛）扫描或显示的CPU，IO和总的东西。 Access path: index (iff)Index: PK_CIPBF_IXTABLE: CERT_INSURED_PLAN_BENEFIT_FACTRSC_CPU: 2865229980   RSC_IO: 52693IX_SEL:  0.0000e+00  TB_SEL:  1.0000e+00Access path: iff  Resc:  55630  Resp:  27815   4.Use the formula:             Combined Resc Cost = (RSC_CPU cost / _cpu_to_io) + RSC_IO CostSolve for _cpu_to_io:_cpu_to_io = RSC_CPU Cost / (Combined Cost - RSC_IO Cost)= 2865229980   / (55630 - 52693)= 975563.49 CPU cycles per IO D)  计算多块读除数 当CBO在评估一张全表扫描的成本或者一个索引快速的扫描，它会在一个表或索引的总块数除以除数是将读多少块估计每个物理读磁盘（这里的多块读除数或MBDivisor的）。在过去，使用参数“DB_FILE_MULTIBLOCK_READ_COUNT估计的MBDivisor的值（它的价值是由公式为现实世界的限制，以弥补减少）的基础上，在9.2和更高版本，估计值的MBDivisor不同，如果系统的统计数据收集。 在分析10053之前，了解下CBO的起源是很有必要的，以至于我们能在之正确的情况下能够快速的发现它。非常低的值将导致CBO成本FTS的和敌我识别多个索引访问路径昂贵;高值往往会花费FTS的/ IFF便宜得多。 为了得到除数，找到一个单一的表的访问路径条目和获取资源的成本表扫描（RESC“）（”TSC“）。然后找到表中的块的总数。计算如下因素：tsc cost = Num Blocks / MBDivisor Solve for the MBdivisor:  MBdivisor = Num Blocks / tsc cost For example:From the "Base Statistical Information" section: Table stats    Table: CERTIFICATE   Alias: A12 PARTITION [95]    CDN: 3164453  NBLKS:  125272  AVG_ROW_LEN:  617TOTAL ::  CDN: 3164453  NBLKS:  125272  AVG_ROW_LEN:  617 From the "Single Table Access Path" section: SINGLE TABLE ACCESS PATH... TABLE: CERTIFICATE     ORIG CDN: 3164453  ROUNDED CDN: 2089  CMPTD CDN: 2089 Access path: tsc  Resc:  116982  Resp:  29052 Mdivisor = Nblks / tsc Mdivisor = 125272 / 116982 = 1.07 注意：此因素似乎非常低。这将是非常有益的，看看有什么系统的统计数据是如何计算这个值。低值FTS的敌我识别索引扫描，扫描相对昂贵。其可能的，这些值是不现实的，但它也有可能系统的统计期间的时间，并不代表实际的负载。考虑如何将是昂贵的FTS的，有趣的是，顾客觉得他们打倒指数成本进一步使用index_cost_adjustment参数。不难看出，这个数据库将喜欢几乎任何一种指数比在许多情况下，FTS的访问。 这似乎是不寻常的OPTIMIZER_INDEX_COST_ADJ的那么高，当多块除数已经很低，可能客户一套气馁反正CBO的选择非索引路径。这将是有益的，知道为什么顾客设置该值的历史原因。  E)  扫描" BASE STATISTICAL INFORMATION" 和" SINGLE TABLE ACCESS PATH" 这两部分来寻找失去的和不重要的统计数据。 典型的问题包括： 在表中和索引中是去了统计数据如果统计对象尚未聚集，你会看到这样的消息："(NOT ANALYZED)".  不幸的是，索引有没有消息明确表示，他们没有分析。相反，你将有阅读指数统计和寻找默认的统计数据。为LEAF_BLOCKS的默认统计是25日和为CLUSTERING_FACTOR是800。 对于分区对象，确定是否已聚集了全球唯一的统计数据或分区级别统计。 检测到的全球唯一（没有分区级统计信息收集），寻找未经分析的分区。实例（而不是从当前跟踪）： Table stats Table: SALES Alias: SALES(Using composite stats)(making adjustments for partition skews)ORIGINAL VALUES:: CDN: 919315 NBLKS: 1768 AVG_ROW_LEN: 29PARTITIONS::PRUNED: 5ANALYZED: 0 UNANALYZED: 5TOTAL :: CDN: 919315 NBLKS: 94 AVG_ROW_LEN: 29 不幸的是，有没有办法告诉复合材料的统计，如果是一个全球性的抽样或聚合各个分区。全球取样是首选，所以如果有疑问，如果DBA_TABLES.GLOBAL_STATS等于YES确认全球统计数据收集。 没有直方图寻找特定列“直方图”等报表。实例（而不是从当前跟踪）： SINGLE TABLE ACCESS PATHCOLUMN: TIME_ID(DATE) Col#: 3 Table: SALES Alias: SALESSize: 8 NDV: 1187 Nulls: 0 Density: 8.4246e-04 Min: 2450815 Max: 2452275No Histogram: #BKT: 1(1 uncompressed buckets and 2 endpoint values)   分析 总结 用来分析10053的程序基本上是从底部的跟踪工作文件感兴趣的领域。这似乎是一个有缺陷的计划的一部分，当它涉及到一个地区的利益。 总之，下面的这些步用来分析10053追踪文件： 1. 以结尾开始 确认你所感兴趣的SQL是属于你在分析的追踪文件中。如果EXPLAIN PLAN在追踪中，那么缩进，使其可读。 2.看已经选择的计算的最后的成本 3.找到连接顺序产生的最后成本 4.  找到成本计算的利息是连接顺序的一部分 5.  找到特定的连接的类型，产生的成本的连接顺序 6.  第5步中找到的连接类型的检查费用。 a. 确定访问路径被用来 b. 检查其他的访问路径被拒绝（只适用于嵌套循环联接多个访问路径的内部行源费用） 详细分析   以结尾开始，解释原因 对10053始终获得一个精准的输出结果是很重要的。在10053中会丢失一些信息，我们需要就成本的核算做出一个结论。其他时间，我们将要使用的计划，以浏览10053或完整性检查我们自己的分析。 确保缩进计划的步骤，根据父ID，以使该计划的层次可读。 请注意跟踪文件中嵌入的解释计划输出版本之间的不同，往往是不存在的。在10g中，您可以通过打开10053跟踪，然后执行解释计划的一个很好的格式化的计划......命令。然而，绑定值的存在，可能会影响实际的计划，生产和EXPLAIN PLAN命令将无法赶上它用来执行绑定窥视到一个不同的代码路径。2.  Look at final cost of the plan: Final: CST: 20762  CDN: 1  RSC: 83447  RSP: 20762  BYTES: 173IO-RSC: 20658  IO-RSP: 82626  CPU-RSC: 101017010  CPU-RSP: 801120184 PLAN Cost of plan:  20762 Operation...........Object name.....Options.........Id...Pid.. SELECT STATEMENT 0SORT GROUP BY 1TABLE ACCESS CERTIFICATE BY LOCAL INDEX R 2 1NESTED LOOPS 3 2NESTED LOOPS 4 3TABLE ACCESS PREMIUM_PLAN_COD FULL 5 4INDEX PK_CIPBF_IX FULL SCAN  6 4 INDEX XPKCERTIFICATE RANGE SCAN  7 3 The better plan (in a another trace file) which used the NO_INDEX hint, looked like this: Cost of plan: 58201Operation...........Object name.....Options.........Id...Pid.. SELECT STATEMENT 0   SORT GROUP BY 1       TABLE ACCESS CERTIFICATE BY LOCAL INDEX R 2 1            NESTED LOOPS 3 2                HASH JOIN 4 3   <== hash join instead of NLTABLE ACCESS PREMIUM_PLAN_COD FULL 5 4  <== full table scan instead of indexfull scan                   TABLE ACCESS CERT_INSURED_PLA FULL 6 4            INDEX XPKCERTIFICATE RANGE SCAN 7 3  3.找出连接顺序产生的最后成本 作为一个重要的使用成本（20762）找到连接以便评估这个成本。我们发现： Join result: cost: 20762  cdn: 1  rcz: 173 Best so far: TABLE#: 0  CST: 15810  CDN: 1     BYTES: 122Best so far: TABLE#: 2  CST: 20266  CDN: 1981  BYTES: 277340       Best so far: TABLE#: 1  CST: 20762  CDN: 1     BYTES: 173 这属于加入订单编号2......向上滚动到连接顺序节开始看到这个： Join order[2]: PREMIUM_PLAN_CODE [A13] CERT_INSURED_PLAN_BENEFIT_FACT [A11] CERTIFICATE [A12] 发现连接顺序选择的执行计划在9206和10g是比较容易，因为我们已经在10053跟踪： JOIN ORDER: 2CST: ... CDN: ... RSC: ... RSP: ... BYTES: ...  在这里，选择 "JOIN ORDER"的是2 4。找到的“好”计划和“坏”的计划之间的连接顺序，不同的部分。在这种情况下，它们之间的区别在成本在第二个表的连接顺序："Good" Plan: Join result: cost: 58201 cdn: 1 rcz: 173Best so far: TABLE#: 0 CST: 15810 CDN: 1 BYTES: 122Best so far: TABLE#: 2 CST: 57706 CDN: 1981 BYTES: 277340  Best so far: TABLE#: 1 CST: 58201 CDN: 1 BYTES: 173 "Bad Plan" Join result: cost: 20762 cdn: 1 rcz: 173Best so far: TABLE#: 0 CST: 15810 CDN: 1 BYTES: 122Best so far: TABLE#: 2 CST: 20266 CDN: 1981 BYTES: 277340   <== this cost is different (20266 vs 57706)Best so far: TABLE#: 1 CST: 20762 CDN: 1 BYTES: 173  5。搜寻连接内连接顺序部分生产步骤中确定的成本你会发现这条线，为您搜寻的成本为20266的文件： Join result: cost: 20266  cdn: 1981  rcz: 140 继续搜索，找到加入（最低）成本： Best NL cost: 20266  resp: 20266 我们知道从计划，它打算成为了NL连接，所以这证实了这一点。在NL搜索加入，导致这个成本的计算部分： NL Join Outer table: cost: 15810  cdn: 1  rcz: 122  resp:  15809 Inner table: CERT_INSURED_PLAN_BENEFIT_FACT...OPTIMIZER PERCENT INDEX CACHING = 70Access path: index (no sta/stp keys)Index: PK_CIPBF_IXTABLE: CERT_INSURED_PLAN_BENEFIT_FACTRSC_CPU: 116668803   RSC_IO: 17885              IX_SEL:  1.0000e+00  TB_SEL:  2.1281e-04Join:  resc: 81471  resp: 20266  在这一点上，我们看到最佳的成本发现“RESP”成本。这是“响应时间”成本，即成本的计划，使用PX的在最短的时间内获得答案。 “RESC”成本“资源成本”。这是连续查询执行的资源消耗成本。会显示是否PX的被使用或不完整的执行计划输出。 我们需要弄清楚如何计算成本。要做到这一点，我们需要看到CBO的费用如何联接。这里是与实际的替代值的基本计算公式：OT。 Basic NL join cost formula:  COST(outer) + [ CARD(outer) * COST(inner) ] 注意：下面的公式，“RESC（外）”，是指以资源成本的访问内部表。 “教育储蓄计划（外）”，是指响应外部表（PX）的成本。 resc = RESC(outer) + [CARD(outer) * RESC(inner)] = 63646 +       [    1       * (rsc_cpu / cpu_factor + rsc_io) * index_cost_adj ]= 63646 +       [    1       * ( 116668803 / 975563.49 + 17885) * 0.99 ]= 63646 + 17824.5 = 81470.5 ~ 81471:  OK Resp = RESP(outer) + (CARD(outer) * RESC(inner) )= 15809 + [1 * (rsc_cpu / cpu_factor + rsc_io)/(deg of join parallelism * parallel scaling factor) * index_cost_adj ] = 15809 + [1 * (116668803 / 975563.49 + 17885)/(4 * 0.9) * 0.99 ]= 15809 + 18004.59 / 3.6 * 0.99 = 20602.17 vs. 20266, close...but not exact...costing has fudge factors? 置换此连接使用外部表和内部表的并行奴隶的并行操作，但每个从站内表使用一个完整的索引访问路径。由于其NL连接，其可能使用的“广播”PX行分布，做到这一点。没有执行计划，其强硬知道这是在CBO选择了做什么。 (deg of join parallelism * parallel scaling factor)= 4 * 0.9 = 3.6 因此，除以4的成本，而不是它分为3.6成本。 外部表的全表扫描的并行度是在这里看到。联接的并行度设置任何特定的表并行的最高程度。在这种情况下，它被设置为的并行为PREMIUM_PLAN_CODE表的程度。一个完整的执行计划的输出将是非常有益验证这一点。 Other Costs in the NL Join for the table " CERT_INSURED_PLAN_BENEFIT_FACT" Using an FTS: NL JoinOuter table: cost: 15810 cdn: 1 rcz: 122 resp: 15809 (Note: serial tsc cost = 63646)Inner table: CERT_INSURED_PLAN_BENEFIT_FACT Access path: tsc Resc: 167233  (NOTE: parallel tsc cost = 41309)      Join: Resc: 230879 Resp: 57618 <== cost = 15809 + 41309 = 57118 Resc = Resc(outer) + [Card(outer) * Resc(inner) ] =  63646           + [1                 *     167233   ]   (Note:  Resc(Inner) is close to the value in single table access path, but not exact)= 230879 (exact) Resp = Resp(outer) + [Card(outer) * Resp(inner) ]= 15809             + [ 1                * 41309        ]= 57118 vs. 57618 (close, not exact)   Using an Index Fast Full Scan: NL JoinOuter table: cost: 15810 cdn: 1 rcz: 122 resp: 15809 (Note: serial tsc cost = 63646)Inner table: CERT_INSURED_PLAN_BENEFIT_FACT ...Access path: index (iff)Index: PK_CIPBF_IXTABLE: CERT_INSURED_PLAN_BENEFIT_FACT   RSC_CPU: 2865229980   RSC_IO: 52693 IX_SEL:  0.0000e+00  TB_SEL:  1.0000e+00Inner table: CERT_INSURED_PLAN_BENEFIT_FACT  Access path: iff  Resc: 55630   Join:  Resc:  119276  Resp:  29717 Resc = Resc(outer) + [ Card(outer) * Resc(Inner) ]=   63646      + [        1          * 55630         ]          =  119276 (exact)                Resp = Resp(outer) + [Card(outer) * Resp(inner) / (degree of join parallelism) ]= 15809         + [        1         *  27815 / 2      ]= 29716.5 = 29717 (exact)   Costs for other join types (SMJ and HJ): SM Join  Outer table:    resc: 63646  cdn: 1  rcz: 122  deg: 4  resp: 15809 Inner table: CERT_INSURED_PLAN_BENEFIT_FACT   resc: 55630  cdn: 22878070  rcz: 18  deg:  2  resp: 27815   using join:1 distribution:2 #groups:1   SORT resource      Sort statistics     Sort width:          598 Area size:     1048576 Max Area size:   104857600   Degree: 1     Blocks to Sort:        1 Row size:          145 Rows:          1     Initial runs:          1 Merge passes:        0 IO Cost / pass:          0     Total IO sort cost: 0     Total CPU sort cost: 975652     Total Temp space used: 0   SORT response      Sort statistics     Sort width:          598 Area size:    20971520 Max Area size:   104857600   Degree: 4     Blocks to Sort:        1 Row size:          145 Rows:          1     Initial runs:          1 Merge passes:        0 IO Cost / pass:          0     Total IO sort cost: 0     Total CPU sort cost: 1084058   SORT resource      Sort statistics     Sort width:          598 Area size:     1048576 Max Area size:   104857600   Degree: 1     Blocks to Sort:    84029 Row size:           30 Rows:   22878070     Initial runs:          7 Merge passes:        1 IO Cost / pass:     149862     Total IO sort cost: 233891     Total CPU sort cost: 27269777197     Total Temp space used: 1288102000   SORT response      Sort statistics     Sort width:          598 Area size:    20971520 Max Area size:   104857600   Degree: 2     Blocks to Sort:    42015 Row size:           30 Rows:   11439035     Initial runs:          4 Merge passes:        1 IO Cost / pass:      74932     Total IO sort cost: 129941     Total CPU sort cost: 14577786635 Merge join  Cost:  381119  Resp:  188508 Resc cost = Resc(outer) + Resc(inner) + Sort_Cost(outer) + Sort_Cost(inner= Resc(outer) + Resc(inner) + [ (CPU_Cost(outer) + IO_Cost(outer) ) + (CPU_Cost(inner) + IO_Cost(inner)  ]   =   63646      +     55630     + ( 975652 / 975563.49 +           0          ) + ( 27269777197 / 975563.49 + 233891) =  381120.8 ~ 381119 (very close)Resp cost =  Resp(outer) + Resp(inner) + Par_Sort_Cost(outer) + Par_Sort_Cost(inner) = Resp(outer)  + Resp(inner) + [ (Par_CPU_Cost(outer) + Par_IO_Cost(outer) )  + ( (Par_CPU_Cost(inner) + Par_CPU_Cost(inner)) ]= 15809         +    27815      + [ ( 1084058 / 975563.49  +    0       )       + ( 14577786635 / 975563.49 +     129941)               ] = 188509.1 ~ 188508 (very close) HA Join  Outer table:    resc: 63646 cdn: 1  rcz: 122  deg: 4  resp: 15809 Inner table: CERT_INSURED_PLAN_BENEFIT_FACT   resc: 55630 cdn: 22878070  rcz: 18  deg:  2  resp: 27815   using join:8 distribution:2 #groups:1 Hash join one ptn Resc: 587   Deg: 4     hash_area:  5120 (max=25600)  buildfrag:  1  probefrag:  20946 ppasses: 1     buildfrag: 1   probefrag: 20946   passes: 1 Hash join   Resc: 121625   Resp: 44212 Resc cost = Resc(outer)  + Resc(inner)  + HJ_Cost_Ser                  = 63646        +  55630        +  (HJ_Resc_Cost * HJ_Dop)= 63646        +  55630        +  (          587        *      4        )=  121624 ~ 121625 (very close) Resp cost  = Resp(outer) + Resp(inner) + HJ_Cost_Par=  15809      +    27815     +        587= 44211 ~ 44212 (very close) 注：SMJ和HA RESC和RESP的使用成本是从单个表的访问为每个表的成本部分。即 RESC（内层）是敌我识别RESC的成本和注册教育储蓄计划（内部）是敌我识别RESP成本。  结论 这里的最终结果是，与unhinted计划（“坏”），CBO的选择做了NL加入全索引扫描。由下面的几个方面所影响： 1.FTS的成本高（由于“多块读除数”非常低的值） 2.由于OPTIMIZER_INDEX_CACHING参数的索引访问的成本低。此参数有超越什么是合理的系统索引访问的成本显着降低的效果。 因为我们知道更好的计划执行全表扫描，并有更好的性能，我们可以看到“多块读除数”似乎是在这种情况下，不准确的。更准确的除数将FTS的/ IFF便宜得多的成本，并计划使用哈希联接将更具吸引力。一个更美好的不良的计划可能是一个嵌套的循环使用内部的行来源敌我识别（以哈希联接计划类似，但避免散列费用）的计划。敌我识别没有被选为在这种情况下，嵌套循环内的行来源，因为它的成本计算没有收到的OPTIMIZER_INDEX_CACHING因素的成本降低的好处（只适用于读单块读操作的索引）。此外，还提出了森林论坛的相对成本低的多块读除数。 这个服务请求调查的下一步骤包括： 找出为何多块读除数是如此之低（检查系统的统计，在aux_stats元） 再次进入了一个名为“stattab”现实的间隔期间收集系统统计比较在aux_stats现有值$ 找出客户为什么这么高集OPTIMIZER_INDEX_CACHING[/face][/face][/face]</P><P></P>