发展与壮大

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了一张表。。。

　　谁对中国20-40岁女性的身材(三围)最了解?这个人不是别人，而是阿里巴巴的老大马云----他只要下个命令，让数据挖掘工程师把淘宝某段时间内20-40岁女性购买相关商品的数据汇总，再做个简单的挖掘，答案就放在那了。

　　2010年以来，随着凡客、京东与苏宁易购这两类B2C电商的崛起，国内掀起了又一次B2C电商的热潮，与以往的电商热不同，这次电商热的主流 参与者是众多传统企业。面对这种局面，淘宝祭出了建立2年却不温不火的淘宝商城，将其独立拆分运营，旨在吸引更多传统大中企业来此安家落户，而不要自己做 独立电商。

　　但是很显然，淘宝商城是拦不住数以万计、十万甚至百万计的大中小型传统企业最终做独立B2C的趋势的。而且，接下来还会有更多的凡客、京东杀出来。这种趋势是会让马云睡不着觉的，因为这种趋势发展下去，会把淘宝王国一点一点解构掉。

　　为了让自己能睡着觉，马云拿出了一个用他自己的话说是"要让百度睡不着觉"的对策，也就是一淘。一淘的底子实际上是原来淘宝的站内搜索，拆分独立后嫁接了全网搜索尤其是电商网站产品页抓取的技术。一淘的推出，标志着马云第一次大张旗鼓地把触角伸到了非阿里--淘宝体系的独立电商领域。一淘对于马云 来说绝不仅仅是个电商搜索工具，从战略上说，他是希望一淘最终能成为中国电子商务网站的搜索、导航门户。如果能做到这点，纵使独立电商的大潮如何汹涌，马 云都可高枕无忧。

　　但是事情却没那么顺利。一淘一推出就毁誉参半，京东等大型的独立B2C网站首先表示将用技术手段封杀一淘的抓站蜘蛛或爬虫。一淘想从包括京东在内的大小独立电商网站获得什么?京东等抵制一淘的网站捍卫的又是什么?答案很简单：数据。

　　如果你问我马云旗下这些公司最有价值的是什么，我的答案也是：数据。如今很多互联网企业对数据重视程度不断提高，但多数其他互联网企业的数据，其价值都无法与阿里巴巴所掌握的数据相提并论。

　　这里我们回想一句马云在2008年2月的"冷预言"：冬天来了，准备过冬吧。这句话在莺歌燕舞的2008年冒出来，几乎所有的人的反应都是：这是疯人疯语。

　　但令人意想不到的是，半年多后，大洋彼岸就传来了美国次贷危机进而引发全球金融危机的消息。马云为什么能如此先知先觉?答案跟本文开篇部分那个 半开玩笑的问题一样，马云不仅能从淘宝数据知道中国女性的身材情况，他同样能通过阿里巴巴的数据知道海量中小企业的经营状况，甚至能部分地知道美欧等国当 地居民消费力水平的变化。把这些数据结果跟不断恶化的次贷危机趋势一叠加，他就很容易地成了"先知"了。

　　如今业界对阿里巴巴旗下公司的标准描述是：阿里巴巴是中国最大的B2C平台;淘宝是国内最大的C2C平台;支付宝是中国最大的互联网第三方支付工具;拆分出来的淘宝商城有望成为国内最大的B2C平台;而一淘的目标则是成为基于商品搜索的网购门户。

　　把上面描述的加在一起等于什么?等于阿里巴巴通过旗下的各项业务积累了海量网民网购行为特征数据、众多商家的基本交易数据。然后呢?如今中外很多互联网公司手上也都掌握着很多数据，但是，我们也没有看到什么真正的奇迹发生。

　　马云你能创造奇迹吗?如果把阿里系所掌握的所有数据，再配以先进的数据挖掘技术，阿里巴巴将从一个B2B、B2C、C2C交易平台变身成为一家 超级商业智能(BI)企业。从很早开始，阿里内部就建立了强大的数据挖掘部门，其掌握的数据挖掘技术在国内互联网行业内应是数一数二的;其次，今年上半 年，阿里巴巴悄然收购了作针对中小网站流量统计的CNZZ，此举目的很明确，那就是把百万量级的中小网站的数据也逐步整合到阿里的数据体系中。而且，这些 数据不仅仅是部分中小电商网站的数据，更多是海量网民在众多网站间的行为数据。

　　如果这就是马云秘而不宣的下一个梦想，那么一淘的出现就已经暴露了他的新野心。

　　阿里巴巴成立于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;

In this Document
Symptoms
Changes
Cause
Solution
References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 - Release: 10.2 to 10.2
Information in this document applies to any platform.

Symptoms

In some cases queries against the ALL_SYNONYMS view are slower after upgrading to 10.2.0.x
For example:

SELECT /*+ RULE */ COUNT(*)
FROM
ALL_SYNONYMS WHERE OWNER='PUBLIC' AND SYNONYM_NAME='&1'

Oracle 10g Release 10.2:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       81      0.02       0.00          0          0          0           0
Execute     81      0.05       0.09          0          0          0           0
Fetch       81    355.93     371.05          0   45269282          0          81
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      243    356.00     371.15          0   45269282          0          81

Oracle 9i Release 9.2:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       81      0.02       0.02          0          0          0           0
Execute     81      0.04       0.01          0          0          0           0
Fetch       81      0.03       0.01          0        810          0          81
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      243      0.09       0.05          0        810          0          81

Changes

Changed to a version higher than 9.2 from 9.2 or below.

Cause

10g release 10.1.0.5, 10.2.0.1 and above contain a new view definition for ALL_SYNONYMS which is the result of a fix to an outstanding defect. This defect meant that certain synonyms would not be displayed when selecting from ALL_SYNONYMS. To fix the defect a new, more complex, ALL_SYNONYMS was required and as a side affect queries that select against the new ALL_SYNONYMS definition have much more complicated execution plans and may be more expensive when compared to execution plans in earlier versions (such as 9.2).
For example:

Compare the execution plan for ALL_SYNONYMS queries in 10046 trace file in 10.2 and in 9.2, to confirm execution plan is more resource consuming in 10.2 :

In 9.2 execution plan is :

Rows     Row Source Operation
-------  ---------------------------------------------------
1  SORT AGGREGATE
1   FILTER
1    NESTED LOOPS
1     NESTED LOOPS
1      TABLE ACCESS BY INDEX ROWID USER$
1       INDEX UNIQUE SCAN I_USER1 (object id 41)
1      TABLE ACCESS BY INDEX ROWID OBJ$
1       INDEX RANGE SCAN I_OBJ2 (object id 34)
1     TABLE ACCESS BY INDEX ROWID SYN$
1      INDEX UNIQUE SCAN I_SYN1 (object id 98)
0    FILTER
0     NESTED LOOPS
0      NESTED LOOPS
0       TABLE ACCESS BY INDEX ROWID USER$
0        INDEX UNIQUE SCAN I_USER1 (object id 41)
0       TABLE ACCESS BY INDEX ROWID OBJ$
0        INDEX RANGE SCAN I_OBJ2 (object id 34)
0      INDEX RANGE SCAN I_OBJAUTH1 (object id 100)
0     FIXED TABLE FULL X$KZSRO
0    FIXED TABLE FULL X$KZSPR

In 10.2 execution plan is :

