Archives for 一月 2016

【dbdao Hadoop 大数据学习】权限指导

dbDao.com 引导式IT在线教育
Hadoop 技术学习QQ群号  : 134115150

本文固定链接:http://www.askmaclean.com/archives/hadoop-permissions-guide.html

本文是官方文档的翻译,原文地址是:

http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html

 

 

1.概述

 

HDFS为文件和目录实现了一个权限模块,一大部分共享是POSIX模式。每个文件和目录关联到一个用户和一个组。文件和目录以用户所有者来权限划分,其他的用户可以是一个组的成员,也可以是所有其他的用户。对于文件来说,r 权限是读文件的权限,w 权限是写或者追加到文件的权限。对于目录来说,r权限是列出目录内容的权限,w权限是删除和创建文件或目录的权限,x权限是访问子目录的权限。

于POSIX模式对比,文件没有setuid或setgid位,因为没有可执行文件的概念。同样地,对于目录也没有setuid和setgid位。粘贴位可以被设置在目录上,可以防止除了超级用户之外,目录所有者或文件所有者在这个目录中删除或移动文件。在文件上设置粘贴位没有作用。总的来说,一个文件或目录的权限是它们的模式。一般来说,Unix用户的表现模式将被使用,包括这个表述上的8进制方法。当文件或目录被创建,它们的所有者是客户端进程的标识,它们的组时父目录的组(BSD规则)。

HDFS也提供了POSIX ACLs(访问控制列表)支持,来增加对特定命名用户或命名组的更细粒度规则的文件权限。ACLs在后面有更详细的讨论(www.askmaclean.com)。

每个客户端进程访问HDFS拥有2部分标识:用户名和组列表。当文件和目录被一个客户端进程访问时,HDFS必须进行权限检查。

  • 如果用户名匹配所有者,那么所有者权限是通过的。
  • 如果组权限匹配组列表中任何一个成员,那么组权限是通过的。
  • 否则,其他权限是通过的。

如果权限检查失败,客户端操作就失败。

[Read more…]

【MySQL学生手册】MySQL表分区类型

本文地址:http://www.askmaclean.com/archives/mysql-partition-type.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

Mysql技术学习QQ群:146959374

 

9.2 分区类型

  • RANGE分区:基于列值所处在的给定范围来对行进行分区。
  • LIST分区:和RANGE分区类似,不过区别是基于一组离散值集合中的值匹配来进行分区。
  • HASH分区:分区的选择基于要插入行的列值进行用户定义功能函数计算后的返回值。其功能函数可以包括任意MySQL有效表达式并返回一个非负的整数值。
  • KEY分区:和Hash分区类似,不过区别是使用MySQL自有的哈希功能来对一列或多列进行哈希计算,其中的列值也可以包含除整数值之外的值,而MySQL并不关心列值的具体数据类型,在哈希计算后,都会返回一个整数值。

 

通常使用数据库分区时会按日期时间来都对数据进行分割。一些数据库系统支持显式时间日期分区语法,不过MySQL不支持。不过在MySQL中,想要基于DATE,TIME,或DATETIME列来建立分区,或基于使用这些列进行计算的表达式来进行分区都并不困难。

 

当通过KEY或LINEAR KEY建立分区时,你可以在不对DATE,TIME或DATETIME列进行任何值修改的情况下,直接使用它们来进行分区。例如,以下表分区语句在MySQL中是可行的:

CREATE TABLE members (
firstname VARCHAR(25) NOT NULL,
lastname VARCHAR(25) NOT NULL,
username VARCHAR(16) NOT NULL,
email VARCHAR(35),
joined DATE NOT NULL
)
PARTITION BY KEY(joined)
PARTITIONS 6;

[Read more…]

云中制胜 – 记Oracle SPARC M7重磅来袭

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

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

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

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

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

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

[Read more…]

【MySQL学生手册】分区(Partition)

本文地址:http://www.askmaclean.com/archives/mysql-partition.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

Mysql技术学习QQ群:146959374

第9章 分区(Partition)

 

章节概述

