存档

2011年3月 的存档

这个主题是周末参加博文视点组织的open party上的演讲,准备不足,所以ppt中的内容不多,大部分内容都是现场即兴发挥。
根据这个ppt,我想整理两篇文章,一篇是如何取得SSD的磨损数据,以及SSD的可靠性分析;另一篇是通过实际案例讲述数据分布对于数据库性能的影响,以及flashcache的解决方案。
关于SSD与database的结合,flashcache的应用,这也是我今年的技术重点。
PPT:Database和SSD的实践与探索
–EOF–

3 20th, 2011 | Filed under 大话技术
标签: , ,

我之前曾经写过一篇Library cache内部机制详解,但是遗留了一些关于11g中mutex的改进的问题,最近因为有些11g的数据库频频发生mutex相关的等待事件,所以我又多这个问题做了一些探讨。
关于Mutex,可以参考ORACLE mutex实现机制这篇文章,mutex是从10g开始引入的,在library cache中有大量的使用,它的主要作用有两个:一是用来替换library cache pin,二是作为更轻量级的latch使用。
在9i中,Library cache lock有null,share,exclusive三种模式,lock的作用是控制进程间的并发访问。Library cache pin有share和exclusive两种模式,pin的作用是保证数据一致性,防止数据在访问时被交换出去。我们先来回顾一下library cache lock和library cache pin在不同场景下的使用方式:
Procedure/function/trigger
访问对象:需要在object handle上获取一个null类型的library cache lock(首先获取share,然后转换为null),然后在data heap上获取share类型的library cache pin,在其所依赖的表上不加任何lock和pin(先申请share类型的lock,申请到之后不再持有任何lock和pin,允许修改procedure所依赖的对象,即允许被打破)。
编译对象:需要在object handle上获取一个exclusive类型的library cache lock,然后在data heap上获取exclusive类型的library cache pin,同时在依赖的对象上获取share类型的library cache lock和pin,保证依赖的对象不能被修改。
当持有对象的library cache pin时,同时会在row cache中对相应的对象加锁,就是row cache lock,阻止可能导致数据字典信息混乱的DDL发生,row cache lock和library cache lock/pin一样,都是为了保证对象的一致性。
Cursor
Cursor execute:在object handle上获取null类型的library cache lock(首先获取share,然后转换为null),然后再data heap上获取share类型的library cache pin,在其所依赖的表上不加任何lock和pin(先申请share类型的lock,申请到之后不再持有任何lock和pin,允许修改cursor所依赖的对象,即允许被打破)。
Cursor hard parse:Cursor硬解析需要在object handle上获取exclusvie类型的library cache lock,然后再data heap上exclusive获取类型的library cache pin,同时在依赖的对象上获取share类型的library cache lock和pin,保证依赖的对象不能被修改。
Null类型的library cache [...]

3 1st, 2011 | Filed under 大话技术
标签: