ORACLE RAC数据库系统备份对信息安全的价值初探

中国信息界２０１０年第９期　总第１５３期　实践与应用　ＯＲＡＣＬＥ　ＲＡＣ数据库系统备份对信息安全的价值初探　王祥　（国家广播电影电视总局信息中心北京１　００８６６）　

摘要：ＯＲＡＣＬＥ　ＲＡｃ数据库系统以多实例共享存储数据的集群架构为基础，来承载应用层数据的存／取操作。　对数据面临的共享磁盘失效、人为逻辑错误、软件故障、病毒破坏等威胁因素，必须在数据库之外采取有力　措施加以防范，最有效的手段就是对系统当中的数据进行备份，来解决安全问题。　关键词：ＯＲＡＣＬＥ　ＲＡＣ数据库系统备份　

１　ＯＲＡＣＬＥ　ＲＡＣ系统综述　１．１ＯＲＡＣＬＥ　ＲＡＣ系统体系结构　ＯＲＡＣＬＥ　ＲＡＣ数据库系统以多实例共享存储数据的　集群架构为基础，来承载应用层数据的存／取操作，它基本　的体系架构如下图所示。　

幽　

■　Ｏ●ｔＡＣＬＩＥ队ｃ体系结稠　通常来讲，组成集群的每个服务器平台上运行一个数　

据库实例，这些实例负责对同一数据库物理文件进行存／取　访问，所有的实例从操作数据库的角度来看是平等的，所　需要操作的数据库数据存放在共享的磁盘阵列上。　数据库本身的物理文件主要包括控制文件、数据文　件、重做目志文件、归档日志文件以及数据库软件自　身的安装文件（在ＯＲＡＣＬＥ—ＨＯＭＥ所在的目录中）。　ＯＲＡＣＬＥ　ＲＡＣ在工作时，所有的实例需要根据同一个控制　文件定义的数据文件结构来操作物理数据文件，因此，控　制文件及数据文件必须放在共享的磁盘阵列上。在日志管　理上，每个实例单独负责其自身对数据库操作的归档，实　例彼此之间不发生干涉，因￣ｋＯＲＡＣＬＥ　ＲＡＣ对重做日志文　件及归档日志文件的存放位置不做硬性要求，也就是说，　既可以放在本地硬盘上，也可以放在共享的存盘位置上，　只要文件在能被实例所在的节点识别的位置上，都可以放　重做日志及归档日志。同样，每个实例的数据库软件的安　装位置也是既可以在本地磁盘，也可以在共享存储上。　在ＯＲＡＣＬＥ　ＲＡＣ的集群架构下，集群注册软件及表　决磁盘是协调整个集群当中所有实例的中枢机构，是全部　实例共享的，因此其存储位置也必须在共享磁盘阵列上。　因为系统出现问题时，上述的各种文件彼此之间可以　相互修复及补救，在存放时，建议把必须共享的控制文　件、数据文件、ＯＣＲ及ｖｏｔｉｎｇ　ｄｉｓｋ放在共享磁盘阵列上，　其它的文件放在实例各自所有的主机本地磁盘空间当中。　１．２ＯＲＡＣＬＥ　ＲＡＣ系统高可用级别　ＲＡｃ系统在性能、高可用、扩展性、负载均衡上都做　了充分的考虑，在很大程度上保证了ＲＡＣ系统的完善程　度。但ＲＡＣ系统还不能解决如下特定的问题。　１．２．１共享磁盘阵列的失效　ＯＲＡＣＬＥ　ＲＡＣ系统采用共享存储的架构，共享磁盘　阵列是数据存储的唯一地点，虽然高端存储设备在稳定性　及高可用性上有很多的先进技术作保障，但还是不能达到　１００％的高可用，一旦磁盘阵列失效，数据将不可再生，对　整个数据库系统将是毁灭性的打击，这样的后果是任何政　府部门及企业用户都不能承受的。　１．２．２人为逻辑错误　ＯＲＡＣＬＥ　ＲＡｃ能提供很好的系统高可用特性，但它　会响应一切对数据库操作的动作，只要是通过验证的数据　库操作，它都认为是合法的。而这些动作里边会有一定比　例的人为错误，比如误删除一张表，那么这样的ＤＭＬ语句　将直接作用到数据库当中，并且会作为结果永久保存，数　据库的操作具有不可逆转的特性，这样的人为错误也将不　可恢复。　１．２．３软件故障　除了人为错误之外，数据库系统软件故障也是导致数　据库系统不可用的重要因素，软件故障在一般情况下不　会出现，但在极端的情况下，还是会有很高比例的出现频　率，比如突然的断电事故就会很可能导致系统当中的ＣＲＳ　或者ｖｏｔｉｎｇ　ｄｉｓｋ￣效，整个系统就会出现不可用状态，修复　ＣＲＳ及ｖｏｔｉｎｇ　ｄｉｓｋ则可能影响到在线系统数据的安全及整个　系统修复之后的可用状态。　

