ORACLE公司之起源

很难想象，ORACLE公司的这一段传奇居然要从IBM开始。

1970年的6月，IBM公司的研究员埃德加·考特 （Edgar Frank Codd） 在 Communications of ACM 上发表了那篇著名的《大型共享数据库数据的关系模型》（A Relational Model of Data for Large Shared Data Banks）的论文。这是数据库发展史上的一个转折。要知道，当时还是层次模型和网状模型的数据库产品在市场上占主要位置。从这篇论文开始，拉开了关系型数据库软件革命的序幕。

虽然早在1970年就诞生了关系模型理论，但是市场上迟迟不见关系型数据库管理软件的推出。主要原因是很多反对者认为关系型数据库速度太慢，比不上当时的层次式数据库。值得好笑的是，IBM虽然1973年就启动了System R的项目来研究关系型数据库的实际可行性，也没有及时推出这样的产品，因为当时IBM的的IMS（著名的层次型数据库）市场不错，如果推出关系型数据库，牵涉到IBM很多人的自身利益。再者，IBM庞大复杂的官僚机构处在决策上远不那么灵活。

1977年6月，Larry Ellison与Bob Miner和Ed Oates在硅谷共同创办了一家名为软件开发实验室（Software Development Laboratories，SDL）的计算机公司（ORACLE公司的前身）。那个时候，32岁的Larry Ellison，这个读了三家大学都没能毕业的辍学生，还只是一个普通的软件工程师。公司创立之初，Miner是总裁，Oates为副总裁，而Ellison，因为一个合同的事情，还在另一家公司上班。没多久，第一位员工Bruce Scott（用过ORACLE数据库软件的人都知道有个Scott用户的吧？没错，就是这个Scott，至于Scott用户的密码Tiger，那是Scott养的猫的名字）加盟进来，在Miner和Oates有些厌倦了那种合同式的开发工作后，他们决定开发通用软件，不过们还不知道自己能开发出来什么样的产品。Oates最先看到了埃德加·考特的那篇著名的论文连同其他几篇相关的文章并推荐Ellison和Miner也阅读一下。Ellison和Miner预见到数据库软件的巨大潜力（跟着IBM走，没错），于是，SDL开始策划构建可商用的关系型数据库管理系统（RDBMS）。

图1 左起 Ed Oates、Bruce Scott、Bob Miner、Larry Ellison

很快他们就弄出来一个不太像样的产品，或者具体的说，更像一个Demo。根据Ellison和Miner他们在前一家公司从事的一个由中央情报局投资的项目代码,他们把这个产品命名为ORACLE。因为他们相信，ORACLE（字典里的解释有“神谕, 预言”之意）是一切智慧的源泉。1979年，SDL更名为关系软件有限公司（Relational Software，Inc.，RSI），毕竟“软件开发实验室”不太像一个大公司的名字。1983年，为了突出公司的核心产品，RSI再次更名为ORACLE。

图2 美国 Oracle 公司总部一瞥

发展与壮大

RSI在1979年的夏季发布了可用于DEC公司的PDP-11计算机上的商用ORACLE产品，这个数据库产品整合了比较完整的SQL实现，其中包括子查询、连接及其他特性。但不得不说，软件不是很稳定，并缺少事务处理这样的重要功能。出于市场策略，公司宣称这是该产品的第二版，但却是实际上的第一版。之所以被命名为第2版而不是第1版，是因为Ellison认为潜在的客户更愿意购买第2个版本，而不是初始版本。（虽然这样做有些不太诚实，还是要承认这是个十分高明的技巧。到现在还有一些公司把自己卖给客户的版本叫做1.0 ，学学1979年的ORACLE吧！）多年以后的今天，ORACLE公司声称是他们第一个提供了第一个SQL关系型数据库管理系统。

