1® ®

技 术 动 态

Oracle SAP for

• Oracle Database 12c – 让云计算简单化的卓越数据库 • Oracle Database In-Memory – 助力实时型企业 •面向 SAP BW 的 Flat Cube – 简化数据建模并加快数据加载

•信息生命周期管理 – 成熟的性能优势 •混合列压缩 – 减少 I/O，实现高水平的数据压缩 • Oracle Multitenant – 可插拔数据库 – 简化整合 • Oracle Database Vault – 提高现有应用的安全性

Oracle 提供了全面的 IT 数据库和基础设施平台，旨在更好地运行 SAP 应用

第 26 期 Oracle for SAP，2017 年 5 月 www.oracle.com/sap

www.oracle.com/sap

2

尊敬的 SAP 客户：

Oracle提供全面、开放和高集成度的技术体系，涵盖数据库、业务软件、操作系统、服务器和存储等各个方面，为 SAP 应用提供了一个绝佳的运行平台。

Oracle 公司与 SAP SE 的合作历史悠久，双方有丰富的联合开发经验，而且为了确保共同客户的利益，合作前景非常广阔、坚稳。

可以说，只要 SAP 支持 SAP Business Suite 和 SAP BW，Oracle 也将一直为它们提供相应的支持。这种合作例证比比皆是，例如，根据 SAP 说明 1951491，SAP 在 SAP NetWeaver 7.4 SP08 中引入了创新技术，以便充分利用 Oracle 数据库平台的新技术功能（即核心数据服务）；根据 SAP 说明 2178980，SAP 环境中支持 Oracle Database In-Memory 选件；而且 SAP BW 优化了 InfoCube/Flat Cube。

根据 SAP 用户组进行的最新市场调研（2017 年 2 月）*， • 只有 2% 的德语 SAP 客户在使用 S4 HANA 平台 • 有 50% 的客户认为 S4 不是传统 ERP 系统的替代产品 • 只有三分之一的 SAP 客户计划在 2020 年将 S4 HANA 作为主要 SAP 平台。这意味着大多数 SAP 客户仍会继续使用 SAP

NetWeaver 体系，并将 SAP Business Suite 作为基于关系数据库的主要 ERP 平台。

29年来，两家公司通力合作，一贯秉持服务于数以万计共同客户的宗旨。我们之间刚刚续签的长期经销商协议和支持协议为客户放心采用 Oracle 数据库技术和享受出色的客户支持提供了有效保证。Oracle 的产品战略为客户打造 IT 基础设施提供了灵活多样的选择。因此，SAP 大中型企业客户中的绝大多数都为其应用选择了 Oracle 数据库。

通过选择 Oracle 数据库和数据库选件，SAP 客户可以不间断地利用持续创新，从而获得显著的收益。在经过深入了解后，您会发现让 Oracle 数据库成为 SAP 应用运行平台的优势有：出色的性能和可扩展性、部署灵活性、可用性、可靠性、灾难恢复、安全性、可管理性、自主管理、对超大型数据库的支持、对数据库整合的支持以及软硬件一体化集成。现在，所有 SAP 客户都能利用 Oracle 数据库的功能和特性来优化 SAP 部署的成本。

目前，以下 Oracle Database 12c选件已经过 SAP 认证并由 SAP 支持：

- Oracle Database In-Memory

-信息生命周期管理 (ILM) /自动数据优化 (ADO) -与 ILM 相结合的适用于 Oracle Exadata 和 Oracle SuperCluster 的混合列压缩 (HCC) - Oracle Multitenant 选件

Oracle Exadata 数据库云平台经过集成设计，将所有 SAP 数据库和非 SAP 数据库整合到一个私有数据库云环境中。它为运行 Oracle 数据库私有云提供了拥有高性能和高可用性的平台，可运行包括联机事务处理（例如 SAP ECC 6.0）和数据仓储（例如 SAP BW 7.0 和更高版本）在内的所有类型的数据库负载。 Oracle Exadata 数据库云平台能够承载重要的大型数据库负载，通常可将速度提高 10 倍以上，因此有大量 SAP 客户部署了该服务器。

Oracle SuperCluster是通用型集成系统。它整合了全新 SPARC 处理器的超强计算能力、Oracle Solaris 11 的高性能和可扩展性、Oracle Exadata 存储的数据库性能优化以及 SAP 内核 6.40 或更高版本的运行时优化。

Oracle MiniCluster是简单、高效的集成系统，旨在为运行企业数据库和应用提供超强的安全性。

Oracle 全面更新和扩展了 SPARC M7、T7 和 S7 服务器系列，这一举措改写了企业计算经济学，以较高的性价比为客户提供出色的价值。我们刚刚更新了 SPARC 和 Solaris 规划，展望了 2021 年后的前景。

*https://www.dsag.de/news/dsag-investitionsumfrage-2017-relevanz-der-business-suite-ungebrochen

https://www.dsag.de/news/dsag-investitionsumfrage-2017-relevanz-der-business-suite-ungebrochen

3 Oracle 提供了全面的 IT 数据库和基础设施平台，旨在更好地运行 SAP 应用

Oracle Exalogic 中间件云平台与 Oracle Exadata 数据库云平台相结合，可为 SAP 和非 SAP 应用提供高可扩展性、超强的性能和管理简易性。

Oracle私有云一体机是一个集成系统，它彻底简化了融合基础设施的安装、部署和管理，可用作数据库和应用的虚拟化平台。

Oracle 数据库机开辟了一种新方式，让客户可以在一个易于部署和管理的系统上利用广受欢迎的 Oracle 数据库。它是一个包含软件、服务器、存储、高可用性和联网设备的完整系统，旨在通过简化部署、维护和对数据库负载的支持节省时间和成本。

Oracle Linux 7 是 Oracle 新版 Linux，可满足您的 SAP 基础设施的计算需求。它运行速度快，可为 SAP 应用提供出色性能；它紧跟时代步伐，可为客户带来全新的创新；它稳定可靠，可提供数据完整性、更高的安全性和更长的应用正常运行时间；而且它针对 SAP 环境下的 Oracle 数据库进行了优化。

Oracle VM Server for x86 是一个免费的服务器虚拟化解决方案，可以简化 SAP 和其他企业应用的部署、管理和支持。

Oracle 基础设施即服务 (IaaS) 云 –正在进行 SAP 认证 –无论在价值方面，还是安全性和性能方面，都是一个极具吸引力的企业云平台，能够为 SAP 客户提供部署和运行 SAP 基础设施的多种方案，包括内部、云端、私有云、公有云甚至混合云方案。

在德国沃尔多夫 SAP SE 总部现场办公的 Oracle 开发团队将继续与 SAP 开发人员合作，以确保 SAP 客户总在使用全新优化的 Oracle 技术，从而拥有出色性能、高可靠性和全新创新。

Oracle SAP 服务和支持团队提供高级客户服务 (ACS)，包括针对 SAP 环境的健康检查、技术研讨会、数据库迁移、性能分析、调优以及 Oracle Solaris 高级客户服务，其中包括辅助服务项目（针对 IT 基础设施的分析/改进与 SAP 就绪服务）。

要了解更多信息或查看当前及早期版本，请访问：www.oracle.com/sap

如果您有何建议或问题，请联系我们：frontdesk-walldorf_de@oracle.com

顺祝商祺！

Gerhard Kuppler

Oracle SAP 联盟副总裁甲骨文公司

甲骨文公司：甲骨文公司 2016财年 GAAP总收入达 370亿美元，拥有 42 万家客户、 31万家 Oracle数据库客户、 12万家 Oracle融合中间件客户、 11万家 Oracle管理软件客户、 6000家集成系统客户，在全球拥有 25000多个合作伙伴以及 135000多位员工，其中包括： 40000位开发人员和工程师， 16000位支持人员， 18000位咨询专家，每年资助 110个国家和地区的 310万名学生。

http:frontdesk-walldorf_de@oracle.comwww.oracle.com/sap

4

目录

2-3 5

18 37 40 44 46 49 50 56 59 61 63 65 69 71 74 76 78 81 84 86 90 94 97

编辑寄语面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持面向 SAP 客户的 Oracle 数据库选件和管理包 Oracle Database In-Memory 在 KIVBF 的应用 - SAP BW 性能提升巨大

Oracle Database In-Memory 和 Flat-Cube 在 Villeroy & Boch 的应用 Oracle Database In-Memory 在 Bosch GmbH 的应用 SAP BI 与 Oracle Database In-Memory 组合在 DB Masters 的应用面向 SAP BW 的 Oracle Database In-Memory 工具包为何选择面向 SAP 的 Oracle 数据库和集成系统？ Oracle Exadata 数据库云平台在瑞士邮政的应用 Oracle Exadata 数据库云平台在 Granarolo 的应用 Oracle Exadata 数据库云平台在物美的应用 Oracle Exadata 数据库云平台结合 SAP 助力 AmerisourceBergen 实现顶级业务运营 Oracle Exadata 数据库云平台在 Nagase 的应用 Oracle Database 12c 和 Database In-Memory 在 LION 的应用印尼能源集团选择采用 Oracle SuperCluster Oracle 私有云一体机在 Secure-24 的应用 Oracle Exadata 数据库云平台在 Utkonos 网上超市的应用面向 SAP 客户的任务关键型支持服务面向 SAP 客户的 Oracle SuperCluster M7通过 SAPCTL 为 SAP 资源赋予高可用性专门针对创新、效率和简单性进行了集成设计：面向 SAP 的 Oracle 集成系统 Oracle 裸机云 Oracle 相关 SAP 说明的参考资料列表出版信息

5面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

面向 SAP 的 ORACLE DATABASE 12c：面向应用优化的全新数据库技术和支持

研发战略和规划集成战略从一开始，面向 SAP的 Oracle数据库或在 Oracle数据库上运行 SAP 的战略就由两大支柱在支撑。一个支柱是 Oracle 数据库特性与 SAP 环境的集成。另一个支柱是 SAP应用特性与 Oracle数据库的集成。

将 Oracle 数据库特性集成到 SAP 环境 的需求一直显而易见。如果 Oracle 发布了新的数据库特性，而 SAP架构还未做好应对的准备，那么这种需求就会特别明显。许多客户可能还记得，在将 Real Application Clusters (RAC) 集成到 SAP 架构时，大家都认为会有多个 SAP 应用服务器实例，但事实上只有一个数据库服务器实例。

这绝非旧事重提。目前的计划是为 SAP 客户提供 Oracle Multitenant，这相当于一次架构革命，需要付出的努力不亚于获得 RAC 认证。

