Recently in Oracle摘 Category

发展与壮大

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语言重新写就这一版本。出于移植性的考虑，Bruce 向 Miner 推荐 C 语言，要知道，C语言当时推出不久，用它来写ORACLE软件也是具有一定的风险的，尽管 Miner 不是很赞同，但除此之外，别无选择。很快就证明了这样做是明智之举：C 编译器便宜而又高效，移植性相当的好。用C重写 Oracle 的大部分工作由 Bruce 承担，而 Miner 精力主要仍放在 PDP 汇编上。从这个版本开始，ORACLE产品有了一个关键的特性：[可移植性]。ORACLE第3版还推出了SQL语句和事务处理的"原子性"--SQL语句要么全部成功，要么全部失败，事务处理要么全部提交，要么全部回滚。ORACLE第3版还引入了非阻塞查询，使用存储在"Before Image File"中的数据来查询和回滚事务，从而避免了读锁定（read lock）的使用（虽然通过使用表级锁定限制了它的吞吐量）。同样是1983年，IBM发布了姗姗来迟的Database 2（DB2），但只可在VMS上使用。不管怎么说，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操作系统上。回过头来看，在 Oracle V2 发布之后，VAX 已经抢占了本属于 PDP 的大部分市场，要赢得先机，就必须尽快的让 Oracle 支持 VAX 。最初 Oracle 跑在 VAX 的模拟模式下，效果不佳，所以移植 Oracle 到 VAX 平台是必须要面对的事情。早在1979年公司就已经雇了一位DEC公司的技术高手Robot Brandt进行VAX上ORACLE的开发。开始的时候资金有限，只能到加州大学伯克利分校去蹭机器进行开发，后来好一些，但机器也是借来的。尽管困难重重，Brandt还是比较成功的完成了移植工作。随着VAX小型机的大量销售乃至供不应求，ORACLE软件也成为VAX上最受欢迎的程序。这一点要归功于Larry对市场的先知先觉。如果说，是IBM引领着ORACLE公司走上数据库的大船，那么DEC公司的VAX就是带着他们扬帆出海了。短短的几年之后，ORACLE数据库被移植到各种主要平台之上。ORACLE产品也一直因为有可移植性这个关键特性而被那些潜在的客户关注。

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

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

1984 年 4 月，Oracle 拿到了 Sequoia Capital (红杉资本) 的投资。同年10月，发布了第4版产品。从第四版开始，产品的稳定性总算得到了得到了一定的增强，用Miner的话说，达到了"工业强度"。但是还不够令 人满意，用户对产品的抱怨似乎永无休止。这一版增加了读一致性（Read Consistency），这是数据库的一 个关键特性，可以确保用户在查询期间看到一致的数据。也就是说，当一个会话正在修改数据时，其他的会话将看不到该会话未提交的修改。可以看到，在 ORACLE第四版之前，产品始终是不稳定的，但是ORACLE的销售人员，尤其是Ellison，他在宣传ORACLE的时候总是不乏夸大其词，但他就 是有能力把软件卖出去，而且，还卖得很好，不得不承认，这的确有些神奇。

让我们看看1984年软件市场的情形，在数据库市场上的霸主是Ashton-Tate公 司，他们的拳头产品是刚推出不久的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版还支持分布式查询(distributed queries)，允许通过一次性查询访问存储在多个位置的数据。

那是在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也快撑不住了。公司下大力气整顿财务（财务主管杰夫·沃克，Jeff Walker ，从某种程度上解救了公司）。公司宣布削减开支，裁退大量销售人员，同时聘用了专门的管理人才，Jeff Henley（CFO) 与 Raymond Lane (COO) 加盟 Oracle。

噩梦延续到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希望借此来抵制微软的强势，彼时 Windows 95 刚刚发布，风头正健。很快，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) 的最终协议。历时十八个月的争斗终于尘埃落定。

--EOF--

UTF8 will not be updated anymore when new Unicode versions are released, only AL32UTF8 and AL16UTF16 will.

Due to compatibility problems with pre-9i versions use UTF8 if you have Oracle8i clients connecting to the database. Use AL32UTF8 in pure Oracle9i environment.

UTF-8 encoding is variable-width. In UTF-8, each character can be represented by either one, two, or three bytes.

UTF8 is a varying width 1-3 bytes per character Unicode encoding. It is supported for both database and national character sets. It is a binary superset of US7ASCII. UTF8 corresponds to Unicode CESU-8 encoding.

AL32UTF8 is a varying width 1-4 bytes per character. It is supported for CHAR, VARCHAR2, LONG and CLOB only (database character set). It is a binary superset of UTF8 (in 9.2 only) and US7ASCII. AL32UTF8 corresponds to Unicode UTF-8 encoding.

This is what Metalink says. In Note: 237593.1

There is a possible problem for 817 and lower versions: Problems connecting to AL32UTF8 databases from older versions 8i and lower.

The default UTF8 characterset for 9i/10G is AL32UTF8, however this characterset is NOT recognised by any pre-9i clients/server systems.

Oracle recommends that you use UTF8 instead of AL32UTF8 as database characterset if you have 8i (or older) servers and clients connecting to the 9i/10g system until you can upgrade the older versions.

