调整会话的细节取决于许多因素，包括您是主动调整还是被动调整。
在主动SQL调整中，您经常使用SQL Tuning Advisor来确定是否可以使SQL语句性能更好。在反应式SQL调整中，您可以纠正用户遇到的与SQL有关的问题。
无论您是主动调整还是被动调整，典型的SQL调整会话都涉及以下所有或大部分任务：
- 识别高负载的SQL语句
查看过去的执行历史记录，以查找负责大部分应用程序工作负载和系统资源的语句。
- 收集与性能相关的数据
该优化的统计数据是SQL调优的关键。如果这些统计信息不存在或不再准确，那么优化器将无法生成最佳计划。与SQL性能相关的其他数据包括该语句访问的表和视图的结构，以及该语句可用的任何索引的定义。
- 确定问题的原因
通常，SQL性能问题的原因包括：
- 设计效率低下的SQL语句
如果编写SQL语句以使其执行不必要的工作，那么优化器将无法做很多事情来提高其性能。低效设计的例子包括
- 次优执行计划
的查询优化器（也称为优化器）是确定哪个内部软件执行计划是最有效的。有时，优化器会选择一个访问路径不理想的计划，这是数据库从数据库检索数据的方式。例如，具有低选择性的查询谓词的计划可能会在大表上使用全表扫描而不是索引。
您可以将性能最佳的SQL语句的执行计划与性能欠佳的语句的计划进行比较。这种比较以及诸如数据量变化之类的信息可以帮助确定性能下降的原因。
- 缺少SQL访问结构
缺少索引和实例化视图之类的SQL访问结构是导致SQL性能欠佳的典型原因。最佳的访问结构集可以将SQL性能提高几个数量级。
- 陈旧的优化器统计信息
DBMS_STATS当统计信息维护操作（自动或手动）无法跟上DML导致的表数据更改时，收集到的统计信息可能会过时。由于表上的陈旧统计信息无法准确反映表数据，因此优化程序可以基于错误信息做出决策并生成次优执行计划。 - 硬件问题
性能欠佳可能与内存，I / O和CPU问题有关。
- 设计效率低下的SQL语句
- 定义问题的范围
解决方案的范围必须与问题的范围相匹配。在数据库级别考虑一个问题，在语句级别考虑一个问题。例如，共享池太小，这会导致游标快速老化，进而导致很多硬解析。使用初始化参数增加共享池的大小可以解决数据库级别的问题，并提高所有会话的性能。但是，如果单个SQL语句未使用有用的索引，则更改整个数据库的优化器初始化参数可能会损害整体性能。如果单个SQL语句有问题，则使用此语句在适当范围内的解决方案可以解决此问题。
- 实施纠正措施以优化执行SQL语句
这些操作视情况而定。例如，您可以重写SQL语句以提高效率，通过重写使用绑定变量的语句来避免不必要的硬解析。您可能还会使用等联接，从
WHERE子句中删除函数，并将复杂的SQL语句分解为多个简单的语句。在某些情况下，不是通过重写语句而是通过重组架构对象来提高SQL性能。例如，您可以为新的访问路径建立索引，或对串联索引中的列进行重新排序。您还可以对表进行分区，引入派生值，甚至更改数据库设计。
- 防止SQL性能下降
为了确保最佳的SQL性能，请验证执行计划是否继续提供最佳性能，并在可用时选择更好的计划。您可以使用优化器统计信息，SQL配置文件和SQL计划基准来实现这些目标。