但在另一方面，将 SAP 应用特性集成到 Oracle 数据库的需求却经常被忽视。经典的 SAP 应用（如 R/3 和 BW）在 Oracle 数据库上构建。之后， SAP 开始支持 IBM DB2 和 Microsoft SQL Server，但他们采用公分母策略，即只使用所有受支持的数据库中都包含的数据库特性。因此 Oracle数据库没有承受太多压力。

但 SAP 自己数据库 (HANA) 的问世改变了这一状况。SAP 很快意识到他们需要放弃公分母策略并改变 SAP 应用：只要 SAP 应用以无差别的方式对待

HANA 和所有其他数据库， SAP 就很难证明 HANA 的优势并说服客户实施 HANA。因此， SAP 已着手进行应用优化项目，以便支持 SAP 应用使用特殊的 HANA 特性。

但是，“特殊的 HANA 特性”并不表示“只有 HANA能提供这些特性”。 HANA能提供的特性在 Oracle数据库中都有。因此将 SAP 应用特性与 Oracle 数据库集成的需求越来越受到重视。

如今，在 Oracle 数据库上运行 SAP 的战略的两大支柱已经夯实。每当 Oracle发布一个主要的数据库新特性，Oracle开发团队就需要将其集成到 SAP架构以及 SAP 提供的安装、管理和监视工具。每当 SAP 发布一个新的应用优化，开发团队也需要将其与 Oracle 数据库技术集成。

Oracle 很看重 Oracle 数据库和 SAP 应用的紧密集成对于我们共同客户的价值。 Oracle 提供全面的数据库功能集并支持目前的特殊 HANA 优化（比如核心数据服务和 Oracle 优化的 Flat Cube），显而易见， Oracle会继续对两个支柱进行支持。

6

SAP 应用优化支持

Oracle Database 12c 的新特性和选件

认证和支持规划 Oracle Database 11g

针对 Oracle Database 11g (11.2.0.4) 的标准维护服务已于 2015 年 1 月 31 日到期，因此于 2015 年 2 月开始了为期三年的延伸支持服务。Oracle 为 Oracle Database 11.2.0.4 免费提供截止到 2018 年 12 月 31 日的延伸支持。（要了解更多信息，请参阅 SAP 说明 2098258。） Oracle Database 12c (12.1)为了保障双方共同客户的利益，Oracle 与 SAP 同意将认证过程划分成几个阶段。这不仅会缩短Database 12c 正式版上市的时间，还会充分延长对

Oracle

Oracle Database 11g的支持。

• 第 1 阶段 进行基本认证，该阶段已于 2015 年 3 月完成。涉及的认证内容为之前已经在 Oracle Database 11g 中提供的所有特性和选件以及 Oracle Database 12c中完全透明或者只需极少集成工作的几个特性。

• 第 2 阶段已于 2015年 6 月完成。在该阶段对 Oracle Database 12c 中的主要新选件进行认证： Oracle Database In-Memory。

• 第 3 阶段已于 2015 年 12 月完成，Oracle Database 12c Advanced Compression 中包含的信息生命周期管理 (ILM) 特性以及 Oracle Exadata 和 Oracle SuperCluster上带有行级锁定功能的混合列压缩 (HCC)已于本阶段完成认证。

• 第 4 阶段 已于 2017 年 2 月完成，该阶段完成了面向 SAP 客户的 Oracle Multitenant 的认证。该选件允许将多个数据库整合到一个容器数据库中。它基于一个全新的数据库架构，需要完成大量 Oracle/ SAP 集成工作。

Oracle Database 12c (12.2) Oracle Database 12.2 改进了独特的多租户架构和内存中数据库技术，可为 SAP 客户的所有 SAP 负载提供出色的整合、性能、可靠性和安全性。

根据计划， Oracle Database 12.2 将于 2017 年年底前完成 SAP 认证。应用优化从理论上讲，面向 SAP 应用的 Oracle 支持的优化是一个持续的项目，完全独立于 Oracle Database 12c 认证过程。但在某些情况下可能会需要特定的 Oracle Database 12c特性。

• 最初随 SAP NetWeaver 7.40 (SP 05) 一起发布的 SAP核心数据服务获得 Oracle Database 11g 和 Oracle Database 12c 的支持，不需要特定的特性或选件（请参阅 SAP 说明 1951491）。

• 许多数据模型优化会提高对磁盘空间的要求。在这种情况下，建议您使用表压缩，但这并不是强制性要求。而且，由于相当一部分表中含有 255个以上的列，所以 Oracle Database 12c是允许客户压缩所有相关表的版本。

• 面向 SAP BW 的 Flat Cube 只能与 Oracle Database 12c和 Oracle Database In-Memory 一起使用。

7 面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

基本认证特性在 Oracle Database 11g 上运行 SAP 应用的客户可以选择各种不同的压缩特性，例如标准数据库特性索引键压缩和索引组织表 (IOT)，以及 Oracle Database 11g Advanced Compression 提供的面向结构化数据的 OLTP 压缩和面向非结构化数据的 SecureFile 压缩。

Oracle Database 12c Advanced Compression 自带很多新特性。一些重要的特性与信息生命周期管理支持相关，已在第 2 阶段认证后提供给 SAP 客户。一些 Advanced Compression 特性已在第 1 阶段通过认证，现在就可以在 SAP 环境中使用。

Advanced Index Compression是一种新的索引压缩形式。使用 Advanced Index Compression 创建或重建索引能够减少唯一和非唯一索引的大小，并且能提高访问索引的效率。Advanced Index Compression 适用于所有受支持的索引，包括不能利用现有索引键压缩获得良好成效的索引。

Advanced Network Compression，可用于在发送端压缩要传输的数据，然后在接收端解压缩收到的数据，以减少网络流量， Advanced Network Compression 可缩短传输大量数据的时间。这能提高 SQL 查询响应速度并节省带宽（请参阅 SAP说明 2138262）。

Oracle 数据库企业版中自带了 Data Guard，它是设置备用数据库必需的功能。而 Active Data Guard 是一个额外的选件。在 Oracle Database 11g 中，它提供一些附加特性，如自动块修复和快速增量备份。

Active Data Guard Far Sync是 Oracle Database 12c提供的一个主要的新特性。该特性允许客户对 WAN 中相隔距离遥远的主数据库和备份数据库进行同步，不仅能实现高性能（异步数据传输的特征），还能实现零数据丢失（同步数据传输的特征）。如需了解详情，请参阅“用 Oracle数据库选件和管理包为 SAP客户实施数据管理基础设施”一章的 “Data Guard 和 Active Data Guard”小节（本文的第 26页）。

Oracle Recovery Manager (RMAN) 为高效地备份和恢复 Oracle 数据库提供了一个全面的基础平台。它在设计之初就考虑了与服务器密切协作，可在备份和恢复期间提供块级损坏检测。 RMAN 在备份过程中通过文件多路复用和备份集压缩来优化性能和空间占用。与此同时， RMAN 还集成了 Oracle Secure Backup 和第三方介质管理产品，用于磁带备份。

跨平台备份和恢复使用完整和增量备份集来支持用户实现数据的跨平台传输。要利用备份集进行跨平台备份，目标数据库必须是 Oracle 12c 或更高版本。这个新增特性简化了平台迁移，并大幅度减少了源数据库上的只读停机时间。

尽管 RMAN 仍然是常用的 Oracle 数据库备份工具，用户也可以使用另一种常用方法进行数据库备份，即为数据库中的所有文件创建存储快照。将快照挂载到另一台服务器（生产数据库服务器以外的其他服务器），然后将数据复制到磁带等三级存储设备上，这样就分流了生产服务器的备份处理。

存储快照优化支持用户使用第三方技术创建数据库的存储快照，且无需将数据库置入备份模式。

8

凭借 Oracle Database 12c，客户无需将数据库置入备份模式即可创建存储快照，实现一步恢复。既可以恢复到当前的时间点，也可以恢复到创建快照后的特定时间点，用户无需进行其他操作。

如果您是 Exadata 的用户，您可能知道 Exadata 此前一直不支持 ACFS。不过，如果您运行的是 Grid Infrastructure v12.1.0.2 或更高版本，那么您可以在 Exadata 上使用 ACFS。在 SAP 环境中，它可以用于 SAP共享文件系统（ /sapmnt 等）。但这并不意味着 ACFS是在 ASM上运行数据库的替代方案。 Oracle数据库仍需在使用 Exadata Storage 节点的 ASM 上运行。这是受支持的配置。

面向 Oracle Grid Infrastructure 的高可用性网络文件存储 (HANFS) 在高可用虚拟 IP (HAVIP) 上公开 NFS 导出，并用 Oracle Clusterware 代理确保 HAVIP 和 NFS 导出始终联机，从而提供不中断服务的 NFS V2/V3导出路径。如果某个集群节点发生故障，HAVIP和 NFS 导出会自动迁移到一个正常运行的节点。

SQL 语句中的 UNION 和 UNION ALL 操作符连接两个或多个分支（如子查询）： UNION 。过去，在这种类型的查询中，各个分支逐个执行，即在一个特定的时间点仅执行一个分支，该分支执行完成后再按顺序执行后续的分支。而 Oracle Database 12c 可以并行执行 Union 和 Union All 分支，即，在同一时间，由一组并行服务器执行一个分支，另一组并行服务器执行另一个分支。这种并行执行分支的能力可以提高语句的执行速度，从而改善 SAP BW 的性能。

联机移动分区：自 Oracle Database 12c 开始，ALTER TABLE ...MOVE PARTITION 操作用作无阻塞联机 DDL 命令，而 DML 操作继续在正在移动的分区上不间断地执行。此外，系统会在移动分区时维护全局索引，因此用户不再需要手动重建索引。

联机移动数据文件：在 Oracle Database 12c 之前，移动数据文件只能脱机进行。用户可以使用一些技巧尽可能减少停机时间，但停机仍不可避免。 Oracle Database 12c 对 ALTER DATABASE 命令进行了改进。现在，用户完全可以联机移动数据文件。

重建索引组织表：由于索引组织表存储为 B 树索引，所以插入、更新和删除等操作可能会产生碎片。然而，您可以使用 ALTER TABLE...MOVE ONLINE语句重建索引组织表并减少碎片。要了解更多信息，请参阅 SAP说明 1856270和 2087004。在 Microsoft Windows 上实施时，Oracle Database 12c 支持使用 Oracle 主用户，该用户可以在安装时指定。引入 Oracle 主用户的目的是使用一个低权限的非管理员帐户托管 Oracle 服务，以提高系统的安全性。Oracle 主用户可以是 Windows 内置帐户，也可以是 Windows 标准用户帐户（非管理员帐户）。此帐户用于为 Oracle 主目录运行 Windows 服务。要了解更多信息，请参阅 SAP 说明 1915302。

