即至农历春节前，Oracle终于完成其在中国最后一站 — 上海站的SPARC M7新产品宣讲。

作为一个坚定的Oracle粉，身居上海的我们自然也受到了会议邀请~。不过，和广大技术同胞不同的是，我们是以媒体人的身份来参加的，因此分支会议上会有些小小的不同:）

主题为《安“芯”防卫，智胜云端》的Oracle大会一如既往的座无虚席，虽然是产品介绍会，但是除了媒体之外，还是有非常多的IT技术人员到场听讲的。

也许是由于开场的时间稍有延后的关系，在Oracle中国区事业部的詹飞浪总经理做了简短的开幕致辞后，潘榆奇总监便开始了对Oracle SPARC M7的主题演讲。

此次Oracle力推的SPARC M7产品确实是一款Oracle的实力之作，诚如潘榆奇先生所言，Oracle的发展思路明确，”速度” -> “安全” -> “云”。

从软件到硬件的整合能力，到对一体机的长期投入研发，Oracle在其技术领域中一直处于标杆地位。现在Oracle更需要乘着云的东风，希望在硬件领域有更多突破。

[Read more…]

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

尝鲜Oracle 12c

就在本书写作期间的2013年秋天，Oracle公司终于正式推出了令广大IT人士翘首以盼的12c数据库，c就是云（Cloud），意味着Oracle将12c定位为数据库云平台整体解决方案。

12c到底有哪些新特性和新技术？特别是在云计算方面有什么特色技术？在12c尚未正式推出的2013年春天，本人参加了一次公司内部的12c技术培训，发现12c林林总总的新特性真不少，但培训教材的前几章则在全面介绍两大技术领域：CDB/PDB架构和信息生命周期管理，可见这两大技术领域在数据库云平台和云计算方面的重要性。于是，本章也只涉足这两大技术领域，以及相关的实施案例。

新特性培训课的趣事

本人从2001年加入Oracle公司算起到2013年的12年间，Oracle数据库版本从9i一直发展到了12c，个人知识和能力也是伴随着Oracle技术的不断发展而共同进步。以下就是Oracle公司描述的最新几个版本的技术创新示意图：

在这12年间，本人也有幸参加了各个版本的新特性培训。记得在2001年参加9i新特性培训时，还是在国贸二座的Oracle大学一间大教室，公司内外听课者有数十人之众。而在2004年参加10g新特性培训时，人数就只有10余人了。再到2007年在上海Oracle大学参加11g新特性培训时,则只有区区3个人，其中包括本人在内的2位是Oracle内部员工，真正的客户就1位。而在2013年参加12c新特性培训时，也只有可怜的4个人，而且可能是因为12c尚未正式发布的缘故，4个人全部都是Oracle公司内部员工。

记得2007年在参加11g培训时，当老师按照教材一上来就介绍有关ASM新特性时，那位唯一的客户一听就傻眼了：“老师，什么叫ASM啊？”。原来他们的系统还运行在9i平台，尚未接触过10g，更未听说过什么ASM，呵呵。感慨：以后听这种新特性的课程，一定不能跨版本。IT技术发展太快了。

在本次连续5天的12c培训过程中，因工作等各种原因，包括本人在内的4位听课者或多或少缺席了一些课程。到培训的最后一天，其他同学因故都缺席了,老师就只对我一个人滔滔不绝了，但老师依然是非常职业地抑扬顿挫，搞得我都不好意思了：“老师，就我一个人了，您不用那么大声音了。”呵呵。但我一直坚持到最后做完课程的所有练习。

IT技术的确发展太快，搞得客户都有点跟不上这种高速发展的步伐了。但作为原厂技术服务人员，紧跟IT技术发展潮流，并及时抢占技术制高点其实是我们的基本职业诉求。

虽然说总体感觉12c相比以前版本而言，并未发生很多革命性的根本变化。例如像10g一样，新增加ASM、clusterware等架构性技术。但5天的培训课程，感觉12c还是推出了大量新特性。限于篇幅，也根据自身理解，将只介绍几个12c最重要的新特性，包括在架构方面的新变化和新技术：Container DB和Pluggable DB，以及在信息生命周期方面的新技术。

12c架构方面最大变化

Oracle传统架构

Oracle数据库主版本从8i开始均带有一个字母：8i、9i、10g、11g、12c。根据Oracle公司官方解释：i代表Internet、Intellegence等，g则代表Grid Computing（网格计算），而c则是Cloud Computing（云计算）了。

Oracle宣称12c版本为云计算平台，并非赶时髦，而的确是在架构层面大动干戈了！传统的Oracle架构中实例和数据库关系只有1对1关系和N对1关系。下图就是实例和数据库1对1关系的单机架构：

同时，Oracle还支持多个实例共享一个数据库的N对1关系，即如下图所示的RAC集群架构：

在12c之前的传统Oracle架构中，是不支持一个实例管理多套数据库的1对N关系的架构，即如下图所示：

但是为适应云计算发展的需要，Oracle在12c中也支持这种架构了，也就是后面要详细描述的Container DB和Pluggable DB概念了。这就是本人觉得12c在架构方面最大的改变和新特性了。

Container DB和Pluggable DB基本概念

以下就是Container DB和Pluggable DB概念示意图：

首先，在这种架构下只有一个数据库实例，即所有数据库共享一组后台进程和一组内存，包括SGA、PGA等。

其次，该实例可以管理多个数据库，即多个Container数据库。上图表示一个名为root 的Container数据库，简称CDB。而且包括3个类型为Pluggable的Container数据库，简称PDB。其中一个为Seed PDB（种子PDB），另外两个为SALES PDB和HR PDB应用数据库，也就是说CBD和所有PDB是父子关系，并且CBD和PDB数据库在一个实例下运行和管理。

再者，在CDB层面像传统数据库结构一样，包括SYSTEM、SYSAUX、UNDO、TEMP等系统表空间和应用表空间，以及控制文件和日志文件等。但在PDB层面则只有专属PDB的SYSTEM、SYSAUX系统表空间和应用表空间，而没有UNDO表空间、控制文件和日志文件。也就是说CDB的UNDO表空间、控制文件和日志文件是整个CDB所共享的。

CBD的临时表空间和临时表空间组可以为各PDB所共享，但是每个PDB也可拥有自己独立的临时表空间和临时表空间组。

最后，CDB的归档模式决定了所有PDB的归档模式。即所有CDB和PDB同为归档或非归档模式。

Container DB和Pluggable DB架构的好处

Oracle公司为什么在12c中推出这种实例和数据库为1对N关系的CDB和PDB架构？这就是为了满足云计算，特别是数据库整合的需要而应运而生的。我们还是先从现有IT 系统架构现状分析开始：

首先，出于业务、管理、安全等多方因素考虑，以及技术架构本身限制等，大多数企业存在大量部门级的小系统，这些典型的竖井式、孤岛式系统其实在平时资源利用率非常低。本人曾在国内某大型银行参与其全国大集中项目，发现大部分小系统都处于这种状态，如下图所示：

可见，除了晚上几个后台作业对资源有一定开销之外，大部分时间的资源利用率非常之低。

其次，这些系统其实应用并不复杂，但同样需要DBA去进行运行监控、性能分析、版本和补丁管理、备份恢复等各种管理工作。

再者，在Oracle现有技术架构层面，由于每个应用系统都需要自己的实例和数据库，尽管可以将多套系统部署在同一个物理服务器，但同样将导致过多的Oracle后台进程和内存的开销，以及数据字典数据的重复。

最后，就像上章所言，虽然基于11g的云计算可以在Schema级进行数据库的整合，但毕竟带来数据隔离性下降等客户顾虑的安全性问题。

如何能有效解决这一问题，特别是用更少的资源去管理更多的数据库，充分发挥硬件资源利用率、降低管理成本，同时又保障一定的数据隔离性呢？这就是Oracle 12c推出CDB和PDB的重要意图。具体而言，这种新型架构的好处如下：

• 有效提高资源利用率

首先，在这种架构下，更多应用数据库被整合到一个硬件环境，资源利用率得到有效提高。同时12c在CDB和PDB的不同层面可以进行资源管理的设计，这样也将有效解决不同数据库系统高峰期间的资源竞争问题。

• 有效降低资源开销

其次，由于一个数据库实例管理多套数据库，这样只有一套后台进程和内存开销，数据字典的冗余信息也降低，有效降低了整体资源开销。

• 管理成本下降

由于只要管理一个数据库实例，系统的日常监控、性能分析、版本和补丁管理、备份恢复等各种管理工作都简化，而且这种架构下通过克隆、复制等多种方式，PDB可快速、简洁地进行部署，同时对应用透明。因此，总体管理成本将下降。

• 有效的安全控制

在这种架构下，既可在CDB层面进行集中统一的安全控制管理，由于各个应用系统还是相对独立的PDB，又可在PDB层面进行安全控制管理，确保了一定的数据隔离性和职责分离性。

• 支持Oracle其它技术和架构

CDB/PDB架构支持RAC架构。在 RAC架构中，CDB作为一个整体而部署。这种架构也支持Data Guard架构，但也只能在CDB而不能在PDB级别进行部署和管理。

OEM也支持CDB和PDB的管理。在 OEM中，管理员既可直接通过身份认证连接到CDB进行整个CDB管理，也可连接到指定PDB，只对该PDB进行管理。

资源管理器也增强了对CDB和PDB的资源管理。例如，可根据各PDB的不同资源需求，在一个CDB内部的各PDB之间进行合理的资源分配。

CDB和PDB的创建、启动和关闭

管理CDB和PDB的方式

Oracle 12c中提供了管理CDB和PDB的多种访问方式和工具，如下所示：

可见，创建 CDB和PBD就可以通过SQL*PLUS命令行，DBCA、EM、SQL Devloper等图形化工具等进行。本书限于篇幅，将主要介绍SQL*PLUS命令行进行 CDB、PDB创建和日常管理的基本操作。

创建CDB

创建CDB，主要分为如下四个步骤：

• 配置ora初始化文件

与创建正常数据库一样，首先需要配置init.ora初始化文件，包括设置ORACLE_SID、CONTROL_FILES、DB_NAME等参数。但欲创建CDB数据库，需要设置新的初始化参数ENABLE_PLUGGABLE_DATABASE = TRUE。

• 启动数据库实例

SQL> CONNECT / AS SYSDBA

SQL> STARTUP NOMOUNT

• 创建CDB数据库

SQL> CREATE DATABASE cdb1 
 2 USER SYS IDENTIFIED BY p1 USER SYSTEM IDENTIFIED BY p2
 3 LOGFILE GROUP 1 ('/u01/app/oradata/CDB1/redo1a.log',
 4 '/u02/app/oradata/CDB1/redo1b.log') SIZE 100M,
 5 GROUP 2 ('/u01/app/oradata/CDB1/redo2a.log',
 6 '/u02/app/oradata/CDB1/redo2b.log') SIZE 100M 
 7 CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 
 8 EXTENT MANAGEMENT LOCAL DATAFILE 
 9 '/u01/app/oradata/CDB1/system01.dbf' SIZE 325M 
 10 SYSAUX DATAFILE '/u01/app/oradata/CDB1/sysaux01.dbf' SIZE 325M 
 11 DEFAULT TEMPORARY TABLESPACE tempts1 
 12 TEMPFILE '/u01/app/oradata/CDB1/temp01.dbf' SIZE 20M 
 13 UNDO TABLESPACE undotbs 
 14 DATAFILE '/u01/app/oradata/CDB1/undotbs01.dbf' SIZE 200M
 15 ENABLE PLUGGABLE DATABASE 
 16 SEED FILE_NAME_CONVERT =
 17 ('/u01/app/oradata/CDB1',
 18 '/u01/app/oradata/CDB1/seed');

可见，与创建正常数据库语句类似，该语句在创建数据库过程中创建了一个SYS用户，并创建了两组、每组两个成员的联机日志文件，并且指定了数据库字符集为AL32UTF8，以及国家字符集为AL16UTF16，同时还创建了SYSTEM、SYSAUX、TEMPTS1、UNDO等系统级表空间。

但与传统创建数据库语句不同的是，ENABLE PLUGGABLE DATABASE短语表示创建的是CDB数据库。另外，SEED   FILE_NAME_CONVERT =       (‘/u01/app/oradata/CDB1’, ‘/u01/app/oradata/CDB1/seed’)表示该语句还将创建一个SEED PDB，而SEED PDB的数据文件将通过复制root CDB的文件而产生。

当然，上述语句执行前必须先创建好’/u01/app/oradata/CDB1’和 ‘/u01/app/oradata/CDB1/seed’目录，并确保有足够的存储空间。

• 创建CDB数据库之后的操作

创建CDB数据库之后，主要需要创建相关数据字典：

SQL> CONNECT / AS SYSDBA
SQL> alter session set "_oracle_script"=true;
SQL> alter pluggable database pdb$seed close;
SQL> alter pluggable database pdb$seed open;
SQL> @?/rdbms/admin/catalog.sql;
SQL> @?/rdbms/admin/catblock.sql;
SQL> @?/rdbms/admin/catproc.sql;
SQL> @?/rdbms/admin/catoctk.sql;
SQL> @?/rdbms/admin/owminst.plb;
SQL> @?/sqlplus/admin/pupbld.sql;

• 创建CDB数据库之后的结果

在创建CDB数据库之后，Oracle将创建root Container和Seed PDB两个数据库，并分别创建CDB和PDB两个Service。两个数据库也将分别创建SYS和 SYSTEM两个公用用户，并授予一些公用的访问权限和预定义角色，同时分别创建SYSTEM和SYSAUX表空间。

在设置环境变量ORACLE_SID=CDB之后，管理员通过“connect / as sysdba”将连接到CDB数据库，而欲连接到指定PDB，则通过“CONNECT username/password@pdb_net_service_name”进行连接。

创建PDB

Oracle 12c可以通过如下四种方式创建PDB，以下主要通过SQL*PLUS命令行方式，分别介绍这四种方式：

1. 第一种：通过seed PDB进行复制

该方式非常简洁，具体操作先以SYS用户登录到CDB，然后执行通过seed PDB进行复制的命令：

SQL> CONNECT / AS SYSDBA;
SQL> CREATE PLUGGABLE DATABASE pdb1 
 2 ADMIN USER admin1 IDENTIFIED BY p1 ROLES=(CONNECT)
 3 FILE_NAME_CONVERT = ('PDB$SEEDdir', 'PDB1dir');

上述命令将seed PDB数据库文件目录复制为pdb1的数据文件。

通过如下命令，可验证pdb1数据库是否成功创建：

SQL> CONNECT / AS SYSDBA
SQL> SELECT * FROM cdb_pdbs;
SQL> SELECT * FROM cdb_tablespaces;
SQL> SELECT * FROM cdb_data_files;
SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN;
SQL> CONNECT sys@pdb1 AS SYSDBA
SQL> CONNECT admin1@pdb1

1. 第二种：将一个传统非CDB数据库以PDB形式装载（Plug）到一个CDB

Oracle提供了三种方式，可将一个传统非CDB数据库以PDB形式装载（Plug）到一个CDB。第一种是通过表空间传输技术（TTS）、传输数据库技术（TDB）或者全库Export/Import技术。第二种是通过DBMS_PDB包，产生一个描述非CDB数据库的XML文件，再装载到CDB中。第三种则是通过 GoldenGate数据复制技术。

本书仅介绍第二种DBMS_PDB包方式，也是最简单的一种方式，但该方式必须假设非 CDB数据库为12.1版本以上。

• 连接到非 CDB数据库ORCL，并且将该数据库设置为READ ONLY状态。
• 执行如下脚本：

SQL> EXEC DBMS_PDB.DESCRIBE (‘/tmp/ORCL.xml’);

• 以SYS用户连接到目标CDB，并将ORCL装载到CBD中：

SQL> conn / as sysdba;

SQL> CREATE PLUGGABLE DATABASE  PDB2 USING ‘/tmp/ORC.xml’;

• 执行如下脚本：

SQL> CONNECT sys@PDB2 AS SYSDBA;

SQL>@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb

该脚本删除一些PDB SYSTEM表空间中一些不必要的信息。在第一次打开PDB2之前，必须运行该脚本。

• 打开并验证 PDB2

SQL> CONNECT / AS SYSDBA
SQL> SELECT * FROM cdb_pdbs;
SQL> SELECT * FROM cdb_tablespaces;
SQL> SELECT * FROM cdb_data_files;
SQL> ALTER PLUGGABLE DATABASE pdb2 OPEN;
SQL> CONNECT sys@pdb2 AS SYSDBA

1. 第三种：在一个CBD中，通过克隆（clone）现有一个PDB，创建一个新PDB

• 假设不使用OMF技术，设置初始化参数PDB_FILE_NAME_CONVERT= ‘PDB1dir’, ‘PDB3dir’
• 以SYS用户连接到CDB，并将 PDB1设置为READ ONLY状态：

SQL> conn / as sysdba;

SQL> ALTER PLUGGABLE DATABASE pdb1 CLOSE;

SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY;

• 通过克隆（clone）PDB1，创建PDB3：

SQL> CREATE PLUGGABLE DATABASE pdb3 FROM pdb1 FILE_NAME_CONVERT=(’pdb1dir’,’ pdb3dir’);

• 打开并验证 PDB3

SQL> CONNECT / AS SYSDBA
SQL> SELECT * FROM cdb_pdbs;
SQL> SELECT * FROM cdb_tablespaces;
SQL> SELECT * FROM cdb_data_files;
SQL> ALTER PLUGGABLE DATABASE pdb3 OPEN;
SQL> CONNECT sys@pdb3 AS SYSDBA

1. 第四种：从一个CDB先卸载（Unplug）一个 PDB，再装载（Plug）到另一个CDB

该方式的示意图如下：

具体步骤如下：

• 以SYS用户连接到CDB1，并将 PDB1设置为READ ONLY状态：

SQL> conn / as sysdba;

SQL> ALTER PLUGGABLE DATABASE pdb1 CLOSE;

SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY;

• 将PDB1卸载（unplug）为一个XML文件：

• 将PDB1卸载（unplug）为一个XML文件：

SQL> ALTER PLUGGABLE DATABASE  pdb1 UNPLUG INTO ‘xmlfile1.xml’;

• 以SYS用户连接到CDB2，并检查PDB1与CDB2是否兼容：

SQL> conn / as sysdba;
SET SERVEROUTPUT ON DECLARE compat BOOLEAN; 
BEGIN compat := DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file 
 => '/disk1/usr/salespdb.xml', pdb_name => 'pdb1'); DBMS_OUTPUT.PUT_LINE('Is PDB compatible? = ' || compat); 
END;

• 如果兼容，则通过如下命令将PDB1加载到CBD2：

SQL> CREATE PLUGGABLE DATABASE pdb1 USING ‘xmlfile1.xml’ NOCOPY;

• 在CDB2中打开并验证 PDB1

SQL> CONNECT / AS SYSDBA
SQL> SELECT * FROM cdb_pdbs;
SQL> SELECT * FROM cdb_tablespaces;
SQL> SELECT * FROM cdb_data_files;
SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN;
SQL> CONNECT sys@pdb1 AS SYSDBA

删除PDB

通过如下命令可删除指定的PDB：

SQL> CONNECT / AS SYSDBA
SQL> ALTER PLUGGABLE DATABASE pdb1 CLOSE; 
SQL> DROP PLUGGABLE DATABASE pdb1 [INCLUDING DATAFILES];

该命令执行后， Oracle将自动将pdb1被删除信息记录在 CDB的控制文件之中。当指定INCLUDING DATAFILES选项时，pdb1数据库的所有数据文件将被删除掉。当未指定INCLUDING DATAFILES选项时，pdb1数据库的所有数据文件将保留，这种情况适合于从一个CDB先卸载（Unplug）一个 PDB，再装载（Plug）到另一个CDB的需要。

如何将12c版本之前的数据库迁移到12c CDB?

总体而言，可通过如下两种方式，实现将12c版本之前的数据库迁移到12c CDB：

• 第一种：升级 + Plug

该方式示意图如下：

即首先将12c版本之前的数据库升级到12c，成为12c的非CBD数据库。其次，通过DBMS_PDB包，以XML方式，将非 CDB数据库加载（Plug）到CBD中。

• 第二种：创建PDB + 导入数据

该方式示意图如下：

即首先在CDB1中创建一个PDB1，然后通过Data Pump技术进行数据导出/导入，或者通过GoldenGate数据复制技术实现数据迁移。

CDB和PDB数据库的启动和关闭

• 启动CDB实例和打开CDB数据库

以下是CDB和PDB数据库的启动各阶段示意图：

可见，CDB和PDB数据库的启动与传统数据库既有相似之处，也有一定的差异，下面详细介绍之。

通过如下命令，CDB数据库可启动为nomount状态：

SQL> CONNECT sys@CDB1 AS SYSDBA

SQL> STARTUP NOMOUNT;

此时，CDB数据库实例被启动。

通过如下命令，CDB数据库可启动为mount状态：

SQL> CONNECT sys@CDB1 AS SYSDBA

SQL> STARTUP MOUNT;

Or

SQL> CONNECT sys@CDB1 AS SYSDBA

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE CDB1 MOUNT;

此时，不仅CDB数据库实例被启动，而且控制文件被打开，Root CDB和所有PDB处于Mount状态。

通过如下命令，CDB数据库可处于open状态：

SQL> CONNECT sys@CDB1 AS SYSDBA
SQL> STARTUP;
Or
SQL> CONNECT sys@CDB1 AS SYSDBA
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE CDB1 MOUNT;
SQL> ALTER DATABASE CDB1 OPEN;
Or
SQL> CONNECT sys@CDB1 AS SYSDBA
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CDB1 OPEN;

此时，不仅CDB数据库实例被启动，而且控制文件、日志文件、数据文件被打开，Root CDB将处于Open状态。但Seed PDB将处于READ ONLY状态，而其它PDB将处于Mount状态。通过如下命令可确认之：

SQL> SELECT name,open_mode FROM v$pdbs;
NAME OPEN_MODE
---------------- -------------
PDB$SEED READ ONLY
PDB1 MOUNTED
PDB2 MOUNTED

• 打开PDB数据库

通过如下命令，可手工打开指定或全部PDB数据库：

SQL> CONNECT sys@CDB1 AS SYSDBA

SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN;

Or

SQL> ALTER PLUGGABLE DATABASE ALL OPEN;