虽然软件不是很好，但是客户还是有的。美国中央情报局迫不及待的想买一套这样的软件来满足他们的需求。但在咨询了IBM公司之后发现IBM没有可以商用的产品，他们联系了RSI。于是RSI有了第一个客户。在当时，政府和军方的机构往往同时有几种计算机，而那时还没有什么“软件可移植”这样的说法，当然，也几乎没有具有这样的能力的应用软件。也就是说，给PDP-11开发的ORACLE数据库不能用在IBM主机和DEC的VAX上。很快用户就表现出来这样的需求：ORACLE能否同时在不同的操作系统上运行？这给RSI带来了新的挑战（主要是Miner和Scott）。70年代末期和80年代早期的软件一般都设计成在单一操作系统上运行，具有可移植能力的软件很少。

1983年3月，RSI发布了ORACLE第三版。Miner和Scott历尽艰辛用C语言重新写就这一版本。要知道，C语言当时推出不久，用它来写ORACLE软件也是具有一定的风险的，但除此之外，别无他法。很快就证明了这样做是多么的正确:C编译器便宜而又有效，还有很好的移植性。从现在起，ORACLE产品有了一个关键的特性：[可移植性]。ORACLE第3版还推出了SQL语句和事务处理的“原子性”–SQL语句要么全部成功，要么全部失败，事务处理要么全部提交，要么全部回滚。ORACLE第3版还引入了非阻塞查询，使用存储在“Before Image File”中的数据来查询和回滚事务，从而避免了读锁定（read lock）的使用（虽然通过使用表级锁定限制了它的吞吐量）。同样是1983年，IBM发布了姗姗来迟的Database 2（DB2），但只可在MVS上使用。不管怎么说，ORACLE已经占取了先机。

在开发第三版还没有结束的时候，Scott离开了ORACLE。当时用C语言改写ORACLE的压力很大，无休止的软件调试终于让Scott不堪重负，选择了一走了之。把剩下的重担交给了Miner一个人。在出售了自己的%4的股票之后，Scott 后来创建了Gupta公司（现更名为Centura Software）和PointBase公司（提供百分之百纯Java嵌入式数据库），都是开发和数据库相关的产品。多年后有人问到他的%4的ORACLE股票的时候，Scott，这个曾经给ORACLE写出第一行代码的技术高手，也只能报以一笑了。如果能坚持下来，那是一笔几亿美金的财富。不过当时的Scott没有那么多的想法，他只是太累了。

图3 Bruce Scott 现在是PointBase公司的创办者之一

ORACLE最先将其软件移植到DEC VAX计算机上的VMS操作系统上。早在1979年公司就已经雇了一位DEC公司的技术高手Robot Brandt进行VAX上ORACLE的开发。开始的时候资金有限，只能到加州大学伯克利分校去蹭机器进行开发，后来好一些，但机器也是借来的。尽管困难重重，Brandt还是比较成功的完成了移植工作。随着VAX小型机的大量销售乃至供不应求，ORACLE软件也成为VAX上最受欢迎的程序。这一点要归功于Larry对市场的先知先觉。如果说，是IBM引领着ORACLE公司走上数据库的大船，那么DEC公司的VAX就是带着他们扬帆出海了。短短的几年之后，ORACLE数据库被移植到各种主要平台之上。ORACLE产品也一直因为有可移植性这个关键特性而被那些潜在的客户关注。

Oates这个时候因为婚姻趋于破裂而情绪沮丧，已经不能把精力全部放到公司上，不得不离开公司。几年后，他又重返公司，重新为ORACLE做出巨大的贡献，他许下诺言，在公司员工超过1万人的时候会再度离开。1999年，他完成了心愿。现在他正在纵情于音乐，自得其乐。

很长一段时间里，公司研发由Miner独力承担。Miner视金钱如无物，为人低调，和Ellison的锋芒必露形成鲜明的对比。在公司里，大家一致认为他是老好人，他也深受员工爱戴。Ellison是公司的大脑，Miner则当之无愧的成为公司的心脏。他是个沉默的英雄，正如Steve Jobs背后的Steve Wozniak一样。

