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对中国市场的重视程度明显提高，对中国网络社区的关注程度也明显提高。希望大家可以加强交流，共同提高。