Oracle 12cR2数据库（Oracle12.2）新特性之一：高可用性（Availability）

【转载】12.2的发布，让很多技术爱好者迫不及待要尝尝鲜了，然而众多的新特性却可能让我们无所适从，为此我们节选12.2中一些重要的新特性，将在接下来的几期晨读中分享给大家，希望大家能够在12.2的应用中游刃有余。[color=#696969]注：原文章内容由云和恩墨整理。若需要了解更多，请查阅官方文档。
1、[size=14px]Multi-Instance Redo Apply ([size=14px]多实例redo应用)[color=rgb(62, 62, 62)]在Oracle Database 12.2 之前的版本上，对于物理standby 数据库，将Redo应用于Oracle RAC standby数据库上的单一实例是受限的。在12.2版本上， redo apply现在可以根据用户的不同配置在部分或者所有standby实例上运行。 如果需要，可以通过添加其他standby实例来实现Redo Apply性能扩展。
[color=rgb(62, 62, 62)]有了这个新功能，可以为任何主要工作负载实现恢复时间上的目标。 这对于大型Oracle RAC集群的客户和Oracle Exadata的客户都有重要的意义。 Oracle Active Data Guard用户还可以实时访问当前信息。 以这种方式扩展应用性能意味着standby数据库始终是最新的，即使在有很多个节点的Oracle RAC集群的逻辑卷上也能保证信息的实时性。[color=rgb(62, 62, 62)]
2、Oracle Data Guard for Data Warehouses(用于数据仓库的Oracle Data Guard)[color=rgb(62, 62, 62)]在以前的版本中，在primary数据库上使用NOLOGGING选项进行直接加载，一直很难更新对应的standby数据库上的数据。在物理standby数据库上，数据块被标记为不可恢复，并且尝试读取它们的任何SQL操作都将返回error。 对于逻辑standby数据库来说，SQL apply将会因为redo失效的错误而被迫中止。
[color=rgb(62, 62, 62)]现在在2.2 中，物理standby数据库中的块，被记录在standby数据库的控制文件中，可以使用如下命令以简单方便的方式进行修复[indent]RMAN RECOVER DATABASE NONLOGGED BLOCK[/indent][color=rgb(62, 62, 62)]
3、Data Guard Broker PDB Migration or Failover Data Guard 代理PDB 迁移或故障转移)[color=rgb(62, 62, 62)]在多租户代理配置中，可能需要将生产PDB从一个container数据库移动到驻留在同一系统上的另一个container数据库。当生产PDB发生故障，container数据库和所有其他PDB正常工作时，用户还可能需要将PDB从Data Guard standby数据库故障切换到新的生产container数据库。[color=rgb(62, 62, 62)]
[color=rgb(62, 62, 62)]在12.2中将有简单的办法来实现整个过程。[color=rgb(62, 62, 62)]使用命令：Data Guard Broker DGMGRL命令：[indent]MIGRATE PLUGGABLE DATABASE[/indent][color=rgb(62, 62, 62)]
[color=rgb(62, 62, 62)]该命令能够从primary数据库中拔出PDB，并将其插入主系统上的另一个container数据库，以及通过从Data Guard standby 容器中拔出PDB来故障切换单个PDB数据库，并将其插入standby系统上的现有新primary container数据库。在这两种情况下，正在移动的PDB的数据文件必须驻留在对当前容器数据库和目标container数据库均可见的存储上。[color=rgb(62, 62, 62)]
[color=rgb(62, 62, 62)]当以此方式迁移PDB时，必须将数据文件从新container数据库复制到其Data Guard standby数据库，并且必须为新PDB启用恢复。当将PDB从Data Guard standby数据库故障转移到新的primary container数据库时，Data Guard备用数据库和目标容器数据库上的数据库版本必须相同。当在主系统上将PDB从一个container移动到另一个container时，版本可以等于或高于当前container，但必须升级PDB才能使用它。
[color=rgb(62, 62, 62)]使用新的Data Guard Broker命令MIGRATE PLUGGABLE DATABASE，可以轻松地将单个PDB从一个container数据库移动到另一个container数据库，或将单个PDB从Data Guard standby 数据库故障切换到新的生产container数据库。[color=rgb(62, 62, 62)]
4、Online Table Move(在线表移动)[color=rgb(62, 62, 62)]非分区表可以作为联机操作移动，而不阻止任何并发DML操作。 表移动操作现在还支持自动索引维护作为移动的一部分。
[color=rgb(62, 62, 62)]对非分区表的数据维护不需要任何维护窗口，因为它不会影响任何DML或查询操作。[color=rgb(62, 62, 62)]
5、Partitioning: Table Creation for Partition Exchange(创建分区表和分区交互)[color=rgb(62, 62, 62)]新的DDL命令（CREATE TABLE FOR EXCHANGE WITH）允许创建与分区表的形状完全匹配的表，因此能够进行分区表的分区或子分区交换。 请注意，索引不是作为此命令的一部分创建的。
[color=rgb(62, 62, 62)]创建能够进行分区或子分区交换的表对于已经进行了各种结构更改和重组的旧表而言可能是一个乏味的任务。 使用这个新的DDL，任务变得非常简单和直接实现。 与CREATE TABLE AS SELECT命令相比，它还向此类操作添加了一些隐式业务上下文。[color=rgb(62, 62, 62)]该命令举例：CREATE TABLE sales_exchange TABLESPACE my_sales_tblspace FOR EXCHANGE WITH TABLE sales;
6、Partitioning: Filtered Partition Maintenance Operations(分区：过滤分区维护操作)[color=rgb(62, 62, 62)]分区维护操作现在可以与数据过滤结合使用。 例如，分区可以被压缩并移动到不同的表空间，但是只有满足特定过滤标准的数据被实际移动。
[color=rgb(62, 62, 62)]具有数据过滤的分区维护操作结合了两个最常见的数据维护操作。 这种组合不仅使得分区维护操作更加灵活和强大，而且与两个单独的数据管理操作相比，它使得其更高性能和更少的资源密集。
7、Disk Space Check During RECOVER TABLE Operation(RECOVER TABLE操作期间的磁盘空间检查)[color=rgb(62, 62, 62)]Oracle RMAN表恢复（RECOVER TABLE）功能会隐式创建辅助实例，还原和恢复表空间或数据文件时会执行执行表恢复操作。 但是，如果没有足够的空间来创建实例，则返回操作系统级错误。 此增强功能在RMAN执行表恢复之前对辅助实例的可用磁盘空间进行预先检查。
[color=rgb(62, 62, 62)]RECOVER TABLE是一种数据库级别的操作，可防止由于磁盘空间问题导致的操作系统级错误。 实现此功能时，如果没有足够的空间来执行操作，则会提前通知用户，并且会中止RECOVER TABLE操作。[color=rgb(62, 62, 62)]
8、Data Guard DUPLICATE Command Enhancements(Data Guard DUPLICATE命令增强)[color=rgb(62, 62, 62)]该功能包含两方面的增强：[indent][list]
[*]Far Sync Standby Support 远程同步Standby 支持 从Oracle Database 12c版本1（12.1）开始，引入了一个称为远程同步备用的standby数据库的新变体。 此增强的目标是允许用户使用DUPLICATE命令创建此类型的standby数据库。
[*]Normal Duplicate Database From Physical Standby Database 从物理standby数据库正常复制数据库
[/indent][color=rgb(62, 62, 62)]
[color=rgb(62, 62, 62)]目前，当目标数据库是物理standby数据库时，不可能创建数据库的副本。只有当连接到物理standby数据库并将此作为目标数据库时，才能创建物理standby数据库。 [color=rgb(62, 62, 62)]
[color=rgb(62, 62, 62)]DUPLICATE功能增强的目的是是排除类似限制，并且当目标数据库是primary数据库或物理standby数据库时，会允许同一组操作。 此增强功能利用现有物理standby数据库进行更多用途，从primary数据库卸载。
9、Data-Dependent Routing(数据相关路由)
[color=rgb(62, 62, 62)]Java数据库连接（JDBC），Oracle调用接口（OCI）和Oracle Data Provider for .NET（ODP.NET）客户机能够识别连接字符串中指定的分片键。 连接层中的分片拓扑高速缓存用于将请求直接路由到数据所在的分片。
[color=rgb(62, 62, 62)]JDBC客户端的Oracle通用连接池（UCP）还能够识别连接URL中指定的分片键。 分片拓扑高速缓存用于将连接直接路由到数据所在的分片。 Oracle UCP还支持非Oracle应用程序客户端（如Apache Tomcat，WebSphere等）与Oracle分区一起使用。数据相关路由为为分片式数据库架构设计的应用程序提供高性能数据访问和可用性。[color=rgb(62, 62, 62)]
10、Automatic Deployment of Oracle Data Guard(自动部署Oracle Data Guard)[color=rgb(62, 62, 62)]在具有Oracle Data Guard快速启动故障转移（自动数据库故障转移）的分区之间进行Oracle Data Guard物理复制时，部署是自动的。 这是单个分片的默认Oracle高可用性（HA）配置。[color=rgb(62, 62, 62)]业务优势包括：[indent][list]
[*]自动部署减少了管理开销。