1984年10月，ORACLE发布了第4版产品。产品的稳定性总算得到了得到了一定的增强，用Miner的话说，达到了“工业强度”。但是还不够令人满意，用户对产品的抱怨似乎永无休止。这一版增加了读一致性（Read Consistency），这是数据库的一个关键特性，可以确保用户在查询期间看到一致的数据。也就是说，当一个会话正在修改数据时，其他的会话将看不到该会话未提交的修改。可以看到，在ORACLE第四版之前，产品始终是不稳定的，但是ORACLE的这群销售人员，主要是Ellison，他在宣传ORACLE的时候总是要夸大其词，但他就是有能力把软件卖出去，而且，还卖得很好，不得不承认，这的确有些神奇。让我们看看1984年软件市场的情形，在数据库市场上的霸主是Asnton-Tale公司，他们的拳头产品是刚推出不久的dBase III（确切的说dBase是PC上的数据库软件霸主），刚刚成为全球第三大的独立软件公司（第一和第二分别是微软、Lotus，ORACLE在当时还排不上号），这一年，也是苹果公司Macintosh诞生的年度，Steven Jobs用这个拳头产品挑战老大哥IBM。同样在这一年中，ORACLE公司的开发人员刚刚把产品移植到PC上。这是最好的年代，也是最坏的年代。数以千计的小公司在软件领域里争斗不休，新公司如雨后春笋般成立，ORACLE如何才能于不败之地？

在1985年，ORACLE发布了5.0版。有用户说，这个版本算得上是ORACLE数据库的稳定版本。这也是首批可以在Client/Server模式下运行的的RDBMS产品，在技术趋势上，ORACLE数据库始终没有落后。这意味着运行在桌面PC机（客户机）上的商务应用程序能够通过网络访问数据库服务器。1986年发布的5.1版还支持分布式查询，允许通过一次性查询访问存储在多个位置的数据。

那是在1985年，当时曾经的最大的独立软件公司Cullinet(主要销售网状数据库)已经如流星般陨落。ORACLE的主要竞争对手是Ingres数据库。Ingres在加州大学伯克利分校诞生，主要的设计者是当时鼎鼎大名的Michael Stonebraker教授。可以说Ingres数据库软件是上个世纪80年代技术上最好的数据库，Ingres市场分额的快速增长已经给ORACLE早成了很大的压力。巧的是，这个时候，IBM公司再一次伸出“上帝之手”。

Ingres使用的是Stonebraker 发明的QUEL（Query Language））的查询技术，这和IBM的SQL大不相同。在某些地方QUEL甚至要优于SQL。IBM当时担心Ingres把QUEL变成标准会对自己不利。经过一番衡量，决定把自己的SQL提交给数据库标准委员会。而Stonebraker教授可不打算把QUEL提交给数据库标准委员会，学院派的他认为这麽做实际上是扼杀了创新精神。鹬蚌相争，渔翁得利。ORACLE看到并抓住了这个绝佳的机会，大肆宣布ORACLE全面与SQL兼容，加上ORACLE当时对Ingres PC上的版本的攻击（弱化对手优势，化解自己弱势是他们最拿手的本领），再加上ORACLE公司销售上的强势，Ingres不断丢城失地，等到后来推出支持SQL的数据库的时候为时已晚。紧跟IBM让ORACLE得以成长、壮大，拥抱标准，拥抱开放，拥抱变化，让ORACLE立于不败之地。

1986年3月12日，ORACLE公司以每股15美元公开上市，当日以20.75美元收盘，公司市值2.7亿美元。3月13日，微软以每股21美元的发行价上市，以28美元收市，公司市值达到7亿美元。远远超过了ORACLE。成功的光环的微软和盖茨遮盖住了ORACLE和Ellison的光芒，可能这也是Ellison敌视微软的开始。

图4 桀骜不驯的Larry Ellison

经受挫折

ORACLE第6版于1988年发布。由于过去的版本在性能上屡受诟病，Miner带领着工程师对数据库核心进行了重新的改写。引入了行级锁（row-level locking）这个重要的特性，也就是说，执行写入的事务处理只锁定受影响的行，而不是整个表。这个版本引入了还算不上完善的PL/SQL（Procedural Language extension to SQL）语言。第6版还引入了联机热备份功能，使数据库能够在使用过程中创建联机的备份，这极大地增强了可用性。同时在这一年，ORACLE开始研发ERP软件。

公司发展看上去比较顺利，不过，噩梦才刚刚开始。