9

5

5

面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

基本认证和应用优化在 Oracle Database 11g 中，结构化表数据压缩（ OLTP压缩）方式不能用于超过 255 列的表。而 Oracle Database 12c Advanced Compression 解除了 255 列的限制。在基本认证后，SAP 用户在进行表压缩时不再受到此限制的影响。

从表面上看，这似乎是一个小小的改进，但几乎所有 SAP 系统中都存在超过 255 列的表。

在 SAP说明 1835008和 1892354中讨论了一个非常有趣的例子： SAP的一些应用优化只适用于脱离了集群的表。由于集群表中的数据通常以 SAP的压缩方式存储，当表转化成透明表时，表的大小会大幅增加。遗憾的是，有不少脱离了集群的表所含列数超过 255。 Oracle Database 11g Advanced Compression 不能减少这些表的大小。而有了 Oracle Database 12c Advanced Compression 选件，用户就能压缩和管理这些超宽表格中的数据了。

核心数据服务

许多人认为， SAP 决定放弃公分母策略并通过优化来支持 SAP 应用使用 HANA 特性是受到了 Oracle 的威胁。确实，在 SAP 环境中，HANA 是 Oracle 数据库的竞品。但在许多情况下，SAP 全新的应用优化让 Oracle 员工和 Oracle 客户如释重负。我们以 SAP 核心数据服务 (CDS) 为例，这一现象很容易解释。

核心数据服务背后的主要问题是：什么是数据库？它能做什么？不能做什么？

传统上，人们认为数据库就是简单的数据存储。它是一个可以永久存储数据的容器，仅此而已。一旦客户想要利用数据做一些有用的工作，就必须将数据传输至应用服务器，因为应用服务器具有智能。

传统的 SAP 应用就基于这一概念。它的缺点显而易见：如果需要对 100 万个值进行求和计算，而且这

些值表示不同币种的货币，用户需要将这 100 万个值从数据库服务器传输到应用服务器，并在计算完成后丢弃这些数据。这种方法带来的网络流量降低了系统的性能。

25年以前， Oracle数据库的开发人员问道：在数据库服务器一端求和会不会更好？这会不会显著提高系统的性能？他们对数据库的概念给出了不同的答案：数据库不仅仅是数据存储，它不仅能存储数据，还能够存储和执行使用这些数据的过程 — 一些代码片段，这些代码片段来自应用服务器上运行的应用，现在被迁移到数据库服务器上。所以，应用分为两层，一些在应用服务器上运行，另一些在数据库服务器上运行，因此数据库服务器也是一个应用层。 Oracle开发人员不只是抛出问题和提出一个新概念，他们还构建了一个能够存储和执行数据库过程的全新数据库版本（ Oracle 7，于 1992年发布）。

10

5

5

但在当时， Oracle 数据库是可用作应用层的数据库。存储过程不包含在公分母特性子集中，因此 SAP 拒绝使用存储过程。

20 年后，当 SAP 开始推广 HANA 时，他们立刻发现自己的 SAP 应用是全新内存中数据库架构的敌人。只要应用将数据库视为简单的数据存储，且认为只有应用才能有效地进行计算，那么用户就只能通过网络传输数值，这抹杀了内存中数据库的所有潜在优势。这时，SAP 意识到他们需要放弃公分母策略，并打破对数据库的固有成见。

作为应对措施，SAP 制定了“下推”策略：将需要数据密集型计算的代码从应用层下推到数据库层。他们开发了一个全新的编程模型，允许 代码（以隐式或显式方式）调用存储在数据库中的过

ABAP程。

为了防止出现混乱，他们定义了一个标准过程库。该库被称为核心数据服务 (CDS)。并且他们同意将该库提供给支持存储过程的其他非 HANA数据库。

SAP 核心数据服务的发布与 Oracle 7 的发布相隔 20 年，这解释了 Oracle 客户和员工如释重负的原因：SAP 下推策略所取得的性能提升本该在 20 年前实现。但亡羊补牢，未为迟也。

Oracle Database In-Memory

Oracle Database 12c带有 Database In-Memory 选件，但它并不是内存中数据库。内存中数据库方法的支持者认为，数据库不应存储在磁盘上，而应（完全）存储在内存中，并且所有数据都应以列格式存储。我们很容易发现，有几个原因（包括数据持久性和通过 OLTP 应用进行数据操作）导致这个意义上的纯粹的内存中数据库不可能实现。因此，HANA等内存中数据库悄悄添加了一些与原有概念不符的组件和特性。而 Oracle 选择相反的策略：如有需要，数据可以填充到内存中列存储。在其他情况下，数据还按一贯的方式存储和处理。（有关 Oracle Database In-Memory 概念的更多信息，请参阅“用 Oracle 数据库选件和管理包为 SAP 客户实施数据管理基础设施”，尤其要关注第 35页的 "Oracle Database In-Memory"小节和第 23页的“总结”。）

Oracle Database In-Memory 已于 2015 年 6 月通过 SAP 认证。与竞争对手提供的类似产品不同，Oracle Database In-Memory 的应用场景并不限于 SAP Business Warehouse (SAP BW)，它可以用于所有基于 SAP NetWeaver的 SAP应用，包括典型的 OLTP应用。但这不表示 Oracle Database In-Memory 是一把万能钥匙。它是针对一个特定问题或一系列特定问题的解决方案，并不能解决所有问题。它不能在所有情况下实现性能提升。如果使用方式不当，它甚至可能会 — 像纯粹的内存中数据库一样 — 降低系统性能。因此必须精心选择可从数据的列格式存储中受益的 SAP应用。

11

5

5

面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

必须对应用和各个表进行选择 — 在 SAP 环境中实施 Oracle Database In-Memory 似乎很难。然而，早期采用者对体验 Oracle Database In-Memory 的描述非常一致，他们认为在 SAP 环境中可以轻松、快捷地实施 Oracle Database In-Memory。这似乎有悖于常理，但事实并非如此。

首先，许多客户都了解会占用大量时间的查询和作业，并且他们知道涉及的表。对于这些客户来说，选择合适的 SAP 应用和表的任务非常轻松。

其次，对于不希望实施 Oracle Database In-Memory 来解决特定问题而是愿意采用通用方法的客户， 提供了 In-Memory Advisor — 这是一个向导，能够分

Oracle

析特定系统的负载，并根据可用的内存量建议可填充

到列存储的表。这意味着“使用 Oracle Database InMemory 需要多少内存”这个常见问题失去了意义。情况正好反过来，您告诉 Oracle 您有多少内存，顾问程序就会告诉您如何以有效的方式使用这些内存。

第三，一旦确定了相关的表，之后的一切都能轻松、快速完成：发送一条 ALTER TABLE XXX INMEMORY语句，您声明相关表数据都填充到列存储中。从此刻起，所有操作均在后台执行。

与迁移到 HANA 等内存中数据库不同，实施 Oracle Database In-Memory 不需要革命性的改变：不需要新硬件、不需要新操作系统，也不需要新数据库。客户可以继续使用现有基础设施，而管理员只需几个小时就能完成对 Oracle Database In-Memory 的了解。

Flat Cube

Oracle Database In-Memory 在 2015 年 6 月通过 SAP 认证时还受到一些条件的限制。尤其是，SAP 强烈建议用户不要删除标准索引和聚合。这造成了一些失望，因为从 Oracle 的角度来看，当基表填充到列存储后，索引就毫无必要了，因此可以删除。

但在这种情况下（像在本文中描述的所有其他情况下一样），负责进行 SAP 和 Oracle 技术集成的 Oracle/ SAP 开发团队必须遵循 SAP 的学习曲线。 Oracle Database In-Memory 通过 SAP 认证后的情形（此处指的是通过 SAP BW 的认证）与在 HANA 上提供 SAP BW 的 SAP 项目的早期阶段非常相似。

就像传统 SAP BW 数据模型不兼容内存中数据库这种新概念一样，这种情况也在一定程度上让用户感到失望。

而我们将在本节稍后介绍的 Flat Cube 类似于 SAP为 HANA 设计的全新数据模型。在许多情况下，加载到 Business Warehouse 中的数据是超宽记录。即便一条记录中没有数百个数据项，也可能含有公司名、邮编、城市、街道地址以及详细运输信息、订单号、订单日期和发票号等数十项信息。但在数据仓储的早期阶段，数据库存储在磁盘中，而磁盘的价格非常昂贵，如果某家公司发来 1000个物品，该公司或运输信息就出现 1000 次，或者如果一家运输公司完成了 10 万次运输，该运输公司就出现 10 万次，这是令人无法接受的。因此，数据库架构师提出了一个名为星型模型 的设计：将放在一起的数据子集（所有的客户详细信息，所有的运输详细信息）迁移至各个单独的维度表中。其余的数据与 ID 存储在事实表中，指向维度表中的相关条目。

12

传统的“星型”（即扩展的雪花）模型

但这种拆分不能满足所有情况。例如，CUSTOMERS 和 CARRIERS 表中都可能会多次出现邮编、城市名和街道地址的组合。如果再次执行相同的拆分操作，系统会再创建一些表，但这些表不会连接到事实表，而会与维度表相连。这引出了更复杂，但更有效（从磁盘空间的角度来看）的设计，称作雪花模型。SAP BW 等高端数据仓库添加了另一个级别的明细表，因此依赖扩展的雪花模型。设计这种复杂的架构是为了优化数据模型，以满足传统的、只在磁盘中存储的关系数据库的需求。但着眼于内存的全新数据库（SAP HANA 和 Oracle Database In-Memory 在这一点上没有差别）有着截然不同的需求。

因此，SAP 专为在 HANA 上运行 SAP BW 设计了一个新的数据模型，并因此称之为经 HANA 优化的 InfoCube。

下面是对经 HANA 优化的 InfoCube 的简单（但有些出人意料）描述：如果为面向磁盘的数据库优化 SAP BW 数据模型是从平面的宽记录向扩展的星型模型转变的过程，那么为面向内存的数据库优化数据模型则是从扩展的星型模型转变回平面的宽记录的过程。

但这并不是完全反向的转变。经 HANA 优化的 InfoCube 在一个单独的表中结合了事实表（实际上是 E 和 F 事实表）和维度表（一级明细），而小型的二级和三级表（特征、属性和层级结构）仍然存在。这种变化足以显著地提升性能和可管理性。

13面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

新的平面多维数据集设计