本章介绍在MySQL中分区的管理。你会了解:

  • 理解分区概念
  • 使用SHOW VARIABLES来确定服务端的分区支持
  • 如何建立一张分区表
  • 描述分区类型

 

9.1 分区概述

SQL标准中并不提供很多关于数据物理存储方面的指导。而SQL语句本身趋向于独立于数据结构或这些模式(schema/database),表,行或列下对应的介质进行运行。但是,大多数高级的数据库管理系统都会有一些方法来判断具体被用于存储的文件系统或硬件下的数据片的物理位置。在MySQL中,InnoDB存储引擎还支持表空间概念。在MySQL服务端,介绍分区之前,你可以配置不同的空物理目录来存储不同的数据库。

Tips:分区是从MySQL 5.1.14-Beta版本开始被引入的功能。

 

分区在此基础上更近一步,允许你在将单个表的各个部分分布在整个文件系统中(只要所设分区文件的大小遵守系统的规则)。实时上,一张表的不同部分可以如各个分割的表存储在不同位置。数据通过用户选择的规则进行的分割(我们称为分区功能),如按量值进行分区,或简单匹配一个值列范围进行分区,或使用内部哈希函数或一个线性函数进行分区等。如何分区由用户按分区类别来确定,其所用的功能匹配可以接受用户提供的表达式值作为参数,表达式可以是一个整型列值,或在对一个或多个列进行处理后来得出的一个整数来作为返回。表达式的值被传给分区功能函数,此函数会返回一个整数值代表了对应数据行应该被存放在哪个分区的分区号。此功能函数必须是非静态值和非随机值。它不能包含任何查询,但可以“虚拟的“使用在MySQL中有效的任意表达式(只要表达式返回的正整数小于最大可能的正整数值MAXVALUE即可)。【dbdao.com 数据岛】

 

我们在这里所介绍的分区在概念上指水平分区(horizontal partitioning)– 即,表中的不同行可以在不同的物理分区中。MySQL不支持垂直分区(vertical partitioning),即表中的不同列被分派到不同的物理分区中。到现在为止,MySQL还未有任何计划来引入垂直分区功能。

 

9.1.1 查看分区功能启用状态

在MySQL 5.6版本之前,你可以通过使用以下语句来查看MySQL的分区功能是否已经启用:

mysql> SHOW VARIABLES LIKE '%partition%';

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| have_partitioning | YES   |
+-------------------+-------+
1 row in set (0.00 sec)

不过从MySQL 5.6开始,have_partitioning环境变量已经被移除,因此你需要使用show plugins来查看partition的启用情况。

如果对应状态显示未被启用的话,则说明当前的MySQL服务端不支持分区功能。

[Read more…]

Oracle Acs资深顾问罗敏 老罗技术核心感悟:尝鲜Oracle 12c

作者为: 

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公司描述的最新几个版本的技术创新示意图:

12cz1

 

在这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关系的单机架构:

 

12cz2

 

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

12cz3

 

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

12cz4

 

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

Container DB和Pluggable DB基本概念

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

 

12cz5

 

 

首先,在这种架构下只有一个数据库实例,即所有数据库共享一组后台进程和一组内存,包括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 系统架构现状分析开始:

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

 

12cz6

 

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

其次,这些系统其实应用并不复杂,但同样需要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的多种访问方式和工具,如下所示:

 

12cz6

 

可见,创建 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

该方式的示意图如下:

 

12cz7

 

具体步骤如下:

  • 以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

该方式示意图如下:

12cz8

 

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

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

该方式示意图如下:

 

12cz9

 

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

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

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

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

 

12cz10

 

可见,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数据库的启动各阶段示意图:

 

 

12cz11

通过如下命令,可根据不同需要关闭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)实际上包括有效管理数据的一系列策略、过程和工具等,从而满足客户提高访问效率、降低存储开销、满足安全性和合规性要求等综合目标。

 

12cz12

 

 

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技术结合使用的示意图:

 

12cz13

 

即在启动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系统服务质量等目的。如下图所示:

 

 

12cz99

 

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

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

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

 