Rows     Row Source Operation
-------  ---------------------------------------------------
1  SORT AGGREGATE (cr=558882 pr=0 pw=0 time=4326033 us)
1   VIEW  ALL_SYNONYMS (cr=558882 pr=0 pw=0 time=4325993 us)
1    SORT UNIQUE (cr=558882 pr=0 pw=0 time=4325988 us)
1     UNION-ALL  (cr=558882 pr=0 pw=0 time=4325909 us)
1      FILTER  (cr=10 pr=0 pw=0 time=185 us)
1       NESTED LOOPS  (cr=10 pr=0 pw=0 time=173 us)
1        NESTED LOOPS  (cr=7 pr=0 pw=0 time=136 us)
1         TABLE ACCESS BY INDEX ROWID USER$ (cr=3 pr=0 pw=0 time=56 us)
1          INDEX UNIQUE SCAN I_USER1 (cr=2 pr=0 pw=0 time=39 us)(object id 41)
1         TABLE ACCESS BY INDEX ROWID OBJ$ (cr=4 pr=0 pw=0 time=77 us)
1          INDEX RANGE SCAN I_OBJ2 (cr=3 pr=0 pw=0 time=48 us)(object id 34)
1        TABLE ACCESS BY INDEX ROWID SYN$ (cr=3 pr=0 pw=0 time=31 us)
1         INDEX UNIQUE SCAN I_SYN1 (cr=2 pr=0 pw=0 time=17 us)(object id 98)
0       FILTER  (cr=0 pr=0 pw=0 time=0 us)
0        FILTER  (cr=0 pr=0 pw=0 time=0 us)
0         NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
0          NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
0           TABLE ACCESS BY INDEX ROWID USER$ (cr=0 pr=0 pw=0 time=0 us)
0            INDEX UNIQUE SCAN I_USER1 (cr=0 pr=0 pw=0 time=0 us)(object id 41)
0           TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)
0            INDEX RANGE SCAN I_OBJ2 (cr=0 pr=0 pw=0 time=0 us)(object id 34)
0          INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us)(object id 100)
0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us)
0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
0      NESTED LOOPS  (cr=558872 pr=0 pw=0 time=4325697 us)
0       NESTED LOOPS  (cr=558872 pr=0 pw=0 time=4325692 us)
7        NESTED LOOPS  (cr=558849 pr=0 pw=0 time=4325568 us)
1         TABLE ACCESS BY INDEX ROWID USER$ (cr=3 pr=0 pw=0 time=25 us)
1          INDEX UNIQUE SCAN I_USER1 (cr=2 pr=0 pw=0 time=15 us)(object id 41)
7         VIEW  _ALL_SYNONYMS_TREE (cr=558846 pr=0 pw=0 time=4325543 us)
7          CONNECT BY WITHOUT FILTERING (cr=558846 pr=0 pw=0 time=4325527 us)
7           FILTER  (cr=279521 pr=0 pw=0 time=1848969 us)
18            COUNT  (cr=279323 pr=0 pw=0 time=1505655 us)
18             NESTED LOOPS  (cr=279323 pr=0 pw=0 time=1143804 us)
25717              NESTED LOOPS  (cr=201352 pr=0 pw=0 time=1113824 us)
27395               NESTED LOOPS  (cr=148330 pr=0 pw=0 time=925979 us)
69679                NESTED LOOPS  (cr=51254 pr=0 pw=0 time=487918 us)
958                 TABLE ACCESS FULL USER$ (cr=233 pr=0 pw=0 time=2996 us)
69679                 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=51021 pr=0 pw=0 time=431685 us)
69679                  INDEX RANGE SCAN I_OBJ2 (cr=3216 pr=0 pw=0 time=80937 us)(object id 34)
27395                TABLE ACCESS BY INDEX ROWID SYN$ (cr=97076 pr=0 pw=0 time=697424 us)
27395                 INDEX UNIQUE SCAN I_SYN1 (cr=69681 pr=0 pw=0 time=425927 us)(object id 98)
25717               TABLE ACCESS BY INDEX ROWID USER$ (cr=53022 pr=0 pw=0 time=309207 us)
25717                INDEX UNIQUE SCAN I_USER1 (cr=27305 pr=0 pw=0 time=150664 us)(object id 41)
18              TABLE ACCESS BY INDEX ROWID OBJ$ (cr=77971 pr=0 pw=0 time=598777 us)
26615               INDEX RANGE SCAN I_OBJ2 (cr=51865 pr=0 pw=0 time=371282 us)(object id 34)
7            FILTER  (cr=198 pr=0 pw=0 time=1794 us)
7             NESTED LOOPS  (cr=198 pr=0 pw=0 time=1489 us)
50              NESTED LOOPS  (cr=91 pr=0 pw=0 time=853 us)
7               NESTED LOOPS  (cr=52 pr=0 pw=0 time=414 us)
7                TABLE ACCESS BY INDEX ROWID SYN$ (cr=31 pr=0 pw=0 time=264 us)
7                 INDEX UNIQUE SCAN I_SYN1 (cr=24 pr=0 pw=0 time=179 us)(object id 98)
7                TABLE ACCESS BY INDEX ROWID USER$ (cr=21 pr=0 pw=0 time=126 us)
7                 INDEX UNIQUE SCAN I_USER1 (cr=14 pr=0 pw=0 time=74 us)(object id 41)
50               TABLE ACCESS BY INDEX ROWID OBJ$ (cr=39 pr=0 pw=0 time=320 us)
50                INDEX RANGE SCAN I_OBJ2 (cr=22 pr=0 pw=0 time=215 us)(object id 34)
7              INDEX RANGE SCAN I_OBJAUTH1 (cr=107 pr=0 pw=0 time=596 us)(object id 100)
2             FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=174 us)
18           COUNT  (cr=279325 pr=0 pw=0 time=1440703 us)
18            NESTED LOOPS  (cr=279325 pr=0 pw=0 time=1440701 us)
25717             NESTED LOOPS  (cr=201354 pr=0 pw=0 time=1112712 us)
27395              NESTED LOOPS  (cr=148332 pr=0 pw=0 time=926537 us)
69679               NESTED LOOPS  (cr=51255 pr=0 pw=0 time=487858 us)
958                TABLE ACCESS FULL USER$ (cr=233 pr=0 pw=0 time=2945 us)
69679                TABLE ACCESS BY INDEX ROWID OBJ$ (cr=51022 pr=0 pw=0 time=431397 us)
69679                 INDEX RANGE SCAN I_OBJ2 (cr=3216 pr=0 pw=0 time=80879 us)(object id 34)
27395               TABLE ACCESS BY INDEX ROWID SYN$ (cr=97077 pr=0 pw=0 time=687683 us)
27395                INDEX UNIQUE SCAN I_SYN1 (cr=69681 pr=0 pw=0 time=415512 us)(object id 98)
25717              TABLE ACCESS BY INDEX ROWID USER$ (cr=53022 pr=0 pw=0 time=308614 us)
25717               INDEX UNIQUE SCAN I_USER1 (cr=27305 pr=0 pw=0 time=150815 us)(object id 41)
18             TABLE ACCESS BY INDEX ROWID OBJ$ (cr=77971 pr=0 pw=0 time=591777 us)
26615              INDEX RANGE SCAN I_OBJ2 (cr=51865 pr=0 pw=0 time=363738 us)(object id 34)
7           FILTER  (cr=198 pr=0 pw=0 time=1794 us)
7             NESTED LOOPS  (cr=198 pr=0 pw=0 time=1489 us)
50              NESTED LOOPS  (cr=91 pr=0 pw=0 time=853 us)
7               NESTED LOOPS  (cr=52 pr=0 pw=0 time=414 us)
7                TABLE ACCESS BY INDEX ROWID SYN$ (cr=31 pr=0 pw=0 time=264 us)
7                 INDEX UNIQUE SCAN I_SYN1 (cr=24 pr=0 pw=0 time=179 us)(object id 98)
7                TABLE ACCESS BY INDEX ROWID USER$ (cr=21 pr=0 pw=0 time=126 us)
7                 INDEX UNIQUE SCAN I_USER1 (cr=14 pr=0 pw=0 time=74 us)(object id 41)
50               TABLE ACCESS BY INDEX ROWID OBJ$ (cr=39 pr=0 pw=0 time=320 us)
50                INDEX RANGE SCAN I_OBJ2 (cr=22 pr=0 pw=0 time=215 us)(object id 34)
7              INDEX RANGE SCAN I_OBJAUTH1 (cr=107 pr=0 pw=0 time=596 us)(object id 100)
2            FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=174 us)
0        TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)
0         INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)(object id 33)
0       TABLE ACCESS BY INDEX ROWID SYN$ (cr=0 pr=0 pw=0 time=0 us)
0        INDEX UNIQUE SCAN I_SYN1 (cr=0 pr=0 pw=0 time=0 us)(object id 98)

Solution

There is no resolution to this issue.
In future versions it is possible that this may be addressed but any fix would not be back-portable to previous versions as architechtural changes are required to enable it.

The current ALL_SYNONYMS view's changes and additional explain plan steps are necessary to resolve the original issue with the ALL_SYNONYMS view.

To have similar performance from the ALL_SYNONYMS view on 10g to version 9.2 do the following steps :

