老徐的博客只有干货

如果要分析某条SQL的性能问题，通常我们要先看SQL的执行计划，看看SQL的每一步执行是否存在问题。 如果一条SQL平时执行的好好的，却有一天突然性能很差，如果排除了系统资源和阻塞的原因，那么基本可以断定是执行计划出了问题。准备工作：首先必须采用用Oracle的sqlplus登陆sys账号sqlplus " sys/sys@XXX as sysdba "然后执行如下脚本：

一. SQL_TRACE当SQL语句出现性能问题时，我们可以用SQL_TRACE来跟踪SQL的执行情况，通过跟踪，我们可以了解一条SQL或者PL/SQL包的运行情况，SQL_TRACE命令会将SQL执行的整个过程输出到一个trace文件中，我们可以读这个trace 文件来了解在这个SQL执行过程中Oracle 都做了哪些操作。 可以通过sql命令启动SQL_TRACE，或者在初始化参数

以下内容转自网络：-------------------------------------说到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：1、语法检查(syntax check)  检查此sql的

我们知道，在Oracle中存在许多参数能够影响SQL的查询计划，如hash_join_enabled、optimizer_index_cost_adj、_optim_peek_user_binds。正确调整这些参数能够解决不少SQL所引起的性能问题。但是，在调整这些参数时需要注意一点，他们是对整个实例其作用的。他们的影响范围如此之大，以至于我们可能通过调整这些参数解决某一条SQL的问题，但是参数的

查询优化手段和gather_plan_statistics hint：在10g以后我们可以通过利用gather_plan_statistics提示来了解更多的SQL执行统计信息，具体使用方法如下：如果在statistics_level参数设置为ALL，或者执行的sql使用了gather_plan_statistics hint，则在sql执行后，会在v$sql_plan_statistic

原文：http://www.oracle.com/technetwork/issue-archive/2013/13-jan/o13asktom-1886639.htmlI have a question about joining with collections and cardinality estimation. The optimizer is always estimati