“貌离神合”

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

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

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

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

12cz98

 

也就是说,将现在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三个层面进行数据和应用的整合,以下就是其“地市统一支撑云平台”的基本框架和建设思路:

 

12cz14

 

  • 数据库云平台建设思路

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

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

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

 

阶段 主要任务 详细内容
     
需求系统设计 各地市现有系统调研工作 调研各地市现有系统平台、版本、架构、数据库字符集、性能等总体情况
地市资源池架构设计工作 在12c平台,开展地市资源池架构设计工作,包括12c RAC架构设计;CDB、PDB架构设计;版本和补丁方案设计等
12c日常运维管理方案设计 包括12c Clusterware、ASM、RAC、CDB、PDB日常运维方案和操作。例如CDB和PDB启动和关闭、CDB和PDB的数据库备份和恢复等。
资源池迁移方案设计 针对各地市系统的不同需求,开展“升级 +  Plug”、“创建PDB + 导入数据”等迁移方案设计
12c RAC高可用性方案设计 针对具体应用开展高可用性方案设计,例如负载均衡、TAF、Failover、Service等设计,同时开展各种软、硬件的故障模拟案例设计
12c RAC变更管理方案设计 开展Clusterware、ASM、RAC等变更管理方案,例如如何进行公网、私网的变更,如何进行补丁实施,如何进行ASM磁盘的增加、删除等。
历史数据管理方案设计 针对各地市系统的不同需求,开展基于12c的Heat Map和ADO、数据库内部归档 (In-Database Archiving)等技术的历史数据管理方案设计工作
其它整改和优化方案设计 针对各地市系统的不同需求,基于12c整合的平台,尤其是利用12c相关新特性,开展各地市系统的优化和整改方案设计工作
12c技术交流和知识转移 开展12c技术交流和知识转移工作
环境建立 硬件环境准备的技术支持和环境检查 提供硬件系统环境需求,例如操作系统补丁、包的需求,网络配置需求等,并进行环境检查和确认
地市资源池数据库系统软件的安装、配置和调试 安装12c RAC软件及相关补丁
创建CDB、PDB数据库,加载数据 针对典型地市,创建CDB、PDB数据库,并加载相关模拟数据
系统备份环境搭建的技术支持 为物理备份环境的搭建提供技术支持,同时开展Catalog数据库创建、与磁盘或磁带库的连接等实施工作
系统测试 12c日常运维管理方案测试 开展12c Clusterware、ASM、RAC、CDB、PDB日常运维方案测试工作。例如CDB和PDB启动和关闭、CDB和PDB的数据库备份和恢复等。
资源池迁移方案测试 针对各地市系统的不同需求,开展“升级 +  Plug”、“创建PDB + 导入数据”等迁移方案测试工作
12c RAC高可用性方案测试 针对具体应用开展高可用性方案测试工作,例如负载均衡、TAF、Failover、Service等设计,同时开展各种软、硬件的故障模拟案例测试
历史数据管理方案测试 针对各地市系统的不同需求,开展基于12c的Heat Map和ADO、数据库内部归档 (In-Database Archiving)等技术的历史数据管理方案测试工作
其它整改和优化方案测试 针对各地市系统的不同需求,基于12c整合的平台,尤其是利用12c相关新特性,开展各地市系统的优化和整改方案测试工作
上线阶段 正式环境上线前封装检查 针对地市资源池生产系统,进行封装检查
上线前性能基线收集 针对地市资源池生产系统,进行上线前性能基线收集
正式迁移割接 针对地市资源池生产系统,正式迁移割接
上线后性能监控 针对地市资源池生产系统,进行上线后性能监控
上线后支持阶段 上线后的技术支持服务 上线值守
上线后数据库性能调整优化 后期优化调整
项目管理 项目管理 项目计划、文档管理等

综合日志库的建设

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

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

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

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

 

12cz15

 

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

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

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

 

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

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

序号 资料类别 资料名称 资料概述
       