1. Create a new view "SYS.ALL_SYNONYMS_920X" with all_synonyms definition from database 920X. The view definition for ALL_SYNONYMS is stored in the $ORACLE_HOME/rdbms/admin/catalog.sql script. To create the new view, login as the SYS user and execute the following:
   connect / as sysdba
create or replace view SYS.ALL_SYNONYMS_920X
(OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK)
as
select u.name, o.name, s.owner, s.name, s.node
from sys.user$ u, sys.syn$ s, sys.obj$ o
where o.obj# = s.obj#
and o.type# = 5
and o.owner# = u.user#
and (
o.owner# in (USERENV('SCHEMAID'), 1 /* PUBLIC */) /* user's private, any public */
or /* user has any privs on base object */
exists
(select null from sys.objauth$ ba, sys.obj$ bo, sys.user$ bu
where bu.name = s.owner
and bo.name = s.name
and bu.user# = bo.owner#
and ba.obj# = bo.obj#
and ( ba.grantee# in (select kzsrorol from x$kzsro)
or ba.grantor# = USERENV('SCHEMAID')
)
)
or /* user has system privileges */
exists (select null from v$enabledprivs
where priv_number in (-45 /* LOCK ANY TABLE */,
-47 /* SELECT ANY TABLE */,
-48 /* INSERT ANY TABLE */,
-49 /* UPDATE ANY TABLE */,
-50 /* DELETE ANY TABLE */)
)
)
/
2. To force users to select from this new view without code modification, a private synonym can be created:

   CREATE SYNONYM username.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_920X 
   

   This is private synonym must be created for any user executing which wants to use the new definition.
   Note that the users could also select from the new definition directly but this would require code references to be changed in the application.

Note that this workaround simply reverts to the previous view definition.It simply provides a workaround to achieve the old performance in the short term.

Having reverted to the previous view definition users may hit Bug:3369744 per which ALL_SYNONYMS does not show all accessible synonyms.

References

BUG:5454590 - SELECT FROM ALL_SYNONYMS AND ALL_OBJECTS IS MUCH SLOWER IN 10.2.0.2
NOTE:364822.1 - Poor Performance On Certain Dictionary Queries After Upgrade To 10g
SR:16161618.6

　　甲骨文的出价合每股43美元,较RightNow周五收盘溢价20%.RightNow股价周一收盘暴涨19.41%至42.94美元.甲骨文收高2.33%报32.87美元.

　　甲骨文正全力进军云技术市场,涉足的领域包括销售能力自动化,人力资源和数据库等系统.

　　"RightNow从甲骨文得到的报价非常优惠,我认为不会有其他公司来抢亲.不会再有这样的估值了."Pacific Crest分析师Brendan Barnicle说.

　 　自1997年RightNow创始人Greg Ginaforte在自家一间空闲卧室中起家,到2010年该公司已经是营收超过1.85亿美元的大公司,并可与更大的同业 SalesForce.com(CRM.N: 行情)和在线营销软件生产商Constant Contact(CTCT.O: 行情)展开竞争.

　　"相信甲骨文收购RightNow将给SalesForce.com的云服务业务带来更直接的竞争和更加难以应付的威胁,"Oppenheimer分析师Brad Reback说.

　　多年来,市场一直传言甲骨文有意收购SalesForce.com来充实自己的云技术实力.另一个可能的收购目标是NetSuite(N.N: 行情),甲骨文执行长埃利森已经部分拥有该公司.

　　但Rick Sherlund认为SalesForce.com并非不二之选,因为甲骨文正尝试拓宽"软件即服务(software-as-a-service)"这一整体业务模式,从而确保能够参与市场的全面竞争.

　　RightNow如果接受其他方提出的更高报价,可能需要向甲骨文支付约6,000万美元的分手费.如果协议在某些条件下告吹,分手费或只需1,800万美元左右.RightNow发言人拒绝对交易进一步置评.

　　甲骨文预期该宗交易将在今年底或明年初完成.

　　会有更多并购交易涌现?

　　分析师表示,甲骨文在过去一年里不断买入资产以弥补云技术服务方面的空白,收购了包括ATG,Inquira和FatWire在内的公司.

　　"这次收购表明,甲骨文对于涉足云技术领域是认真的,"Susquehanna分析师Derrick Wood说,"不过我们认为,它不可能通过自体成长实现这一目标,如果想成为强大的竞争者,就需要借助收购来进入这一市场."

　　分析师估算,甲骨文收购RightNow的价格约占其现金和投资总额的4%.

　　但分析师认为,对小型云计算公司感兴趣的并非只有甲骨文一家,戴尔(DELL.O: 行情),惠普(HPQ.N: 行情)和微软(MSFT.O: 行情)等大型科技企业可能也有兴趣.

　　Pacific Crest的Barnicle表示,收购RightNow的交易对整个行业有利,因为这预示着一波收购热潮将会来临.

　　"我认为客户关系管理领域将继续有并购活动涌现,"Nucleus Research分析师Rebecca Wettemann说.

　　消息披露後,RightNow的同业之一Egain Communications(EGAN.O: 行情)股价一度涨至7.98美元,最终收高10.45%报7.82美元。

1. 电信计费数据的加载

通用数据库大家见的多了，Oracle、Db2、Sqlserver、Sybase、Informix 还有最近比较火的Mysql、和Pqllite，当然还不能忘记开源的PostgreSQL。通常情况下这些数据库可以承担重要业务，但是在要求高性能方面还是略有不足。在计费系统中如果用户信息常常改变的话延迟方面就会产生比较大的影响，甚至能影响到计费系统的正常运行。

我接触到唯一的内存数据库就是亚信在中移动计费中心稽核系统中使用的。由于稽核系统需要实施同步用户状态信息和订购信息，然后对产生的话单进行稽核，如果响应速度 较慢的话就会产生错误的结果。最初没有稽核系统的时候，计费的标准基本是sp发过来的，然而用户方面却经常发现自己没有实际使用或者已经取消这项业务的时 候，自己的帐单中仍然收取了费用，因此中移动决心要对sp的话单进行稽核，以自己的数据为标准，彻底剪断sp乱收费的手段。

如果要取到用户状态信息和订购信息的话就要从多个系统中同步过来，同时对话单进行稽核，中间的处理时间要求比较严格（用户可能会在短时间内检查自己的话费信息），对系统响应时间就要尽量短。

通用数据库在这方面处于劣势。亚信就以三台rx8420作为数据库主机，将31个省用户的信息按照数量的多少分担到三台主机，每个省至少有一个入库进程，对于用户比较多的就采用多个进程进行入库。数据的采集来源主要是通过BOSS和计费的一级系统。

由于数据是存储在内存中，所以存储的数据结构和通用数据库有所差异，同时为了保证数据的安全，在磁盘上有一个内存数据的镜像，每隔一定时间将内存中的数据同步到磁盘上，当主机故障时可以通过磁盘恢复数据。当主机故障时，会有备用主机通过HA接管。但是对于数据操作的日志和回滚就没有Oracle做的好了，只提供了简单的恢复机制。

在计费系统中首先要对sp发来的话单进行稽核，主要标准是用户状态和订购信息。例如用户最近7天一直处于关机状态，如果sp的话单中出现新的订购信息就将此条话单作为错单处理。移动通过这种方式在和sp的博弈中取得主动。稽核系统上线后用户对于sp的投诉问题明显减少。

链接一:内存数据库与传统数据库的异同

传统的数据库系统是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。

对磁盘数据库而言，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间 与估算的最坏情况执行时间相差很大，如果将整个数据库或其主要的"工作"部分放入内存，使每个事务在执行过程中没有I/O，则为系统较准确估算和安排事务 的运行时间，使之具有较好的动态可预报性提供了有力的支持，同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。

内存数据库所处理的数据通常是"短暂"的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无 效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价， 处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。

在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。

链接二:几款内存数据库产品

■ Oracle TimesTen

Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防） 所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。

■ Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管 理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理 能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适 合于有高时效要求的实时系统。

■ eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有 50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合 技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。

"Oracle技术嘉年华"是由ACOUG发起并联合云和恩墨、ITPUB、IT168共同举办的一次数据库界的顶尖盛会。大会持续2天时间，共计28个 主题演讲，邀请到24位中外嘉宾，其中有9位ACE总监（全球仅93位），1位ACE，1为Java Champion，另有多位国内知名专家及Oracle公司高级经理、架构师，阵容十分强大。
会场内座无虚席

