oracle 12c发布已经有几天了,最近一直比较忙,没时间研究,趁周末在家玩玩,熟悉下12c的新特性.
其中有2个比较新的概念是multitenant container database (CDB) ,pluggable database(pdb).

一个CDB包含0个或1个甚至多个PDB. 每个CDB都包含如下的内容：
Exactly one root (存放oracle提供的metadata信息和公共user信息)

The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied
PL/SQL packages (see “Data Dictionary Architecture in a CDB”). A common user is a database user known in every container
(see “Common Users in a CDB”). The root container is named CDB$ROOT.

Exactly one seed PDB (这是oracle提供的system 模板,这里面的对象的只读的)

The seed PDB is a system-supplied template that the CDB can use to create new PDBs. The seed PDB is named PDB$SEED.
You cannot add or modify objects in PDB$SEED.

Zero or more user-created PDBs (用户存放的数据)

A PDB is a user-created entity that contains the data and code required for a specific set of features. For example,
a PDB can support a specific application, such as a human resources or sales application. No PDBs exist at creation of the CDB.
You add PDBs based on your business requirements.

每个CDB中的组件，都可以理解为是一个container(容器). 那么到底是怎么样一个结构呢，大家可以参考官方文档的图，如下：

 

 

可以看出,上面的一个CDB中包含了4个container，分别是：root，seed，hrpdb，salespdb.
当然，只有hrpdb和sealespdb里面的数据才是我们的实际业务数据.这里需要注意的是，虽然从上图来看，逻辑上来看是一个整体。然而其物理结构是有所不同的，例如文件的存放位置.
首先我们来看下12c pdb的结构图：

 

可以看到，实际上是共享一个instance memory结构.  下面我们来手工创建一个pdb.

注意这里的file_name_convert是创建pdb中cdb的语法,如果你去查询v$parameter你会发现其实并没有这个参数.

官方文档中只有PDB_FILE_NAME_CONVERT 这个参数. 下面我们打开pdb中所有的CDB.

大家可以发现，我这里的orcl这个CDB中，有2个我自己创建的pdb。同时大家也可以发现，这2个pdb都有属于自己的system datafile，这说明了什么
？说明一个CDB中的每个pdb都属于自己的数据字典信息，换句话讲，一个CDB中的每个pdb的数据字典信息都是独立的，每个pdb就可以理解为一个单独的数据库，只不过这些pdb是共享的一个实例和redo，以及controlfile，undotbs. 如下，查询你会发现每个pdb的数据字典信息都不一致：

这样设计有什么好处？显然好处之一就是便于进行迁移。同时我们也知道12c可以在线进行datafile 的move移动，先测试一把：

通过监控发可以发现move datafile的时候会出现type为MV的锁，mode是4,6. 换句话讲，在move的过程的中，该datafile的对象是可以进行访问的. 经测试发现在move datafile期间，该datafile上的对象是可以进行dml和select操作的,如下：

这里只列出delete的操作，其他操作就不列了.  online 移动datafile是12c中一个很好的特性之一，对我们做迁移来讲是太好不过了，比如存储更换，可以直接move，都不需要用rman去进行restore了.

那么多move datafile的实质到底如何呢 ？下面我们通过10046 event和strace命令来跟踪下move datafile的操作。

—-Session 1

那么这里只有一种解释,将每个block都写一次,每次读完后都写128次.

每次db file single write之前也是对应的db file sequential read,大家注意后的p3也是128,并不是1. 12c的官方文档是这样解释这个event的：

所以这里给人似乎有点难以理解,难道是每次读1个block,读128次?

另外,关于move datafile操作,我相信肯定也是会触发检查点的.

我们再来看下strace 该进程的trace内容是如何的 ：

—-fd 信息

—-读操作

我们可以发现对controlfile的读写,其次是会读undotbs.  写操作主要集中在controlfile和datafile 261上。
由于会触发检查点，那么更新controlfile是必然的，这点无容置疑.我们重点来看下对datafile 261的操作.

针对datafile 261的第1次写操作：
4192       0.000057 pwrite(261, “\v\242\0\0\1\0\200\1\0\0\0\0\0\0\1\0046\300\0\0\0\0\0\0\0\0\20\fM\212IP”…, 8192, 8192) = 8192

从offset 8192来看，这里是操作的datafile header block.

针对datafile 261的第2次写操作：
4192       0.000383 pwrite(261, “\35\242\0\0\2\0\200\1\353\371\32\0\0\0\1\4\233N\0\0\6\0\0\0\10\0\0\0\0d\0\0″…, 1040384, 16384) = 1040384

这里offset是16384,而我们的block size是8k,换句话讲是从第2个block开始写的. 后面的1043384表示写了127个block,跟我们10046 trace是完全能对上的.

大家注意后面每次针对datafile 261的写都是以128 block为单位的,也就是每次写单位是1m. 写完之后，最后再更新datafile header block.
所以,从strace process的结果来看,是多block写的,跟前面10046 trace的db file single write似乎有点不一致.

最后来个简单的总结：

1. oracle database 12c感觉确实比较强悍,引入了很多新特性,例如多个lgwr,虚拟column等等
2. 引入了cdb,pdb的概念,但是对于同一个cdb来讲,不管其中包含多少个pdb,其本身是共享redo,undo和controlfile的,
同时也是共享一个instance memory结构.
3. 每个pdb都属于自己的数据字典信息,这样可以便于进行pdb的迁移.
4. 较为重要的一个特性move datafile,非常棒,我这里测试发现move datafile的时候回产生type为MV的锁,mode为4,6.
但是并不会阻塞dml和select操作.(或许我是vm测试较为简单,高并发环境或许有所不同)

后面会逐步分享12c的其他特性,敬请期待~~~