由于过去对软件测试重视的程度不够–那个时候公司规模小，基本上都是客户帮助免费测试的。在第六版刚发布之后，很多迫不及待开始使用的用户就怨声载道。这是个根本就没有测试好就进行发布的产品（也怪Ellison，大话总要说在前头，只好自尝苦果）。用户开始对ORACLE大肆抨击，ORACLE的一些对手也开始落井下石，针对ORACLE产品的一些弱点进行攻击。开发人员一面应付愤怒的用户，一面加班加点地对程序进行接连不断的修正，最后，总算得到了一个比较稳定的版本，暂时平息了用户的愤怒。

但是，实际的问题并不在这里，几年来高速增长的同时也给公司带来了巨大的隐患，1990财年第三季度报表的公布引爆了一切。财务人员发现了1500万美元的坏帐，并且公司利润距离预期相差甚远。接下来的时间里，大公司病的诸般症状接踵而来，面对股东的指控，股票一落千丈，公司前景暗淡，甚至面临破产。一度靠贷款来维持自己的奢华生活也不变卖股票的Ellison也快撑不住了。公司下大力气整顿财务（财务主管杰夫·沃克从某种程度上解救了公司）。公司宣布削减开支，裁退大量销售人员，同时聘用了专门的管理人才。

噩梦延续到ORACLE第七版的推出而结束。这个公司已经空谈了好几年的新版本（一度被讥讽为不过是Ellison的故计重施而已），直到1992年6月才终于闪亮登场，这一次公司吸取了第六版匆忙上市的教训，听取了用户的多方面的建议，并集中力量对新版本进行了大量而细致的测试。该版本增加了许多新的性能特性：分布式事务处理功能、增强的管理功能、用于应用程序开发的新工具以及安全性方法。ORACLE7还包含了一些新功能，如存储过程、触发过程和说明性引用完整性等，并使得数据库真正的具有可编程能力。还有一点必需要说明的是，这个版本在原有的基于规则的优化器（RBO）之外引入一种新的优化器：基于开销的优化器（Cost-Based Optimizer ,CBO）。CBO根据数据库自身对对象的统计来计算语句的执行开销，从而得出具体的语句执行计划。在以后的几个重大版本中，ORACLE的工程师们逐步对这个优化器进行改进，CBO逐渐取代了RBO。

ORACLE 第七版是ORACLE真正出色的产品,取得了巨大的成功。这个版本的出现真是好时机，当时Sybase公司的数据库已经占据了不少份额，ORACLE借助这一版本的成功，一具击退了咄咄逼人的Sybase。公司的销售人员这次算到了给用户兑现空头许诺的时候。公司经过两三年的治理，终于摆脱了种种麻烦，重新开始健康发展，销售额也从92年的15亿美元变为四年后的42亿美元。

跨上巅峰

“搅浑水”是Ellison的一项绝技。在1995年巴黎举行的欧洲信息技术论坛会议上，Ellison在即兴演讲中介绍了网络计算机（Network Computer，NC）的概念,所谓NC指的是配置简单却能充分利用网络资源的低价电脑，最为重要的是，它不需要操作系统，或者更准确的说，不需要微软的操作系统。Ellison希望借此来抵制微软的强势。很快，ORACLE联合IBM、Sun、Apple和Netscape在1996年制定了网络计算机的标准，但事实上人们从头到尾没有看到一台真正的NC生产出来。这次的演讲在业界引起了轩然大波，通过这个事件，ORACLE公司吸引了足够多的注意力，同时也让人们看到ORACLE公司对于网络的巨大信心。

1997年6月，ORACLE第八版发布。ORACLE8支持面向对象的开发及新的多媒体应用，这个版本也为支持Internet、网络计算等奠定了基础。同时这一版本开始具有同时处理大量用户和海量数据的特性。这个版本也算可圈可点了。

