Oracle 21c新特性--基于PDB的ADG

由 ·  

0    209    1

Tags：

👉 本文共约5196个字，系统预计阅读时间或需20分钟。

本页目录 隐藏
简介
传统的CDB架构层的Data Guard
什么是PDB层的Data Guard？
PDB层Data Guard架构
PDB层Data Guard的局限性
DGPDB基础功能验证
参考
相关文章

简介

Oracle数据库作为一款企业级核心数据产品从诞生之时就对高可用和容灾进行探索和努力。1996年Oracle发布了7.3版本，其中有一个具有跨时代的功能：Standby Database，那时Standby Database（备库）可以看成是主库的一个基于文件的备份。主库与备库的同步只能依赖于归档日志，而归档日志依赖于第三方工具从主库传输到备库。备库只能启动到MOUNT阶段，通过激活命令将数据库从备库状态转为主库状态。1998年Oracle发布了8.1.5版本，Standby Database在这个版本中得到了质的飞越，对它的运维变得更加简单，Standby Database不仅仅有容灾功能，同时还引入了只读功能，使得原来在主库环境中消耗大量资源的报表业务可以迁移到备库端运行。

经过20多年的不断努力和推陈出新，Oracle以DG和RAC技术为主要基石，在Extended RAC，ASM，Sharding，Active Data Guard，Site Guard，Flashback，RMAN+ZDLRA，Global Data Service，Application Continuity，Transaction Guard，Online Redefinition，Edition-based Redefinition等技术加持下已形成完备的数据保护体系，帮助众多关键客户实现了高水平的最高可用性架构。根据2022年4月Oracle发布的最新MAA参考架构，MAA架构已经细分为了基于本地部署、Exadata部署、云端部署三大平台。Oracle MAA 最佳实践定义了四种高可用性参考架构（白金级、黄金级、白银级和青铜级）来解决各行各业中大大小小企业的各种可用性和数据保护需求。

在此基础之上，随着2022年7月DGPDB特性的发布，我们将被带入到完美MAA架构的”最后一公里“。

什么是DGPDB特性，我们不得不从它的基础环境多租户开始说起，在2013年发布的12c中Oracle引入了多租户架构，深刻的改变了Oracle数据库的原有架构，打开了数据库新的整合能力和创建周期，经过多年的发展，多租户架构不断增强，在不同的版本中都引入了新的特性，包括热克隆，可刷新的克隆，在线迁移等等。

测试数据表明，多租户在数据库整合能力上与使用相同系统资源（CPU、内存和 I/O）的单实例数据库相比可实现：

  • 整合密度提高 50%（整合的数据库数量），同时每个数据库可达到相同的吞吐量。
  • 整合相同数量的数据库时，总吞吐量增加80%。

从另一个角度看，这些测试证实了Oracle多租户架构如何带来真正的硬件和软件许可成本的节省。

相信在很多需要实现”两地三中心“架构的客户中大家都反映过一个共同的问题，多租户整合能力变强，但基于ADG技术的复制和切换还是以CDB实例为单位。CDB实例内不同的PDB往往对应不同的业务系统，业务系统的切换需求实际是“众口难调”，例如，按照银行业监管部门要求，有的业务系统需要一年三次切换，有的一年一次切换就可以，有的可能三年一次就可以，有的管理类系统不需要切换；同样的，在某个业务系统出现故障，需要切换它对应的数据库时，PDB对应的CDB实例不得不整体切换，势必会影响其他业务系统的正常运行，所以从切换演练和故障切换的角度来说，传统的基于CDB的ADG切换其实带来了另一种风险和不确定性，由此可见，多租户虽然实现了高效的整合和有效的隔离，但整合的灵活性和跨设备资源的利用率都还有待加强。在同城双中心之间网络带宽和时延都比较理想的情况下，PDB级别不具备ADG切换的功能离大家心目中真正的“双活”，甚至“多活”还差了那么一点点，达不到大家心中对技术”完美“的追求。

2022年7月，Oracle在21.7版本引入了PDB层的Data Guard可用性特性（简称：DGPDB），这个多租户新的Data Guard特性将用来替代传统的CDB架构层的Data Guard。它允许客户实施高效的CDB 层的Data Guard，或者更灵活的PDB层Data Guard（在每个PDB上配置、维护和独立的Switchover、Failover操作）。