这个新的数据模型消除了之前数据模型的主要缺陷，但保留了原有的优势。再也不需要拆分传入的宽记录并分配到多个表中 — 这加快了数据加载；不再需要传统的索引 — 这也加快了数据加载；以后不再需要进行表的联接 — 这加快了查询处理的速度。由于有了面向磁盘上数据和面向内存中数据的压缩特性，开始推动扩展的雪花模型发展并提高了冗余数据对磁盘和内存要求的平面数据模型的主要缺陷已经不再是问题。

如果这个新的数据模型要面向非 HANA 数据库，那么“经 HANA 优化的 Infocube”显然不是一个适当的名称。“SAP BW Flat InfoCube for Oracle” 或 “SAP BW Flat Cube for Oracle”指的是同一个数据模型，只是叫法不同。它需要与 Oracle Database 12c 和 Oracle Database In-Memory 一起使用，因为脱离列存储的 Flat Cube 没有任何意义。

面向 Oracle 数据库上 SAP BW 的 Flat Cube 已于 2016 年 6 月上市。要了解更多信息，请参阅 SAP 说明 2335159。

14

延迟压缩和信息生命周期管理我们已经在“基本认证特性”和“基本认证和应用优化”中讨论了 Oracle Database 12c Advanced Compression 中的一些新特性。但是，两个主要的新特性还没有介绍。它们不包含在基本认证中，但在几个月后（2015 年 12 月）通过了 SAP 环境的认证。这两个新特性是热图和自动数据优化 (ADO)。对于这两个特性背后的基本概念的介绍，请参阅“用 Oracle 数据库选件和管理包为 SAP 客户实施数据管理基础设施”，尤其要关注第 21 页的“Advanced Compression (Oracle Database 12c)”小节。我们将在这里简要介绍一下特定于 SAP 的实施。

Oracle Database 12c Advanced Compression 支持客户区分当前（“热”）和历史（“冷”）数据。但是，“热”和“冷”的含义并不明确。因此，我们需要进行定义： ALTER TABLE ILM ADD POLICY

AFTER DAYS OF NO MODIFICATION;

这条 SQL 语句的第三行回答了我们的问题。新数据被视为“热”数据。如果数据未修改的时长达到特定的天数（ 30、60、90 天），那么这些数据被视为“冷”数据 — 假设客户不希望定义“温”数据这样的中间级别。但如果仔细观察，我们会发现上述语句只回答了一个问题：何时将数据称为“冷”数据？

我们仍然不知道（而且数据库系统仍然不知道）：数据变冷后会怎么样？将发生什么情况？这将在第 2 行中定义： ALTER TABLE ILM ADD POLICY

ROW STORE COMPRESS ADVANCED ROW

AFTER 40 DAYS OF NO MODIFICATION;

在本示例中，我们假设（在这个特定的表中）热数据完全不压缩，而且我们告诉系统：(a) 未修改的时长达到 40 天的数据是冷数据，(b) 冷数据需要使用 Oracle Database 12c Advanced Compression 提供的表压缩算法进行压缩。

我们和系统如何知道数据未修改的时长已经达到40 天了？热图的工作就是提供这类信息。热图可在行级和段级自动跟踪修改和查询的时间戳，提供对数据访问方式的详细洞察。自动数据优化 (ADO)则可根据热图收集的信息按用户定义的策略（如我们在此处举出的示例）自动移动和压缩数据。

到目前为止，我们一直使用 ALTER TABLE 语句定义 ILM策略。但在 SAP 系统中，我们需要处理数万个表，使用这种方法可能非常繁琐。因此，BR*Tools (BRSPACE) 使用 Oracle 数据库提供的另一种方法： ALTER TABLESPACE TSX DEFAULT ILM ADD POLICY

ROW STORE COMPRESS ADVANCED ROW

AFTER 40 DAYS OF NO MODIFICATION;

15

5

5

面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

在本示例中，我们不为单独的表定义特殊的策略，而是使用表空间级别的默认策略。除了带有单独策略的表，此表空间中创建的所有表都自动应用默认策略。

在 Oracle 集成系统（如 Exadata、SuperCluster）上运行 Oracle Database 12c 的客户能够受益于混合列压缩 —这组压缩算法是存档的替代方案，适用于处理纯历史数据。如果 Advanced Compression 能达到 2 到 3 倍的数据压缩率，那么混合列压缩能轻松达到 10 到 15倍的压缩率。

在这种情况下，我们将未修改时长为 40 天的数据称为“温”数据，并将较长时期（例如 6 或 12 个月）未更改的数据称为“冷”数据。

我们将原有的策略作为第 1 层压缩（针对温数据），并添加一个额外的策略，作为第 2 层压缩（针对冷数据）。而且我们将未分区表和分区表分离到不同的表空间，因为混合列压缩不压缩各个块，而是压缩整个分区： ALTER TABLESPACE TSY DEFAULT ILM ADD POLICY

ROW STORE COMPRESS ADVANCED ROW

AFTER 40 DAYS OF NO MODIFICATION;

ALTER TABLESPACE TSY DEFAULT ILM ADD POLICY

COLUMN STORE COMPRESS FOR QUERY LOW ROW

LEVEL LOCKING SEGMENT

AFTER 6 MONTHS OF NO MODIFICATION;

Oracle Multitenant

Oracle Multitenant 是 Oracle Database 12c 的一个新选件，它通过简化整合、供应以及升级等过程来帮助客户降低 IT 成本。它由一个新架构提供支持，该架构允许在一个容器数据库 (CDB) 中容纳并管理多个可插拔数据库 (PDB)（请参阅“用 Oracle 数据库选件和管理包为 SAP 客户实施数据管理基础设施”，尤其要关注第 27 页的“ Oracle Multitenant”小节）。

使用 Oracle Multitenant，可以将多个现有数据库转换成 PDB 并整合到单个 CDB 中。PDB 是一个完备的功能齐全的 Oracle 数据库。从应用的角度来看，并没有发生什么变化。这一点非常重要，因为这意味着无需更改应用即可采用此架构。对于应用来说， PDB 就是数据库。但是，从运营角度看， CDB 才是数据库。

16

CDB 代表了单个整合运营环境。这里只有一组后台进程和一个共享内存区域 (SGA)，由 CDB 中的所有

共享。该架构消除了重复开销，从而能够充分利用PDB

可用资源。这意味着，您可以极大地减少资本支出 (CapEx)，因为可以在每个服务器上整合更多的应用（请参见图 11a-e）。从运营角度讲，您可以集中管理所有这些整合的 PDB，从而可以极大减少运营支出 (OpEx)。这对于备份、高可用性配置、补丁应用和升级等事项都适用。这些 CapEx 和 OpEx 上的减少是 Multitenant实现我们云计算承诺的一部分。

Oracle Multitenant 是面向下一代数据库云的架构。它实现了真正的规模经济。一个 VM 包含一个数据库，这种昂贵的模型被可插拔数据库 (PDB) 所取代。由于 PDB 固有的成本可以忽略不计，因此每个 SAP 系统的 PDB 成本缩减为它们所做的实际工作。

截至 2017 年 2 月，Oracle Multitenant 正式向所有使用 Oracle 数据库的 SAP 客户发布。 Oracle Multitenant

架构可用于所有基于 SAP NetWeaver 的应用，但不支持在同一容器数据库中混合使用 SAP OLAP (BW)和 SAP OLTP（ERP、CRM 等）系统。

数据库管理员可获得以下工具支持： • SWPM 自版本 1.0 SP 19 起支持创建容器数据库

(CDB) 和可插拔数据库 (PDB)。这些任务必须使用 SWPM 完成，以确保所创建的数据库（目录路径、文件名等）与 BR*Tools 兼容。有关详细信息，请参阅 SAP 说明 2336881。

• 在大多数情况下，客户不会创建新数据库，而是将现有的独立（非 CDB）数据库转变为可插拔数据库。SAP 说明 2335850 描述了针对这种转换的支持过程。

• BR*Tools 从版本 7.40 补丁 24 起支持 Oracle Multitenant。全新配置参数、命令和命令选项支持管理员通过熟悉的 BRCONNECT、BRSPACE、 BRBACKUP/BRARCHIVE 或 BRRESTORE/BRRECOVER 命令指定启动操作的目标数据库。

整合性能测试亮点：Oracle Multitenant 性能更高，需求资源更少

-

17面向 SAP 的 Oracle Database 12c：面向应用优化的全新数据库技术和支持

与 Oracle Database 12c相关的 SAP 说明

数据库：常规：版本支持

1174136，Oracle：支持服务终止日期

2428722，Oracle 12.1 的支持服务免费延长至 2019 年 7 月 31 日

2098258，Oracle 11.2 的支持服务免费延长至 2018 年 12 月 31 日

数据库：特性：概述 105047，面向 SAP 系统的 Oracle Database12c Advanced Compression

1914631，Oracle 12c：压缩表的转换

2133079，Oracle 12c：使用压缩表进行 SAP 升级过程中存在的问题

2138262，BR*Tools 支持 Oracle ADO/ILM

2157904，使用 Oracle Database 12c自动数据优化

2166836，Oracle 12c：使用压缩表进行 SAP 升级过程中存在的问题

2254836，BR*Tools 支持 Oracle ADO/ILM

2254866，使用 Oracle Database 12c自动数据优化

2255992，R3load 和 R3szchk：针对数据库 ILM 策略的 Oracle 新特性

2258061，针对表转换或系统复制的 ADO/ILM 的增强

2384534，使用 BRSPACE 7.40 进行 LOB 转换和表压缩

数据库：选件： In Memory

2178980，使用 Oracle Database In-Memory 和基于 SAP NetWeaver 的产品

2137032，DBA Cockpit：面向 In-Memory 特性的监视

2189163，面向 SAP 的 Oracle Database In-Memory Advisor

2335159，面向 Oracle 数据库上 SAP BW 的 Flat Cube

2351252，适用于 SAP BW 的 Oracle Database 12c In-Memory 工具包

数据库：选件： Multitenant

2333995，BR*Tools 支持 Oracle Multitenant 数据库

2335850，将现有独立数据库转变成可插拔数据库

2336881，使用 Oracle Multitenant 和基于 SAP NetWeaver 的产品

数据库：选件： Database Vault

2218115，Oracle Database Vault 12c

数据库：安装与升级

1915299，为 12.1.0.2 安装故障排除软件

1915301，在 Unix 上安装 Database 12.1.0.2 的软件

1915302，在 Windows 上安装 Database 12.1.0.2 的软件

1915315，面向 12.1.0.2 的数据库升级脚本

1915317，迁移到软件所有者 'oracle'

1915323，面向 Oracle Database 12c R1 的操作系统用户概念

2064206，将数据库升级到采用 Grid Infrastructure 的 12.1.0.2 版本

数据库：补丁