UTF8 is unicode revision 3.0 in 8.1.7 and up. AL32UTF8 is Unicode 3.0 in 9.0.1, Unicode 3.1 in 9.2, Unicode 3.2 in 10.1 and Unicode 4.01 in 10.2

Besides the difference in Unicode version the "big difference" is that AL32UTF8 has build in support for "Surrogate Pairs" (also known as Surrogate characters or "Supplementary characters").
Practically this means that in 99% of the cases you can use UTF8 instead of AL32UTF8 without any problem.

There are only a few situations where Surrogate Pairs are already used on client side. Windows system with HKSCS2001 (hong kong extension) is one of those. Note that you actually can *store* Surrogate Pairs in UTF8 but will store 2 * 3 byte characters and not like AL32UTF8 one 4 byte character.

Note that if you now use UTF8 as database characterset and -in the future you do a roll out of new 9i or higher clients and all your other databases are upgraded to 9i or higher, you can simply do a alter database characterset to go from UTF8 to AL32UTF8 so downtime will be limited to a few minutes if the need to go to AL32UTF8 should arise. There is no performance impact on staying on UTF8

NOTE:
This note is ONLY relevant if you have already a 9i AL32UTF8 database with data in. If you still need to create the 9i system then choose UTF8 instead of AL32UTF8 as database characterset in the database creation assistant.

So, *IF* you have already a 9i system running with AL32UTF8 then you can use the following steps in this note to change the database characterset to UTF8 without losing data.

You can't simply use "ALTER DATABASE CHARACTERSET" to go from AL32UTF8 to UTF8 because UTF8 is a SUB-set of AL32UTF8 (some codepoints which are correct in AL32UTF8 are not known in UTF8)

But again, UTF8 *contains* all characters know in AL32UTF8, the difference between them is pure the way some characters are stored (AL32UTF8 is a bit more efficient for some characters)

So you will run into ORA-12712 if you try alter database ...

Quote from : http://songhefei.itpub.net/post/7281/473958

据说今天是光棍节，逢年过节，必有大事。快下班的时候，一位朋友碰到了一个大问题，数据库服务器异常断电重启以后，数据库无法启动，报ora-600[4000]错误，尝试了使用隐藏参数，还是无法打开。

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []

从ora-600内部错误的类型可以看到，4000是trasaction undo相关的内部错误。搜索一下可以发现，logzgh同学已经两次碰到过该问题了(第一次，第二次)。看来在异常宕机的情况下，这个问题出现的机率还是比较高的。既然是有先例的，恢复起来应该是没有问题的，这个案例和logzgh的第一个案例基本一样，trace文件里显示也是obj$上有异常事务:

ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1

将trace文件往下翻，可以看到出现问题的block的dump信息，在block的itl中果然有一条活动事务存在。用bbed找到对应块，设置offset到61，将itl的flag从20改为80，重新计算block的checksum并apply。然后尝试重新启动数据库，这次ora-600[4000]错误没有了，报的是ora-600[2662]错误，数据库无法open。2662就比较容易了，网上相关的处理案例已经一大堆了，将数据库启动到mount状态，设置10015事件来调整scn即可

alter session set events '10015 trace name adjust_scn level 1';

如果数据库已经处于open状态，则可以使用如下语句来调整SCN:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

再次重新打开库，报ora-600[2256]，继续使用10015事件，这次level设置为(ora-600错误的第三个参数+1)*4

alter session set event '10015 trace name adjust_scn level 20';

重启，报ora-600[4097]错误，好了，现在基本上恢复已经接近尾声了，使用下面几个隐藏参数，可以正常将数据库打开了。接下来就是告诉朋友做全库export/重建库/import了。

_allow_resetlogs_corruption=true
_allow_terminal_recovery_corruption=true
_corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$,
 _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

年关将近，事故高发时期，阿弥陀佛，多求个平安吧。话说这个案例还没来得及些写呢，晚上回家的路上又接到说有人truncate了一张表。。。

　　阿里巴巴成立于1999年，是中国最大的电子商务公司，它拥有的互联网用户遍布全球，成立之初只有18人。现在该公司在中国、香港、台湾、日本、韩国、英国和美国等国家和地区已拥有2万多名员工。

　　阿里巴巴走向成功离不开人力资本战略。阿里巴巴一直在努力推进企业价值观和员工素质的融合发展，为不同类型的员工提供不同的职业发展通道和广阔的成长空间，不断满足企业战略发展所需。

　　为了充分发挥人才的价值，更好地管理人力资本，进而提升组织关键能力和核心竞争力，阿里巴巴组织IT 和管理方面的专家进行了人力资源管理的咨询论证，并经过广泛市场调研和严密选型，选择了PeopleSoft HCM软件构建统一的e-HR平台。

　　在甲骨文合作伙伴毕博管理咨询公司的协助下，阿里巴巴实施了核心人力资源管理(Core HR)、薪资与福利管理、电子绩效管理、培训管理等诸多模块，并与财务管理等系统实现了充分集成与全面整合，构建统一规范的e-HR平台，为集团提供了人员信息和组织信息的单一可信数据源，并可与其他系统进行分享。由此，阿里巴巴在全球化背景下的人力资本的理念、价值观体系及相关活动项目都得以充分推行和落实。

