1.3.5  LIBRARY CACHE和CURSOR    LIBRARY CACHE也是SHARED POOL的一个子HEAP（SUBHEAP），和ROW CAHCE相比，LIBRARY CACHE更为复杂，存放的数据也更为复杂。在分析LIBRARY CACHE的内部结构之前，首先我们要了解一下LIBRARY CACHE中有哪些主要的对象,LIBRARY CACHE中的OBJECT TYPE包括:· Cursor

点击此处查看原文

1.9.6 从数据块结构看目前主流容灾技术谈到容灾平台，很多DBA总是觉得离自己好远。容灾系统也许真的看不到启用的那一天了。记得有一次和几个朋友在四川意外碰到，一起喝酒。朋友中有一位是以前在某省邮储搞容灾的，就说起现在的容灾平台，真正能启用的恐怕不到一半。我那个哥们表示不信，他觉得当年他们搞容灾系统的时候是很认真的，而且有专人管理，定期演练，是必须确保能够立马切换的。也许我碰到的客户都不是金融行业的，容灾建设比较马虎。正说着这个事情，我接到一个客户的电话，这个客户是金融行业的，他们接到上级部门的通知，要搞容灾演练。在切容灾系统的时候，发现容灾系统的一套10g的Oracle 数据库启动不起来了。后来这个问题解决了，其实也很简单，他们容灾环境是采用IBM的

点击此处查看原文