1915313，针对 Oracle Database 12c R1 (12.1) 的当前补丁集

1915316，数据库：针对 12.1.0.2 的补丁

2145572，Grid Infrastructure：针对 12.1.0.2 的补丁

数据库：实例配置

1888485，数据库参数 12.1.0.2

数据库：管理： BR*Tools

2087004，面向 Oracle Database 12c的 BR*Tools 支持

集成系统

2145628，Exadata/SuperCluster：针对 12.1.0.2 的补丁

2145651，Oracle 数据库机：针对 12.1.0.2 的补丁

2290084，SAP 软件和 Oracle 数据库机 12.1

2388511，面向 SAP 的 Oracle 数据库机 (ODA) X6-2 系统

18

用 ORACLE 数据库选件和管理包为 SAP 客户实施数据管理基础设施

简介数据库版本 Oracle 数据库有 5 个版本，每个版本适用于不同的开发和部署场景。不过只有 Oracle 数据库企业版获得了 SAP 环境的认证和支持。因为 SAP 应用要求非常严苛，只有 Oracle 数据库企业版提供的企业级计算特性才能使其高效运行。

数据库选件和管理包 Oracle 还提供若干个数据库选件、管理包和其他产品来增强 Oracle 数据库的专用功能。它们增强了 Oracle 数据库企业版的能力，可以满足特定客户或应用对磁盘空间高效使用、性能和可扩展性、高可用性、安全性和合规性、数据仓储和大数据以及可管理性等方面的各种需求。

面向 SAP 环境的选件和管理包本文将介绍面向 SAP 客户的数据库选件和管理包。普通的 Oracle 数据库和面向 SAP 的 Oracle 数据库之间有很多不同：

• 即便一个选件通过了认证，SAP 也可能不支持其中的某些特性。本文为概括说明，受篇幅所限，不能讨论所有详细信息。如果您有任何疑问，也可以查看 SAP 说明 105047。

• 由于 SAP 数据模型或应用设计的独特性， Oracle Database 选件或管理包可能是它的必需搭档，而不是可选组件。举例来说，在 Oracle 数据库上运行 SAP Business Warehouse (BW) 就需要安装有 Oracle Partitioning。

• Oracle 的客户需要单独购买选件或管理包的许可。但是从 SAP (ASFU) 购买 Oracle 数据库企业版的客户可以免费获得一些（但不是所有）选件和管理包。有关详细信息，请参阅 SAP 说明 740897。

图 1：Oracle 数据库企业版、数据库选件（通过认证的必需选件或通过认证的可选选件）以及 Enterprise Manager 管理包（通过认证的必需管理包或通过认证的可选管理包）。

19面向 SAP 客户的 Oracle 数据库选件和管理包

以上所有问题的共同点是：默认情况下（根据定义），数据库中的表是不保证物理顺序的、无序的记录集，但是从用户、应用或 DBA 的角度来说，这个数据集可能由特定的子集构成，这些子集在理想情况下应与其他子集隔离。Oracle Partitioning 从物理上将相关数据尽可能紧密地存储在一起，从而使用户能够实现这样的子集。

表和索引分区

挑战：如今，磁盘上的数据分布成为问题的情况越来越多： (a) 单一查询或复杂的批处理任务访问表数据的某个子集需要太长时间。 (b) 数据加载 (SAP BW) 速度缓慢，因为必须更新很多索引；要缩短加载时间就需要删除或重新构建索引，而这会减缓用户查询的速度。 (c) 数据存档导致数据库严重碎片化。 (d) 客户希望实施信息生命周期管理（请参见本文 Oracle DB 12c章节）。价值主张：Oracle Partitioning 将表和索引划分为较小的单元（称为分区）并且强制将所有数据存储在相应的单元中。各个分区可以单独访问和管理。因此： (a) 理想情况下，通过一个查询便能在一个分区中找到所有相关数据，而其他所有分区都可以

结构和基础设施如前所述，数据库选件增强了 Oracle 数据库企业版的能力，可以满足客户对磁盘空间高效使用、性能和可扩展性、高可用性、安全性和合规性、数据仓储和大数据以及可管理性等方面的需求。不过，本文只关注其中一个方面，即数据库选件如何帮助客户实现结构化。如果一个数据库的数据量不断增加，并且这些数据来自不同来源甚至来自一个数据管理基础设施（例如 Oracle Multitenant）中整合的多个数据库时，当数据量和复杂性增加到一定程度，非结构化的海量数据将变得难以处理。因此，整合需要差别化。或者：基础设施需要结构化。

忽略（“分区修剪”）。这大大缩短了运行时间。 (b)如果某个分区表中定义的索引也进行了分区，那么用户可以删除或重新构建各个索引分区，而其他所有分区保持原样。 (c)数据存档策略可以基于分区结构，避免磁盘空间产生碎片。 (d) 分区是信息生命周期管理的基本技术之一。认证/支持：Oracle Partitioning 通过了所有 SAP NetWeaver 应用的认证。版本：Oracle Database 11g、Oracle Database 12c实施：默认情况下，在运行于Oracle上的SAP BW 中配置和使用分区（范围分区）。在 SAP OLTP 系统中，可以使用 SAP 分区引擎实施（能够解决数据存档问题），也可以由面向 SAP 的 Oracle ACS 实施。

20

图 2 解释了为何将相关数据尽可能紧密地存储在一起能产生这样的结果。图中显示了填有记录的数据库块。不同的颜色代表不同的条件，比如不同的月份或不同的位置。我们假定在大多数情况下，访问这些数据的应用希望检索相同颜色的所有记录。

图 2：表分区 —从物理上将相关数据子集尽可能紧密地存储在一起

在这种情况下，左侧显示的是可以想象的非常糟糕的状况：每个数据库块包含每种颜色的一条记录。换句话说，具有相同颜色的所有记录子集分布在所有

Advanced Compression (Oracle Database 11g)

挑战：如今，数据库规模和未来预期增长成为问题的情况越来越多。该问题所涉及的方面有：存储成本、性能保障 (SLA) 以及在合理时间内克隆和备份数据库文件。价值主张：Oracle Advanced Compression 采用不同的格式存储表数据。它与 数据库企业版自带的其他压缩技术（例如，索引

Oracle 键压缩）结

合使用有助于将数据库规模减小 50% 或更多。这属于基本优势，是 Advanced Compression 的设计宗旨。如果源数据库较小，创建备份和其他副本所需的时间更短。

数据库块中。从 I/O 角度看，一个查询要查找某一颜色的全部记录需要读取 8 个数据库块；从内存的角度看，即使所有用户处理的是相同颜色的记录，也需要将全部 8 个块完全缓存到数据库内存中；从性能的角度看，太多 I/O 意味着性能不理想；从数据库管理的角度看，无法单独管理有相同颜色的记录子集；从 ILM 的角度看，无法分隔“热”数据和“冷”数据；所以这是非常糟糕的状况。

相比之下，右侧的状况是理想的（重申一下，我们针对的是上述情况）：具有相同颜色的记录都存储在同一个数据库块中。从 I/O 角度看，一个查询要查找某一颜色的所有记录只需读取 1 个块；从内存的角度看，如果所有用户都处理相同颜色的记录，那么只需将 1 个块缓存到数据库内存中；从性能的角度看，I/O 数的显著减少意味着性能大大提升；从数据库管理的角度看，可以单独管理有相同颜色的记录子集；从 ILM 的角度看，可以分隔“热”数据和“冷”数据；所以这是理想的状况。

现在，将这一侧显示的记录数乘以块数。一个分区就是包含相同颜色记录的所有块的子集。

使用 Advanced Compression 的客户可获得性能提升的额外好处。这里的额外（相对于“基本”）指的是：可能会发生，但不保证一定发生。认证/支持：Oracle Advanced Compression 通过了所有 SAP NetWeaver 应用的认证。由 SAP 为实施提供支持。实施：Oracle Advanced Compression 可以在 SAP 环境中轻松实施，因为 SAP 提供了 BRSPACE 工具，它能识别所有特定于 SAP 的需求。有关详细信息，请查看 SAP 说明 1431296。

面向 SAP 客户的 Oracle 数据库选件和管理包 21

图 3 的左侧为典型的 Oracle 数据库，这是 SAP（本案例中为 ERP）系统不可或缺的组成部分。大约有三分之一的

SAP磁盘分配给索引（红色）使用，三分

之二的磁盘保存表数据（蓝色）。表数据又可以分为结构化数据（以列的形式组织）和非结构化数据（例如， PDF 或图像文件）。 Oracle Database 11g 可以压缩所有三种数据类型： • 索引键压缩 — 用于索引。也可以压缩索引组织表

(IOT)。Oracle 数据库企业版中自带这两个特性，不需要安装 Advanced Compression。

• OLTP 压缩 — Advanced Compression 的主要特性，可用于压缩结构化的表数据。该特性并不局限于 OLTP 系统，也可以在 SAP BW 系统中实施。

• SecureFile 压缩（也是 Advanced Compression 的一个特性） —可用于压缩非结构化的表数据。如果实施了所有特性，并对所有适合的数据库对象进行了压缩，那么客户的磁盘空间平均可节省 55%。（假设这是彻底重组的数据库。如果是未经重组的碎片化数据库，那么经过重组和压缩之后，客户的磁盘空间节省可高达 80%。）

Advanced Compression (Oracle Database 12c)

挑战：(a) Oracle Database 11g 中的数据压缩存在一些限制。尤其是无法压缩超过 255 列的表。 (b) 如果目标表经过压缩，则数据加载速度会变慢。(c) 不支持自动化的信息生命周期管理。价值主张：Oracle Database 12c Advanced Compression打破了 255列这个限制，允许压缩更多的表。其全新特性（热图、自动数据优化）支持客户实施延迟数据压缩策略和复杂的信息生命周期管理 (ILM) 策略。

能节省多少磁盘空间取决于数据的特征，而数据特征又取决于采用何种 SAP 应用。通常，SAP BW (BI) 数据的压缩效率高于 SAP ERP (ECC) 数据，而 SAP CRM 数据可实现更高的磁盘空间节省。 Oracle Database 11g Advanced Compression 不仅能提供 OLTP 和 SecureFile 压缩。它还可以大幅压缩由 RMAN 创建的备份文件以及由 Data Pump 创建的导出文件，甚至生产数据库中的表和索引也能够压缩。此外，重做日志数据在从生产数据库运送到备用数据库之前也可以进行压缩（请参阅本文的 Data Guard 章节）。

图 3：Oracle Database 11g 索引键压缩和 Advanced Compression（OLTP 压缩、SecureFile 压缩）

