Oracle中SQL语句解析的步骤
我们都知道在Oracle中每条SQL语句在执行之前都需要经过解析，这里面又分为软解析和硬解析。那么这两种解析有何不同之处呢？它们又分别是如何进行解析呢？Oracle内部解析的步骤又是如何进行的呢？下面我们就这些话题进行共同探讨。 在Oracle中存在两种类型的SQL语句，一类为DDL语句，他们是从来不会共享使用的，也就是每次执行都需要进行硬解析。还有一类就是DML语句，他们会根据情况选择要么进行硬解析，要么进行软解析。在Oracle 8i OCP教材的023中1-12有说明SQL语句的解析步骤，当一条SQL语句从客户端进程传递到服务器端进程后，需要执行如下步骤：
• 在共享池中搜索 SQL 语句的现有副本
• 验证 SQL 语句的语法是否准确
• 执行数据字典查找来验证表和列的定义
• 获取对象的分析锁以便在语句的分析过程中对象的定义不会改变
• 检查用户访问引用方案对象的权限
• 确定语句的最佳执行计划
• 将语句和执行计划载入共享的 SQL 区
这个先入为主的概念一直占据着我的脑海，我认为硬解析就是上面几个步骤。相对于硬解析，软解析的步骤就是上面第一步找到现有SQL语句的副本后，只需要验证用户是否有权限执行就是了，这样省略上面好几个步骤，相对硬解析来说性能开销就非常小了。即使是在论坛上和大家讨论时，我也一直坚持这个看法。直到前一天看了Tom的《Effective Oracle By Design》中关于语句处理的章节后，我才知道这个自己一直坚持的观点事实上是错误的。
事实上，在Oracle中SQL语句的解析步骤如下：
1、 语法检测。判断一条SQL语句的语法是否符合SQL的规范，比如执行：SQL> selet * from emp；我们就可以看出由于Select关键字少了一个“c”，这条语句就无法通过语法检验的步骤了。
2、 语义检查。语法正确的SQL语句在解析的第二个步骤就是判断该SQL语句所访问的表及列是否准确？用户是否有权限访问或更改相应的表或列？比如如下语句：
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
由于查询用户没有可供访问的emp对象，因此该SQL语句无法通过语义检查。
3、 检查共享池中是否有相同的语句存在。假如执行的SQL语句已经在共享池中存在同样的副本，那么该SQL语句将会被软解析，也就是可以重用已解析过的语句的执行计划和优化方案，可以忽略语句解析过程中最耗费资源的步骤，这也是我们为什么一直强调�
相关文档：
数据文件
每一个Oracle数据库都有一个或多个物理的数据文件,数据库信息(结构,数据)都保存在这些数据文件中,并且这些文件也只Oracle才能够解释与管理这些存储.Oracle数据文件具有以下一些特性:
1.一个数据文件仅仅关联一个数据库,数据文件与数据库之间对应关系是一对一关系,当然反过数据库与数据文件是一对多关系. ......
在系统迁移或升级的时候，可能会有oracle JOB迁移的需求。
对于10G的系统好说。可以用下面的办法：
userid="/ as sysdba"
directory=EXP_DIR
dumpfile=expdp_job.dmp
logfile=expdp_job.log
include=job
对于9i库好象有点复杂：
可以用下面的办法。
set echo on
conn sm ---------->JOB所在的用户名。
set se ......
--------------------显式游标
--查询数据
select * from employees;
--定义部分
declare
--声明游标
cursor mycur is select * from employees where employee_id<120;
--定义一个集合变量用� ......
查询速度慢的原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
7、 ......
2009-10-08 16:05
什么是视图
大家都知道，我们国家现在“神七”上天了。从美国的月球登月开始，人类上天不再是神话。听说，在美国，你只要出几十万美元，您就可以上一次月球进行太空旅行，所以，我们相信：在不久的将来，上天旅行将走进我们百姓的生活，那是一件多么新鲜神奇的事情� ......
