buptdream
1:在初期学习oracle的过程中，是往数据库某一方面（比如优化，恢复）专而精学习，还是横向进行广的学习，想听听您的意见？
[答]这是个仁者见仁、智者见智的问题，个人认为很难给出一个一成不变的套路。原因有很多，例如：
1、数据技术更新快，无论是软、硬件的发展还是新技术的产生，都会影响到数据库技术的变更；
2、各人在工作中的职责不同，侧重的知识点也不同；
3、各自所处的数据库环境不同，面临的问题也不同；
不过这里还是给出一些个人的看法，供初学者参考：
1、基础很重要。目前的关系型数据库系统，都是建立成熟的关系型数据库理论的基础上。上层的高级技术以及具体的软硬件实现方法发展很快，但是底层的理论依据却少有变化。在初学过程中，基础一定要打好，这是进一步理解具体数据库实现技术的必要前提。例如，在面临锁、并发控制等问题时，你需要对“事务”基本理论有较深刻的认识；在解读、调优SQL语句时，你需要能区分出各种访问方式和关联方法的区别；
2、养成良好的技术积累习惯。工作和学习过程中，你会发现知识量越来越大，以至于学到新知识就会忘了旧知识。一些好的技术积累手段能帮助你更好的保存学到的知识。例如，每次完成事故处理后，以笔记的形式再做总结；将平时日常积累的技术做一个分门别类的归纳，形成一个自己的知识库；
3、牢固掌握与日常工作相关的技术后，再做横向扩展。在实际工作中学到的技术印象是最深刻的，反过来，这些技术也是对你以后工作帮助最大的。数据库技术（以及其他关联的技术，如平台）之间都是存在相关性的。在掌握好与自己工作相关的技术后，再拓展学习其他相关技术，能起到以点带面的作用，反过来也能让你对以前学到技术有新的认识。
2：在计算索引成本的过程中，在谓词中包含多个列，而且有范围查询时。Effective Index Selectivity，Effective Table Selectivity这两个参数如何去计算？
[答]选择率的计算，受到多种因素的影响，例如是否绑定变量、是否使用柱状图数据、谓词表达式的逻辑组合关系。具体的计算方法在书中第5.3节有做详细介绍。
在书中，当谓词表达式为访问条件读取索引时，称之为索引访问选择率（Index Access Selectivity），即你所指的Effective Index Selectivity；当需要再有索引上的ROWID访问表数据，且谓词条件存在以索引字段作为过滤条件时，在访问选择率的基础上，再由过滤条件所造成对ROWID结果集的选择率则称为索引过滤选择率（Index Filter Selectivity），即Effective Table Selectivity。
3：在平时创建复合索引的时候，对于范围查询的列，为了减少索引成本，一般都放在索引定义的末尾。但有时候由于clustering_factor的影响，导致按照上述规则建立的索引反而不好，在建立复合索引时，对于列的顺序应该如何去考虑？
[答]索引的选取，是一个比较综合和的问题。你不能仅针对一条SQL考虑索引字段选择，需要考虑所有引用该表、高频率执行的语句；既要考虑查询性能的要求，又要考虑索引的维护成本，还要考虑磁盘空间开销等问题。一个原则就是，让索引上的字段访问选择率（ Access Selectivity）在尽可能多的语句上有效。要做到这一点，你需要了解到：什么条件能成为索引的访问条件；由这些访问条件所得到的选择效率如何。
对于第一条，你需要知道复合索引的构造：索引的数据结构为B*Tree；索引键值由多个字段“按序”构成。对索引进行查找时，从根节点开始，按照键值顺序查找。当索引的前列字段为等于匹配时，后续字段的匹配仍然能够从匹配到索引记录开始，按数序继续匹配。如果前列字段为非等于匹配时，在匹配到的记录中，满足后续字段条件的记录将可能是跳跃的、不连续的。
对于第二条，可以参考书中关于选择率计算的部分。
Clutering_factor的影响，是要乘以过滤选择率的。而范围选择率又是过滤选择率的构成因子。因此，越小的过滤选择率，越能提高查询效率。
4：在sql优化过程中，对于树形查询，有没有统一的优化方法？
[答]SQL优化要针对具体问题进行分析，通过高效率的访问数据方法，减少资源的浪费和消耗。但是很难给出一个统一的方法。
5：oracle计算并行成本的时候，如何去定义的？是并行成本除以并行度吗？并行扫描的时候，数据不需要使用缓存，直接进行读取快，那这些在成本中需要考虑吗？
[答]并行执行计划中的成本反映的是单个并行进程的成本，因此是由串行成本除以并行度。具体的计算方式，请参考书中第5.5节。
优化器计算的是逻辑读的成本。但我们在实际优化过程中，要考虑到，在进行大批量数据的访问时，直接读取可以减少对缓存的占用，避免降低整体的缓存命中率。关于直接读取的性能统计，可以参考6.3.1.3~6.3.1.7章节。
6：oracle在优化in方面，INLIST ITERATOR比采用or展开优化器有哪些优点？
[答]INLIST ITERATOR可以减少对索引枝节点的逻辑读次数
7：oracle统计信息需要准确，如果数据库非常大，DML操作也比较频繁，在这种情况下，收集统计信息对数据库会造成较大负担，那在统计信息准确性和数据库压力之间有没有一个好的办法？
[答]这确实是一个很实际的问题。DBA要做的是在准确性与其压力负载之间找到一个平衡点。对于庞大、数据变化频繁数据库，需要根据数据库各个对象的性能要求、数据量及变化、被使用情况等因素制定比较复杂的更新策略。并且这样的策略也不是一蹴而就的，需要经过一段时间的观察与调整，来获得一个稳定、均衡的更新维护计划。例如，将表按照数据量变化、使用频率和周期等情况，对表进行分组；在采用各自不同的统计数据更新参数、更新作业周期对不同组的表分别更新统计数据；对分区表、分区索引，考虑按照分区更新；更新周期要考虑对象的数据变化频率、可接受的陈旧数据比（最初可以设为30%）以及数据库的负载表化周期等因素共同决定。这里还要提到的一个统计数据更新参数就是“采样比”，在你了解对象的数据更新频率的基础上，设定相应的采样比，而不要采用自动模式，这会导致额外的开销。
8：针对oracle sql后面出现的advisor工具，作为DBA,应该如何对对待？是否可以直接采用？这种技术有什么不合理的地方？
[答]要善于利用工具，但不能过分依赖工具。Oracle提供了这些工具，目的就是帮助我们提高效率，使用它们并没有什么不妥。并且，这些工具不是单独存在的，而是结合了Oracle的内核组件（例如优化器引擎），作为Oracle系统的一个部分运行的。因此，它们拥有其他第三方工具无法比拟的优势。但是，在使用这些工具的同时，也要注意一些问题：它们在分析过程中，对资源消耗非常大，使用不当，会导致对系统整体性能产生负面影响；它们的优化判断标准是建立在一些内部参数的基础上的，这些参数有可能是一些经验值，它们也许适用于大部分情况，但不是所有情况。
这些工具的分析过程和建议标准也是值得我们借鉴的。参考它们的实现方法，能帮助我们在日常优化过程中达到快速优化目的。我在第七章介绍和分析了多种Oracle优化技术，描述了它们的实现过程和分析方法。第八章的快速优化思路则是参考了这些优化技术给出的优化方法。
9：现在数据库越来越智能化，DBA如何去适应未来的发展？是去学习hadoop，nosql等一些新兴的技术还是坚持oracle到底？
[答]新的技术意味着新的问题。数据库是服务与应用需求的，而应用需求的变化往往快于技术的发展。我想，这也是nosql这一类新型技术出现的原因。这类技术的出现，并非为了淘汰现有的成熟技术，而是弥补了现有技术的不足。DBA不要抗拒新技术，而是要放宽视野，接受和了解新技术。
个人认为，传统的大型关系数据库系统与这些新型技术的联系会越来越紧密，甚至会吸收和融合某些技术思想。
存在直方图的情况下，优化器如何去计算density的值？
[答]根据Histogram的类型不同，density计算方式不同。Frequency Histogram由记录数、采用比计算得到；High Balanced Histogram的Density计算过程则比较复杂，需要调整采用比，满足放缩条件后，使用相应的过程对数据进行放缩。具体计算过程在4.3.3.10节有做介绍。
面条s
面对一个大sql，有时候不知道从哪下手，请问优化如何开始？
[答]优化SQL，我们可以从两个方面着手：业务逻辑和数据库技术手段。因此，要优化SQL语句，首先需要从业务逻辑和执行计划两个方面理解SQL语句。
对业务逻辑的理解，是基于自己对业务的熟悉程度和与相关开发人员的交流的基础上的。你需要了解语句的业务目的，以及语句中涉及到的对象之间的相互关系。尝试在达到业务目的的前提下，改写逻辑实现方法甚至相关设计，避免不必要的额外操作，减少高消耗操作。举例来说，曾经看到一条复杂的SQL语句，关联了多个大表，返回一个结果集给应用程序，其目的就是为了判断在这些关联条件下是否能获得返回值。了解业务目的后，我们完全可以写一条更加有效率的语句达到同样的目的。对于大多数技术人员来说，都比较偏向于使用“技术”手段达到优化目的，往往忽略这一有效的优化方法。
对于执行计划的理解，由于执行计划本身就是一个树状结构，该树状结构最底层叶子节点上操作通常为访问数据的操作，枝节点上操作则为各种关联、过滤操作。因此，要理解执行计划，需要先从最底层开始读执行计划，由底向上观察各个操作的代价、数据数量，找到代价急剧增加、数据数量急剧（非聚集函数引起的）减少的节点，这样的操作往往是导致性能问题的瓶颈。此外，获得更多的额外信息，例如语句的实际运行统计数据、历史执行情况，也有助于我们分析和解决问题。
城管队长
现在 SQL turning advisor 和sqlt 都很强大的 SQL 优化工具。 感觉以后SQL 优化人工干预的机会越来越少了！随着oracle的发展 优化器也越来越强大，DBA 如何在SQL优化这一块体现自己的价值？
[答]确实，新技术和新工具的出现，对DBA的工作带来很大的变化，但这些变化不是消除DBA的作用，而是要求DBA了解和接受这些新工具和新技术，调整自己的工作方式和方法，适应新技术带来的变化。举个简单的例子，在RBO时代，DBA可能需要花费大量通过改写语句、增加提示的方式进行优化，而在CBO时代，则需要制定更加合理的统计数据更新策略，让优化器尽可能的获得最优的执行计划。工具的作用是否强大，不是在于工具本身，而是在于使用它的人。
jiubadaoxiahun
4.不知大师是否遇到过当问题超出自己能力的解决范围时，您是如何去面对的，怎么度过这一关
[答]这种情况相信任何人都会遇到过。
1、三人行，必有我师。虚心向相关专家请教；
2、善于查找资料。你遇到的问题很可能是别人已经遇到并解决了的问题。Google是我的浏览器的首页。
3、学会变通。对于当前无法直接解决的问题，要尝试从其它角度找到规避问题的方法，尽量使其影响降至最低。
例如，我们曾经发现Oracle的bug，Oracle的技术支持与开发部门尚在对问题进行定位分析。在获得进一步支持之前，我们通过修改应用程序，避免触发该Bug。
xgghxkhuang
应用是olap的，上游加载文件的，粒度到日和月，出日报和月报，已经在日的和月的粒度上对表进行了分区。表目前的执行计划都是全表扫描，索引没有办法用上。
数据只插入清除不会修改，整个主机和数据库是我们系统独自使用的，低并发，cpu和io配置不错，主机是e6900，这种情况下针对olap系统改如何调整？
大表的join很消耗时间，有没有办法预先连接，预先连接减少join的时间？
[答]从技术角度说，减少Join时间的方法有：
1、创建Bitmap Join Index，
2、创建Materialized View
3、采用并行查询
4、从设计上实现，增加冗余字段，消除Join，通过触发器或定时作业维护冗余字段
5、修改逻辑方法，例如月报是否可以从日报的基础上产生，而非直接读取原始数据表。
6、对于只读表，压缩和减少PCTFREE都可以起到减少IO的目的；
LuiseDalian
1. Oracle SQL优化和性能优化哪个从概念范畴上讲内容更多一些？
[答]这是难以量化的概念。优化主要是由SQL引擎中的优化器实现，而调优则通常是通过工具或人工干预改善SQL语句性能。要注意的是，这两项技术结合越来越紧密，要做到最佳的调优效果，必须要对两个方面都有一定的认识。
2. Oracle SQL优化应该从何入手学习，如果是从官方文档入手，建议从哪个文档开始（Oracle 11.2.0.x)
[答]Oracle Database Performance Tuning Guide是最佳的优化官方文档。里面对性能优化涉及的基本技术和概念都有很清晰的解释。
5. 对于实际生产环境的调优，是否像升级一样在执行之前需要制定调优计划？
[答]在生产环境设施任何操作都需要谨慎。不仅要经过充分测试，而且需要准备回滚计划。
6. 对于前台业务代码造成的性能问题，是否都存在相应的数据库端的调整方案，在实际项目中遇到过无法调整的问题吗？
[答]这个不能给一个绝对的答案。但是，目前Oracle的优化手段非常多，它可以让你在不修改代码的前提下改变语句的执行行为。不过要注意的是：在整个架构环境中，数据库是出在最底层的。底层的改变，造成的影响会向上层扩大。因此，从上层解决问题能最大程度减少对整个系统架构的影响。
lastwinner
一张表上有200个字段，其中100个字段会被用来做查询条件（条件由一个或多个字段组合而成），每个字段被作为查询条件的概率是很平均的。
而这100个字段中除了单一主键外还有49个字段，这49个字段中的每个字段都有至少3000个不同的值（分布不一定是均匀的）
该表记录数比较多，超过5亿。
已知该表的字段长度、非空约束都非常合理，目前只有一个主键上有索引，请问现在该表的其他索引该如何建，另外还需要做一些什么事情或者采取什么策略，才能保证所有在该表上的查询效果达到最佳？（所谓最佳，就是大约能达到80%以上的查询都能较快的查出结果就行）
[答]一个比较实际的做法是：在该表被使用的业务高峰时期，捕捉到相关语句（如创建AWR），再采用下列方法之一进行优化分析：
1、使用SQLTune Advisor和Access Advisor对SQL集进行分析，创建SQL集时，可以进行过滤，仅获得与该表相关的语句，或者再加上其他性能数据作为过滤条件（达到你的80%的要求），减少分析过程的资源消耗。建议导出SQL集到模拟环境中执行分析过程；
2、参考上述两个Advisor的分析过程（参考第七章），逐个分析SQL集中的SQL语句，找到和创建合适的索引。
htyansp
CBO老是走错索引，尤其在使用绑定变量的情况下，很容易导致后面的SQL慢的要命。这种问题在还有直方图和分区的情况下比较明显。貌似话说11G的ACS 稍微好点了。
大师能否谈谈你工作中CBO导致走错执行计划的一些案例，及其解决方案。
[答]通常来说，CBO下没有采用正确索引或者使用了性能低下的执行计划，大概有以下几种情况：
大多数案例都是由于统计数据不准确导致的。制定一个完备的统计数据更新策略，平衡统计数据维护代价与准确性要求，是保证优化器能正确获取最佳执行计划的最有效手段；
在字段数据分布不均匀时，绑定变量窥视特性也可能会导致性能突然下降。11g的ACS对该问题作了极大的改进，无法使用ACS情况，需要进行人为干预，例如使用提示、SQL Profiler等手段改变优化器行为；
部分案例是修改了优化器隐含参数，启用了当前版面默认为关闭的优化器特性。在生产环境中，避免修改隐含参数，除非是在Oracle技术支持的指引下修改；
还是极少数个案是由于优化器的BUG引起的；
liyc444
1 关于物理读、逻辑读、一致读对sql性能的有哪些重要影响；
[答]物理读的IO效率非常低，同时还会消耗更多的CPU资源。一致性读反应了Oracle进程对数据块的访问次数，既包括对物理数据块的访问、又包括对缓存数据块的访问，当存在一致性回滚时，还包含了的UNDO数据块的访问。在查询语句，一致性读反应了语句的逻辑读次数。在DML语句中，逻辑读还包含了当前模式读取的数据块次数。
2 我们得到一份sql的执行计划的时候，一般关注哪些点呢？如何去界定sql慢的原因？
[答]执行计划是优化器根据统计数据对语句预先估算出的执行方式，在统计数据正确的前提下，代价高的操作通常是语句的性能瓶颈；而cardinality急剧减少（非聚集操作导致）则该语句执行过程可能存在浪费资源的情况。此外，在8.2节当中，列出了各种可以从执行计划当中找到的定位性能问题的各种潜在因素。
4 优化了sql之后，一般通过什么条件来界定我们优化的sql基本不能再优化了，比如我们处理了一个sql，之前跑1个小时出结果，现在10分钟出结果，可是用户想10秒就出结果，这种情况我们如何界定已经不能再继续向下优化了？
[答]通过优化器的代价计算原则，我们不难知道，其优化的最终结果为获得语句所实现的逻辑结果的基础，选择到的IO和CPU消耗的执行方式。同样，我们对SQL语句调优时，也是以语句运行过程中产生最小的IO为目标。最理想的情况为，SQL语句仅仅通过缓存访问那些获得逻辑结果所必需的数据块，且每个数据块仅访问一次。然而这种理想状态通常很难实现。我们的优化目的就是无限的接近这个理想目标。此外，除了SQL语句本身的优化，在条件允许的情况下，还可以采用改变设计，如物化视图、分区，或并行化等方法减少语句的响应时间。
还要注意的是，优化并不局限于数据库技术本身。逻辑优化也是提升SQL性能的重要手段。
gyhgood
想钻研调优一直不得要领，到处收集资料看了之后感觉有些帮助但是还是提高不上去，想问问大师给指条学习路线从那些基础东西开始着手学习提高自己 ？目前接触不到需要调优的SQL自己怎么创造这样的环境来钻研练习？
[答]如果你是初学，建议你先从基础开始学习，了解Oracle的架构、了解数据库体系、掌握PLSQL的知识。Oracle的官方文档是非常不错的学习材料。它的首页给出了掌握当前Oracle基础知识的几个必要文档。
在网上有许多别人分享的优化案例。条件允许时，你可以搭建自己的环境来重现这些案例，对比起调优前后的效果，理解作者的调优思想。通过这种方式学习别人的经验，吸收为自己的知识。
lantian8766
2. 如果更新操作数据量很大，每次100万条左右，而且基本表数据量很大3亿条左右，是分区表，给一些优化建议；
[答]对于更新操作，你首先要知道它包含两部分：数据查询和数据修改。你需要知道哪个部分是性能瓶颈。简单的方法是：将查询部分从语句中分离，单独评估。如果是查询部分导致性能问题，可以参考前面的回答中介绍的一些方法进行优化。而如果是数据修改导致的性能问题，则可能存在多种潜在原因，例如：其他事务的锁导致等待；索引的维护；外键约束等。通常，更新操作可能会产生递归语句的调用。所以，你可以做一个10046的事件跟踪深入的分析性能瓶颈在何处。找到原因后，再采取相应措施进一步优化，例如删除重复索引或重新组织索引以减少索引数量，保证查询性能的前提下减少复合索引中字段的数量，在相应的外键上创建索引等。
3. 性能监控方面，一般的方法可以分享下；
[答]Oracle自身提供的性能监控功能，如AWR、OEM/Grid Control预警设置、动态视图等，已经相当完备。设置和利用这些工具，基本上可以满足我们日常对系统的性能监控需求。监控报告的周期、预警设置的临界值，则与系统的负载变化周期、系统资源负荷承受程度相关。
4. 大数据量的排序，如何减少I/O操作；
[答]在PGA自动管理模式，工作区（包括排序和HASH）的利用得到极大的提升，它能最大化利用当前的可用内存区。因此，排序操作是否发生磁盘IO操作，由排序数据大小、当前并发的其它利用工作区的操作的规模以及PGA的大小决定。
通常的一些优化措施包括：创建索引，使无序数据变为有序数据；减少Order by、select字句中不必要的字段，降低排序数据大小；优化执行计划中的其他操作，减少排序记录数。
452098219
想问问书中有没有详细介绍CBO对于索引扫描与表扫描的代价计算?是否有公式？
[答]书中第五章介绍了优化器计算各种主要的执行计划操作的公式，包括索引扫描和表扫描。
tianya_2011
一个大表，表的某个字段明明有索引，但执行计划却不走索引，以前一直是正常的。
我做了以下工作，1，analyze收集了表和索引统计信息。
2，查询的数据量不是太大，不应该走全表扫描
3，查询optimizer_mode=ALL_ROWS
4，考虑对表进行分区
请问还可以从哪些方面进行考虑？
[答]你可以从以下几个方面考虑：
1、使用DBMS_STATS包而非Analyze方式收集统计信息；
2、分析执行计划，找到使数据在被扫描过程中过滤的谓词条件中的Filter条件，确认这些条件是否能成为索引的访问条件；
3、使用提示或者其它方法使语句强制使用索引，再和当前的执行计划的实际运行性能对比，运行性能统计数据是否存在较大差别。如果是，通过10053事件跟踪，分析未能获取正确执行计划的原因
1，在日常维护中，通过AWR，ADDM和等待事件找出可能有问题的SQL，怎么分析sql是否需要优化,以及优化到什么程度？
[答]参考前面的回答
2, oracle的官方文档和MOS是学习oracle很好的两个工具，我现在遇到问题一般是去google，baidu,MOS查找类似问题的解决办法，感觉自己处理问题不太规范，怎么才能把官方文档和MOS很好结合起来学习和解决问题。
[答]官方文档对基本概念、架构体系等基础知识描述得非常详细，稳固的掌握这些基础知识可以帮助你的分析问题时找对问题的方向。MOS上的案例通常是比较规范的。它一般会给出重现条件、规避方法、解决办法以及参考指引，而Oracle技术支持与用户之间的交互过程则是问题的分析过程。你在分析和解决问题时，通过MOS和Google找到相关的案例和解决方法，要重点学习别人对问题的分析过程，涉及到无法理解的知识点时，通过官方文档或者其他资料去了解这些知识点。要做到当你自己再次遇到类似问题时，也能通过自己对问题进行分析和定位，找到解决方法，而不再依赖别人的解决方法。
3，一个几十行的SQL，设计到多个表的连接，执行计划也有很多层，阅读起来非常困难，怎么能快速从这么多行的执行计划中检索出需要优化的表以及对表的执行有问题的Operation 。
[答]参考前面回答。重点分析操作代价、记录数以及谓词条件。
4，在一个分区表中有些分区所在的表空间被OFFLINE，在统计信息收集的过程中报错，这种问题怎么解决，分区表相对于普通表维护起来还是有一定的困难，请问有没有这方面的经验可以分享。
[答]对于分区表，通常每个分区的数据活跃程度不同，因此建议按照分区收集统计数据；
wumming
我有一个问题想请教一下，关于ORACLE绑定变量窥视以及cursor_sharing参数的。
1、如果使用隐含参数_optim_peek_user_binds关闭了绑定变量窥视，那优化器是如何计算一条带有绑定变量的语句的成本并制定执行计划的？估算吗？如果是根据什么估算?
[答]主要影响的是选择率的计算，由唯一值数、密度等统计数据计算得出，同时还与谓词表达式中的逻辑操作符有关。5.3.2节中给出了各种逻辑操作符所对应的计算方法。
2、按理说，cursor_sharing参数设置为SIMILAR，如果数据倾斜的字段上收集了直方图的话，优化器应该能够根据不同的绑定变量值给出不同的执行计划，但我测试的结果依然是按照窥视后的结果，从而使执行计划依然可能会出问题，不知这是为何？
（注：我在10G和11G下测试的，11G的自适应游标共享也没有起到作用，绑定变量窥视依然困扰）
[答]你的语句中是否直接捆绑了数据还是使用了变量。你可以查询library cache，确认该语句被解析了几个子游标，它们的执行计划是否相同，它们窥视到的数据是否为绑定数据。要注意的是，使用SIMILAR会带来一些问题，例如子游标过多。在Oracle的后续版本中将会废除该游标共享方式。
meridian-line
我在测试你博客中提供Fy_Recover_Data，文件系统中恢复正常。尝试恢复ASM和裸设备中被truncate的表，请问相关路径应该如何设置？
[答]该过程使用UTL_FILE读写数据文件，但是这个包不支持对ASM和裸设备的读写。
cmj100424
SQL优化的思路、方向？
[答]请参考前面回答。
1:在初期学习oracle的过程中，是往数据库某一方面（比如优化，恢复）专而精学习，还是横向进行广的学习，想听听您的意见？
[答]这是个仁者见仁、智者见智的问题，个人认为很难给出一个一成不变的套路。原因有很多，例如：
1、数据技术更新快，无论是软、硬件的发展还是新技术的产生，都会影响到数据库技术的变更；
2、各人在工作中的职责不同，侧重的知识点也不同；
3、各自所处的数据库环境不同，面临的问题也不同；
不过这里还是给出一些个人的看法，供初学者参考：
1、基础很重要。目前的关系型数据库系统，都是建立成熟的关系型数据库理论的基础上。上层的高级技术以及具体的软硬件实现方法发展很快，但是底层的理论依据却少有变化。在初学过程中，基础一定要打好，这是进一步理解具体数据库实现技术的必要前提。例如，在面临锁、并发控制等问题时，你需要对“事务”基本理论有较深刻的认识；在解读、调优SQL语句时，你需要能区分出各种访问方式和关联方法的区别；
2、养成良好的技术积累习惯。工作和学习过程中，你会发现知识量越来越大，以至于学到新知识就会忘了旧知识。一些好的技术积累手段能帮助你更好的保存学到的知识。例如，每次完成事故处理后，以笔记的形式再做总结；将平时日常积累的技术做一个分门别类的归纳，形成一个自己的知识库；
3、牢固掌握与日常工作相关的技术后，再做横向扩展。在实际工作中学到的技术印象是最深刻的，反过来，这些技术也是对你以后工作帮助最大的。数据库技术（以及其他关联的技术，如平台）之间都是存在相关性的。在掌握好与自己工作相关的技术后，再拓展学习其他相关技术，能起到以点带面的作用，反过来也能让你对以前学到技术有新的认识。
2：在计算索引成本的过程中，在谓词中包含多个列，而且有范围查询时。Effective Index Selectivity，Effective Table Selectivity这两个参数如何去计算？
[答]选择率的计算，受到多种因素的影响，例如是否绑定变量、是否使用柱状图数据、谓词表达式的逻辑组合关系。具体的计算方法在书中第5.3节有做详细介绍。
在书中，当谓词表达式为访问条件读取索引时，称之为索引访问选择率（Index Access Selectivity），即你所指的Effective Index Selectivity；当需要再有索引上的ROWID访问表数据，且谓词条件存在以索引字段作为过滤条件时，在访问选择率的基础上，再由过滤条件所造成对ROWID结果集的选择率则称为索引过滤选择率（Index Filter Selectivity），即Effective Table Selectivity。
3：在平时创建复合索引的时候，对于范围查询的列，为了减少索引成本，一般都放在索引定义的末尾。但有时候由于clustering_factor的影响，导致按照上述规则建立的索引反而不好，在建立复合索引时，对于列的顺序应该如何去考虑？
[答]索引的选取，是一个比较综合和的问题。你不能仅针对一条SQL考虑索引字段选择，需要考虑所有引用该表、高频率执行的语句；既要考虑查询性能的要求，又要考虑索引的维护成本，还要考虑磁盘空间开销等问题。一个原则就是，让索引上的字段访问选择率（ Access Selectivity）在尽可能多的语句上有效。要做到这一点，你需要了解到：什么条件能成为索引的访问条件；由这些访问条件所得到的选择效率如何。
对于第一条，你需要知道复合索引的构造：索引的数据结构为B*Tree；索引键值由多个字段“按序”构成。对索引进行查找时，从根节点开始，按照键值顺序查找。当索引的前列字段为等于匹配时，后续字段的匹配仍然能够从匹配到索引记录开始，按数序继续匹配。如果前列字段为非等于匹配时，在匹配到的记录中，满足后续字段条件的记录将可能是跳跃的、不连续的。
对于第二条，可以参考书中关于选择率计算的部分。
Clutering_factor的影响，是要乘以过滤选择率的。而范围选择率又是过滤选择率的构成因子。因此，越小的过滤选择率，越能提高查询效率。
4：在sql优化过程中，对于树形查询，有没有统一的优化方法？
[答]SQL优化要针对具体问题进行分析，通过高效率的访问数据方法，减少资源的浪费和消耗。但是很难给出一个统一的方法。
5：oracle计算并行成本的时候，如何去定义的？是并行成本除以并行度吗？并行扫描的时候，数据不需要使用缓存，直接进行读取快，那这些在成本中需要考虑吗？
[答]并行执行计划中的成本反映的是单个并行进程的成本，因此是由串行成本除以并行度。具体的计算方式，请参考书中第5.5节。
优化器计算的是逻辑读的成本。但我们在实际优化过程中，要考虑到，在进行大批量数据的访问时，直接读取可以减少对缓存的占用，避免降低整体的缓存命中率。关于直接读取的性能统计，可以参考6.3.1.3~6.3.1.7章节。
6：oracle在优化in方面，INLIST ITERATOR比采用or展开优化器有哪些优点？
[答]INLIST ITERATOR可以减少对索引枝节点的逻辑读次数
7：oracle统计信息需要准确，如果数据库非常大，DML操作也比较频繁，在这种情况下，收集统计信息对数据库会造成较大负担，那在统计信息准确性和数据库压力之间有没有一个好的办法？
[答]这确实是一个很实际的问题。DBA要做的是在准确性与其压力负载之间找到一个平衡点。对于庞大、数据变化频繁数据库，需要根据数据库各个对象的性能要求、数据量及变化、被使用情况等因素制定比较复杂的更新策略。并且这样的策略也不是一蹴而就的，需要经过一段时间的观察与调整，来获得一个稳定、均衡的更新维护计划。例如，将表按照数据量变化、使用频率和周期等情况，对表进行分组；在采用各自不同的统计数据更新参数、更新作业周期对不同组的表分别更新统计数据；对分区表、分区索引，考虑按照分区更新；更新周期要考虑对象的数据变化频率、可接受的陈旧数据比（最初可以设为30%）以及数据库的负载表化周期等因素共同决定。这里还要提到的一个统计数据更新参数就是“采样比”，在你了解对象的数据更新频率的基础上，设定相应的采样比，而不要采用自动模式，这会导致额外的开销。
8：针对oracle sql后面出现的advisor工具，作为DBA,应该如何对对待？是否可以直接采用？这种技术有什么不合理的地方？
[答]要善于利用工具，但不能过分依赖工具。Oracle提供了这些工具，目的就是帮助我们提高效率，使用它们并没有什么不妥。并且，这些工具不是单独存在的，而是结合了Oracle的内核组件（例如优化器引擎），作为Oracle系统的一个部分运行的。因此，它们拥有其他第三方工具无法比拟的优势。但是，在使用这些工具的同时，也要注意一些问题：它们在分析过程中，对资源消耗非常大，使用不当，会导致对系统整体性能产生负面影响；它们的优化判断标准是建立在一些内部参数的基础上的，这些参数有可能是一些经验值，它们也许适用于大部分情况，但不是所有情况。
这些工具的分析过程和建议标准也是值得我们借鉴的。参考它们的实现方法，能帮助我们在日常优化过程中达到快速优化目的。我在第七章介绍和分析了多种Oracle优化技术，描述了它们的实现过程和分析方法。第八章的快速优化思路则是参考了这些优化技术给出的优化方法。
9：现在数据库越来越智能化，DBA如何去适应未来的发展？是去学习hadoop，nosql等一些新兴的技术还是坚持oracle到底？
[答]新的技术意味着新的问题。数据库是服务与应用需求的，而应用需求的变化往往快于技术的发展。我想，这也是nosql这一类新型技术出现的原因。这类技术的出现，并非为了淘汰现有的成熟技术，而是弥补了现有技术的不足。DBA不要抗拒新技术，而是要放宽视野，接受和了解新技术。
个人认为，传统的大型关系数据库系统与这些新型技术的联系会越来越紧密，甚至会吸收和融合某些技术思想。
存在直方图的情况下，优化器如何去计算density的值？
[答]根据Histogram的类型不同，density计算方式不同。Frequency Histogram由记录数、采用比计算得到；High Balanced Histogram的Density计算过程则比较复杂，需要调整采用比，满足放缩条件后，使用相应的过程对数据进行放缩。具体计算过程在4.3.3.10节有做介绍。
面条s
面对一个大sql，有时候不知道从哪下手，请问优化如何开始？
[答]优化SQL，我们可以从两个方面着手：业务逻辑和数据库技术手段。因此，要优化SQL语句，首先需要从业务逻辑和执行计划两个方面理解SQL语句。
对业务逻辑的理解，是基于自己对业务的熟悉程度和与相关开发人员的交流的基础上的。你需要了解语句的业务目的，以及语句中涉及到的对象之间的相互关系。尝试在达到业务目的的前提下，改写逻辑实现方法甚至相关设计，避免不必要的额外操作，减少高消耗操作。举例来说，曾经看到一条复杂的SQL语句，关联了多个大表，返回一个结果集给应用程序，其目的就是为了判断在这些关联条件下是否能获得返回值。了解业务目的后，我们完全可以写一条更加有效率的语句达到同样的目的。对于大多数技术人员来说，都比较偏向于使用“技术”手段达到优化目的，往往忽略这一有效的优化方法。
对于执行计划的理解，由于执行计划本身就是一个树状结构，该树状结构最底层叶子节点上操作通常为访问数据的操作，枝节点上操作则为各种关联、过滤操作。因此，要理解执行计划，需要先从最底层开始读执行计划，由底向上观察各个操作的代价、数据数量，找到代价急剧增加、数据数量急剧（非聚集函数引起的）减少的节点，这样的操作往往是导致性能问题的瓶颈。此外，获得更多的额外信息，例如语句的实际运行统计数据、历史执行情况，也有助于我们分析和解决问题。
城管队长
现在 SQL turning advisor 和sqlt 都很强大的 SQL 优化工具。 感觉以后SQL 优化人工干预的机会越来越少了！随着oracle的发展 优化器也越来越强大，DBA 如何在SQL优化这一块体现自己的价值？
[答]确实，新技术和新工具的出现，对DBA的工作带来很大的变化，但这些变化不是消除DBA的作用，而是要求DBA了解和接受这些新工具和新技术，调整自己的工作方式和方法，适应新技术带来的变化。举个简单的例子，在RBO时代，DBA可能需要花费大量通过改写语句、增加提示的方式进行优化，而在CBO时代，则需要制定更加合理的统计数据更新策略，让优化器尽可能的获得最优的执行计划。工具的作用是否强大，不是在于工具本身，而是在于使用它的人。
jiubadaoxiahun
4.不知大师是否遇到过当问题超出自己能力的解决范围时，您是如何去面对的，怎么度过这一关
[答]这种情况相信任何人都会遇到过。
1、三人行，必有我师。虚心向相关专家请教；
2、善于查找资料。你遇到的问题很可能是别人已经遇到并解决了的问题。Google是我的浏览器的首页。
3、学会变通。对于当前无法直接解决的问题，要尝试从其它角度找到规避问题的方法，尽量使其影响降至最低。
例如，我们曾经发现Oracle的bug，Oracle的技术支持与开发部门尚在对问题进行定位分析。在获得进一步支持之前，我们通过修改应用程序，避免触发该Bug。
xgghxkhuang
应用是olap的，上游加载文件的，粒度到日和月，出日报和月报，已经在日的和月的粒度上对表进行了分区。表目前的执行计划都是全表扫描，索引没有办法用上。
数据只插入清除不会修改，整个主机和数据库是我们系统独自使用的，低并发，cpu和io配置不错，主机是e6900，这种情况下针对olap系统改如何调整？
大表的join很消耗时间，有没有办法预先连接，预先连接减少join的时间？
[答]从技术角度说，减少Join时间的方法有：
1、创建Bitmap Join Index，
2、创建Materialized View
3、采用并行查询
4、从设计上实现，增加冗余字段，消除Join，通过触发器或定时作业维护冗余字段
5、修改逻辑方法，例如月报是否可以从日报的基础上产生，而非直接读取原始数据表。
6、对于只读表，压缩和减少PCTFREE都可以起到减少IO的目的；
LuiseDalian
1. Oracle SQL优化和性能优化哪个从概念范畴上讲内容更多一些？
[答]这是难以量化的概念。优化主要是由SQL引擎中的优化器实现，而调优则通常是通过工具或人工干预改善SQL语句性能。要注意的是，这两项技术结合越来越紧密，要做到最佳的调优效果，必须要对两个方面都有一定的认识。
2. Oracle SQL优化应该从何入手学习，如果是从官方文档入手，建议从哪个文档开始（Oracle 11.2.0.x)
[答]Oracle Database Performance Tuning Guide是最佳的优化官方文档。里面对性能优化涉及的基本技术和概念都有很清晰的解释。
5. 对于实际生产环境的调优，是否像升级一样在执行之前需要制定调优计划？
[答]在生产环境设施任何操作都需要谨慎。不仅要经过充分测试，而且需要准备回滚计划。
6. 对于前台业务代码造成的性能问题，是否都存在相应的数据库端的调整方案，在实际项目中遇到过无法调整的问题吗？
[答]这个不能给一个绝对的答案。但是，目前Oracle的优化手段非常多，它可以让你在不修改代码的前提下改变语句的执行行为。不过要注意的是：在整个架构环境中，数据库是出在最底层的。底层的改变，造成的影响会向上层扩大。因此，从上层解决问题能最大程度减少对整个系统架构的影响。
lastwinner
一张表上有200个字段，其中100个字段会被用来做查询条件（条件由一个或多个字段组合而成），每个字段被作为查询条件的概率是很平均的。
而这100个字段中除了单一主键外还有49个字段，这49个字段中的每个字段都有至少3000个不同的值（分布不一定是均匀的）
该表记录数比较多，超过5亿。
已知该表的字段长度、非空约束都非常合理，目前只有一个主键上有索引，请问现在该表的其他索引该如何建，另外还需要做一些什么事情或者采取什么策略，才能保证所有在该表上的查询效果达到最佳？（所谓最佳，就是大约能达到80%以上的查询都能较快的查出结果就行）
[答]一个比较实际的做法是：在该表被使用的业务高峰时期，捕捉到相关语句（如创建AWR），再采用下列方法之一进行优化分析：
1、使用SQLTune Advisor和Access Advisor对SQL集进行分析，创建SQL集时，可以进行过滤，仅获得与该表相关的语句，或者再加上其他性能数据作为过滤条件（达到你的80%的要求），减少分析过程的资源消耗。建议导出SQL集到模拟环境中执行分析过程；
2、参考上述两个Advisor的分析过程（参考第七章），逐个分析SQL集中的SQL语句，找到和创建合适的索引。
htyansp
CBO老是走错索引，尤其在使用绑定变量的情况下，很容易导致后面的SQL慢的要命。这种问题在还有直方图和分区的情况下比较明显。貌似话说11G的ACS 稍微好点了。
大师能否谈谈你工作中CBO导致走错执行计划的一些案例，及其解决方案。
[答]通常来说，CBO下没有采用正确索引或者使用了性能低下的执行计划，大概有以下几种情况：
大多数案例都是由于统计数据不准确导致的。制定一个完备的统计数据更新策略，平衡统计数据维护代价与准确性要求，是保证优化器能正确获取最佳执行计划的最有效手段；
在字段数据分布不均匀时，绑定变量窥视特性也可能会导致性能突然下降。11g的ACS对该问题作了极大的改进，无法使用ACS情况，需要进行人为干预，例如使用提示、SQL Profiler等手段改变优化器行为；
部分案例是修改了优化器隐含参数，启用了当前版面默认为关闭的优化器特性。在生产环境中，避免修改隐含参数，除非是在Oracle技术支持的指引下修改；
还是极少数个案是由于优化器的BUG引起的；
liyc444
1 关于物理读、逻辑读、一致读对sql性能的有哪些重要影响；
[答]物理读的IO效率非常低，同时还会消耗更多的CPU资源。一致性读反应了Oracle进程对数据块的访问次数，既包括对物理数据块的访问、又包括对缓存数据块的访问，当存在一致性回滚时，还包含了的UNDO数据块的访问。在查询语句，一致性读反应了语句的逻辑读次数。在DML语句中，逻辑读还包含了当前模式读取的数据块次数。
2 我们得到一份sql的执行计划的时候，一般关注哪些点呢？如何去界定sql慢的原因？
[答]执行计划是优化器根据统计数据对语句预先估算出的执行方式，在统计数据正确的前提下，代价高的操作通常是语句的性能瓶颈；而cardinality急剧减少（非聚集操作导致）则该语句执行过程可能存在浪费资源的情况。此外，在8.2节当中，列出了各种可以从执行计划当中找到的定位性能问题的各种潜在因素。
4 优化了sql之后，一般通过什么条件来界定我们优化的sql基本不能再优化了，比如我们处理了一个sql，之前跑1个小时出结果，现在10分钟出结果，可是用户想10秒就出结果，这种情况我们如何界定已经不能再继续向下优化了？
[答]通过优化器的代价计算原则，我们不难知道，其优化的最终结果为获得语句所实现的逻辑结果的基础，选择到的IO和CPU消耗的执行方式。同样，我们对SQL语句调优时，也是以语句运行过程中产生最小的IO为目标。最理想的情况为，SQL语句仅仅通过缓存访问那些获得逻辑结果所必需的数据块，且每个数据块仅访问一次。然而这种理想状态通常很难实现。我们的优化目的就是无限的接近这个理想目标。此外，除了SQL语句本身的优化，在条件允许的情况下，还可以采用改变设计，如物化视图、分区，或并行化等方法减少语句的响应时间。
还要注意的是，优化并不局限于数据库技术本身。逻辑优化也是提升SQL性能的重要手段。
gyhgood
想钻研调优一直不得要领，到处收集资料看了之后感觉有些帮助但是还是提高不上去，想问问大师给指条学习路线从那些基础东西开始着手学习提高自己 ？目前接触不到需要调优的SQL自己怎么创造这样的环境来钻研练习？
[答]如果你是初学，建议你先从基础开始学习，了解Oracle的架构、了解数据库体系、掌握PLSQL的知识。Oracle的官方文档是非常不错的学习材料。它的首页给出了掌握当前Oracle基础知识的几个必要文档。
在网上有许多别人分享的优化案例。条件允许时，你可以搭建自己的环境来重现这些案例，对比起调优前后的效果，理解作者的调优思想。通过这种方式学习别人的经验，吸收为自己的知识。
lantian8766
2. 如果更新操作数据量很大，每次100万条左右，而且基本表数据量很大3亿条左右，是分区表，给一些优化建议；
[答]对于更新操作，你首先要知道它包含两部分：数据查询和数据修改。你需要知道哪个部分是性能瓶颈。简单的方法是：将查询部分从语句中分离，单独评估。如果是查询部分导致性能问题，可以参考前面的回答中介绍的一些方法进行优化。而如果是数据修改导致的性能问题，则可能存在多种潜在原因，例如：其他事务的锁导致等待；索引的维护；外键约束等。通常，更新操作可能会产生递归语句的调用。所以，你可以做一个10046的事件跟踪深入的分析性能瓶颈在何处。找到原因后，再采取相应措施进一步优化，例如删除重复索引或重新组织索引以减少索引数量，保证查询性能的前提下减少复合索引中字段的数量，在相应的外键上创建索引等。
3. 性能监控方面，一般的方法可以分享下；
[答]Oracle自身提供的性能监控功能，如AWR、OEM/Grid Control预警设置、动态视图等，已经相当完备。设置和利用这些工具，基本上可以满足我们日常对系统的性能监控需求。监控报告的周期、预警设置的临界值，则与系统的负载变化周期、系统资源负荷承受程度相关。
4. 大数据量的排序，如何减少I/O操作；
[答]在PGA自动管理模式，工作区（包括排序和HASH）的利用得到极大的提升，它能最大化利用当前的可用内存区。因此，排序操作是否发生磁盘IO操作，由排序数据大小、当前并发的其它利用工作区的操作的规模以及PGA的大小决定。
通常的一些优化措施包括：创建索引，使无序数据变为有序数据；减少Order by、select字句中不必要的字段，降低排序数据大小；优化执行计划中的其他操作，减少排序记录数。
452098219
想问问书中有没有详细介绍CBO对于索引扫描与表扫描的代价计算?是否有公式？
[答]书中第五章介绍了优化器计算各种主要的执行计划操作的公式，包括索引扫描和表扫描。
tianya_2011
一个大表，表的某个字段明明有索引，但执行计划却不走索引，以前一直是正常的。
我做了以下工作，1，analyze收集了表和索引统计信息。
2，查询的数据量不是太大，不应该走全表扫描
3，查询optimizer_mode=ALL_ROWS
4，考虑对表进行分区
请问还可以从哪些方面进行考虑？
[答]你可以从以下几个方面考虑：
1、使用DBMS_STATS包而非Analyze方式收集统计信息；
2、分析执行计划，找到使数据在被扫描过程中过滤的谓词条件中的Filter条件，确认这些条件是否能成为索引的访问条件；
3、使用提示或者其它方法使语句强制使用索引，再和当前的执行计划的实际运行性能对比，运行性能统计数据是否存在较大差别。如果是，通过10053事件跟踪，分析未能获取正确执行计划的原因
1，在日常维护中，通过AWR，ADDM和等待事件找出可能有问题的SQL，怎么分析sql是否需要优化,以及优化到什么程度？
[答]参考前面的回答
2, oracle的官方文档和MOS是学习oracle很好的两个工具，我现在遇到问题一般是去google，baidu,MOS查找类似问题的解决办法，感觉自己处理问题不太规范，怎么才能把官方文档和MOS很好结合起来学习和解决问题。
[答]官方文档对基本概念、架构体系等基础知识描述得非常详细，稳固的掌握这些基础知识可以帮助你的分析问题时找对问题的方向。MOS上的案例通常是比较规范的。它一般会给出重现条件、规避方法、解决办法以及参考指引，而Oracle技术支持与用户之间的交互过程则是问题的分析过程。你在分析和解决问题时，通过MOS和Google找到相关的案例和解决方法，要重点学习别人对问题的分析过程，涉及到无法理解的知识点时，通过官方文档或者其他资料去了解这些知识点。要做到当你自己再次遇到类似问题时，也能通过自己对问题进行分析和定位，找到解决方法，而不再依赖别人的解决方法。
3，一个几十行的SQL，设计到多个表的连接，执行计划也有很多层，阅读起来非常困难，怎么能快速从这么多行的执行计划中检索出需要优化的表以及对表的执行有问题的Operation 。
[答]参考前面回答。重点分析操作代价、记录数以及谓词条件。
4，在一个分区表中有些分区所在的表空间被OFFLINE，在统计信息收集的过程中报错，这种问题怎么解决，分区表相对于普通表维护起来还是有一定的困难，请问有没有这方面的经验可以分享。
[答]对于分区表，通常每个分区的数据活跃程度不同，因此建议按照分区收集统计数据；
wumming
我有一个问题想请教一下，关于ORACLE绑定变量窥视以及cursor_sharing参数的。
1、如果使用隐含参数_optim_peek_user_binds关闭了绑定变量窥视，那优化器是如何计算一条带有绑定变量的语句的成本并制定执行计划的？估算吗？如果是根据什么估算?
[答]主要影响的是选择率的计算，由唯一值数、密度等统计数据计算得出，同时还与谓词表达式中的逻辑操作符有关。5.3.2节中给出了各种逻辑操作符所对应的计算方法。
2、按理说，cursor_sharing参数设置为SIMILAR，如果数据倾斜的字段上收集了直方图的话，优化器应该能够根据不同的绑定变量值给出不同的执行计划，但我测试的结果依然是按照窥视后的结果，从而使执行计划依然可能会出问题，不知这是为何？
（注：我在10G和11G下测试的，11G的自适应游标共享也没有起到作用，绑定变量窥视依然困扰）
[答]你的语句中是否直接捆绑了数据还是使用了变量。你可以查询library cache，确认该语句被解析了几个子游标，它们的执行计划是否相同，它们窥视到的数据是否为绑定数据。要注意的是，使用SIMILAR会带来一些问题，例如子游标过多。在Oracle的后续版本中将会废除该游标共享方式。
meridian-line
我在测试你博客中提供Fy_Recover_Data，文件系统中恢复正常。尝试恢复ASM和裸设备中被truncate的表，请问相关路径应该如何设置？
[答]该过程使用UTL_FILE读写数据文件，但是这个包不支持对ASM和裸设备的读写。
cmj100424
SQL优化的思路、方向？
[答]请参考前面回答。
297
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