认证/支持：Oracle Database 12c Advanced Compression 中的一些新特性已于 2015 年 3 月通过了认证。对 ILM 特性的认证已于 2015 年第四季度末完成。实施：请参阅 SAP说明 2258061 – 针对表转换或系统复制的 ADO/ILM的增强相关特性：Oracle Database 12c 混合列压缩（ Advanced Compression 中不包含该特性，但可从集成系统获得）提供更强大的压缩算法，尤其适

Oracle

用于“冷”数据（即历史数据）。对 Oracle 集成系统上的 HCC的认证已于 2015年 12月完成。

22

基本认证特性在 Oracle Database 11g 中，索引和表压缩特性存在一些限制。因此 Oracle Database 12c Advanced Compression 提供了新的、更高效的索引压缩算法（高级索引压缩），增加了可压缩的表的列数。有关详细信息，请参阅本文中的“面向 SAP 的 Oracle Database 12c —规划和基本认证特性”。

热图和自动数据优化除了这些改进之外，Oracle Database 12c Advanced Compression 还增加了两个全新的特性。其中，热图可在行级和段级自动跟踪修改和查询的时间戳，提供对数据访问方式的详细洞察。自动数据优化 (ADO) 则可根据热图收集的信息按用户定义的策略自动移动和压缩数据。延迟压缩从 Advanced Compression (Oracle Database 11g) 章节提供的信息来看，似乎压缩只是减少了所需的磁盘空间，与数据库结构没有关系。这是一种错误的观念。即使在 Oracle Database 11g 中，我们也需要辨别压缩受益表和压缩非受益表（如果都是压缩受益表，那么默认会压缩所有的表），也就是需要辨别哪些表应该压缩而哪些表不应该压缩。

尽管如此，这仍然是一种非常基本、不灵活的辨别。以用于数据加载的 SAP BW 表为例：一方面，这样的表可以被压缩，因为大多数时候是以只读模式访问它。另一方面，它又不应该被压缩，因为压缩会大大降低加载操作的速度。在 Oracle Database 11g 中，推荐的做法是不压缩这一类表。

热图和自动数据优化可帮您引入一种新的区分参数：如果表或分区应被压缩，那么您希望在何时进行压缩？在 Oracle Database 11g 中，用户只能选择立即进行压缩或不进行压缩。而在12c中，您可以指定在今天加载数据、明天（自动）

Oracle Database

压缩数据。

信息生命周期管理由于 Oracle Database 12c Advanced Compression 中新增了一些特性，您可以引入更多的参数。其中一个参数是位置。当数据库中同时存在“热”（当前）数据和“冷”（历史）数据，并且您有两种不同的存储类型，此时您会有疑问：存储在哪里？这两种数据应该分别存储在哪里呢？

除了 Advanced Compression，您还可以使用 Partitioning，或者，您可以将数据从一个表空间（即存储层）移至另一个表空间，当这些数据“变得不活跃”时，就释放成本较高的存储层上的空间来存储更重要的（“热”）数据。这种方法称为（自动）存储分层。

混合列压缩 (HCC)如果您在 Oracle Exadata 或 Oracle SuperCluster 上运行 Oracle Database 12c，您会遇到下一个问题：如何操作？您希望如何（也就是使用哪种算法）压缩数据？

除了 OLTP 和 SecureFiles 压缩，集成系统还支持混合列压缩。顾名思义，此技术使用行和列方法的组合来存储数据。这种混合方法既可获得列存储的压缩优势，又可避免纯列形式的性能劣势。采用 HCC可实现的压缩率要远远高于“普通”压缩。因此 HCC尤其适用于“冷”数据。

由于缺少行级锁定功能，因此一直未能证明 Oracle Database 11g 混合列压缩是否可用于 SAP 环境。不过在 Oracle Database 12c中，用户可在 Oracle Exadata 和 Oracle SuperCluster 上使用该功能。您可以在这些系统上实施（自动）压缩分层。也就是说，当不压缩“热”数据时，可以用标准压缩算法 (Advanced Compression) 压缩“温”数据，用混合列压缩算法压缩“冷”数据。

23面向 SAP 客户的 Oracle 数据库选件和管理包

图 4：Oracle Database 12c Advanced Compression —支持信息生命周期管理 (ILM)

Oracle Database In-Memory

挑战：越来越多的系统需要满足分析性能需求，这已成为一大挑战。例如， BW 系统需要长时间运行查询。 OLTP 系统也会存在这个问题，例如，如果非常灵活地实施运营计划 /报告，这意味着允许用户创建大量略有不同的查询变体。价值主张：Oracle Database 12c In-Memory 允许管理员将一定数量的数据库服务器内存分给列存储 —这种内存结构以列格式（而非行格式）存

内存：新的双格式架构 Oracle 数据库历来采用行格式存储数据。这是联机事务处理 (OLTP) 系统的理想格式，因为它允许快速访问记录中的所有列。列格式数据库以单独的列结构存储事务或记录的每个属性。这是执行分析的理想格式，因为当仅选择了少量列但是查询要访问大部分的数据集时，这种格式能够更快地执行数据检索。

但如果您的系统运行的是混合负载，会出现什么情况呢？到目前为止，您只能选用一种格式，要么牺牲 OLTP 性能，要么牺牲分析性能。同时让 OLTP 和分析性能得到优化的方法是用复杂的 ETL 流程将数据从 OLTP 系统复制到分析系统，但这既会增加开销又会延长时间。

储数据。列存储的建立过程既快速又轻松。采用列格式可以大大提升查询的性能。认证/支持：Oracle Database In-Memory 通过了所有 SAP NetWeaver 应用的认证。版本：Oracle Database 12c

实施：如需了解概要信息和更详细的参考资料链接，请参阅 SAP 说明 2178980。

Oracle Database 12c In-Memory 可以优化分析和混合负载 OLTP，不仅提供出色的事务处理性能，还同时支持实时分析、商务智能和报告。这个突破性的功能依托 Oracle Database In-Memory 的双格式架构。该架构同时使用传统的行格式和全新的内存中列格式来表示表，您无需再进行权衡取舍。Oracle SQL Optimizer 自动将分析查询发送到列格式，将 OLTP 查询发送到行格式，从而透明地向两者提供出色的性能。就像 Oracle Database 12c如今在表和索引之间保持一致性一样，它也自动在行格式和列格式之间保持完全的事务一致性。

24

磁盘：没有任何改变新的列格式是纯粹的内存中格式。我们采用基于行的现有格式将表存储在磁盘上（或者以混合

Oracle

列格式存储在集成系统上）。由于没有持久的列存储格式，因此没有额外的存储成本，不存在存储同步问题，而且无需修改数据库。Oracle Database 12c In-Memory 的实施无需进行数据库迁移或表重组。

这样一来，新的 Oracle Database 12c In-Memory 特性完全兼容现有的标准数据库特性或可选数据库特性，如表和索引压缩、表加密以及表分区。同时，它还兼容 Real Application Clusters (RAC) 提供的横向扩展架构以及所有现有的高可用性技术（如 Data Guard）。这些特性无论是与 Oracle Database In-Memory 搭配使用还是独立使用都能发挥一样良好的效果。

易于实施和管理除了兼容数据库特性和应用，Oracle Database In-Memory还易于实施和管理。启用 Oracle Database In-Memory非常简单，只需设置内存中列存储的大小并确认要放到内存中的表和分区即可。由后台进程将数据从存储填充到内存列中，同时数据库保持完全活动和可访问。细粒度控制为典型场景提供智能默认值让用户可以轻松上手 —这正是 Oracle 客户所期望的。此外，Oracle 客户还期望有实现细粒度控制和调优的机制。因此 Oracle Database 12c In-Memory 提供了这样的机制。例如： • 表可以包含“冷”数据，也就是不再更新并且查询不再访问的数据。如果这些表非常大，那将它们全部保存在内存中列存储中就会浪费内存。因此，管理员希望只填充 DSS 查询真正需要的数据。表分区可以帮助他们实现这一点。如果按照实用的方式（例如，按月）进行表分区，则这个内部结构可用于定义要保留在内存中列存储中的表数据的一个水平子集。

• 一个或多个表列中有可能包含与 DSS 查询不相关的数据。数据库管理员可能也希望限制保存在内存中列存储中的数据，但此时的目标是定义表数据的一个垂直子集，即在填充过程中排除一个或多个列。同样，Oracle 可以帮助您实现这一点，因为 Oracle Database In-Memory 允许管理员针对不同的表列指定不同的内存中特征。

• 数十年来 Oracle 数据库经过不断优化和调优，可在 SMP 服务器上纵向扩展。大型 SMP 服务器也非常适合内存中负载，因为极速背板上的全部处理器均可访问所有内存。Oracle Database In-Memory 不仅能够纵向扩展，而且还可以利用服务器集群 (RAC) 中的所有内存和处理器来横向扩展至极高的内存和 CPU 容量。在这样的环境下，填充到内存中的所有对象将默认分布到集群的所有内存中列存储。用户也可以在 Oracle 集成系统上复制对象。也就是说，填充到内存中列存储的一个对象（或对象的一部分，例如一个分区）会将镜像副本放置在 集群的其他某个节点上。复制数据可提供内存中

RAC 容错，因为即使某个节点出现故

障或因维护而停机，用户仍然可通过内存中列存储访问数据。

图 5：Oracle Database 12c In-Memory —双内存格式、单一磁盘格式

25面向 SAP 客户的 Oracle 数据库选件和管理包

Real Application Clusters (RAC)

挑战：当数据库服务器上的负载增加（例如由于应用版本更新、新安装了应用或者增加了用户等）时，传统解决方案是将现有服务器替换为更大的服务器（纵向扩展）。但是大服务器是极其昂贵的。为了保证数据库服务器的高可用性，常规做法是实施故障切换集群。不过这样的解决方案至少存在两个弊端： (a) 故障切换集群的设计理念是，在任何指定时间点，一个服务器上只有一个数据库实例处于活动状态。其他服务器（极有可能也是价格昂贵的服务器）都处于空闲状态。 (b) 当在主服务器上检测到故障时，需要在辅助服务器上启动 Oracle 数据库服务器实例。在这种特定情况下，启动可能要花 30 分钟的时间，这就意味着长达 30 分钟的计划外停机。价值主张：Real Application Clusters (RAC) 允许上线运行多个实例以及同时访问同一个数据库。由于这些实例可以（而且在大多数情况下确实）运行在不同的服务器上，因此客户可以选择实施横向扩展方案：4、6 或 8 台小型服务

图 6 显示了刚提过的 RAC 优势：可扩展性：使用 RAC 时，客户也可以在数据库层面实施 SAP 应用服务器始终支持的横向扩展方法。