1998年9月，ORACLE公司正式发布ORACLE 8i。“i”代表Internet，这一版本中添加了大量为支持Internet而设计的特性。这一版本为数据库用户提供了全方位的Java支持。ORACLE 8i成为第一个完全整合了本地Java运行时环境的数据库，用Java就可以编写ORACLE的存储过程。对，Java，只要是能够打击微软的武器，ORACLE都要派上用场。ORACLE8i 添加了SQLJ（一种开放式标准，用于将SQL数据库语句嵌入客户机或服务器Java代码）和ORACLE interMedia（用于管理多媒体内容）以及XML等特性。同时，ORACLE 8i 极大程度上提高了伸缩性、扩展性和可用性以满足网络应用需要。接下来的几年中，ORACLE陆续发布了8i的几个版本，并逐渐添加了一些面向网络应用的新特性。面对开源运动的蓬勃发展，ORACLE自然不甘落后，1998年十月ORACLE发布了可用于Linux平台的ORACLE 8 以及ORACLE Application Server 4.0，随后不久，ORACLE又发布了ORACLE 8i for Linux。在 .com大潮中，ORACLE是站在风口浪尖的弄潮儿。

在2001年6月的ORACLE OpenWorld大会中，ORACLE发布了ORACLE 9i。在ORACLE 9i的诸多新特性中，最重要的就是Real Application Clusters（RAC）了。说起ORACLE集群服务器，早在第五版的时候，ORACLE就开始开发ORACLE并行服务器（ORACLE Parallel Server ，OPS），并在以后的版本中逐渐的完善了其功能，不过，严格来说，尽管OPS算得上是个集群环境，但是并没有体现出集群技术应有的优点。在完全吸收了Rdb（ORACLE在1994年收购了Compaq公司的Rdb数据库，此前Rdb属于DEC公司，DEC公司在VAX上实现了第一个可以商用的Rdb集群数据库）的一些技术优势之后，ORACLE终于推出了真正的应用集群软件。RAC使得多个集群计算机能够共享对某个单一数据库的访问，以获得更高的可伸缩性、可用性和经济性。ORACLE 9i的RAC在TPC-C的基准测试中打破了数项记录，一时间业内瞩目。这个新的数据库还包含集成的商务智能（BI）功能。ORACLE 9i第2版还做出了很多重要的改进，使ORACLE数据库成为一个本地的XML数据库；此外还包括自动管理、Data Guard等高可用方面的特性。

历史还在继续

2003年9月8日，旧金山举办的ORACLE World大会上，Ellison宣布下一代数据库产品为“ORACLE 10g”。ORACLE应用服务器10g（ORACLE Application Server 10g）也将作为甲骨文公司下一代应用基础架构软件集成套件。“g”代表“grid ,网格”。这一版的最大的特性就是加入了网格计算的功能。何谓网格计算？网格计算可以把分布在世界各地的计算机连接在一起，并且将各地的计算机资源通过高速的互联网组成充分共享的资源集成。通过合理调度，不同的计算环境被综合利用并共享。ORACLE宣称10g可以作为网格计算的基础，矛头直指最大的敌人IBM的“随需应变”！看来，ORACLE公司已经把这一次的“赌注”押在了网格计算的大市场上。但前景如何？让我们拭目以待。

如果说，IBM是IT产业中的一头巨鲸，那么ORACLE一定就是一条大鲨鱼：咄咄逼人，善于进攻。就在2003年6月初，ORACLE突然宣布51亿美金收购仁科（PeopleSoft），业内再次震动。此举又一次露出ORACLE 一贯善于进攻的本性。要知道，ORACLE在发展过程中很少对企业进行收购的，那么收购仁科目的何在？首先，ORACLE觊觎企业应用软件市场已久，但苦于不能进一步扩大市场分额，尤为重要的是，一旦成功，可以直接对最大的敌人IBM进行打击，还可以阻击SAP等巨头的强势。时至今日，ORACLE依然以不达目的不罢休的态势和仁科缠斗，结果如何，让我们拭目以待。

“人生最大的快乐是击败敌人”，Ellison一定很喜欢这句话。

后记：2004年12月13日，Oracle公司宣布签订了以每股26.50美元、总计约103亿美元的代价收购 仁科(PeopleSoft) 的最终协议。历时十八个月的争斗终于尘埃落定。

