【SQL 性能优化】参数设置

QL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
SQL> show parameter optimizer_
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      CHOOSE
optimizer_secure_view_merging        boolean     TRUE
SQL>
---optimizer_features_enable
如果在升级数据库后还想保持优化器在旧版本上的原有行为,可以设置optimizer_features_enable为旧版本号,不过建议尽快将应用程序调整为适合新版本数据库。可以看看这个参数的取值:
SQL> alter session set optimizer_features_enable ='ddd';
ERROR:
ORA-00096: invalid value ddd for parameter optimizer_features_enable, must be from among
10.2.0.4.1, 10.2.0.4, 10.2.0.3, 10.2.0.2, 10.2.0.1, 10.1.0.5, 10.1.0.4, 10.1.0.3, 10.1.0,
9.2.0.8, 9.2.0, 9.0.1, 9.0.0, 8.1.7, 8.1.6, 8.1.5, 8.1.4, 8.1.3, 8.1.0, 8.0.7, 8.0.6,
8.0.5, 8.0.4, 8.0.3, 8.0.0
optimizer_features_enable 是动态的,可以在系统级和语句级修改。也可以在语句级使用提示修改

optimizer_features_enable(enable)
optimizer_features_enable('10.2.0.5')
注意:optimizer_features_enable 不仅能禁用新版本的特性也能禁用bug 修复。

--optimizer_mode
从这里的提示可以看出优化模式的选择值。
SQL> alter session set optimizer_mode ='dd';
ERROR:
ORA-00096: invalid value dd for parameter optimizer_mode, must be from among
first_rows_1000, first_rows_100, first_rows_10, first_rows_1, first_rows, all_rows,choose, rule
每个值的含义如下:
Rule:基于规则的方式,忽略CBO和统计数据并且完全基于基本数据字典信息生成执行计划。
Choose:允许ORACLE选择最合适的优化器目标,默认的情况下Oracle用的便是这种方式。指的是当一个表或或索引有统计信息,则走CBO的方式,如果表或索引没统计信息,那么ORACLE将使用RULE模式
First Rows:基于成本的优化器模式,当一个表有统计信息时,它将以最快的速度返回查询的最先几行,从总体上减少了响应时间,但是会造成总体查询速度的下降或者是消耗更多的资源,通常会选择索引扫描而不是全表扫描,所以这种模式最适用于在线系统,因为在这样的系统中终端用户希望以最快的速度看到一些结果
All Rows:基于成本的优化器模式,当一个表有统计信息时,它将确保总体查询时间最短,但是它可能在收到第一条记录的操作上花费更长的时间。这种模式通常选择全表扫描,所以这种模式最适用于批量查询,没有统计信息则走RULE模式。
一般来讲,
1 需要获取所有记录更重要,应该将参数设置为all_rows。比如报表系统和 OLAP,数据仓库系统和缓存数据的中间层组件中。
2 如果前几行更重要或者对响应时间的要求非常高的系统,使用first_rows_n这里的n可取(1,10,100,1000)。
  optimizer_mode 是动态的,可以在系统级和语句级设置。也可以使用提示(all_rows,first_rows(n))在语句级更改。

---optimizer_dynamic_sampling 动态采样
优化器可以在语句解析阶段进行信息统计并动态收集。注意:动态信息统计信息既不存储在数据字典也不在其他地方,真正重用它们的是共享游标本身。该参数指定了动态采样的的方式和时间。
1 如果optimizer_features_enable设置为10.0.0或者以上,默认为2,
2 9.2.0则为1,
3 9.0.1或者以下则为0,即禁用了动态采样。
可以在系统级别和会话级别来修改这个参数。也可以通过提示dynamic_sampling()在语句级应用动态采样。
1 设置为所有表设置采样层级:dynamic_sampling(N)
2 为某个表指定采样层级:dynamic_sampling(TNAME N)
层级  含义                                                                     数据块的数量
0     禁止动态采样                                                                0
1     对于没有对象统计信息的表在下面三种情况下使用动态采样。                      32
      1 表没有索引。2 是连接的一部分(包括子查询和不可合并视图)。3块数多于采样数。  
 
2      对于没有对象统计信息的表使用动态采样。                                     64

3     对符合层级2标准的表已及已经使用了评估条件选择性猜测的表使用动态采样                             32

4     对符合层级3标准的表以及where子句中引用了两个或更多字段的表使用动态采样。                  32
 
5     同等级4                                                                     64
6     同等级4                                                                     128
7     同等级4                                                                     256
8     同等级4                                                                     1024
9     同等级4                                                                     4096
10    同等级4                                                                      所有               