器的负载处理能力相当于一台大型服务器。不过小型服务器的价格要便宜得多。而且可以根据需要增加服务器的数量。在这种架构中，所有 Oracle 实例同时上线运行。因此不需要重新启动。如果某个 RAC 服务器发生故障，其他实例可以随时接替。受影响的用户只需数秒（而非数分钟）就可以完成重新连接。总而言之，Oracle Real Application Clusters 集负载分布、可扩展性、高可用性、更出色的可管理性以及成本节省等多种优势于一身。认证/支持：Oracle Real Application Clusters 通过了所有 SAP NetWeaver 应用的认证。版本：Oracle Database 11g、Oracle Database 12c实施：客户可以使用通过 SAP认证的任何通用设备（Unix、Linux 或 Windows）构建 RAC 系统。采用 Oracle提供的集成系统（ Exadata、SuperCluster）进行实施则更加容易。 Oracle Grid Infrastructure提供一系列基础技术来简化实施和帮助节省资金。

在本示例中，运行于 5 个不同服务器上的 5 个 SAP 应用服务器实例连接到了运行于 4 个不同服务器上的 4 个 Oracle 数据库服务器实例上。

图 6：用 Real Application Clusters (RAC) 实现横向扩展和即时（实例）故障切换

26

高可用性：如果某个 Oracle 实例出现故障，受影响的 SAP 实例将自动重新连接到一个可用的 Oracle 实例上。随后用户可以继续自己的工作。完成故障切换只需数秒钟。

Oracle Grid Infrastructure提供了支持 RAC 所需的基础技术。它有两个主要组件： • 要让多个 Oracle 实例同时访问数据库文件，我们需要一个集群文件系统。因此 Oracle 提供了 Oracle Automatic Storage Management (ASM)。与其他第三方集群文件系统不同的是，该系统针对 Oracle 数据库文件进行了优化，并且可免费使用。

Data Guard 和 Active Data Guard

挑战：RAC 通过增加 Oracle 实例数量提供高可用性。然而这样的高可用性仅限于实例级别。即使在基于 RAC 的系统中，数据库仍然存在单点故障。这意味着 DBA 失误、数据损坏、服务器或数据中心故障都可能导致整个系统无法使用。价值主张：Data Guard 可消除这种单点故障。使用该技术时，客户可以设置一个备用（影子）数据库作为主用（生产）数据库的副本，然后让两个数据库保持同步。请注意，Data Guard 包含在 Oracle 数据库企业版中。它不是一个选件。但 Active Data Guard 是一个选件。在 Oracle Database 11g中，它提供一些附加特性，如自动块修复和快速增量备份。

Data Guard 可以提供零数据损失保护，并可以接近即时的速度恢复因任何原因变得几乎无法恢复的生产数据库。这是利用 Data Guard 同步重做传输并结合备份数据库端可感知复制的应用进程实现的。然而，任何同步复制方法都可能对数据库性能产生影

• Oracle Clusterware 是运行 Oracle 数据库的 RAC 选件所需的跨平台集群软件。它支持节点之间彼此通信，让这些节点构成一个就像单个逻辑服务器一样运行的节点集群。Oracle ASM 消除了对于第三方集群文件系统的需求，与之类似，Oracle Clusterware 则消除了对于第三方集群管理软件的需求。

Oracle Clusterware 可以像对 Oracle 资源一样为 SAP 资源提供高可用性和资源管理。因此 Oracle/SAP 开发团队打造了一款 Oracle Clusterware 工具 SAP Control (SAPCTL)，用以帮助客户轻松管理 SAP 高可用性资源。

Active Data Guard Far Sync 是 Oracle Database 12c

提供的一个主要的新特性。该特性允许客户对 WAN 中相隔距离遥远的主数据库和备份数据库

进行同步，不仅能实现高性能（异步数据传输的

特征），还能实现零数据丢失（同步数据传输的

特征）。

认证/支持：Oracle Data Guard 通过了所有 SAP NetWeaver 应用的认证。但目前只支持物理备用数据库，不支持逻辑备用数据库。 Oracle Active Data Guard 通过了所有 SAP NetWeaver 应用的认证。但不能在 SAP 环境下执行实时查询，因为就连报告生成也不是只读操作。版本：Oracle Database 11g、Oracle Database 12c实施：适用标准的 Oracle 设置过程。SAP 在 “Oracle 备用数据库”白皮书中介绍了 BR*Tools 支持。

响，当主数据库和复制数据库相隔很远时，这一点常常让零数据损失保护变得不切实际。相较于数据保护，很多企业更重视数据库性能，于是会选择实施异步复制，并接受了不可恢复的中断将导致各种程度的数据损失这一现实。

27面向 SAP 客户的 Oracle 数据库选件和管理包

Active Data Guard Far Sync 是 Oracle Database 12c提供的新功能，可以将零数据损失保护从主数据库扩展到相距任意距离的副本数据库上，客户无需再权衡利弊。Far Sync 使相距主数据库任意距离的备用数据库与主数据库保持同步，从而为生产数据库提供了零数据损失保护，而且这种方法不影响性能、成本低、复杂度也很低。新的 Data Guard 目标类型（称为远程同步实例）同步从主数据库接收变更，然后将变更异步转发给远端备用数据库。无论采用手动还是自动方式，生产数据库都可以快速故障切换到远端备用数据库，且不产生任何数据损失。

远程同步实例是只管理控制文件和日志文件的轻型实体。它仅需要占用备用数据库的一小部分 CPU、内存和 I/O。它没有用户数据文件，也不运行恢复。其目的就是透明地将为远程目标提供服务的主数据库的负载进行分流。远程同步实例用Advanced Compression 执行传输压缩，因此可以节

Oracle

省网络带宽。

Oracle Multitenant

挑战：很多 SAP 环境是由几个大型系统和大量小型或非常小型的系统构成的。但是由很多小型 SAP 系统充当独立的数据库服务器有一些弊端： • 大量小型系统（甚至是虚拟化系统）会占用大量硬件资源（内存、 CPU）

• 管理众多小型数据库系统需要花费大量时间价值主张：Oracle Multitenant 将“容器”数据库和“可插拔”数据库进行隔离，以减少资源占

Oracle Database 12c Multitenant 引入了一种全新的架构，支持客户在不改变应用的情况下轻松整合多个数据库。这种架构具有将多个数据库作为一个数据库进行管理的所有优点，而且保留了独立数据库的数据隔离和资源优先级。

以一个现有的 Data Guard 异步配置为例：主数据库位于波士顿，备用数据库位于旧金山。只需在波士顿的同步复制距离（小于 150英里）内用 Active Data Guard部署一个远程同步实例即可实现零数据损失。这既不会破坏现有环境，也不需要专用存储、专有网络、更多数据库许可或复杂的管理。

图 7：Active Data Guard Far Sync —跨远距离 WAN 提供高性能和零数据损失保护

用。它将标准操作移至“容器数据库”级别，从而简化管理。认证/支持：Oracle Multitenant 已通过认证。版本：Oracle Database 12c

实施：要了解更多信息，请访问 http://scn.sap.com/community/oracle 或 www.oracle.com/sap

整合方法大型企业可能会使用数百个甚至数千个数据库。这些数据库通常运行在多个物理服务器上的不同平台上。一个数据库可能只占用一小部分服务器硬件容量。这种方法成本高昂，无法充分利用硬件和人力资源。

www.oracle.com/saphttp://scn.sap.com/community/oracle

28

应对这个管理问题的常规做法是在每个服务器上放置多个数据库（直接安装或者使用虚拟机）。但问题是，多个数据库实例并不共享后台进程、系统和进程内存，也不共享 Oracle 元数据。还有一种做法是从逻辑上将数据划分为不同的模式（模式整合）。但问题是，这些虚拟实体难以管理、难以保障安全且难以传输。

Oracle Multitenant 架构 Oracle Database 12c Multitenant 基于一种称为数据库整合的方法。它提供一种新的架构，支持一个容器数据库 (CDB) 容纳多个可插拔数据库 (PDB)。请参见图 8。

现有数据库可以“插入到”一个 中。以后可以在任何时间将其拔出，然后插入到另

CDB 一个 CDB

中。所有 Oracle 数据库软件版本均支持拔出/插入操作。

从通过 Oracle Net 连接至数据库服务器的客户端应用的角度来看，PDB 就是数据库。PDB 与非 CDB 完全兼容 — 这一规则也被称为 PDB/非 CDB 兼容性保障。

资源利用和资源管理一个 CDB 中的众多 PDB 共享其内存和后台进程。与旧架构提供的基于模式的整合方法相比，这种方法能够整合更多的数据库，并且不需要对应用进行重大的更改。

Oracle 数据字典的水平分区（一种概念分区，并非物理表分区）不再需要在每一个数据库中存储和管理系统级元数据。“下”半部（在 CDB 中实施）只保存系统级元数据，而“上”半部（在 PDB 中实施）只保存特定于应用的元数据。

用新的 SQL 命令创建可插拔数据库、在容器间移动可插拔数据库和克隆可插拔数据库，这些操作仅需数秒即可完成。如果底层文件系统支持精简供应，TB 级数据的克隆几乎可以瞬间完成。

由于共享后台进程、内存结构、系统级元数据和数据库文件，因此资源占用大大减少。此外，客户还可以使用特定功能扩展 Oracle Database 12c Resource Manager，以便控制一个 CDB 中多个 PDB 之间的资源争用。

将多个数据库作为一个整体来管理

通过将现有数据库整合为可插拔数据库，管理员可以将多个数据库作为一个整体来管理。这种做法的优势包括： • 在给一个 CDB 打补丁的同时也完成了对其中多个 打补丁的操作。要升级 CDB 中的所有 PDB，只

PDB 需升级 CDB，其中的所有 PDB 即可“就

地”升级。 • 管理员不用执行单独的数据库备份，只需在 CDB 级别备份数据库即可。换言之，所有整合到一个容器中的 PDB 将被视为一个整体来进行备份，不过，数据库管理员在必要时也可以灵活地对单个 PDB 执行恢复操作。

• 管理员在另一数据中心（用 Data Guard 或 Active Data Guard）维护备用系统将只需在 CDB 级别设置一个备用配置即可复制该容器中整合的所有 PDB。

图 8：Oracle Multitenant —采用新架构来整合数据库和简化操作

29面向 SAP 客户的 Oracle 数据库选件和管理包

Oracle Advanced Security