补：2009年4月Oracle斥资74亿美金收购伟大的SUN（公司，这样Oracle不但有了自己的数据库（Oracle ,MySQL),操作系统（Solaris，OEL），硬件（SPARC  Scalable Processor Architecture架构的平台），还有JAVA。至此，Oracle一路高歌猛进，引领IT领域！从硬件存储，到操作系统，应用软件，中间件，以及后台数据库，各个领域都拥有自己的产品线，同IBM，Microsoft各家IT巨头相抗衡！我相信只要拽住Ellison的衣角，搭乘Oracle这艘巨轮，在IT行业定能平步青云！！！

———-End———-Original from http://www.dbanotes.net/Oracle/History_about_Oracle_company.htm

modified by Asher Huang.

Oracle是什么? 是一个管理数据的软件系统, 很重要, 和结婚前的恋人差不多, 此篇献给不懂Oracle的本站读者, 很早时写过一两篇的, 但站点被黑因此全丢了.

Oracle Standby, 有一颗红心, 两种或多种准备, 万一一个恋爱谈崩了, 马上移到下一个. 从Primary切到Standby一般是不太愿意的, 放弃第一个而取第二个, 同样也是不太愿意的. 备用的一开始不需要很细心的照顾, 稍微留点心, 就可以保持了, 出问题时努力一下就成了Primary了. 如果出了问题就得重新建立了.

Oracle Dataguard, 其实和Standby一样, 只是关系更密切一些, 需要投入更多一点的资源, 需要切换成Primary时更省力一些而已, 但还是有主从之分的.

Oracle RAC, 这就比较花心了, 可以说成脚踩两只或多只船, 可能分不清楚主从关系. 所需要代价也是比较高的, 所以有钱的人才上RAC, 中国特别多, 政府部门大都喜欢上RAC系统. 但不容易管理, 常出问题, 上RAC系统比较能满足心里要求. 加减节点同样是件非常不容易的事.

Oracle Tuning, 调优就是让人开心了. 一个节点时只调一边就行了. RAC时可能需要调所有的节点, 还常关系到资源的分配问题, 经常是因为资源问题让整个RAC系统跑不起来的, 现实生活中更是如此了. 而Dataguard和Standby上的调优则比较简单, 没有多少可以调的地方. 调优的关键是要知道问题所在, 让人开心的关键也是知道对方需要什么, 并不是增加的资源越多, 系统就越好的.

Oracle Recovery, 就是修复破损关系了, 有时会遇到不能修复的情况, 就只能放弃选择重建了.

如果你的对方懂Oracle, 可以适当用用这些术语了.

—–Derived From http://www.anysql.net/life/oracle_before_marry.html

How to backup the Oracle Control File ?

There are two approaches: you either generate a binary image of the Control File, or you generate a text file script which will re-generate a Control File when run as a SQL script.

To create the binary image, issue the command ALTER DATABASE BACKUP CONTROLFILE TO ‘C:\SOMEWHERE\CONTROL01.BKP’; (obviously pick a destination and file name that are suitable for your needs).

To create the text script version, issue the command ALTER DATABASE BACKUP CONTROLFILE TO TRACE. That causes a file to be written to wherever your init.ora parameter USER_DUMP_DEST is pointing. The file name will be something like ‘ora_<some numbers>.trc’. You’ll have to track it down using the O/S date and timestamp (or you can take advantage of the fact that the “some numbers” bit is your Server Process ID Number -which you can determine from v$session and v$process).
The binary image is ready to work from the word go (with one hugely important proviso, of which more below).

The trace file is, however, a bit of a mess, and needs to be knocked into shape if it is to be of any use in a recovery situation. Firstly, it contains a whole heap of junk at the top (referencing your O/S, your Oracle version, dates and times and process or thread numbers). That’s got to go -which means deleting all of it, until the first line reads STARTUP NOMOUNT. Immediately before that line, you need a connect string, since you can’t ever issue the ‘startup’ command until you’ve connected as a Privileged User. Insert something appropriate, therefore (such as CONNECT / AS SYSDBA if using O/S authentication, or CONNECT SYS/ORACLE AS SYSDBA if using Password File Authentication). You may possibly also need to qualify the ‘STARTUP NOMOUNT’ line itself so that it references an appropriate init.ora (for example, STARTUP NOMOUNT PFILE=/SOMEWHERE/NON-DEFAULT/INIT.ORA). Other than that, the file is fine, and useable.