如何实现打开CDB的同时，就自动打开所有或部分PDB？如下触发器将在打开CDB的同时就打开所有PDB：

SQL> CREATE TRIGGER Open_All_PDBs 
 after startup on database
begin
 execute immediate 'alter pluggable database all open';
end Open_All_PDBs;
/

• 关闭PDB数据库

以下是PDB数据库的启动各阶段示意图：

通过如下命令，可根据不同需要关闭PDB数据库：

SQL> CONNECT / AS SYSDBA

SQL> ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE;

SQL> ALTER PLUGGABLE DATABASE ALL EXCEPT pdb1 CLOSE;

SQL> ALTER PLUGGABLE DATABASE ALL CLOSE;

其中第2条命令关闭pdb1数据库；第3条命令关闭除pdb1之外的所有PDB数据库；第4条命令关闭所有PDB数据库。

也可通过如下命令，连接到指定PDB，并进行关闭该PDB数据库的操作：

SQL> CONNECT sys@pdb1 AS SYSDBA
SQL> ALTER PLUGGABLE DATABASE CLOSE;
Or
SQL> SHUTDOWN IMMEDIATE;

与传统数据库关闭不同的是，PDB数据库关闭只是将PDB的数据文件关闭了，但CDB的整个实例还没有关闭。因此PDB数据库关闭之后，将显示下述正常的错误信息：

SQL> SHUTDOWN IMMEDIATE;

ORA-65020: Pluggable database already closed

• 关闭CDB数据库

通过如下命令，可关闭整个CDB数据库和CBD实例：

SQL> CONNECT sys@CDB1 AS SYSDBA

SQL> SHUTDOWN IMMEDIATE

此时，所有PDB将被关闭，接下来CDB被关闭，最后整个CDB实例将被关闭。

CDB和PDB的日常管理

CDB和PDB中表空间的管理

与传统数据库一样，表空间的合理设计将有效提高数据的可管理性、可操作性和安全性。CDB和PDB概念的引入，使得表空间管理更有层次性，更能满足云计算环境下数据整合的需要。

以下就是在root CDB下创建表空间的范例：

SQL> CONNECT system@cdb1
SQL> CREATE TABLESPACE tbs_CDB_users DATAFILE
 2 '/u1/app/oracle/oradata/cdb/cdb_users01.dbf'
 3 SIZE 100M;

以下就是在PDB下创建表空间的范例：

SQL> CONNECT system@cdb1
SQL> CREATE TABLESPACE tbs_CDB_users DATAFILE
 2 '/u1/app/oracle/oradata/cdb/cdb_users01.dbf'
 3 SIZE 100M;

以下就是在PDB下创建表空间的范例：

SQL> CONNECT system@PDB1
SQL> CREATE TABLESPACE tbs_PDB1_users DATAFILE
 2 '/u1/app/oracle/oradata/cdb/pdb1/users01.dbf'
 3 SIZE 100M;

以下就是在root CDB下分配缺省表空间的范例：

SQL> CONNECT system@cdb1

SQL> ALTER DATABASE DEFAULT TABLESPACE tbs_CDB_users;

以下就是在PDB下分配缺省表空间的范例：

SQL> CONNECT pdb1_admin@pdbhr

SQL> ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE pdbhr_users;

以下就是在root CDB下分配缺省临时表空间的范例：

SQL> CONNECT system@cdb1

SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_root;

以下就是在PDB下分配缺省临时表空间的范例：

SQL> CONNECT pdb1_admin@pdbhr

SQL> ALTER PLUGGABLE DATABASE DEFAULT TEMPORARY TABLESPACE local_temp;

Or

SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE local_temp;

可见，CDB和PDB中表空间管理语句与传统语句其实一样，区别在于连接到CDB和PDB不同数据库而已，或者在 PDB级增加PLUGGABLE短语。

CDB和PDB的数据库备份

再次重复Oracle公司的一句名言：无论如何强调数据库的备份都不过分。在通过CDB和PDB架构下实现数据库整合之后，数据库的备份和恢复更加重要。为满足数据库整合备份恢复的更复杂需求，Oracle 12c提供了在CDB、PDB不同层面进行更灵活的备份和恢复技术。

以下就是对所有CDB和PDB进行备份的语句：

$ export ORACLE_SID=cdb1

$ rman TARGET /

RMAN> BACKUP DATABASE;

以下就是对指定PDB进行备份的语句：

RMAN> BACKUP PLUGGABLE DATABASE hr_pdb, sales_pdb;

RMAN> RECOVER PLUGGABLE DATABASE hr_pdb;

以下就是对指定PDB的表空间进行备份的语句：

RMAN> BACKUP TABLESPACE sales_pdb:tbs2;

CDB和PDB的数据库恢复

CDB和PDB的数据库恢复与传统数据库恢复既有相同之处，也有其特殊之处。以下介绍主要事故场景的恢复过程。

• 实例故障

与传统数据库恢复一样，当实例发生故障时，Oracle将在实例重启时，自动进行数据库的恢复，包括利用redo log日志进行向前恢复和利用UNDO信息进行向后恢复。

但不同之处在于，只有CDB可以进行实例恢复，而PDB是共享CDB实例的，因此PDB没有实例恢复一说。

• 临时表空间数据文件故障

无论是CDB或PDB的临时表空间数据文件出现故障，当SQL应用需要使用到临时表空间时，将出现相关错误。例如：

SQL> CONNECT / AS SYSDBA
SQL> select * from DBA_OBJECTS order by 1,2,3,4,5,6,7,8,9,10,11,12,13;
select * from DBA_OBJECTS order by 1,2,3,4,5,6,7,8,9,10,11,12,13
 *
ERROR at line 1:
ORA-01565: error in identifying file '/u01/app/oracle/oradata/CDB1/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory

当启动CDB实例和打开CDB数据库时，Oracle都将自动创建这些出现故障的临时表空间数据文件。如果自动创建失败，则可以通过手工方式创建。例如：

SQL> ALTER TABLESPACE temp ADD TEMPFILE 
 2 '/u01/app/oracle/oradata/CDB1/temp02.dbf' SIZE 20M;
SQL> ALTER TABLESPACE temp DROP TEMPFILE 
 3 '/u01/app/oracle/oradata/CDB1/temp01.dbf’;

• 控制文件故障

如果控制文件损坏，由于控制文件属于CDB，因此整个CDB将出现宕机。恢复控制文件的最快捷方式应该是重新创建之。为此，建议当CDB出现大规模结构型变化时，通过如下命令进行控制文件的导出：

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

当出现控制文件故障时，并通过相关trace文件重新创建控制文件。

否则，需要如下命令进行整个数据库的恢复，将非常消耗时间和资源。

RMAN> CONNECT TARGET / 
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;

• CDB的SYSTEM或UNDO表空间文件故障

与传统数据库恢复一样，当CDB的SYSTEM或UNDO表空间文件出现故障，整个CDB将在Mount状态下进行恢复，也意味着整个CDB和PDB将处于不可用状态。以下是UNDO表空间恢复过程：

RMAN> STARTUP MOUNT;
RMAN> RESTORE TABLESPACE undo1; 
RMAN> RECOVER TABLESPACE undo1;
RMAN> ALTER DATABASE OPEN;
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;

• CDB的SYSAUX表空间文件故障

与传统数据库恢复一样，当CDB的SYSAUX表空间文件出现故障，只需将该表空间设置为OFFLINE状态，并进行恢复，而整个CDB和PDB将处于可用状态。以下是SYSAUX表空间恢复过程：

RMAN> ALTER TABLESPACE sysaux OFFLINE IMMEDIATE; 
RMAN> RESTORE TABLESPACE sysaux; 
RMAN> RECOVER TABLESPACE sysaux;
RMAN> ALTER TABLESPACE sysaux ONLINE;

• PDB的SYSTEM表空间文件故障

当PDB的SYSTEM表空间文件出现故障，整个CDB将关闭并需要进行相关数据文件的恢复操作，在此期间，整个CDB和所有PDB将不可访问。以下就是指定PDB的SYSTEM表空间恢复过程：

RMAN> CONNECT TARGET / 
RMAN> STARTUP MOUNT;
RMAN> RESTORE PLUGGABLE DATABASE sales_pdb; 
RMAN> RECOVER PLUGGABLE DATABASE sales_pdb;
RMAN> ALTER DATABASE OPEN;
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;

或者：

RMAN> CONNECT TARGET / 
RMAN> STARTUP MOUNT;
RMAN> RESTORE TABLESPACE sales_pdb:system; 
RMAN> RECOVER TABLESPACE sales_pdb:system;
RMAN> ALTER DATABASE OPEN;
RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;

• PDB的普通表空间文件故障

当PDB的普通表空间文件出现故障，只需对相关数据文件进行恢复操作。在此期间，除了该表空间之外，整个CDB和所有PDB都可访问。以下就是PDB的普通表空间恢复过程：

RMAN> CONNECT system@sales_pdb 
RMAN> ALTER TABLESPACE tbs2 OFFLINE IMMEDIATE;
RMAN> CONNECT TARGET / 
RMAN> RESTORE TABLESPACE sales_pdb:tbs2;
RMAN> RECOVER TABLESPACE sales_pdb:tbs2;
RMAN> ALTER TABLESPACE tbs2 ONLINE;

CDB数据库的Flashback Database

Oracle 12c只能在CDB级进行Flashback Database操作。与传统数据库Flashback Database设置一样，CDB的Flashback Database配置过程如下：

/*+ 配置flash recovery area */
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 4G;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/oracle/frec_area';

/*+ 配置retention target参数 */
SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880;

/*+ 启动Flashback Database */
SQL> ALTER DATABASE FLASHBACK ON;

Oracle 12c可在CDB mount状态通过Flashback Database命令，将整个CDB和PDB快速闪回到指定SCN、过去某个时间点或日志序列号。例如：

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> FLASHBACK DATABASE TO SCN 10;
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;

在数据库进行闪回期间，可通过如下命令将CDB和PDB以read only方式打开，并监控数据库闪回情况：

SQL> ALTER DATABASE OPEN READ ONLY;
SQL> ALTER PLUGGABLE DATABASE ALL OPEN READ ONLY;

信息生命周期管理的挑战和12c解决方案

信息生命周期管理的挑战

数据量的日益增长已成为IT系统发展的一个显著特征。如下图所示，数据从采集、存储到数据库中，到广泛、深入地被访问和共享，以及有效的管理，形成了一个完整的信息生命周期。信息生命周期管理（Information Lifecycle Management，简称ILM）实际上包括有效管理数据的一系列策略、过程和工具等，从而满足客户提高访问效率、降低存储开销、满足安全性和合规性要求等综合目标。

Oracle在12c之前已经为满足上述信息生命周期管理提供了大量技术，例如：在提高访问效率方面，Oracle已经提供了分区技术、迁移到高性能的表空间技术，将传统LOB字段迁移到性能更好的SecureFiles技术等。在降低存储开销方面，可采用11g提供的丰富多彩的数据压缩技术（Basic、OLTP、HCC、SecureFiles等），以及SecureFiles的去重技术，迁移到低成本存储表空间，删除过期数据等。在数据安全性管理方面，可采用传统的权限管理、视图设计，虚拟私有数据库（VPD）、基于标签数据库（OLS），采用普通审计和细粒度审计（FGA），以及Database Vault和Audit Vault等安全产品。

但是上述ILM管理中，都还是需要DBA或开发人员手工运用上述技术，并且进行大量针对ILM 的应用开发工作。在数据量、访问量日益增长的今天，这种手工方式很难满足需求的不断增长。Oracle是否有新的机制能自动分析数据访问情况，从而自动进行相关的ILM管理呢？例如自动将已经不访问或极少访问的数据进行压缩，或者迁移到低性能、廉价的存储上去呢？答案是有！这就是本章后面即将展开的Oracle 12c在ILM管理方面的新技术：Heap Mat、ADO、In-Database Archiving、Temporal Validity… …

Heat Map和ADO概述

所谓Heat Map，就是Oracle 12c提供的一种自动跟踪、分析和记录数据访问和数据变更情况的新技术，包括在Segment级别对数据访问和在数据块和Segment级别对数据访问变更情况的跟踪、分析，并将这些分析统计数据存储在位于SYSAUX表空间的相关系统数据字典表中。

为此，12c新增加了HEAP_MAP初始化参数。为启动Heat Map特性，可将HEAP_MAP初始化参数设置为ON，该参数缺省值为OFF，并且是动态参数。

SQL> ALTER SYSTEM SET heat_map = ON;

如果启动了Heat Map功能，Oracle将自动对除SYSTEM和SYSAUX之外所有数据对象的DML和访问操作进行跟踪、分析和保存。

所谓ADO，即Automatic Data Optimization(自动数据优化)技术，是指12c基于Heat Map的统计信息而创建一种策略，Oracle依据这种策略自动进行数据压缩和数据分层处理的新技术。

以下就是Heat Map和ADO技术结合使用的示意图：

即在启动Heat Map技术之后，通过ADO首先可以在表空间、对象组、段、记录等不同级别定义相关的数据管理策略，当Oracle通过分析Heat Map统计信息，发现满足相关条件之后，Oracle接下来自动进行定义的数据管理动作，如：数据压缩、迁移数据到其它层级存储，或者二者兼有之。例如，当某个分区数据3天以上没有发生变更时，Oracle可自动对该分区数据进行压缩，免去了手工进行数据压缩的工作量。

Heat Map和ADO详细技术

Heat Map统计信息的查询

在启动Heat Map技术之后，可通过如下多种视图查询Heat Map统计信息：

• Segment级Heat Map统计信息

通过如下DBA_HEAT_MAP_SEG_HISTOGRAM、DBA_HEAT_MAP_SEGMENT等视图，可查询Segment级Heat Map统计信息。例如：

SQL> SELECT object_name, subobject_name, track_time,
 2 segment_write WRI, full_scan FTS, lookup_scan LKP 
 3 FROM DBA_HEAT_MAP_SEG_HISTOGRAM; 
OBJECT_NAME SUBOBJECT_NAME TRACK_TIME WRI FTS LKP 
-------------- -------------- ---------- --- --- ---
INTERVAL_SALES P1 02-JAN-12 YES YES NO
INTERVAL_SALES P2 28-MAR-12 NO YES NO
INTERVAL_SALES P3 28-MAR-12 NO NO YES
I_EMPNO 07-dec-12 YES NO YES 

其中：

• TRACK_TIME：该segment被访问时的系统时间。
• SEGMENT_WRITE：该segment是否有写操作。
• FULL_SCAN：该segment是否有全表扫描操作。
• LOOKUP_SCAN：该segment是否有按索引访问操作。
• DBA_HEAT_MAP_SEGMENT视图包括了Segment最新访问情况。

例如：

SQL> SELECT object_name,
 2 segment_write_time WRITE_T, segment_read_time READ_T, 
 3 full_scan FTS_T, lookup_scan LKP_T
 4 FROM DBA_HEAT_MAP_SEGMENT; 
OBJECT_NAME WRITE_T READ_T FTS_T LKP_T
----------- --------- --------- --------- ---------
EMP 07-dec-12
T1 07-dec-12 08-dec-12
EMPLOYEE 07-dec-12 08-dec-12 08-dec-12
I_EMPNO 07-dec-12 08-dec-12

其中：

• SEGMENT_WRITE_TIME：该Segment最新写操作时间。
• SEGMENT_READ_TIME：该Segment最新读操作时间。
• FULL_SCAN字：该Segment最新全表扫描操作时间。
• LOOKUP_SCAN：该Segment最新按索引访问操作时间。

Oracle 12c后台NMON进程定期将保存在SYS.HEAT_MAP_STAT$ 、V$HEAT_MAP_SEGMENT等表和视图的Heat Map统计信息刷新到上述视图中。

• Block级Heat Map统计信息

通过DBMS_HEAT_MAP.BLOCK_HEAT_MAP表函数，可查询指定Segment的Block级Heat Map统计信息，例如：

SQL> SELECT segment_name, tablespace_name, block_id, writetime 
 2 FROM table(dbms_heat_map.block_heat_map 
 3 ('SCOTT','EMPLOYEE',NULL,8,'ASC'));
SEGMENT_ TABLESPACE_NAME BLOCK_ID WRITETIME
-------- ---------------- ---------- ---------
EMPLOYEE LOW_COST_STORE 196 12-DEC-12
EMPLOYEE LOW_COST_STORE 197 12-DEC-12
EMPLOYEE LOW_COST_STORE 198 12-DEC-12 

其中输入参数如下：

• Owner：Segment所属用户
• Segment_name：Segment名称，例如普通非分区表名。如果是分区表，则该参数为空。
• Partition_name：分区名称。如果是普通非分区表，则该参数为空。
• Sort_columnid：字段排序号。取值范围：1到9。
• Sort_order：排序方式。取值：ASC、DESC

其中输出参数如下：

• Owner：Segment所属用户
• Segment_name：Segment名称，例如普通非分区表名。如果是分区表，则该参数为空。
• Partition_name：分区名称。如果是普通非分区表，则该参数为空。
• Tablespace_name：包含该Segment的表空间名称。
• File_id：包含该Segment的绝对文件名称。
• Relative_fno：包含该Segment的相对文件名称。
• Block_id： Block_id号。
• Writetime：Block的最新写操作时间。
• Extent级Heat Map统计信息

通过DBMS_HEAT_MAP.EXTENT_HEAT_MAP表函数，可查询出指定Segment的Extent级Heat Map统计信息，并且包括最小、最大修改时间。例如：

SQL> SELECT segment_name, block_id, blocks, max_writetime 
 2 FROM table(dbms_heat_map.extent_heat_map 
 3 ('SCOTT','EMPLOYEE'));
SEGMENT_ BLOCK_ID BLOCKS MAX_WRITETIME
-------- ---------- ---------- ------------------
EMPLOYEE 136 8 12-DEC-12 12:58:46
EMPLOYEE 144 8 12-DEC-12 12:58:46
EMPLOYEE 256 128 12-DEC-12 12:58:47
EMPLOYEE 384 128 12-DEC-12 12:58:47

其中输入参数如下：

• Owner：Segment所属用户
• Segment_name：Segment名称，例如普通非分区表名。如果是分区表，则该参数为空。
• Partition_name：分区名称。如果是普通非分区表，则该参数为空。

其中输出参数如下：

• Owner：Segment所属用户
• Segment_name：Segment名称，例如普通非分区表名。如果是分区表，则该参数为空。
• Partition_name：分区名称。如果是普通非分区表，则该参数为空。
• Tablespace_name：包含该Segment的表空间名称。
• File_id：包含该Segment的绝对文件名称。
• Relative_fno：包含该Segment的相对文件名称。
• Block_id： Block_id号。
• Blocks：该extent的Block数量。
• Min_writetime：Block最小修改时间。
• Max_writetime：Block最大修改时间。
• Avg_writetime：Block平均修改时间。

压缩策略的定义

在启动Heat Map技术之后，ADO流程的第二步就是根据不同条件，定义压缩和数据迁移策略。本节我们主要通过例子来介绍各级别压缩策略的定义和相关概念。

• 表空间级压缩

SQL> ALTER TABLESPACE tbs1 DEFAULT ILM ADD POLICY 
 2 ROW STORE COMPRESS ADVANCED 
 3 SEGMENT AFTER 30 DAYS OF LOW ACCESS;

该语句表示当30天后，如果tbs1表空间数据处于低访问（LOW ACCESS）状态，则tbs1表空间将自动按ROW STORE COMPRESS ADVANCED算法进行压缩。

所谓LOW ACCESS状态，是指Oracle自动根据ROWID访问量（按索引访问）、全表扫描量、DML操作量等统计值进行加权计算，而得到的一个综合指标。该指标与不同压缩算法相关，例如若采用ARCHIVE HIGH压缩算法，则ROWID访问量（按索引访问）和DML操作量的权重较高，而全表扫描量权重较低。至于该指标的详细计算公式，Oracle并没有公开，我们也就不深究了。

另外，所谓ROW STORE COMPRESS ADVANCED算法，也称之为Advanced Compression Option（简称ACO），实际上就是11g的OLTP压缩算法。

• Group级压缩

SQL> ALTER TABLE tab1 ILM ADD POLICY 
 2 ROW STORE COMPRESS ADVANCED 
 3 GROUP AFTER 90 DAYS OF NO MODIFICATION;

该语句表示当90天后，如果tab1表数据没有修改（NO MODIFICATION）时，则tab1表数据将自动按ROW STORE COMPRESS ADVANCED算法进行压缩。

另外，该语句指定了GROUP短语，表示该表的SecureFiles LOB字段也将进行相应的压缩。与表的ROW STORE COMPRESS ADVANCED压缩算法相对应的SecureFiles LOB压缩级别是LOW，而COLUMN STORE COMPRESS FOR QUERY LOW/QUERY HIGH和COLUMN STORE COMPRESS FOR ARCHIVE LOW/ARCHIVE HIGH压缩算法相对应的SecureFiles LOB压缩级别是MEDIUM。

同时，GROUP短语还表示该表进行压缩时，对应的Globle Index将自动进行维护。

再看如下语句：

SQL> ALTER TABLE tab2 MODIFY PARTITION p1 ILM ADD POLICY 
 2 COLUMN STORE COMPRESS FOR ARCHIVE HIGH
 3 GROUP AFTER 6 MONTHS OF NO ACCESS;

该语句表示当6个月后，如果tab2表数据没有访问（NO ACCESS）时，则tab2表的p1分区数据将自动按COLUMN STORE COMPRESS FOR ARCHIVE HIGH算法进行压缩。

另外，GROUP短语表示p1分区的SecureFiles LOB字段也进行相对应级别的压缩，此时是MEDIUM级别压缩。

• Segment级压缩

SQL> ALTER TABLE tab4 ILM ADD POLICY 
 2 COLUMN STORE COMPRESS FOR QUERY HIGH 
 3 SEGMENT AFTER 90 DAYS OF NO MODIFICATION;

该语句表示当90天后，如果tab4表数据处于无修改（NO MODIFICATION）状态，则tab4表数据将自动按COLUMN STORE COMPRESS FOR QUERY HIGH算法进行压缩。

SQL> ALTER TABLE tab5 ILM ADD POLICY 
 2 COLUMN STORE COMPRESS FOR ARCHIVE HIGH 
 3 SEGMENT AFTER 6 MONTHS OF LOW ACCESS;

