DBA日记(第二部).doc

DBA日记第二部?前言部分-老白学RAC?(1) 3 1.1.?单机升级到RAC 7 1.1.1.?4月14日?各怀心思的研讨会 7 1.1.1.?5月19日?令人目瞪口呆的方案 10 1.1.1.?6月20日?令人沮丧的实验 13 1.1.1.?6月21日?好事多磨 17 1.1.1.?7月1日?一身冷汗 20 1.1.?经常宕机的RAC系统 26 1.1.1.??3月2日?上海的紧急故障 26 1.1.2.?3月3日?上海第一天 30 1.1.3.?3月4日?决定 39 1.1.4.?3月5日?平安无事了 44 1.1.5.?后记 47 1.1.6.?本章技术要点讲解 48 1.1.?EAI系统的性能问题 52 1.1.1.?3月6日?紧急求援 52 1.1.2.?3月7日?典型的RAC性能问题 55 1.1.3.?3月8日?继续优化 59 1.1.4.?后记 62 1.1.?奇怪的RAC性能问题 63 1.1.1.?8月4日?系统告急 63 1.1.1.?8月5日?分析的方法 68 1.1.1.?8月6日?extent?pre-allocation 72 1.1.?好的方法是成功的一半 74 1.1.1.?8月8日?又宕机了 74 1.1.1.?8月9日?求人不如求自己 79 1.1.1.?8月9日夜?定位故障 86 1.1.1.?8月10日?及时雨 90 1.1.1.?后记 94 1.1.?爱刨根问底的客户 97 1.1.1.?8月15日?奇怪的性能下降 97 1.1.1.?8月16日?系统级的调整 101 1.1.1.?8月17日?继续优化 111 1.1.?外来的和尚好念经 120 1.1.1.?4月25日?一封邮件引发的事端 120 1.1.1.?4月27日?突生变故 123 1.1.1.?4月29日?Richard?Warham 127 1.1.1.?5月1日?在家聊天 132 1.1.1.?5月8日?危机再现 135 1.1.1.?5月12日?Richard的180度大转弯 139 1.1.1.?5月13日?系统扩容 141 1.1.1.?5月14日?Richard请客 144 1.1.1.?6月1日?新的起点 147 1.1.1.?6月7日?孤独的唱反调的人 150 1.1.1.?6月8日?ITL等待引发的RAC性能问题 152 1.1.2.?6月9日?ORA-8104 154 1.1.1.?6月15日?又陷危机 156 1.1.1.?6月16日?IO负载均衡 158 1.1.1.?6月18日?按下葫芦浮起了瓢 161 1.1.1.?6月19日?实施优化 163   DBA日记第二部?前言部分-老白学RAC?(1) RAC的时候RAC还叫OPS，OPS翻译成中文就是ORACLE并行服务器，不过那个时侯DBA还是喜欢把OPS叫做ORACLE CLUSTER。老白对CLUSTER的认识来自于DEC公司???VAX CLUSTER，VAX CLUSTER是一种十分优秀的集群系统，在集群里的任何一个资源（文件、磁盘、端口、设备，等等）只要被设置为CLUSTER资源，那么这个资源就可以在整个CLUSTER中共享。VAX CLUSTER这种古老但是十分优秀的技术现在已经基本上快消亡了，不过VAX CLUSTER技术给了老白很多误导，认为CLUSTER就应该是这样的，不过随着DEC的灰飞烟灭，我们看到20年后的今天，UNIX上的CLUSTER还只能做到VAX CLUSTER的一小部分功能。15年前，老白开始使用ORACLE数据库的时候，绝大多数客户对CLUSTER的认识还停留在HA层面上，当时最常用的词汇是双机热备和双机冷备这个概念，这两种技术都被宣传为CLUSTER技术，所不同的是双机热备就是我们现在所认知的RAC，而双机冷备就是我们现在常说的HA系统。早期老白接触CLUSTER系统的时候，实际上客户对ORACLE CLUSTER???要求只是基于热备和冷备的需求，而不是来自于性能和可扩展性方面的需求。那时候的数据库往往较小，一般在几百M到10多个G，而且应用系统也比较简单，因此系统在性能上的问题较少，DBA的主要工作就是帮助客户安装ORACLE系统，当然OPS的安装是这中间技术含量最高的了。 早期的OPS系统安装十分复杂，需要在操作系统上打打大量的补丁，进行复杂的配置，因此OPS系统的安装一般会选择购买原厂的服务，ORACLE的销售一般会把OPS的安装说成是一个和阿波罗登月一样复杂的工作，因此敢于不购买原厂安装服务的客户少之又少。说实在的，不要说是OPS系统，早期的ORACLE系统安装也十分复杂，老白曾经帮客户安装过ORACLE 5.1 FOR OPENVMS，介质存储在266M???磁带上，从磁带上将安装