1. Oracle 12c联机文档 《Oracle® Database New Features Guide》 就像Oracle以前每个新版本一样,这是一本描述Oracle 12c新特性的专门文档,DBA和开发人员都应该先睹为快。
2. Oracle 12c联机文档 《Oracle® Database Administrator’s Guide》Part VI“Managing a Multitenant Environment” 这是Oracle 12c联机文档中,最集中、最全面讲述多租户环境即CDB/PDB的地方。
3. Oracle 12c联机文档 《Oracle® Database VLDB and Partitioning Guide》第五章“Managing and Maintaining Time-Based Information” 这是Oracle 12c联机文档中,最集中、最全面讲述信息生命周期管理的地方:Heat Map、ADO、In-Database Archiving、Temporal Validating… …
4. Oracle大学培训教材 《Oracle Database 12c:New Features for Administrators》 Oracle大学全面系统进行12c新特性培训的教材,参加该课程培训,一定物超所值!呵呵。
5. My Oracle Support 《Master Note for the Oracle Multitenant Option (Doc ID 1519699.1)》 有关12c多租户即CDB/PDB的资料汇集地:联机文档、白皮书、论坛、最佳实践经验等。
6. My Oracle Support 《How to migrate an existing pre12c database(nonCDB) to 12c CDB database ? (Doc ID 1564657.1)》 如何将传统非CDB数据库升级/迁移到12c CDB?本文档给出了相关技术方案。
7. My Oracle Support 《Oracle Multitenant Option – 12c : Frequently Asked Questions (Doc ID 1511619.1)》 什么叫CDB/PDB?CDB/PDB的好处何在?如何实施 CDB/PDB?这些林林总总的问题,基本都能在这篇文档中找到答案。
8. My Oracle Support 《Information Lifecycle Management (ILM), Heat Map, Automatic Data Optimization (ADO) (Doc ID 1612385.1)》 这是一片简要讲述ILM、Heat Map、ADO的官方文档,帮助大家快速了解这些12c的重要新特性。
9. Oracle白皮书 《 Automatic Data Optimization with Oracle Database 12c》 这是Oracle技术网站(http://otn.oracle.com)中有关12c ADO技术的白皮书。链接是:http://www.oracle.com/technetwork/database/enterprise-edition/automatic-data-optimization-wp-12c-1896120.pdf
10. My Oracle Support 《12c: In-Database Archiving And Compression (Doc ID 1592186.1)》 如何将非活动数据进行压缩并进行数据库内部归档,而将当前活动数据保持为非压缩状态?本文档给出了一个详细脚本案例。

 

【dbdao Hadoop 大数据学习】Hadoop概念

dbDao.com 引导式IT在线教育

Hadoop 技术学习QQ群号  : 134115150

 本文固定链接:http://www.askmaclean.com/archives/hadoop-concepts.html

 

 

Hadoop概念

 

应用程序经常需求,超过廉价(商品)机器上可用的更多资源。许多组织发现自己的业务流程不再适合在单一的、具有成本效益的计算机上进行。一个简单却昂贵的解决方案是购买耗费大量内存,并具有多个CPU的专门机器 。该解决方案可最快扩展至机器所支持的程度,但是唯一的限制因素通常是你的预算。另一种解决方案是建立一个高可用性集群,它通常试图看起来像一个单台机器,并且通常需要非常专业化的安装和管理服务。许多高可用性集群都是有版权并且昂贵的。

 

获取必要的计算资源的一种更经济的解决方案是云计算。一种常用模式是:那些需要被转换的批量数据,其中每个数据项的处理基本上独立于其他数据项;也就是说,通过使用单指令,多数据(SIMD )方案。Hadoop提供一个云计算的开源框架,以及一个分布式文件系统。

本书的设计意图是作为使用Hadoop,一个由Apache软件基金会主办的项目,来开发和运行软件的实用指南。本章将为你介绍Hadoop的核心概念。目的是为下一章的内容做准备,下一章中你将了解Hadoop的安装和运行(www.askmaclean.com)。

 

Hadoop介绍

 

Hadoop是以发表于2004年的有关MapReduce的Google文章为基础,其发展始于2005年。当时,Hadoop的开发是为了支持一个叫做Nutch的开源网络搜索引擎项目。最终,Hadoop从Nutch中分离出来,成为Apache基金会下自己的一个项目。

今天Hadoop是市场上最知名的MapReduce框架。目前,有几家围绕Hadoop的公司已经发展到提供Hadoop软件的支持、咨询和培训服务。

Hadoop的核心是一个基于Java的MapReduce框架。然而,由于Hadoop平台的迅速普及,支持非Java用户群体很有必要。Hadoop已经发展到拥有以下改进,和支持该群体的子项目,并将其范围扩大到企业。

[Read more…]

Oracle Acs资深顾问罗敏 老罗技术核心感悟:数据库私有云技术

作者为: 

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行业所普遍接受:

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

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

cloudz1

 

云计算基本特征

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

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

云计算服务模式

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

  • 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系统,将为客户带来如下图所示的四方面的效益:

 

cloudz2

 

  • 降低IT系统成本

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

  • 降低IT系统复杂性

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

  • 提高IT系统灵活性

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

  • 提高IT系统服务质量

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

 

不同层次的云计算

不同层次的云计算

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

cloudz3

 

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

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

不同层次的云计算的对比

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

cloudz4

 

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

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

某客户采购了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容量。如下图:

cloudz5

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

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

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

cloudz6

 

  • 根据上述初步规划,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等情况:

 

cloudz7

cloudz8

 

即设置了多个消费组,并对其中的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技术来进行资源的管理和控制。二者的有机协调工作,将会为数据库云平台的资源合理、有序使用提供保障。

 

cloudz9

 

一次尴尬的拜访经历

一次尴尬的拜访经历

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年间成功实施了该项目。下面将该项目一些主要情况叙述如下,供大家在建设类似项目时,加以借鉴。

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

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

cloudz10

可见,具有典型的“三多”现象:系统多、平台多、版本多。例如,平台包括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、内存配置和利用率等方面也各不相同,数据库容量也相差甚远。这种设备配置和部署都是考虑各业务系统峰值,而系统之间是绝对隔离的,资源无法共享,导致了资源极大浪费,同时又存在业务高峰时单个系统资源不足的风险。

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

整合目标和总体架构

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

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

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

 

cloudz11

 

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

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

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

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

关键技术的运用

  • Service的运用

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

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

例如,以下就是部分Service设计和部署情况:

原有数据库名 应用名 服务名 PREFER AVAILABLE TAF policy Failover type Failover method retries delay
双屏数据库 Ngdus ngdus inetg1 integ4 Basic select basic 10 2
稽核系统数据库 Ahaudit ahaudit inetg2 integ4 Basic select basic 10 2
BI库(接口) Worabidb dss_bi integ3 integ4 Basic select basic 10 2
… …                  

以下就是创建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的资源分配计划:

cloudz12

 

cloudz13

 

即:

  • 划分了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本章参考资料及进一步读物

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

序号 资料类别 资料名称 资料概述
       
1. Oracle公司网址 http://www.oracle.com/technetwork/topics/cloud/whatsnew/index.html 这是Oracle公司技术网站中有关云计算的资源汇集地,有产品、技术、白皮书、最佳实践经验等。
2. Oracle技术白皮书 《 Architectural Strategies for Cloud Computing》

该文章位于http://www.oracle.com/us/ciocentral/architecrl-strategies-for-cc-396213.pdf

该文章描述了云计算基本概念,特别是Oracle公司的云计算基本策略。
3. Oracle技术白皮书 《 Database Consolidation onto Private Clouds》 该文章描述了Oracle数据库私有云基本概念、架构、关键技术运用及实施案例等。
4. My Oracle Support 《Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure (Doc ID 1096952.1)》 RAC作为重要基础架构技术,在Oracle数据库私有云计算中至关重要。这篇文章就是RAC技术资源的汇集地。
5. Oracle 11g R2联机文档 《Oracle® Real Application Clusters Administration and Deployment Guide》 该文档全面介绍了RAC 管理和实施,例如多个章节均讲述了Service的概念、运用和管理。
6. My Oracle Support 《Master Note for Automatic Storage Management (ASM) (Doc ID 1187723.1)》 ASM为实施云计算的存储资源整合提供了良好的平台。这篇文章就是ASM技术资源的汇集地。
7. My Oracle Support 《Configuring and Monitoring Instance Caging (Doc ID 1362445.1)》 什么是Instance Caging?如何配置?如何监控其使用过程,以及如何优化?请看这篇文档。
8. My Oracle Support 《Master Note: Overview of Oracle Resource Manager and DBMS_RESOURCE_MANAGER (Doc ID 1484302.1) 》 Resource Manager技术在数据库云计算平台的精细化管理中起到了重要作用,这篇文档就是各类Resource Manager资料的汇集地。

 

Oracle Acs资深顾问罗敏 老罗技术核心感悟:话说升级

作者为: 

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

话说升级

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

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

关于数据库升级的疑虑

关于升级的矛盾和纠结

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

upgrade1

 

上述“为什么要升级?”和“升级能带来什么益处?”,其实更多地是有关升级的必要性问题。而“升级如何保证停机时间”、“万一升级失败,怎么办?”、“新版本对应用是否兼容”、“升级后是否会导致性能下降”等类问题,则是有关升级的可行性问题了。最后,“如何使用新特性?”、“需要对系统运维工作进行哪些调整?”等问题,就不仅仅是将升级看成是一种被动而为的事情,特别是为了满足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数据库产品和服务的生命周期政策:

 

upgrade2

 

其中:

  • 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各类服务的详细情况:

 

upgrade3

 

可见,只有在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的示意图:

 

upgrade4

 

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

升级项目涉及的主要内容

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

upgrade5

 

  • 数据库升级技术方案

如何根据现有系统运行状况,特别针对升级需求进行深入分析,合理运用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系统:

upgrade6

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

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

upgrade7

 

即在存储、数据库和应用服务器等不同层面均提供了资源共享池技术基础架构,从而打破了现有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数据库之中。

方案示意图如下:

 

upgrade8

 

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

升级方案2:原地升级

  • 方案要点

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

方案示意图如下:

 

upgrade9

 

  • 在现有数据库服务器上安装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后还支持跨平台迁移,是一种高效的实现数据迁移的方案。

方案示意图如下:

upgrade10

 

该方案总体步骤如下:

  • 在新生产系统安装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数据库。

方案示意图如下:

 

upgrade11

 

  • 首先需要部署不低于现有生产系统环境的新生产系统环境,包括主机和存储资源。
  • 在新生产环境服务器上安装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实现现有生产库和新生产库的数据同步,并最终一次性进行割接。

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

upgrade12

 

  • 该方案需要部署中间库环境,包括安装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技术保持数据同步,最终通过切换完成升级和迁移。

方案示意图如下:

 

upgrade13

 

  • 该方案需要部署新生产环境,包括分别安装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实施有若干技术限制,需要结合具体系统情况,充分加以论证。

方案总结和建议

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

编号 方案 跨平台 升级时间 环境要求 技术复杂性 可回退性 应用关联性 适用场景
                 
1. 数据逻辑迁移 支持 数小时 一套额外存储和主机 较简单 良好 与应用相关 数据量不大,停机时间窗口较长的系统
2. 原地升级 N/A 2-3小时 一套额外存储 较简单 良好 与应用无关 数据量大,停机时间窗口在2-3小时左右的系统
3. 表空间传输 支持 数小时 一套额外存储和主机 较简单 良好 与应用相关 数据量不大,停机时间窗口较长的系统
4. Data Guard方案 不支持 2-3小时 一套额外存储和主机 复杂 良好 与应用无关 数据量大,停机时间窗口在2-3小时左右的系统
5. PPRC + Golden Gate方案 支持 几乎零停机 两套额外存储和主机 最复杂 良好 与应用无关 数据量大,停机时间窗口要求最短的系统
6. RMAN + Golden Gate方案 不支持 几乎零停机 主机需要更多存储资源 复杂 良好 与应用无关 数据量大,停机时间窗口要求最短的系统

根据上述综合分析,我们建议如下:

  • 如果数据量不大,或者停机时间窗口允许,可选择数据逻辑迁移、原地升级或表空间传输。
  • 否则,建议考虑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的流程图:

upgrade14

 
即首先在生产环境捕获所关注的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的应用示意图:

upgrade15

 

 

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

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

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

 

升级项目的实施和组织

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

upgrade16

 

 

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

项目方 人员 职责
     
XX银行银行 项目负责人 l 负责整个项目的组织、协调工作

l 负责项目总体方案的评审

l 负责项目确认和验收

运行维护人员

 

l 负责协调系统硬件的准备,包括测试系统和生产系统的主机系统、网络设备和存储设备等,并保证其正常运行

l 负责及时提供详尽的系统需求,以及相关的资料

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作

l 协调应用开发等部门关系

应用开发人员 l 负责应用系统信息提供

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作

测试人员 l 负责测试环境的准备

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作

Oracle公司 技术架构师 l 负责各总体方案设计

l 参与Oracle环境安装和部署

l 参与测试工作

l 参与各方案的实施

l 负责11g技术知识转移

实施顾问 l 负责各总体技术方案设计

l 负责各详细技术方案设计

l 负责Oracle环境安装和部署

l 负责各技术方案测试和实施

l 参与11g技术知识转移

Oracle全球客户7*24二线服务支持及产品研发中心 l 对一线现场专家提供二线支持及后备

l 以800免费咨询电话及互联网的方式提供产品支持服务

l 提供补丁援助

说明如下:

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

 

升级风险评估控制

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

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

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 客户可能无法及时提供用于系统实施的测试环境资源 无法进行系统实施的测试工作,影响项目实施进度。 尽早准备测试环境的硬件资源,搭建完整的测试环境,用于系统实施相关的各项测试工作。

升级中的风险及规避方法

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 升级中遇到无法解决的错误,如升级程序遇到Bug。 升级失败 1)尽早搭建和生产环境一致的测试环境,预先在测试环境演练升级全过程,对于升级中发生的每一种错误找到解决办法;

