Anton Els,Vít Špinka,Franck Pachot
Oracle Database 12c Release 2 Multitenant
EISBN 978-1-25-983609-1
Copyright © 2017 by McGraw-Hill Education.
All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including without limitation photocopying, recording, taping, or any
database, information or retrieval system, without the prior written permission of the publisher.
This authorized Chinese translation edition is jointly published by McGraw-Hill Education and Tsinghua
University Press Limited. This edition is authorized for sale in the People’s Republic of China only,
excluding Hong Kong, Macao SAR and Taiwan.
Translation copyright © 2018 by McGraw-Hill Education and Tsinghua University Press Limited.
版权所有。未经出版人事先书面许可，对本出版物的任何部分不得以任何方式或途径复制或传播，
包括但不限于复印、录制、录音，或通过任何数据库、信息或可检索的系统。
本授权中文简体字翻译版由麦格劳-希尔(亚洲)教育出版公司和清华大学出版社有限公司合作出版。
此版本经授权仅限在中国大陆区域销售，不能销往中国香港、澳门特别行政区和中国台湾地区。
版权©2018 由麦格劳-希尔(亚洲)教育出版公司与清华大学出版社有限公司所有。
北京市版权局著作权合同登记号 图字： 01-2017-3077
本书封面贴有 McGraw-Hill Education 公司防伪标签，无标签者不得销售。
版权所有，侵权必究。侵权举报电话： 010-62782989 13701121933
图书在版编目(CIP)数据
Oracle Database 12 R2 多租户权威指南 / (新西兰)安东·艾尔斯(Anton Els)， (捷克)维特·斯
普林克(Vít Špinka)， (瑞士)弗兰克·帕丘特(Franck Pachot) 著；史跃东 译. —北京：清华大学
出版社， 2018
书名原文： Oracle Database 12 Release 2 Multitenant
ISBN 978-7-302-50251-7
Ⅰ. ①O… Ⅱ. ①安… ②维… ③弗… ④史… Ⅲ. ①关系数据库系统－指南
Ⅳ. ①TP311.138-62
中国版本图书馆 CIP 数据核字(2018)第 103253 号 号
责任编辑： 王 军 李维杰
封面设计： 牛艳敏
版式设计： 思创景点
责任校对： 曹 阳
责任印制：董 瑾
出版发行： 清华大学出版社
网 址： http://www.tup.com.cn， http://www.wqbook.com
地 址：北京清华大学学研大厦 A 座 邮 编： 100084
社 总 机： 010-62770175 邮 购： 010-62786544
投稿与读者服务： 010-62776969， c-service@tup.tsinghua.edu.cn
质 量 反 馈： 010-62772015， zhiliang@tup.tsinghua.edu.cn
印 刷 者：北京鑫丰华彩印有限公司
装 订 者：三河市溧源装订厂
经 销： 全国新华书店
开 本： 170mm×240mm 印 张： 23 字 数： 451 千字
版 次： 2018 年 6 月第 1 版 印 次： 2018 年 6 月第 1 次印刷
印 数： 1～3500
定 价： 79.80 元
———————————————————————————————————————————
产品编号： 074808-01
本打算趁着农历春节之前，利用调休的时间将这本 400 多页的书翻译完毕，
谁曾想诸事缠身，一顿忙活之后，也就到了年三十。于是这本书也就只能在春
节之后搞定了。
严格来说，这本书是去年 9 月时着手翻译的，到 2018 年 2 月，又是 6 个月
的时间。回想起去年翻译《云端存储 Oracle ASM 核心指南》时，也是断断续
续忙了 5 个月才完工。留意起来，才意识到翻译这个活儿，真心是一项费时费
心的工作。平时工作繁忙，也只能挤出晚上或周末，抑或调休的时间进行翻译。
并且书中很多词句都要斟酌再三、反复琢磨，才能够将原文的意思准确表达出
来。自己写书，是对自己会的知识进行梳理；而翻译，则是研究自己不会的东
西。因此，从某种程度上来说，翻译的过程，实质上也是学习新技术、新知识
的过程。
多租户与 IMO 一道，并称为 Oracle Database 12c 的两大关键特性。此番有
幸从清华大学出版社拿到这本书的翻译权，也是件值得高兴的事情。只不过与 IMO 相关的一本书， 则被 Oracle 原厂拿去翻译了。若是这两本书都由笔者翻译，
再加上前面的 ASM，岂不是完美？可惜。
多租户技术，是 Oracle 自 12.1 版本开始引入的一项全新特性。它从根本上
改变了 Oracle 数据库长久以来的体系结构，也是 Oracle 在这个风起云涌的时代，
全面迎合云计算的具体表现。对于传统的 Oracle DBA 来说，熟练掌握 12c 版本
中的这一新特性，已经是毋庸置疑的事情。
本书的封底，指出这本书由 OCM 专家团队编写，而实际上，翻阅了本书
前言的各位读者就会知道，本书的三位作者均是 Oracle ACE。他们不仅有着多
年的实践经验，也在各大技术社区和相关会议上进行技术分享。由这样的人撰
写本书， 本书内容的实战性可想而知。本书从多租户的基本概念入手， 涵盖 CDB
与 PDB 的创建和管理、网络与服务、安全、备份和恢复、数据移动以及多租户
的诸多高级特性，尤其是深入探讨了诸多技术在多租户环境下和此前版本中的
不同之处，这对于我们的实际工作来说，显然是极具价值的内容。
当然，依然要感谢所有在本书付梓出版的过程中给笔者提供帮助的各位人
士，正是你们一直以来的关心与帮助，笔者才能够笔耕不辍、日日向前。
由于笔者才疏学浅，因此在本书的翻译过程中注定会有些错误与不足之处，
各位读者见到后，望不吝赐教。
2018 年 2 月 22 日
Anton Els 是一位 Oracle ACE，目前是 Dbvisit 软件有限公司的高级副总裁。
Anton 在数据库技术领域已经有超过 15 年的工作经验，擅长 Oracle 数据库、备
份和恢复、数据库备库、 Oracle Linux、虚拟化以及 docker 技术。 Anton 是独立
Oracle 用户组(Independent Oracle Users Group， IOUG)的活跃成员，同时也是新
西兰 Oracle 用户组(New Zealand Oracle Users Group， NZOUG)的副主席。 Anton
拥有 Oracle Database 11g OCM 证书，还拥有从 8i 到 12c 的全部 OCP 证书。同
时，他还拥有 Oracle Database 11g RAC 与 GI 管理员方向的 OCE 证书、 Red Hat
5 RHSA 证书，以及 Oracle Solaris 10 的 SCSA 证书。 Anton 经常出席相关工业
及用户组会议，例如一些行业合作会议、在日本举行的 Oracle OpenWorld 数据
库技术专场会议、 NZOUG，以及亚太和拉美地区的 Oracle 技术网络(OTN)年
会等。可以访问他的 Twitter(@aelsnz)或博客(www.oraclekiwi.co.nz)。
Vít Špinka 是一位 Oracle ACE-A， 目前是 Dbvisit 软件有限公司的首席架构
师。 Vít 在数据库技术领域也有超过 15 年的工作经验，主要擅长 Oracle 数据库
技术。 Vít 也是 IOUG 的活跃成员，并经常出席 Oracle OpenWorld、行业合伙 会议、UKOUG、DOAG 以及 NZOUG 的相关活动。Vít 拥有 Oracle Database 10g、
11g 以及 12c 的 OCM 证书，还拥有从 9i 到 12c 的 OCP 证书、Oracle Database 10g
RAC 管理员专家认证，以及 LPIC-2 Linux 网络专业认证。可以访问他的
Twitter(@vitspinka)或博客(http://vitspinka.blogspot.com)。
Franck Pachot 是一位 Oracle ACE 总监，目前是 dbi 服务公司(瑞士)的首席
顾问、培训专家以及 Oracle 技术领导人。 Franck 在 Oracle 技术领域拥有超过
20 年的工作经验。 Franck 也经常参加 Oracle OpenWorld、 IOUG 合作会议、
DOAG、 SOUG 以及 UKOUG 的活动。他是 SOUG 和 DOAG 的活跃成员，同
时还是 OraWorld 团队的荣誉成员。 Franck 拥有 Oracle Database 11g 和 12c 的
OCM 证书， 还拥有从 8i 到 12c 的所有 OCP 证书， 同时拥有 Oracle Database 12c
性能管理与优化方向的 OCE 证书。另外，他还拥有 Oracle Exadata Database
Machine 2014 实施认证证书。可以访问他的 Twitter(@franckpachot)或博客
(http://blog.pachot.net)。
Deiby Gómez 是世界上最年轻的 Oracle ACE(23 岁)以及 ACE 总监(25 岁)，
同时也是母国危地马拉的第一位 ACE 和 ACE 总监，还是拉美地区最年轻(24
岁， 2015.2)的 Oracle 11g OCM 证书获得者。他是危地马拉第一位 OCM 证书获
得者，另外也是最年轻(26 岁， 2016.4)的 Oracle 12c OCM 证书获得者，是中央
美洲第一位 Oracle 12c OCM，是最近的 2016 年度编辑选择大奖的获得者(拉斯
维加斯，内华达州)。他经常在 Oracle 全球技术大会上发表演讲，包括 2013 年
至 2016 年的 Oracle 技术网络拉丁美洲年会、合作会议(美国)以及 Oracle
OpenWorld 等。 Deiby 也是 Oracle 12cR2 beta 版本在危地马拉的第一位测试者。
Deiby 分别用英文、西班牙文以及葡萄牙文发表过多篇技术文章，这些文章发
表在 Oracle 网站和 DELL’s Toad World 上。另外，在自己的博客上，他也发表
过数百篇技术文章。他曾以杰出专家的身份出现在 2014 年 11 月份和 12 月份
的 Oracle 杂志上。同时， Deiby 也是危地马拉 Oracle 用户组(GOUG)的主席、 拉美 Oracle 用户组社区(LAOUC)的技术支持总监，他还是 OraWorld 团队的共
同发起人。目前， Deiby 拥有自己的公司 NUVOLA,S.A，为拉美地区的客户提供
Oracle 技术服务。
Arup Nanda 以 DBA 的身份工作超过 20 年，工作经验几乎涉及 Oracle 技
术的所有方面，从建模到性能调整，再到 Exadata 均有涉猎。他已经发表过大
约 500 篇文章，是 5 本书的合著者，发表过 300 多场演讲。其博客网站为 arup.
blogspot.com，他也是新手技术导师，是一名经验丰富的 DBA。他曾于 2003 年
获得过 Oracle 年度 DBA 大奖，在 2012 年获得过年度企业架构师大奖。他也是
一位 ACE 总监，同时也是 Oak Table 网络的成员。
Mike Donovan 于 2007 年加入 Dbvisit，在该公司， Mike 扮演了多个角色，
包括担任全球支持团队的领导人以及数字业务开发先驱。并且就在最近，他成
为该公司的 CTO。 Mike 对新技术有着狂热的激情，他与客户及合作伙伴一起
工作，努力搭建数据库技术与大数据等前沿技术之间的桥梁，从而创造出商业
价值。他喜欢接受挑战，会尝试探求更智能、更低成本的解决方案或替代方案。
Mike 具有技术、艺术以及客户支持和软件开发等多方面的复合背景。他对
Oracle 数据库技术极有热情，并为之工作超过 10 年的时间。他也在多个行业会
议上发表演讲，包括 OOW、 RMOUG、日本数据技术会议以及合作会议等。
Mike 作为产品 DBA 工作多年，获得了从 9i 到 12c 的多项认证。
在 Oracle Database 12cR1 版本(12.1)中， 开始引入名为“多租户”的新选项。
从那时起，新的术语“可插拔数据库”便传播开来。但是这个术语，往往意味
着对该特性或其影响并没有清晰的理解。从 12c 的第一个版本开始，多租户已
经是 Oracle 数据库中最为重大的架构变革之一，同时该选项在数据库软件中已
经被落地实施。多租户选项带来了很多新的特性，但也影响到了 Oracle DBA
进行日常管理的方式。从 12c 的第二个版本(12.2)开始，对多租户选项的可用特
性进行了更多的扩展。现在比较清楚的一点就是，旧的系统架构已经被抛弃，
多租户则已经开始生根发芽——不容忽视。
12cR2 中多租户的到来，需要 DBA 调整他们现有的思考方式，以及进行日
常管理的方式。无论是运行单租户数据库，还是运行包含大量租户的数据库，
都需要经历一个新的学习过程。所以，相比于单纯描述多租户这个新东西究竟
包含了什么内容，本书更倾向于描述与 DBA 相关的工作究竟发生了怎样的变
化，无论是核心的日常维护操作，还是一些相关的高级特性。可以将本书视为
Oracle Database 12c 的管理指南。此外，还可以学到关于这些新特性的一些实 战知识，包括语法上的改变，以及最佳实践等方面的内容。本书由三位具有丰
富 DBA 经验并具备相关认证的 DBA 撰写，并经由诸多技术精湛的审核人员进
行严格审查，从而使内容的价值得到进一步的提升。唯有如此，才能让你带着
洞察一切的激情来了解 Oracle 数据库的管理工作。
本书第Ⅰ部分介绍多租户的功能。其关键问题包括， Oracle 公司为何要引
入这一选项，并以何种方式来模仿其他数据库产品，以及该选项是否能够真正
为我们设计并部署应用的方式所需要。第 1 章专注这些问题并解释多租户架构。
第 2 章讨论容器数据库(CDB)的创建流程，以及如何正确完成这一流程。因为
在 12c 版本中，创建 CDB 已经是默认的选项，不管信不信，我们真的遇到一些
人在对 CDB 毫不知情的情况下就创建了 CDB。在对多租户的各种特性进行详
细描述之前，第 3 章会为你提供信息，让你决定究竟是选择使用 CDB 还是非
CDB 数据库，并且第 3 章还提供不同可用版本和选项的概要信息。
第Ⅱ部分将会讲述当使用多租户特性时，你的日常工作将会发生怎样的改
变。这一部分从第 4 章开始，该章关注 PDB 的创建与管理，并且也会涉及将数
据库升级到 12c 版本的内容。第 5 章将会详细讨论数据库的网络与服务。接下
来的第 6 章，则会关注另一个重要议题——安全——我们将探讨 PDB 的隔离、
用户的公共性以及加密。
第Ⅲ部分将会讨论备份与复制操作等方面的巨大提升。当然，主要是在
PDB 级别。第 7 章将会详细研究作为每一个 DBA 都应该足够熟悉的领域——
备份和恢复——以及如果需要的话，如何将数据库恢复到过去的某个状态。第
8 章讨论如何使用数据库闪回技术实现归档，以及如何在 PDB 级别实现基于时
间点的恢复。本部分的最后一章，第 9 章将会研究如何插入/拔出 PDB，以及如
何对 PDB 进行克隆、传输或在线重定位(online relocation)。
在本书的第Ⅳ部分，你将会在一个新的层次或级别上学习多租户。当对多
个 PDB 进行集成时，将不得不意识到资源管理器(Resource Manager， RM)的价
值。关于 RM，将在第 10 章进行讨论。在多租户环境中， RM 将会发挥极为重
要的作用。第 11 章将会关注如何使用 DG 来对多租户数据库进行保护。第 12
章将会讨论 CDB 中的数据共享问题。与物理克隆或同步技术相比，基于云的
解决方案，则需要数据能够以一种更具灵活性的方式来提供。我们将在第 13
章讨论逻辑复制的相关内容。
第 1 章 多租户概述 ······················3
1.1 历史课堂： IT 技术的
新时代·································4
1.1.1 通往多租户之路············ 5
1.1.2 方案集成 ······················· 6
1.1.3 表集成 ··························· 9
1.1.4 服务器集成 ··················· 9
1.1.5 虚拟化 ························· 10
1.1.6 一个实例管理多个
数据库 ························· 10
1.1.7 集成策略总结·············· 11
1.2 系统字典与多租户架构 ··· 11
1.2.1 过去：非 CDB············· 11
1.2.2 多租户容器·················· 14
1.2.3 多租户字典·················· 16
1.2.4 使用容器 ····················· 21
1.3 什么是 CDB 级别的
集成···································27 1.4 本章小结 ··························33
第 2 章 创建数据库 ····················35
2.1 创建容器数据库(CDB) ····36
2.1.1 OMF 概述···················· 36
2.1.2 CDB 创建选项 ············ 37
2.2 创建可插拔数据库
(PDB) ································52
2.2.1 使用 PDB$SEDD 创建
新的 PDB ···················· 53
2.2.2 使用本地克隆方式创建
新的 PDB ···················· 56
2.2.3 使用 SQL Developer
创建 PDB ···················· 57
2.2.4 使用 DBCA 创建 PDB··· 60
2.2.5 使用 Cloud Control
创建 PDB ···················· 61
2.3 使用 catcon.pl 脚本 ··········62
2.4 本章小结 ··························64
第 3 章 单租户、多租户以及应用
容器·······························65
3.1 多租户架构不是一个
选项 ··································66
3.1.1 抛弃非 CDB ················ 66
3.1.2 不兼容特性 ················· 67
3.2 标准版中的单租户···········68
3.2.1 数据移动 ····················· 68
3.2.2 安全 ····························· 69
3.2.3 与 SE2 集成················· 69
3.3 企业版中的单租户···········70
3.3.1 闪回 PDB····················· 71
3.3.2 PDB 的最大数量 ········· 71
3.4 使用多租户选项···············73
3.4.1 应用容器 ····················· 73
3.4.2 与多租户选项集成 ······ 76
3.5 本章小结 ··························77
第 4 章 日常管理 ·······················79
4.1 选择要使用的容器···········81
4.2 管理 CDB ·························83
4.2.1 创建数据库·················· 83
4.2.2 启动与关闭数据库 ······ 83
4.2.3 删除数据库·················· 84
4.2.4 修改整个 CDB············· 84
4.2.5 修改根容器·················· 85
4.3 管理 PDB··························86
4.3.1 创建新的 PDB ············· 86
4.3.2 打开和关闭 PDB ········· 86
4.3.3 查看 PDB 的状态 ········ 90
4.3.4 查看 PDB 的操作
历史 ····························· 90
4.3.5 在多个 PDB 上运行
SQL······························ 90
4.3.6 修改 PDB····················· 91
4.3.7 删除 PDB····················· 93
4.4 打补丁与升级···················93
4.4.1 升级 CDB ···················· 94
4.4.2 插入 ·························· 103
4.4.3 打补丁 ······················ 105
4.5 使用 CDB 级别与 PDB 级别
的参数·····························106
4.5.1 CDB SPFILE············· 106
4.5.2 PDB SFPILE 的
等价性 ······················ 106
4.5.3 SCOPE=MEMORY ··· 108
4.5.4 ALTER SYSTEM
RESET······················· 108
4.5.5 ISPDB_MODIFIABLE··· 108
4.5.6 CONTAINER=ALL ··· 109
4.5.7 DB_UNQIUE_
NAME ······················· 110
4.6 本章小结 ························ 111
第 5 章 网络与服务 ··················113
5.1 Oracle Net ······················· 114
5.2 Oracle 网络监听 ············· 114
5.3 LREG 进程 ····················· 115
5.4 网络：多线程与
多租户····························· 117
5.5 服务名称 ························ 119
5.5.1 默认服务与连接到
PDB ··························· 119
5.5.2 创建服务 ··················· 122
5.6 为 PDB 创建专用监听 ···127
5.7 本章小结 ························130
第 6 章 安全·····························131
6.1 用户、角色以及权限·····132
6.1.1 公共用户还是本地
用户？ ······················· 132
6.1.2 何为用户？ ··············· 133
6.1.3 CONTAINER=
CURRENT················· 134
6.1.4 CONTAINER=
COMMON················· 135
6.1.5 本地授权 ··················· 138
6.1.6 公共授权 ··················· 139
6.1.7 冲突解决 ··················· 140
6.1.8 保持清晰与简单······· 143
6.1.9 CONTAINER_
DATA························ 143
6.1.10 角色 ························ 145
6.1.11 代理用户················· 145
6.2 锁定概要文件
(lockdown profile)············147
6.2.1 禁用数据库选项······· 148
6.2.2 禁用 ALYTER
SYSTEM··················· 148
6.2.3 禁用特性 ·················· 150
6.3 PDB 隔离························150
6.3.1 PDB_OS_
CREDENTIALS········ 150
6.3.2 PATH_PREFIX ········· 151
6.3.3 CREATE_FILE_
DEST ························ 151
6.4 透明数据加密(TDE) ······151
6.4.1 创建 TDE·················· 152
6.4.2 带有 TDE 的插入与克隆
操作 ·························· 157
6.4.3 TDE 总结·················· 157
6.5 本章小结 ························157
第 7 章 备份和恢复··················161
7.1 回到基础知识·················162
7.1.1 热备份与冷备份······· 162
7.1.2 RMAN：默认配置 ··· 164
7.1.3 RMAN 冗余备份······ 165
7.1.4 SYSBACKUP 权限··· 166
7.2 CDB 备份与 PDB 备份 ···166 7.2.1 CDB 备份 ·················· 167
7.2.2 PDB 备份··················· 171
7.2.3 别忘了归档日志！ ···· 174
7.3 恢复场景 ························174
7.3.1 实例恢复 ··················· 175
7.3.2 对 CDB 进行还原和
恢复··························· 176
7.3.3 对 PDB 进行还原和
恢复··························· 178
7.4 RMAN 优化方面的一些
考量·································180
7.5 数据恢复指导·················183
7.6 块损坏 ····························184
7.7 使用 Cloud Control 进行
备份 ································184
7.8 本章小结 ························186
第 8 章 闪回与基于时间点的
恢复·····························189
8.1 PDB 的基于时间点的
恢复 ································190
8.1.1 在指定时间恢复
PDB ··························· 191
8.1.2 UNDO 在哪里？ ······· 193
8.1.3 版本 12.1 中的
PDBPITR 总结 ·········· 195
8.2 版本 12.2 中的本地
UNDO ·····························196
8.2.1 数据库属性 ··············· 197
8.2.2 创建数据库 ··············· 197
8.2.3 修改 UNDO 表空间 ·· 198
8.2.4 修改 UNDO 管理
模式··························· 199
8.2.5 共享 UNDO 还是本地
UNDO？ ··················· 200
8.3 版本 12.2 中 PDBPITR···201
8.3.1 共享 UNDO 模式下的
PDBPITR·················· 201
8.3.2 本地 UNDO 模式下的
PDBPITR·················· 202
8.4 闪回 PDB························202
8.4.1 闪回日志 ·················· 203
8.4.2 使用本地 UNDO 进行
闪回 ·························· 205
8.4.3 使用共享 UNDO 进行
闪回 ·························· 205
8.4.4 CDB 和 PDB 级别的
还原点 ······················ 206
8.4.5 干净还原点··············· 209
8.5 resetlogs ·························· 210
8.6 闪回与 PITR···················212
8.6.1 何时需要 PITR 或
闪回？ ······················ 212
8.6.2 对备库的影响··········· 212
8.6.3 辅助实例的清除······· 214
8.7 本章小结 ························215
第 9 章 移动数据 ·····················217
9.1 锚定 PDB 文件位置 ·······218
9.2 插入与拔出 ····················218
9.2.1 PDB 的拔出与插入 ·· 219
9.2.2 停留在源库中的已拔出
数据库 ······················ 220
9.2.3 XML 文件中究竟有
什么？ ······················ 222
9.2.4 为插入操作检查
兼容性 ······················ 225
9.2.5 像克隆一样插入········ 226
9.2.6 PDB 的归档文件 ······· 228
9.3 克隆 ································229
9.3.1 克隆本地 PDB··········· 229
9.3.2 克隆远程 PDB··········· 231
9.4 应用容器的一些考量·····236
9.5 转换非 CDB 数据库·······236
9.5.1 插入非 CDB ·············· 237
9.5.2 克隆非 CDB ·············· 239
9.6 将 PDB 移动到云上 ·······240
9.7 基于 PDB 操作的
触发器·····························241
9.8 全传输导出/导入············241
9.9 可传输表空间·················244
9.10 本章小 结 ··························· 245
第 10 章 Oracle 数据库资源
管理器························249
10.1 资源管理器基础···········250
10.1.1 资源管理器关键
术语 ······················· 251
10.1.2 资源管理器的
需求 ······················· 253
10.1.3 资源管理器的
级别 ······················· 253
10.2 CDB 资源计划··············254
10.2.1 资源分配与使用
限制 ······················· 254
10.2.2 默认与自动任务
指令 ······················· 256
10.2.3 创建 CDB 资源
计划 ······················· 257
10.3 PDB 资源计划··············265
10.3.1 创建 PDB 资源
计划 ······················ 266
10.3.2 启用或禁用 PDB 资源
计划 ······················ 268
10.3.3 移除 PDB 资源
计划 ······················ 269
10.4 使用初始化参数管理 PDB
的内存和 I/O ················269
10.4.1 PDB 的内存分配·· 269
10.4.2 限制 PDB 的 I/O··· 270
10.5 实例囚笼
(instance caging) ··········· 270
10.6 监控资源管理器···········272
10.6.1 查看资源计划与资源
计划指令··············· 272
10.6.2 监控被资源管理器
管理的 PDB ·········· 273
10.7 本章小结 ······················274
第 11 章 Data Guard ···············275
11.1 ADG 选项·····················276
11.2 创建物理备库···············277
11.2.1 使用 RMAN 进行
复制 ······················ 277
11.2.2 使用 EMCC 创建
备库 ······················ 289
11.3 在多租户环境下管理
物理备库 ······················292
11.3.1 在源端创建新的
PDB ······················ 293
11.3.2 将 PDB 从源端
删除 ······················ 294
11.3.3 修改子集 ·············· 295 11.3.4 EMCC···················· 298
11.4 云上的备库···················298
11.5 本章小结·······················301
第 12 章 在 PDB 之间共享
数据···························303
12.1 数据库链接···················304
12.2 共享公共只读数据·······305
12.2.1 可传输表空间········ 306
12.2.2 存储快照与基于写的复
制(copy on wirte) ··· 307
12.3 跨 PDB 视图·················308
12.3.1 简单用户表 ··········· 309
12.3.2 集成数据 ··············· 313
12.4 跨数据库复制···············327
12.5 本章小结 ······················327
第 13 章 逻辑复制····················329
13.1 Oracle 日志挖掘器
(LogMiner)····················331
13.2 已过期的特性···············332
13.2.1 Oracle CDC··········· 332
13.2.2 Oracle 流技术 ······· 332
13.2.3 Oracle 高级复制 ··· 332
13.3 OGG(Oracle
GoldenGate)··················333
13.3.1 OGG 中的多租户
支持 ······················ 333
13.3.2 大数据适配器······· 343
13.4 Oracle XStream·············345
13.5 逻辑备库 ······················346
13.6 其他第三方选项···········347
13.6.1 Dbvisit Replicate ··· 347
13.6.2 Dell SharePlex······· 347
13.7 本章小结 ······················347 多租户意味着什么

多租户概述
在 Oracle Database 12c 中， Oracle 引入了一项发生于数据库体系结构上的
重大调整。在 Oracle Database 12c 以前，一个实例只能打开一个数据库。如果
想处理多个数据库，那么需要启动多个实例才行。因为它们都是完全隔离的架
构，即便这些数据库都安装在同一台服务器上也是如此。这一点与其他关系型
数据库颇为不同，其他很多的数据库，都是可以使用一个实例来管理多个数据
库的。
进入 Oracle Database 12c 之后，一个实例就可以打开多个可插拔数据库，
或者称之为 PDB(Pluggable DataBase)。 Oracle 将之称为新多租户架构，以前旧 的架构名称便被抛弃了。无论是否使用了多租户选项，将来所有的 Oracle 数据
库都会运行在多租户架构上。关于这点事实，所有的 DBA 都是不能忽视的。
1.1 历史课堂： IT 技术的新时代
在介绍将来的架构之前，让我们先简要回顾一下使用数据库的历史。如你
在图 1-1 中所看到的，我们并不关注时间，而是关注数据库版本，通过它来回
顾 Oracle 数据库的演化历程。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站设计、网站建设、外贸网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的平泉网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

图 1-1 从 IT 集成到云
当 Oracle Database 8i 和 9i 出现在市场上时， 数据中心使用中型机逐渐变得
流行起来。我们从大型机时代开始步入客户端/服务器时代。而当时的 Oracle
数据库的体系结构，显然是非常适应这一趋势的。由于 Oracle 数据库是使用 C
语言编写的，因此它在多种平台上均能成功运转。并且，所有用户管理信息都
存储在数据库的数据字典中。 Oracle 数据库显然为客户端/服务器架构做好了准
备，它可以使用操作系统来监听 TCP/IP 端口并存储文件。此外，数据库的架构
在小型机上也是可扩展的，这多亏了一个被称为并行服务器的特性。当然，后
来它被称为 RAC(Real Application Cluster)。
随着服务器数量的增长，数据库的数量也随着增长。在那时，一家公司往
往会拥有很多台物理服务器，并且使用 DAS(Direct Attached Disks，直连存储)
作为存储，而在每台服务器上，则又运行着 1 个或 2 个 Oracle Database8i 或 9i
实例。
随着数据库数量的增长，管理所有的服务器和磁盘则又成为噩梦一般的存
在。面对着数据的指数级增长，还依然使用内部磁盘来管理这些数据的话，则
容量规划就变得极其困难。此时， Oracle Database 10g 便应运而生。我们需要 对存储进行集成，这样我们就可以把数据库文件存放到一个存储阵列中，并通
过 SAN(Storage Area Network， 存储区域网络)让所有的服务器都可以共享访问。
这就是存储集成。
随着时间的流逝， Oracle Database 11g 开始登场。早期，比较流行的想法
是，我们使用服务器，然后每台服务器上都带有磁盘。但是，相比于设置多台
服务器的容量并对其进行维护而言，虚拟化软件则为我们提供了一种新的可能：
我们可以将多台物理服务器放在一起，并在此基础之上提供虚拟机。在以前的
时代，我们就是使用这样的方法：应用服务器、 SAN 或 NAS，以及虚拟机。
现在， Oracle Database 12c 为我们带来一种新的方法。很多拥有集成存储
和服务器的组织，目前已经意识到运营这样的架构其实并非他们的核心业务。
相反，他们将 IT 需求视作一个服务，它应该具有可扩展性和灵活性。小公司想
要使用公有云来提供他们所需的 IT，大一些的公司则打算建立自己的私有云。
在这样的情况下，虚拟化就可以提供 IaaS(Infrastructure as a Service，基础设施
即服务)。但是，我们也需要 AaaS(Application as a Service，应用即服务)和
DBaaS(DataBase as a Service，数据库即服务)。对于 IT 技术生态圈而言，这显
然是一个极为重大的变化。 这与当年从客户端/服务器架构进化到应用服务器时
代颇为相似，无论是扩展性方面还是重要性方面。当然，这一过程并非一蹴而
就——它需要时间。不过，现在就可以断言，在接下来的十年中，混合模型(按
需供应/云)将变得更强大，但是也终将会被云慢慢替代。
正如我们所期待的，新的时代有着不同的需求。数据库的未来也将与集成、
敏捷开发，以及快速就绪等联系在一起。对于 Oracle 而言，类似这样的一些特
性，其实从 9i 到 11g 一直都处于快速进化之中。比如简单数据传输、克隆，以
及精简指令配置(thin provisioning)等。但是数据库中的两个核心架构功能：一
数据库一实例，以及一数据库一数据字典，一直以来都是如此，尚未做好集成
的准备。为此， Oracle Database 12c 提供了这两个问题的答案：多租户。在保
留原有可移植性架构的基础之上， Oracle 对其架构进行了设计调整，从而使得
可以在同一个数据库上运行应用——无论程序是运行在小型服务器上，还是运
行在很大的云上。
1.1.1 通往多租户之路
新的时代是关于集成的时代。一些人会将其想象成一个集中式系统，并辅
以集中管理。但是这带来了新挑战：我们需要越来越高的敏捷性。让一个数
据库快速就绪在今天而言，本非一件容易之事。但至少，我们不能让它变得
更糟糕。
考虑这样一个例子。你是一个 Oracle DBA。然后一个开发人员来到你的办
公桌前，并表示她需要一个新的数据库。在她的意识里，可能会认为这是一个 很简单的需求，你只需要在一个管理界面上单击几下鼠标应该就能搞定。你看
着她，瞪大眼睛，然后告诉她需要去填一张需求申请单，上面需要指定存储、
内存、 CPU 以及可用性方面的内容。并且，你还得解释，这样的需求要上级领
导批准，需要花费数天甚至一周的时间才能建立一个数据库。显然，这里就是
开发人员与运维人员之间通常会产生误解的地方。
开发人员可能以前就没有使用过 Oracle 数据库， 所以她就闪过一些念头，
认为数据库不过就是用来装她的应用程序表的一个容器罢了，并且这个容器
还是一个很轻量级的玩意——在很多其他的非 Oracle 数据库中，这实际上就是
“数据库”。
但是在 Oracle 中，恰恰相反，我们是有一些轻量级的容器——逻辑级别上
的方案(scheme)，以及物理级别上的表空间(tablespace)——但是数据库，则不仅
仅是这些内容的整个组合。 Oracle 数据库，是一组方案和表空间的集合，然后
再加上用于管理这些内容的元数据(数据字典)，以及为数众多的用于实施各种
特性的 PL/SQL 代码(DBMS 包)。每一个数据库都必须拥有自己的实例，而实
例又由一组后台进程和一块共享内存构成。并且每一个数据库也都有相应的结
构来保护事务的完整性，比如 UNDO 表空间和 REDO 日志。
因此，基于上述这些理由，提供一个新的数据库并不是件很琐碎细微的事
情。要创建一个新的数据库，需要与系统管理员和存储团队进行沟通，因为需
要服务器和磁盘资源。你并不打算在一台服务器上部署太多实例，但是你也不
太可能在一台服务器上只部署一个数据库。正是因为这些，现在我们通常使用
虚拟化技术，然后为每个实例提供一台虚拟机(Virtual Machine， VM)。当然，
这种方法并不适用于每一个应用或每一个环境，从敏捷的角度来看——因为这
样的话，需要的虚拟机就太多了。另外，当为每一个数据库都不得不分配服务
器、存储以及实例时，最终你就会发现，这样浪费太多资源了。
在 Oracle Database 12c 以前，这种场景下，对于开发人员来说，比较合适
的方法，就是在现有的数据库中为其创建新的方案。但是这种方法并不总是可
能的，或者说是可行的。让我们解释一下为什么。
1.1.2 方案集成
在 Oracle Database 12c 以前，方案就是可用的解决方法。每一个应用程序
都可以有自己的方案，或是一组方案，如果想将表和存储过程分开的话。这些
方案在逻辑上是隔离的，并使用权限管理来保证其安全性。
从物理上来讲，也可以为每个应用设置不同的表空间。这就意味着，一旦
数据文件丢失，在还原期间，可能就只有一个应用处于离线状态。如果想将表
空间重新分布到其他文件系统中，也是如此。但是，除此之外，为了优化资源
使用，其他的所有资源我们都是共享的：实例进程与内存、SYSTEM 与 SYSAUX 表空间、数据字典等。
备份策略和高可用(High Availability， HA)策略也都是相同的。一个 DBA
管理一个数据库，然后在这个数据库上运行多个应用。在 Oracle 数据库的早期
版本中，数据库就是按照这样的方式来设计的。
1. 可传输表空间
在 Oracle 数据库中，很多操作都是发生在表空间级别的。尤其是可传输表
空间这一特性。通过这一特性，可以将应用的数据文件物理地拷贝到其他数据
库中，即便是拷贝到一个更高版本的数据库中也是可以的。可传输表空间这一
特性足够重要，因为它被认为是多租户技术的先驱，或者是始祖。1997 年， Oracle
公司为可传输表空间技术申请专利，名为“数据库系统的可插拔表空间”。而现
在，多租户架构恰恰就是可插拔数据库的基础。
在这里，可插拔的意思，就是可以直接将一个物理结构(数据文件)插到一
个数据库中，并令其成为该数据库的一部分。可传输表空间这一特性，就能够
将用户表空间的数据文件插入到数据库中。 然后就只需要导入相应的元数据(数
据字典实体)即可。这样，在新的数据库中，这些逻辑对象的定义就与数据文件
中的物理内容相匹配了。
当然，在 Oracle Database 12c 中，也可以传输表空间，这样的操作也足够
简单。如果想传输所有的用户表空间，使用“FULL=Y”选项即可。但是相关
的元数据还是需要被逻辑传输。如果有数百张表的元数据需要传输，那么这个
时间可能就会比较长。即便这些表都是空表也是如此。例如，如果想迁移一个
PeopleSoft 数据库，它里面包含 20 000+张表。即便这些表都是空的，导入元数
据也需要几个小时的时间。
正如你将看到的，由于多租户更卓越的性能，传输一个可插拔数据库，实
际上就成为所有数据文件的传输，包括 SYSTEM 和 SYSAUX 中的数据文件。
显然，这里面就包含了数据字典，甚至还可能包含 UNDO 信息。这就意味着所
有的元数据也将会被物理导入。因此，相比传统的可传输表空间技术，这样的
操作就快了很多。
2. 方案名称冲突
在真实世界中，想实现方案集成，其实还是很有难度的。你可能想将很多
应用都集成到一个数据库中，甚至包括同一个应用的测试环境也想集成进来。
此时，就会面对一系列应用程序的约束问题。
如果应用中的方案所有者是硬编码的，不能修改，那么此时该怎么办？如
果我们需要建立一个电话清单系统，而该系统在数据库中对应的方案为 PB，然
后我们想将多个环境都集成到测试数据库中，那么这显然是被禁止的。原因是
该方案的名称已经硬编码到应用程序以及包中，当然还有其他地方。如果有应 用程序供应商派来的顾问，也许我们还能够比较好地理解这些奇怪的方案名称。
但是如果没有，可能就得去猜测这些方案名称最初究竟是什么意思。
当然，如果应用是在你的掌控之下进行设计的，那么你就可以避免这样的
问题。并且无须多言，你应该在自己的应用程序中从来都不要对方案名称进行
硬编码。可以使用某一用户连接到数据库，然后简单地使用 ALTER SESSION
SET CURRENT_SCHEMA 语句来设置当前应用程序的方案所有者，从而来访
问所有相关的对象。如果有多个方案？那么为应用程序使用多个方案倒也不算
是一个坏主意。
例如，可以使用代码(PL/SQL 包)来分离数据(表)。这能够让数据实现更好
的隔离与封装。但即便是在这种情况下，也不要将表所在的方案名硬编码到包
中。可以在包所在的方案中，为这些对象创建同义词即可。这样，就可以在
PL/SQL 代码中引用这些对象，而不用使用方案名(因为同义词与代码在同一个
方案中)，而这些同义词会自动关联到相应的对象上。如果对象名称发生改变，
重新创建同义词就行了。这些动作都可以很简单地完成，也可以自动完成。
3. 公共同义词与数据库链接
对于上面提到的同义词，显然，我们讨论的是私有同义词。不要使用公共
同义词。因为它们会覆盖整个名称空间中的私有同义词。当一个应用程序创建
公共同义词时，无法让其绑定其他任何东西。这就是方案集成的一个限制：不
属于特定方案的对象，容易与其他应用程序，或是其他版本、其他环境中的同
一应用的对象产生冲突。
4. 角色、表空间名称与目录
一个应用程序可以定义或引用其他对象，只要这些对象均处于数据库的公
共名称空间即可——例如角色、目录以及表空间名称。如果一个应用程序在不
同环境中运行，则这些环境其实也可以被集成到同一个数据库中。只需要在执
行 DDL 脚本时，为不同的环境分别设置不同的参数，从而可以让这些数据库
对象分别适用不同的环境即可。如果不是这种情况的话，那么想实现方案集成
就有难度了。
另外一方面，这些不属于特定方案的对象，也会让数据移动的实现变得更
为复杂。例如，当想使用数据泵(Data Pump)来导入一个方案时，这些对象可能
需要在事先就完成创建。
5. 游标共享
即便一个应用程序是专门为方案集成而设计的，在将所有的东西都集成
到一个数据库里面时，也照样可能会遇到性能方面的问题。我们曾经处理过
一个包含 3000 个方案的数据库，它其实是一堆数据集市(data mart)：结构相 同，数据不同。
另外，很显然，应用程序的代码也都是相同的。用户需要连接到其中一个
数据集市，然后执行查询，而这些查询已经在应用程序中进行了定义。这就意
味着同样的查询——甚至在 SQL 文本上也是完全相同的——将会运行在不同
的方案上。如果知道 Oracle 数据库中的游标共享是如何实现的，就立即能够看
到问题所在：一个游标会有上千个子游标。一个父游标会被所有的 SQL 文本共
享，当对象不同时，便会创建不同的子游标。当在多个方案中执行这些代码时，
问题就出来了。 SQL 解析时需要扫描一个相当长的子游标链表，而在扫描期间
需要持有 latch，这显然会导致很严重的库缓存竞争。
在多租户环境下，为满足集成的目的，父游标会被共享，但是在子游标搜
索方面需要进行一些性能方面的提升，从而缓解上述问题。
1.1.3 表集成
当想要对多个环境中的数据进行集成时，而这些环境又有着相同的应用程
序及代码版本，这就意味着要用到的表将会具有完全相同的结构，可以把所
有的东西都放到一张表中。通常情况下，我们是在每一个主键值中添加环境
ID(公司、国家、市场以及其他信息)来区别数据。这样做的好处，是可以一次
性管理所有的东西。例如，当想要添加索引时，可以为所有的环境添加。
基于性能和维护方面的原因考虑，可以基于环境 ID 来对表中的数据进行
物理分区，并将不同的分区数据存放在不同的表空间中。但是，这样做，其隔
离级别就会很低，并进而影响到性能、安全以及系统的可用性。
实际上，大部分应用程序都采用类似这样的设计，并且一般都把数据存储
在一个环境中。绝大部分情况下，添加到主键值前面的 ID 往往都只有一个值，
而这也是 Oracle 引入索引跳跃扫描的原因之一。可以使用虚拟私有数据库策略
来管理对这些环境的访问。可以使用分区交换技术，在物理上实现对这些分区
的独立管理。如果想找一个类似的例子，可以看一下 RMAN 的资料库(恢复目
录)：所有已注册的数据库，其信息都存储在相同的表中。但是，在存储不同环
境(测试、开发以及生产环境)中的数据时，或是存储不同版本(数据模型也不尽
相同)的数据时，这样的隔离其实是不够的。
1.1.4 服务器集成
如果有多个独立的数据库，但是又不想为每个数据库都配置一台服务器，那
么可以将这些实例集成到一台服务器上。如果曾经登录过 Oracle 的 Ask Tom 网
站(astome.oracle.com/)，并咨询过在一台服务器上推荐配置几个实例， Tom Kate
的答案是这样的：“我们不建议在一台主机上部署多个实例——主机可以是虚拟
机或物理机，我们并不关注——但是你可以这样认为：一台主机 = 一个实例。” 但是在真实生活中，就像我们看到的那样，一台数据库服务器上往往运行着多个
实例。可以在一台主机上安装多个版本的数据库(ORACLE_HOME)，也可以在一
台主机上运行多个实例——并且很多时候都是不得不如此。我们曾经见过一台
服务器上运行着多达 70 个实例。
这种情况下，在实例之间进行隔离的方法就比较少了。比如内存，可以通
过设置 SGA_MAX_SIZE 参数来在物理上对内存进行分割。也可以在 Oracle
Database 12c 中使用 PGA_AGGREGATE_LIMIT 来限制进程使用的内存。可以
使用实例囚笼策略，来设置每个实例在 CPU 上运行的最大进程数量。在最新的
Oracle Database 12cR2 中，不需要企业版就可以使用实例囚笼策略。我们将在
第 3 章中讨论这个主题。
但是，在一台服务器上运行大量的实例依然是个问题。例如，当要重启服
务器时，需要启动大量的进程，并完成内存分配。一次服务器停机，无论是计
划内的还是计划外的，都会对大量应用程序造成影响，并且需要消耗大量资源
来处理多个 SGA 以及数据字典表。
1.1.5 虚拟化
现今，虚拟化是一个非常好的方法，可以在不需要管理大量物理服务器的
前提下实现一个实例一台服务器。可以对环境进行极好的隔离设置，在限制范
围内分配 CPU、内存以及 I/O 带宽。甚至可以使用不同的网络来隔离这些数据
库。但是，即便这些服务器都是虚拟机器，也还是无法解决资源浪费，因为还
是要持有多个 OS、 Oracle 软件、内存以及数据字典。并且，还是得管理多个数
据库——备份恢复、实现高可用特性，比如 Data Guard 等。然后，还是有多个
OS 需要打补丁和监控。
此外，在虚拟化环境中，软件许可也是梦魇般的存在。当进行软件安装
时， Oracle 软件是按照处理器数量进行授权的， Oracle 会考虑这些因素，比
如与虚拟化技术相关的授权问题，以及在虚拟机上安装软件并运行，等等。
当然，这些也依赖供应商所提供的管理程序，以及这些管理程序的版本。
1.1.6 一个实例管理多个数据库
那么问题来了，如何找到一种方法，能够实现这样的一种隔离级别：能够
同时满足环境的隔离与资源集成两个目的。显然，这种隔离级别高于方案隔离，
但是又低于我们现在所知道的实例与数据库。也就是说，我们可以在一台服务
器上，使用一个实例来管理多个数据库。
在 12c 以前的 Oracle 数据库版本中，显然没有这样的功能。但是在现今
的多租户架构中，这种方法就颇为可行了。现在，一个集成的数据库可以管
理多个可插拔数据库。另外，也出现了一种新的隔离级别，即独立数据库—— 可插拔数据库，这种架构在环境准备、移动以及系统升级等方面都提供了相
当高的敏捷性。
1.1.7 集成策略总结
表 1-1 简要总结了在多租户技术出现之前，几种可选的集成策略之间的不
同之处。
表 1-1 不同集成策略的优劣分析

集成策略	优势	劣势
表	将所有内容当成一个整体来进行管理	隔离级别受限较大，且不适用于不 同环境
方案	可以实现实例、数据字典以及 HA 级 别的共享	公共对象之间容易出现冲突，且隔 离级别受限
数据库	只需要管理一个数据库	需要多个 SGA 及多组后台进程，也 需要维护多个备份与 HA 配置
虚拟化	可以提供最佳的隔离级别，可以实现 职责分离，并提供 HA 以及 vMotion 方面的特性	授权许可问题，需要学习新的技术， 需要管理并运行多台主机

1.2 系统字典与多租户架构
在多租户架构中，系统字典是变化最大的部分之一。让我们来看看在以前
的版本中，系统字典是如何实现的，以及在 Oracle Database 12c 中，它又发生
了哪些变化。
1.2.1 过去：非 CDB
数据库中既存储数据，又存储元数据。例如，假设在 SCOTT 方案下有一
张表 EMP。该表的描述信息——名称、包含的列以及数据类型等——同样也存
储在数据库中。这些描述信息——也就是元数据——存储于系统表中，并且是
系统字典的一部分。
1. 字典
Codd 的规则(由 E.F.Codd 建立， 其提出了关系模型)定义了关系型数据库中
的元数据必须与数据有着同样的表现形式：可以使用 SQL 来查询元数据或数
据。作为数据库管理员，这样的事情几乎每天都在做。通过查询字典视图，例
如 DBA_TABLES，来获取数据库中对象的相关信息。 Codd 的规则虽然只用于
表述逻辑层面，并由字典视图提供这些信息；但是 Oracle 走得更远——通过在 关系型表中物理存储这些元数据信息——对于同样类型的表和应用程序表，这
些都为 SYS 方案所拥有，并存储在系统表空间(SYSTEM 和 SYSAUX)中。
其实，在处理数据及元数据信息存储时，并不需要使用 Oracle 字典的实际
名称和详细信息，如图 1-2 所示。表 SCOTT.DEPT 用于存储用户数据，该表的
定义则存储在字典表中， 即 SYS.COLUMNS。该字典表用于存储列的相关信息，
并且由于这个字典本身也是表，因此它的定义信息也采用同样的方式存储下来。

网页名称：OracleDatabase12cR2多租户权威指南
分享路径：http://ybzwz.com/article/iejjji.html