该语句表示当6个月后，如果tab5表数据处于低访问（NO MODIFICATION）状态，则tab5表数据将自动按COLUMN STORE COMPRESS FOR ARCHIVE HIGH算法进行压缩。

SQL> ALTER TABLE tab6 ILM ADD POLICY 
 2 ROW STORE COMPRESS ADVANCED 
 3 SEGMENT AFTER 6 MONTHS OF NO ACCESS;

该语句表示当6个月后，如果tab6表数据处于无访问（NO MODIFICATION）状态，则tab6表数据将自动按ROW STORE COMPRESS ADVANCED算法进行压缩。

• 行级压缩

SQL> ALTER TABLE tab1 ILM ADD POLICY 
 2 ROW STORE COMPRESS ADVANCED
 3 ROW AFTER 30 DAYS OF NO MODIFICATION;

该语句表示当30天后，如果tab1表数据处于无修改（NO MODIFICATION）状态，则tab1表数据将自动按ROW STORE COMPRESS ADVANCED算法进行行级（Row-level）压缩。

需要说明的是，行级压缩只能采用ROW STORE COMPRESS ADVANCED压缩算法。

数据层级策略的定义

所谓数据层级策略（Tiering Policy），是指当指定表空间达到一个阀值时，ADO自动将该表空间或该表空间对象迁移到其它存储设备的表空间的一种策略和技术。例如：

SQL> ALTER TABLE tab6 MODIFY PARTITION p1 ILM ADD POLICY

2                   TIER TO low_cost_storage;

该语句表示当tab6表的p1分区所在的表空间达到Oracle缺省指定的阀值时，p1分区数据将自动迁移到low_cost_storage表空间。

所谓Oracle缺省指定的阀值是指如下两个参数：

SQL> SELECT * FROM dba_ilmparameters;

NAME                           VALUE

————————- ———-

TBS PERCENT USED                  85

TBS PERCENT FREE                  25

即分别表示表空间使用率（TBS PERCENT USED）达到85%，或者表空间空闲率（TBS PERCENT FREE）低于25%。

通过如下语句可定制化这两个参数值：

SQL> EXEC DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED,90);

SQL> EXEC DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE,15);

如果实施了数据层级的某表空间达到了表空间使用率阀值（TBS PERCENT USED），例如85%，假设该表空间有多个数据对象，Oracle如何进行数据迁移，从而使得该表空间空闲率（TBS PERCENT FREE）降到25%？答案是Oracle采用最少访问表迁移的策略（The Least Recently Access）。例如，假设某个表空间包含T1，T2, T3表，分别在上周、今天和昨天被访问过，该表空间假设达到了表空间使用率阀值，则T1表首先被迁移走。如果表空间空闲率仍然没有降到25%，则T3表被迁移走，直至表空间空闲率降到25%。

根据ILM管理需求，很多历史数据不仅需要迁移到低端存储，而且这些数据可能不需要改动了。为此，ADO提供了如下语句：

SQL> ALTER TABLE tab7 ILM ADD POLICY

2                   TIER TO tablespace_tbs

3                   READ ONLY;

SQL> ALTER TABLE sales MODIFY PARTITION HY_2010 ILM ADD POLICY

2                    TIER TO tablespace_tbs

3                    READ ONLY;

即第一个语句将tab7数据迁移到tablespace_tbs表空间，并且设置为只读状态。第二个语句将sales表的HY_2010分区数据迁移到tablespace_tbs表空间，并且设置为只读状态。

客户化策略的定义

除了上述Oracle内置提供的压缩和数据层级策略定义之外，用户还可以通过自定义函数的方式，来客户化定义策略，从而满足更复杂的ILM管理需求。

例如，如下语句假设创建了一个返回TRUE或FALSE的函数：

SQL> CREATE FUNCTION CUSTOM_ILM_RULES

2    (objn IN NUMBER)

3      RETURN BOOLEAN …

n  /

如下语句可引用上述函数，达到客户化定义策略的目的：

SQL> ALTER TABLE EMP    ILM ADD POLICY

2         ROW STORE COMPRESS ADVANCED

3                 SEGMENT ON CUSTOM_ILM_RULES;

SQL> ALTER TABLE sales MODIFY PARTITION before_jan_2005

2             ILM ADD POLICY

3         TIER TO history ON CUSTOM_ILM_RULES;

21.7 数据归档新技术

In-Database Archiving(数据库内部归档)技术

• 数据归档的常规做法和问题

在Oracle 12c之前，当数据库的数据规模日益增长而不堪重负之后，IT系统管理者和技术人员通常想到的就是数据库瘦身计划，即把已经极少访问的历史数据进行归档，例如迁移到磁带或磁带库中，从而达到降低生产系统数据规模，提高生产系统数据库访问性能的目的。

但这种策略带来的问题也非常明显，如果需要查询归档数据，开发人员和管理员又不得不编写程序将需要的数据从磁带或磁带库中折腾回数据库内部，这种归档数据的往返迁移的确增加了管理和开发人员的负担。

12c针对这种数据归档的常规做法有什么新技术，并有效解决常规做法的问题呢？有，答案就是：In-Database Archiving技术，翻译过来叫数据库内部归档技术。

• In-Database Archiving技术细节

我们通过如下例子来介绍In-Database Archiving技术：

SQL> CREATE TABLE emp

2    (EMPNO NUMBER(7), FULLNAME VARCHAR2(40),

3     JOB VARCHAR2(9), MGR NUMBER(7))

4  ROW ARCHIVAL;

上述语句不仅创建emp表，而且定义该表采用In-Database Archiving技术,即使用ROW ARCHIVAL技术。通过该技术，用户可根据记录的访问情况确定其状态： Active 或non_Active。该技术实际上在表中增加了一个内部字段：ORA_ARCHIVE_STATE。

缺省情况下，当记录第一次插入时，该字段值为‘0’，表示为Active状态。随着时间的延长，当记录已经极少被访问也没有修改时，客户可将该字段值设置为非‘0’状态，比如‘1’，表示该记录为non-Active状态了。

用户只有在明确指定ORA_ARCHIVE_STATE字段的情况下，方能看到该字段内容，例如：

SQL> SELECT ORA_ARCHIVE_STATE, fullname FROM emp;

ORA_ARCHIVE_STATE FULLNAME

—————– ——————

0 JEAN                      <—- Active

1 ADAM                      <—- Non-Active

1 TOM                       <—- Non-Active

1 JIM                       <—- Non-Active

通过如下方式可手工设置记录的活跃状态：

/* 将指定记录设置为non-Active状态*/

SQL> UPDATE emp

2        SET ORA_ARCHIVE_STATE = DBMS_ILM.ARCHIVESTATENAME(1)

3  WHERE  empno < 100;

/* 将指定记录恢复为Active状态*/

SQL> UPDATE emp

2       SET ORA_ARCHIVE_STATE = DBMS_ILM.ARCHIVESTATENAME(0);

通常缺省情况下，在会话级用户只能看到Active数据，例如：

SQL> SELECT ORA_ARCHIVE_STATE, fullname FROM emp;

ORA_ARCHIVE_STATE FULLNAME

—————– ——————

0 JEAN                      <—- Active

如果欲查询到所有数据，则可在会话级设置如下参数：

SQL> alter session set ROW ARCHIVAL VISIBILITY = ALL;

SQL> SELECT ORA_ARCHIVE_STATE, fullname FROM emp;

ORA_ARCHIVE_STATE FULLNAME

—————– ——————

0 JEAN                      <—- Active

1 ADAM                      <—- Non-Active

1 TOM                       <—- Non-Active

1 JIM                       <—- Non-Active

正因为In-Database Archiving技术的存在，使得当前和归档数据实际上仍然保存在生产系统数据库中。这样，应用软件能很好地控制是否需要只查询当前数据或查询归档数据。当访问当前数据时，Oracle能自动过滤掉归档数据，确保访问的高性能。当需要访问归档数据时，又不需要编写程序将数据从磁带或磁带库重新加载，而只需要设置一个Session级的ROW ARCHIVAL VISIBILITY 参数为 ‘ALL’即可。

欲关闭In-Database Archiving技术，也非常简单。如下所示：

SQL> ALTER TABLE emp NO ROW ARCHIVAL;

该语句将自动删除emp表隐藏的ORA_ARCHIVE_STATE字段。

Temporal技术

除了上述In-Database Archiving(数据库内部归档)技术，12c在数据归档方面还提供了所谓的Temporal技术。由于在笔者写作此章时，12c尚未正式发布，Temporal技术也没有官方的中文术语，暂且就不翻译了。

Temporal技术又分为Temporal Validity和Temporal History技术。其中Temporal History技术就是11g的FDA技术，或Total-Recall技术，本书第12章已有讲述。虽然12c在Temporal History技术方面有所新特性增强，但限于篇幅，我们就不讲述了。而Temporal Validity则是12c纯新技术，我们下面将重点讲述。

我们同样通过如下例子来讲述Temporal Validity技术：

SQL> CREATE TABLE emp

2      ( empno number, salary number, deptid number,

3        name VARCHAR2(100),

4        user_time_start DATE, user_time_end DATE,

5  PERIOD FOR user_time (user_time_start,user_time_end));

上述语句除创建emp表之外，还通过PERIOD FOR短语表示该表采用了Temporal Validity技术。所谓emporal Validity技术，就是指表记录的可视性将由PERIOD FOR指定的时间维度字段的范围而定，只有落在时间字段范围之内的记录，相关SQL语句才可看见这些记录，而落在时间字段范围之外的记录，相关SQL语句则无法访问这些记录。而记录的时间范围则完全由应用程序来控制。例如，应用程序插入如下数据：

SQL> INSERT INTO emp (empno, salary, deptid, name,

2                    user_time_start, user_time_end)

3  VALUES (1,1000,20, ‘John’, to_date(’01-JAN-1990′,’DD-MON-YYYY’), to_date(’31-DEC-2010′,’DD-MON-YYYY’));

SQL> INSERT INTO emp (empno, salary, deptid, name,

2                    user_time_start, user_time_end)

3  VALUES (2,1500,10, ‘Scott’, to_date(’01-JAN-1991′,’DD-MON-YYYY’), to_date(’31-DEC-2012′,’DD-MON-YYYY’));

… …

SQL> INSERT INTO emp (empno, salary, deptid, name,

2                    user_time_start, user_time_end)

3  VALUES (10,800,30, ‘Kim’, to_date(’01-JAN-1994′,’DD-MON-YYYY’), to_date(’30-JUN-1994′,’DD-MON-YYYY’));

当使用如下新的PERIOD FOR短语，执行如下查询：

SQL> select * from hr.emp as of PERIOD FOR user_time

2                to_date(’01-DEC-1992′, ‘dd-mon-yyyy’) ;

Oracle将只返回第一条John和第二条Scott记录，而不会返回第三条Kim记录，因为Kim的User_time有效期为1994年1月1日至1994年6月30日，不包括上述查询语句指定的1992年12月1日。

当使用如下新的VERSIONS PERIOD FOR短语，执行如下查询：

SQL> SELECT * FROM hr.emp VERSIONS PERIOD FOR user_time

2   BETWEEN to_date(’31-DEC-2011′,’DD-MON-YYYY’)

3   AND     to_date(’31-DEC-2012′,’DD-MON-YYYY’);

Oracle将只返回第二条Scott记录，因为只有Scott的User_time有效期在上述查询语句指定的2011年12月31日至2012年12月31日之间。

用户也可通过如下语句使用Temporal Validity技术：

SQL> CREATE TABLE emp2

2      ( empno number, salary number, deptid number,

3        name VARCHAR2(100),

3  PERIOD FOR user_time);

即在表字段定义不用指定时间维度字段，而只要在PERIOD FOR短语中指定时间维度名称user_time。Oracle将自动创建user_time_start和user_time_end两个时间维度字段。

Oracle 12c还提供了DBMS_FLASHBACK_ARCHIVE包来控制记录的可视性。例如：