2)预先制定可靠的系统回退方案,一旦升级失败,可采取快速回退,保障生产业务系统不受影响。

2 升级耗用的时间超过计划停机时间 业务系统运营延误 1)在测试环境升级演练中估算生产环境所需的升级时间,适当调整升级方案和计划。

2)升级前进行预演,保障升级最终方案的可行性。

升级后的风险及规避方法

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 客户端应用与服务器端不兼容 应用不稳定或不可用 1)尽管Oracle 11g数据库对10g的应用是兼容的,为保证应用系统在升级后运行的稳定性和高效性,Oracle ACS实施团队建议数据库升级前,应用开发商做较全面的应用功能测试,以验证客户端应用与11g数据库的兼容性。

2)如环境或资源的限制,不能作到应用的全面测试,但也要保证重点业务应用的测试。

3)Oracle ACS实施团队将依据以往的项目实施经验,提供与应用密切相关的数据库重点测试内容,例如设置新的11g数据库参数、数据库分区、数据库并行处理操作、物化视图、Data Guard等测试。

4)建议将客户端也升级到11g,并重新对原有应用进行link操作。

2 部分应用的性能降低 部分业务处理无法正常进行 同上
3 数据库运行不稳定 生产运营受到影响 1)在测试环境进行充分的压力测试,提早发现潜在问题,通过Oracle的支持找到解决办法;