挑战：要读取或更新存储有 SAP 应用数据的 Oracle数据库，对合法用户而言，显而易见的选择就是使用这一特定应用。但攻击者不一样，他们想绕过 SAP 的用户管理和访问控制，所以可能会用网络嗅探工具捕捉传输中的数据或者用某些文件编辑器读取静止数据，即数据库文件副本中的数据。价值主张：Oracle Advanced Security 包含一系列特性，使管理员能够加密数据，让攻击者更难以理解看到的信息。客户可以用 Oracle 网络加密保护传输中的数据，用 Oracle 透明数据加密

保护传输中的数据：Oracle 网络加密在 SAP 环境中，用户并非直接连接到 Oracle 数据库服务器。他们先连接到 SAP 应用服务器实例，然后由 SAP 应用服务器实例连接到 Oracle 数据库服务器。在这种情况下，应用服务器实例就是 Oracle 客户端，Oracle 网络加密将对往返于应用服务器和数据库服务器之间的所有数据进行加密。

Oracle 网络加密需要 Oracle 软件，而 Oracle 软件并不安装在用户的设备上。因此，我们必须使用其他技术或产品来保护 SAP 用户和 SAP 应用服务器之间的通信。

然而，人们不仅可能试图读取传输中的数据，而且还可能试图截获并修改它们。因此，除了网络加密之外，Oracle 还支持加密校验和来确保数据完整性。加密和加密校验和都对应用完全透明，并且都为系统管理员提供了多种算法选择。1

1请注意：截至 2013 年 6 月，网络加密和加密校验和不再是 Oracle Advanced Security

的一部分。他们包含在所有受支持的、经过许可的 Oracle 数据库版本中，由 Oracle 免

费提供。

和备份集加密保护生产数据库文件及其备份副本中的数据。认证/支持：Oracle Advanced Security 通过了所有 SAP NetWeaver 应用的认证。由 SAP 为实施提供支持。版本：Oracle Database 11g、Oracle Database 12c实施：可通过 Oracle Net 配置或用 SAP 的 BR*Tools 激活 Advanced Security 特性。有关详细信息，请参阅 SAP 说明 973450、974876 和 1324684。

保护静止数据：Oracle 透明数据加密 Oracle 透明数据加密 (TDE) 对构成生产数据库的文件（而不是备份文件，此类文件将在下一节中讨论）中的数据进行加密。顾名思义， TDE 对应用透明，不需要更改应用。自 SAP NetWeaver v7.20 起，您可以使用 BRSPACE 在表空间级别设置加密属性。 BRSPACE 还可以用于管理存储加密密钥的钱夹。

透明数据加密有两种形式。一种是列加密（从 Oracle Database 10g开始提供），也就是只选择部分SAP表，甚至只选择这些表中包含敏感数据的列进行加密。而其他一切均保持未加密状态。第二种是表空间加密（从 Oracle Database 11g开始提供）。它可以加密可能包含数百、数千甚至数万个表的整个表空间。

保护静止数据：Oracle 备份加密如果您决定在数据库备份中使用列加密，那么窃取数据库文件备份通常比窃取生产数据库容易得多。因此，Oracle Advanced Security 中的第三组特性与备份加密有关。

30

如果您只是对数据库文件进行备份，那么在备份副本中，只有在生产数据库文件中进行加密的那些列是经过加密的。但是，结合使用 Oracle Recovery Manager (Oracle RMAN) 和 Oracle Advanced Security 可以加密整个备份集（即所有数据）。

Database Vault

挑战：如果攻击者不使用第三方工具而是使用 Oracle 工具来绕过 SAP 应用，那么数据加密就不起作用。如果攻击者是特权数据库用户（如数据库管理员），而且当数据库管理工作外包或者数据存储在云端时，情况会变得非常危险。价值主张：Oracle Database Vault 用更灵活、功能更强大的新策略取代了传统的数据库权限管理策略。它远远超越了传统的用户 -权限或用户 -角

特权数据库用户（如，数据库管理员）可使用 DBA 工具直接连接到数据库，借此绕过 SAP的安全检查（见图 10）。加密无法消除此类威胁。例如，如果某用户能够使用具有足够权限的帐户成功连接到数据库，然后发送一个查询请求，则 Oracle 数据库会毫无保留地为该用户提供结果集。如果请求的数据经过加密，Oracle 还会进行解密。因为从 Oracle 数据库的角度来看，该用户发送的请求似乎是完全有效的请求。

这种情况有可能发生，因为按照惯例，如果您被显式授予了足够数量的系统权限，那么您也就隐式获得了所有表的对象权限。数十年来，人们一直觉得这种情况是可以接受的。但是最近，各公司开始思

图 9：Oracle Advanced Security —加密传输中的数据或静止数据

色关联。Oracle Database Vault 允许公司实施和执行职责分离或“四眼双人监控”等原则。认证/支持：Oracle Database Vault 通过了所有 SAP NetWeaver 应用的认证。由 SAP 为实施提供支持。版本：Oracle Database 11g、Oracle Database 12c实施：用 Oracle Database Vault Administrator (DVA) 管理 Database Vault。

考以下问题：对于负责管理数据库结构的数据库管理员，真的有必要让他们在默认情况下能够读取（甚至更改）数据库中的所有数据吗？

Oracle Database Vault

要解决这个问题就需要在数据库中引入新的权限管理策略。该策略应该继续提供系统权限和对象权限，但应该删除隐式授予的对象权限。

这正是 Oracle Database Vault 的用武之地。它以更灵活的新策略取代了传统、稍显呆板的权限管理策略。它消除了所有隐式授权，转而提供一些方法来显式定义访问权限以及定义权限生效的环境。这远远超越了传统的用户-权限或用户-角色关联。

31面向 SAP 客户的 Oracle 数据库选件和管理包

Oracle Database Vault 允许公司实施和执行职责分离或“四眼双人监控”等原则。

面向 SAP 的 Oracle Database Vault Oracle 销售的 Oracle Database Vault 只是一个工具箱。它确实附带有预定义的领域和角色，但这些领域是针对系统表的，角色也是非常通用的（基本的）。这些预定义的组件让 Oracle Database Vault 变得实用，您可以使用它，但这些组件不会保护特定于您的应用的数据。这是因为，Oracle 不知道有关您的应用和数据的任何信息。Oracle 只能为您提供一个工具箱，由您自己确定您的安全需求，然后将这些需求转化为访问控制策略。

这里要弄清楚一个重要的差别。只要客户使用自行开发的应用，就不能指望 Oracle 能做更多工作。但是，如果数千或数万家公司都使用某个标准应用，并且所有这些公司的安全需求至少在某个方面来说是相同的（因为它们是应用设计的结果），则 Oracle 对这些需求进行分析并实施一种基本的安全策略相对而言是十分有意义的。

Real Application Testing (RAT)

挑战：为数据库软件打补丁或升级、修改数据库服务器配置以及实施新的数据库特性/选件可以提高数据库服务器和整体系统的性能、可用性和安全性。尤其是，如果实施需要考虑特定于客户或应用的特征，那么管理员会希望提前了解新特性或配置在生产系统中的工作方式。价值主张：很多测试系统的主要问题是对其应用的负载较小或者与生产系统的实际负载不同，导致新特性或配置在测试系统运行良好，在生产系统却效果不佳。因此， Oracle Real Application

Oracle 确实这样做了，为客户节省了实施繁琐的、特定于应用的安全策略基础工作所需的时间，并避免了这些公司忘记实施某些基础工作。到目前为止，Oracle 提供了一系列的预定义、特定于应用的 Oracle Database Vault 策略，面向 SAP 的 Oracle Database Vault 正是这个系列的一员。

图 10：Oracle Database Vault —特权用户访问控制和分析

Testing 允许客户捕获生产系统的数据库负载，然后在测试系统重放负载。通过这两个步骤，我们就可以在生产系统实施变更之前利用实际负载了解这些变更的实际效果。认证/支持：Oracle Real Application Testing 通过了所有 SAP NetWeaver 应用的认证。由 SAP 为实施提供支持。版本：Oracle Database 11g、Oracle Database 12c实施：这是数据库特有的特性，不需要 SAP 工具支持。有关详细信息，请参见 SAP 说明 1426980。

32

Oracle Real Application Testing 使您能够执行实战测试。它捕获生产数据库负载，然后在生产系统部署更改之前评估系统更改的影响，从而降低更改带来的不稳定风险。Oracle Real Application Testing 包括两个组件： Database Replay 和 SQL Performance Analyzer。

Database Replay

目前的负载测试一般都是测试团队利用工具根据用户在系统上的预期行为来生成合成负载。随后，应用虚拟用户重放这些负载，模拟用户向应用提交请求。尽管该方法应用广泛，但它在测试数据库级别的更改时仍有诸多不足：

• 创建合成负载需要相当长的时间，并需要专业编程技能。

• 由于对用户行为了解不充分，因此在合成测试中往往遗漏很多可能的工作流。

• 使用这些工具几乎无法模拟生产规模的数据库的并发性。

• 使用这些工具模拟用户时需要一个完整的应用体系来支持测试。

利用 Oracle Real Application Testing 中附带的 Database Replay，DBA 和系统管理员可以在测试环境下如实、准确、逼真地重新运行实际生产负载，其中包括联机用户负载和批处理负载。Database Replay可从生产系统中捕获所有数据库负载（包括所有并发性、相关性和时序性），使您能够在测试系统中从实质上重建生产负载（这样的负载重现绝对无法通过脚本实现），对系统更改进行逼真的测试。使用 Database Replay，DBA 和系统管理员可以测试：

• 数据库升级、补丁、参数、模式更改等。 • 配置更改，例如从单实例转换为 RAC、ASM 等。 • 存储、网络、互联更改。 • 操作系统、硬件迁移、补丁、升级、参数更改。

SQL Performance Analyzer

Database Replay 可以实现 Real Application Testing 的一半功能，另一半功能由另外一个工具 SQL Performance Analyzer 来实现。这两个工具的主要区别在于工作范围：Database Replay 适用于捕获和重放数据库中的所有活动，SQL Performance Analyzer 则使您能够捕获特定的 SQL 语句并重放这些语句。后者对于 SQL 调优有显著优势，因为您可以微调某个应用发出的 SQL 语句并评估其影响。

SQL Performance Analyzer (SPA) 可以预测和防止环境更改导致的 SQL 执行性能问题。通过在更改前后顺次运行 SQL 语句，它可以提供环境更改对 SQL 执行计划所产生影响的详细报告和统计信息。

图 11：Real Application Testing (RAT) —捕获和重放实际数据库负载

33面向 SAP 客户的 Oracle 数据库选件和管理包

Enterprise Manager 管理包

挑战：监视和管理整个 IT 基础设施通常极具挑战性。管理员可能会使用大量专为各种特定用途设计的管理工具。价值