SQL> exec DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME(‘ASOF’,

(to_timestamp(’29-SEP-10 05.44.01 PM’))

当在某会话中执行上述语句后，表明该Temporal Validity表的记录只有落在29-SEP-10 05.44.01 PM之内，才能被该会话中的正常SQL和DML操作看见。

如下语句：

SQL> exec DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME(‘CURRENT’);

则表明Temporal Validity表的记录只有落在当前时间之内，才能被该会话中的正常SQL和DML操作看见。

如下语句：

SQL> exec DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME(‘ALL’);

则表明将Temporal Validity表的记录全部可视，这也是Temporal Validity表的缺省设置。

需要说明的是，DBMS_FLASHBACK_ARCHIVE包只能控制查询和DML语句，而DDL语句将能访问所有记录。例如：CTAS、alter table move、在线重定义等操作。

采用Oracle 12c新技术还是应用程序

在目前的技术条件下，大部分应用开发人员基本都通过编写应用程序来进行数据归档。其好处在于可有效实现数据归档的各种复杂业务逻辑，而且由于运用成熟技术，稳定性较好。但缺点是不仅数据归档应用程序本身复杂，而且由于归档数据脱离了生产环境，给归档数据的访问带来很大不便，应用开发人员又不得不编写将归档数据加载回生产系统的程序，同时也给归档数据和当前数据的共同访问和计算带来麻烦。

如果采用上述Oracle 12c的数据归档新技术In-Database Archiving和Temporal Validity呢？好处不言而喻，由于归档数据其实还保存在生产系统数据库中，不仅不用编写数据归档程序了，也确保生产系统应用的性能得到提升，而且对归档数据的访问也非常便利。但是，新技术的有效性和稳定性如何呢？只有不断去尝试，并且在Oracle不断丰富、完善之后才可考虑这些技术的使用范围和深度了。但不管怎样，Oracle 12c的这些数据归档新技术，的确为满足海量数据管理，特别是数据生命周期管理提供了新的技术手段和思路。不妨一试。

21.8 “貌合神离，貌离神合”

各行各业数据中心建设如火如荼，但到底是建成大一统的架构，还是将大系统又拆分成若干分离的系统？这是困扰IT系统决策部门和架构设计人员的重大问题。正如古语：“合久必分、分久必合”一样，很多IT系统也一直处于先进行整合，然后又进行拆分等纠结和矛盾之中。这种分分合合的行为，一方面与业务发展和需求相关，另一方面也是与IT技术，特别是IT架构技术发展相关。

为满足IT系统发展需求，Oracle公司在数据库架构技术方面一直处于不断的推陈出新之中。Oracle传统的RAC、ASM、资源管理、Service等技术，为数据库整合提供了技术基础架构和多种技术手段。Oracle  12c在数据库云计算架构和信息生命周期管理方面推出了更多新技术，这些又为企业数据中心架构设计提供了新的思路。

“貌合神离”

数据库云计算和资源整合一个重要目标就是将现有大量独立的竖井式系统整合成一个资源共享池，从而达到降低IT系统成本、提高资源利用率、降低IT系统复杂性、提高IT系统灵活性、提高IT系统服务质量等目的。如下图所示：

但这种大一统架构又给IT部门领导和技术人员带来新的忧虑：如何在这个大资源池中，对众多数据和应用进行精细化的管理？如何确保某个不良应用不要耗尽资源，更不要对其它正常应用产生不良影响？如何在尽量不停机情况下下，进行各种数据库维护操作？如何加强数据安全性管控？… …

好在Oracle早就提供了Service、资源管理（Resource Manager）、各种在线操作技术，以及Database Vault等数据库安全性产品，这些都能有效解决上述客户的疑虑。例如，根据各业务特征设计相应的Service，这样就可以按Service来进行应用部署、性能监控、作业调度、高可用性切换等，从而达到对众多应用进行精细化管理和运行的目的。

这就是所谓的“貌合神离”，即看似数据库都集中、整合了，但实际上仍然可以通过多种技术手段进行分门别类的精细化管理。

“貌离神合”

大部分行业的IT系统特别是核心生产系统，在天长地久的运行之后，都出现了应用越来越复杂，数据量越来越庞大的臃肿现象，也带来了性能、稳定性等多方面问题。于是，除了硬件扩容、应用优化、数据压缩等各种措施之外，IT决策者们都在试图对这些系统进行消肿，例如，将运行了过多应用的大系统拆分成若干系统，将堆积了过多信息，特别是访问频度很低的历史数据迁移到专门的历史数据库之中。

但这种系统和数据的拆分操作又带来了新的问题：系统拆分之后，不是又回到传统竖井式架构带来的资源浪费、管理复杂等问题吗？另外，假设历史数据迁移出去了，我们又想查询历史数据，例如将历史数据与当前数据进行对比分析、汇总统计等操作，怎么办？再将需要的数据迁移回生产系统，还是专门写程序进行跨库操作？这些都是我们在拆迁之前必须面对的问题。

好在作为IT基础架构供应商的Oracle公司，在Oracle 12c中推出的CDB、PDB架构，以及数据库内部归档（In-Database Archiving）等数据生命周期管理方面的新技术，为解决上述如何消肿的问题，提供了新的思路。

以某移动公司为例。该移动公司拟将现有CRM按应用功能和模块拆分成若干系统，我们能否采用12c的CDB、PDB架构，做到“貌离神合”呢？以下就是示意图：

也就是说，将现在CRM一个大数据库在现有平台上按照应用和数据分类，拆分成多个PDB。这样，将现在按Schema、表进行分离的数据，以PDB形式进行重新部署，既提高了不同应用和数据之间的隔离性，也降低了不同应用之间的相互影响，同时还提高了管理的灵活性，并降低了故障影响范围。另外，由于仍然是在一个平台、一个实例上运行，这种架构仍然能充分体现资源共享、管理简化等云计算基本特征。这就是在应用层面的“貌离神合”。

这种“貌离神合”策略相比将系统拆分成若干绝对隔离的物理系统，更为先进和有益，绝对隔离架构又回到了硬件资源增加、资源利用不均衡、架构复杂、运维工作量大、库与库互操作效率低等老路。以库与库互操作为例，传统的DB-link技术存在性能低、无法使用并行处理技术等缺陷，而12c的 PDB之间是采用内部的快速DB-link技术，实际上是在一个CDB内部的互操作，与传统DB-link操作的性能不可同日而语。

再从该移动公司的历史数据迁移需求来诠释“貌离神合”的理念。所谓历史数据迁移就是通过创建一个历史库，并将业务上定义为历史数据、访问频度很低的数据从生产系统迁移到历史库中。在技术层面，针对大批量数据迁移需求，Oracle已经提供了大量成熟的先进技术，例如并行导出和导入、表空间迁移等。但在历史数据管理中，其实最让客户困惑的是业务层面问题：“如何确定历史数据标准？”，“如何同时操作当前数据和历史数据？”…为回答这些问题，其实我们应从源头分析历史数据迁移的动机：我们进行历史数据迁移不就是为了对生产系统瘦身，最终目的是为了提高应用的访问性能吗？让我们反向思维：假设不进行历史数据迁移，但Oracle自己能识别出哪些数据访问频度很低，并自动设置为历史数据，这样当前应用就访问不到这些历史数据，性能不就提高了吗？同时操作当前数据和历史数据也不是问题了。这就是Oracle 12c的 数据库内部归档技术（In-Database Archiving）！

通过In-Database Archiving技术，使得当前和历史数据实际上仍然保存在生产系统数据库中，应用软件却能很好地控制是否需要只查询当前数据或查询历史数据。当访问当前数据时，Oracle能自动过滤掉历史数据，确保访问的高性能。当需要访问历史数据时，不需要编写程序将数据从历史库重新加载，或者编写跨库操作的应用，而只需要进行某些参数设置即可。

这样，不仅提高了应用访问性能，而且也免去了专门建设历史库、专门开发应用之苦。况且历史库建设还不一定能真正满足业务需求。既然当前数据和历史数据难以区分，为什么一定要去分呢？

这就是所谓的数据层面“貌离神合”：看似数据划分成当前数据和历史数据了，但实际上仍然存储在一起，应用也仍然是一个整体。

12c实施案例

12c才刚出来个第一版，就有人要吃螃蟹了！在本人最近负责提供服务的几个移动运营商客户分别结合自身业务需求，提出了在12c平台建设新系统的项目计划。这种驱动力一方面来自于移动集团对各省公司的创新激励机制，另一方面也是各省公司在仔细研究12c架构新特性，并分析各自业务需求之后，提出的有针对性的建设方案。—- 不能为了创新而创新。

当然，12c的确是新出炉的第一版产品，Bug、问题肯定少不了。为稳妥期间，这些客户实际上都是将非核心的外围系统部署在12c平台，而且在本人写作此章的2013年12月，这些项目还处于初步酝酿和环境搭建之中。以下就介绍2个案例。

地市统一支撑云平台建设

• 现状及需求

目前，XX移动各地市均部署了相应的数据库系统和应用系统，虽然基本了满足各地市的业务需求，但这种分离的架构也给各地市的运行维护、数据资源共享和交换等带来了困难。

为此，XX移动拟基于云平台技术，在 IaaS、PaaS、SaaS三个层面进行数据和应用的整合，以下就是其“地市统一支撑云平台”的基本框架和建设思路：

• 数据库云平台建设思路

以下就是基于12c架构开展的数据库云平台建设思路

• 在省公司部署一套基于X86平台的多节点12c RAC环境。
• 利用12c的CDB、PDB架构，对各地市数据库进行部署。
• 共享数据区部署在CBD库中。包括地市共享应用数据、地市业务汇总数据、地市基础明细数据、指标体系新增、业务模型新增等。
• 地市数据专区则部署在CDB库中。包括地市个性化数据区、地势临时数据区、地市应用数据区等。
• 通过CDB、PDB、Service、资源管理等技术实现精细化的管理，达到“貌合神离”的效果。
• 利用集中统一的整合平台，降低数据库运行维护工作量，提高数据资源共享和交换能力，达到“貌离神合”的效果。
• 利用12c在数据生命周期管理方面的若干新技术、新特性，开展各地市历史数据管理实施工作。
• 在基于12c整合的平台，尤其是利用12c相关新特性，开展各地市系统的优化和整改工作。
• 实施计划

以下就是我们为该项目在PaaS层面提供的12c服务计划：

综合日志库的建设

就像大多数企业客户一样，XX移动公司拥有IBM、HP、EMC、思科、华为等数以千计的硬件设备，还拥有Oracle、DB2、SYBASE、TERADATA、TimesTen、HADOOP、MySQL、WebLogic等系统软件。这些软硬件都会产生大量的后台日志，这些日志对故障分析、事件跟踪、安全审计等方面都有重要意义。

随着运行时间的增长，这些日志也会急剧膨胀，消耗大量存储资源。面对这种情况，系统管理员、DBA的通常做法就是将这些日志文件分门别类归档之后，然后清空当前日志。这种现状带来的问题是由于缺乏统一的日志管理平台，导致日志文件管理存在散、乱，不利于综合利用和分析等问题，也导致运维工作量的增加。

为解决这种问题，XX移动公司提出了综合日志库的建设项目。即将操作系统、数据库、应用服务器等多个技术层面的日志信息进行集中管理，同时覆盖CRM、计费、账务、经分等多套业务系统。

如何在技术架构上加以实现呢？12c的CDB、PDB再适合不过了。以下就是初步的架构示意图：

即以IT技术层面进行CDB和PDB的设计，例如按操作系统、数据库、应用服务器、网络分类进行PDB设计。当然也可考虑按业务系统划分，例如按CRM、计费、账务、经分等分类进行PDB设计。

据客户初步估算，该综合日志库初始容量就将达到10TB，而且还将高速增长。日志信息如何有效进行数据生命周期管理？如何压缩、如何分层管理？12c的Heat Map和ADO技术、In-Databaes Archiving技术、Temporal技术等将发挥重要作用。

究竟如何设计CDB/PDB架构？如何有效进行日志信息的自动化管理？在笔者写作之时，项目仍然在初步运筹和环境搭建之中。欲知实际实施效果，且等笔者新作了，呵呵。

21.10本章参考资料及进一步读物

本章参考资料及进一步读物：

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

数据库私有云技术

云计算是当下IT行业最为热门的技术领域之一。无论是IT行业各厂商，还是IT从业人员，如果不念念有词云计算，不知道什么叫IaaS、PassS、SaaS，似乎就Out了。不仅广大IT人士被各厂商的云计算概念弄得云山雾罩，而且也有很多调侃云计算的段子。例如，美国某记者在街头随机采访一老太太，询问“什么叫云计算？”。老太太一本正经：“就是在飞机上访问Internet吧？”，呵呵。

云计算到底是什么？作为IT公司大佬的Oracle是如何定义和诠释云计算，特别是数据库云计算的？Oracle数据库云计算中有哪些关键技术？数据库云计算有哪些成功案例？本章将就这些话题展开讨论。

20.1 云计算概述

云计算定义

云计算实际上是网格计算、分布式计算，以及并行计算、网络存储、虚拟化、负载均衡等传统计算机技术和网络技术发展融合的产物。虽然各IT软硬件供应商都在研究和发展自己的云计算产品和技术，对云计算的定义和解释也不尽相同。但美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）的如下定义，基本为IT行业所普遍接受：

“云计算是一种新的计算模式。在该模式下，用户可便捷、按需地通过网络访问一组包括网络、服务器、存储、应用和服务在内的计算资源池，并且服务供应商可以极少的管理成本，对计算资源提供快速供应和释放能力。”

以下是云计算架构示意图：

云计算基本特征

根据上述定义，云计算具有如下基本特征：

• 按需的自助服务能力
• 资源共享池
• 快速灵活的伸缩性
• 可度量的服务
• 高速网络访问能力

云计算服务模式

云计算可以认为包括以下几个层次的服务：

• IaaS：基础设施即服务

IaaS(Infrastructure-as-a-Service)：基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得的服务。

• PaaS：平台即服务

PaaS(Platform-as-a-Service)：平台即服务。PaaS实际上是指将软件研发的平台作为一种服务提交给用户。

• SaaS：软件即服务

SaaS(Software-as-a-Service)：软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。

云计算的实施模式

从实施角度而言，云计算具有如下4种模式：

• 公有云

公共云是在公共网络上搭建的计算平台，比如亚马逊等网站提供的云服务。

• 私有云

私有云就是企业内部搭建的计算资源平台。比如Oracle公司在企业内部就拥有并使用很多私有云平台，供广大研发和技术支持人员使用。

• 社区云

社区云是公有云和私有云的变种，实际上是若干个企业共享一个云计算平台，介于公有云和私有云之间，主要特征是使用权和所属权的分离。

• 混合云

混合云是将私有云和公有云结合起来的计算资源。比如很多银行和保险公司在月底做报表的时候需要大量的计算资源，如果按照这个峰值配置硬件设备又很浪费，80%的时间内有80%的机器是闲置的。因此，可以将企业内部的机器和亚马逊这类的云服务供应商相连接，需要的时候通过云计算服务租取机器。

云计算的益处

云计算的核心思想即为客户提供一组资源共享池。通过云计算理念构造的IT系统，将为客户带来如下图所示的四方面的效益：

• 降低IT系统成本

在云计算架构下，各IT系统不再拥有独立的计算资源，而是共享计算资源，因此，IT系统建设和运行维护成本都将显著下降。例如在建设方面，服务器、存储等硬件资源将大幅度减少，对应的软件许可证（License）和资源投入也将大幅度减少。

• 降低IT系统复杂性

云计算架构的共享计算资源池，将具有规范的配置，包括操作系统、数据库等平台和系统软件都将实现标准化和统一化，从而有效降低IT系统的复杂性。

• 提高IT系统灵活性

云计算架构所具有的在线变更能力、快速响应能力等，将使得随着业务的不断发展，可灵活变更IT系统架构，充分提高IT系统灵活性。

• 提高IT系统服务质量

云计算架构提供了完备的高可用性解决方案，将有效保障IT系统服务时间。共享资源池将使得 IT系统处理能力和响应速度大大提升。同时，各种有效的安全技术和产品施，也将使得运行在云计算架构下的IT系统更加安全、可靠。

不同层次的云计算

不同层次的云计算

根据Oracle公司的定义，云计算可划分为如下层次：

即划分为基础架构云计算和数据库云计算。其中基础架构云计算是指在主机和操作系统层面实现的资源共享和整合，例如通过虚拟技术将一台高端物理主机划分为多台虚拟主机，或者将多台物理虚拟成一台高端主机。

而数据库云计算则是在基础架构云计算之上实现的更高层次、给客户带来更高投入产出比的资源共享和整合技术。数据库云计算又可分为平台整合和数据库整合技术。其中平台整合是指将过去在多个平台、多个版本的数据库，整合到统一的硬件和操作系统平台，但仍然部署为多套数据库的架构技术。而数据库整合则是进一步将多个数据库整合为一套集群数据库的架构技术。

不同层次的云计算的对比

以下是Oracle公司针对上述不同层次的云计算架构，而进行的对比分析：

总之，数据库云计算相比基础架构云计算，给客户带来的投入产出比更高，具有更好的架构灵活性，并提供更好的服务质量，但实施难度更大。

某案例的基础架构云计算实施

某客户采购了IBM 770服务器，并欲在其中实施数据库云计算项目。以下就是IBM公司从基础架构层面提供的云计算实施建议，供大家参考：

总体思路

通过虚拟化技术，将XX客户采购的IBM 770服务器资源划分为多个逻辑服务器，作为数据库云服务器。这些逻辑服务器可以快速的根据XX客户各业务需要灵活部署应用，并可根据实时业务压力，分配各个业务的资源需求，从而提高系统管理效率，降低管理成本。

随着系统规模的扩大，如今后资源服务器池需要扩充时，可以通过纵向扩容的方式增加服务器处理能力；或者采购新的高端服务器，添加到数据库服务器池中。

实施策略

• 根据业务需要，可初步规划多个分区分别用于各个生产应用。另外，虚拟IO分区可以用于向其他分区提供虚拟网卡和虚拟磁盘。对于关键应用，可以配置真实的物理网卡和物理磁盘。对于非关键业务（如：开发测试或者一些小规模的应用，可以分配虚拟的网卡和虚拟的磁盘，这些磁盘和网卡由虚拟IO服务器提供）。
• 在系统部署时，通过高级虚拟化技术（如：IBM Power 770服务器中采用的PowerVM虚拟化技术），可将整台服务器进行灵活的逻辑划分，分区的颗粒度可达到0.1颗CPU。每个分区相互独立，各自运行独立的操作系统和应用，互不影响。同时，利用共享处理器池(shared processor pool)和动态逻辑分区(dynamic logical partition)的功能，能够保证最大限度地利用系统宝贵的硬件资源，能够为分区提供极大的峰值处理能力，还可以根据实际需要，在不停机的情况下调整硬件资源，部署新的业务分区等。
• 在实施时，可以将分区设置为“不受限”uncapped分区：即，分区能够使用到的CPU处理能力，允许超过其分配的CPU容量。如下图：

其优势在于，当分配给此分区的CPU没有使用时，分区内的CPU资源可以“还回”共享处理器池。而当此分区有工作负载时，此分区又可以马上得到“额定”的CPU资源。

另外，虚拟化技术的引入，使对于操作系统的监控方法和指标发生了改变。这需要我们转变思路来适应。在硬件层面，使用共享处理器池方案分区可以自动调整计算能力，分区所获得的计算能力会根据负载变化。

最终产生的效果是通过虚拟化技术，降低了物理设备的资源需求的，提升了系统总体的利用率，示意图请参见下图。

• 根据上述初步规划，IT资源服务管理平台可以帮助实现IT资源的自动化部署，且在不停机的情况下动态调整资源配置。
• 为了保证系统的持续运行和高可用性，770服务器上的分区都安装高可用集群软件，实现自动的故障探测和切换，消除系统单点故障。
• 每个逻辑分区中还配置多块Gigabit 以太网卡，进行高速的数据通信。在分区中配置8Gb/s的HBA光纤通道卡，连接存储服务器，实现对数据的高速访问。

在IBM Power机器上配置的8Gb HBA卡是有NPIV功能的。如前文所述，对于开发和测试可以考虑使用虚拟的IO设备，由虚拟IO服务器分区来提供，而在这些分区中使用NPIV（N-Port ID Virtualization）技术可以简化VIO Server的部署和管理。简单的讲NPIV功能原本就是在SAN交换机上的一种虚拟化技术，目前应用到Power服务器上实际上是HBA卡的虚拟化，同时也需要SAN交换机的配合（这种配合比较简单，目前大多数的SAN交换机，都支持NPIV技术。在实施时，将相应的SAN交换机的NPIV功能激活即可）。

产品和方案特点

• 优异的系统处理能力

此次XX客户采购的IBM 770服务器是IBM的顶级UNIX服务器，配置36核CPU和320GB内存，具有强大的在线事务处理能力和计算能力。该服务器采用先进的POWER7微处理器，高主频提供了优异的整机性能及近线性的扩展能力。其多项基准测试数值为业界领先。在衡量服务器在线事物处理能力的基准测试中，是目前在该项测试中排名第一的服务器产品。

• 选择业界领先的处理器技术和平衡的服务器体系结构

服务器体系结构是决定服务器性能的关键因素。在选择服务器时，需要根据业务情况选择合适的主机平台，主机平台要能够支持交易处理，业务查询和应用开发，尤其在交易高峰期间能够与磁盘系统配合，使整个系统性能平衡不会出现系统瓶颈，保证系统响应大压力的数据负载。

IBM一直保持着单机性能业界第一的位置，在CPU的数量上仅为其他竞争厂商的一半甚至更少，也就是说在相同性能下选用IBM服务器大大降低了IT系统的总体成本，在现在IT系统更讲究系统资源集中的情况下，IBM的服务器以更高的性能、较少的CPU、更高的安全稳定性、更低的功耗、更小的占地面积来完成IT系统的整合。大大降低用户的初期总体投资以及运营成本。

• 选择高可用技术

XX客户运行的关键业务要求其生产系统达到7X24的连续运作水平，因此系统高可用性的考虑是系统方案中必不可少的因素之一。在进行硬件配置时，用户肯定会选择运行更为稳定的硬件，以及更高安全级别的技术，但任何单机运行的系统都是不安全的，因此，建议为生产系统中的分区配置高可用软件（如：IBM的HACMP软件），同时配置相应的配件（如：串口卡等），构成双机系统。

在生产系统中，某个应用至少要部署在两个服务器分区上，分区上安装高可用软件，实现双机互为备份或者双机同时工作。

能够对群集环境中每个结点的异常情况进行实时监测并进行恢复响应，监测过程不需要人工干预，可以监测的对象包括：系统处理器、系统内存、网络介质及网卡、系统进程、应用进程等。当POWERHA监测到上述故障时，它会重新配置群集结构，并将应用从出现问题的主机系统快速地切换到正常工作的主机之上继续运行，保证了应用的连续和正确运行，这个恢复相应的过程也无需操作人员的参与。

除了减少意外停机外，还能减少计划停机的时间。当需要进行硬件更换或软件升级等系统维护工作时，操作人员可以发出简单的命令将应用包从待维护的结点移至其他结点。这样，在进行系统维护的同时，整个群集中的应用不受影响。当结点的维护工作完成之后，便可将其重新加入到群集结构中，并把原在其上运行的应用包切换回来，恢复该结点的正常运行。采用循环升级的方法可以升级群集内的所有系统，同时不影响群集的正常运行。

因此，在我们的推荐的方案中，对所有的生产系统全部进行高可用性保护，消除整个系统中的单一故障点。

• 选择成熟稳健的虚拟化技术

建议XX客户业务在服务器上的部署采用先进和成熟的分区方式。虚拟化技术能够提高服务器资源利用率，简化系统管理和维护的负担。

以IBM PowerVM技术为例：它提供了比物理分区更好的灵活性和细颗粒度，以及比软件（操作系统级）分区更好的性能，可靠性和效率。其最大的特点在于可实现资源的动态分配而无需重启操作系统。对于XX客户业务而言，重启操作系统就等同于宕机，这种无形的损失是无法估量的，这一动态分配技术则很好的解决了这一问题。

在CPU、内存、I/O等资源控制和调配上，分区技术具有更大的灵活性和操作性，使用户更加有效地利用服务器资源，当各个分区投入生产后，若某个分区的资源不够时，动态分区技术可以做到不用停止操作系统和应用程序，就可以将分区之间的资源进行相互调配(动态增加或删除CPU、内存、I/O卡等)。分区技术稳定可靠，能够保证各分区之间相互隔离，保证一个分区的错误不会影响到另一个分区的运行。

数据库云计算中的典型技术

在Oracle数据库云计算实施中，为实现按需的自助服务能力、资源共享池、快速灵活的伸缩性、可度量的服务等云计算基本特征，特别是实现对数据库整合之后的性能、安全性、资源管理等精细化管理和控制，Oracle提供了RAC集群、自动存储管理（ASM）、服务（Service）、资源管理（Resource Manager）、实例隔离（Instance Caging）、企业管理器（OEM）、Data Guard 容灾等典型技术，其中除实例隔离（Instance Caging）等之外，其它技术均在11g之前就已经推出，但这些技术在数据库云计算中得以发扬光大，真可谓老树发新芽。

以下只介绍服务（Service）、资源管理（Resource Manager）、实例隔离（Instance Caging）等技术在数据库云计算中的运用。

服务（Service）及在数据库云计算中的运用

服务的概念最早是在 Oracle8i 中引进的，当时是通过服务的设置，使得监听程序在集群的节点和实例之间实现连接负载平衡。现在，服务的概念、定义和实施都已经有了巨大的扩展，特别是在数据库云计算中，通过服务可以实现对众多整合资源的精细化管理和控制。

服务是一项工作量管理功能，用于组织数据库内的整个工作执行，以便使该工作更易于管理、衡量、优化和恢复。服务是数据库内相关任务的组合，这些任务有共同的功能、质量预期值以及相对于其它服务的优先级。服务可提供单一系统映像，用于管理在单个实例内运行的竞争应用程序，以及跨多个实例和数据库运行的竞争应用程序。

使用标准接口（例如 DBCA、Oracle Enterprise Manager 和 SRVCTL），可将服务作为单个实体进行配置、管理、启用、禁用和度量。

服务具有高可用性特征。即某个节点或实例宕机之后，运行在其上的服务中断后，仍然会在仍正常运行的节点或实例上快速自动恢复。

在Oracle的AWR中，可以服务为单位进行性能的监控分析，更有效地进行应用的性能管理。在Resource Manager中，也可以服务为单位进行资源的细粒度分配，能更合理地有效利用系统资源。Oracle的其它工具和产品，例如Oracle Scheduler, Parallel Query, and Oracle Streams Advanced Queuing等均能有效地运用Service概念，进行系统负载的管理工作。

服务还具有动态性。即负载增大时，可增加服务运行的实例数；负载减小时，可减少服务运行的实例数。通过这种动态资源分配，可以实现经济有效的解决方案，随时满足各种需求。

在下面的案例中，我们将看到在数据库云平台中，如何通过服务实现众多应用的精细化管理和控制的。

资源管理器（Resource Manager）及在数据库云计算中的运用

通常客户都有这样的需求：防止普通用户通过SQL*Plus或PL/SQL Developer等工具，随意执行低质量的SQL语句，从而消耗大量资源，对前台正常业务造成影响。针对优先级特别高的应用模块，希望Oracle能优先分配更多资源，等等。

为满足客户对系统资源使用的细粒度控制，Oracle自8i开始就推出了Database Resource Manager技术。在历经8i、9i、10g之后，该技术在 Oracle 11g中不仅日益成熟，而且功能也有了重大增强，更在数据库云计算中得到了更大的运用空间。

试想，在数据库云平台中，众多应用模块同时运行在一个资源池中，共享也是竞争相同的硬件和软件资源，如何有效地根据不同应用模块的特征和优先级，合理调度和控制资源的使用，是数据库云计算项目建设和运维需要考虑的重大问题。

Resource Manager通过将用户分组，然后把系统资源分配给不同用户组，实现系统资源的管理。Resource Manager可以管理CPU资源，内存资源，以及服务器上的其它资源，并且可以实现资源管理的自动化。例如，如果预计某个用户组的资源使用将超过限额，Resource Manager将重新安排它的优先级，从而使系统的整体性能达到最佳。

Resource Manager允许对资源的更多粒度控制并为客户组添加诸如自动客户组切换、最大活动会话数控制、查询执行时间估计和撤消池限额之类的特性。管理员能够指定每个客户组的最大并发活动会话数。一旦达到这一极限，Resource Manager 将对所有后续请求进行排队并仅在现有活动会话完成之后才运行它们。

Resource Manager 的自动客户组切换功能允许管理员指定某一准则，如果满足它，将导致 Resource Manager 自动切换一个长时间运行的客户组，例如，从为 OLTP 操作而建立的客户组到另一个适合成批报告的客户组。管理员也能够为每个客户组设置最大估计执行时间。然后 Resource Manager 在每个操作开始之前为操作估计大致的查询执行时间，如果此时间超过指定的极限，将终止该操作。利用撤消池限额特性，管理员能够为每个资源客户组生成的回退数据总量指定一个最大值。这将阻止一个”欺骗”事务处理消耗过多的回退空间并因而影响系统操作。

以下是某电信公司为避免部分用户对系统资源过度使用系统资源，运用 Resource Manager的一个实施案例：

• 资源计划设计

resource_manager_plan = FORCE:CRM_PLAN

即强制设置了资源计划：CRM_PLAN。

• 资源消费组设计

以下是在 OEM中设计的资源消费组(Comsumer Group)和Direcive等情况：

即设置了多个消费组，并对其中的INTERACTIVE_GROUP、INTERFACE_GROUP、MAINTAIN_GROUP等消费组的Execution Time、I/O等指标进行了限制，并达到了显著效果。

实例隔离（Instance Caging）技术及在数据库云计算中的运用

实例隔离（Instance Caging）技术是11g R2为满足数据库云计算需求而推出的新技术。该技术其实很简单，就是增加了一个数据库初始化参数：CPU_COUNT，该参数表示该实例所能使用的CPU个数，其缺省值为0，表示该实例可以无限制地使用机器当前服务器的所有CPU配置。

Oracle RDBMS的若干组件都与CPU个数相关，例如：优化器、并行查询、资源管理器等。因此，通过CPU_COUNT参数的配置，可为共享服务器中的数据库实例提供CPU访问能力控制，避免无限制使用CPU资源，保证服务级别。特别在采用平台整合技术实现的数据库云平台，通过Instance Caging技术的运用，可根据不同应用、不同实例和不同数据库的服务级别的优先级，设置相应的可使用的CPU数量上限。

例如，右图表示在一个8核CPU服务器上整合了HR、Sales、ERP三套数据库和应用。我们可以根据需求，为ERP应用分配4颗CPU，为HR、Sales各分配2颗CPU。

同时，CPU_COUNT参数可不停机动态进行调整，如果业务负载发生变化或服务级别发生变化，可通过该参数的调整，满足相应的需求。

另外，Instance Caging技术支持硬件分区和虚拟化技术。该技术也是对Resource Manager的补充。即在数据库实例内部，主要通过Resource Manager来进行资源使用的管理和控制，而实例之间则可通过Instance Caging技术来进行资源的管理和控制。二者的有机协调工作，将会为数据库云平台的资源合理、有序使用提供保障。

一次尴尬的拜访经历

一次尴尬的拜访经历

2013年夏天，本人作为服务解决方案顾问拜访某外资银行时，得知该客户的现有几十套IT系统为典型的“竖井”式架构，并具有典型的“三多”特征：系统多、平台多、版本多。当时我们力荐客户进行数据库整合和版本升级，并从数据库云平台高度去帮助客户立项。但客户当时说需要等几个月进行内部调整之后，方可进行这么大的架构改造动作。

待2013年12月我们再次拜访该客户，旧话重提，并希望我们Oracle服务团队能在此项目中大显身手时，客户的回答是：“我们已经做完升级和整合了”。-

—- 惊讶、失望、尴尬，刹那间这些复杂情绪全部涌上心头。惊讶的是客户怎么如此之快就悄然完成了这么复杂的数据库升级和整合操作？失望的是客户自己完成了这么浩大的工程，我们Oracle服务团队失去了一次商机，更失去了一次在客户面前展现原厂服务价值的机会。尴尬的是我们Oracle公司成天讲升级、整合的难度和风险，客户现在这么神速完成升级和整合，肯定会觉得这不就是搭建个11g RAC数据库，然后把现有系统数据一倒，应用一跑就完了吗？你罗工不就是一大忽悠吗？

尽管感到一定震惊，但经验让我马上镇定下来。接下来，我开始详细了解客户如何完成升级和整合的。哦，原来如此：客户的数据库资源池硬件为IBM X86平台，8核或16核CPU、64GB，按照该外资银行总部的整合规则，最多6个数据库部署在2个节点的6套RAC数据库中。原来只是在硬件平台进行了整合，即上述的平台整合，而不是以schema方式进行的数据库整合。也就是说：虽然数据库版本都升级到11g R2，并且部署到统一的硬件平台，但数据库并没有整合，整合力度不够，仍然存在实例过多，内存、进程浪费的问题。

而且在平台整合过程中，客户并没有充分考虑实例之间的Instance Caging、实例内部的资源管理器等技术的运用，即没有考虑不同应用对资源使用的不同优先级需求。同时，也没有考虑Service等技术的运用。也就是说，虽然系统整合了，但精细化管理技术的运用并不够。总之，该项目是一个整合力度不够，而且粗放型的整合项目。

进一步，在对被整合的一个最大的数据仓库系统进行现场调研分析时，也发现该系统存在应用软件质量较差，例如索引策略不合理，语句共享性较差；没有实施分区方案；RMAN实施存在缺陷等诸多问题。具体而言，在RMAN实施方面采取简单的每天全库备份策略，3TB的全库备份时间长达3个小时，而且备份时间从8：00开始，直接影响了生产系统正常访问，非常不合理。改进措施就是不仅调整备份时间窗口，更重要的是采用“全库+增量”备份策略，并采用快速增量备份（FIB）技术。果然，客户在马上采纳我们的建议之后，增量备份时间才18分钟！

因此，再次验证本人一句断言：任何一个IT 系统的实施都会存在不足，只要有心，作为Oracle原厂技术服务团队，我们都能找到服务机会，并展现我们的服务价值的。

但是，我在离开该客户现场之后，仍然是感慨万千，特别是失落感更为强烈：毕竟客户围绕Oracle展开这么大的架构改造动作，居然一点没告诉我们Oracle公司，虽然存在一定问题，但总体还是成功了。如果客户能更相信我们，甚至依靠我们；如果我们的销售、售前、实施团队能更紧密地与客户沟通，也许客户就会采纳我们的更多方案和建议，例如在数据库层面进行整合、采用资源管理和Service等关键技术，我们的服务价值就能得到更充分发挥，我们与客户的合作关系就将更加紧密… …

毕竟IT系统建设和运维是一项长期的系统工程，亡羊补牢，为时未晚。这个世界上也允许有很多如果存在的… …

数据库云计算案例分享

某移动客户的业务支撑部门在多年发展中，不仅建设了营业、帐务、计费、中心枢纽等核心业务系统，而且还由于业务和历史原因，还建设了平台、架构不一的几十个外围小系统。如何将这些系统进行整合，并有效提高设备利用率、加强技术平台规范化、降低建设和运行维护成本，成了该客户领导和技术人员关注的话题。于是，综合资源池项目建设提到了议事日程，并在局方、Oracle ACS团队、多个开发商的共同努力下，于2012年 – 2013年间成功实施了该项目。下面将该项目一些主要情况叙述如下，供大家在建设类似项目时，加以借鉴。

“我们的架构也差不多都是这样”

下图就是该移动客户业支部门大大小小的部分外围小系统基本情况：

可见，具有典型的“三多”现象：系统多、平台多、版本多。例如，平台包括HP-UX、AIX、Sun Solaris等，数据库版本包括9.2.0.1、9.2.0.6、10.2.0.3、10.2.0.4、10.2.0.5、11.2.0.2等。

从架构方面而言，大量采用双机热备技术，只有一套系统采用了RAC技术。双机热备架构并不能充分满足高可用性切换的时效性需求，而且备份服务器资源不能得到充分利用。

上述系统在CPU、内存配置和利用率等方面也各不相同，数据库容量也相差甚远。这种设备配置和部署都是考虑各业务系统峰值，而系统之间是绝对隔离的，资源无法共享，导致了资源极大浪费，同时又存在业务高峰时单个系统资源不足的风险。

这就是典型的竖井式架构！当本人每次将该表格展现给其它客户时，他们都会掩嘴自乐：“我们的架构也差不多都是这样”。我想很多读者看过之后，也会发出类似感慨和会心一笑，呵呵。

整合目标和总体架构

以下就是综合资源池项目的总体目标：

• 构建安全的共享数据处理资源池
• 采用云化技术统一构建与管理
• 统一考虑处理能力与冗余
• 主机与数据库平台的规范化建设，降低运维成本
• 统一管理平台
• 统一采用集群与容灾技术
• 增强业务高可用性
• 分布式数据层技术
• 通过分布式的数据层和智能存储解决性能瓶颈，实现高智能复杂业务
• 能够容易水平的扩展处理能力
• 良好投资回报率

以下就是数据库整合之后的架构：

可见，数据库整合项目将部署在一个4节点组成的RAC数据库之中，即采用的是数据库整合架构，而不仅仅是平台整合架构。即原有各应用数据库以Schema形式部署到新的数据库资源池中。

在4个节点中，前三个节点承担相关应用的运行，而第4个节点作用则包括两个：一是承担日常数据库备份操作，二是当前三个节点发生故障时，承担故障切换（Failover）角色。

在前三个节点的应用部署中，则综合考虑了多种因素，例如：重要系统与一般系统；OLTP与OLAP；操作系统厂商情况；CPU、内存、IO负载情况；业务数据量大小；业务应用连接数量；业务负载情况；数据库版本情况；数据库数据字符集；原有数据库部署架构；应用代码开发编写特点（绑定变量的使用）；业务月结负载特点… …

可见，如何在考虑业务尽量均衡、数据访问冲突间量少，还要兼顾上述那么多因素，以及未来业务发展趋势等方面进行应用部署，并不是一件轻松的事情。

关键技术的运用

• Service的运用

在该项目的数据库资源池中大量利用Service技术，来达到对众多整合资源的精细化管理和控制。具体而言，该项目按照如下原则进行Service的设计和部署：

• 每个业务或者应用皆定义为Service。
• 应用基于Service进行部署，并实现高可用性的连接。
• 应用基于Service进行动态的部署
• 应用基于Service进行故障切换
• 基于Service进行资源的控制
• 基于Service进行管理，提供了一种新运维管理维度

例如，以下就是部分Service设计和部署情况：

以下就是创建Service的规范化语句：

srvctl add service -d 云平台 -s srv14 -r 云平台1 -a 云平台4 -P basic -e select -m basic -z 10 -w 2

其中：
-d <dbname>
-s <service name>
-r <prefer node>
-a <available node>
-p <TAF policy> 服务端设置为basic
-e <failover type> 配置为session 或者select 建议默认配置为select
-m <failover method> 配置为basic
-z <failover retries> 云平台设置为10
-w <failover delay> 云平台设置为2

• 资源管理器的运用

该项目通过资源管理器来合理控制资源使用，即一方面为不同层级应用制定资源优先级策略，为核心应用确保足够的资源，另一方面也防范对资源滥用情况的发生。为此，该项目制定了如下一些资源管理策略：

• 每一类应用用户使用固定的service 连接至云平台数据库。
• 每一类应用至少给予5%的CPU 资源。
• 核心应用至少给予30%的CPU 资源
• 系统管理类用户(sys/system) 会有最高权限获得至少75%的 CPU 资源并且保证可以连接
• 系统自动任务和管理类JOB 会使用应用CPU 资源余下部分中的至少5%的CPU资源并且总CPU资源消耗不超过90%
• 其余连接用户或者服务使用余下资源。

例如，以下就是节点1的资源分配计划：

即：

• 划分了level1至level3 三级分配策略。Level1 优先级最高,level3优先级最低。
• 上一级未用完的系统资源可用于下一级。
• 如节点1中，首先管理进程可获得最多75%的CPU资源。
• INGWDB,PMOS,SMS,MRMSPU资源的最大比例为7:1:1:1。
• 如果前两级资源为充分使用，在第三级可获得前两级剩余CPU资源。其中分配比例为3:3:3:1

效益评估

以下就是从项目建设和系统运维方面对该项目的效益评估：

• 项目建设方面

首先在硬件方面降低了成本，通过整合，将16台数据库服务器整合到4个数据服务器，平均每台数据库服务器利用率从15%增加到40％。

在软件方面，由于通过整合，将30台服务器192 CPU整合到4台112CPU ,降低了软件采购成本。

再则，打破了以前建设一套新系统需要专门部署一套硬件和软件的思路，现在的新系统建设，只需在数据库设计、应用设计、Service设计、应用部署等方面进行规范化检查，即可快速部署，而无需专门部署硬件和安装系统软件。

• 系统运维方面

首先，通过整合，将原有30台主机的日常维护，健康检查，补丁升级工作，降低为对4台主机的日常维护，运维管理效率提高7.5倍。通过企业管理平台的实施，包括诊断和调优包实现自动诊断和调优操作，使运维人员工作效率提高。同时，通过标准化平台管理，降低了复杂性并和减少配置工作。

再则，将原有30台主机的耗电空调降温成本，降低为对4台主机的耗电空调降温成本。将原有30台主机整合到1-2个机柜，减少了数据中心空间占用。

最后，数据库版本升级后，使用11G数据库新优化特性，提高数据库处理性能。 另外，数据库迁移后，数据碎片得到整理。提高数据库IO处理效率。而且，数据库版本升级后原厂支持响应更及时。

20.7本章参考资料及进一步读物

本章参考资料及进一步读物：

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

话说升级

长期以来，Oracle数据库系统升级是让IT系统决策者和管理者陷入两难境地的重要话题。一方面，IT系统高速发展所提供的大量新技术和新特性，对IT人员充满诱惑，也的确能解决现有IT系统中的大量问题。另一方面，面对各行业正在运行的、非常重要的生产系统，缺乏全面评估和验证的数据库系统升级操作，不仅可能会导致业务中断时间过长，更严重的是可能导致应用软件的不稳定性，甚至性能衰减。因此，犹豫和彷徨之中，IT系统决策者们一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”。日积月累之下，不仅数据库技术老化，而且也妨碍了硬件、网络、中间件等其它层次新产品和新技术的运用，最终导致现有IT系统难堪重负。更有甚者，索性推翻原有IT系统，另起炉灶。这不仅导致大量重复建设，更使得现有系统的软硬件资源和数据资源难以继承，即导致整个IT系统的投入产出比(ROI)的下降。

关于Oracle数据库升级，业界到底有多少顾虑？为什么要升级？升级项目应该包括哪些实施内容？升级技术方案到底有哪些？如何防范升级之后应用软件性能不衰减？升级项目如何组织实施？如何防范风险？本章试图围绕这些话题一一道来，希望给大家在计划和组织升级项目实施时，起到抛砖引玉的作用。

关于数据库升级的疑虑

关于升级的矛盾和纠结

关于升级，IT行业不同层面和角色人员到底有哪些纠结、矛盾和疑虑？以下这张图大概能表白大家的很多共同心声：

上述“为什么要升级？”和“升级能带来什么益处？”，其实更多地是有关升级的必要性问题。而“升级如何保证停机时间”、“万一升级失败，怎么办？”、“新版本对应用是否兼容”、“升级后是否会导致性能下降”等类问题，则是有关升级的可行性问题了。最后，“如何使用新特性？”、“需要对系统运维工作进行哪些调整？”等问题，就不仅仅是将升级看成是一种被动而为的事情，特别是为了满足Oracle产品服务期限的需求，也不是一种新瓶装旧酒的保守思维方式，而是以更积极的心态，主动接受和拥抱新平台、新技术，将升级看成是一次升华的过程了。

本章和本书更多章节内容，都是在试图解答大家的这些共同的疑虑，从而帮助大家面对升级工作，树立起既积极乐观、又严谨缜密的思维模式和工作方法。

关于升级两种绝对观点

在多年与国内多个行业的众多客户探讨数据库升级时，我们经常听到如下两类截然相反的观点：

• “升级是很简单的事情”

此观点更具体的叙述是：“升级哪有你们Oracle公司说的那么复杂，不就是建个11g新库，然后把9i、10g数据倒一遍吗？你们Oracle就想忽悠我们买你们更多服务吧？”

以本人经验，持这类观点的用户也是有所根据的：通常他们的系统数据量可能不大，例如最多只有几十GB。更重要的是，这类系统高可用性可能并不高，停几个小时、甚至停个周末进行升级都无所谓，几十GB数据慢慢倒几天呗。还有，这类系统的应用软件也比较简单，基本采用最基础、最经典的SQL语句，也几乎不可能在新平台运行时出现应用不兼容、性能衰减的问题。

不过，尽管这类客户的数据库升级风险不是很大，但麻雀虽小、五脏具全，同样也应考虑作为一个升级项目的方方面面的工作，例如升级技术方案的确定、性能稳定性保障、11g新特性运用、数据库是否需要整合等工作内容。

• “升级太复杂了，风险太大了”

持这类观点的人当然是银行、电信、政府、制造等关键行业的客户了。这些行业的数据库系统不仅数据量动辄达到TB、甚至几十TB以上，而且几乎全部是7*24小时的关键业务系统。为了升级这种多年难遇的事情，也最多向主管部门申请数个小时的停机时间窗口，如何保证在这么短的时间窗口内，完成这么浩大的升级工作？

再则，这类关键系统的应用通常都非常复杂，不仅表、索引、分区、存储过程、函数等数据对象经常达到万个以上，而且国内应用开发高手们，经常写出数百行的单个SQL语句，这些SQL语句在新平台的兼容性，特别是性能稳定性如何保证？的确是困扰各层面人士的难题。

于是，就出现了上述犹豫和彷徨之中，一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”的局面。

数年前，某电信公司将核心营业系统的Siebel应用软件进行升级，同时将数据库也升级到11g R2版本。尽管专门组织了由客户、集成商、Oracle原厂商等组成的团队，更进行了长时间的精心准备和测试，但依然在正式升级之后，出现了数据库宕机，并长时间停止对外服务的重大故障，甚至被媒体曝光。究其原因是多方面的，例如Oracle 11g进程内存消耗过大问题；测试期间模拟并发数不够，而投产之后更大并发数导致内存耗尽等问题。此次严重故障也让客户各层面人士，特别是高层承受了巨大压力，甚至导致客户得出了这样的结论：“以后我们再不为你们Oracle版本单独升级了，除非我们在你们新平台重新建设一套新系统。”

其实，深究其原因，还是在升级项目组织、工作内容、工作流程方面等方面出现了重大偏差，如果我们好好总结经验教训，还是完全可以借鉴并避免这些问题发生的。

关于升级的正确观点

关于升级的正确观点是什么呢？总体而言应该用“战略上藐视，战术上重视”来描述。首先以事实为依据，在笔者所在的Oracle高级服务团队（ACS）自从2007年开始在全国提供全面、系统的数据库升级服务以来，我们团队在国内各行业的数百个系统实施了升级到10g和11g的项目，尽管经历了大大小小的各种坎坷，但没有一个系统没有升级成功！因此，对于升级，我们完全可以持“战略上藐视”的态度。

但是，在我们经历的升级项目中，也的确出现过上述电信公司尽管没有回退,但充满坎坷的项目，更经历过第一周升级不成功而不得不回退，在及时总结经验教训之后，第二周成功升级的典型案例，这也恰恰说明升级工作的复杂性和风险性，也就是说“战术上重视”的重要性。

更具体而言，针对数据库升级工作，我们应持如下的观点和相应的工作方法：

• Oracle数据库系统升级是一项机遇和风险并存的系统工程。
• 对现有系统的全面了解和评估，升级需求的分析，合理的升级技术方案设计是升级项目的基础。
• 性能问题是升级过程中需要特别关注的问题。
• 科学的升级方法论指导和项目有计划的实施是升级的重要保障。

下面章节，我们就将围绕这些观点，以某银行现状和升级需求为背景，展开更进一步的讨论。

为什么要升级？

为什么要升级？其实主要原因只有两个：首先就是Oracle产品支持周期问题，其次就是充分运用新版本的新技术和新特性，有效解决现有版本无法解决的一些问题。有关11g新特性话题，我们已经在本书前面若干章节进行了讲述。本节只叙述Oracle产品支持周期问题。

Oracle产品均有自己的生命周期，下图就是Oracle9i、10g、11g数据库产品和服务的生命周期政策：

其中:

• Permier Support（PS）表示Oracle标准支持服务期
• Extended Support（ES）表示Oracle延长支持服务期，Extended Support需在标准服务费的基础上增加额外的延长支持服务费用，且要求客户的数据库需要升级到当前版本的最后一个补丁集，如9i R2的2.0.8，10g R2的10.2.0.5等。
• Sustaining Support（SS）表示Oracle扩展支持服务期，相比Extended Support，客户需要支付更昂贵的服务费用，而得到的服务反而会更少。

下图就是Oracle官方提供的PS、ES、SS各类服务的详细情况：

可见，只有在PS情况下，Oracle公司提供的服务才是最全面的，而当产品处于ES和SS阶段时，得到的服务不仅越来越少，而且投入还会越来越多。

例如Oracle 10g R2最后一个补丁集(Patchset) 为10.2.0.5，在2010年7月就停止了PS服务，在此之后Oracle公司既不会为该版本推出新的功能，也不会为Oracle 10g R2提供任何补丁了。如果客户数据库系统发生了一个Bug，而这个Bug已经有现成补丁，客户在Oracle服务部门指导下，可直接采用该补丁。如果是新发现的Bug，除非客户花更多的服务费用采购了ES和SS服务，Oracle才会专门开发定制的补丁。

相比之下， Oracle目前主流的11g R2版本将可以获得Oracle公司从产品研发到全球支持服务部门的全面技术支持。Oracle在2014年7月之前将一直提供对11g第二版的PS支持，而ES支持则可以持续到2018年7月。

Oracle这种服务策略霸道吗？上述服务策略是霸王条款吗？作为Oracle公司人员，本人并不这么看待。Oracle制定这种服务策略，如同所有IT公司一样，的确是在鼓励客户与时具进，享受IT技术最新发展成果。再则，我们从商务层面也不难理解这种服务策略，Oracle公司毕竟要将最主要的研发技术力量放在最新的产品设计和开发之中，如果要兼顾老版本的技术支持，必将投入更多的技术资源，向客户收取额外服务费用也是可以理解的。

总之，为得到Oracle最强有力的技术支持，享受IT技术最新发展成果，也是为了提高客户在服务方面的投入产出比，Oracle公司还是强烈推荐客户能积极、稳妥地实施数据库升级操作，尽量采用Oracle数据库最新版本。

Oracle升级方法论（GSDK）介绍

GSDK概述

Oracle公司在总结历年为全球各行业广大客户实施数据库升级项目过程中，提炼出了一套结构化实施方法：Upgrade Service Global Service Delivery Kit (GSDK)。GSDK方法论详细定义了用于实施数据库升级的所不可缺少的步骤和任务。GSDK是一组预定义好的、在整个数据库升级项目中起指导作用的、可用多种方法管理的实施步骤。GSDK可以帮助我们解决诸如如何正确评估现有现状、如何制定升级计划、如何组织升级测试、如何具体组织实施升级、如何制定各种回退计划、如何防范各种可能存在的风险、如何合理使用新版本功能、如何解决应用软件兼容性、如何解决与其它系统软件平台兼容性等比较棘手的问题。

以下是GSDK的示意图：

即根据GSDK方法论，升级项目将分为计划、转换、优化等不同阶段，并在每个阶段完成相应的工作内容。

升级项目涉及的主要内容

根据ACS总结多年运用GSDK实施升级项目的经验，升级项目通常应包括如下四大类主要内容：

• 数据库升级技术方案

如何根据现有系统运行状况，特别针对升级需求进行深入分析，合理运用Oracle各种相关技术，设计合理的升级技术方案，并制定缜密的实施计划，是升级项目最核心的工作内容。

本章下面就是针对某客户系统现状和升级需求分析，初步制定的若干种升级技术方案。详细的技术方案限于篇幅，就不在本书一一展开了。

• 应用性能管理和优化

根据Oracle公司的总结，数据库系统升级的大量实践表明：90%问题并不是升级技术方案本身，而是升级之后的应用软件稳定性，特别是性能问题。

如何在11g升级过程中，制定合理的应用性能管理和优化方案，并加以有效实施，同时有效运用11g性能管理和优化相关新技术，将是升级项目的重要工作内容。下面还将专题讨论性能问题。

• 11g新特性运用

Oracle 11g R1和11g R2版本推出了大量新特性和新技术，为设计和开发更高质量的IT系统提供了良好的技术基础。但是，凡事都有利弊，在ACS升级11g和实施11g的项目中，几次出现问题，均与11g若干新特性相关。例如：

• 在某移动公司升级到1.0.7项目中，出现严重的资源消耗过高的问题，则与11g R2的auto space advisor特性出现Bug相关。
• 在某银行升级到2.0.3项目中，部分语句因为11g R2的SQL tuning advisor特性产生了不良SQL Profile，从而导致执行计划变异，最终导致性能下降，资源消耗过大。

可见，如何制定合理的11g新特性运用策略，有效规避新特性带来的风险，将是升级项目需要充分考虑的重要方面。

• 架构整合服务

多年来，国内外大多数行业在IT系统建设中，由于各种技术、业务等方面原因，建设了大量相对独立的，类似于如下竖井式的IT系统：

即大多数IT系统均为专有的硬件和软件，每套系统运行单一应用。这种架构之下，系统之间的软、硬件资源通常没有共享，导致每套系统均为最高峰值而配置，不仅投入成本高，而且难于扩展，运行维护成本也居高不下。

为有效解决现有IT系统的上述问题，Oracle公司以云计算为理念，提供了如下的云计算基础架构环境：

即在存储、数据库和应用服务器等不同层面均提供了资源共享池技术基础架构，从而打破了现有IT系统之间相对隔离的状态，不仅具有了资源共享能力，而且具有快速供应能力、灵活的伸缩性和集中监控管理等。

Oracle在11g R2中更是提供了若干针对性的技术，例如：RAC中Service技术的增强、基于策略的RAC管理技术（Policy-managed Oracle RAC）、网格即插即用技术(Grid Plug and Play)、资源隔离（Instance Caging）技术等。

建议客户利用11g升级项目，对现有系统进行一次全面调研，并有针对性地合理制定架构整合方案，运用11g相关技术，将若干系统进行有效整合，从而全面提高系统的资源利用率、降低 IT系统的建设和运行维护成本。

现状及升级改造需求分析

以下我们对某银行数据库现状及升级改造需求进行分析。

系统现状

通过与该银行相关人员的沟通，以及参考 Oracle ACS历年来的相关服务实施报告，我们初步了解该银行Oracle数据库状况如下：

• 主要硬件平台为IBM AIX和HP 平台
• 大部分为RAC系统，数据库版本为2.0.4。
• 存储设备有EMC和HDC两种，采用裸设备技术。
• 备份策略主要采用RMAN + Veritas。
• 大部分没有采用容灾系统。个别系统采用了Data Guard，较重要的系统采用了磁盘镜像技术。

升级需求分析

通过与该银行升级项目组的初步交流，客户对Oracle数据库升级总体需求如下：

• Oracle数据库升级目标版本为11g R2最新版本。例如：2.0.3。
• AIX平台将采用到1。HP平台将采用11.31。
• Oracle数据库存储技术将由现在的裸设备迁移到ASM技术。
• 大部分系统将迁移到新采购的存储和主机上，但也会有少量原地升级的系统。
• 跨平台迁移的系统不多，但部分HP PA平台需要迁移到HP IA平台。
• 全面升级之后，应保持AIX、HP UX、Oracle、WAS、CICS等软件版本之间的兼容性，对应用程序的影响应降至最少。
• Oracle数据库升级时间窗口应尽可能短。每套系统的具体时间窗口,将根据系统重要性、环境等情况而定。
• 升级过程应具有良好的回退方案，以防万一升级失败，能回退到旧系统，最大限度降低对外服务的影响。回退时间窗口，同样将根据具体情况而定。

 升级和迁移技术方案

升级方案1：数据逻辑迁移

• 方案要点

该方案的主要思路是部署新生产环境，包括安装11g R2软件并创建基于ASM的数据库，然后通过Data Pump或Exp/Imp技术，将现有10g R2数据库数据，加载到11g R2数据库之中。

方案示意图如下：

• 在新生产系统服务器上安装11g R2软件，并创建基于ASM的数据库
• 通过Data Pump或Exp/Imp技术，将现有10g R2数据库数据，加载到11g R2数据库之中。
• 方案优点
• 跨平台、跨版本
• 相比后续技术方案，该方案技术难度低。
• 通过数据导出/导入，可有效进行数据库碎片整理，降低数据库容量，提高新库的访问效率。
• 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。
• 方案缺点
• 在数据逻辑迁移期间，虽然现有生产系统没有停机，但为了保证数据逻辑完整性和一致性，现有数据库将停止对外服务。时间长短，取决于数据库容量。针对TB级数据库，预计很难满足升级时间窗口需求。
• 如果在应用层面设计逐次导出/导入方案，复杂度和实施难度较高。

升级方案2：原地升级

• 方案要点

该方案的主要思路是在现有生产环境部署新的存储设备，并创建10g ASM磁盘组，然后通过RMAN相关技术，实现裸设备到ASM的复制和切换，最后再升级为11g R2数据库。

方案示意图如下：

• 在现有数据库服务器上安装11g R2软件
• 增加与现有存储资源相当的新存储资源，并在现有10g R2环境下创建ASM磁盘组。
• 通过RMAN的如下典型命令，完成裸设备到10g R2 ASM的整库迁移：

CONNECT TARGET
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM 'filename_of_old_control_file';
ALTER DATABASE MOUNT;
BACKUP AS COPY DATABASE FORMAT '+DATA';
SWITCH DATABASE TO COPY;
RECOVER DATABASE;

也可在表空间级进行裸设备ASM的迁移，详细命令略。

同样地，也可在表级或分区表级进行裸设备ASM的迁移，即先创建基于ASM磁盘组的表空间，再通过“Alter table <表名> move tablespace <基于ASM磁盘组的表空间>”或“Alter table <表名> partition <分区名> move tablespace <基于ASM磁盘组的表空间>”方式，逐表进行迁移。

• 在11g R2环境下，对2.0.4的ASM数据库启动升级脚本，完成最终升级操作。
• 原有2.0.4的裸设备资源可释放。

另外，也可采取如下类似方案：

• 先在现有2.0.4环境启动升级脚本，升级到11.2.0.3。
• 再通过RMAN操作，完成裸设备到ASM的整库迁移。
• 方案优点
• 只需要增加磁盘资源，不需要新增小机资源。
• 相比后续技术方案，该方案技术难度略低。
• 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

• 方案缺点
• 生产系统需要在停机情况下升级操作系统软件、数据库软件、中间件和其他系统软件，操作时间和影响对外服务时间长。例如整库迁移到ASM，可能耗费数小时，很难满足停机时间窗口需求。
• 根据该银行的运行维护规定，提前连接磁盘属于生产变更，可能会影响生产系统运行。

升级方案3：表空间传输

• 方案要点

该方案使用表空间传输（TTS）技术，将10.2.0.4的表空间直接挂载到11g数据库上，实现数据库的升级。TTS不仅支持跨数据库版本，10g后还支持跨平台迁移，是一种高效的实现数据迁移的方案。

方案示意图如下：

该方案总体步骤如下:

• 在新生产系统安装2.0.3软件和数据库
• 在源库和目标库创建directory，用于存放dump文件
• 将源库的应用表空间设置成read only方式
• 使用expdp导出源库应用表空间的metadata信息（不包含实际的数据），通常只有几兆的数据
• 将metadata和应用表空间对应的datafile传输或远程复制到新的主机
• 使用impdp将表空间metadata导入11g数据库，把datafile直接挂载到11g数据库。
• 把源库和目标库的表空间改成read write方式

该方案将使用裸设备到ASM文件的转换技术。

• 方案优点
• 方案相对简单，步骤较少。
• 需要增加磁盘资源，不需要新增小机资源。
• 相比后续技术方案，该方案技术难度略低。
• 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。
• 方案缺点
• 在测试和验证过程需要将生产系统表空间改成read only，对生产系统的使用有影响。
• 网络文件传输的速率决定了整体升级的时间，如果速度很慢，升级时间将大大增加，需要在测试环境搭建好以后，先测试网络文件传输效率。
• 裸设备到ASM文件的转换技术较为复杂。

升级方案4：Data Guard方案

• 方案要点

该方案需要先部署新生产环境，并通过10g Data Guard在新生产环境部署现有生产系统的容灾数据库。在正式升级过程中，将容灾库切换为生产库，再通过运行升级脚本，将10g R2数据库升级到11g R2数据库。

方案示意图如下：

• 首先需要部署不低于现有生产系统环境的新生产系统环境，包括主机和存储资源。
• 在新生产环境服务器上安装2.0.4和11.2.0.3软件
• 在不影响现有生产系统情况下，通过10g Data Guard技术在新生产环境服务部署现有生产环境的容灾数据库，并采用ASM技术。
• 在正式升级时间窗口，通过Data Guard的Switch over操作，将新生产环境的容灾库切换为生产库。
• 在新生产环境启动2.0.3系统，并mount 新生产库，启动升级脚本，完成最终升级操作。
• 方案优点
• 总体升级时间短

该方案在搭建Data Guard时，不需要生产系统停机。在正式升级时，Switch over操作为分钟级，而升级脚本的运行与数据库容量无关，而只与数据字典大小相关。根据Oracle实施经验，该方案总体升级时间窗口约2-3小时。

• 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

• 方案缺点
• 需要额外新增小机资源
• 相比第一种技术方案，该方案技术难度略高。

升级方案5：PPRC + Golden Gate方案

• 方案要点

该方案综合运用PPRC磁盘镜像技术、GoldenGate等技术。首先通过PPRC创建中间库，然后通过Data Pump技术将数据加载到新生产系统，再通过GoldenGate实现现有生产库和新生产库的数据同步，并最终一次性进行割接。

该方案最大优点是几乎可以零停机方式，实现数据库的升级。方案示意图如下：

• 该方案需要部署中间库环境，包括安装2.0.4软件。其存储设备与现有生产系统必须同等型号，但主机资源可低于现有生产系统，例如单机环境即可。
• 该方案还需要部署不低于现有生产系统环境的新生产系统环境，包括主机和存储资源，并安装2.0.3软件和ASM数据库。
• 通过磁盘镜像技术（PPRC）构造与生产系统相同的2.0.4中间库。
• 在中间库进行Data Pump卸载之前，记录中间数据库的时间点（timestamp），或者SCN，或者Log file sequence
• 将中间库数据进行Data Pump卸载（expdp）之后，再将数据通过Data Pump加载(impdp)到新生产环境的2.0.3之中。
• 再通过GoldenGate技术，从现有生产库的指定时间点（timestamp），或者SCN，或者Log file sequence开始，将现有生产库数据同步到新生产环境的2.0.3之中。这样，现有生产库与新生产环境数据将逐渐保持一致。
• 只需要GoldenGate将生产系统所有日志同步到目标库之后，即可进行正式割接。
• 方案优点
• 总体升级时间最短

该方案在通过PPRC搭建中间库，以及实施GoldenGate时，几乎不需要生产系统停机。因此，该方案总体升级时间最短，几乎可以做到零停机。

• 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

• 方案缺点
• 需要额外新增中间库和新生产环境两套资源
• 需要硬件厂商参与该方案的设计和实施
• 相比前面几种技术方案，该方案技术难度最高

GoldenGate实施有若干技术限制，需要结合具体系统情况，充分加以论证。

升级方案6：RMAN + Golden Gate方案

• 方案要点

该方案综合运用RMAN、GoldenGate等技术。该方案首先在新环境搭建10g ASM环境，然后通过RMAN将现有生产系统数据恢复至新环境，并记录下日志序列号。然后将新环境升级到11g，并通过GoldenGate技术保持数据同步，最终通过切换完成升级和迁移。

方案示意图如下：

• 该方案需要部署新生产环境，包括分别安装2.0.4、 11.2.0.3软件，并部署ASM。
• 首先，通过RMAN技术，将现有生产系统数据库恢复到新生产环境的2.0.4的ASM数据库中，同时记录下RMAN最新恢复的日志序列号。
• 其次，在新生产环境通过手工运行升级脚本方式，将该库升级为2.0.3
• 然后，在通过GoldenGate技术，从现有生产库的指定日志序列号开始，将现有生产库数据同步到新生产环境的2.0.3之中。这样，现有生产库与新生产环境数据将逐渐保持一致。
• 只需要GoldenGate将生产系统所有日志同步到目标库之后，即可进行正式割接。
• 方案优点
• 总体升级时间最短

与方案5相似，该方案总体升级时间最短，几乎可以做到零停机。

• 节省资源

相比方案5，可以不需要中间库的主机和存储资源。

• 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

• 方案缺点
• 生产系统需要更多存储空间，保留RMAN恢复期间和11g升级期间的归档日志。
• 相比方案5，由于采用了RMAN技术，因此不支持跨平台。
• 相比前面几种技术方案，该方案技术难度也较高。
• GoldenGate实施有若干技术限制，需要结合具体系统情况，充分加以论证。

方案总结和建议

以下是上述五种方案的对比和总结：

根据上述综合分析，我们建议如下：

• 如果数据量不大，或者停机时间窗口允许，可选择数据逻辑迁移、原地升级或表空间传输。
• 否则，建议考虑Data Guard方案、PPRC + Golden Gate方案、RMAN + Golden Gate方案。
• 如果跨平台，还不能选择Data Guard方案和RMAN + Golden Gate方案

19.6 升级中的性能优化和性能管理

性能问题需特别关注

作为Oracle中国公司专门从事数据库升级工作的ACS服务团队，我们对性能问题感同身受。例如在某移动公司的升级过程中，由于我们在设计阶段充分调研分析了系统现状和升级需求，精心设计了4套升级技术方案，并经过充分演练，基本保证了升级操作本身的顺利完成。但在升级投产之后，性能问题就开始显现，如执行计划更改、优化器更改、游标问题等导致的性能下降。深入分析，无外乎以下三类原因所导致：

• 原有应用软件就存在性能问题，在新平台不仅不可能直接得到改进，而且显现得更加明显。
• 原有应用运行在RBO模式，在10g/11g中被强制运行在CBO，而导致应用执行计划出现不良变异。
• Oracle某些新特性方面存在Bug。例如Bind变量的Peeking功能。

上述问题其实都可以通过在测试阶段，加强应用软件的压力测试而得到有效解决。

如何降低升级过程中的性能风险

• 项目组织和投入

首先，建议在升级过程中，关于性能问题可能带来的风险，能引起相关部门领导和技术负责人的重视，并在项目组织和投入方面能给予充分考虑。例如，在项目计划中能将应用软件兼容性测试和压力测试，作为单独的任务项，并安排相关资源和环境进行充分测试。特别是需要应用开发商进行资源投入和配合工作。

下面章节关于实施建议方面，给出了更详细的项目周期、项目组织、资源投入、职责等方面的详细建议。

• 现有应用软件进行必要的优化

应用软件的优化是一项长期而艰巨的任务。由于时间和资源的关系，我们不可能在升级项目过程中解决所有性能问题，但我们建议在升级项目的应用软件测试过程中，将一些不涉及整体架构，或者不需要进行应用软件大幅度改造的问题，尽可能加以优化，避免在新平台重现这些问题，甚至引发其它问题。

• 采用11g的性能优化管理新技术

为保证应用软件在升级前后的稳定性，建立合理采用如下的11g性能优化管理新技术：

1. SQL Performance Analyzer

以下是SQL Performance Analyzer的流程图：

 
即首先在生产环境捕获所关注的SQL语句，并存储在SQL Tuning Set(STS)中；然后将STS传输到测试环境中；在变更之前的测试环境下，先运行STS，并记录性能基准指标；测试环境实施变更，例如数据库升级；再运行STS，并记录变更之后性能指标；最后SPA将产生相应的性能对比分析报告， 包括性能无变化报告、性能提高报告、性能衰减报告。SPA可结合SQL Tuning Set(STS)、SQL Tuning Advisor和SQL Plan Management等工具和技术，对存在性能衰减的SQL语句直接给出优化建议。

SPA目前可支持9i、10g到11g的升级。SPA技术可为升级过程中所特别需要关注的SQL语句性能管理，提供有效的分析和诊断手段。

1. SQL Plan Management

SQL Plan Management（SPM）是Oracle 11g最新推出的保证SQL语句执行计划稳定性，以及性能整体稳定性的新技术。SPM通过自动维护SQL语句执行计划历史记录，并确保优化器每次选择代价最低的执行计划，来保证应用性能稳定性。

数据库升级、开发测试环境到生产环境的应用迁移等场景下，SPM具有良好的应用空间。例如，以下就是在数据库升级场景下，SPM的应用示意图：

即首先在现有生产环境，通过上述SPA工具的使用，捕获典型业务周期的SQL语句，形成STS包。然后将STS包传输到新的11g数据库之中，并将这些语句执行计划形成Baseline。

在新的11g环境运行时，Oracle可能形成新的执行计划，优化器自动进行比较：如果性能更好，则选用新执行计划，否则，继续沿用现有的从10g传输过来的Baseline执行计划。

这样，通俗地讲：通过SPA和SPM的综合使用，可保证11g环境下的相同语句可能运行性能更好，但不可能低于10g的运行效率，从而保证了运行性能不会出现衰减。

升级项目的实施和组织

针对该银行的大规模升级项目，建议成立专门的项目组来开展此次11g测试及升级服务方案设计工作，该项目组由XX银行、Oracle公司，以及其它方面专家共同组成。

上述人员的主要职责如下：

说明如下：

• 上述组织结构没有包括Oracle公司销售经理、服务实施经理（SDM）等人员，其职责应包括与各方资源的协调、Oracle团队的资源管理和协调、参与项目总体方案的评审、项目确认和验收等方面工作。
• 由于此次11g测试及升级方案研究工作，涉及硬件服务器、操作系统、数据库、中间件等各个层面的升级，因此上述项目组织结构还应该包括中国建设银行负责上述其它层面的技术人员，并在必要时得到上述其它产品的原厂商技术支持。

升级风险评估控制

在这里，我们分析一下升级本身可能遇到的风险及相应的规避方法。从风险定义来讲，是由于不确定因素导致的损失。对于数据库升级项目，如果我们能够从技术和实施两方面充分考虑到各种可能的不确定因素，采取有针对性的规避方法，就可以把风险降到可控范围或完全消除风险。

关于硬件、网络和软件的风险

升级中的风险及规避方法

升级后的风险及规避方法

人员的风险

项目范围和项目管理的风险

有感于某移动公司的升级案例

2013年8月间，某移动公司在一个晚上成功实施了CRM、账务、计费、渠道等7套核心数据库的11g升级操作，在业界产生了不小的影响。虽然本人没有参与该项目，甚至从未为升级项目而亲临过客户现场，但从客户和Oracle同事们提供的各种讯息和资料中，还是对该项目的整体情况有了基本了解。因此，作为旁观者，本人也冒昧在本书发表一些感悟如下，供大家参考。

回顾当年10g的升级

温故而知新。首先，回顾一下该移动客户当年10g的升级。2007年至2008年间，该客户曾经实施了9i到10g的大规模升级项目。当年该升级项目不仅对客户而言是吃螃蟹的头一遭，而且对Oracle服务团队而言，也是第一次在国内全面、系统地提供升级服务。好在作为全球化公司，我们有GSDK这样的全球升级方法论的指导，因此从项目组建设、项目规划、升级技术方案、测试计划、上线割接方案、上线后支持等，Oracle实施团队都提出了较为全面的方案和实施计划。

例如，在升级技术方案方面，我们团队就针对客户数据库实际情况，提出了“有容灾并迁移主机的升级和割接方案”、“有容灾无迁移主机的升级和割接方案”、“无容灾的升级和割接方案”、“其他升级和割接方案”等4种方案及相应的回退方案。

在测试方面，我们也根据GSDK方法论，强调了应用软件兼容性和性能稳定性测试的重要性，甚至采用了当时刚刚推出的SPA技术进行9i和10g不同平台的性能对比测试。

但是，当年本人曾经去客户现场，与实施该项目的同事进行交流时才了解到：因为缺乏经验的缘故，无论是客户、开发商，还是Oracle自身对升级项目的艰巨性和风险性都认识不足，具体表现就是投入明显不够。Oracle现场实施人员其实就1-2位，开发商更是几乎没有太大投入。虽然升级方案本身设计比较全面，在具体实施中也比较顺利，但升级之后却多次出现Oracle Bug、Oracle 10g新特性运用不当、SQL语句执行计划变化而导致性能衰减等问题。究其根本原因，就是在升级项目中的应用软件测试、10g新特性运用等工作量不够所导致。

总之，该移动客户当年虽然成功实施了9i到10g的升级项目，但却是一路坎坷、一路震荡之后，才逐步达到平稳运行状态的。

有感于11g的升级

首先，感谢和钦佩该移动客户领导和技术人员敢于接收挑战和新技术的勇气和魄力。当然，也是为满足业务发展需求，提高IT系统稳定性，同时充分采用最新的数据库技术，2013年该移动客户再次启动了10g升级到11g的项目。有了9i到10g升级的经验教训，此次升级项目客户明显加大了各方面的投入，以下就是客户专门为此次升级项目而组建的项目组结构：

在升级项目实施内容方面，更是几乎涵盖了GSDK方法论建议的每个方面和步骤。在升级方案方面，其实相比当年的10g方案更为简捷，即通过硬件磁盘镜像容灾环境，先原地升级容灾系统，并将容灾中心切换为生产系统，然后重新复制数据到原生产系统，并切换回原生产系统。

相比10g升级项目，此次11g升级项目最大的加强应该是应用软件的性能对比测试，以及11g新特性的运用策略分析。例如，通过11g SPA技术，连续一个月在某10g生产系统进行SQL语句捕获，并在11g测试环境进行回放。据介绍，捕获的语句量达到42万个，而发现性能衰减的语句为450个，并最终有效解决这些性能衰减问题。

在一个晚上成功实施7套核心系统的升级，并在割接之后，没有出现一个性能衰减、Oracle Bug问题，真是一个不小的奇迹！本人事后得到整个项目实施计划，才知道为了这一个晚上的成功，局方、Oracle实施团队、开发商、第三方测试团队等共同艰辛努力了半年多。其中， Oracle实施人天就达到700多。

成功升级之后的某天，本人与该项目的Oracle实施经理沟通时，我问他：“你觉得，这次升级项目投入最大、效果最好的是哪个技术环节？”，他的回答非常简捷：“ SPA！”—— 这就是一线实施人员的宝贵经验！

本章参考资料及进一步读物

本章参考资料及进一步读物：

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

Oracle集群数据库RAC（Real Application Cluster）自Oracle公司在2001年 9i版本推出以来，经过10g、11g和最新的12c等多个版本的发展，产品已经得到不断发展和稳定，尤其在国内银行、电信、政府、制造等诸多行业得到了广泛、深入的应用。

但是，作为保障数据库系统高可用性的重要产品，却时常出现宕机、挂起等故障。究其原因，与RAC自身版本和补丁、主机和操作系统环境、网络环境，以及与应用等多方面都有关系。

如何遵循Oracle公司RAC实施方法论和最佳实践经验，合理组织RAC的实施，确保RAC运行的稳定性，同时充分发挥RAC在性能、扩展性等方面的作用，是本章的宗旨。

本章将结合一些具体案例来叙述RAC实施方法论和最佳实践经验，并在RAC高可用性、RAC运维管理等领域展开一些深入介绍，希望能给大家在RAC实施过程中起到抛砖引玉的作用。

客户哑口了

某典型故障

某日，我接到某移动公司DBA发过来的邮件，描述了其RAC数据库两次出现宕机的情况。邮件要点如下：

• 系统环境

某关键业务系统运行在 IBM AIX 5.3，数据库为两节点10.2.0.4.12 RAC环境，存储技术采用裸设备，即采用IBM HACMP软件。

• 故障现象及初步原因分析

在5月8日和6月20日由CRS发起了主机重启，从数据库的日志来看， vote disk心跳超时导致重启的，但是从主机上看，当时系统并未发现异常。由于本次重启，在主机侧未发现任何异常，IBM主机工程师认为是当时主机繁忙，在短时间内未响应，导致数据库误认为主机已经异常或者HANG住了。

IBM工程师进一步分析由于HACMP和Oracle Clusterware心跳检测参数设置不匹配，是导致宕机的一个重要因素。其中HACMP心跳检测参数为600秒，而CRS缺省为30秒。

即IBM工程师认为是Clusterware检测参数设置过小，导致Clusterware过于敏感了，应用软件压力大点，Clusterware在30秒中未检测到对方心跳，就以为对方宕机或 HANG住了。

• 初步解决方案

为了避免此问题，IBM公司的ORACLE数据库工程师建议将misscount的值改动到大于HACMP的心跳超时的值。这样的话，一旦主机有问题将由HACMP进 行重启，不会由数据库来发动重启，而且在他们实施的案例中，修改过这个参数之后，这个问题就避免了。

• 客户提出的问题

如果修改这个参数的值 为600秒，会导致数据库出现什么问题，从经验来看，该值一般设置为多大合适？

Oracle官方建议

仅分析上述邮件内容，就感觉该问题涉及的层面比较多，既可能与应用压力过大相关，也与HACMP和Clusterware底层参数设置相关，更与整个系统架构相关。为此，我首先在Metalink中查询了好几篇关于CSS参数设置相关的文档，特别是《CSS Timeout Computation in Oracle Clusterware [ID 294430.1]》。在此文档中，Oracle总体建议是谨慎调整MISSCOUNT参数。例如，在该文档的“CONSIDERATIONS WHEN CHANGING MISSCOUNT FROM THE DEFAULT VALUE”一节中，特别指出：

“
… …
5. An increase in misscount to compensate for i/o latencies directly effects reconfiguration times for network failures. 
The network heartbeat is the primary indicator of connectivity within the cluster. Misscount is the 
tolerance level of missed 'check ins' that trigger cluster reconfiguration. Increasing misscount will prolong 
the time to take corrective action in the event of network failure or other anomalies effecting the availability of a node in the cluster. 
This directly effects cluster availability.
… …
7. Do not change default misscount values if you are running Vendor Clusterware along with Oracle Clusterware. 
The default values for misscount should not be changed when using vendor clusterware. 
Modifying misscount in this environment may cause clusterwide outages and potential corruptions.
… …
”

可见，第5条大意是指调高misscount，一旦网络出现故障，会增加集群重组的时间，重组时间越长，将影响集群高可用性。

第7条更是明确说明，当Clusterware与HACMP等操作系统厂商的集群软件混用时，建议不要修改misscount缺省值，否则会导致集群宕机等严重故障。

另外，针对该问题，Oracle技术支持部门在SR 3-7483242251、SR 3-7412760111中也明确指出misscount值不建议进行修改。其中一个理由是misscount值调大，甚至超过HACMP设置的600秒，HACMP其实并不能有效检测出心跳故障，反而增加 RAC运行风险。

我的远程分析和建议

Oracle官方建议既然如此，那客户系统宕机原因究竟何在，又如何解决呢？由于在远程无法得到进一步信息，于是，我提出了如下更进一步建议：

第一，如果如IBM工程师所言，由于应用压力过大，导致心跳无法正常检测，最终某个节点重启。那么，对应用进行专题和持续的优化才是解决该问题根本。

第二，系统目前的技术架构是：IBM HACMP + 10g Clusterware + 10g RAC。建议考虑升级到11g，并采用 11g GI(Clusteware + ASM) + 11g RAC的技术架构。针对该问题的好处是不再涉及IBM HACMP，技术架构更简洁，问题也更容易诊断，而且在某些平台如LINUX等，misscount参数不再需要设置。

第三，不知道XX移动10g RAC当年实施的详细情况。如果按照Oracle公司的RAC实施方法论，我们Oracle服务团队会提供更专业的RAC实施，例如在RAC最佳实践经验中，我们会针对不同平台提供各种参数的合理配置，包括操作系统、网络、存储、Clusterware、数据库初始化参数等。

客户当场哑口了

就在我们和客户通过邮件沟通后不久，我们参加了客户组织的由多方人员参与的问题讨论会。在会上，我们首先了解到其实两次宕机时，数据库服务器的压力并不是很大，排除了先前分析的是由于应用压力过大，导致Clusterware无法检测到心跳，而最终导致宕机的原因分析。

接下来，几方又回到是否调整Clusterware的misscount参数进行讨论了，我们Oracle技术人员坚持Oracle官方的建议，即保持缺省值为30秒，而IBM工程师则说根据他们的实施经验，应该调大，避免Clusterware检测过于敏感。

就在几方相持不下，各持己见时。忽然间，不知道是谁问了客户，你们心跳线是直连的，还是经过交换机？客户回答：直连的。哇，Oracle技术人员一下炸开了锅： Oracle 10g以后版本不支持心跳线直连了！

我也在一旁为自己的先见之明而暗自得意，我回复邮件的第三条不就是在怀疑客户可能没有遵循Oracle RAC最佳实践经验吗？喏，以下就是在《RAC: Frequently Asked Questions [ID 220970.1]》中，Oracle关于不支持心跳线直连的官方回答和原因解释：

“Is crossover cable supported as an interconnect with RAC on any platform ? 

1.  CROSS OVER CABLES ARE NOT SUPPORTED. The requirement is to use a switch: 

Detailed Reasons:

1) cross-cabling limits the expansion of RAC to two nodes

