xiaoyu的数据库小窝-技术交流

oracle 12c引入了多租户环境，允许一个数据库容器CDB承载多个可插拔数据库PDB，CDB全称为Container Database翻译为数据库容器，PDB全称为Pluggable Database翻译为可插拔数据库，在oracle 12c之前实例与数据库是一对一或者多对一的关系，而在oracle 12c之后实例与数据库可以实现一对多的关系，也就是一个CDB，多个PDB，这个其实如果大家有接触过mysql、sqlserver这类数据库，对于这个概念就很好理解了，摘要下官方文档关于CDB和PDB的关系图：

CDB组成：
root组件：也就是CDB$ROOT,存储着ORACLE提供的元数据库和common user，元数据比如oracle提供的pl/sql包的源代码，common user是指每个容器中都存在的用户
SEED组件：Seed又叫做PDB$SEED，这个是创建PDBS数据库的模板，不能在Seed中添加或者修改对应，这个基本类似于sql server的module数据库
PDBS组件：具体的PDB数据库

ROOT、Seed、PDB关系可以这么简单描述：ROOT(根)是一个容器，Seed(种子)是一个容器，每个PDB是一个容器。每个容器在CDB中都有一个独一无二的的ID和名称。

绑定变量分级是oracle在pl/sql中会根据文本类型的绑定变量的定义长度而将这些文本型绑定变量分为四个等级：

1 定义长度在32字节（bytes)以内的文本型绑定变量被分在第一个等级，oracle为其分配32字节的内存空间
2 定义长度在33-128字节之间的被分为第二个等级，oracle为其分配128字节的内存空间
3 定义长度在129-2000字节之间的文本型被分为在第三个等级，oracle为其分配2000字节的内存空间
4 定义长度在2000字节以上的被分为在第四个等级，取决于对应文本类型的绑定变量锁传入的实际绑定变量的大小，如果实际传入的绑定变量的值小于或者等于2000，oracle为其分配2000字节的内存空间，如果实际传入的绑定变量大于2000字节，则oracle为其分配4000字节的内存空间

需要注意的是这里的绑定变量分级仅仅适用于文本类型的绑定变量，对于number类型的绑定变量oracle统一为其分配22字节的内存空间。

自己在11.2.0.4环境中对于SQL语句测试绑定变量分级，发现并不绝对遵守上面的规则来生成child cursor，当然还是建议SQL语句或者PL/SQL中对于相同的绑定变量，申明的数据类型和长度必须统一，避免因为绑定变量分级而产生过多的child cursor。其原因是因为child cursor不仅仅存储了解析树和执行计划，还会存储该SQL所使用的绑定变量类型和长度，如果该SQL的绑定变量类型和长度发生变化，则oracle将无法重用该child cursor，必须为该SQL再生成一个child cursor。

绑定变量何时被捕获：
1 含有绑定变量的sql语句被硬解析时
2 当含有绑定变量的sql语句以软解析或者软软解析方式重复执行时，该sql语句中的绑定变量的具体输入值也可能被oracle捕获，只不过默认情况下这种捕获操作oracle需要间隔15分钟才会做一次

需要注意的是oracle只会捕获那些位于目标sql语句的where条件中的绑定变量的具体输入值，而对于那些使用了绑定变量的insert语句，不管insert语句是否以硬解析方式执行，oracle始终不会捕获其value子句中对应的绑定变量的具体输入值。

我们重新设置下绑定变量的具体值，再次执行上述sql，这里oracle并没有马上捕获sql语句中新的绑定变量的具体值，这个是因为软解析和如软软解析时，oracle为了考虑性能等问题需要间隔15分钟后才能再次捕获绑定变量的具体值：

这里提到关于绑定变量的问题，这里再提一下何种谓词适合用绑定变量:一般而言对于主键、id、流水号等基本唯一的值，并且对应的SQL执行频率特别高，oracle建议使用绑定变量，而对于那些状态值（例如能够枚举的，不同值只有几个或者数十个）不建议使用绑定变量，因为这类SQL即使不使用绑定变量，oracle的解析消耗也是微乎其微，而如果使用绑定变量，会导致在某些特定场景下SQL执行计划并不是最合理的，甚至是非常糟糕的，所以也不要将系统中所有的SQL都使用绑定变量，这里简单做个测试以供大家参考：

对于object_type=’INDEX’优化器更应该选择全表扫描，而不应该选择索引范围扫描，但是因为使用的绑定变量，然后又关闭了绑定变量窥视，则优化器计算选择率时只能是1/num_distinct，进而导致rows评估也存在较大的误差，从而选择了资源消耗更多的索引范围扫描；如果开启了窥视，又没有自适应游标等特性支撑，会导致后续的SQL都使用之前的执行计划，又是一个性能隐患。