2)升级后如数据库出现问题,可通过Oracle内部关键支持力量(包括产品研发部门)对系统问题提供及时响应和解决;

4 与CICS等存在不兼容性 应用不稳定或不可用 1) 相关厂商提供CICS等支持11g的认证信息

2) 在11g client环境重新编译应用程序

3) 在测试环境充分进行集成测试

人员的风险

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
 

1

项目组成员不能到位 项目计划无法正常执行 尽早提出和确定项目实施计划,以便客户方及时安排主要人员的工作
 

2

项目组成员缺乏足够的知识和技能 不能完成项目工作计划所赋予的任务,影响后续工作的进行 安排相关人员的技术交流

强调各类技术人员的配合工作

对项目组人员进行系统的专业培训

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

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1. 显著改变项目范围 由于需要额外的时间来研究范围变更的后果,因而可能使项目延期 分阶段进行项目的实施。每一阶段都制定切实可行的目标和时间要求。

项目开始前双方同意有关范围目标和实施方法的一般原则,尽量不变。

正式提交变更请求前认真考虑时间、成本和产出的三角制约关系。

按照范围变更的优先级别作不同的处理。

2. 不能及时地审阅和签署项目组提交的文档 影响后续任务的开展,可能使项目延期 在审核代表不能履行职责时,应指定代理人。