2) cross-cabling is unstable:

1. a) Some NIC cards do not work properly with it. They are not able to negotiate the DTE/DCE clocking,

2. and will thus not function. These NICS were made cheaper by assuming that the switch was going to have the clock. Unfortunately there is no way to know which NICs do not have that clock.

3. b) Media sense behaviour on various OS's (most notably Windows) will bring a NIC down when a cable is disconnected.

4. Either of these issues can lead to cluster instability and lead to ORA-29740 errors (node evictions).

”

总之，这是Oracle官方根本不支持的配置，不用再对上述内容进行翻译和详细解释了。出了问题，Oracle公司当然没有责任和义务进行分析和解释。客户这下子彻底哑口了。估计当年RAC安装实施的时候，可能没有在环境准备、网络配置等方面进行深入细致的研究和部署，也没有全面研究Oracle RAC有关最佳实践经验。

现在怎么办？赶紧将私网线由直连改成通过交换机进行连接吧。客户DBA又一次有苦难言，原因是网络配置是网络部规划的，现在交换机端口都插满了，需要增加交换机并进行级联，DBA需要协调更多部门和资源进行调整。DBA最后无奈地说：“不搞了，再撑几个月吧，反正系统要迁移到新服务器，并升级到11g了，但愿这几个月不再出事了吧。”大家在一片笑声中一哄而散了。