　　借助PeopleSoft HCM软件，阿里巴巴成功将e-HR平台推广到包含港台和海外子公司在内的所有子公司，所有分支机构能同时开展人力资源管理工作，实现了整个集团的人力资 源工作流程规范化和自动化，显著提高了人力资源管理的精确性和工作效率，并从容应对了企业员工人数从2000人到2万多人的急剧扩张、业务高速发展、组织 机构和人员全面改制重组的巨大挑战。

　　此外，利用PeopleSoft HCM 电子绩效管理模块，阿里巴巴构建了一个集团统一标准的全过程跟踪绩效管理平台，显著提高了绩效和评估等工作的时效性和可靠性，同时通过全新的绩效考核机制 提升了员工的企业价值观绩效，并通过对人力资源数据的智能分析为管理层战略决策提供了有效支撑。

　　更重要的是，在本次部署PeopleSoft HCM软件中，阿里巴巴通过自主创新不断对新平台进行调整，完善和丰富系统功能，取得了让新平台更加适应集团发展需求的重要成功，如在将原来的一家公司拆 分为集团子公司架构的组织重组过程中，集团内部不断磨合沟通，寻求最佳解决办法，最终圆满完成了架构调整、流程设置、人员配置等。

　　甲骨文高管及客户相关引言

　　阿里巴巴集团e-HR资深经理宗鸣表示："通过实施基于PeopleSoft 人力资源解决方案的e-HR 平台，阿里巴巴的人力资源政策制度和统一流程在整个集团得到了更加有效无误的贯彻，人力资源部门的员工也从事务性的工作中逐步被释放出来，帮助我们实现了'让人力资源管理实践更加开放简单'的目标。"

　　甲骨文公司大中华区人力资本管理业务发展总监叶天禄表示："人才是一个企业保持持续快速发展的关键资本，发现人才、管理人才并给予其符合企业业 务发展所需的技能、发掘人才潜力，成为了每个企业的管理之重。作为同类最佳的人力资本管理软件，Oracle PeopleSoft 企业人力资本管理(HCM)软件，可帮助企业通过对人进行投资而使其增值并创造新的价值，增强企业核心竞争力。"

　　甲骨文公司副总裁及大中华区管理软件业务总经理潘杰君表示："甲骨文全面、开放、集成的应用软件解决方案适用于所有规模的不同行业企业，并为这 些企业提供了全方位的选择。借助甲骨文业界领先的应用软件产品和解决方案，我们致力于帮助更多的客户优化企业绩效，实现显著的业务增长。"

ora-600[25012]错误的本质原因是因为oracle在构造一致读的过程中发现undo block的rdba不对了，说到底还是因为块的损坏，解决方法就是往前递增全库的SCN，使oracle不产生一致读就可以了。当然，如果这个块已经坏的面目全非，那上述这种方法也不一定行。

我们来看一下我构造的这个例子：

SQL_testdb>drop table t1;

Table dropped.

SQL_testdb>create table t1(id number,name varchar2(10));

Table created.

SQL_testdb>insert into t1 values(1,'cuihua1');

1 row created.

SQL_testdb>insert into t1 values(2,'cuihua2');

1 row created.

SQL_testdb>commit;

Commit complete.

SQL_testdb>select * from t1;

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

这么改：

1、  递增上述两条记录所在的itl的commit SCN;

2、  修改上述两条记录所在的itl的undo block的RDBA；

改完后ora-600[25012]如期而至：

SQL_testdb>select * from t1;

select * from t1

              *

ERROR at line 1:

ORA-00600: internal error code, arguments: [25012], [11], [971], [], [], [],

[], []

此时的解决方法很简单----就是递增全库的SCN不让oracle产生一致读就可以了。

递增完全库的SCN后可以看到ora-600[25012]已经不复存在：

SQL_testdb>select * from t1;

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

ORA-600 [25012] "Relative to Absolute File Number Conversion Error"

Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:
  This article discusses the internal error "ORA-600 [25012]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.

ERROR:
  ORA-600 [25012] [a] [b] [c]

VERSIONS:
  versions 8.0 and above

DESCRIPTION:

  We are trying to generate the absolute file number given a tablespace
  number and relative file number and cannot find a matching file number
  or the file number is zero.

ARGUMENTS:
  Arg [a] Tablespace Number
  Arg [b] Relative file number
  Arg [c] Absolute file number (This arg is present is more recent releases)

FUNCTIONALITY:
  KERNEL FILE MANAGEMENT TABLESPACE COMPONENT

IMPACT:
  POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:        

  The possibility of physical corruption exists.

  Obtain the trace files and alert.log for this error and log a Service Request
  with Oracle Support Services for diagnosis.

  If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
  that can cause this error.

  The following query list fake indexes :

  select a.*,b.flags from dba_objects a, sys.ind$ b
  where a.object_id = b.obj#
  and bitand(b.flags,4096)=4096;