使用绑定变量字段类型：
xiaoyu个人是不太建议状态字段、时间范围字段等使用绑定变量的，这类SQL如果执行频率又不高，不存在较大的并发，即使不写成绑定变量，也只有几十个sql_id在shared pool中，这点解析消耗微乎其微，而如果走错一个不合理的执行计划，则消耗的资源将远远超过这点解析消耗。

可以参考之前写的关于sql代码中哪些列适合使用绑定变量 http://www.dbaxiaoyu.com/archives/2534

性能优化时大体有如下两种评估方式：如果希望知道性能度量值指示服务器接近容量限制，则应设置绝对值；但是如果希望知道今天的性能与上周（或者上个月)同一时间的性能之间的差异，则当前性能必须与基线进行比较，基线是某个时段内生成的一组快照，按照统计学对这些快照进行了分组，以便获得一组随时间变化的基线值，可以以任何时段快照采样来做基线，只不过一般情况下我们大多会选择系统正常时段的快照来做基线。

基线在oracle 10g中就出现了，而在oracle database 11g进一步增强了自动工作量资料档案库基线：
1 即用型移动窗口基线，可通过该基线指定自适应阀值
2 使用基线模板安排基线的创建操作
3 重命名基线
4 设置基线的到期日期

AWR baseline是指一个特定时间段内的性能数据，保留这些数据是为了在性能问题产生时与其他类似的工作负载时间段进行比较：

fixed baseline：fixed baseline表示的是您制定的一个固定的、连续的时间段
moving window baseline：表示的是war保留期内存在的所有war数据
Baseline template：您可以使用baseline template创建将来某个连续时间段的baseline,oracle中有两种baseline模板分别是single和repeating

创建fixed baseline：

创建baseline的procedure和function

还可以删除和重命名baseline：

在oracle 11g中系统已经默认创建moving window baseline：

oracle database会自动维护系统定义的moving window baseline，系统定义的moving window baseline的默认窗口大小就是当前的AWR保留期，如果打算使用自适应阀值，请考虑使用更长的移动窗口，比如30天，以便精确的计算阀值。移动窗口的大小调整为小于或等于AWR的保留天数，因为要增加移动窗口的大小，必须要先增加相应的AWR保留期限。

基线模板：
基线模板允许定义可能在将来要捕捉的基线，create_baseline_template存储过程定义单一基线或重复基线的捕捉，创建单一基线模板与创建基于时间的基线类似，除了将来的时间外。

重复基线模板稍微有点不同，因为它需要调度信息，start_time和end_time参数分别在模板激活和释放时定义，day_of_week、hour_in_day和duration定义产生基线的日期、时间和持续时间，因为模板会产生多个基线，基线名是以baseline_name_prefix开始的。

repeat基线模板：

上面介绍了基线，那么如何来使用基线和指定时段的快照做awr数据对比了，其实Oracle为我们提供出AWR Compare Period Report来方便实现指定时段的awr数据对比。

由于基线又由于可以一直保存在awr快照中，DBA做性能分析时则可以利用基线和故障时段的awr做对比，更进一步的分析数据库的性能趋势变化，下面简单的来做一个AWR数据时段对比：

接下来使用awrddrpt.sql脚本来生成两个awr的对比数据：

生成的AWR部分信息：

客户提出SYSAUX空间太大，已经占据了20多G的空间，登陆系统发觉SYSAUX表空间中占据TOP SEGMENT的主要就是WRI$_SQLSET_PLAN_LINES表

对于WRI$_SQLSET_PLAN_LINES表查看其中数据只有0条，但是segment分配已经达到了4G多，这个优先考虑的就是在系统闲暇时间进行move或者shrink space操作：

而对于包含LONG的数据表无法进行move或者shrink space，oracle提供了一种方法，就是首先exp或者expdp将这部分数据导出，然后truncate该表，最后将数据导入到该表中。这里对于WRI$_SQLSET_PLAN_LINES表仅仅只是存储的SQL SET的信息，而这部分SQL SET已经被删除掉，这里直接truncate该表就可以释放出该表的空间，当然如果表中有数据则可以参考上面这种处理方式。

MOS中有一篇关于如何缩减SYSAUX表空间的文章 How to Reduce SYSAUX Tablespace Occupancy Due to Fragmented TABLEs and INDEXes (文档 ID 1563921.1)

在线重定义数据文件：
在oracle 12c R1之前的版本中，如果在线移动数据文件需要将表空间或者数据文件离线，然后操作系统mv，recover后online数据文件或者表空间，在oracle 12c R1后可以直接在线重定义数据文件，这个过程用户可以进行查询、DML以及DDL的任务，另外数据文件也可以直接在存储设备间迁移，比如ASM到文件系统的相互迁移。

在线移动数据文件

在线迁移表分区或者子分区：

这里的在线迁移并不会影响该表的DML操作，为了满足在线迁移的特性，oracle需要引入锁机制，这个会导致下降并且产生大量的redo，影响程度取决于表分区或者子分区的大小，当然oracle推出的新特性可能也会存在一定的隐患，这个需要dba多去关注mos上的文章。