RAC实施方法和实施内容

本章以上述案例作为开篇，并非要刨根问底地深究HACMP和Clusterware的心跳检测参数的内部细节，而是想说明RAC实施方法和最佳实践经验的重要性。的确，作为Oracle数据库最高端产品的RAC系统，一方面给客户IT系统，特别是数据库系统的高可用性、高性能、可扩展性提供了良好的技术基础架构，另一方面，由于其自身多个技术层面的复杂性，特别是对操作系统、网络等环境要求较高 ，因此RAC本身也成了一个高贵而脆弱的东西，也成了客户经常诟病的对象：“我们使用你们RAC本来是保障高可用性的，没想到你们RAC自己这么娇气，动不动就宕机了。”

如何高质量地实施Oracle RAC架构，并降低运行风险呢？遵循Oracle公司官方提出的RAC实施方法和最佳实践经验，就是一条确保成功的有效途径。

Oracle 11g RAC实施解决方案是一种面向Oracle RAC客户群体的高级客户服务，提供从设计，安装、配置、优化，运维支持以及技能传授等服务。通过对用户的系统数据库和应用环境的深入了解，以及专业的技术应用，Oracle的11g RAC实施解决方案可以帮助用户提高关键业务系统的高可用性、高扩展性，高效、稳定地提供关键业务服务。Oracle在RAC系统实施管理生命周期各个阶段提供不同的服务协助用户高效的管理 11g RAC系统。主要服务内容包括：