optimizer_index_caching
这个参数影响嵌套循环连接的探测索引的代价,0-100表示在使用嵌套循环或这in-list迭代时将索引缓存在buffer cache的百分比。例如,设置为100,则优化器认为100%能在内存中找到索引数据,会按照这个设定来计算cost和选择执行计划。

optimizer_index_cost_adj

和optimizer_index_caching一样,这个参数也是cbo用来计算cost的,这个参数可以用来调整使用索引的代价,默认值是100,范围是1-10000,它表示索引扫描和全表扫描的比值。例如设置为10,意味着使用通过索引路径访问是正常通过索引路径访问的10%(oracle 10g performace tuning guide),也即可以设置索引参与计算代价的不同值。
optimizer_secure_view_merging
这个参数控制视图合并,默认值是true,在不影响安全问题的情况下允许视图合并,如果设置为false,则在任何情况下允许视图合并。

时间: 2024-08-02 21:14:04

【SQL 性能优化】参数设置的相关文章

Spark SQL性能优化

性能优化参数 针对Spark SQL 性能调优参数如下: 代码示例 import java.util.List; import org.apache.spark.SparkConf; import org.apache.spark.api.java.JavaSparkContext; import org.apache.spark.sql.api.java.JavaSQLContext; import org.apache.spark.sql.api.java.Row; import org.a

Oracle SQL性能优化系列学习一_oracle

正在看的ORACLE教程是:Oracle SQL性能优化系列学习一.1. 选用适合的ORACLE优化器  ORACLE的优化器共有3种:  a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性)  设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖.  为了使用基于成本的优化器(

Oracle SQL性能优化系列学习二_oracle

正在看的ORACLE教程是:Oracle SQL性能优化系列学习二.  4. 选择最有效率的表名顺序(只在基于规则的优化器中有效)  ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行派序,然后扫描第二个表

ORACLE SQL性能优化系列 (十四) 完结篇

oracle|性能|优化 46.       连接多个扫描 如果你对一个列和一组有限的值进行比较, 优化器可能执行多次扫描并对结果进行合并连接. 举例:     SELECT *     FROM LODGING     WHERE MANAGER IN ('BILL GATES','KEN MULLER');       优化器可能将它转换成以下形式     SELECT *     FROM LODGING     WHERE MANAGER = 'BILL GATES'     OR MA

面包含点-PostGresql SQL性能优化求助

问题描述 PostGresql SQL性能优化求助 点表:create table point_p(flong float8flat float8userid int4);insert into point_p(flongflatuserid) values (113.12655922.6553671);insert into point_p(flongflatuserid) values (113.02934522.6219592);insert into point_p(flongflatu

SQLSERVER SQL性能优化技巧_MsSql

1.选择最有效率的表名顺序(只在基于规则的优化器中有效) SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表driving table)将被最先处理,在FROM子句中包含多个表的情况下,必须选择记录条数最少的表作为基础表,当SQLSERVER处理多个表时,会运用排序及合并的方式连接它们, 首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行排序:然后扫描第二个表(FROM子句中最后第二个表):最后将所有从第二个表中检索出的记录与第

SQL性能优化之定位网络性能问题的方法(DEMO)_MsSql

最近项目组同事跟我说遇到一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,很不科学.我帮了分析出了原因并得到解决.下面小编安装类似表结构,构造了一个案例,测试截图如下所示: 这个表有13800KB(也就是13M多大小),因为该表将图片保存到数据库(Item_Photo字段为iamge类型),这个是历史原因,暂且不喷这种的设计.看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,而是在网络数据传时间上(服务器与客户端位于异地,两地专线带宽6M,不过很多应

Oracle SQL性能优化系列学习三_oracle

正在看的ORACLE教程是:Oracle SQL性能优化系列学习三.8. 使用DECODE函数来减少处理时间  使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.  例如:  SELECT COUNT(*),SUM(SAL) FROM EMP  WHERE DEPT_NO = 0020  AND ENAME LIKE 'SMITH%';  SELECT COUNT(*),SUM(SAL)  FROM EMP  WHERE DEPT_NO = 0030  AND ENAME LIKE

你对SQL性能优化知识知多少?

转自:http://www.vaikan.com/what-do-you-know-about-sql-performance/  "SQL性能优化是一种黑魔法 就像炼金术一样: 各种配方难解晦涩, 只有一小部分圈内人才能理解." 这是一种误解,SQL数据库使用的是大家公知的算法来实现可以预期的执行性能.然而,问题是,人们很容易写出不能发挥最高效算法的SQL查询语句,因而也容易产生无法预期的性能结果. 下面是5道关于SQL性能优化小测试题,这些测试题也许会让你坚信SQL优化就是一种黑魔

复杂SQL性能优化的剖析(二)(r11笔记第37天)

    昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大.    对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个.我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