基本成型的Oracle 11gR2文档已经可以看到了，通览一下New Features部分，列举看上去很美妙的一些亮点。 以下仅仅是通过阅读文档得到的信息，在11gR2正式发布之前，一切都可能是会变化的。 1. RMAN Web-Services Backup 现在Oracle允许通过RMAN将数据库直接备份到Amazon S3或者其它的云计算存储解决方案中，虽然还没有明确的报价，但是可以预见一定会比自己购买带库要便宜。这里需要解决的一个是备份的效率问题，另外一个是备份集的安全性。 2. Edition-Based Redefinition 一直以来都知道在产品环境中，我们不能随便地去重定义包，函数，存储过程，视图，否则可能产生严重的锁等待，现在Edition-Based Redefinition的引入有助于在繁忙的产品环境中通过版本的控制来顺利地升级或者修改应用程序。 3. Cluster Time Service 代替NTP的东东，也许是因为NTP导致了一系列RAC的bug，所以Oracle干脆自己做一个时间同步服务，似乎这是在11gR2中安装RAC的前提条件了。 4. Columnar Compression 列式压缩，全新的压缩方式，消耗更多的CPU能力来获得更小的存储消耗，列式压缩对于应用是透明的，数据仓库系统值得去尝试一下这个新功能。 5. Data Pump Legacy Mode 在11gR2中原先的exp已经不再被支持，imp仍然允许使用。因此11gR2提供了兼容模式，允许在Data Pump中使用之前的exp和imp脚本，使客户获得更加平滑的升级体验。 6. Significant Performance Improvement of On-Commit Fast Refresh 对于物化视图刷新的改善，鼓励更多的数据仓库用户使用物化视图重写来改善应用性能。 最后也是最重量级的震撼新功能，那就是ASM全面升级，脱胎换骨。 7. Automatic Storage Management for All Data，是的，所有的数据都可以存储在ASM中，因为在11gR2中ACFS, ADVM闪亮登场了。 ASM Dynamic Volume Manager (DVM)是Oracle的卷管理软件，ASM Cluster…
Tag: Oracle11g
CBO need more human brains?
从Oracle8中引入的CBO和统计信息收集功能在8i，9i，10g，11g中一直在发展，CBO的设计理想是美好的，但是一直以来也受到用户的质疑，CBO的不够智能，或者说某些时候过于笨，有些时候又过于自作聪明，引发了很多问题。 11g推出之后，Oracle在完善CBO自身功能的同时，又添加了很多允许用户参与的功能，也许言下之意是，CBO的完善还有很长的路要走，但是面对各种现实问题，还是先允许更加聪明的人类用户来参与影响SQL的执行计划吧。 看看新提供的DBMS_STATS.COPY_TABLE_STATS功能，该功能可以改善对于使用range方式来分区的大分区表的统计信息生成方式，这种表往往统计信息更新赶不上数据更新。通过copy statistics可以将一个已经存在的分区统计信息复制到新生成的分区中，该方法基于的理念是每个业务分区的统计信息在数据条数，数据分布，NDV值等等方面都是基本相同的。 再加上之前介绍的SPM功能，也同样是允许用户来决定最终使用哪个执行计划的举措。 数据库管理越来越智能，并不意味着数据库管理员的工作越来越少了。
How to resolve ORA-13541
在尝试调整AWR报告的保留时限时，出现ORA-13541错误。 SQL> exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(4320,60); BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(4320,60); END; * ERROR at line 1: ORA-13541: system moving window baseline size (691200) greater than retention (259200) ORA-06512: at “SYS.DBMS_WORKLOAD_REPOSITORY”, line 89 ORA-06512: at “SYS.DBMS_WORKLOAD_REPOSITORY”, line 137 ORA-06512: at line 1 试图查询ORA-13541的具体含义，但是发现oerr ora 13541并没有任何输出，同时在metalink上也查询不到任何一篇提及ORA-13541错误的文章。 只有从错误信息本身进行解读，我们的SQL动作是将AWR报告的保留时限从默认的8天改为3天。语句中的参数4320是retention，以分钟为单位，4320分钟等于3天。错误信息中的259200也是retention，但是却是以秒为单位，4320分钟=259200秒。那么691200也同样是秒，换算为天数是8天。此时再去检查AWR Baseline中的定义。 SQL> select moving_window_size from dba_hist_baseline; MOVING_WINDOW_SIZE —————— 8 那么重新解读一下错误信息，就是AWR Baseline中的MOVING_WINDOW_SIZE是8天，大于了想要修改的AWR Retention的3天。 尝试先将AWR Baseline的MOVING_WINDOW_SIZE修改为3天。可以在OEM的AWR…