前言
 
    oracle7月11日在美国纽约发布了11g版本，可惜迟迟没有可公开下载的版本，只有加入oracle的测试计划的合作客户才可以得到beta版本试用。但这并不妨碍oracle爱好者们根据一些流传出来的文档来了解oracle 11g。7月30日开始的上海oracle open world，oracle宣称11g是30年来最重要的一次版本发布。对这样一个噱头我们还是比较冷静的看待的。OOW期间在一个采访oracle ACE 的活动中，我们几个ACE都不大赞同这样一种说法，其实oracle 一直以来都在前进，不断地改进以满足客户的需要。应该说，11g达到了许多客户所期望的目标，是一个关注细节的版本。那么11g到底有哪些重要的值得关注的地方呢，不妨挑一些特性做个简要分析。
 
 
关注应用、关注性能
 
    SQL replay
 
    OOW后 rich Niemiec(www.tusc.com) 先生趁着来中国的机会各地巡游，期间到了我们公司，他问我在oracle 数据库的使用中我最大的困难是什么？我最大的困难是应用为了应对多变的商业需求，频繁地发布。而应用变化则带来schema的变化，尤其严重的是对于数据库来说可能需要新增加index。增加index绝对是一件危险的事情，这本是为了优化查询而增加，但却可能导致原来的某些查询选择了错误的index，运气好则是应用性能少量下降，运气不好则是数据库立即crash！每年这么多变化，我如何来保证每次都是正常的？数据库可靠性要求很高，任何意外都不是我所期望的。为了避免这种情况，通常我们会尽力在测试环境中做尽量多的测试。但任何的变化若都要进行回归测试，QA通常都是比较紧缺的资源。这种现状，中外都一样，只是我们通常没老外做的好。
    那么这件事情跟SQL replay有什么关系呢。我们来看看这个功能，在系统中捕获某个时段所运行的所有SQL,然后我们可以搭建一个和当前系统一样的测试环境，这样我们可以在测试环境中做我们想做的事情，如增加index，准备好之后我们可以重现搜集时段内数据库所执行的SQL(replay)。 通过观察replay期间的表现和性能信息，我们可以方便的看到哪些sql性能降低了，然后做出修正再replay，直到满意为止。这样做的好处是，我们可以不再倚赖于QA资源。要知道对于一个复杂庞大的系统，做回归测试工作量巨大。Oracle这个特性为我们提供了方便。
 
    Database workload capture and replay
 
    这一项与SQL replay不同的是搜集了整个数据库的负载情况。比如我们曾经出现过一个存储系统IO能力表现不佳的情况，厂商为了证明存储性能新搭建了一套环境，但我们却很难把真实应用放到新环境中去测试。最多也只是使用一些工具来模拟。后来打算换新存储，实际上在新系统上线前，我们无法预测新存储的表现到底能好到什么程度，这就存在着风险。如果有了Database workload capture and replay 这项功能，那么我们的困难也将迎刃而解。包括数据库要升级，也可以通过这个功能来做很好的性能预测。
 
    Result Set Caching
 
    这项功能的推出，再次表明oracle对细节的关注程度。当然，换个角度来讲，现代关系型数据库和计算机技术的发展，一直没有出现重大的突破，都是在几十年前的基础上不断地升级、修补。现在已经关注到客户应用的一些非常具体的需求上。这点其实从很多oracle有关执行计划的特点上也能看出来。Oracle推出了大量的只适合某些特定情况的执行计划，优化的触角伸到了非常精细的领域。回过来说result set caching 这项功能。这其实是我们众多用户在一些特定情况下所期望的但又和早先数据库系统的设计思想不一致的地方。oracle为了满足大家的要求，做出了这么一项功能。在还没有真切地感受这项功能的好处和限制之前，我们不妨先看一看特点。这项功能可以使得用户在使用 /*+result_cache*/ 提示的情况下，将查询的结果缓存。当查询被反复地执行的时候，不再需要到表中去获取，只需要来这个存放结果的地方就可以了。实际上这跟我们当前的一些web cache 的功能非常相似。这种cache应该更倾向于对结果集比较小、查询频繁切查询语句固定的情况。问题接踵而来，如果支持频繁的变化的数据，对性能有多大的影响，在使用上到底有些什么限制？很遗憾，我无法在这里详细地解释这些问题。一切都待我们做更多的实验来检验。
 
    Invisible index
 
    这是一项非常有用的功能，oracle虽然在8i就推出了虚拟索引的功能，但是，毕竟那还只是针对某个session的执行计划的观察和调整。现在我们可以选择实实在在的创建好index但却是invisiable 的状态，DML 也依然在维护这个index。然后我们可以通过使用提示走到index上来测试性能。当我们发现一切正常的时候，可以选择将index设置为visible 状态。如果我们想drop掉某个index但又担心不保险的时候，也可以选择将index设置为invisible状态，发现有问题再设置回visible状态。这样就可以避免经历drop之后再重新create的状况，在联机事务处理的大表上，create  index是一个非常消耗资源的任务。
 
    关于性能方面的补充
 
    当然在应用性能方面除了以上几种特性外，还有很多的新的特性，如SQL Plan Management 提供能类似store outline 的功能，Auto sql tuning可以自动的协助用户来对sql进行优化，更强大的ADDM，提高lob类型数据的io性能，总之，有非常多的值得关注的内容等待大家去探索。
 
 