４７　实践与应用　中国信息界２０１０年第９期总第１５３期　１．２．４病毒破坏　病毒破坏具有不可预料及无明显规律的特点，随着病　毒种类的增多，数据库系统受病毒的威胁产生的危险系数　也在逐渐提高。ＯＲＡＣＬＥ　ＲＡＣ数据库系统本身对病毒的　抵抗能力有限，必须有系统之外采取安全措施加以防范。　１．３ＯＲＡＣＬＥ　ＲＡＣ系统备份必要性　ＯＲＡＣＬＥ　ＲＡＣ系统当中的数据是整个数据库系统的　核心内容，对数据面临的共享磁盘失效、人为逻辑错误、　软件故障、病毒破坏等威胁因素，必须在数据库之外采取　有力措施加以防范，最有效的手段就是对系统当中的数据　进行备份，来解决上述的安全问题。数据的备份，对整个　数据库系统的安全保证是极其必要的，是数据库系统安全　的最后一道防线。　备份是保证整个系统高可用的重要技术手段，　ＯＲＡＣＬＥ　ＲＡＣ系统配合一定的备份手段，将使整个系统　在任何问题出现情况下都有高可用方面的应对措施，让整　个数据库系统呈现出优异的健壮性。　２　ＯＲＡＣＬＥ备份与恢复概述　２．１　ＯＲＡＣＬＥ数据库备份类型　ＯＲＡＣＬＥ数据库通常有两种备份类型，即逻辑备份和　物理备份。　逻辑备份即将表中的数据进行逻辑的导出，形成ＳＱＬ　语句的批处理文件，在恢复时候模拟ＳＱＬ语句重新在表中　生成数据。在ＯＲＡＣＬＥ　ＤＡＴＡＢＡＳＥ　９Ｉ之前，使用ＩＭＰ／　ＥＸＰ工具，在ＯＲＡＣＬＥ　ＤＡＴＡＢＡＳＥ　１０Ｇ之后，使用数据泵　体系结构来支持逻辑的备份与恢复，它包括数据泵导出程　序ＥＸＰＤＰ￣数据泵导入程序ＩＭＰＤＰ。对于逻辑备份来讲，　恢复是全表级别，不可能将数据库恢复到某个具体的时间　点或者某个特定状态。　物理备份是将实际组成数据库的操作系统文件从一处　拷贝到另一处的备份过程，通常是从磁盘到磁带、磁盘到　磁盘、或者磁盘到虚拟带库。在进行物理备份的时候，在　数据库关闭情况下，可以使用操作系统命令进行数据库的　物理备份。但在ＲＡＣ情况下，因为文件系统的结构比较　复杂，￣Ｉ］ＡＳＭ作为磁盘管理系统情况下，操作系统命令　无法操作物理文件，这时候就需要用ＯＲＡＣＬＥ自身的备份　工具来进行备份，在这点上ＯＲＡＣＬＥ提供了一个极其出色　的备份工具——０ｒａｃｌｅ恢复管理器（Ｒｅｃｏｖｅｒｙ　Ｍａｎａｇｅｒ，　ＲＭＡＮ）作为物理在线的备份工具，在线备份时，数据库　对外正常提供服务。　２．２ＯＲＡＣＬＥ恢复管理器（ＲＭＡＮ）简介　ＲＭＡＮ是ＯＲＡＣＬＥ中的一个独立的应用程序，它负责　建立到ＯＲＡＣＬＥ数据库的客户端连接，以访问数据库内部　的备份与恢复数据包。ＲＭＡＮ实用程序有一种独特的、有　序的、可预测的用法来完成所有的备份、还原、恢复和处　理备份工作。　ＲＭＡＮ做备份时，是通过控制文件来获取数据库的结　构信息，根据控制文件中记录的物理文件，来完成备份，　控制文件在备份过程中起到至关重要的作用。　２．３控制文件的作用　控制文件平时的作用是负责数据库的物理结构。顾名　思义，控制文件控制数据库查找物理文件的位置，并控制　每个文件当前包含的头信息，其内容包括数据文件信息、　重做日志信息和归档日志信息。控制文件当中还含有与数　据库关联的关键文件的每个文件头的快照。正是因为控制　文件包含有丰富的信息，所以在ＲＭＡＮ会利用控制文件获　取备份所需的信息，具体的操作方法是：ＲＭＡＮ使用控　制文件来编译文件列表，得到检查点信息，并确定可恢复　性。通过直接访问控制文件，ＲＭＡＮ可以编译文件列表而　不需要用户创建文件列表，这样避免了备份脚本时的一个　非常繁琐的步骤，并且在添加一个新文件时不需要更改这　个脚本。控制文件会存储新文件的信息，因此ＲＭＡＮ也能　从控制文件中得到这个信息。　控制文件还用做ＲＭＡＮ目录。ＲＭＡＮ完成数据库任何　部分的备份后，会在控制文件中添加该备份的记录，以及　说明备份开始和结束时问的检查点信息。控制文件中的这　些记录通常称为无数据，它与实际备份中记录数据相关。　ＲＭＡＮ备份出来的文件称为备份集。　