ACOUG发起人之一盖国强先生发表题为《创新开放集成-数据库技术的未来》的演讲

Oracle大中华区高级经理韩鄂春（Jack.Han）先生介绍Oracle ACE项目

Dell公司Oracle实验室Kai YU在主会场发表演讲

阿里巴巴运维部DBA，数据架构师张瑞先生发表演讲 - 《软硬件结合数据库解决方案》

oracle-base创始人Tim Hall先生演讲 - Clonedb The quick and easy cloning solution you never knew you had

由于版面限制，我们把更多的内容传到了以下地址，欢迎大家下载：
嘉宾PPT
1、注册新浪微博，关注http://weibo.com/acoug 。我们已将全部的PPT上传至新浪微盘中，您可以分开或整体下载
2、通过http://www.box.net/shared/kr51ck04jhbgjivp4vzv 逐个下载
3、通过ITPUB下载
活动照片
1、注册新浪微博，关注http://weibo.com/acoug 。我们已将全部的照片上传至新浪相册中
2、可通过Google picasa网络相册查看并下载（由于众所周知的原因，访问速度较慢。如果您知道其他储存照片的网络位置，请邮件告知管理员admin#acoug.org，非常感谢！）

我们还要感谢本次活动的赞助商：
云和恩墨

韩国恩核（EN-CORE）公司

Precise

达梦数据库

感谢各赞助商对活动的大力支持与赞助！

感谢各位嘉宾不辞辛劳，为我们分享他们在各自领域的心得及经验！
感谢各位朋友能够抽出宝贵的时间参加会议，你们的参加让我们更有动力组织更多的分享活动！

　　我以为在这时候，他经历了两件足以影响他的事情。第一件事是祖父带他去听大歌剧，一开始他很为那些女演员和布景分心，但慢慢他开始沉浸到音乐里 去了，觉得非常兴奋，激动。祖孙两人非常满足地走在回家的路上，他祖父告诉他这个歌剧的作者是某某人，他一听就大吃一惊，他说这难道是人写出来的吗？我曾 经碰到一个景颇族的孩子，他给我讲他的故事，读中学的时候住在镇上，在一个棺材店里寄宿，每天晚上有个汉族的老师给他们讲故事，他们就坐在棺材板上听，有 一天老师说现在我给你们讲曹雪芹写的《红楼梦》，这个孩子一下子跳起来了，大声问道书是人写的吗？这其实是一个非常动人的蒙昧时期，以为一切存在都是神圣 无上，都是神制造的，从来也没想到人也有机会，也有可能，也有使命承担神的义务。爷爷所说的这个简单的事实使克利斯朵夫感到有一天也会轮到他去做神明而造 物。这是一件于他很重要的事情。

　　第二件重要事情是由于他的舅舅，一个四海为家的小贩，有时会到他们家里小住几天。他们全家除了他母亲都是自视很高的人，父子们都以耍弄舅舅为乐 事。这个舅舅却以非常安详的态度来面对这一切，从来也不生气，只是默默地坐在一边，怀着一种冥冥之中和谁在对话的表情。有一天克利斯朵夫胡闹够了，就开始 卖弄地大声唱他的那些曲子，舅舅静静地听完之后说，可怜的克利斯朵夫，这真是难听啊。他很不服气，又唱另一首更好的，舅舅说这个更难听。舅舅看着他沮丧的 样子，怜悯地问，可怜的克利斯朵夫，为什么要写这样的东西，谁逼着你去写呢？他回答说因为我想成为一个伟大的人。他舅舅又问为什么要成为一个伟大的人呢？ 他说因为我要写好听的东西。他舅舅就说，你这样就像一条追着自己尾巴跑的小狗。这使他想起了他最初在钢琴上按下琴键时候的声音，音乐是这样的，而现在的情 况却是那样的。这两件事情都是在帮助他调整他与音乐的关系，为他的成长奠下基础。

　　他慢慢长大，祖父死了，母亲非常善良，可是她的智商和才能只是一个厨娘，父亲酗酒更加厉害，越来越没理智，两个弟弟都是坏孩子，和他没有话说。 他在这个家庭里非常孤独。而他这样小小年纪也到宫廷里做了一个提琴手，为了能够挣点钱养活撑持这个家庭。他的童年进入了这么一个惨淡的时期。但是他所继承 的血缘是强壮旺盛的，他身体非常棒，经得起折磨，而且非常怕死，渴望生活，所以这一切都不会妨碍他健康地成长，长成一个强壮的孩子。然后，恋爱的时期到 了。

　　他的恋爱走过漫长的道路。首先是一次预演。他有一次去参加一个亲王的Party，在渡船上遇到一个男孩子，名叫奥多。奥多出生在一个中产阶级家 庭，他认出了克利斯朵夫，因为他已经是一个小名人了。克利斯朵夫生来缺少朋友，一下子遇见一个男孩子，而且是个干干净净有礼貌的男孩子，对他那么巴结，自 然非常激动。这两个孩子就开始了比爱情还要热烈的友谊。他们俩在同一个城市里，可是还要互相写信，他们信上写的话比情话还要情话，他们互相称呼对方"我的 灵魂"、"我的我"，说"你来杀我吧，你把我杀死了，我的灵魂还留出一线光明来爱你".因为他们俩的纯洁，这些过火的表达却也并不显得肉麻。其实他们完全 是两种人，只是在这共同的年龄里有一种共同的感情需要，这份需要把他们的眼睛全都蒙住了。他们的关系最终是被克利斯朵夫的两个弟弟破坏的。这是两个很庸 俗，很卑鄙的小子，偷看了他俩的情书，嘲笑他、讽刺他，把他哥哥的这种感情说得非常污浊。克利斯朵夫天性是有洁癖的，他绝不能容忍这种污辱，所以就和奥多 断了关系，这是一次热烈的友谊，其实也是一次爱情的前奏。

　　接着，他得到一次爱情的操练，就是他的初恋。他们家附近的空院子里，有一天搬进了一对贵族母女，母亲是一个寡妇，女儿叫弥娜，和克利斯朵夫一般 大，那位母亲请克利斯朵夫给她女儿做钢琴教师。这个女孩子很骄横，也很无聊，但她也很可爱、娇嫩，喜欢做媚眼，好像为她将来走进社交圈作准备，这些媚眼落 在克利斯朵夫身上自然是产生一些影响了。有一次克利斯朵夫给她上课时情不自禁地在她手背上吻了一下，从此以后，这个女孩子就等着克利斯朵夫再来吻她一下手 背。克利斯朵夫可是吓坏了，再也不敢了，这女孩子就非常勇敢地把她的手背贴到他嘴唇上。他们就这样爱上了，非常热烈。这是一次很正式，也很完整的爱情，从 热恋开始，以失恋告终。弥娜的母亲非常冷静地观察着事态的发展，并不横加指责，但是以一种极度的礼貌，使他清楚认识到自己的卑微地位，因此他们的爱情只是 游戏，是玩笑。这种态度对克利斯朵夫的刺激是很强烈的。他的第一次爱情遭到失败，同时他的父亲又死了，双重打击之下他不禁陷入迷茫。在他陷入迷茫中是谁来 救他呢？还是他的舅舅，他的舅舅就像承担了一个先知的使命。这时他是来告诉克利斯朵夫你的责任还没完成，你必须要生活下去，你还不能垮下来。克利斯朵夫心 里的力量是很强的，他不会垮下来的，但必须有人不断提醒他，才能使他清醒。因此他又把这个难关咬着牙挺过来了。