关注维护、关注管理
 
    Online Patch
 
    作为维护高可用数据库系统的DBA，最担忧的事情之一，就是遭遇无法回避的bug而被要求升级！以往升级有一个很重要的问题，那就是需要数据库停机！如果仅仅是更换rdbms obj文件并重新link，那么似乎rac可能在应用配合切换的前提下做到不停机。但如果升级需要在startup migrate下运行catpatch.sql ，则停机不可避免。虽然正常状况下这个过程不是特别长，如果在正运行的机器上使用独立的安装目录来打补丁，打完再替换原来的rdbms软件，则down time大约是替换时间加上运行catpatch.sql 的时间之和。也就是说运气不错的话能控制在5—10 分钟内。但应用的起停，往往却异常复杂。比如我们有几百台连接数据库的服务器包含了几十种形形色色的应用，做一个停机维护是一件大事。这直接就延长了down time。所以打补丁一事我们非常慎重，新上线数据库选择的版本也非常慎重。一定要选择稳定可靠的版本，应用一定要使用传统、可靠的数据库功能。这也使得很多新出来的数据库新特性我们不能及时地使用。传闻ebay一轮数据库升级大概需要2年时间，希望11g的online  patch 和Database workload capture and replay能缩短这个周期，也让DBA们能轻松一些。
    online patch 这类特性，我一直都期待数据库能实现。现在开放平台os的kernel升级基本做不到online，似乎只有存储在这方面做的不错，高端存储的软件和硬件升级都可以online（基本使用的是cluster接管交替升级模式）。主机也许因为变化太频繁以及成本原因，难以实现cluster交替升级的模式。但其实我也希望尽快研究一下oracle实现online patch的原理，是如何解决link与正在运行的程序之间的关系，以及catpatch时刻如何解决数据库内部对象的变化问题。
 
    Object dependency tracking
 
    在oracle中我们可以通过dba_dependencies查找到对象之间的依赖关系，如果被依赖的对象发生了DDL，不论这个改变是否会影响到依赖对象，依赖对象都invalid并需要重新编译。很多人在繁忙的oltp系统中遭遇过类似困境。比如表中lob的storage属性发生变化会影响到引用这个表的对象如procedure、function、trigger等。往往不经意之间，dba的一个改动，系统突然就挂了。那么11g在这方面有所改进，如果对象属性的变化不会影响到依赖对象，那么依赖对象就不会需要重新编译。
    既然oracle都实现online patch了，强烈希望将来在对象重新进行编译的时候可以手工控制，预先编译完成择机切换，类似表的online redefine一样。希望11g未来某个版本可以实现这个功能。
 
    Data Guard Snapshot
 
    这个特性是使得我们可以在standby上做出快照而保留下standby在若干时间点上状态的版本。这样我们就可以挑选某一个快照出来使用。可以做测试、可以核对数据。当然，我在netapp filesystem 上做oracle 9i版本standby snapshot 已经有几年了，这项功能我非常喜欢，可以随意open read only一个2星期甚至3星期前的数据库去查找当时的某些数据。现在11g提供了这项功能，则我们就不必局限在存储厂商所提供的快照功能上了。
 
    Query on Physical standby database
 
    这个消息犹如一个重磅炸弹，在众多资深DBA中激起了无穷的想象。Oracle在9iR2中实现了logical standby（传闻是quest工程师的支援下用logmnr实现），logical standby只能存在一个，可以被用于产生报表。如果oracle可以在物理standby上做查询，那么这个意义就重大的多。一个主数据库可以拖多个物理standby，假定采用最大数据保护模式（事务能及时地传递到standby并且立即被应用到standby），那么这跟mysql的集群类似了，一个写多个读。ebay就是在负载均衡设备F5 加quest同步工具shareplex的帮助下，实现了一个写入多个读的模式，从而支持了数据库性能的扩展，也使得数据库的维护变的更容易， 不再担心单个数据库的灾难带来致命的影响。那么现在oracle 似乎朝这个方向又迈进了一步。9iR2 提出并在10g大加宣扬的oracle streams在11g中并没有成为重点，看起来streams还不如shareplex和realsync更获得用户的认可。那么query on physical standby 看起来则是一个简单的廉价的解决方案。这个功能最终能做到什么程度，还有待实践来检验。但是，这个消息，给予了我们太多的期望！
 
    Auto Memory Tuning
 
    Oracle 从9i 开始，让PGA可以自动管理，不必为单独进程的各个pga组件设置大小，减轻了dba的工作量，让进程内存管理更容易。同时sga可以通过设置sga max size 上限，sga内部各组件可以动态调整大小，系统也根据动态统计信息给出sga组件设置大小建议。到了10g 开始可以支持sga各组件由系统自动调整分配。虽然这个功能还让大家放心不下，但毕竟自动化管理的方向是得到大家认可的。现在11g走的更进一步，sga和pga合起来可以由数据库自动分配。DBA只需要告诉oracle可以使用多少内存而不必去关注各组件的具体分配。看起来，DBA们的日子又将轻松一些。
 
    ASM and ILM
 
    存储厂商早就提出了信息生命周期管理的概念，看起来一切那么美好。当然，在存储厂商炒作这个概念的时候，我发现对于一般客户这并不是一个可行的低成本方案。我们关注新技术新概念（实际上大多都是老技术组合包装稍微加工一下就成了新技术），切实地分析其对我们能产生什么价值，实际上成本是一个非常重要的因素。Oracle 在10g中推出ASM是一个重大的新特性。但可惜ASM稳定性相对raw device还没得到用户的广泛认可。ASM 是oracle向存储管理软件延伸的一个重要标志。在我看来，除了在无传统cluster软件下做rac之外，更重要的是存储负载均衡的功能。当新增加存储设备的时候，oracle可以在系统IO相对空闲时期将数据移动到新存储设备上达到均衡分布的目的。尤其在数据仓库中这个功能非常好用。
    我一听见oracle  ILM 第一印象就是想到ASM，它应该可以配合ILM做很多的事情，ASM可以帮助DBA将不活跃数据在线迁移到其他设备上，这是信息生命周期管理的基础。oracle在不断地尝试，放弃被市场淘汰的功能，发展被市场认可的特性。
    我以前曾经多次论述oracle 跟 os之间相互学习的过程，现在看起来，数据库不仅跟os，还跟存储搅和在一起了。将来三者之间是相互竞争、相互合作的过程。不管如何，对于我们客户来说，能从中受益，那就是好事。
 
 
后记
 
    Oracle数据库技术的发展，其实最近几年一直都在朝着关注细节的方向，如何满足客户差异化的需求，为客户提供特定环境下的最佳性能，是oracle领先于其他数据库厂商的重要原因。数据库、os、存储在某些功能上的融合，也有利于我们客户降低投资成本和管理成本。最后要感谢oracle的设计者，你们能真切地感受到客户的需求，并转变为现实。
    今年oracle将在北京、上海、广州、成都四地分别举办oracle DB 11g launch大会，9月19日在上海，开场15分钟我受邀将做一个不限制内容的演讲。从包括今年oracle open world的状况来看，oracle对中国市场的重视程度明显提高，对中国网络社区的关注程度也明显提高。希望大家可以加强交流，共同提高。