亚马逊AWS官方博客

Oracle On EC2 多租户架构轻松、高效整合数据库上云

当今,云计算以其独特的魅力受到众多企业的青睐, 很多行业标杆企业在其数字化转型的道路上已经品尝到了上云带来的好处,纷纷开始把自己的数据中心的所有业务系统进行整合系统化上云,以此达到降本增效、提高业务敏捷性的效果,从而提升企业的竞争力,实现快速转型。

那么,作为业务系统的核心组件,数据库的整合需要倍加关注。由于历史及其他多种原因,通常在一个企业内部会大量使用 Oracle 数据库 ,有的企业在本地机房甚至会有成百上千个 Oracle 数据库单独运行在每个服务器上。而每台服务器的资源平均资源利用率不到 10%。在这种情况下,一是硬件资源没有得到充分的利用,二是软件许可存在极大的浪费,三是大规模的软硬件资源维护变得低效,运维成本极高。因此 Oracle 数据库整合上云后,这三类问题可迎刃而解。如下图所示:

通过整合本地数据库中心的 CRM, HR, OA, Retail 四个数据库到云上一个多租户架构的 Oracle 数据库上。可以具有下列的优势:

  • 降低成本

通过将分散在各个硬件服务器上的多个数据库实例整合进云中单个数据库实例,并高效共享计算和内存资源,您可以降低硬件和维护成本。例如,单个服务器上的100 个 PDB 共享一个数据库实例。需要特别指出,整合后数据库软件许可成本将极大地降低,整合密度越高,许可节省的成本越明显。

  • 化管理

统一管理多个数据库,统一备份、统一升级、统一版本、大量减少数据库管理任务。

  • 职权分离

用户帐户是通用的,这意味着它可以连接到任何具有权限的容器,也可以连接到本地的,这意味着它仅限于特定的 PDB。CDB 管理员可以使用公共用户帐户来管理 CDB。PDB 管理员使用本地帐户管理单个 PDB。由于权限包含在授予该权限的容器中,因此一个 PDB 上的本地用户对同一 CDB 内的其他 PDB 没有权限。

  • 资源管控

在多租户环境中,一个问题是运行在同一台计算机上的 PDB 之间的系统资源争用。另一个问题是限制资源使用以获得更一致、更可预测的性能。为了解决此类资源争用、使用和监视问题,可以使用 Oracle 数据库资源管理器控制和协调好资源。

整合既然能带来如此多的好处,我们应如何进行规范化整合呢?首先需要一个标准的流程,使用流程来规范化迁移,保障迁移成功。如下图所示:

首先是系统调研,对系统进行全面的调研,包括对基本信息收集、数据库特性信收集、容灾备份信息收集,数据库工作负载信息收集以及应用依赖信息收集。信息收集后对其进行充分的评估,然后设计出满足业务需求的数据库架构,初始的实例和存储大小,以及权限与安全的解决方案(如评估过程中需要涉及应用系统改造则需要单独设计系统改造方案)。迁移方案设计完成后需要进行系统测试,测试通过后则需要对生产系统进行正式的迁移和割接。最后是交付给客户进行运维。

对于 Oracle 多租户架构的整合,除了需要遵循上述流程以保证迁移成功,我们还必须去选择符合业务需求的迁移方法和工具以提高迁移效率。对 Oracle 多组户架构进行离线迁移整合常见的方式有如下三种方案——

远程克隆 PDB 迁移整合

方案有如下特点:

  • 迁移整合简单: 通过简单配置 Database Link 就可以实现数据库的单指令迁移和整合
  • 迁移整合性能弹性可控:通过配置指定并行度控制复制性能
  • 轻量级数据校验:PDB 级别的完整物理迁移整合,避免了数据库的深入校验的必要性
  • 有数据库版本要求:要求 12C 以上的版本

表空间传输迁移整合

