latch :library cache ,latch:shared pool,library cache lock ,library cache pin)
以下内容摘自 高级owi与 oracle性能调整
用户请求执行SQL,ORACLE则会利用上面说明的内存和 latch执行必要的工作，将这些内容整理结果如下： (1) 用户请求执行新SQL时，oracle在执行基本语法和权限检查等步骤后，获得hash bucket的library cache latch,然后确认 library cache是否存在相同的sql,则相同的LCO.若获得library cache latch过程中发生争用，则等待latch:library cache事件。 存在相同lco存在时直接调至第8阶段执行，此过程称之为soft parsing. 每当发生sql parsing 请求时，oracle都会增加parse count (total)统计值。 (2) 若不存在相同sql,在获得shared pool latch后，从空闲列上查找最合适大小的 空闲chunk,如果在获得shared pool latch过程中 发生��用，则等待 latch:shared pool事件，oracle一直会拥有 shared pool latch, 直到确保chunk为止。 (3) 若不存在最适合大小的空闲chunk,则查找更到的 空闲chunk后分割(split)使用，分割后剩下的内存区重新登记到适当的空闲列。 (4) 若检索了所有空闲列也没有找到恰当的空闲chunk，则检索lru列，lru列上的chunk是重建(recreatable)的，而且是当不使用的(还没有 pin的) (5) 若在LRU上检索也不能确保恰当大小的chunk，则追加分配共享池内的剩余内存空间 (6) 以上过程均失败，则发生错误ora-4031 (7) 若找到恰当的chunk,对sql相应的handle(library cache handle)以exclusive模式获得library cache lock,并创建LCO信息 ，创建LCO信息后，library cache lock变换为null,将library cache pin以exclusive模式获得后，创建执行计划(excution plan) 第2-7耗过程为hard parsing,若发生hard parsing 过程中发现sql语句错误,则parse count(hard)统计值和parse count(failure)统计 值将会一起增加。 (8) oracle对sql cursor以shared模式获得library cache lock和library cache pin，并执行sql，这个阶段称为执行阶段， sql cursor锁参考的lco(table,procedure)基本上与sql cursor相同模式获得library cache lock和library cache pin.但是 执行修改对象信息(如DDL语句)工作时，对相应的对象所对应的LCO以exclusive模式获得library cache lock和library cache pin .例如"alter table xx add varchar2(10)",这个sql 语句在执行（exceute）阶段，对与sql cursor自身以shared 模式获得 library cache lock,但是对与表xxx所对应的lco以exclusive模式获得libraryt cache lock和library cache pin过程发生争用。则 各自需要等待library cache lock事件和library cache pin事件。 (9) oracle对执行结束的sql cursor fatch数据，这个过程就是fatch阶段,在fatch阶段， sql cursor将library cache lock变换成null 模式，并解除library cache pin，oracle手册将以null模式获得library cache lock称为breakable parse lock. ------
parsing阶段的cpu使用事件和执行parsing时经历时间记录在parse time cpu统计值和parse time elapsed 统计值上。若在执行parsing过程中，为获得latch或tx锁等待时间拖长，parse time elapsed统计值表现得比 parse time cpu统计值高出许多，特别是多个会话同时执行hared parsing时，会出现parse time elapsed统计值 大幅增加现象，这是因为在获得大部分library cache latch和shared pool latch过程中发生争用，导致等待时间 相应增加。 请注意： 即便存在许多空闲chunk，但是只要未发现能承载最适合大小的理想空闲chunk，oracle就不再执行工作 共享池的空闲内存(free memory)虽然很富裕，但还是会出现错误ora-4031 (unable to allocate %s bytes of shared memory)就是这个原因，这种现象大部分发生过渡hared 导致空闲chunk分割的时候，这种共享池碎片化 (fragm entiation)也影响shared pool latch争用.若共享池被碎片化，则空闲列包含许多空闲chunk,为了分配空闲 chunk检索空闲列的过程中，需要获得shared pool latch，所以chunk被分割得太碎，空间列检索时间会增加，相应地 拥有shared pool latch时间也会增加。 发生错误ora-4031时，alter system flush shared pool命令作为应急措施使用，在共享池flush,连续的空闲chunk会聚会 (coalesce),所以下次请求sql时发现相当大的空闲chunk可能性提高，但是shared pool的 flush 不是错误ora-4031的解决方案， 要知道flush也会可能会引起其他性能问题。 每次发生parsing时，均需要获得library cache latch,所以发生争用的概率特别高，library cache latch与 系统性能有直接关系，所以oracle为解决library cache latch提供了多种方法： 1、对于pl/sql内反复执行的sql cursor 只有在最初执行时parsing,之后没有soft parsing也可以执行，因为不发生 soft parsing,所以不需要获得library cache latch,oracle 将sql cursor相应的lco pin在sga上，所以即便没有获得 library cache latch也可以参���lco 2、提供会话内缓冲LCO位置的功能，这个就是session cursor caching.oracle 将一个会话内执行三次以上的sql cursor 的位置(library cache的位置)和sql文本存储在PGA,所存储的sql cursor数量由session_cached_cursors参数决定，即便使用了 此功能也依旧会发生soft parsing，需要获得library cachelatch,不用检索library cache内存结构，而直接知道lco位置。 所以能缩短获得library cache latch的时间。相应的library cache latch所引起的争用也会件减少。
|
当前位置：
论坛首页 »
自由讨论区 »
MySQL, Oracle及数据库讨论区
»
发起投票
技术讨论
加好友
发消息
2011-8-3 17:11:57 |
赞(
操作
