20140309_博瑞学习

  今天在博瑞学了不少东西，在这里先谢谢邱老师！

  今天讲的课题是数据库调优，主要讲的是sql调优。下面说说我记录的不清楚的知识点吧：

1：数据库优化器模式；

    这部分内容已经整理到自己的ncp文件中了，可以查看。

2：数据库挂了怎么办？（连sqlplus / as sysdba也没反应）

     可以在后台杀了所有的进程，试试看；（kill -9）

     kill -9 pid （9：强制杀进程）

     杀死进程，pid 为进程的进程标识符。

     要杀死那个进程，可以用ps -l命令查看pid

3：sql调优的几个方面：

     第一：优化器模式；

     第二：索引；

     第三：添加提示；（例如：只是为了更改当前sql的优化模式，可以添加/* +first_row */）

           这种方法可能主要是由于输出的时候数据量太大

First_rows, 开始的行(第一行)优先输出 First_rows_n, 开始的n行优先输出 All_rows 所有的行优先输出(查询的总体时间最短)

4：sql执行过程：

4.1、语法检查(syntax check):检查此sql的拼写是否语法。

4.2、语义检查(semantic check): 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

4.3、对sql语句进行解析(prase): 利用内部算法对sql进行解析(软解析，硬解析)，生成解析树(parse tree)及执行计划(execution plan)。

Parse主要分为三种：

               1、Hard Parse (硬解析)

               2、Soft Parse (软解析)

               3、Soft Soft Parse(好像有些资料中并没有将这个算在其中)

           Hard Parse：就是上面提到的对提交的Sql完全重新从头进行解析(当在Shared Pool中找不到时候将会进行此操作)，总共有一下5个执行步骤：

               1：语法分析

               2：权限与对象检查

               3：在共享池中检查是否有完全相同的之前完全解析好的. 如果存在，直接跳过4和5，运行Sql, 此时算soft parse.

               4：选择执行计划

               5：产生执行计划

           注：创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。

           Soft Parse：就如果是在Shared Pool中找到了与之完全相同的Sql解析好的结果后会跳过Hard Parse中的后面的两个步骤。

Soft Soft Parse：实际上是当设置了session_cursor_cache这个参数之后，Cursor被直接Cache在当前Session的PGA中的，在解析的时候只需要对其语法分析、权限对象分析之后就可以转到PGA中查找了，如果发现完全相同的Cursor，就可以直接去取结果了，也就就是实现了 Soft Soft Parse.

解析的步骤可以分为两个步骤：

               1)　验证SQL语句是否完全一致。

             在这个步骤中，Oracle将会对传递进来的SQL语句使用HASH函数运算得出HASH值，再与共享池中现有语句的HASH值进行比较看是否一一对应。现有数据库中SQL语句的HASH值我们可以通过访问v$sql、v$sqlarea、v$sqltext等数据字典中的HASH_VALUE列查询得出。

             如果SQL语句的HASH值一致，那么ORACLE事实上还需要对SQL语句的语义进行再次检测，以决定是否一致。那么为什么Oracle需要再次对语句文本进行检测呢？不是SQL语句的HASH值已经对 应上了？事实上就算是SQL语句的HASH值已经对应上了，并不能说明这两条SQL语句就已经可以共享了。

                 例如：假如用户SYS有自己的一张表EMP，他要执行查询语句：select * from emp; 用户SYSTEM也有一张EMP表，同样要查询select * from emp；这样他们两条语句在文本上是一模一样的，他们的HASH值也会一样，但是由于涉及到查询的相关表不一样，他们事实上是无法共享的.

因此在检查共享池共同SQL语句的时候，是需要根据具体情况而定的。

可以进一步查询v$sql_shared_cursor以得知SQL为何不能共享的原因：

SQL>selectaddress,auth_check_mismatch,translation_mismatch,optimizer_mismatch

                      from v$sql_shared_cursor where address in (

                      select address from v$sql where upper(sql_text) like 'SELECT * FROM EMP%' )

              TRANSLATION_MISMATCH表示SQL游标涉及到的数据对象是不同的；

              AUTH_CHECK_MISMATCH表示对同样一条SQL语句转换是不匹配的。

              optimizer_mismatch表示会话的优化器环境是不同的。

                  2)验证SQL语句执行环境是否相同

                  比如同样一条SQL语句，一个查询会话加了/*+ first_rows */的HINT，另外一个用户加/*+ all_rows */的HINT，他们就会产生不同的执行计划，尽管他们是查询同样的数据。

             通过如上检查以后，如果SQL语句是一致的，那么就会重用原有SQL语句的执行计划和优化方案，也就是我们通常所说的软解析。如果SQL语句没有找到同样的副本，那么就需要进行硬解析了。

              Oracle根据提交的SQL语句再查询相应的数据对象是否有统计信息。如果有统计信息的话，那么CBO将会使用这些统计信息产生所有可能的执行计划(可能多达成千上万个)和相应的Cost，最终选择Cost最低的那个执行计划。如果查询的数据对象无统计信息，则按RBO的默认规则选择相应的执行计划。这个步骤也是解析中最耗费资源的，因此我们应该极力避免硬解析的产生。至此，解析的步骤已经全部完成，Oracle将会根据解析产生的执行计划执行SQL语句和提取相应的数据。

4.4、执行sql，返回结果(execute and return)

5：关于sql优化的几个注意事项：

     5.1：在优化sql时，若not in 慢的时候，可以考虑用minus 代替；可以考虑用 <= 代替 < ；

     5.2：not null ,or 是不走索引的，所以在where  a is null 时，（a列上有索引）可以使用创建组合索引的方法，（这里a列必须放在组合索引的第一个字段，不为空的字段放后面）；若含有 or 时，可以使用  union 代替；

     5.3：尽量少使用外连接，因为外连接时走的是全表扫描；

     5.4：对于父子表：

          若父表数据大的时候最好使用 in 代替 exists；

6：关于怎么定位sql、查看执行计划；

   这部分内容很多，已经整理到自己的ncp文件中了，可以查看。

本文出自 “博瑞学习记录” 博客，谢绝转载！