Entries tagged with “Oracle” from DBA notes
真是一种嘲讽，就在刚才，收到一封广告信，标题是 "Sun为企业发展提供更多动力"
对于 IT 产业来说，这是最好的时代，这是最坏的时代。Sun 要做 Web 2.0 中的这个 Dot 没做成，74 亿美金把自己卖掉了。
尽管我不是 Sun 的粉丝，还是感觉不太痛快。这次收购意味着又有若干产品有可能被打入冷宫。而大家比较关心的 MySQL 可谓命运不济，被 Sun 折腾一年多，在开源社区里面一点好没讨到，这回在 Oracle 新的产品线里面如何定位呢? will be an addition to Oracle's existing suite of database products... 当然，InnoDB 这回和 MySQL 算是破镜重圆了。是否有其它变数，比如被原 MySQL 团队赎身出来? 难!
对于 Oracle 来说，这次自己终于有了硬件(SPARC)和操作系统(Solaris)这两块王牌，其实 Oracle 和 Sun 算是多年的合作伙伴了(超过 25 年)，相信整合起来可能问题不大。这次收购比较失败的可能就是 IBM 了，Oracle 这次给了竞争对手 IBM 以更大的压力。难道蓝色巨人出不起这个价格麽? 还是觉得足够鸡肋? Sun 手里的 Java 技术对于 IBM 的小型机是个很好的补充，想不通。再过几年，这可能就是 IBM 犯过的最大错误。
不痛快的除了 IBM ，恐怕还有 RedHat。不过别着急，没准儿哪天 Oracle 也把 RedHat 也一并收了，我相信 RedHat 手里的 JBoss 至少让 Oracle 眼馋不已。有 JBoss 在，其他中间件就不可能赚到更多。
一切皆有可能。其他事情不好确定，但有件事情还是能基本肯定，拉里·埃里森大叔这回又有机会体验一下世界首富的滋味了...
--EOF--
延伸阅读：
近期在和几位同事一起翻译这本 Troubleshooting Oracle Performance (TOP)，这是2008 年国外 Oracle 相关书籍中唯一一本值得期待的作品。
本来撺掇同事童家旺写书，不过他谦虚到底，说宁愿翻译，而且一般的图书看不上，只对这本 TOP 感兴趣，家旺慧眼识珠，我也只得勉为其难，助他完成这事儿(其实我对这书也非常感兴趣)。翻译图书是吃力不讨好的活，考虑到各自工作也比较繁重，又拉来同事胡怡文，三个人乐观估计可以拿下这本厚达 600 页的大作。没想到几个月过去，还是耽误了进度不少--出版社估计已经准备扣稿费了 :)
这本书的作者Christian Antognini，对 Oracle 数据库的理解精深，凭借此书已经奠定 Oracle Guru 地位。其人也是 OakTable 的成员，说起 Oak Table ，这是一群 Oracle "科学家(Scientist)" 的圈子，没有几手绝活只凭忽悠那是不能位列其中的。
目前这本书已经倒了后期校稿阶段，近期准备放点样章上来供大家参考。翻译得是否得体，亦或佶屈聱牙，还请各位别吝惜手里的板砖，尽管拍来。
--EOF--
数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。
Exadata Storage Server 架构分析
该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。
如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西 ，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ......
从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL --OEL 也在这个框架内。
名词解释：iDB
iDB - the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。
InfiniBand
Oracle 的 RAC 集群是 "Share Storage" 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。
实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。
HP Oracle Database Machine
相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?
结论
流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。
这并非一个会让人多么激动的产品。
--EOF--
附加：价格列表
连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。
如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询，会发现很多和该参数有关的 Bug ，执行计划的出错特征是也走了索引，但是走了索引全扫描(INDEX FULL SCAN)，如果做 10053 Trace ，会发现有个烦人的 Recost for ORDER BY 步骤，然后就会引到错误的执行计划上。
在 9i 升级到 10g 最容易遇到这个问题(原来好好的，到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发，更多的时候优化器模式是 FIRST ROWS -- 这样 Oracle 会尽量消除排序，默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题：
ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5
其它可能的解决办法：对索引里面的排序保持和 SQL 里的 ORDER by 一致。
其实说白了，很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的，因为不具备普遍性，所以在某些版本中作为隐含参数出现。在生产数据库上，个别的时候启用隐含参数倒也不是不行的，只要明白了相应的隐含参数到底是干啥的就成了。
题外话：_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现，倒是感觉和 Oracle 内部代码管理有关，本来应该消除掉的，怎么后面的版本又跑了出来?
目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ，有中文译本：《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。
--EOF--
今天 Oracle 公司 Real-World Performance Group 的 Andrew J. Holdsworth 与 Bob Carlin 来阿里作交流。尽管语言沟通上不是很顺畅，还是讨论的不亦乐乎。Andrew 过去也来过阿里巴巴作交流。
Andrew 今天提到了 GATHER_PLAN_STATISTICS ，这已经是短短一段时间第三次遇到这个 Hint 了，上次看到是在 Lewis 的 BLOG：DBMS_xplan in 10g，第二次在 Greg Rahn (也是 Real-World Performance Group 的成员)的 BLOG：Troubleshooting Bad Execution Plans ，以前或许也看到过，可能忽略了。
这个 Hint 在调查执行计划突变的时候非常有用，执行 SQL 的时候收集额外的统计数据。走投无路的时候，或许能用来救急。
另外一个以前忽略的话题是 CARDINALITY 评估错误引起的错误执行计划。事后查了一下，居然还有个 CARDINALITY hint (对，还有个 CARDINALITY Hint! )能直接指定 CARDINALITY 。
一天的讨论学到了两个知识点，已经很不错了. 这一天比较充实的.
--EOF--
下载 PPT : When to Use the Appropriate Database Technology，第二遍阅读的时候，发现这个 PPT 还是很好的。
偶然发现三年前的一个技术问题。当时比较匆忙，避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。
问题描述：通过 JDBC 上来的 Java 查询应用，SQL 表现异常。表字段使用了 DATE 类型，针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，发现无效。仍然是 FULL TABLE SCAN (FTS)。
罪魁祸首：setTimestamp() 把值绑定为 TIMESTAMP 类型，这样和 DATE 类型比较的时候，CBO 就会选择全表扫描。
通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了，连续几个版本其实都有类似的问题。
解决办法：使用 setString() 而不是 setTimestamp() 方法。
这个故事告诉我们，Oracle 的 JDBC 驱动程序其实问题挺多的。同样，TIMESTAMP 潜在的问题也不少，尽管这个数据类型已经出现多时。
--EOF--
偶然看到 Tanel Poder 提到的一个 Metalink Note (438452.1): Performance Tools Quick Reference Guide 。这文档倒的确挺新，其中有几个工具值得关注一下。
LTOM：The Lite Onboard Monitor
Java 程序，定位是"实时诊断平台"。具有自动 Session 跟踪特性。另外具备自动 Hang 检测，自动数据收集等功能。该工具应该对于 Oracle 技能不太强的中小用户有比较大的帮助。但对于比较关键的系统，恐怕都不太放心跑一个 Java 程序在数据库上。
OPDG：Oracle Performance Diagnostic Guide
类似决策树的一个工具，访问的时候要打开个 Java 虚拟机，以我这样的网速根本访问不到(到了 22% 就停掉了) 。不知道等着着用这个工具的用户会急成什么样。
TRCANLZR：Trace Analyzer
格式化原始的 SQL Trace 数据，以 HTML 形式展现给用户。
HANGFG ：Hang file generator
用以收集系统 Hang 住时的状态信息。看来，Oracle 出问题比较多的时候还是系统 Hang 啊 :)
除了这几个，还有 STACKX ，用以分析 Core 文件的内容；还有以前大家都知道的 OS Watcher ，现在也做了一些改进。这个软件包基本上是 Unix 的那些传统的性能工具加上比较有好的图表展现脚本。
应该说随着 Oracle 开发、开放更多的性能相关的工具出来，对于有一定经验的 DBA 来说，会有个很好的辅助作用。对于经验不够丰富的用户来说，不是缺少工具，而是即使有性能数据，也不知道如何分析，如何定位。
--EOF--
偶然发现，Metalink 对于文档的关键字也是用 Hint 的方式, 哈
一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件，通过该插件，Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。
在 Oracle 10g 刚发布那会儿，EM 的地位在整个链条中倒是挺重要的，几年下来，似乎并没有占领多少市场。我个人觉得这个工具挺"重"的，倒是很少看到有 DBA 用这个工具。
尽管这个 MySQL 插件应用场景可能不多，但这还是第一次看到第三方给 Oracle EM 带来扩展能力。
比较关注即将召开的 The 2008 MySQL Conference & Expo，Sun 收购 MySQL 之后第一次大规模亮相，能带来什么? 新版本的特性基本了解了，还有呢?
Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。
--EOF--
Oracle 对 PHP 的支持一直是不错的(只是国内好像 PHP + Oracle 的开发并不多)。 Oracle 11g 中的新特性数据库驻留连接池(Database Resident Connection Pool，DRCP) 对 PHP 应用进一步扩展带来了一种可能。
这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。
Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个...还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。
--EOF--
今天在无聊的售前演示中看完了一篇技术文档 All About Oracle's In-Memory Undo，关于 Oracle 的 In-Memory Undo (IMU)，记得几年前讨论过，大部分基于猜测，这算是看到的第一篇比较细致的东西。
Oracle 公司在 10g 推出 IMU 这个特性（已经申请了专利）。Undo 作为最重要的组成部分之一，其高效与否直接关系到整个 DB 的能力。Undo 旧有的基于 Block 的段(Segment，指存储层的概念)管理模式方式，UNDO 本身的变化要记录到 Redo Log Buffer 里，而 IMU 避免了这个操作(因为是内存而不是存储)，从而减小了生成的 Redo 量。
另外，因为读一致性开销直接到了内存里而不再依赖存储段, 整体也大大降低，CPU 的负荷也会有效降低。其应用模式应该说是适合一致读的需求量比较大的 OLTP。
Oracle 10g 默认是使用 IMU 这个特性的。通过隐含参数 _in_memory_undo 可以关闭这个特性。因为是隐含参数，也侧面反映出该特性并非那么成熟。搜索一下 Metalink，有不少关于 IMU 的 Bug，而 UNOD 的 Bug 一旦遇到，不停 DB 恐怕都很难解决。所以，对于可用性要求比较高的系统，现在起用该特性还是需要三思。
附: 全部机制在专利全文里。谁有兴趣仔细读一下吧.
--EOF--
从 Laurent Schneider 的 Blog 看到信息，Oracle 10gR2 的第三个 PatchSet 10.2.0.4 已经出来了。虽然还没有正式宣布，但是在 Metalink 上已经能够看到 Linux 平台的了。PatchSet 号码为：6810189 。
现在 Oracle 的 PatchSet 出来的顺序基本上还是 Linux 是第一个，也反应了某种趋势。若干年前都是 Solaris 平台 上最早出来的，现在都变成 Linux 了，操作系统的流行变迁可见一斑。原来传言说 2007 年年底会发布的 ，还是拖到了现在才看到，难道 Oracle 的开发力量都投入 11g 上面去了?
有意思的是，10.2.0.4 Patch Set - List of Bug Fixes by Problem Type 这个列表下仍然写着 “Please note that 10.2.0.4 has not been released on any platform , and does not have release dates available" 。可见 Oracle 内部对文档的更新也是比较乱的。
期待这个版本在修复众多 Bug 的同时不要引入新的 Bug 了，Oracle 10g 在稳定性上还是不能让人放心，淘宝的兄弟们最近就因为 ASM 的 Bug 而折腾了一回。。11g 会好一些么?
对于 DBA ，尤其是 Oracle DBA 来说，厂商发布一个新的 PatchSet 要比发布一个新的版本来的更为实惠一些，因为前者面向解决现有存在的 Bug 问题。新的版本只会引入更多的问题。
--EOF--
今天不知道是什么日子，又一个震撼业界的消息，大胃王 Oracle 收购 BEA。
正在走下坡路的 BEA 算是卖出了合适的价钱。原来自己估价的 82 亿美元，倒是误差不大。不过我倒是真的看不出 Oracle 收购 BEA 有什么必要，应用服务器市场也就那么大嘛，收购 RedHat 不是更物美价廉么? 前几天我写帖子预测 Oracle 会出现财务危机，看来只能算是信口胡说了啊。
照这样下去，应用软件市场也就是能剩下几个巨头了，IBM、微软、Oracle，扳着手指头就能算过来了，对了，还有 SAP，前几天刚用 68 亿美元收购了 BO。说白了，还是有钱公司的财富游戏。
--EOF--
这是我的 Oracle 11g 系列的文章之一(这一篇没啥含量，算是笔记吧)。
在 11g 之前的版本中，DBMS_STATS 自动统计收集(Automatic Statistics Gathering)默认的阀值是 10%, 这个 10% 是不可以修改的。这对千变万化的企业数据库来说环境来说，有些死板，如果是个超大的表，默认的 10% 数据也是海量了，会把整个资源占死。Oracle 11g 中，这个属性可以通过修改 STALE_PERCENT 属性来修改, 有全局（DBMS_STATS.SET_GLOBAL_PREFS ）和表级别（DBMS_STATS.SET_TABLE_PREFS）两种。
例子语句:
设定:SQL> exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',1);
修改为 1％. 范围从 1-100.
恢复:
SQL> exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',null);
查询:
SQL> select dbms_stats.get_prefs('STALE_PERCENT',null,'EMP') from dual;
虽然我很少用 DBMS_STATS 收集数据对象统计信息，不过它的有些用途还真的不错。
Refer: Metalink Note:390737.1
--EOF--
最近在 ITpub 上有几个讨论 IO 的帖子很热闹，其中一个讨论中 Biti 说"响应时间在 10ms 左右能达到的最大 IOPS 能力，是系统 IO 能力的一个最重要指标" ,下面好多网友不知道这个 10ms 怎么来的，以及为什么是 10ms .
其实如果你熟读 Oracle 手册的话，你会发现 10g 中已经涉及到这个 “10ms” 的信息了，而且，侧面透漏出很多潜在的细节。
在 Oracle 10g 中有一个新的参数： DBIO_EXPECTED ，这个参数指 DB 平均读取一个 数据库块的时间，单位是毫秒(millisecond)。由 ADDM（ Automatic Database Diagnostics Monitor）用以分析系统 IO 性能的参考值。默认是 10ms ，之所以取这个值，是因为当前企业内投入使用的硬盘（存储）一般一个 IO 时间(读取一个 DB 块)大约在 10 ms 之下，超出 10 ms 一般意味着在 IO 跑得有点费劲了。这个 10ms 是个经验值，但这个经验值是有来由的。
有些慢速硬盘，比如希捷 Barracuda® ES.2，寻道时间接近 10毫秒，一些老一点的 SATA 盘肯定更慢了；而 Cheetah® 15K.5 则大约只是 3ms-4ms 的样子（DBA没事的时候不妨看看硬盘厂商的白皮书，挺好玩的)。一个 DB 系统上线时，测试一下 IO 基准能力还是必要的。注意测试的时候出现的"拐点"，意味着这个时候的 IO 响应时间是至关重要的，因为这个时候 IO 即使有应用Cache、 数据库 Cache、（主机 Cache）、存储 Cache，也还是有大量 IO 压在了后面的磁盘上，如果磁盘的 IO 到了峰值，IO 层的能力也就到了峰值了(特定响应时间下的最大 IOPS)。多数系统上，应该在 10ms 附近。所以，你盯着 DB 上离散读的平均响应时间，到了 10ms 意味着快撑不住了。
要如实使用 ADDM 衡量 IO 状况，DBIO_EXPECTED 参数还是需要作一点调整的。要注意这个参数并不是初始化参数，如果需要重新设定，则需要提交如下语句修改：
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM', 'DBIO_EXPECTED', 4000);
上面的数值单位是微秒。
数据库 IO 是一个非常有意思的话题，本来想写一系列的东西。结果这篇写出来发现不伦不类。权作抛砖吧。
--EOF--
我必须要说，这是我今年看过的最差的 SNS startup ，尤其这还是软件巨头 Oracle 弄出来的。为了验证我所言不虚，请登陆 Oracle MIX. 这 UI 啊...
此前，Oracle 低调的推出了官方 Wiki, (友情提示,可能会经常的打不开该页面)。在 SNS 如此火爆的今天，卖水的也都开始甩开膀子准备下场掘金，最起码，也要把自家院子里的金子挖一下不是?
--EOF--
国内 Web 2.0 网站的代表之一豆瓣网的用户正式突破 100 万，祝贺豆瓣团队！如果一个国外的 2.0 站点拥有百万用户的话，估计会有 N 多巨头来谈收购了。国内用户的价值就不值钱麽? 是的，的确是这样。不过豆瓣在用户的心中是最有价值的。
或许今天才算是 Oracle 11g 正式发布。因为各平台的都可以下载了。非常喜欢 收购的 Oracle 为什么不干脆把 Quest 收购算了? 或许这样才能把 Quest 那款非它不可的软件价格降下来。当然，Quest 也不是吃素的，也会玩收购，把提供虚拟桌面环境解决方案的 Provision Networks 收购了。
--EOF--
国内数据库技术牛人, Oracle ACE Fangxin Lou 自行开发的 AUL 最近有了一次比较重要的升级：支持压缩表。有趣的是，据他自己说是经过了 20 分钟的发呆 想到的解决方法。很多人都知道 Oracle 的 DUL(Data Unloader) 是数据恢复的最后一招，一般来说是密不可宣的，一旦给用户恢复数据则代价昂贵，而 AUL 则平民化了许多，虽然不是开源的，但是国内用户如果使用的话，基本还是不收费用的(功能还毫不逊色)。
Lou 最近也作了一次 AUL/MyDUL发展历史回顾, 这个工具都三岁了。难得的是坚持，这一点我很服气他。
关于 AUL 更多信息可以参考他为推广 AUL 而做的 英文 Blog
--EOF--
BTW: 鲜果上我的BLOG验证代码: BANG1F1D675F0C335CE77C173BA6XIANGUO
Oracle 10g 开始 引入了AWR (Automatic Workload Repository). Oracle 建议用户用这个取代 Statspack。不过这个需要注意的是使用 AWR 需要有 Diagnostic Pack License。Oracle 后来推出了一个解决方案可以禁止掉该特性。
在 Note. 436386.1 有说明:
SQL> @dbms_awr.plb然后执行：
dbms_awr.disable_awr();
如果用 sys 之外的用户创建 AWR 报告，则需要进行合适的授权。否则会报告错误 PACKAGE 执行错误。
CONNECT / AS SYSDBA;
GRANT ADVISOR TO foo;
GRANT SELECT_CATALOG_ROLE TO foo;
GRANT EXECUTE ON sys.dbms_workload_repository TO foo;
要注意 Bug 4597354 在创建基线数据的时候，对性能有很大影响。在一个非常繁忙的系统上不要进行此操作。
如果结合企业管理器用 AWR 是很方便的，如果用手工方式收集性能数据，多了很多可供调整的地方，是更加方便了呢？还是更加麻烦了?
--EOF--
如果用关键字 "MySQL 迁移 Oracle" 在网上搜索，基本上得到的内容都是关于从 Oracle 如何迁移到 MySQL 的，而从 MySQL 迁移到 Oracle 的信息则少之又少。
抛开那些手工一点点做的方法不谈，网络上也可以找到一些第三方工具来做这个事情，免费的? 我只找到了一个，那就是 Oracle SQL Developer 了。如果采用比较傻瓜化的方法，不妨考虑这个工具。在这个工具之前，Oracle 提供了单独的 Migration Workbench 工具。在 SQL Developer 1.2 版中，Oracle 干脆把这个功能集成进来。
数据流示意图:
Source Database(MySQL/DB2 etc.) --->SQL Developer (ETL)-->Target Database (Oracle)
MySQL JDBC 下载地址：
http://dev.mysql.com/downloads/connector/j/5.0.html
配置 MySQL JDBC:
还需要注意一点就是需要调整一下迁移时候的参数:
剩下的事情就简单了，配置到不同数据库以及准备存放 Metadata 数据库的信息。然后就可以迁移了。不赘述。
这个方法只是够傻瓜化，由于运行机制的限制，速度不是非常好。对于迁移过程中产生的变化数据，也无能为力。
--EOF--
订阅更新
如果喜欢用 RSS reader 获取信息，可以订阅这个 Feed 以便获取 “Oracle” 将来的更新内容.