３　ＯＲＡＣＬＥ　ＲＡＣ系统备份与恢复方案　３．１　ＯＲＡＣＬＥ数据库恢复逻辑　３．１＿１还原与恢复的概念　数据库中的数据状态对数据库是非常重要的，在数据　库启动时要求数据库与给定的时间状态一致。如果数据库　是一致的，则可以打开这个数据库；如果数据库不是一致　的，就不能打开这个数据库。在出现数据库遭到破坏情况　下，需要重建数据库时，需要经历两个主要阶段，一个阶　段是还原，一个阶段是恢复。　在ＯＲＡＣＬＥ恢复体系中，还原与恢复是两个不同的概　念，具有完全不同的含义。还原是指访问先前生成的备份　集，从中得到一个或多个对象，然后在磁盘上的某个位置　还原这些对象。恢复是批一个使数据库与给定时间点相一　致以保证能够打开这个数据库的实际进程，该进程通常是　通过应用联机重做日志和归档的重做日志来完成的。　在经历过还原与恢复之后，数据库达到一致的状态，　可以打开数据库，则标志恢复成功。　３．１．２ＯＲＡＣＬＥ数据库恢复过程　启动数据库恢复时，先要恢复参数文件，参数文件中　记录控制文件应该恢复到什么位置，恢复完初始化参数文　件后，再恢复控制文件，控制文件一旦恢复成功，则整　个数据库的物理结构就已经确定，接着还原数据文件，　ＲＭＡＮ会从先前的备份集中提取数据文件，转换数据格　式并复制到控制文件中定义的位置，最后应用归档日志及　在线重做目志使数据库处于一致状态，从而最终打开数据　库，完成整个恢复过程。　中国信息界２０１０年第９期总第１５３期　实践与应用　３．２ＯＲＡＣＬＥ系统备份要素　从恢复的过程可以看出，ＯＲＡＣＬＥ数据库系统备份　时，重点是备份如下几方面内容，以给恢复提供必要的原　始数据支持。　（１）初始化参数文件；　（２）控制文件；　（３）数据文件；　（４）归档日志文件。　３．３ＯＲＡＣＬＥ　ＲＡＣ独特的备份问题　前面已经提及，ＲＡＣ集群包括多个不同的服务器。每　个服务器都具有自己的内存和本地磁盘，并且都连接到一　个共享的磁盘阵列。ＯＲＡＣＬＥ通过创建多个实例来使用这　个体系结构，每个节点上有一个实例，具有各自的ＳＧＡ／　ＰＧＡ内存区域。每个实例都具有自己的重做曰志，全部节　点上重做日志的累积，才是数据库的数据变化的完全日　志，在备份时，必须对全部节点上的归档日志进行备份。　而通常情况下，一个节点上的日志，是不能被其它节点所　访问的，必须通过一定的技术手段，让节点问能彼此相互　访问日志。　所有控制文件和数据文件在多个实例之问共享，这意　味着只有一个数据库但同时有多个线程被用来访问和更新　这个数据库的数据。　从ＲＭＡＮ角度来讲，这样的体系结构会在执行备份　操作时产生一些需要注意的问题。首先，多个实例同时运　行，但ＲＭＡＮ只能连接到其中一个节点，虽然在备份数据　库文件时不会引起问题，但是备份归档日志时就会产生一　个问题：每个实例都会将自己的重做日志归档到本地驱动　器，而不是归档到共享磁盘，这样的话，就需要对日志的　备份进行特殊处理。　３．４０ＲＡＣＬＥ　ＲＡＣ数据文件备份方案　ＲＡＣ环境中的数据文件备份与单节点的数据库中的　数据文件备份非常相似：ＲＭＡＮ连接到一个节点并执行　ｂａｃｋｕｐ　ｄａｔａｂａｓｅ命令。ＲＭＡＮ执行备份操作所需要的内存是　从这个节点中得到的，如果在磁盘上备份数据，备份就位　于节点本地；如果在磁带上备份数据，就必须配置实例集　成介质管理工具。　ＲＡＣ环境中的数据文件备份的唯一问题是在单个节点　上放置了过多的负荷。用户可以在单个节点上进行备份，　但出于备份性能的考虑，建议让ＲＭＡＮ最初压力较小时，　只连接到单个节点，但在实际的备份操作期间，如果数据　量比较大，ＲＭＡＮ可以在所有节点上分配通道。　随后，我们可以运行备份操作，同时在Ｒ＾ｄＡＮ在两个节　点问展开工作。将数据库中的数据文件平均分配到两个节点　上同时备份，从而提高备份的性能，缩短备份的时间窗口。　ＯＲＡＣＬＥ　Ｄａｔａｂａｓｅ　１０Ｇ对备份功能进行了增加，如果　将备份操作扩展到多个节点，则在其中一个节点失效情况　下，ＲＭＡＮ可以智能地将备份任务迁移到其它健康节点上　进行备份，从而提高并行备份时的可靠性。　建议在备份时，根据系统的实际运行情况，动态的进　行备份方式的调整，数据量小且对备份窗日要求比较大　时，采用在一个实例上分配通道，如果数据量较大，时问　窗口比较小，则采用并行备份的方式。　３．５ＯＲＡＣＬＥ　ＲＡＣ归档文件备份方案　由于每个节点只负责自己的归档操作，也就是说每个　节点都只能访问自己的非共享文件，因此归档日志备份比　数据文件备份复杂许多。如果只连接到一个节点并执行　ｂａｃｋｕｐ　ａｒｃｈｉｖｅｌｏｇ　ａｌｌ命令，ＲＭＡＮ就在控制文件中查找来　自所有节点的归档日志的列表。但是当查看本地节点时，　ＲＭＡＮ将只显示来自该节点的归档日志并显示出错。　在备份时，必须通过一定的技术手段，让节点之间能　相互访问归档日志。　我们可以把归档日志写入到共享磁盘阵列上的原始分　区，但在使用原始分区时，每个分区只能写入一个文件，　也就是说我们必须事先知道所有归档日志文件的名称并且　创建到每个归档日志所在的分获的符号连接，这会带来许　多管理上的额外工作。不建议使用这个的方式，在处理归　档的相互访问上，建议使用集群文件系统或者ＯＲＡＣＬＥ的　ＡＳＭ管理的共享磁盘卷。　ＲＭＡＮ具有称谓自动定位的功能，这个功能标识归　档日志所属的节点，并且只从该节点尝试备份这些归档日　志。通过这样的方式，我们就不必在ＲＭＡＮ中指定需要备　份的归档日志位于哪个节点上，ＲＭＡＮ可以确定这些备份　的日志。　如果想从单一的节点上备份全部的归档日志，则必须　让这个节点有权限能够访问其它节点上的归档日志，网络　文件系统是推荐的一种可行方案。用ＮＦＳ的方法可以让备　份节点加载其他归档日志位置。比如，节点ＮＯＤＥ１上的　本地归档日志存储在／ｕＯ１／ｐｒｏｄｌ／ａｒｃｈ目录中，在这个节点　上，我们可以ＮＦＳ￣Ｈ载节点ＮＯＤＥ２上的／ｕ０１／ｐｒｏｄ２／ａｒｃｈ　驱动器为／ｕ０１／ｐｒｏｄ２／ａｒｃｈ。这样运行归档日志备份时，　ＲＭＡＮ在控制文件中检查归档日志目的地，虽然只连接　到了ｉｎｓｔａｎｃｅ１实例，但是ＲＭＡＮ会发现两个归档日志目的　地。如下图所示。