方案有如下特点:

  • 迁移整合操作复杂:需要进行预检查,导出导入表空间元数据然后再传送数据文件
  • 迁移整合性能弹性可控:可用通过脚本进行并行导出传送以及导入
  • 轻量级数据校验:表空间级别物理迁移整合,避免了数据库的深入校验的必要性
  • 提供跨数据库版本的迁移整合能力

导出导入迁移整合

方案有如下特点:

  • 迁移操作相对复杂:需要导出生成 dmp 文件,传送 dmp 文件,然后再导入到目标数据库
  • 迁移整合性能弹性可控:通过配置指定并行度控制导出导入性能
  • 需要数据和对象的校验:Shema 级别的逻辑迁移整合, 整合后需要校验数据和数据库对象的完整性
  • 可跨版本进行迁移整合:可通过指定版本兼容性参数完成跨版本迁移整合

通过上述三种迁移整合方案的描述,我们不难看出,第一种远程克隆 PDB 迁移整合方案可以更轻松,高效地把本地数据中心的 Oracle 迁移整合进云中的多租户架构的 Oracle 数据库中。下面为远程克隆 PDB 迁移整合的具体步骤:

版本要求:

源数据库版本 迁移工具 目标数据库版本
12C 及以上 Cloning  a PDB From Remote PDB  Or Non-CDB 12C 及以上

(本文测试环境源和目标端数据库都采用 19.3.0.0 EE,数据库字符集都是 AL32UTF8)

源端数据库操作

1  在源端数据库上创建用于复制的用户

sqlplus / as sysdba
ALTER SESSION SET CONTAINER=pdb5;
CREATE USER remote_clone_user IDENTIFIED BY remote_clone_user;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE TO remote_clone_user;

2 修改源端 pdb 数据库为只读模式

CONN / AS SYSDBA
ALTER PLUGGABLE DATABASE pdb5 CLOSE;
ALTER PLUGGABLE DATABASE pdb5 OPEN READ ONLY;
EXIT;

目标端数据库操作

1 在目标端主机上配置 tnsnames.ora

 CRMPDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 172.31.37.66)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = crmpdb.ap-northeast-1.compute.internal)
    )
  )

2 在目标数据库上配置 database link 指向源端 pdb 数据库并测试

create database link clone link connect to remote_clone_user identified by remote_clone_user using 'crmpdb';
测试clone link
DESC user_tables@clone_link

3 开始复制(复制要求 ofm 文件管理模式否则需要 FILE_NAME_CONVERT 参数)

create pluggable database  CRMPDB from CRMPDB@clone_link  parallel xx;

如果数据库较大,可以指定并行度用于加速复制过程

如果是从 Non-CDB 复制数据库需要将 CRMPDB 替换成 NON$CDB

CREATE PLUGGABLE DATABASE db12cpdb FROM NON$CDB@clone_link;

验证迁移完成的数据库

SELECT name, open_mode FROM v$pdbs WHERE name = 'CRMPDB';
ALTER PLUGGABLE DATABASE CRMPDB OPEN;

验证数据:

总结

利用 Oracle 多租户架构特性,整合本地数据中心众多数据库上云,不仅整合过程轻松、高效。整合后的客户收益也非常的可观。首先是许可成本得到了极大的降低,同时其硬件资源得到了充分的利用。其次,在云中整合后由于需要维护的主机和数据库软件的套数的减少,运维管理管理也变得简单快捷。

参考文档

1. Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1)

2. 12c Multitenant Container Databases (CDB) and Pluggable Databases (PDB) Character set restrictions / ORA-65116/65119: incompatible database/national character set (Character set mismatch: PDB character set CDB character set) (Doc ID 1968706.1)

3. How to Convert Non-CDB to PDB – Step by Step Example (Doc ID 2288024.1)

4. http://blog.itpub.net/26736162/viewspace-2222369/

本篇作者

吴胜华

AWS 数据迁移顾问,负责基于 AWS 数据库的迁移解决方案设计和实施。拥有 18 年以上数据库经验,擅长数据库架构设计、性能优化、迁移上云。具有丰富的项目实战经验。