　　建构他身心的硬件部分还有两个任务没有完成。一个任务是宗教。克利斯朵夫是一个虔诚的教徒，只是他自己并无意识，因为这于他是件再自然不过的事 情。父亲死了以后，他们家境一下子衰落得很厉害。两个弟弟都跑了，一个跟着亲戚去学做生意，另一个不知去哪里浪荡了，只剩下他和母亲两个人，又孤独，又伤 心。他们离开了老房子，搬到一个比较小的房子里去，房东姓于莱。和于莱这一家作邻居，使他进入了这个小城的贫民生活。在这些底层的生活里，他开始去想宗教 是怎么回事。于莱这一家人的特点就是吵闹，每天天一亮就听到他们吵闹的声音，好像他们有着很重大的人生任务。实际上他们的人生任务只不过是要把地板擦一 擦，可是却喧哗得不得了。他常常想他们为什么而生存。于莱家里有一个男孩子，长得非常清秀，很孱弱，很安静，是一个在神学院学习的学生。克利斯朵夫就对这 个孩子感到很奇怪，在这么一个嘈杂的，充满了俗世的繁琐事务的人生里，有一个人在潜心学习宗教，必定是这个宗教给予了他什么指示，使他来承受这种生活。有 一天晚上他就和这个男孩子作了一次非常恳切的促膝谈心。这个男孩子看到克利斯朵夫平时这么骄傲，傲慢，这时却愿意和他说话，感到很高兴，也就滔滔不绝，很 愿意说话。一上来他就说"太吵了"，这句话真说到克利斯朵夫心里去了，他已经被这家人吵得没有办法了，听到他们自己家里人能说出这句话来，觉得真是找到知 音了。接着他就问男孩是怎么来看待宗教、上帝的，这个男孩子就向他叙述了上帝给他的东西。上帝给他一个安宁的世界。因为这个世界太嘈杂，太没有秩序，太乱 了，而上帝使他到达一个很和谐，很美丽，很有秩序的天地里去。克利斯朵夫感到非常失望，他想这算什么宗教？这个宗教那么软弱，甚至于比于莱一家的生活更软 弱。他觉得这个男孩所要藏身的和谐的世界甚至比嘈杂的世界更没生命力。他觉得如果宗教是这样的话我就不信上帝了。这完全是一种逃避。他让男孩子叙述他在那 个宗教世界里看到的景色，他看到的都是很虚幻的景象，看到云端，看到一片祥和。克利斯朵夫绝对不是一个虚无主义者，当他从混沌走向混沌，也可以说是从虚无 走向虚无，在此过程中他要求非常严格，绝对不允许有一点可以含糊过去的说法，须是实打实的，看得见，摸得着。所以，这个男孩子的宗教绝对不是克利斯朵夫能 认同的。男孩的宗教完全不足以抵抗人生，因为人生的压力是很沉重的，而他这个上帝太软弱了，所以克利斯朵夫要找一个更强大的上帝。但这时候他不知道他的上 帝在哪里，所以他唯一能做的就是把这个上帝扔掉，抛弃掉。这是他在宗教上的建设，它是以一种丧失的形式出现的。

　　身心建设的最后一项任务是欲念。这个欲念任务是由两个女人来帮他完成的。第一个叫萨皮娜，是一个有夫之妇，开了一个小杂货店，卖卖钮扣，针头线 脑。小杂货店正对着他的窗口。这个女人具有一种典型的女性气质--那就是懒。她就像一只猫一样老是在睡着，从来没看她把衣服穿整齐的时候，任何一件衣服在 她身上都像是一件睡衣。老是见她在那儿梳头，可是从来也没有把头发梳好过。别人来买扣子，因为放在高架上她就回答别人说没有。就是这样一个非常慵懒的形 象。她非常有吸引力，非常打动克利斯朵夫的欲念，但是他最终没有和萨皮娜真正地做爱。他们有过一次机会，那是去郊游，因为下雨在外留宿。他们的房间中间隔 了一扇门，可谁都没有勇气推开这扇门。人走向欲念其实很不容易，克利斯朵夫的欲念是真正的欲念，不像我们平时所说的上了床就是的轻薄之举，他是经历着很强 烈的情感。结果萨皮娜就在这天晚上受了凉，死了。她几乎是一种幻觉，像烟雾一样，一碰就散掉了。但她已经完成了她的使命，那就是从心理上启发克利斯朵夫的 欲念。紧接着就有一个女人在生理上来开启他的欲念。这个女人叫阿达。一个店员，有着丰满的身体和鲜红的嘴唇，彻头彻尾的一个小市民--健壮，粗鲁，精力旺 盛。她很渴望也很熟练地和克利斯朵夫上了床，她把克利斯朵夫欲念的盖子真正地揭开了。等到他和阿达的事情做完以后，我以为克利斯朵夫生理、心理的基本建设 就完成了。如果说这是一个器具的话，这个器具就已经做好了，接着就要看我们往里面放什么东西了。这时他的物质性的准备都已做好。这些准备：亲情、爱情、宗 教、性爱、包括音乐，全都是以丧失为结局的，可是，要做的都做成了，而且非常坚固。这种制作方式，带有着锻打和锤炼的性质。

接下来是第二个阶段，我叫它"思想的成长阶段"，我给它的另一个名字就是"理性".他将开始寻找思想，把思想输入健全的身心中去。我觉得书中的四、 五、六、七卷是描写这个阶段。他首先经历的就是否定的过程。这是很自然的，每个人在他少年的时候总是力图反抗，并且往往是从最身边的反抗起。他也是从最身 边的反抗起，他反抗他的祖国。他认为德国的思想全都是腐朽的垃圾，根本不能供给新鲜的血液。他四处看去都是痛苦，简直不能忍受。他苛刻地评价德国的历史、 文化、政治，德国成为他少年时代反抗的对象，他必须要找到一个对象，如果他生活在法国他就反对法国了。他对德国的要求实际上是一种自我要求，是一种非常严 格的自我否定。克利斯朵夫在这里说过这样一句话：他无情无意地把从母亲那边得来的武器去还击母亲，将来他才会发现他受到了母亲多少好处。这种反抗就好像是 一种蝉蜕，旧的躯壳小了，要挣脱它，换一身大的躯壳。

　　他否定了他的祖国，当然还须寻找一个能够替代的东西作他的思想。他很盲目地到处乱找。首先他找到犹太民族。他认识了一个犹太人，他很想到这些犹 太的家庭里去，看看这个民族能不能给他一些新鲜的、有刺激的，可以帮助他的东西。可当他和他们接触下来，却感到非常失望。他发现这些在德国的犹太人比德国 还德国，将来他还会发现在法国的犹太人比法国还法国。他发现这个民族非常能接受它所在的环境的特性。所以当他和他的犹太朋友结下友谊，深入到他的家庭去以 后，他对这个民族就再也不抱幻想了，他认为这个民族不可能给他什么东西，于是他就退了出来，重新投入茫然的寻找中。然后就发生了具有预兆性的事情，一个法 国的戏班子巡回演出到这个小城里来了。他对法国并没什么好感，他觉得法国人是一种很轻飘的人。但因为它演出剧目里有歌剧《哈姆莱特》，当然莎士比亚的东西 他总是要去看看的。他很快就被演奥菲利亚的女角吸引住了。这个女演员给他极有才气的印象，他看了戏以后就去找这个女演员。他发现她天性里就有一种对戏剧， 或者说对音乐的领悟力，她根本不学习，不用功，不想问题，只是玩，只是吃，只是谈恋爱，可她有艺术的天性。这个女演员就像一个孩子，一个洋娃娃，却是一个 很有生命的洋娃娃，那么热情，很会调情。她的调情克利斯朵夫根本不懂，他是一个认真的人，对他来说要就是爱，要就不是，没有调情这一说。所以她和他调情便 得不到回音，她也并不生他的气，反和他结下了很愉快的友谊。然后这个女演员对他说我下一站要去法兰克福演出，你来看吧。其实她只不过随便说说而已，说过就 忘了，但是克利斯朵夫很认真地接受了邀请。

