-
编辑 删除
资源供给：并发性控制和mutex之三
我的文章里解释的不细致而且模糊点很多，大家可以参考吕海波先生的文章：http://www.itpub.net/thread-1813629-1-1.htm 来简单了解latch和mutex。 mutex的优化，当mutex处于最低粒度的时候，事实上优化的余地就非常小，比如在latch优化中常用的热点分布在mutex基本上是不可实践的。 我们...
-
编辑 删除
资源供给：并发性控制和mutex之二
前面讲了mutex for cursor，个人认为mutex for cursor和library cache pin并没有太大的区别，mutex所强调的细粒度访问并没有在这里体现出来，无论是library cache pin还是cursor mutex都是基于细粒度的，区别只是在于library cache pin采用队列机制，而mutex采用CAS机制而已。CAS机制可以保证在cursor mutex pin上具有比...
-
编辑 删除
资源供给：并发性控制和mutex之一
简单案例描述： 某商业银行业务系统表现出在高峰期CPU消耗很高，有些消耗CPU特别高的进程，但总是会变化，业务系统响应还基本可以接受。在CPU Time表现中Parse CPU相对比较高，Hard Parse不高，系统偶尔出现cursor pin: S，v$mutex_sleep_history表现出较高的gets和sleeps。经过综合判断为mutex的机制冲突引起，应用patch...
-
编辑 删除
资源供给：并发性控制和latch之二
latch，spinlock，轻量的旋转锁，顾名思义通过spin来获得latch。 Oracle期望latch的持有时间很多，所以采用在线等待的方式来获得latch，也就是spin。注意spin不释放CPU资源，在spin期间消耗大量的CPU资源资源...
-
编辑 删除
资源供给：并发性控制和latch
简单案例说明： 某运营商的客服系统在有几天遭遇业务高峰的时候，发生大量row cache object latch冲突，导致客服响应延迟甚至阻塞。通过flush shared_pool有所缓解，但是很快又到达高峰，即使重新启动数据库也很快会达到高峰导致业务系统阻塞。一旦度过高峰期，业务系统恢复正常。查询系统表现出了相对...
-
编辑 删除
资源供给：并发性控制和锁之七
简单案例说明： 某医院业务系统每个30分钟左右会出现一次短暂的卡壳，发现卡壳期间为CKPT等待CF Lock，具体原因由每半小时一次的rman调度引起。 文件锁，比如CF,DF等等，这里对于性能影响比较大的主要是CF锁，由于CF锁引起的性能问题非常多见，在各行各业都会遇到。CF锁，作用在控制文件之上的队...
-
编辑 删除
资源供给：并发性控制和buffer lock
buffer busy wait的运行案例很多，但记忆中没有非常清晰的，居然无法在案头写个简单案例，惭愧。 在写之前简单的搜索知识点整理些思路的时候，发现这片文章不错：http://www.itpub.net/thread-1801066-1-1.html，大家主要参考这篇文章可以了解b...
-
编辑 删除
资源供给：并发性控制和锁之六
简单案例描述： 某运营商持续出现library cache lock,library cache load lock以及library cache latch冲突，即使是重新启动之后也只是简单缓解之后很快就会继续发生状况。初步判断是shared pool不足引起，持续观察shared pool，发现自由空间不断的迅速减少，当减少到一...
-
编辑 删除
资源供给：并发性控制和锁之五
简单案例说明： 某运营商实时计费系统偶尔会出现Session挂起，所有的Session登录几乎完全被挂起，而运行中的Session则可以正常操作。检查systemdump发现，所有的挂起session都在等待audses$的sequence，只要把占有的SQ lock的Sesssion Kill则所有登录可以继续。检查audses$的cache，为缺省的20，增大audses$的cache为200...
-
编辑 删除
资源供给：并发性控制和锁之四
简单案例描述： 某运营商的CRM系统，突然出现大量latch: undo global data冲突，主要的查询语句都大规模的进行关于undo global data的冲突。在consistent read的时候需要获得undo global data latch去查看对应的undo segment Header和Undo block信息，而这个...
-
编辑 删除
资源供给：并发性控制和锁之三
简单案例描述： 某运营商的账务系统在某时刻出现业务系统性能下降，简单检查为大量的TX锁等待，同时发现smon在进行大型事务回滚。该业务锁等待的原因非常简单，手工处理的批量update操作意外被中止，引起系统回滚。回滚操作依赖于s...
-
编辑 删除
资源供给：并发性控制和锁之二
简单案例描述： 在业务运行过程中，某张主要表格发生大规模的TX锁冲突，导致业务完全挂起。原因非常简单，某个维护人员通过PLSQL发起了一个select for update操作，导致表格大量的行被锁定。 事务锁，...
-
编辑 删除
资源供给：并发性控制和锁之一
BL, Buffer Cache ManagementBR, Backup/RestoreCF, Controlfile TransactionCI, Cross-instance Call InvocationCU, Bind EnqueueDF, DatafileDL, Direct Loader...
-
编辑 删除
资源供给：IO子系统之七
随机IO：以数据库而言，以单个block size发布的IO为随机IO，比如db_block_size为4k,8k等 顺序IO：以数据库而言，以大于单个block size发布的IO都为顺序IO 磁盘系统：对于磁盘系统来说，并没有随机IO和顺序IO的说法。一般来说，...
-
编辑 删除
资源供给：IO子系统之六
更新了部分内容，修正了部分错误。这个时候谈IO子系统，就不能不谈SSD，否则都没法生存了。可惜个人在ssd没有什么实践经验，甚至在知识上也非常欠缺。这里只能对于ssd的一些简单认识说些自己的看法，里面必然会有很多的缪论。这里要特别感谢@jametong的帮助，帮我理清了东西。 ...
-
编辑 删除
资源供给：IO子系统之五
认识硬盘的特性，是数据库系统优化的基础所在，也是系统设计优化的基础所在。 硬盘的基本属性： 磁头 盘片 ...
-
编辑 删除
资源供给：IO子系统之四
简单案例描述1： 某新华书店综合业务系统的存储系统从HP VA7100升级到HP EVA 8000之后，业务系统性能没有得到提高，甚至还略有下跌，最不爽的是sar -d显示磁盘利用率很高。而从sar -d的tps远远未达到磁盘本身的iops，hp认为可能是虚拟化存储用了过多的空间导致，在释放一部分空间之后依然表现如...
-
编辑 删除
资源供给：IO子系统之三
简单案例说明：某社保系统在业务高峰期总是性能表现很差，从AWR报告中可以看出，负载压力不是很大，只是IO的响应速度很慢。在负载压力一般的情况下，IO响应速度缓慢只能是意味着下面两个问题：（1）、IO子系统故障 （2）、IO子系统配置不当。检查操作系统，没有发现IO子系统错误状况，检...
-
编辑 删除
资源供给：IO子系统之二
案例描述： 某运营商的dbra备份系统，备份构建在vxvm和vxfs文件系统之上，串行更新的速度基本理想。由于无法达到更新目标，通过增加并行来增加IO写速度，结果并行度加大之后，iops快速下跌，io子系统无法提供并发能力。由于...
-
编辑 删除
资源供给：IO子系统之一
资源供给：IO子系统 简单案例描述：某运营商的OCS实时计费系统实时计费效率不够，磁盘IO使用率100%。简单咨询了下其流程结构：11个并行查询进程的结果送到一个处理中心进行处理。开发生分析是磁盘IO处理能力不足，处理中心富余。我问了如果查询数据每秒100M返回是否可以达到处理效率，回答是肯定的。处...
