数据库实例与文件系统
几个重要的进程和内存组件

  • 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的工作原理如下:

解读Oracle12.2体系架构:Filesystem与Multitenant

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中的数据写满或者写到一定程度就需要把数据写入磁盘,留出空间给新的操作数据。

Flash Cache的flushing过程

缓存内数据写入磁盘称为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时会导致磁盘拥塞

Smart Flash Logging

长期以来,Redo log的IO瓶颈一直是困扰OLTP系统的一大难题,因为Redo的写入延迟直接拖累了整个系统 甚至整个集群的响应速度。

在传统的数据库架构中,一些DBA会将读写延迟较低的小块存储单独划分给Redo,从11204开始,Oracle提出一种新的方案,在闪存区域中专门为Redo开辟一块区域,用于存储临时Redo。

 In-Flash Column SCAN

将列存储落到Flash Cache,提高频繁操作的列存储对象的写IO

  • Change  Tracking File:在增量备份中检测块的 变化,并记录到文件中。 记录单位为block。
  • wallet:Oracle Wallet是用来存储密钥的容器。简单点来说就是个密码箱,通过这个密码箱,可以使原来需要输入密码的场合能够实现免输密码使用,从而保护了账号口令等敏感信息,使得安全性得到了提高,而且更加方便使用。

多租户解决方案

Application Container

应用容器Application Container是12.2提出来的新的组件,将同一应用下的数据库系统划分到一个子容器中,在保证多租户同一管理的情况下,实现相对的业务隔离和数据安全。

PDB拥有自己的undo表空间

从12.2开始,每个PDB都拥有自己的undo表空间。消除了多个PDB间的争用,若要进行闪回或者基于时间戳的恢复,只需要在自己的undo数据中寻找,提高效率。

PDB的灵活创建方式

1、从PDB$seed(或者application root)创建:通过文件复制的方式

2、现有PDB经过hot clone创建

 注:在12.1中,基于一个PDB创建新的PDB的时候,需要将原库以read only的方式打开。

解读Oracle12.2体系架构:Filesystem与Multitenant

而在12.2中,原库可以持续进行DML操作,并不受影响。

解读Oracle12.2体系架构:Filesystem与Multitenant

 

解读Oracle12.2体系架构:Filesystem与Multitenant

克隆完成以后,数据会持续刷新到新库。

3、来自其他CDB中的PDB的迁移:Relocate

解读Oracle12.2体系架构:Filesystem与Multitenant

前端执行 create pluggable database from relocate这样一条命令,后台会自动执行远程hot clone,做远程文件复制和同步。

4、通过ASM磁盘文件的shadow copy方式生成新的PDB。

解读Oracle12.2体系架构:Filesystem与Multitenant

PDB的内存资源管理

在多租户环境下,多个PDB共享内存的资源,当一个PDB需要做buffer Cache的寻址时,需要从整个共享的资源中寻找,非常不方便。在12.2中,Oracle针对部分资源做了基于PDB的domain划分。

12.1的内存资源的hash链表是这样的:

解读Oracle12.2体系架构:Filesystem与Multitenant

12.2中是这样的:

解读Oracle12.2体系架构:Filesystem与Multitenant

更多PDB的新特性

1、字符集:在12.2中,若CDB的字符集为超集,也就是AL32UTF8,那么支持不同字符集的PDB。同时,通过Proxy PDB,可以实现不同字符集的PDB进行查询,Proxy将双方的字符集做识别和兼容,不会出现乱码。

解读Oracle12.2体系架构:Filesystem与Multitenant

多租户技术已经被广大用户广泛应用,而云和恩墨作为数据服务行业的引领者,通过zData解决方案与Oracle 多租户的结合,帮助用户实现了互联网+时代的系统云化转型。

关于多租户更多的新特性详解,请参考
YH9:Oracle Multitenant 知识库
多租户技术已经被广大用户广泛应用,而云和恩墨作为数据服务行业的引领者,通过zData解决方案与Oracle 多租户的结合,帮助用户实现了互联网+时代的系统云化转型。

文章来自微信公众号:数据和云

以上就是了解Oracle12.2的体系架构:文件系统与多租户的详细内容,更多请关注小闻网其它相关文章!

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。