1、硕 士 学 位 论 文论文题目: Oracle 数据库容灾技术应用与研究RESEARCH ON ORACLE DATABASEDISASTER TECHNOLOGY作 者专 业导 师合 作 导 师2009年 4 月 5 日原创性声明和关于论文使用授权的说明原 创 性 声 明本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究所取得的成果。除文中已经注明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研究作出重要贡献的个人和集体，均已在文中以明确方式标明。本声明的法律责任由本人承担。论文作者签名： 日期： 关于学位论文使用授权的声明本人完全了解山东大
2、学有关保留、使用学位论文的规定，同意学校保留或向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅；本人授权山东大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或其他复制手段保存论文和汇编本学位论文。（保密论文在解密后应遵守此规定）论文作者签名： 导师签名: 日期： 目 录摘 要IABSTRACTII第一章绪论11.1 系统开发背景11.2 国内外研究现状21.3 解决的主要问题31.4 本文的主要工作41.5 论文的组织结构5第二章相关知识综述62.1 oracle备份概述62.2 备份与容灾的区别72.2.1 当数据库运行在非归档模式下72.2.
3、2 当数据库运行在归档模式下82.3 容灾的范围与衡量指标9第三章 并行服务器技术 Rac103.1 Rac技术特点103.2 Rac体系结构113.2.1自动存储管理113.2.2 Rac对网络的需求12第四章 建立容灾体系204.1 建立容灾体系的指导方法204.2 建立本地的数据备份214.2.1 通过Exp备份本地数据214.2.2 通过Rman备份本地数据234.3建立用户错误的数据容灾274.3.1 安装Logminer274.3.2创建数据字典文件274.3.3创建日志文件列表284.3.4日志分析294.3.5观察分析结果304.4建立本地应用容灾304.4.1硬件环境304.
4、4.2操作系统及数据库软件304.4.3操作系统准备314.4.4共享磁盘设备344.4.5安装Ocm364.4.6安装Oracle软件394.4.7创建数据库414.4.8启动第二个节点实例454.4.9测试使用RAC46第五章 测试容灾系统495.1测试大量数据丢失495.1.1使用Imp恢复数据库495.1.2使用Rman恢复数据库505.1.3测试分析525.2测试用户错误修改数据525.2.1使用Logminer恢复数据525.2.2测试分析555.3测试并行数据库中某节点失效555.3.1Rac负载均衡测试555.3.2Rac失败切换测试565.3.3测试分析58第六章 结论59参
5、考文献.61致 谢62CONTENTSABSTRACTIChapter 1Introduction11.1 The system develops background11.2 research present condition21.3 Key problem of resolve31.4 Textual main work41.5 The organization structure5Chapter 2 Related knowledge overview62.1 oracle backup62.2 Backup and disaster72.2.1 Archive mode72.2.2
6、No archive mode82.3 scope of disaster9Chapter 3 Rac103.1 Rac technique characteristics103.2 Rac system structure113.2.1 Auto save to manage113.2.2 Need of Rac to network.12Chapter 4 establishment permits disaster system204.1 method of disaster system.204.2 The establishment native data backup.214.2.
7、1 Pass the Exp backup native data214.2.2 Pass the native data of the Rman backup.234.3 customers mistakes permit disaster.274.3.1 Install Log miner.274.3.2 Establish data dictionary274.3.3 Establish the daily record.284.3.4 Analytical.294.3.5 Observation analysis result304.4 native application disas
8、ter.304.4.1 Hardware environments.304.4.2 Operate systems and database software.304.4.3 Operate systems prepare.314.4.4 Share disk equipments.344.4.5 Install Ocm364.4.6 Install Oracle software.394.4.7 Establish a database.414.4.8 Start the second example.454.4.9 Tests use RAC.46Chapter 5 test permit
9、s disaster system.495.1 test data to throw to lose.495.1.1 Usage Imp instauration databases.495.1.2 Usage Rmans.505.1.3 Tests are analytical.525.2 test customer false modification data.525.2.1 Instauration data of the usage Log miners.525.2.2 Tests are analytical.545.3 test some node wrong.555.3.1 R
10、ac loads a balanced test555.3.2 Rac failure cuts over a test.565.3.3 Tests are analytical.57Chapter 6 conclusion59References.61Thanks62摘 要随着企业的快速发展，对应用系统的依赖程度越来越高，需要应用系统提供高可用性、高可靠性的系统。基于这种需求，从而建立容灾系统，来满足企业生产的需要。容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处
11、，使得该系统功能可以继续正常工作。冗余会带来额外的资金投入，但是对于关键性的应用却是十分必要的。无论是人为灾难还是自然灾难，灾难总会发生。这意味着必须有一个安全的系统，在发生服务器故障时能够把恢复时间尽量减少到最少，使用户感觉不到停机时间。本文的目的是为了完善和改进传统的容灾方式。首先分析数据库应用的现状，采用数据库的EXP技术和Rman技术备份本地数据，使用Logminer恢复用户修改的数据。在此基础上，建立本地应用容灾的环境，安装OCM、Oracle，并创建数据库，配置节点，设置容灾体系的环境。然后，测试大量数据丢失的情况。首先使用IMP、Rman进行恢复，结果显示需要的时间较长，对连续性
12、应用有较大影响。其次使用Logminer恢复数据，结果说明所需时间较短，但只能对一部分用户的修改进行恢复。最后采用Rac技术进行数据测试。结果证明，Rac技术可以保证数据库系统不间断提供服务，即使集群中有的节点出现故障，只要集群中存在一个可用节点，客户端的应用程序就不受影响，而且连接到故障节点的客户端会被自动转移到有效节点上。这个过程用户是感觉不到的。通过上述实践过程，证明了Rac技术可以预防单节点数据库失败的情况，能够达到预期的本地数据库容灾应用的目的。关键词：Oracle; 容灾;数据备份;并行数据库;日志ABSTRACTAlong with the fast development of
13、 business enterprise, more and more dependence to the apply system, it need to apply system provide usable and dependable system. According to this kind of need, then build up disaster system to satisfy the demand that the business production. The disaster system means to be the system that been sep
14、arated farther land, so build up two sets or several IT systems of function homologies, mutual systems can carry on healthy appearance surveillance and function to cut over and be a system stop because of accident (like a fire, earthquake.etc.) work, the whole applied system can cut over another pal
15、ace, make that system function be able to continue normal work. The redundancy will bring additional funds devotion, but for decisive application, it is very necessary. Neither regardless artificial disaster nor a natural disaster, disaster cant avoid. This mean must have a safety system can as far
16、as possible reduce time of instauration to at least.The research purpose of this article is for solving to existent relatively fall behind of method. First the present condition of analytical database application, EXP technique and the backup native data of the Rman technique of adoption database, u
17、sage log miner instauration the customer modify of data. Build up the environment that the native application permits a disaster on this foundation, then OCM, Oracle, and establish a database, install node; the constitution permits the environment of disaster system. Then, test a great deal of circu
18、mstance that the data throws to lose. Use IMP, Rman to carry on instauration first, the time of result manifestation is longer, to continuous application influenced. Secondly use a Log miner instauration data, result time that elucidation need be shorter, but can carry on instauration to a part of c
19、ustomers modification. Finally adopt a Rac technique to carry on a data test. Prove as a result that the Rac technique can without a break provide a service by assurance database system and even gather to have in the cluster of the node appear breakdown, as long as gather to exist 1 in the cluster c
20、an use node, the customer carry of the applied procedure be uninfluenced, and link to break down node of customers carry will be transferred valid node automatically up. Through above-mentioned practice process, prove the Rac technique can prevent single node database from fail of circumstance, can
21、attain the purpose that the anticipant native database permits a disaster application.KEYWORD: Oracle 、Disaster 、Backup 、Rac 、Logminer第一章 绪论1.1 系统开发背景计算机系统在为业务的迅猛发展提供信息技术基础架构的同时，也带来了以往我们不曾发觉的负面因素。例如由于信息和处理的高度集中使业务运转过度依赖于IT系统，并会因为IT系统的突发问题而受到很大影响，严重的甚至可以导致业务系统无法正常进行。这些问题包括了进行系统检修和升级带来长时间的系统停机，系统自身的或者
22、人为的因素或事故发生后连锁性的扩大，以及不可预见的故障和突发性灾难等等。如何避免业务运转受到影响，或者使业务影响尽可能降到最低，这是每一个企业管理者必须考虑和重视的问题。可想而知，业务中断或者数据丢失将对企业产生巨大的影响。以金融业为例，在灾难停机2天内所受损失为日营业额的50%，如两星期内无法恢复信息系统，75%的公司将业务停顿，43%的公司将再也无法开业。这并非耸人听闻。在这个数据为王的年代，我们就要千方百计地保护数据，不仅要让系统本身日趋完美，还要考虑到问题出现后的应急措施，也就是我们通常所说的容灾备份。提高IT系统的高可靠性以及IT系统的容灾建设已不再是新鲜的话题了，随着许多用户实施业
23、务系统大集中，针对IT系统的高可靠性和容灾能力的需求日渐突出。然而，目前大多数容灾系统的建设还是存在许多问题的。这些问题中不仅有技术层面的缺陷，还有在流程和人员方面的不足。这些问题可能导致的直接后果就是当发生灾难时，根本无法实现应用系统的快速恢复，甚至可能导致业务运转的长时间灾难性中断。我们可以列举出其中的一些： 1. 仅从产品功能层面考虑问题，最终建设的容灾环境仅是一个多种产品的堆积。仅实现了数据的远程复制或者离线存放，没有进行灾难的各种场景测试和灾难预演，并缺乏灾难恢复机制和危机应对流程。发生灾难时，不知道到底数据或者系统能否恢复正常。 2. 进行了一定的测试和预演，但是缺少相应的灾难恢复
24、计划和特殊情况下的行动指南，更没有全面的业务连续性计划。在真正发生灾难时，百废待兴、千头万绪的情况下，没有依据和参考，可能无法顺利进行有关操作。 3. 有了灾难恢复计划等必要文档，但是没有及时的将IT系统，业务流程和管理人员等不断变化的信息更新，导致容灾手册成为一纸空文。 4. 具备了以上的要素，但是容灾系统的建设局限在IT部门，缺少业务部门的参与和管理高层的介入和全力支持。发生灾害时，IT系统能够恢复但是业务流程仍无法恢复运转。 1.2 国内外研究现状早在上世纪50年代，国外一些公司就开始对自己的重要数据进行备份保护。这些数据有的是纸介质形式，有的是电子数据，人们将其副本放置在另一个相对安全
25、的地点（即现在我们说的灾备中心的雏形）存放，以达到数据安全的目的。70年代的时候这种类似的数据容灾保护形式越来越普遍，到了80年代，美国市场上已经有了上百个专业公司。备份数据异地灾备中心存储模式的灾难恢复解决方案被那些视数据为生命，数据量巨大且数据集中的金融公司广泛采用。1983年美国联邦货币监管中心要求金融机构起草了有关数据灾难备份及恢复的指导性文件，主要强调数据库的备份和恢复，通过运送备份磁带到专门的存储地实现安全。此文件一直使用到1989年，联邦货币监管中心有了更详尽更成熟的一套数据安全相关资料。进入九十年代，计算机的迅速发展和普及冲击了灾难恢复行业。过去集中式的计算机使用模式变成了如今
26、分布式的网络架构使用，这种改变也给容灾行业带来了新的市场和机遇，更过的硬、软件产品有了用武之地。九十年代的中后期，出现了业务连续性的概念，并开始逐渐取代单纯的灾难恢复。与灾难恢复相比，业务连续性不只局限于传统的IT系统，而是涵盖了包括人为操作失误、网络故障、流程中断等。回顾以往，2001年9月11日，美国世贸中心双子大厦遭受了严重的恐怖袭击。根据Gartner Group的相关调查统计，在这两栋大楼中，共有1200家公司，其中仅400家公司执行了灾难恢复预案，而大多数公司因为没有建立灾难恢复系统，数据损毁、丢失，导致业务无法恢复，最后只能宣布倒闭。美国德克萨斯州大学的调查显示：只有6%的公司可
27、以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。美国明尼苏达大学的研究也表明，在遭遇灾难的同时又没有灾难恢复计划的企业中，将有超过60%的企业在两到三年后退出市场。而随着企业对数据处理依赖程度的递增，该比例还有上升的趋势。国际调查机构Gartner Group的调查显示，在经历大型灾难而导致系统停运的公司中有2/5再也没有恢复运营，剩下的公司中也有1/3在两年内破产。“9.11”事件后，Globe Continuity Inc. 对美国、英国、澳大利亚及加拿大共565个公司使用灾难备份中心的情况进行了调查，发现在拥有或租用了灾难备份中心的公司中，56%使用了商业化
28、的灾难备份服务，29%使用自有的灾难备份中心，15%在商业化灾难备份服务的基础上同时拥有自己的备份设施。两项相加，使用灾难备份服务外包的比例达到了71%。美国财政部金融局、美国联邦金融机构检查委员会、全美证券交易商协会、美国联邦金融机构检查委员会、美国联邦储备委员会、证券交易委员会、英国金融服务管理局、新加坡金融管理局、香港金融管理局等对金融行业的业务连续性都提出了明确的政策监管要求。 反观我国，计算机行业发展相对较为滞后，近十几年才有比较快速的飞跃。在为业务的迅猛发展提供信息技术基础架构的同时，也带来了以往我们不曾发觉的负面因素。例如由于信息和处理的高度集中使业务运转过度依赖于IT系统，并会
29、因为IT系统的突发问题而受到很大影响，严重的甚至可以导致业务系统无法正常进行。这些问题并不是经常会发生，但是一旦出现，后果将会很严重，会对企业的生产和经营带来很不利的后果。1.3 解决的主要问题数据库是一个很复杂的事物，对于它的数据保存，也有很多种方式方法，各种方法都有各自的优点与缺点。通过下面的实际情况进行分析：数据库应用的效率：基于FOC数据库有十几个应用系统，应用的特点各不相同，有的应用系统是联机事物处理（OLTP），有的是基于数据仓库的数据分析系统（OLAP）。OLTP系统要求数据库能够对用户的请求作出快速响应，OLAP系统对数据库产生巨大的数据量请求和计算分析，两个应用系统同时存在一
30、台数据库服务器上会影响应用系统的工作效率。现有的单台服务器无法做到把OLTP和OLAP两种不同类型的应用分开,在同一台服务器上使用相同的CPU与内存资源，资源的争用情况严重。 数据库的数据备份方式：FOC数据库的数据备份方式采用的是物理备份和逻辑备份，这两种备份方式能够保证数据的不丢失，但是两种备份方式在进行恢复数据库的时间可能要长达数小时，在恢复过程中所用的应用系统都无法访问数据库，会严重的影响企业的生产运行。数据库的应用备份方式：现有的FOC数据库没有应用备份，如果数据库服务器崩溃短，时间内无法恢复，需要准备一台新的备用服务器、安装操作系统、Oracle 数据库软件，然后使用数据备份进行恢
31、复，整个恢复过程可能需要一天的时间。在恢复过程中所用的应用系统都无法访问数据库，会严重的影响企业的生产运行。解决用户错误：现有的FOC数据库没有针对用户错误的处理方案，但是用户错误是经常出现的，当用户错误修改了数据或者数据库管理员错误的删除了表，需要进行数据库的恢复，恢复时间可能需要数小时。从上面的分析能够看出，现有的FOC数据库无法满足应用系统高可用性的需要，为了不让信息系统成为企业生产运行的瓶颈，必须要解决现有的容灾系统存在的问题。除了以上列出的问题之外，还有许多问题如容灾系统的负载能力估计不足，实施过程中没有严格遵循高可靠标准，实施过程工作界面过多沟通不足，日常运维管理方面存在不足和漏洞
32、，缺少厂商、系统集成商的后续支持服务等等都可能导致业务持续性系统建设的失败。另一类问题是项目小组仅将目光放在了大型灾难等突发事件的应对之上，而忽略了计划性停机对业务运行的影响。根据有关统计，非计划性停机只占13%的停机概率，而在非计划停机中大型自然灾难占的比例就更低了。所以在项目实施时，未能很好的优化现有系统和流程，没有充分发掘现有潜力，未能将日常操作流程和业务持续性目标充分整合，虽然实现了容灾但是仍没有从本质上解决持续性问题。1.4 本文的主要工作在现有数据库的基础上，分析了数据容灾的多种方法，并结合容灾思想的理论，设计了Rac数据库的容灾体系。首先，本文讨论了系统的开发背景以及所面对的问题
33、，介绍了在新形势下面临的挑战和机遇。在此基础上简单说明了本文中涉及到数据库的一些概念，并进行了业务操作设计以及系统化工作。阐述数据库的备份与数据库的容灾概念不同，并着重介绍了Rac并行服务器技术，以及Rac的技术特点和体系结构。其次，在系统的详细设计中，建立容灾体系。先用oracle数据库提供的工具，EXP、RMAN建立本地的备份数据；再用数据挖掘技术恢复用户修改的数据。然后，建立本地应用容灾系统。安装数据库，并创建实例等等。再次，在系统的实现与测试中，对系统的总体实现加以简单介绍，给出了系统的效果图。然后着重对测试的结果进行了详细分析。对数据进行了应用多种恢复方式的测试，先采用Imp、Rma
34、n做数据恢复，然后使用创建的Rac系统，进行负载均衡测试和失败切换测试。最后，本文对本设计的应用情况作了简单介绍，并对系统的设计和实现进行了总结，并提出了对数据库容灾技术的改进建议。1.5 论文的组织结构第1章 引言。主要描述数据库容灾技术的开发背景、国内外现状，本文解决的主要问题和完成的工作。第2章 相关知识综述。首先进行了数据库相关概念的概述。其次描述了该系统的系统目标和解决的问题。最后对容灾与备份的区别与共同点进行描述。第3章 并行服务器技术Rac。主要进行对并行服务器技术Rac的相关方面研究。首先对Rac的技术特点进行了阐述。其次，对并行服务器技术的体系结构进行了说明，并对后面要用到的
35、文件做了设置。第4章 建立容灾体系。本章主要进行系统设计。首先在系统部分，从Exp和Rman两个方面讨论了系统的设计，并且应用上述的两个工具对本地数据进行了备份。其次，建立用户错误的数据容灾，采用数据挖掘技术恢复用户修改的数据。最后，建立本地应用容灾系统。构建操作系统，安装数据库和实例，搭建并行服务器的平台。第5章 测试容灾系统。首先测试大量数据丢失的情况，采用Imp和Rman技术做数据恢复。其次，测试用户错误修改数据的情况。最后，测试并行数据库出现某节点失效的情况，并进行Rac负载均衡测试和失败切换测试。第6章 对论文进行了总结，并对系统的进一步提升提出了改进意见。第二章 相关知识综述2.1
36、 oracle备份概述冷备份是Oracle 最简单的一种备份，执行冷备份前必须正常关闭数据库，然后使用操作系统工具（例如copy命令）或者第三方工具备份所有相关的数据库文件。如果数据库在不正常的情况下关闭，数据库的控制文件和数据文件头以及联机重做日志可能处于不同步的状态，这种情况下进行冷备份无效。冷备份只是适合数据量不大，而且不要求应用系统必须7*24小时提供服务的情况。热备份相对于冷备份而言，就是不关闭数据库时做的备份。理解Oracle的热备份必须要先理解数据库归档的运行模式。数据库能够在两种模式下运行:归档、非归档。归档就是把联机重做日志进行备份，联机重做日志至少有2组，当一组联机重做日志
37、写满后，发生日志切换，LGWR进程会向另一组联机重做日志中写入，ARCn进程把刚记录满的一组联机重做日志拷贝到归档路径下。非归档模式就是数据库不使用ARCn进程进行归档，当日志进行切换时不会产生归档日志文件。Oracle数据库自身附带有备份工具，其中包括Exp工具。Exp是可以把用户数据以表为单位进行导出的工具，导出dmp格式的文件。Oracle 的Imp工具可以读取dmp文件，并且把数据导入某个帐户下进行数据恢复。Exp仅仅备份的是某个用户的数据，包括用户的表、索引、数、触发器等等，不能备份数据库级别的一些文件，包括控制文件、数据文件、归档文件、口令文件、参数文件。 Exp的原理是把数据库中
38、用户的对象全部进行处理，对象的定义转变成DDL语句写入dmp文件，表中的数据转化成insert的语句写入dmp文件中，在Imp导入时候重新建立用户下的对象，并且通过dmp文件中的DDL语句建立对象，通过insert语句写入数据。用Imp导入数据时还会产生大量的日志写入联机日志文件中，恢复的速度比较慢。而且Exp，Imp工具在不同的Oracle 数据库版本之间还有一定的限制，只能遵循由相同版本或者低版本的Exp来导出高版本数据库的数据，然后再由相同版本或者低版本的Imp向目标数据库中导入。Exp和Imp工具应用起来恢复速度较慢，但也有一定的优点。第一、Exp可以跨操作系统平台进行数据的备份恢复，
39、由Windows上的Oracle 数据库导出的dmp文件可以导入到Unix的Oracle数据库中。第二、可以在数据库不关闭的情况下做备份。可以作为数据库热备份的一种工具。可以用于归档或者非归档的数据库。第三、支持以表为单位导出数据，甚至可以支持导出表中的部分数据。Rman是Oracle 提供的另一种强大的备份工具，可以用于备份归档或者非归档的数据库，可以备份用户的数据文件、控制文件、归档日志文件、参数文件、口令文件。我们可以使用nocatalog方式来使用RMAN，此时控制信息记录在目标数据库的控制文件中，但这样不安全，因为一旦目标数据库的控制文件损坏就意味着所有的RMAN备份失效。Rman的
40、优点主要包括：第一、可在表空间或数据库文件级备份，备份的时间短。备份操作和恢复操作都可以并行，而且恢复时也不产生日志，加快备份和恢复的速度。第二、备份时数据库仍可使用。备份时不影响用户的操作，用户几乎没有感觉。第三、可达到秒级时间点恢复（恢复到某一时间点上）。使用数据库有效的备份和从有效备份开始到最新的归档日志，进行恢复时可以恢复到任何一个时间点。第四、可对所有数据库实体做恢复。适用于7*24不间断运行的关键应用系统。2.2 备份与容灾的区别上文对备份的概念作了简述，备份仅仅是数据的备份方式，能够保证用户数据的不丢失。不管使用何种备份方式，在恢复的时候都需要考虑下面几个方面。2.2.1 当数据
41、库运行在非归档模式下准备硬件与操作系统平台，安装Oracle 数据库软件，当用冷备份恢复时候需要使用操作系统级别的拷贝命令。当用Imp命令恢复时候需要先创建数据库，手工建立参数文件和控制文件，要保证新创建的数据库与原数据库的表空间、用户等完全一样，然后再使用Imp命令进行数据的恢复。2.2.2 当数据库运行在归档模式下准备硬件与操作系统平台，安装Oracle 数据库软件，使用Rman把数据文件，控制文件，参数文件恢复，然后应用归档日志对数据库作完全恢复，能够保证用户的数据不丢失。运行模式备份工具备份的范围关闭数据库恢复的范围备份、恢复速度非归档Exp用户数据不需要不完全恢复慢，使用DDL和DM
42、L语句冷备份所有的物理文件需要不完全恢复慢，受限制于操作系统Rman所有的物理文件不需要不完全恢复较快，可以使用并行归档Exp用户数据不需要不完全恢复慢，使用的DDL和DML语句冷备份所有的物理文件需要不完全恢复慢，受限制于操作系统Rman所有的物理文件不需要完全恢复较快，可以使用并行图2-1 备份工具的比较综上所述，数据库的容灾和备份应该是属于两个不同层次的概念，备份只是一种容灾的手段。通过备份数据只能保证数据的不丢失，不能保证数据库应用的连续性。容灾一般是采用冗余来预防单点故障的发生，冗余可以包括服务器的冗余，数据的冗余，网络的冗余等等。2.3 容灾的范围与衡量指标容灾的范围大体有下面几点
43、：1) 用户错误的解决：这是最常见的情况，但是很多系统都没有当用户错误对数据进行修改后采取的方案来做规划。用户的错误一般分为：l 使用应用系统的一般用户的错误：当用户更新一个错误的表或者更新错误的值时，这种类型的错误很难发现，也很难解决，因为它们对于数据库来说是很正常的事物，而不是错误。一般情况下用户的错误并不明显，而且总是伴随着大量的正确的事物的，如何能从所有的事物中找出可能错误的事物是用户错误容灾要考虑的问题。l 数据库管理人员的错误：数据库管理人员和一般用户相比，由于对数据库操作不同，所以可能发生不同的错误。比如误删除了一个表，对表的数据做更新不同，删除表是个灾难性的错误，它和平常的DM
44、L语句不同，是不能回滚的。一旦发出drop命令表就被删除。还有一种可能是truncate命令，它也是一条DDL语句，DDL语句都是不能回滚的，一旦发出truncate命令，表中的数据立刻会被清除，不产生任何的日志，虽然表的结构和约束等信息仍然存在但是数据却可能无法恢复。如何能从上述的错误中快速的部分的恢复数据而不需要对数据库进行完全恢复也是用户错误的容灾要考虑的问题。2) 数据的容灾：数据的容灾主要还是依靠传统的备份方式来完成的，前面有详细的讨论，这里不再说明。3) 应用的容灾：本地提供应用的服务器可能会发生单点故障，如果发生单点故障时，需要用户等待很长的时间来恢复应用，显然是不符合实际要求的。所以如何建立应用的容灾系统能够防止应用的容灾是非常重要的。最坏的情况总是会发生，如果对本地的应用建立了容灾系统，但是如果发生了大规模的自然灾害，导致本地的所有系统无法使用。为了预防这种情况的发生，异地的容灾系统也是需要考虑的问题。