Under no circumstances should you ever need a backup of your Control File, of either type. You’d only use one if ALL copies of the Control File had become corrupt or had been destroyed (and the whole purpose of multiplexing your Control Files is to minimise those possibilities). But if that fateful day ever arrives, then you simply need to fire up Server Manager (or SQL Plus if using 8i or above), and issuing the command to run the trace file script (i.e., typing @name_of_script.ext). There’s no need to connect first -remember, that was the first line we added to the script earlier. If for some reason the Instance is already running, the script will fail -it needs a completely shut down system before it can do its stuff.

The trouble starts when you attempt to restore the binary version of the Control File backup. Because it was an exact, binary copy of a Control File, its SCN number will not agree with the SCN in the headers of all the data files -basically, the Master Clock is out of whack. You therefore have to issue the command “RECOVER DATABASE USING BACKUP CONTROLFILE;” to tell the system not to pay too much attention to the SCN of the Control File. Unfortunately, after you issue that command (and following any recovery that it might cause to take place), you must open the database with the command “ALTER DATABASE OPEN RESETLOGS;”.

That’s unfortunate, because the ‘resetlogs’ command basically forces the entire database to re-synchronise at time zero, which is fine for getting the database open, but is not exactly useful if you ever need to restore from your prior backups (taken when the database was at a time of, say, 10894329), or if you ever expect to be able to apply redo from priot archive logs (which were also taken when the database was at time 10894329 and earlier). Basically, a ‘resetlogs’ renders your database entirely vulnerable: there are no effective backups, and no effective archives. You are therefore supposed to immediately shut the newly-recovered database down, and perform a whole, closed backup of the entire database (which is not exactly a cheap option).

You might wonder why the use of the trace file does not cause this HUGE problem.  The answer is simple: it cheats. Contained within the trace file are locations of every data file in the system. When the file is run, it uses those locations to read the headers of all the data files, whereupon it picks the highest SCN it comes across as the one to write into the header of the Control File it is about to create. That means the re-constructed Control File is already in synchronisation with the data files, and no forced synchronisation to time Zero is therefore required.

So, what’s the best way of backing up the Control File? Answer: multiplex your Control Files so that a recovery is never needed in the first place. But if, despite that, you need some insurance, the Trace File is definitely the better way to go.  It doesn’t render your entire database exposed to failure, it doesn’t effectively trash all prior backups and archives, it works quickly, and well.

There’s only one proviso to this whole discussion: whatever backup method you choose, you need to keep it up-to-date.  Since the Control File contains pointers to the physical location of all data files and redo logs, any backup of that file needs to make sure that those pointers are accurate. Making a physical change to your database (for example, adding a new data file or tablespace, dropping a tablespace, moving or renaming a data file) will instantly render all prior Control File backups out-of-date.  Slightly unnervingly, changing a tablespace from read-write to read-only (or vice versa) also counts as a physical change to your database (because the Control File must always accurately identify any read-only data files).  After any of those operations, therefore, you need to take a fresh backup of the Control File.

It is always conceivable that you could edit a Trace File backup before using it to take account of any physical changes, but the syntax is not easy, and I don’t rate your chances of pulling it off. As for editing the binary copy -forget it!  Net result: keep taking the backups on a regular basis.  I usually recommend a chron job (for our NT friends, that’s an AT job!) which issues the ‘backup to trace’ command every night. It means you need a bit of house-keeping to avoid complete mayhem (and a million trace files) in the user_dump_dest, but it will guarantee a file which, at worst, can be used with the mere addition of a line or two to reference any data files created between the time the trace file was created and the time all Control Files went awol.

Note:How to backup the control file to trace ?

1.SQL>alter database backup controlfile to trace;
Database altered.
2.SQL>show parameter USER_DUMP_DEST;
…………..
3.SQL>select spid from v$process p,v$session s
where p.addr=s.paddr
and s.status=’ACTIVE’
and s.username=’SYS’;

4.Then goto the USER_DUMP_DEST directory (we get it on step 2),view the file named  ora_<SID>_<spid>.trc .It’s contents are what we needed.After modified the file,we can use it to recreate a new controlfile.

—-End