当今的世界，是云的世界。

而关系型数据库管理系统 (RDBMS) 也正在发生一场重大变革 ---- 从固定的服务器和存储转向灵活的云部署，从存储优化的数据库管理转向内存优化的数据库管理。

新一代的数据库环境已经来临。传统数据库中的Oracle也发布了12C的版本，经过一段时间的使用和测试，我们感觉Oracle Database 12C能为我们提供进行创新的基础，并企业以安全、可靠且经济高效的方式进行IT管理。本文主要探讨12C中的几个对新特性带来的影响。

Oracle12c引入了一种新的多租户架构（Multitenant），该架构有助于轻松部署和管理数据库，并能使用户充分利用云计算所提供的资源共享、管理灵活性和成本节省等优势。

Oracle新的多租户架构（Multitenant）为云而设计，它带来的新架构可以简化整合并提供基于模式的高密度的整合，然而却无需更改现有应用程序。它可带来将多个数据库作为一个管理的所有好处，同时还能保持不同数据库的相互隔离和资源控制。在这个架构中，单个容器数据库可以托管多个“可插拔”数据库。对于应用程序而言，每个整合或“插入”到多租户容器中的数据库感觉就和以前版本的Oracle数据库一样。对可插拔数据库的访问与对现有Oracle数据库的访问一样，并且DBA可以控制所有整合数据库使用资源的优先级。

整合多个数据库意味着DBA需要管理的数据库数量变少，对IT部门来说，即使不是数千个数据库，管理数百个数据库也是相当寻常的情况，这些数据库中的每一个（无论是生产、测试还是开发数据库）都需要进行维护。

将多个可插拔数据库整合到一个多租户容器中，可以大大减少所需升级活动的数量。现在只需要在容器级应用补丁和升级，不需要对每个可插拔数据库应用补丁和升级。同时，我们还可以灵活地创建新的修补和/或升级的容器数据库，可以有选择地将数据库从旧的容器数据库中拔出，然后插入新升级的容器数据库中。

新的可插拔架构只需在多租户容器级执行备份，不必对数据中心的每个独立数据库分别进行备份。这意味着DBA管理的备份减少，因为对容器数据库中每个可插拔数据库的备份都是自动进行的。

将多个可插拔数据库作为一个管理的另一个好处是维护的备用数据库减少。使用12C，将在容器级传输和应用重做日志，因此，可以完全保护每个整合到容器中的可插拔数据库免受站点中断影响，但是这里也带来一个负面的影响，这有可能会带来备份空间的浪费。此外，使用ADG的用户还可以将自己的备用可插拔数据库用于生成报表及其他活动用途。

尽管通过整合多个数据库可获得诸多好处，我们还是应该全面考虑数据库整合各个方面的问题。一个显而易见的问题是，在这种新的多租户架构中如何确保资源使用的优先级？毕竟，如果数据库应用程序不断地争用可用系统资源，那么将多个数据库作为一个管理带来的许多好处将会迅速消失，用户性能服务级别也会开始下降。我们可以使用12C的资源管理特性，在可插拔数据库级方便地定义资源使用优先级，虽然目前Oracle Database 12C在多个可插拔数据库之间的IO资源隔离依然存在不足，但在CPU、内存等资源的隔离依然好于其他数据库，使用可插拔数据库对资源的隔离，依然是一个比较合适的选择。

IMDB是12C的一个新选件，它提供了一个独特的双格式架构。可以使用传统的行格式和新的内存中列格式同时在内存中表示数据库表。12C自动维护行格式和列格式间的完全的事务一致性，优化器自动将分析查询路由到列格式，将OLTP查询路由到行格式，从而以透明的方式提供了两者之最佳性能。

IMDB对内存中扫描、内存中联接和内存中聚合采用最新的算法。这些内存中优化能极大的提升分析类业务的查询速度，在同样的硬件环境下，对于分析类业务的性能提升显著。

IMDB不要求将所有数据库数据都放在内存中。用户可以选择只将性能敏感的表、分区或列填充到内存中。性能不太敏感的数据则可以存放在低成本的闪存或磁盘上。对存放于所有三个层（内存、闪存和磁盘）中的数据透明地执行查询使IMDB可以与任何大小的数据库结合使用。

利用IMDB时无需对现有应用程序进行更改。它与12c的所有功能完全兼容，包括Multitenant、最高可用性架构和数据库安全性特性。

12C引入了新的预防、检测和管理控制，这些控制可以帮助用户加强其企业数据的保护。

• 数据编辑：通过在数据库（而非应用程序）中定义和实行数据编辑策略，无需修改应用程序，用户就可以有效地防止在应用程序屏幕和报告上显示诸如身份证号、生日和银行账号等敏感数据。

   

• 全面审计：这种审计架构既是基于策略的也是上下文感知的，并设置了新角色来管理审计策略和查看审计数据。这一新架构将现有审计线索统一为单个审计线索，从而简化了对数据库生成的审计数据的管理，同时提高了它们的安全性。

   

• 权限分析：能够跟踪连接到数据库的特定会话或所有会话的权限及角色使用。权限分析有效地记录所使用的权限和角色，并允许安全的个人、数据库管理员和审计人员通过设计能准确反应日常业务和管理活动所需权限的最小权限模型来保护其数据库。 

尽管Hadoop和分布式键值对存储等技术可以帮助企业获取大量低密度数据，但是，如果能结合更多传统企业数据对大数据进行分析，则能实现大数据的真正价值。

12C为提供了一个数据库仓储平台，该平台可存储和管理海量数据，并可使用熟悉的SQL接口和诸如R等统计框架来处理从简单查询到复杂分析的每件事情。与以往不同，用户不再需要不断将数据从数据仓库移动到数据集市和专用处理服务器，而是可以将企业数据和大数据全部整合到同一个数据仓库中以支持其所有用户的业务智能和分析需求。 

Oracle Database 12c投产到我们部分生产系统已有两年,确实为我们提供了较多的便利。

首先，它提供的多租户架构，让我们能够快速方便的新增数据库，免去复杂的环境配置、参数配置环节。同时，用户可以登陆一台主机，便可查看各个PDB数据库状态及监听状态，便于日常监控管理。

其次，在12c之前的版本中，Varchar2和nVarchar2数据类型的最大长度是4000 字节，一旦超过4000字节，将以out of line方式存放。12c提供的32K String功能，使得Varchar2和nVarchar2类型最大可以支持到 32K。虽然底层存储方面是采用类似LOB字段的out of line的方式存放，但对于前端开发者来说，可以像使用普通的Varchar2字段一样使用32K Varchar2，而不用像使用LOB字段那样需要写专门的代码来访问LOB字段的内容。

此外，在12C中，多个PDB可以共享process，undo等资源，通过将业务高峰期错开的数据库置于一个CDB中，使系统资源得到了充分的利用。

但是，在日常运维中，我们也发现了12c的一些不足。例如，当收到undo表空间使用率告警时，DBA需要到CDB里查看各PDB UNDO使用率，然后再根据使用率，到PDB去查看其具体会话详情, 且PDB中只能查看自身UNDO使用情况，而无法查看其占总UNDO的百分比，给日常问题管理带来较多不便；在12c中，当一个节点的数据库进程出错时，会导致该节点所有的pdb无法继续提供服务。当该节点恢复正常的时候，为了能够让分节点访问的业务正常访问节点，需要启停更多的业务进程，延迟了故障恢复时间等。

 总结 

在云化架构到来的时候，我们可以尝试依据自己的业务对Oracle Database 12C的相关新特性进行测试，并选择最合适自己企业的特性进行生产实践。