1.3.4  ROW CACHE从KGH(HEAP MANAGEMENT）的角度来看，ROW CACHE是共享池的一个SUBHEAP。ROW CACHE到底存放了什么信息呢？通过下面的一个简单的SQL，我们来看看ROW CACHE里到底有些什么内容：SQL> SELECT PARAMETER,SUM(COUNT) FROM V$ROWCACHE  GROUP BY PARAMETER ORDER BY SUM(CO

点击此处查看原文

1.3.3 共享池的SUB POOL技术共享池的SUB POOL技术是Oracle  9i才开始具有的。SUBPOOL技术解决了较大的共享池在并发访问方面的性能问题。在Oracle  8i和以前的版本中，共享池是没有SUBPOOL的，整个共享池的分配和释放都由一个共享池闩锁进行串行化控制。在这种结构下，共享池的分配和释放可能成为一个瓶颈，当大并发量的共享池分配释放请求存在的时候，共享池闩锁这个瓶颈点就十分明显了，因此引入SUBPOOL的概念是十分必要的。Oracle 共享池的SUBPOOL充分利用了大型SMP系统多

点击此处查看原文

3.2.10 DBA需要与时俱进Oracle 数据库的技术发展很快，这一点对于一个Oracle  DBA来说，是既痛苦有幸福的事情。最近这十多年，Oracle 公司基本上以每5年一个新版本的速度发展着。记得2004年在做一个优化项目的时候，和几个搭档讨论Oracle 发展的问题，其中一个人说他已经从7.0干到8i了，8i是他学习的最后一个版本了，9i是坚决不学了。不过没多久，我们又接了一个9i的优化项目，于是我看到他的房间里又多了几本9i的书籍。这回他再次向我发誓，9I将是他职业生涯中学习的最后一个

点击此处查看原文

1.2.8 使用KEEP POOL能改善CBC争用吗？使用KEEP POOL能否改善cache buffers chains闩锁争用？这个问题是多年前DBA界广有争论的一个话题。那时候大家对DB CACHE的内部结构的认识还处于比较初级的阶段，大家都认为KEEP POOL能够改善cache buffers chains的争用。随着大家对DB CACHE内部结构的了解，对HASH CHAINS和LRU CHAINS的内部结构的认识，有一些DBA提出了一个论断，就是启用KEEP POOL仅仅改变了LRU CHAINS的结构，对于HASH CHAINS并无影响。KEEP POOL启用后，在LRU CHAINS结构中，多了一个KEEP POOL LRU CHAINS的链，所有的KEEP POOL的CACHE都属于一个DB CACHE中的子池，这个池中的BUFFER HEAD都链在不同的链上，其AGE OUT算法也和DEFAULT POOL不同。不过无论LRU CHAINS如何变化，都不影响到HASH CHAINS的结构。某

点击此处查看原文

大家可能都碰到过CACHE BUFFER CHAINS闩锁竞争。可能大多数朋友碰到这个闩锁竞争都会想到 热块争用（HOT BLOCK），其实不尽然。正如我们前面几节所讨论的，CACHE BUFFER CHAINS是串联DB CACHE的HASH CHAIN，而HASH CHAIN是和DB BLOCK的寻址有关的。当某个DATA BLOCK被装载到DB CACHE中的时候，根据RDBA的HASH值，找到一个HASH CHAIN，获取要访问这个HASH链的CACHE BUFFER CHAINS子闩锁，然后把BUFFER HEAD连接到这个HASH CHAIN中。如果要查找某个DATA BLOCK，也会首先根据RDBA的HASH值找到这个HASH CHAIN，然后在链上搜索。因此，如果出现严重的

点击此处查看原文

本小节介绍和DB CACHE相关的数据库参数、等待事件、系统统计信息、闩锁和相关诊断视图等信息。目的是让读者能够对DB CACHE及相关的数据库组件有一个总体的认识。由于篇幅的关系，本节仅这些参数和等待事件做简单的介绍。DB CACHE相关的参数如下：参数名称

点击此处查看原文

1.2.5 检索某个DB BLOCK的模拟算法很多朋友都在研究检索数据块的内部算法，不幸的是oracle公司并没有公开这个算法，而且这是Oracle 数据库性能的最核心技术之一，这部分算法是永远也不可能公开的。老白根据这些年对Oracle 内部原理的研究，编写了一段伪代码，通过这段伪代码来向各位读者展示一下DB CACHE管理的一些算法的细节。这个伪代码只能够模拟DB CACHE管理的一些皮毛，可能在实现细节上，Oracle 的内部原理要复杂得多。下面首先我们来看看这段伪代码。main(){

点击此处查看原文

1.2.4 DB CACHE的几个主要的链和CKPT算法    DB CACHE中有很多重要的链，这些链或者和DB CACHE的分配、换出、刷新优化，或者和DB BLOCK的查找有关。下面我们先来了解这些链的基本情况，然后我们来探讨一下这些链在各种DB CACHE活动中所起的作用。LRU list 和LRU-AUX list

点击此处查看原文

1.2.3 DB_WRITER_PROCESSES参数对于绝大多数系统，只要IO能力足够并且DB CACHE足够大，那么一般情况下，单个DBWR进程基本上是能够胜任的。不过对于IO十分敏感的系统，使用多个DBWR进程有助于提高脏数据块写的性能。从Oracle 8.0开始（严格的说是8.0.4），DBWR的算法发生了革命性的变化。Oracle 7虽然也支持多个DB WRITER进程，但是这些DB WRITER 进程之间是有区别的，其中一个是MASTER，其他几个是SLAVER。SLAVER进程是不能使用异步IO的，只能使用模拟的异步IO。从Oracle 8.0.4开始，DBA可以使用2种策略来配置DBWR，一种是单个DBWR进程加上多个IO SLAVER进程；另外一种方法是配置多个DBWR进程。不论是使用DBWR还是IO SLAVER，都可使用异步IO。这种改进大大提高了数据库写IO的性能。

点击此处查看原文

1.2.2 DB CACHE的分配和DBWR的相关算法在DB CACHE的算法中，数据库启动之初，空闲的CACHE都是在LRU链上的。前台进程需要分配DB CACHE的时候，从LRU

点击此处查看原文

1.2.1 什么是DB CACHEDB CACHE是十分复杂的，很多DBA都想了解一下DB CACHE到底是怎么构成的。事实上从Oracle发展了那么多年来看，DB CACHE的变化是十分大的，不过虽然DB CACHE的管理算法一直在变化，不过其基本原理没有发生太大的变化。在本节中，我们就简单探讨一下DB CACHE的一些基本结构和原理，但是本文不是DB CACHE的一个完整的描述，只是通过一些DB CACHE的知识点，让DBA了解DB CACHE的一些基本面貌和算法。首先，DB CACHE是由一系列共享内存组成的，是在SGA中统一分配的一个组件。SGA管理的共享内存区域是通过类似SHMGET,SHMAT等UNIX系统调用获取的。根据操作系统的不同以及操作系统参数设置的不同，SGA可能是经过多个共享内存申请获取到的内存的总和

点击此处查看原文

1.2 理解DB CACHEDB CACHE是Oracle 数据库中对性能影响最大的组件，优化DB CACHE也是一个DBA最基本的职责。搞过软件开发的人都知道，缓冲区是提高性能的十分好的机制，DB CACHE的存在主要是为了提高会话访问数据文件中的数据的效率。Oracle 的DB CACHE

点击此处查看原文

3.1.2 工作中的好习惯带来的福利在本节开始的时候我先提一个问题，如果说客户的ORACLE安装目录满了，发现udump下有好多几百M甚至上G的trace文件，而这个时候，客户的存储上没有空闲空间让你备份这些文件了，而且情况十分紧急，已经有业务受到了影响，希望能够尽快解决问题，这种情况你该怎么处理？

点击此处查看原文

3.1.1 为什么要强调基础概念从我学习Oracle 的成长经历，我得到一个十分重要的经验，那就是从普通DBA成长为专家、高手，其中一个十分重要的一环就是对基础概念的理解和精确掌握。当然我所说的精确掌握，并不是要求每个DBA都把Oracle 的源代码读一遍，了解其十分内部的处理模式和方法。你可以了解的不那么深入，但是你必须十分精准的掌握所学的知识。10多年前，我是靠经验来处理问题的，那时候互联网也不是十分普及，除了METALINK，也

点击此处查看原文

1.1.4 多实例数据库多实例数据库的概念同样经常让DBA感到迷惑，多实例数据库可以说是RAC的另外一种称呼。ORACLE RAC的特点就是多个数据库实例可以同时打开相同的数据库，进行并发的操作。多实例数据库是Oracle 高可用架构和高可扩展性架构的核心技术，多个实例同时打开数据库进行读写，可以避免某个实例故障导致的系统不可用，同时多实例实现负载分担，也可以减轻某个实例的工作负载，从而提高整体吞吐能力。Oracle  RAC

点击此处查看原文

1.1.3 什么是数据库实例    在实际的开发应用中，关于Oracle数据库，经常听见有人说建立一个数据库，建立一个Instance，启动一个Instance之类的话。其实问他们什么是数据库，什么是Instance，很可能他们给的答案就是数据库就是Instance，

点击此处查看原文

前些天和老熊关于这个案例讨论了一下（此老熊是四川的老熊，非DBA日记中的老熊），感觉这个案例的分析过程中确实有很多不确定的东西，简单归结为CPU_COUNT的问题也确实存在证据不足的问题，因此本节将会在正式的书籍中删掉，我会选用一个其他的案例补上 前些天客户有个数据库经常性出现短暂的HANG住现象，有时候时间很短，业务部门刚刚投诉，去检查的时候就已经好了。所以也就没有引起重视，不过这几天，HANG住现象越来越严重，白天业务高峰期间，三天两头会出问题，最严重的一次，整个CRM系统HANG住了10多分钟，严重影响了营业窗口的工作。因此客户找到我们，希望我们能够帮助分析一下，到底是什么原因。客户的数据库是9.2.0.8的单节点的系统，操作系统是AIX 5.3 TL 08。应用系统是CRM，最近并没有进行过任何的改造升级，客户基本上排除

点击此处查看原文

南美丛林的一只蝴蝶煽动翅膀，可能导致莫斯科下大雪，说明的大气系统的复杂性。而DBA在日常工作中叶经常会面临类似的问题，我们从故障的表象上分析问题处理问题，而往往我们采取的措施仅仅是解决一些表象的问题，并没有找到问题的关键。也就是说，我们并没有抓到扇翅膀的那只蝴蝶，而仅仅抓住了莫斯科上空的乌云。前几天碰到一个案例，写出来和大家共享。客户有一套系统下午1点多的时候，突然出现了故障，服务无法响应，新会话连不上去。最后只能通过杀掉了大量的会话，才恢复正常。客户想找到问题的原因。找到我的时候已经是下午的4点多了。出现故障的时段有大量这样的信息：Mon Apr 11 12:52:24 2011Errors in file /oracle/app/oracle/admin/sjz

点击此处查看原文