sql语句执行过程小结

sql语句执行过程
    客户端进程连接到db
我的测试是：当服务器监听是启动状态的时候，远程客户端可以连到mount状态和open状态的db，当db在nomount状态时候查看监听的状
态会发现已经有服务注册了，但是远程客户端连接会报错为：ora-12528:TNS:监听程序：所有的例程都无法建立连接
    db分配一个服务器进程service process来和user process通信。
对于专用服务器方式下的每一个user process服务器端都会产生一个server process负责进行通信，至于共享服务器模式，db会维护少量的服务器进程以调度程序调用服务器进程来处理客户端请求。
    对于server process来执行客户端发出的sql语句而不是由instance的后台进程来执行sql语句，原因应该是对于少量用户和小并发的环境来说也许 oracle可以维护相关的后台进程来处理sql语句，但是用户量和并发性的问题会导致这种由后台进程处理sql语句的方式面对一个瓶颈，而由 server process来处理的话会很好的避免这个瓶颈(dba的思想天空)。(对于dml,ddl,dcl等语句也是由server process产生redo日志写到redo log buffer中，而后缓存中的日志是由lgwr进程写到联机重做日志文件中的)。
    如果没有在shared pool的library cache中找到相同的执行计划则会进行硬解析。找到相同的执行计划则为软解析，相对于硬解析来说软解析也需要进行语法，语义和对象权限等进行查看，只是不需要再生成执行计划。
    如果在db buffer cache中找不到相关数据，则由server process负责从磁盘上的dbf文件(想起我大学的dnf练到刚刚觉醒的狂战了)中读数据--物理读(会发生物理i/o)，而dbwn进程则是负责从 db buffer cache中向dbf文件上写数据。如果在db buffer cache中找到数据则属于逻辑读(进行逻辑i/o)。
    关于逻辑i/o(内存读l) 和 物理i/o(物理读p)，sql的命中率是l/l+p(逻辑读比逻辑读+物理读)。命中率低是一定有问题，但是命中率高不一定没有问题，要关心的是每秒的物理读和逻辑读。(vmstat和iostat是查看状态的两个命令)。(简略，待续...)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29117696/viewspace-1075585/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29117696/viewspace-1075585/