　　这里还须回述一个情节，就是他去看这个法国戏班子演出，是他那有钱的犹太朋友给他的包厢票子，他在戏院门口看见一个等退票的女教师样子的法国女 孩，就把这个法国女孩子一块带到包厢看戏了，其时他并没有对这个女人留下印象。他从法兰克福看完演出，在回去的火车上，当两列火车并排在一个站头上临时停 车时，他却看见了另一列火车里坐着那个与他一同看戏的女教师。这交臂而过的一瞬间，却给他留下了很深刻的印象。他觉得法国以两个面目出现在他面前，一个是 活泼的，热情的，充满活力的，无忧无虑的；另外一个则是那么忧郁，那么深沉，那么安静。法国是以这样不同的两个女性出现在他的印象中，从此他对法国就怀有 了一种向往。然后这段时间他是在混乱中度过。他去给《社会党报》写文章，他根本不了解《社会党报》和王室唱对台戏的背景，他一直是拿着王室乐队的薪俸，却 去给《社会党报》写文章。亲王非常愤怒，把他叫去狠狠地训了一通。他也不知道应该说一些道歉的话，觉得这是我的自由，我想在哪儿发表文章就在哪儿发表文 章，于是就和王室断了来往。《社会党报》的人则趁虚而入，又来找他，他自然说了很多亲王的坏话，报纸上立即登出来了。就这样莫名其妙地卷入了无谓的政治纠 纷。而他发现忽然之间冒出了那么多的敌人，那是因为失去了王室的保护。他又是一个性子非常暴躁的人，难免到处树敌，搞得焦头烂额。在这些孤独的日子里，他 四处寻找着可以支持他的东西。他去探望一个儿童时期非常崇拜的作曲家，这个作曲家在他儿童时代的印象中英俊、聪明、潇洒、才华横溢，充满激情。他把他的希 望寄托在这个作曲家身上。他坐火车去他住的城市，找到他家，经过多少次闭门羹之后，终于见到了这位作曲家，可是作曲家已经完全不同了。他还保持着一股锐 气，可是他这股锐气只是埋怨、牢骚和不满，而且什么都看不上眼，年轻人，音乐会，新作品全都看不上眼，百般指责。自视很高，可是创造力已经消退了。他对克 利斯朵夫也表示了露骨的蔑视。为什么蔑视他？只是因为他蔑视所有的人，虽然心里对他的作品是有好感的。实际上他们两个人有很共同的地方，他们都是有才能的 人，都是锐利的人，孤独的人，想要自由的人，但是他们俩都因为情绪化的影响没有成为朋友，失臂而过。他从他童年偶像那儿离开的时候，感到很伤心，他唯一的 渺茫，脆弱的偶像都没有了。回家的路上他忽然想到，一个曾经给他写信的音乐爱好者住在这儿，就给他发了一份电报。这个音乐爱好者是一个大学教授，没有孩 子，妻子死了，一个人很寂寞地生活，唯一的安慰就是克利斯朵夫的音乐。他非常喜欢他的音乐。一收到电报，马上就在约定时间到火车站去接。他想当然地到头等 车厢接，但克利斯朵夫是坐四等车厢，两人就错过了。然后这个音乐爱好者就满城地去找，找到田野里，看到一个人躺在大树底下，很悠闲。他觉得这个人有点像， 但也不敢冒昧地打招呼，就悄悄地走近他，唱克利斯朵夫的音乐--"来吧，来吧"，克利斯朵夫一下子跳起来，他们就这样见面了。接着他就陷入了一群音乐爱好 者的包围。这些人都做着普通的职业，在乡村里生活，长得也粗俗，胃口且非常旺盛。其中有一个大胖子，宣布要演唱克利斯朵夫的曲子，克利斯朵夫顿时感到灾难 来了，他想尽一切办法阻止他唱，可是办不到，因为这人是被他们远道请来专门演唱的，他必须要唱。他唱出来的第一个声音却把克利斯朵夫镇住了，他怎么会那么 理解他呢？他唱得非常好，是心灵里的声音。他的赞许的眼光鼓励了胖子，胖子开始大加发挥，事情开始变糟了，克利斯朵夫为了使他停止，差不多就快打起来了。 在那里他过了很愉快的几天，又回到他的小城里，依然一无所得。这时候他心里有一个向往渐渐清晰了，他要去法国。可是他走不了，妈妈不让他走。母亲半夜里起 来走到他床边说，现在只有我一个人了，你走的话，我就完了。

　　可是没料想，机会来了。这一段时间他就像一个游魂，一个幽灵，一个无家可归的流浪者一样的到处乱走。有一天他走到一个乡村，这个乡村正在举行晚 会，喝酒，跳舞，唱歌，他就参加进去了。然后来了一群大兵，和农民因为争夺一个女孩子起了纠纷。克利斯朵夫是那么骚动，心里憋了一股热情和力气没有地方 用，就一下子挑起了殴斗，并且打得非常勇猛，造成了惨案。这时候整个村庄的人开始怨恨克利斯朵夫，说如果不是你在里面挑，这事情很快就过去了，很小的事 情，经常发生的，军民之间的一点小冲突，可是你进来之后事情变得复杂了。只有那个因她而起事的小姑娘感激他，说我帮你走，你不能回德国，你再也不能回你的 城市了。她把他送到边境，然后让他过了境，这时候他迫不得已，只能走了。当他踏上开往法国的列车，对着他要去的方向大声喊道："巴黎，救救我！救救我的思 想！"这时候他终于挣脱了他的反抗时期，去往巴黎，开始他的寻求和建设了。

　　他要找法国，找法兰西的精神，可是法兰西的精神在什么地方呢？在这里我特别想说一点，罗曼·罗兰写了整整三卷关于他寻找法国的故事，但是我以为 他绝对无意要对法国的历史、政治、文化作什么评价，他只是要把法国这个地方作为克利斯朵夫思想或者精神的救援，他只是让法国承担这个援助的任务。而我觉得 法国在那个时代足够有条件，有资格成为克利斯朵夫的思想家园，因为它是一个艺术的国家，聚集了很多艺术家，是一个艺术大都会，有着悠久的文明。他进入法国 是由表入里。他一下火车看到巴黎的情景感到非常伤心，满目凄凉，是那种日常抑郁的生活，马陷在泥浆里拉不动车，妇女提着篮子匆匆忙忙地走路，天非常的阴 沉......他不知道他要到哪里去寻找法国，可他知道他必须要在这里寻找。他身边没几个钱，只有两个认识的人在这儿，一个就是从小和他进行过爱情预习的奥多，这 时候已经成为一个商人，已经不能习惯克利斯朵夫那种粗声大气说话的方式，那种过分的热情，完全没有绅士的风度，所以对他很冷淡，可以说是把他拒之门外。他 只得再去找另一个熟人，高恩，是个出版商，专门出版通俗小说，什么黄色他出版什么，所以生意做得挺大的。这个人其实对克利斯朵夫也受不了，况且明显就是找 他吃口饭的样子。可是摆脱不掉，因为克利斯朵夫那么热情。不得已高恩带他见了一些音乐家。可是克利斯朵夫那么傲慢，他完全没有意识到自己是个流亡者，别人 叫他去教小姑娘弹钢琴，他觉得是对他的污辱。但是不管怎样，他把这个高恩给缠上了，高恩带着他进入了法国的音乐界。法国音乐界给他的印象是什么呢？"音乐 在巴黎就像两个穷苦的工人合租一间房子，一个人从床上起来，另一个人就钻进他的热被窝。"就是这样一种情景，到处都是音乐会，多得简直是泛滥了。每个人都 在听音乐，演奏的也是那么回事，但是没有想象，就凭着几千年积累下来的机械的技术在那儿演奏。整个的情形就像赶集，一个星期里同时有好几个地方在举行音乐 会，每天晚上都有音乐会的海报，到处都是制作和弦的铺子。音乐在法国变成一种遍地皆是的，工匠性质的技术，因此整个空气里都充满了音乐。法国的音乐批评界 也是很热闹的，到处都掀起很激烈的争辩，流派简直多得吓死人，其实都很无聊，譬如说有横读派和竖读派（音乐总谱有十几行，和弦是竖的，旋律是横的）。也涌 现了很多当代的新艺术。他非常认真地去听当代的新艺术，这些东西却给他重复的感觉。他总是对高恩讲你再带我去看看。高恩说你要看什么。他说，我要看法兰 西。高恩说你看到的不就是法兰西吗？他说这不是的，一定有更好的东西，否则我不能解释为什么有这么多文化在这儿诞生。他非常执著地去找。他抛开音乐界，进 入了文学，情形同样令他扫兴。他很刻薄地讽刺法国当红的女作家，说这些女作家不过是把在客厅里撒娇的方式拿到书本里来撒娇，向她的读者传送媚眼，把她的私 人小事像雨点一样洒给读者。整个文学界充满了这样的女性的气质，一种委靡的、衰退的、伤感的气质。他也不能忍受，觉得文学和音乐同样糟糕。但是他也承认在 这么乱七八糟、像赶集一样闹轰轰的情景之下，古典艺术还是始终支撑在里面。是一片废墟，那也是古典艺术的废墟，也是罗马的废墟。可是他还是不满意，和高恩 讲你还是要带我去看，我还是觉得没有看到法兰西。高恩说那么你只能自己去看了，我没有办法再带你了，我已经尽我的力把我所有能够企及的艺术界的东西都向你 展览了，而你还是不满意。从此以后，克利斯朵夫只能单枪匹马自己去看法国了。他能看到些什么东西呢？

