共计 2926 个字符，预计需要花费 8 分钟才能阅读完成。
| 导读 | 全面解读 Oracle 12.2 体系架构图系列。本期的内容由两部分组成，一是数据库实例与文件系统的访问；二是多租户解决方案。 |
- RVWR：Recovery Writer Process，当数据库设置了闪回区域的时候，该进程定期将内存中，具体来讲是 shared pool 中的 flashback buffer 里面的闪回数据写入 flashback logs.
- Result cache –> RCBG:result cache 用于存放 SQL 语句或者 plsql 函数在执行过程中，对于原始数据进行运算所得的结果，当数据库再次对相同的对象做同样的操作，可直接获取结果，避免计算资源的浪费。
- ASH buffer–>MMNL: ASH buffer 用于存放活动会话的统计信息，包括 SQL 的执行情况，应用连接情况，等待事件等。当 ASH buffer 被写满的时候，MMNL 进程负责将 buffer 中的数据写入到磁盘中。
- In memory undo（IMU）： 在共享池中开辟一块区域，存放临时 undo，一个事务中若修改多条数据，不再 buffer Cache 中的 undo 数据块做修改，而是增加 IMU 节点进行记录。主要是为减少 undo 所产生的 Redo。
- Private Redo log buffers： 主要用于管理 IMU 所产生的临时 Redo，将事务的 Redo 信息存放在共享池中，减少对 Redo log buffer 的消耗。
- Flash Cache： 全称是 Database smart flash Cache，是从 11.2 开发的一项针对闪存的优化技术，旨在通过使用闪存代替传统的慢速磁盘设备来存储部分数据，已达到减少数据库整体延迟，提高数据库的 IOPS，提升数据库性能的目的。
Flash Cache 的工作原理如下：
Flash Cache 中存放的内容通过两种方式来控制：
1、flash Cache 的智能选择算法：评估数据块、索引块的访问频繁程度来决定。
2、对数据库对象的 cell_flash_cache 属性做修改。
Flash Cache 存储内容基本标准
主要是小 IO 操作，以及数据块、索引块、文件头，控制文件等会被缓存；
针对 RMAN 备份的 IO 操作，数据泵 IO 操作 ASM 镜像操作以及表空间格式化等不会做缓存；
全表扫描的 IO 操作的缓存优先级比较低。
当数据存储在 flash Cache 中，主要是为了提高查询的速度，也就是说，它就相当于在内存之外又增加了一部分 buffer Cache 的区域，只是性能更好，速度更好。那么跟 buffer Cache 一样，flash Cache 中的数据写满或者写到一定程度就需要把数据写入磁盘，留出空间给新的操作数据。
缓存内数据写入磁盘称为 flushing。 可以配置 Starting and stopping cache flushing levels 值，这个值表示占用整个缓存大小的百分比。当缓存内未写入磁盘的数据达到 starting flushing value 时，控制器开始 flushing（由缓存写入磁盘）。当缓存内未写入磁盘数据量低于 stop flush value 时，flushing 过程停止。
如果 start flushing level 设置较高，可以在缓存内存更多的未写入数据。这有利于提高写操作的性能，但是要牺牲数据保护。如果要得到数据保护，可以使用较低的 start and stop values。 经测试表明，使用接近的 start and stop flushing levels 时性能较好。如果 stop level value 远远低于 start value，在 flushing 时会导致磁盘拥塞
长期以来，Redo log 的 IO 瓶颈一直是困扰 OLTP 系统的一大难题，因为 Redo 的写入延迟直接拖累了整个系统 甚至整个集群的响应速度。
在传统的数据库架构中，一些 DBA 会将读写延迟较低的小块存储单独划分给 Redo， 从 11204 开始，Oracle 提出一种新的方案，在闪存区域中专门为 Redo 开辟一块区域，用于存储临时 Redo。
将列存储落到 Flash Cache，提高频繁操作的列存储对象的写 IO
- Change Tracking File: 在增量备份中检测块的 变化，并记录到文件中。记录单位为 block。
- wallet：Oracle Wallet 是用来存储密钥的容器。简单点来说就是个密码箱，通过这个密码箱，可以使原来需要输入密码的场合能够实现免输密码使用，从而保护了账号口令等敏感信息，使得安全性得到了提高，而且更加方便使用。
应用容器 Application Container 是 12.2 提出来的新的组件，将同一应用下的数据库系统划分到一个子容器中，在保证多租户同一管理的情况下，实现相对的业务隔离和数据安全。
从 12.2 开始，每个 PDB 都拥有自己的 undo 表空间。消除了多个 PDB 间的争用，若要进行闪回或者基于时间戳的恢复，只需要在自己的 undo 数据中寻找，提高效率。
1、从 PDB$seed（或者 application root）创建：通过文件复制的方式
2、现有 PDB 经过 hot clone 创建
注：在 12.1 中，基于一个 PDB 创建新的 PDB 的时候，需要将原库以 read only 的方式打开。
而在 12.2 中，原库可以持续进行 DML 操作，并不受影响。
克隆完成以后，数据会持续刷新到新库。
3、来自其他 CDB 中的 PDB 的迁移：Relocate
前端执行 create pluggable database from relocate 这样一条命令，后台会自动执行远程 hot clone, 做远程文件复制和同步。
4、通过 ASM 磁盘文件的 shadow copy 方式生成新的 PDB。
PDB 的内存资源管理
在多租户环境下，多个 PDB 共享内存的资源，当一个 PDB 需要做 buffer Cache 的寻址时，需要从整个共享的资源中寻找，非常不方便。在 12.2 中，Oracle 针对部分资源做了基于 PDB 的 domain 划分。
12.1 的内存资源的 hash 链表是这样的：
12.2 中是这样的：
更多 PDB 的新特性
1、字符集： 在 12.2 中，若 CDB 的字符集为超集，也就是 AL32UTF8，那么支持不同字符集的 PDB。同时，通过 Proxy PDB，可以实现不同字符集的 PDB 进行查询，Proxy 将双方的字符集做识别和兼容，不会出现乱码。
多租户技术已经被广大用户广泛应用，而云和恩墨作为数据服务行业的引领者，通过 zData 解决方案与 Oracle 多租户的结合，帮助用户实现了互联网 + 时代的系统云化转型。
关于多租户更多的新特性详解，请参考
YH9:Oracle Multitenant 知识库
多租户技术已经被广大用户广泛应用，而云和恩墨作为数据服务行业的引领者，通过 zData 解决方案与 Oracle 多租户的结合，帮助用户实现了互联网 + 时代的系统云化转型。
文章来自微信公众号：数据和云