[*]物理数据库复制使用实时Oracle数据验证提供最强大的数据保护。
[*]支持异步或同步复制，实现接近零或零数据丢失保护。
[*]自动数据库故障转移为服务器，数据库，网络和站点中断提供高可用性。
[*]只读工作负载可以在用于HA的所有分片副本之间进行负载平衡，以便在使用Oracle Active Data Guard时实现额外的可扩展性。
[/indent]
11、Creating Data Guard Standbys With Database Creation Assistant[color=rgb(62, 62, 62)](使用DBCA创建Data Guard Standby)
[color=rgb(62, 62, 62)]12.2中可以通过DBCA，通过命令行界面从现有primary数据库创建Oracle Data Guard standby数据库。 此功能减少了在Oracle Enterprise Manager之外创建standby数据库时必须执行的手动步骤。 此外，DBCA允许在standby数据库创建结束时运行自定义脚本。

[color=rgb(62, 62, 62)]此功能使用户能够以非常简单的方式从命令行界面对standby数据库的创建进行脚本化。[color=rgb(62, 62, 62)]
12、Statement-Level Routing and Cross-Shard Queries(SQL级路由和数据库分片间查询)[color=rgb(62, 62, 62)]此功能支持访问存储在多个分片上的数据的查询和事务的路由和处理，还支持不指定分片键的查询的路由。

[color=rgb(62, 62, 62)]该功能实现跨分片的简单的数据汇总和报告。使任何数据库应用程序能够灵活地在表被分片或复制的系统中执行SQL语句（包括SELECT和DML），不需要指定运行查询的分片。 与指定分片键的OLTP事务相比，该功能接受更低的性能级别。