传统的CDB架构层的Data Guard

Oracle 21c新特性--基于PDB的ADG

CDB在传统的Data Guard配置中，一个CDB是主库，另一个CDB是备库，因此在主CDB中的每个PDB将一直是主库的状态（以读写模式打开），同样，在备CDB中的每个PDB将一直是备库的状态（最多以实时应用日志的只读模式打开），当CDB转变为新的角色，其中的所有PDB同样也跟着转换。

什么是PDB层的Data Guard？

从名称就不能看出，PDB层的Data Guard保护的是单个PDB，而不是整个CDB。它的含义是一个DGPDB配置将有两个主CDB替代一个主CDB和一个备用CDB。每个CDB都将包含以读写模式打开的PDB和在远程CDB中的目标PDB。

Oracle 21c新特性--基于PDB的ADG

在PDB层的Data Guard保护允许用户独立的Switchover或者Failover一个PDB到远程站点。在这种架构下包含两个重大的进步：

  • 客户能够在两个不同的站点之间平衡业务负载，同时维持多租户的整合优势。
  • 针对单一PDB的角色转换比在相同的CDB层转换更快。

PDB层Data Guard架构

DGPDB利用传统Data Guard相同的Redo传输服务架构。在主数据库实例，利用日志写进程(LGWR)将整个CDB的Redo信息写到在线Redo日志(ORLs)，ASYNC传输进程(TTnn)异步发送相同的信息到远程CDB的目标端存放。

接收进程(RFS)将从主库接收的Redo写到备库的Redo日志(SRLs)，到目前为止，和传统的Data Guard相比传输机制没有任何改变，同时提供精确的缺失Redo重传解决机制。

每个PDB有一个”应用”进程(TTnn)用于过滤和应用和目标PDB相关的数据。这个恢复能够在PDB层面启动和停止。

Oracle 21c新特性--基于PDB的ADG

DGPDB配置由两个主数据库组成。因此，Redo传输服务进程是对称的，如下图所示：

Oracle 21c新特性--基于PDB的ADG

跨CDB的PDB之间传输和应用对称架构

该架构会将完整的Redo流传输到远程的CDB：如果CDB中只有部分PDB受到保护，这可能会有较大的开销。因此，任何存在大量写的PDB，如果不要求受到保护，那么应该将它放到单独的CDB中，以防止多余的Redo传输。

PDB层Data Guard的局限性

第一个版本的DGPDB主要有以下的限制：

Oracle 21c新特性--基于PDB的ADG

Oracle已经计划在未来的版本中解决以上的部分限制。

DGPDB基础功能验证

下面我们通过21.7的数据库版本对DGPDB的基本功能做验证，DGPDB的配置我们使用Broker来完成，操作比较简单。

1. 安装21.7软件

下面是我们测试使用到的操作系统和数据库环境：

操作系统Centos 7.9 x86 64bit
Oracle Database单机21.7
主机oradb2101, oradb2102

2. 创建测试CDB和多个PDB。

下面是我们测试使用到的两个CDB和其中的PDB定义：

Oracle 21c新特性--基于PDB的ADG

我们会测试源端pdb2到目标端dgpdb_pdb2的实时同步，并且将原有的pdb2主库切换（Switchover）到dgpdb_pdb2作为主库，dgpdb_pdb2并不需要提前创建好。

ORACDB01源CDB包含的PDB：

3. 配置DGPDB准备工作

下面是DGPDB配置前的主要准备工作：

1) 将ORACDB01和ORACDB02两个CDB的DG_BROKER_START设置为TRUE。

2) 确保ORACDB01和ORACDB02两个CDB都使用的是SPFILE，并且都是用SPFILE启动的数据库实例。

3) 源数据库和目标数据库之间必须通过TCP/IP协议进行连接，在ORADB01和ORADB02的两个主机端配置连接到两个CDB的tnsnames.ora文件：

4 配置DGPDB

我们利用DGPDB特性实现ORACDB01下的PDB2到ORACDB02下的dgpdb_pdb2的同步作为例子，DG PDB配置由以下的内容组成：

Oracle 21c新特性--基于PDB的ADG

保护模式：最大性能；传输模式：ASYNC

1) 关于dgmgrl登录

