-
编辑 删除
ORACLE问题集
问题一ORACLE9i以后，出现多类型多大小buffer cache.除了default cache以外，还有recycle keep buffer cache.除了标准块buffer外，还支持多块2-32k buffer cache.这些buffer cache跟default buffer cache的工作原理是不是一样？有什么区别?问题二一个数据库的buffer cache只有一个ckpt queue，有多个lru list dirty list,什么时候，谁把dirty buffer从dirty list移到ckpt queue?问题三一个SGA自动管理的问题，如果系统进行了自动调整，调整结果设置存放在系统哪里？下次重启数据库会从那里读SGA配置信息?问题四常见latch周期问题。什么样情
-
编辑 删除
浅谈10G SGA自动管理
SGA自动管理一些简单实用知识[@more@]SGA自动管理概述1.为什么SGA自动管理？SGA自动管理可以避免手工管理的局限和不便，简化数据库管理工作。2.如何在SGA自动管理与手工管理之间切换？通过设置sga_target为零和非零值，可以完成手工和自动管理切换。3.常用SGA参数问题：sga_max_size 表示系统可以分配给SGA最大内存大小。如果这个参数设置小于SGA各组件大小的和(包括自动管理和手工管理,明式设置和隐含设置)，则系统会忽略这个参数设置。但在实例启动后，查询这个参数的值自动改为系统实际使用的值。在这种情况下，不能再动态加大sga_targ
-
编辑 删除
浅论ORA-01555
ORA-01555是ORACLE中一个经典报错。这个在错误相对在新开发平台或刚刚更改的应用中更为常见，如果在一个日常生产系统中经常出现ORA-01555报错，这将是一个代价非常大的报错，绝对是性能杀手或计算机资源杀手。所以如果日常生产系统经常出现这个问题，就要考虑优化相关SQL代码和优化数据库设置。ORA-01555报错跟一致性读和事务一致性有很大关系。而ORACLE的一致性读是优胜于当前其它数据库一个重要特征。ORA-01555报错产生根本原因1.一致性读所需要的回滚段里的相关undo信息被覆盖或undo tablespace 空间被回收而导致这些undo信息不可用。2
-
编辑 删除
latch分类
从oracle 9201起，oracle根据不同的spin_count对latch进行了分类。为什么要进行这样的分类了？因为以前版本中，改一个latch的spin_count,会牵一发而动全身，让所有latch的spin_count都被同样地改变了。这种做法明显不太具有实际应用的可行性。所以oracle根据不同的spin_count对latch分成了8类，说明你可以把系统中的latch按它们的不同spin_count分成8类，但它们的系统默认值spin_count都是16000。这样做有什么应用前景？可以根据系统自身资源使用情况，针对不同latch不同资源使用特点，优化各个latch的spin_count.如某个latch的spin成功率
-
编辑 删除
latch的层次概念
latch的层次概念为什么要有这个层次概念？大家都知道oracle锁有一个死锁问题，那么latch了？有没有可能两个进程都持有对方正在等待的latch而形成死锁现象？oracle的latch没有这个现象，为什么？就因为有层次的概念，有效的防止latch死锁现象。那么是如何防止的了？那就要说oracle是怎么用这个level的。关层次oracle有两个规则分别对应不同的latch请求模式：一个是在愿意等待模式下，一个进程请求的latch的level必须高于这个进程现有持有的latch level。一个是在不愿意等待模式下，一个进程不能出现持有两个以上同一层次上的latch的情况。这
-
编辑 删除
Enqueue&Lock and Latch
Enqueue&Lock and Latch Enqueue 和Latch的层次是不一样的，它们不是类似物，不具可比性。而latch 同lock是一个层面的。而enqueue是oracle系统内一个队列，一个等待某个锁的队列，保证对这个锁请求的有序性，FIFO。所以主要讲一下Latch 和Lock1.保护对象不同，一个保护内存结构，一个保护对象结构。2.保护方法不同，一个无序竞争，一个是有序竞争。3.请求模式不同，前者只有二种，后者多达6种。4.可见范围不同，latch保护的是SGA里面的东东，所以当然与实例有密不可分的关系。某个实例里的latch跟其它的实例不搭界的。而lock就不同了，
-
编辑 删除
Free buffer waits
Free buffer waits顾名思义就是data buffer里没有空闲可用buffer，使得当前会话当前进程处于Free buffer wiats等待事件。而oracle这时在做的是DBWR写脏块，清理buffer.为什么会产生这个等待事件？很直接的一个反应是data buffer不够大。这是可能原因之一:原因还有其它如:1.DBWn进程写速度不够快，或触发不够勤快，或有没有使用足够DBWn进程。2.系统本身I/O速度比较慢。3.延迟块清除。4.SQL语句太滥。这么多原因如何判断具体是那个原因导致这个等待事件？如果Buffer cache size不够大。有可能所有buffer都在使用中，且没有dirty buffer可写
-
编辑 删除
我为什么要写等待事件的学习笔记
写等待事件的学习笔记写博客时我是诚惶诚恐!因为一来，我写的学习笔记不是在自己的私人笔记本里，而是在公开blog上，(虽然不一定会有看众，但毕竟是很多人都有可能看到!)一提到公开，公布于众，让大众来查看，评判，我便惶恐起来。厚积薄发的道理我还是懂的，且深以为然。所以按我的性子，即使我是TOM那样的大师，如果要把自己对oracle的一些看法和理解公布于众，我也会三思而行，宜少不多宜精不滥，能省则省。二来我毕竟不是什么大师，不是高手，只是一个中级菜鸟,且我深信山外有山楼外有楼，个人有能力是很有限的，更何况我这个庸人!那我
-
编辑 删除
Buffer busy waits
Buffer busy waits 等待事件表示当前在等待中的会话想操作的buffer 正在被别的会话占有使用或正在被别的会话读入到buffer中。所以要等待别的会话使用完后释放这个buffer。产生这个等待事件的原因很多。我就挑二个主要和常见的原因讲述我的见解。第一种数据块在buffer中，被其它会话占有进行DML操作，导致后面的会话大量buffer busy waits等待。解决办法1.减少每一个块的row数。a.修改pctfree参数.重建对象，把pctfree参数值增加，注：增加后与pctused的差不要太近，如果这个差太小会造成free_list的竟争。如把pctfree设为49 pctused为50，
-
编辑 删除
等待事件之log篇
Log buffer space 表示会话正在进行把UGA中redo entries 复制到log buffer中，但是log buffer里没有可用的空间，(在当前设置下lgwr写速度跟不上产生速度过快的日志量)所以等待log buffer中的可用空间。这时系统等待log buffer清理，以便释放buffer。也就是等待触发lgwr进行redo entries 写操作的事件。可能原因是1。log buffer size 不妥当2。lgwr写性能有问题，一些原因导致写的速度比较慢。解决办法1。加大log buffer。注没必要把log buffer设的太大，具体size看系统是不是很忙。一般系统不是特大特忙的系统1M左右或以这个基础上稍微调整