事先制定有关规则,按照签署文档的重要程度分别指定签字代表。

将需要签字的文档分为较小的若干个内容单一的文档分别签字。

3. 签字代表不能对提交文档作出决定 影响后续任务的开展,可能使项目延期 及时提交至有决定权的领导层

请Oracle有关人员作出进一步说明解释

将需要签字的文档分为较小的若干个内容单一的文档分别签字。

4. 项目时间计划比较紧张 没有足够的时间对前一个任务进行处理,经常会导致下一任务的延期 合理进行任务划分、任务衔接安排、项目组人员调配

 

 

 

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

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升级的经验教训,此次升级项目客户明显加大了各方面的投入,以下就是客户专门为此次升级项目而组建的项目组结构:

upgrade17

 

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

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

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

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

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

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

序号 资料类别 资料名称 资料概述
       
1. Oracle 11g R2联机文档 《Oracle® Database Upgrade Guide》 Oracle 11g R2联机文档中关于数据库升级的不得不看的专门文档。
2. My Oracle Support 《Master Note For Oracle Database Upgrades and Migrations (Doc ID 1152016.1)》 有关Oracle数据库升级和迁移的主文档目录。
3. My Oracle Support 《Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]》 手工升级到11g R2的完整操作步骤文档。
4. My Oracle Support 《Upgrade / Downgrade Assistant: Oracle Database/Client (Doc ID 1561791.2)》 Oracle数据库升级/降级及迁移的帮手,帮你快速找到相关文档、技术资源、下载的版本和补丁等。
5. My Oracle Support 《Different Upgrade Methods For Upgrading Your Database (Doc ID 419550.1)》 该文档介绍了DBUA、手工升级、Export/Import、Data Copying、GoldenGate等多种升级方案。
6. My Oracle Support 《Database Server Upgrade/Downgrade Compatibility Matrix (Doc ID 551141.1)》 该文档描述了Oracle数据库版本升级和降级的路线图。
7. My Oracle Support 《Best Practices to Minimize Downtime During Upgrade (Doc ID 455744.1)》 如何降低升级期间的停机时间窗口?该文档给出了相关最佳实践经验。
8. My Oracle Support 《How to estimate the time required to upgrade a database? (Doc ID 739485.1)》 如何估算数据库升级时间?其实升级过程取决于太多因素,Oracle也只能在这篇文档给出一些原则性建议。
9. My Oracle Support 《Oracle 11gR2 Upgrade Companion (Doc ID 785351.1)》 Oracle 11g R2有关升级的辅助文档。
10. My Oracle Support 《Complete checklist for out-of-place manual upgrade from previous 11.2.0.N version to the latest 11.2.0.N patchset. (Doc ID 1276368.1)》 Oracle 11.2.0.2及之后的Patchset是一个完整的版本,如何进行11.2.0.2之后的Patchset安装?该文档给出了完整的手工操作步骤。
11. My Oracle Support 《Master Note for Real Application Testing Option (Doc ID 1464274.1)》 Oracle有关RAT技术的资料汇集地。
12. My Oracle Support 《Master Note: Plan Stability Features (Including SQL Plan Management (SPM)) (Doc ID 1359841.1) 》 Oracle有关SPM技术的资料汇集地。

 

 

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569