• 11g RAC实施方案总体规划
• 11g RAC数据库系统设计
• 11g RAC环境搭建和配置
• 11g RAC系统综合测试
• 11g RAC系统上线支持协助
• 11g RAC系统管理技能传授
• 11g RAC系统性能优化支持
• 11g RAC系统健康检查和问题诊断解决

RAC实施方法论已广泛地为Oracle国内外客户所采用和实践，并在实践中不断得到丰富和发展。对加快项目实施，同时可减少项目实施风险起到了非常好的指导作用。其主要流程和内容如下：

下面我们将基于Oracle RAC实施方法论，并结合某案例，介绍RAC一个重要特性：高可用性方案的设计和测试。

18.3 11g RAC高可用性方案设计

RAC高可用性相关概念

Oracle RAC 11g 提供了实现数据中心高可用性的基础架构。在其基础架构中，具有多种涉及高可用性、负载均衡能力等方面的技术。下面先简要介绍这些技术，再结合XX项目具体需求，分别设计不同的高可用性方案。

• Client Connect-Time Load Balance

客户端连接负载均衡（Client Connect-Time Load Balance）是指在RAC中，客户连接请求在多个协议地址表中随机地选择Listener，在RAC的多个Listener中实现连接负载均衡的特性。

在TNSNAMES.ORA中设置如下参数：

load_balance=on

如果load_balance=off，则Oracle Net在多个协议地址表中顺序选择Listener，直至连接成功。

• Client Connect-Time Failover

客户端连接故障切换（Client Connect-Time Failover）是指在RAC中，当客户连接请求在连接到第一个Listener失败之后，再连接到其它Listener的特性。协议地址表中Listener个数决定了Oracle Net连接失败再尝试的次数。

在TNSNAMES.ORA中设置如下参数：

Failover=on

缺省值为on。如果Failover = off，则Oracle Net只对一个Listener进行连接。

• Server Connect-Time Load Balance

服务器端连接负载均衡（Server Connect-Time Load Balance）是指在RAC中，在多个Instance或Dispatcher中再进行连接负载均衡的特性。

如果采用Dedicated Server模式，Oracle通过如下顺序选择Instance：

1. 负载最轻的节点。
2. 负载最轻的实例。

如果采用Shared Server模式，Oracle通过如下顺序选择Instance：

1. 负载最轻的节点。
2. 负载最轻的实例。
3. 该实例上负载最轻的Dispatcher

即Oracle通过在服务器端根据节点或实例的负载情况，例如：节点或实例的运行队列长度等，再对客户连接进行负载均衡分配，从而更合理地保证应用吞吐量和处理能力的均衡化。

服务器端连接负载均衡特性主要通过Local_Listener和Remote_Listener等数据库参数的设置，利用Oracle动态服务注册（Dynamic Service Registration）功能，加以实现。

• Transparent Application Failover(TAF)

透明应用故障切换（Transparent Application Failover，TAF）是指在RAC中，当数据库实例出现故障时，已连接到该实例的连接将被Oracle自动切换到正常实例中，并可恢复SELECT操作的特性。TAF主要由OCI提供，因此在客户端具有OCI Driver的情况下，应用将具有这种特性。

在TNSNAMES.ORA中设置如下参数：

Failover_mode

• Service概念

在Oracle 10g/11g中，可针对复杂的应用系统划分为若干服务（Service），并以服务为单位进行整个系统负载的监控和管理。

在10g/11g RAC中，可将各个服务在RAC体系结构中进行应用部署和管理。例如在正常情况下，可将某些服务分配到某个实例中（称之为Preferred Instance），在这些实例出现故障时，这些服务可连接到其它实例中（称之为Available Instance）。

另外，在Oracle的AWR中，可以服务为单位进行性能的监控分析，更有效地进行应用的性能管理。在Resource Manager中，也可以服务为单位进行资源的细粒度分配，能更合理地有效利用系统资源。Oracle的其它工具和产品，例如Oracle Scheduler, Parallel Query, and Oracle Streams Advanced Queuing等均能有效地运用Service概念，进行系统负载的管理工作。

• 单一客户端访问名称SCAN

11g提供了新技术：SCAN。SCAN提供了一个固定的客户端访问名，当RAC增加或者调整某些节点时，客户端无需进行任何变化，从而简化了客户端配置。

XX系统高可用性方案设计

根据 XX客户对RAC实施的总体需求，并结合XX系统的上述特点， XX系统RAC高可用性方案的示意图如下：

• 不进行SCAN方案设计

由于各系统目前均采用2节点RAC，而且没有配置域名服务器，因此，建议暂时不采用11g的新技术：SCAN。

• 不进行Service方案设计

由于XX项目确定每个应用系统直接部署在一套两节点的RAC环境之中，这样每套RAC系统业务比较单一，因此暂时不考虑Service的设计。

• 负载均衡设计

不采用Client Connect-Time Load Balance、Server Connect-Time Load Balance策略。即在客户端和服务端两级都不进行负载均衡设计。

针对XX应用系统，由于卡表按卡号进行HASH分区，因此应用开发中将通过分析Oracle HASH算法，来选择连接的Oracle实例，有效实现负载均衡，并降低数据访问冲突。

• Client Connect-Time Failover配置

配置Client Connect-Time Failover。确保在某个节点出现各类故障时，新连接请求能Failover到未失效节点。

• TAF配置

配置Transparent Application Failover(TAF)。确保在某个节点出现各类故障时，支持TAF应用的现有连接能Failover到未失效节点。但Oracle不支持JDBC Thin Driver方式程序的TAF。

RAC高可用性方案配置

根据上述方案思路，相关配置如下：

• tnsnames.ora配置

ABROADDB_PERSON =
 (DESCRIPTION =
 (LOAD_BALANCE = off)
 (ADDRESS = (PROTOCOL = TCP)(HOST = p570l0502-vip)(PORT = 1521))
 (ADDRESS = (PROTOCOL = TCP)(HOST = p570l0505-vip)(PORT = 1521))
 (CONNECT_DATA =
 (SERVER = DEDICATED)
 (SERVICE_NAME = abroaddb)
 (FAILOVER_MODE =
 (BACKUP = ABROADDB_CORPOR)
 (TYPE = SELECT)
 (METHOD = BASIC)
 (RETRIES = 180)
 (DELAY = 5)
 )
 )
 )

ABROADDB_CORPOR =
 (DESCRIPTION =
 (LOAD_BALANCE = off)
 (ADDRESS = (PROTOCOL = TCP)(HOST = p570l0505-vip)(PORT = 1521))
 (ADDRESS = (PROTOCOL = TCP)(HOST = p570l0502-vip)(PORT = 1521))
 (CONNECT_DATA =
 (SERVER = DEDICATED)
 (SERVICE_NAME = abroaddb)
 (FAILOVER_MODE =
 (BACKUP = ABROADDB_PERSON)
 (TYPE = SELECT)
 (METHOD = BASIC)
 (RETRIES = 180)
 (DELAY = 5)
 )
 )
 )

• JDBC Thin Driver连接方式

节点1的JDBC Thin Driver连接方式如下：

url="jdbc:oracle:thin:@(DESCRIPTION=
 (LOAD_BALANCE=off)
(ADDRESS_LIST=
 (ADDRESS=(PROTOCOL=TCP)(HOST=p570l0502-vip)(PORT=1521))
 (ADDRESS=(PROTOCOL=TCP)(HOST=p570l0505-vip)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME=abroaddb)))"

节点2的JDBC Thin Driver连接方式如下：

url="jdbc:oracle:thin:@(DESCRIPTION=
 (LOAD_BALANCE=off)
(ADDRESS_LIST=
 (ADDRESS=(PROTOCOL=TCP)(HOST=p570l0505-vip)(PORT=1521))
 (ADDRESS=(PROTOCOL=TCP)(HOST=p570l0502-vip)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME= abroaddb)))"

JDBC Thin Driver方式不支持透明应用切换（TAF），因此不需要进行Failover配置。

• 相关参数配置

实例1：

NAME TYPE VALUE
-------------------- ------- -------------------
local_listener string LISTENER_P570L0503
remote_listener string

实例2：.

NAME                        TYPE              VALUE
--------------------       -------            -------------------
local_listener              string            LISTENER_P570L0504
remote_listener             string

11g RAC高可用性测试

测试目的

• 通过对不同应用系统情况特点分析，制定不同的高可用性方案，为未来其它业务系统的RAC高可用性方案设计提供参考。
• 在应用系统的真实运行环境下，验证Oracle RAC体系结构对各种故障的恢复能力。
• 为客户日常运行维护提供各种故障恢复的可操作性步骤。

测试范围

根据XX项目采用11g R2 RAC的架构特点，并参考Oracle公司研发部门RAC Assurance Team的官方建议，此次高可用性测试方案，将至少包括如下案例：

测试案例

限于篇幅，我们将真实环境的测试过程列举若干如下。

SYS_05：数据库实例异常宕机

• 模拟操作测试

采用kill -9 pmon 模拟数据库实例crash

• 预期测试结果

*.inst资源将显示为offline状态。并且集群将会自动重启数据库实例

• 测量过程记录

使用第2节点测试。

kill 掉pmon 进程后 alert 日志显示如下，同时可以发现crs 理解侦测到了实例crash，并且立即尝试重启。

最终恢复后状态如下：

• 测试效果总结

数据库实例如果异常crash此时集群会自动监测到状态异常并且尝试重启，时间间隔仅为2秒左右，最终数据库实例会恢复。

CRS_01：CRSD进程crash模拟测试

• 模拟操作步骤

采用 ‘kill -9 crsd进程ID’模拟CRSD进程失效

• 预期测试结果

CRSD进程立刻被重起

• 测量过程记录

在第2节点测试

/home/grid-> ps -fe |grep crsd

root  8345     1  0  Dec 26  ?        288:08 /oracle/grid/grid_home/bin/crsd.bin reboot

grid 28160 28097  0 13:44:08 pts/0     0:00 grep crsd

/home/grid-> exit

logout

w4sd14pa:/#kill -9 8345

服务立刻重启。检查crsd.log日志，可以看到在极短时间内侦测到进程停机，crsd启动并且恢复完成

2013-01-19 13:45:52.711: [    CRSD][1] AuthLoc /oracle/grid/grid_home/auth/crs/w4sd14pa

2013-01-19 13:45:52.711: [    CRSD][1] PE active version: 11.2.0.3.0

2013-01-19 13:45:52.711: [    CRSD][1] PE Engine: NEW

2013-01-19 13:45:52.711: [    CRSD][1] Using OCR batch ops : ENABLED

2013-01-19 13:45:52.711: [ CRSMAIN][1] Creating RTI lock info…

2013-01-19 13:45:52.711: [ CRSMAIN][1] Initializing EVMMgr

2013-01-19 13:45:52.719: [ CRSMAIN][1] Getting local nodename…

[   CLWAL][1]clsw_Initialize: OLR initlevel [70000]

2013-01-19 13:45:53.081: [ CRSMAIN][1] CRSD listening on 10 style E2E port (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.200.22)(PORT=65516))

2013-01-19 13:45:53.086: [ CRSMAIN][1] Starting Threads

2013-01-19 13:45:53.086: [ CRSMAIN][1] CRS Daemon Started.

2013-01-19 13:45:53.086: [    CRSD][1] Connecting to the CSS Daemon

2013-01-19 13:45:53.087: [    CRSD][1] Local CSS Node Number is: 2

2013-01-19 13:45:53.087: [    CRSD][1] Local Css Node Name is: w4sd14pa

2013-01-19 13:45:53.087: [    CRSD][1] Initializing OLR context

2013-01-19 13:45:53.090: [    CRSD][1][F-ALGO] getIpcPath returning (ADDRESS=(PROTOCOL=IPC)(KEY=CRSD_IPC_SOCKET_11))

2013-01-19 13:45:53.090: [CLSFRAME][1] Inited lsf context 600000000167b680

2013-01-19 13:45:53.091: [CLSFRAME][1] Initing CLS Framework messaging

2013-01-19 13:45:53.093: [    CRSD][1][F-ALGO] getIpcPath returning (ADDRESS=(PROTOCOL=IPC)(KEY=CRSD_IPC_SOCKET_11))

2013-01-19 13:45:53.095: [UiServer][1] UI Comms initalize() 1

2013-01-19 13:45:53.095: [CLSFRAME][1] New Framework state: 2

2013-01-19 13:45:53.095: [CLSFRAME][1] M2M is starting…

2013-01-19 13:45:53.096: [  CRSCCL][1]clsCclInit called by process 28836: groupname=CLSFRAME commOptions=8 clusterType=0

2013-01-19 13:45:53.096: [  CRSCCL][1]Software version: 11.2.0.3.0.

2013-01-19 13:45:53.096: [  CRSCCL][1]Active version: 11.2.0.3.0.

2013-01-19 13:45:53.097: [  CRSCCL][1]USING GIPC ============

2013-01-19 13:45:53.097: [  CRSCCL][1]clsCclGipcListen: Attempting to listen on gipcha://w4sd14pa:CLSFRAME_2.

• 测试效果总结

crsd进程一旦异常，数据库集群将会自动进行修复并且重新启动，用时在0-10秒钟之内。整个数据库系统对外提供服务不受影响。

SYS_13：拔所有私网线

• 模拟操作步骤

在RAC的一个节点上，移去该节点上私用网卡的网线，模拟内网中断。

• 预期测试结果

CRS应侦测到集群分裂，节点及数据库实例将会宕机，节点将会被集群逐出。

在两节点RAC集群中，具有最小实例号的节点将继续存活。

在多节点RAC集群中，具有最大子集群的集群将继续存活。

若出现的等大小子集群，则具有最小实例号的子集群将继续存活。在11.2.0.2以前版本，Oracle将直接重新启动另外一个节点。在11.2.0.2以上版本，Oracle将启动“Reboot less Restart”功能，即在被逐出的节点上，Clusterware尝试graceful方式的shutdown。具体过程如下：

• 所有I/O相关的客户进程将被终止，并且所有资源将进行清理。如果该过程没有顺利结束，则被逐出节点将重新启动。
• 如果上述过程顺利结束，并且私网被顺利恢复，则OHASD进程将尝试重新启动该节点的Clusterware和RAC。

即在11.2.0.2以上版本，被逐出的节点可能不会重新启动。

请检查如下日志，查看详细过程：

• $GI_HOME/log/<nodename>/alert<nodename>.log
• $GI_HOME/log/<nodename>/cssd/ocssd.log

• 测量过程记录

A.拔除第2节点1根内网网线，客户已经做了网卡冗余。

无问题

1. 拔出第二节点2根网线。

ocssd 侦测到心跳网络断了。

随后开始clean up 进程

随后节点被驱逐，状态如下

相应的，根据日志显示已经进入graceful shutdown阶段。

此时要求将内网网络恢复。

网络一旦恢复，ohasd 进程会侦测到并且立即进入恢复阶段。