在下面的大部分操作中Broker内部都需要在不通的CONFIGURATION之间交互，登录dgmgrl需要使用到密码，否则交互时会受到ORA-1017的报错。可以通过以下两种方式用密码登录：

方式一：

方式二：

2) 在源和目标端创建CONFIGURATION：

在ORACDB01实例创建源端CONFIGURATION：

在ORACDB02实例创建目标端CONFIGURATION：

3) 在两个CONFIGURATION之间建立连接：

在源数据库ORADB01节点执行以下命令将源端和目标端的CONFIGURAITON关联起来：

注意：执行这步之前需要将ORACDB01实例的密码文件拷贝到ORACDB02实例下，并按实例名称重命名，确保两个CDB使用的是相同的密码文件及拷贝。

在源数据库ORACDB01端执行以下命令查看关联的CONFIGURATION：

在目标数据库ORACDB02端执行以下命令查看关联的CONFIGURATION：

4) 拷贝数据文件：

在目标数据库开始恢复之前，确保源数据库相应的数据文件被拷贝到了目标数据库，可以使用RMAN或者操作系统copy命令。拷贝源和目标数据库的数据文件位置必须符合ADD PLUGGABLE DATABASE命令指定的PDBFileNameConvert子句。

测试过程我们使用的是操作系统命令进行的拷贝。

5) 启用所有的CONFIGURATION：

在源数据库ORADB01节点执行以下命令启用所有的配置：

两个主数据库的CONFIGURATION都被启用成功。

6) 创建源PDB的Data Guard（添加目标PDB）：

在目标数据库ORADB02节点执行以下命令添加DGPDB：

执行完以上命令之后，目标端的CDB中就会多一个DGPDB_PDB2的新PDB。

注意：

1. 当目标PDB被添加之后，在两个CONFIGURAITON中的主数据库之间会自动建立Redo传输。

2. PDBFileNameConvert关键字指定如何将源PDB的数据文件转换到目标PDB。

7).强制日志记录：

在ORACDB01和ORACDB02实例下执行以下命令打开FORCE LOGGING：

8).添加Standby Redo Log：

在ORACDB01和ORACDB02实例下执行以下命令添加4组Standby Redo Log：

5 验证DGPDB传输和应用

1) 查看CONFIGURATION状态：

在源端执行以下的命令查看MyConfig1配置的状态：

2) 查看源PDB状态：

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！

在源端执行以下的命令查看pdb2在oracdb01上的状态：

表明了pdb2的DGPDB角色为主库。

3) 查看目标PDB状态：

在源端执行以下的命令查看dgpdb_pdb2在oracdb02上的状态：

表明Redo传输和应用都是实时的。

6 Switchover PDB DG

Switchover常被称为计划内的切换，是最常用的ADG切换方式，下面我们通过将PDB2 Switchover到DGPDB_PDB2来验证基于PDB层的ADG切换。

1.Switchover前的必要条件：

1).主数据库的传输状态为TRANSPORT-ON，对应的目标PDB的应用状态为APPLY-ON。

2).源数据库和目标数据库都是健康状态，没有任何报错和告警。

3).在源数据库创建了Standby Redo日志。

2.检查源数据库和源PDB的状态：

执行如下的命令查看源数据库和源PDB的状态和属性：

以上命令没有任何报错。

3.查看目标数据库和目标PDB的状态：

执行如下的命令查看目标数据库和目标PDB的状态和属性：

以上命令没有任何报错。

4.执行SWITCHOVER TO命令切换到目标数据库：

执行以下的命令将主数据库从pdb2切换到dgpdb_pdb2：

Switchover切换成功，新的主数据库变成了DGPDB_PDB2。

5.验证Switchover操作：

在源端数据库执行以下的命令显示源和目标数据库切换后的DG PDB配置：

通过以上的例子我们简单验证了在Oracle Database 21.7的环境下，如何通过Broker工具实现PDB层面的DG配置与DGPDB的Switchover。当然如文章前面所说，这是DGPDB的第一个特性版本，相信在未来的版本中，DGPDB的功能会有更多的改进。

参考

https://mp.weixin.qq.com/s/A4ACvuZxZSNHGTvKGrAWxg

标签：

头像

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿，我是小麦，需要帮助随时找我哦
  • 18509239930

  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群

  • 个人微店

  • 回到顶部
返回顶部