　　他首先走进了一些沙龙，去研究女性。他发现这些形象各异的女性说到底只有一种类型，就是漂亮、时髦、擅长谈情说爱，但缺乏鲜活的生命力。他也接 触了犹太人，就像前面说的，他觉得法国的犹太人比法国还法国。他认识了社会党人，参加到社会团体的阵营里去，参加他们的一些疯狂的讨论。他就发现在这些政 治里充满了资产阶级虚伪的气味，平民全都给资产阶级腐蚀了。后来他生病了。睡在一所公寓里，孤苦伶仃，所有的朋友都断绝了来往，只有一个住在顶楼的女佣人 来照顾他。这个女佣人是一个没有什么人生目的，对生活也不去思考，只是凭着本能在那儿勤勤恳恳，认认真真地生活。她说了一些很简朴的话，譬如说，你看到的 法国是一些有钱人的，而我们才是真正的法国，她只会说这些很淳朴的话。这使我想起张贤亮的小说《牧马人》，一个右派考虑了那么多，受了那么多苦，怎么都不 能解决问题，一个四川逃荒来的小姑娘，说了两句很简单的话：犯了错误改就行了，以后我们不犯就是了，问题就解决了。在这里情况也有点相似，克利斯朵夫就是 从一些非常淳朴的人生里开始领悟到法国精神的微光。但是不同的地方在于克利斯朵夫是从这种最低级状态，最淳朴状态起步，他还要出发的。可是"牧马人"就到 这儿为止了，永远是那么朴素的道理要来解答我们这么复杂的人生，其实是不可能的。这是一个很大的区别。而克利斯朵夫就在这个女佣人给他的启示上重新出发 了，他终于找到了出发点。以前都在浮面，而现在终于找到了根，从根上重新出发寻找法国。

　　然后他在一个Party上认识了一个青年，是个诗人，很敏感的气质，叫奥里维。他觉得奥里维和他似曾相识，在哪里见过。后来才知道他的姐姐安多 纳德，就是前面所说的法国戏班子来德国小城演出时，他带去包厢看戏的那位法国女教师，后来在一个车站，火车交车时，他们又见过一次。她的姓叫耶南。作者这 么描绘这个家族："耶南是它的姓，耶南是那些几百年来驻守在法国的一角，保持着纯血统的旧家庭。虽然社会经过了那么多的变化，这等旧家庭在法国还比一般预 料的为多，它们与乡土有多多少少连自己也不知道的根深蒂固的联系。直要一桩极大的变故才能使它们脱离本土。"安多纳德家的家史几乎可以说是法国的近代史。 最初他们的祖先是农民、佃户，然后作了工匠，或者乡下的公证人。她的爷爷是一个很精明的买卖人，最终成为一个银行家，他很顽强，很规矩，很正派，喜欢享 受，头脑很实际，也很潇洒，然后把这个家业传到她父亲手里。她父亲人缘很好，感情充沛，对政治没有兴趣，作为一种时髦而反教会，他把他所有的财产都投资在 一件投机买卖里，结果破产。他自杀了，留下妻子带着安多纳德和奥里维姐弟俩到了巴黎。他们是真正的贵族，被巴黎的粗鲁吓坏了。这么乱，这么多的人，马路上 的马车声、人声，就像一个咆哮的大海。他们在旅馆里住下来，然后去投奔亲戚，亲戚都非常冷淡，将他们拒之门外。于是只能去找工作，贵族的面子又拉不下来， 觉得他们去做家庭教师很丢人。母亲只能去修道院教弹钢琴，收人非常低，勉强维持三口人的开销，最后母亲去世了，将姐弟俩孤苦伶仃地抛在巴黎。安多纳德为了 能使弟弟受高等教育，就到德国去做家庭教师挣学费。这就是我们前面所说的克利斯朵夫在德国的家乡遇到安多纳德的背景。当他在法兰克福回去的路上，从并列停 车的车窗内看见这个女孩子的时候，安多纳德正是被她的东家解雇了回法国。因为她被克利斯朵夫请进去的包厢，正是她东家的包厢。东家的包厢里坐着他家的女教 师和一个狂妄的音乐家，被认为是小城里面一件很大的丑闻，完全不能接受，就让她回家了。姐弟俩苦苦挣扎，他们的贵族气质在平民的生活里压榨到极点，地位、 财富、尊严、骄傲，一切都没有了，可是却保留了贵族血统里最好的气质，那就是精神的高贵。安多纳德她才是真正体现了法国的精神，然而这种精神的生命实在是 太微弱，时间延续得太久，变故消耗得太剧烈，他们姐弟两个人的生命力只够一个人用的。安多纳德把她全部心血倾注于弟弟一身，结果她死了，奥里维一个人活 着。当克利斯朵夫看到奥里维时，他从奥里维的眼睛里看到安多纳德的眼睛。这时候法国开始向克利斯朵夫展现它的面目。这里我还要说一句，事实上克利斯朵夫遇 到过很多女人，可真正有过爱情的是安多纳德，也正因为这是爱情，所以他们永远没有握过一次手，只是在包厢里看过一场戏，隔着车窗和隔着马路见上一面。安多 纳德是寄托在奥里维身上，与克利斯朵夫相爱。这是灵魂之爱，只有天才才配领受，却是以痛苦与寂寞为代价的。

　　法国终于向克利斯朵夫展现了面目，主要有这么两大段情节。第一段是，他和奥里维认识后马上就变成很亲密的朋友，两个人在贫民区里租了一间公寓， 公寓住的全都是平民。于是他看见了法国的平民精神，这种平民精神是以贵族精神作底的，所以它有一种永远不会堕落的性质，再难，再挣扎，也总是立着。他周围 有电气工人，有受过罗马教庭处分的神父，工程师和他的家人，他们互相不来往，保持着精神的孤独，这是法国潜藏的生机。这使克利斯朵夫感觉到法国的优秀分子 其实是隐藏在暗处，这是一种收到盒子里的精神，收敛起来的。法国贵族的传统全都被现代工业打碎了，流落到了巴黎就藏在一个个盒子似的公寓里。他终于接触到 了法国。

　　第二段是与奥里维的长谈。专辟一章，写他们两人在房间里，整整八天，足不出户，讨论法国的精神。奥里维向他叙述了法国，法国有美丽的灵魂，但法 国的生命力却慢慢衰微，由于它缺乏行动。这时候克利斯朵夫开始意识到德国的优势，德国具有一种强悍有力的平民的力量。法国具备了优美、高贵、精神的想象， 而德国充满了现实的力量。我是这么来看的，当罗曼·罗兰塑造克利斯朵夫时，他想让德国作他物质性的盛器，里面盛的是法国的思想精神。其实，无论是法国也 好，德国也罢，只是个命名而已，其间的内容给它命名什么都可以，按照罗曼·罗兰的方式，我们暂且称它为德国和法国。这时克利斯朵夫的思想已经基本形成，他 已经找到了精神的家园，就开始了他成长的第三个阶段。

