问题现象今天在生成一套rac的awr报告时，发现只有一号节点的数据，这是一套11.2.0.4的rac。 123sys@TFDW1> select * from Dba_Hist_Snapshot where instance_number=2;未选定行 查看mmon进程信息，发现二号节点并没有这个进程 123[root@tfdw2 ~]# ps -ef|grep mmongrid

除了收集合适的统计信息，提供一个管理这些统计信息的综合架构同样重要。oracle提供了多个方法去做这些工作，包括恢复统计信息到以前的版本，提供从一个系统迁移统计信息到另外一个的选项，甚至你可以手动设置统计信息。这些选项在某些特定情形下都非常有用，但是仍然建议都通过DBMS_STATS包来收集统计信息。 恢复统计信息当你用DBMS_STATS包来收集统计信息时，原来的统计信息会自动备份存储在字典表里

分区表上的统计信息要同时计算表级别和分区级别，11g以前新增一个分区或者修改少数分区的数据需要扫描整张表去刷新表的统计信息。如果跳过收集全局统计信息，那么优化器则会根据分区级别的统计信息去推断全局级别的统计信息。这种方法对于简单的表统计信息（例如行数）是准确的——通过聚合所有分区的行数，但是其他的统计信息就无法准确的推断。比如无法从每个分区独立的信息来准确推断出一个字段的唯一值记录（优化器使用的最

从11g开始引入了对列收集扩展统计信息，扩展统计信息包含了两种额外类型的统计信息：组合列和表达式统计信息。 组合列对于真实数据来说，一个表中多个字段直接的数据通常具有关联性。比如在CUSTOMERS表中，CUST_STATE_PROVINCE字段会受到COUNTRY_ID字段值的影响，比如湖北只会出现在中国下面，如果只有基本的统计信息，优化器是没有办法知道这些关系的，如果在一个语句中这几个字段条件

介绍很早之前的版本中，如何执行一个sql语句是由RBO（Rule Based Optimizer）决定的，根据一些设定好的规则来生成执行计划。 后来的版本中CBO（Cost Based Optimizer）被引入进来。CBO检查sql所有可能的执行计划然后选择其中cost最低的一个，cost其实就是反应了执行计划估算的资源消耗。cost越低，这个执行计划也就被认为效率越高。为了能让CBO计算出更准

为了将以前的旧库整合起来，需要将旧库都插入到12c数据库当中统一管理 这篇文章主要介绍如何将原有的11g数据库作为pdb插到已有的12c数据库当中去 现有环境 SID 版本 CDB Test 11.2.0.4 NO Ora12c 12.2.0.1 YES 升级11g数据库参考通过DBUA升级11g到12.2，不过多介绍 从NO-CDB插入到CDB示意图 确认源库信息12345

12c已经出来了很长时间，公司的11g系统可能都考虑升级到12c，整理一下相关操作。这篇文章都是在实验环境上，所以有些不必要的步骤就没有一一做完，如果是生产环境则需要认真读一下官方文档Database Upgrade Guide 12.2 看一下升级到最新的12.2可以通过哪些途径 Current Release Upgrade Options 12.1.0.1, 12.1.0.211

之前写过一篇12c Adaptive Plans，现在来说一下Adaptive Query Optimization的另外一部分：Adaptive Statistics sql执行的计划的好坏很大程度上取决于统计信息的质量，现在的sql语句越来越复杂，单纯的依赖单独某个表的统计信息已经无法满足要求，为了使统计信息更加丰富完善，引入了新的帮手Adaptive Statistics Dynamic

12c在优化器方面引入了不少的新特性，其中一个就是Adaptive Plans。 在特定的条件下优化器会使用这个新特性，比如sql语句包含了表关联、复杂的谓词条件导致很难精准的估算cardinality，Adaptive Plans使优化器可以等到真正在执行sql语句的时候才决定采用哪种执行计划。 优化器会优先选择一个默认执行计划，同时搭配一个_statistics collectors_,这样就

从12c开始，truncate命令支持了新的参数cascade 有了这个参数你就可以同时truncate父表和子表，当然这个参数的使用有一定的前提条件，就是父子表的完整性约束必须要用ON DELETE CASCADE来定义，父子表必须要属于同一个用户下，同时你要对这些表都有DROP TABLE的权限 新建一对父子表，用ON DELETE CASCADE来定义相关约束 12345678910111