最终恢复结果如下：

• 测试效果总结

由于客户已经做了网卡冗余策略，1根网线故障不会对集群和数据库可用性造成影响。

内网网络中断的情况下，CRS将会侦测到集群分裂，由于集群发生脑裂故障，数据库无法使用，并且于300秒后故障集群被踢出，此时无故障节点恢复使用。300秒后，故障节点（2节点）被踢出集群，集群进入cleanup 和graceful shutdown 阶段。

只要在故障时间内将网线恢复，故障排除，集群将会自动侦测到并且重新加入集群，恢复所有的资源和数据库实例。

提请用户注意：网络故障恢复后查看是否数据库实例已经正常启动，如果没有恢复需要手动恢复数据库实例。

此时不仅需要用srvctl status database -d shzw 来确定数据库状态，而且需要在每个节点通过 sqlplus ps -fe |grep pmon 和查看alert log 来确定数据库的状态。

18.5 某项目的11g RAC实施内容

现状及需求

为充分提高数据库系统的高可用性、高性能、可扩展性，某公司准备逐步采纳并推广Oracle RAC集群技术。

一方面，该公司计划将实施由美国总部统一部署的第一套基于Oracle RAC的应用系统。另一方面，该公司准备在部署这套系统时，逐步掌握Oracle RAC基本原理和日常运维操作，同时能通过在测试环境专门部署一套RAC系统，并结合一定的应用系统，开展全面的RAC架构设计、高可用性测试、上线方案演练、运维管理、变更管理等工作，为该公司将来全面的RAC改造工作奠定基础。

Oracle服务建议

针对上述现状，我们提出如下的Oracle服务建议：

• 首先，我们将在第一套RAC实施过程中，对该公司的现有 RAC实施方案提供检查和咨询，以及上线期间的现场支持服务。
• 我们将依据Oracle 11g RAC实施解决方案，为该公司的RAC项目提供专项服务。

以下就是RAC专项服务的实施计划及实施内容：

可见，上述RAC专项服务涵盖RAC架构总体方案、RAC数据库物理设计和应用部署、RAC日常运维管理、RAC日常运维管理、RAC变更管理、RAC高可用性等诸多方面的方案设计和测试工作。以下我们挑选几个主要服务项目进行详细介绍。

OCR设备管理

OCR（Oracle Cluster Registry）设备是Oracle Clusterware及RAC环境的重要设备，如果OCR设备出现故障，将导致Clusterware出现宕机等严重故障。在RAC项目实施中，我们将在如下方面展开OCR的实施工作。

• OCR设备是如何自动备份的？

正因为OCR设备的如此重要，因此Oracle自动进行OCR设备的备份工作。作为DBA，我们应了解OCR设备的自动备份策略和备份位置等。

Oracle是采取如下三种自动备份策略：

1. 每间隔4小时进行一次OCR设备备份，并保留最新的三个备份。
2. Oracle每天对OCR设备备份一次，并保留最新的两个备份。
3. Oracle每周对OCR设备备份一次，并保留最新的两个备份。

这样，Oracle最多可能有7个备份：1个4小时前的备份，1个8小时前的备份，1个12小时前的备份，1个24小时前的备份，1个48小时前的备份，1个7天前的备份，1个14天前的备份。

OCR自动备份数据位于<Grid Home>/cdata/<cluster name>目录。通过如下命令，可显示OCR自动备份结果：

$ ocrconfig -showbackup auto

host02 2009/07/28 12:20:42  /u01/app/…/cdata/cluster01/backup00.ocr

host02 2009/07/28 08:20:41  /u01/app/…/cdata/cluster01/backup01.ocr

host02 2009/07/28 04:20:40  /u01/app/…/cdata/cluster01/backup02.ocr

host02 2009/07/27 16:20:37  /u01/app/…/cdata/cluster01/day.ocr

host02 2009/07/28 00:20:39  /u01/app/…/cdata/cluster01/week.ocr

• 如何修改OCR自动备份位置？

缺省情况下，Oracle在RAC的主节点将OCR设备备份到本地的<Grid Home>/cdata/<cluster name>目录。为安全起见，Oracle建议将OCR设备备份目录设定到所有节点都能访问的共享目录，这样，一旦主节点出现故障，其它节点仍然可以进行OCR设备的备份工作。以下就是修改OCR设备备份目录的命令：

# ocrconfig –backuploc <path to shared CFS or NFS>

即OCR备份目录应是共享的CFS或NFS目录，但不能设置为ACFS文件系统。

• 如何进行OCR设备的手工备份？

相比Voting Disk设备， OCR设备保存的Clusterware配置信息更加动态。因此，当OCR设备内容发生比较大的变化时，除了Oracle的上述自动备份策略之外，建议及时进行OCR设备的手工备份。

如下命令进行OCR设备的手工备份：

# ocrconfig -manualbackup

即Oracle将自动在OCR备份目录产生一个格式为backup_<date>_<time>.ocr的OCR备份文件。

通过如下命令将显示手工备份的OCR备份文件清单：

$ ocrconfig –showbackup manual

host02 2009/07/28 16:59:17     /u01/app/…/cdata/cluster01/backup_20090728_165917.ocr

通过如下命令，还可对OCR设备进行手工的逻辑备份：

# ocrconfig -export /home/oracle/ocr.backup

上述OCR设备手工备份操作，并不影响Oracle的自动备份策略。

• 如何增加、替换、修复、删除OCR设备

在安装或升级Oracle Grid Infrastructure之后，可通过如下命令增加OCR设备：

# ocrconfig -add +DATA2

# ocrconfig -add /dev/sde1

第一条命令在+DATA2磁盘组中增加一个OCR设备，第二条命令将/dev/sde1 设备增加为OCR设备。Grid Infrastructure最多可支持5个OCR设备。

通过如下命令替换OCR设备：

# ocrconfig -replace /dev/sde1 -replacement +DATA2

上述命令将现有OCR设备/dev/sde1，替换为磁盘组+DATA2中的OCR设备。也就是删除OCR设备/dev/sde1，并在+DATA2中增加一个OCR设备。

在停止运行Clusterware的节点，可对OCR进行修复操作，包括增加、删除、替换OCR设备等操作。例如：

[root@host03]# ocrconfig -repair -add +DATA1

通过如下命令，可删除OCR设备：

# ocrconfig -delete +DATA2

# ocrconfig -delete /dev/sde1

第一条命令在+DATA2磁盘组中删除一个OCR设备，第二条命令将OCR 设备 /dev/sde1 设备删除。但是，Clusterware必须有至少一个OCR设备存在，否则上述删除操作将报错。

• 如何将OCR设备迁移到ASM？

Oracle从11g R2开始可以通过ASM进行OCR 设备的存储和管理，这样可进一步提高整个Clusterware设备的可管理性，例如通过EM可对数据库和Clusterware的存储设备进行集中的统一管理。如果将10g数据库升级到11g，则可以将OCR设备迁移到ASM之中。以下就是详细步骤：

1. 通过如下命令，确认Oracle Clusterware已经升级到11g R2版本：

$ crsctl query crs activeversion

Oracle Clusterware active version on cluster is [11.2.0.1.0]

2. 通过ASMCA工具配置，并在集群的所有节点启动ASM实例。同时创建一个至少为Normal冗余、大小至少为1GB的磁盘组。
3. 通过如下命令，在上述磁盘组中增加一个OCR设备：

# ocrconfig -add +DATA2

上述命令执行一次，增加一个OCR设备。

4. 通过如下命令，可删除以前存储在裸设备上的OCR设备：

# ocrconfig -delete /dev/raw/raw1

# ocrconfig -delete /dev/raw/raw2

• 如何通过物理备份进行OCR设备的恢复？

当OCR设备出现故障时，可通过如下步骤进行OCR设备的物理恢复：

1. 确定OCR物理备份数据

通过如下命令可确定OCR物理备份数据：

$ ocrconfig –showbackup

包括自动（auto）和手工（manual）的OCR物理备份数据。

2. 在所有节点停止Oracle Clusterware

通过如下命令可在所有节点停止Oracle Clusterware：

# crsctl stop cluster -all

3. 在所有节点停止Oracle High Availability Services

通过如下命令可在所有节点停止Oracle High Availability Services：

# crsctl stop crs

4. OCR设备的物理恢复

通过如下命令可进行OCR设备的物理恢复：

# ocrconfig –restore /u01/app/…/cdata/cluster01/day.ocr

5. 在所有节点重启Oracle High Availability Services

通过如下命令，在所有节点重启Oracle High Availability Services：

# crsctl start crs

6. 检查OCR设备的完整性

通过如下命令，可检查OCR设备的完整性：

$ cluvfy comp ocr -n all

• 如何通过逻辑备份进行OCR设备的恢复？

当OCR设备出现故障时，可通过如下步骤进行OCR设备的逻辑恢复：

1. 确定OCR逻辑备份数据

通过逻辑备份命令“ocrconfig -export file_name”命令，可确定OCR逻辑备份数据。

2. 在所有节点停止Oracle High Availability Services

通过如下命令可在所有节点停止Oracle High Availability Services：

# crsctl stop crs

3. OCR设备的逻辑恢复

通过如下命令可进行OCR设备的逻辑恢复：

# ocrconfig –import /shared/export/ocrback.dmp

4. 在所有节点重启Oracle High Availability Services

通过如下命令，在所有节点重启Oracle High Availability Services：

# crsctl start crs

5. 检查OCR设备的完整性

通过如下命令，可检查OCR设备的完整性：

$ cluvfy comp ocr -n all

• 什么叫OLR?

在11g R2版本中，集群中的每个节点都有一个本地的注册信息文件，称之为Oracle Local Registry（OLR）,Oracle在安装OCR设备时进行OLR的安装和配置。当Oracle通过ASM进行OCR和Voting Disk的管理时，OLR主要在Clusterware启动过程中进行一些协调操作，例如确定Voting Disk设备的位置等。

缺省情况下，OLR存储于grid_home/cdata/hostname.olr。通过如下命令，可检查OLR设备的状态：

$ ocrcheck -local

Status of Oracle Local Registry is as follows :

Version                :          3

Total space (kbytes)   :     262120

Used space (kbytes)    :       2204

Available space(kbytes):     259916

ID                     : 1535380044

Device/File Name       : /u01/app/11.2.0/grid/cdata/host01.olr

Device/File integrity check succeeded

Local registry integrity check succeeded

Logical corruption check succeeded

公网的变更

对数据库服务器IP地址进行调整，是客户一项比较正常的变更需求。RAC环境下的IP地址涉及公网、私网，而且都是被Clusterware管理的资源，因此与普通单机数据库不一样的是，需要通过专门的规范化流程来分别进行公网、私网的调整，否则，会导致系统出现严重问题。

• 如何确定当前网络设置？

1. 确定当前集群可用的网络信息：

$ oifcfg iflist –p -n

2. 确定当前集群的公网和私网配置：

$ oifcfg getif

eth0  192.0.2.0  global  public

eth1  192.168.1.0  global  cluster_interconnect

3. 确定当前集群的VIP主机名、VIP地址、VIP子网掩码等信息：

$ srvctl config nodeapps -a

VIP exists.:host01

VIP exists.: /192.0.2.247/192.0.2.247/255.255.255.0/eth0

…

• 如何修改公网VIP地址？

1. 在需要修改的公网VIP地址的所在节点，停止相关服务，例如：

$ srvctl stop service -d RDBA -s sales,oltp -n host01

2. 通过如下命令，确认VIP地址的当前IP地址：

$ srvctl config vip -n host01

VIP exists.:host01

VIP exists.: /host01-vip/192.168.2.20/255.255.255.0/eth0

3. 通过如下命令，停止VIP地址：

$ srvctl stop vip -n host01

4. 通过ifconfig –a命令，确认VIP地址已经停止。
5. 对所有节点的/etc/hosts文件或DNS服务器进行必要的修改，使得新IP地址与主机名关联。
6. 通过如下命令，创建新的VIP地址：

# srvctl modify nodeapps -n host01 -A \ 192.168.2.125/255.255.255.0/eth0

7. 重起VIP地址：

# srvctl start vip -n host01

8. 在相关节点进行上述各步骤的操作，完成相关节点的VIP地址修改。由于srvctl是集群级工具，因此，可在一个节点完成其它节点的维护工作，而不需要登录到相关节点。
9. 通过如下命令，对修改 VIP地址之后的集群环境进行连通性确认：

$ cluvfy comp nodecon -n all -verbose

私网的变更

欲修改私网地址，必须在所有节点同时进行，这是因为Oracle Clusterware目前不支持采用不同的私网Interface，例如不允许节点1为 eth1，而节点2为 eth2。

以下就是私网地址修改过程：

1. 确保Oracle Clusterware在所有节点都启动并正常运行。
2. 通过操作系统命令（例如ifconfig），确保新的私网 Interface已经正确配置，并正常启动。
3. 在集群中的某个节点，通过如下命令，增加新的私网 Interface：

$ oifcfg setif -global eth2/192.0.2.0:cluster_interconnect

4. 在集群中的某个节点，通过如下命令，确认新的私网 Interface已经存在，并停止整个集群的 Clusterware：

# oifcfg getif

# crsctl stop crs

5. 通过如下命令，将新的私网 Interface分配给所有节点的私网网卡：

# ifconfig eth2 192.0.2.15 netmask 255.255.255.0 \

broadcast 192.0.2.255

6. 通过oifcfg getif命令，确认修改成功。
7. 通过如下命令删除老的私网Interface，并重新启动Clusterware：

$ oifcfg delif -global eth1/192.168.1.0

# crsctl start crs

18.6　11件加固RAC环境的事情

在本书坏块处理一章，本人曾说Oracle接客户求救电话中，最多的是如下两类：一类是数据库宕机或挂起，特别是RAC 数据库出现宕机，另外一类是数据库出现坏块。

RAC集群环境涉及主机、操作系统、网络、存储等各层面技术，由于这些环境因素和Oracle软件自身问题而导致的宕机、节点重启等故障，已经司空见惯。RAC本来是为客户数据库系统提供高可用性保障的，但“保障高可用性的东西，自己反而这么不稳定？”成了很多客户诟病和抱怨Oracle公司的典型话语。

如何提高RAC的健壮性？Oracle公司提供的《Top 11 Things to do NOW to Stabilize your RAC Cluster Environment [ID 1344678.1]》，叙述了如下11条RAC最佳实践经验，非常值得我们在 RAC实施中加以借鉴。

1.  安装最新的PSU补丁

在本书的“Oracle版本、Bug和补丁”一章，我们已经介绍了Oracle版本和多种补丁的概念，包括PSU补丁。PSU补丁是Oracle自10.2.0.4版本起，每个季度定期发布的补丁，并包括CPU补丁。PSU补丁包含了当前时间内全球最常见、最重要、对系统健壮性有重要影响的一些小补丁。因此，在RAC实施中，应尽量安装最新的PSU补丁。

需要注意的是，Windows平台没有PSU补丁概念，同期PSU补丁的内容包含在相应的Windows Bundle Patch中。

如下文章更详细介绍了PSU补丁：

《Document 854428.1 Intro to Patch Set Updates (PSU)》

《Document 1082394.1 11.2.0.X Grid Infrastructure PSU Known Issues》《Document 756671.1 Oracle Recommended Patches — Oracle Database》《Document 161549.1 Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms》

2.  设置正确的UDP协议缓冲区参数

RAC集群环境的私网通信（Interconnect）是RAC的命脉，在UNIX和Linux平台，合理设置UDP协议的接受和发送缓冲区参数，将对私网通信效率至关重要。反之，不仅会影响RAC的私网通信效率，更可能导致RAC出现宕机等严重故障。

如下文章更详细介绍了如何合理设置UDP协议缓冲区参数：

《Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS》

《Document 563566.1 gc lost blocks diagnostics》

需要注意的是，由于Windows平台采用TCP协议进行私网通信，因此无需设置UDP缓冲区参数。

3.  在10.2和11.1环境，将DIAGWAIT值设置为13

在10.2和11.1环境，OPROCD后台进程的缺省margin值设置为500毫秒（即5秒）。这样，当系统负载处于繁忙状态时，可能使得Oracle反应过于敏感，从而导致节点重启。将DIAGWAIT值设置为13，将OPROCD后台进程的缺省margin值设置为1000毫秒（即10秒），这样能避免不必要的节点重启，同时也使Oracle在发生节点重启故障时，有更多时间将相关信息写入trace文件，以便进行深入的诊断分析。

通过如下命令，可了解当前的DIAGWAIT配置：

# $CLUSTERWARE_HOME\bin\crsctl get css diagwait

该建议不适合于Windows环境，以及11.2以上版本。

如下文章更详细介绍了DIAGWAIT的含义及设置方法：

《Document 559365.1  Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions》《Document 567730.1  Changes in Oracle Clusterware on Linux with the 10.2.0.4 Patchset》

4.  在LINUX环境下实施 HugePages

在Linux 64位平台，实施HugePages将极大地提高Linux核运行性能，特别是针对内存配置较大的系统。通常而言，超过12GB内存的系统，就应该考虑实施HugePages，内存越大，实施HugePages的效果越明显。其原理在于：当Linux在进行内存管理时，需要按页进行内存的映射和维护操作。若启动HugePages，将有效降低内存页的数量，从而提升系统性能。大量实践经验表明：当未实施HugePages时，由于Linux核内存管理负载较重，可能导致RAC节点被踢出，甚至节点重启。

但是，在Linux 64位平台，11g的自动内存管理技术（AMM）与HugePages技术不兼容。因此，欲采用HugePages技术，应关闭AMM技术。Document 749851.1描述了在Linux 平台AMM和HugePages技术的关联关系。

如下文章更详细介绍了HugePages含义及设置方法：

《Document 361323.1  HugePages on Linux: What It Is… and What It Is Not…》

《Document 401749.1  Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration》

5.  实施OS Watcher及Cluster Health Monitor

尽管与RAC稳定性没有直接关系，但OS Watcher和Cluster Health Monitor工具的部署，将对节点或实例宕机等故障的诊断，特别是在操作系统层面的原因分析，起到非常关键的作用。通过这些工具的信息采集，不仅有利于故障的诊断分析，而且也可有效防止故障的再次发生。与很多第三方工具信息采集周期通常为5分钟不同的是，OS Watcher的采集周期缺省为30秒，因此能采集到更多的操作系统信息，从而有利于故障的定位。虽然Oracle没有在所有平台都提供Cluster Health Monitor工具，但该工具是对OS Watcher的有力补充，该工具可以更精细的粒度进行信息采集。因此，在RAC环境的所有节点部署这些工具，将有效提高故障诊断和处理效率。

如下文章更详细介绍了OS Watcher及Cluster Health Monitor工具：

《Document 301137.1 OS Watcher User Guide》

《Document 1328466.1 Cluster Health Monitor (CHM) FAQ》

6.  遵循AIX操作系统的最佳实践经验

为提高RAC在AIX平台的运行稳定性和效率，Oracle和 IBM公司一直在精诚合作。双方共同推出的《The Oracle Real Application Clusters on IBM AIX Best practices in memory tuning and configuring for system stability》白皮书，就是两个公司工程师们共同的结晶。根据此白皮书的经验总结进行实施，将解决大部分在AIX平台实施RAC的稳定性问题。AIX 6.1版甚至已经将这些经验值作为缺省值进行设置。

如下文章详细介绍了更多内容：

白皮书位于： http://www.oracle.com/technetwork/database/clusterware/overview/rac-aix-system-stability-131022.pdf

《Document 811293.1  RAC Assurance Support Team: RAC Starter Kit and Best Practices (AIX)》

7.  在AIX环境下正确实施APARS，避免过量的Paging/Swapping操作

经验表明，在AIX环境下如果没有正确实施APARS，例如在AIX 6.1版本，没有安装APAR IZ71987，可能导致大量的Paging/Swapping操作。这样在Oracle单机环境可能导致系统Hang，并需要人工干预加以解决。而在RAC环境，则可能导致一个节点被踢出。

如下文章详细介绍了更多内容：

《Document 1088076.1 Paging Space Growth May Occur Unexpectedly on AIX Systems With 64K (medium) Pages Enabled》

8.  实施NUMA补丁

所谓NUMA（Non Uniform Memory Access Achitecture），即非一致访问分布共享存储技术，它是由若干通过高速专用网络连接起来的独立节点构成的系统，各个节点可以是单个的CPU或是SMP系统。Oracle RAC支持NUMA技术。但在NUMA环境实施RAC，同样会有导致性能、甚至宕机的Bug存在。文档 Document 759565.1列出了在10.2.0.4和11.1.0.7版本下的与NUMA相关的问题。若版本为10.2.0.4和11.1.0.7，Oracle建议安装补丁8199533。

9.  在Windows环境下，扩大Nonineractive Desktop Heap值

经验表明，在Windows平台实施RAC，Nonineractive Desktop Heap的缺省值不够，可能导致应用连接问题，甚至导致系统Hang和宕机问题。因此，应主动将Nonineractive Desktop Heap值设置为1M，将有效避免上述问题的发生。

文档《Connections Fail with ORA-12640 or ORA-21561 (Doc ID 744125.1)》详细介绍了上述相关问题及解决办法。

10. 运行RACCheck工具

RACCheck工具全称叫做：RAC Configuration Audit tool，主要用于检查和审计RAC、Clusterware、ASM及GI环境的配置信息。检查和审计的领域包括：操作系统核心参数、操作系统Package、与RAC相关的操作系统其它配置信息、CRS/Grid Infrastructure、RDBMS、ASM、数据库参数、与RAC相关的数据库其它配置信息、11.2.0.3升级就绪评估。

通过RACCheck工具，能帮助客户确认RAC实施是否遵循了Oracle公司建议的一系列RAC最佳实践经验，有效发现存在的问题，并最终提高RAC运行的稳定性。

本书第十章的“10.3 数据库常见诊断工具”一节，详细介绍了RACCheck工具的使用。

11. 实施NTP Slewing Option

假设没有实施NTP回转选项（NTP Slewing Option），会导致系统时钟向前或向后调整。假设向后调整的时间量超出一定范围，会导致节点被踢出。因此，为防止此情况的发生，应设置NTP服务，确保整个集群节点时钟的同步。

假设没有配置NTP服务，11g中将自动配置Cluster Time Synchronization Service（CTSS），并在集群所有节点启动octssd.bin后台进程。

18.7本章参考资料及进一步读物

本章参考资料及进一步读物：