　　第三个阶段我称之为"理性和本能的合作".他的整个物质性的本能和他的精神思想在双方都成熟的时候，是严重起着冲突的，要把它们协调起来，必须 经历一个艰难的，痛苦的融合过程。这就好像把新鲜血液输进身体，会产生强大的排斥力，何况克利斯朵夫又是一个本能极其健全和粗野的人。他是怎样达到灵与肉 的合二为一的呢？首先他经历了一系列的女朋友们。有专门的一卷，卷名就叫"女朋友们".这些女人实际上都没有可能成为他的归宿，只是作为他的一个暂时停泊 地。我想女性是和本能与精神都有直接关系的，她们往往会成为本能实现的载体，同时她们又具有精神化的虚无的特质。所以，这时候，他很希望在他的女朋友里找 到一个使他的精神和肉体能够结合，寄存的家园。这些女朋友各种各样。先是雅葛丽娜，也是一个贵族，很娇弱，有很多幻想，最后她和奥里维两人结成了夫妻。他 们俩的爱情纯洁、高贵、美丽，可是这两个真正的法国人是没有生命力的，所以最后他们是互相折磨，两人的婚姻以失败收场，留下了一个孩子。这个女朋友吸引过 克利斯朵夫，但他觉得她太柔弱，有一些无聊。又有一个女朋友叫赛西尔，是个钢琴家，像个工匠一样的机械，可是以她的技术也能达到很好的境界，能把音乐表达 得相当完美。她的才能是和技术连在一起的，她给予克利斯朵夫安宁的心境。有一晚她和克利斯朵夫睡在两个房间里，中间只隔了一层薄薄的墙壁，互相之间也没有 一点骚乱。可是她对于克利斯朵夫来说，欠缺了激情，还是无法安置他的灵与肉。然后他碰到一个法国女演员叫弗朗索阿斯。这弗朗索阿斯很有才气，经历过苦难， 心里充满了骚动。可是这个女人和克利斯朵夫实在太相像了，在一起是骚动加骚动，痛苦加痛苦，都是做加法的，没有一点互相替补和缓解，也不行。还有一个悄然 露面又悄然消失的女朋友。她的露面是有预示的含义的。那是在一个奥地利大使馆的晚会上，克里斯朵夫作为一个著名音乐家也被邀请参加，他在一面大镜子里看见 了一个女人的面容，觉得很面熟。长期以来他一直感到有一个人在支持他，帮助他，在批评界里给他开创局面。其实就是这个女人，叫格拉齐娅。我们最后再说，她 的含义要在最后才体现，但是她已经在这时候登场了。就这样，他接触了很多女朋友，可始终没有得到一个身心合一的境界，但是他也没有付出太大的痛苦。

　　太大的痛苦紧接着就要来了。他参加了工人运动，而且把奥里维也带了进来。在一次激烈的暴力行动里，奥里维丧身，他被迫逃亡，达到靠近瑞士的边境 地带，投奔一个乡村医生。乡村医生的妻子叫阿娜，是个虔诚的天主教徒，不苟言笑，呆板，严肃，足不出户。他们没有孩子，生活得很平静。克利斯朵夫来了后， 激起她极大的热情。这其实是克利斯朵夫很虚弱的时候，奥里维的死和逃亡生涯使他身心分离，一切空虚，阿娜就此进入了他的生活。阿娜是个非常虔诚的天主教 徒，这种通奸的事情是她深恶痛绝的，可是她阻止不了这种热情。而克利斯朵夫天生是有洁癖的，满心都是对她丈夫的感谢，他的道德，他的良心都不允许他做这种 事情，可是也同样阻止不了喷薄而发的热情。他们俩的偷情真是太痛苦了。再加上他们家有个女佣人，非常爱管闲事。有一天晚上克利斯朵夫到阿娜房间去，发现地 上铺着很细很薄的沙子，他们就知道是这个女佣人干的，企图抓到证据。他们感到非常紧张，愚人节紧接着就要来了，在愚人节里允许人们把最丑陋的东面都揭露出 来，可以用玩笑、调侃的方式来揭露，而且他们已经感觉到这个女佣人和她的朋友在设计让他们当众出丑的节目了。他们只能决定去死。一切准备都已做好，手枪也 偷到了，可子弹生了锈，打不出来，死也死不成。最后阿娜病倒，他只能逃走，逃到瑞士的山里，住在一个农民的小屋子里，谁都不见。他和这尘世断了一切的联 系，什么都没有了。而就当他绝对孤独的时候，他身心开始结合，就像是从炼狱里脱生。他觉得有一个力量在驱使他，他停不下来，必须写作。他完全不去考虑写出 的东西是好是坏，只感到身心的一种冲动使他必须写。我想，此时此刻，克利斯朵夫终于达到了理性和本能的融合，在他离开了所有的女朋友，在他孤独一人的身 上，两者协调起来。而紧接着，死亡来临了。

　　在他死亡以前他回到了人间，回到了巴黎，也回了自己的家乡。这时候他已经成为一个老音乐家，以前攻击过他的报纸开始吹捧他，而且以他来压制下一 代的音乐家。剧院的音乐会里到处在奏他的音乐，他已经被推崇为一代宗师了。可是他对这一切毫无感觉，他已经无所谓了。他知道什么是好什么是不好，这些都无 法左右他了。奥里维死了，可是奥里维有一个小朋友成长起来了，也开始在写诗。这是个工人的孩子，是个驼背，他的祖父是个鞋匠。他的诗里透露出奥里维的灵 光。奥里维的孩子也长大了。他心里宁静下来了。我们前面所说的格拉齐娅，再一次地也是正式地登场了。这个女孩子在很小的时候就爱上了克利斯朵夫，她以一个 儿童的心去爱他。她出生于一个意大利世家，她具有宁静、和谐、高尚、纯洁、仁慈的特质，她是克利斯朵夫心目中的罗马女神，而罗马始终被克利斯朵夫认为是最 高的艺术殿堂。克利斯朵夫非常想和格拉齐娅结婚，可是格拉齐娅始终不同意。她说我非常庆幸我们两人始终是很好的朋友，没有成为夫妻，而成为夫妻后那种日常 的琐事会把我们的感情磨蚀掉的，而我们现在却保持得非常好。克利斯朵夫只能承认这种关系，和她做一个好朋友。在克利斯朵夫临近死亡时，格拉齐娅和他说了一 句带有总结性的话：你已经越过火线了。

　　现在，我可以进行第四步，也就是为我的分析作出结论，我的结论是，《约翰·克利斯朵夫》不是为某一个具体的天才，比如通常以为的贝多芬作传，而 是写一种自然力，这是所有的生命里最好的一种生命力，原力里面最好的原力，是自然力的精华，它的光辉使它超越了真实，成为一个神话。

　　我还想要再进一步地证明一下我的结论，我觉得在那个时代，在20世纪开始之前和开始之初，艺术家是下苦力下死力的，而不是技巧性的。今天的艺 术，则是另辟蹊径。就像扛一个重东西，以前都是用力气来扛的，后来发现了杠杆的原理，学会了巧力。因此在《复活》、《约翰·克利斯朵夫》这类作品中，你很 难找到显著的特征来表明构造的用心和含义，一切看上去都那么日常和真实，但是我觉得还是能找到一些提示，来证明我刚才的观点：不是写一个具体的天才，而是 在写一种永恒的、自然的、生命的最精华。书中给了我们几点提示：一是这个名字，"克科斯朵夫"实际上是一个圣徒的名字，这是在3世纪的一个著名的圣者。主 人公克利斯朵夫经常想到在古罗马教堂门前的圣者克利斯朵夫的浮雕像，他想到哪一天才是他生命的终点：我和这个浮雕像合而为一的时候就是我的终点。圣者克利 斯朵夫传说他身材高大，专门背人过河，有一次他背一个小孩过河听到一个声音说，你背负的是全世界和创造世界的基督，他在宗教里是旅行者的主保圣人。约翰· 克利斯朵夫接近死亡时，脑子里最后的幻像是他背着一个孩子，这孩子拉着他的头发，一直在说"向前走，向前走......"，他说"咱们到了，唉，你多重啊，孩子， 你究竟是谁呢？"这个孩子说："我是即将到来的日子。"第二点提示是，克利斯朵夫忠诚地勤恳地毫不偷懒地走完了生命的全过程。书中有许多人，好人，善人， 软弱的人，都是早死的，夭折的，不等走到生命终点就死了，而克利斯朵夫顽强地努力地走到了生命的终点。在他最后死亡时，他还看到了古教堂门前圣者克利斯朵 夫的像，下有拉丁文铭文：当你看到克利斯朵夫的面容之日，是你将死而不死于恶死之日。用中国话说是善始善终。他忠诚地走完了生命的全过程，没有"早退"， 终于和圣者克利斯朵夫合二而一。

　　第三点提示，作者为克利斯朵夫规定的辉煌的定义是：音乐。音乐可说是一切创造物中最最虚无的东西，它最难物化，它是附在时间的流程上，转瞬即逝。而它的圣灵之光也就在此，它最具有神的特征和灵魂的特征。

　　我要说的观点在分析它的全过程中已经说明了，但我要找到提示性的东西作为我们的引导。现住我可以更肯定无疑地说它不是一个具体人物的传记，不是一个反映现实的作品，而是创造圣者的神话