Oracle数据库容灾技术应用与研究

山东大学硕士学位论文硕士学位论文论文题目:Oracle数据库容灾技术应用与研究RESEARCHONORACLEDATABASEDISASTERTECHNOLOGY作者专业导师合作导师2009年4月5日原创性声明和关于论文使用授权的说明原创性声明本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究所取得的成果。除文中已经注明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研究作出重要贡献的个人和集体，均已在文中以明确方式标明。本声明的法律责任由本人承担。论文作者签名：日期：关于学位论文使用授权的声明本人完全了解山东大学有关保留、使用学位论文的规定，同意学校保留或向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅；本人授权山东大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或其他复制手段保存论文和汇编本学位论文。（保密论文在解密后应遵守此规定）论文作者签名：导师签名:日期：目录TOC\o"1-3"\h\z\uHYPERLINK\l"_Toc225692296"摘要IABSTRACTIIHYPERLINK\l"_Toc225692298"第一章绪论1HYPERLINK\l"_Toc225692299"1.1系统开发背景1HYPERLINK\l"_Toc225692300"1.2国内外研究现状2HYPERLINK\l"_Toc225692301"1.3解决的主要问题3HYPERLINK\l"_Toc225692302"1.4本文的主要工作4HYPERLINK\l"_Toc225692303"1.5论文的组织结构5HYPERLINK\l"_Toc225692304"第二章相关知识综述6HYPERLINK\l"_Toc225692305"2.1oracle备份概述6HYPERLINK\l"_Toc225692306"2.2备份与容灾的区别7HYPERLINK\l"_Toc225692307"2.2.1当数据库运行在非归档模式下7HYPERLINK\l"_Toc225692308"2.2.2当数据库运行在归档模式下8HYPERLINK\l"_Toc225692309"2.3容灾的范围与衡量指标9HYPERLINK\l"_Toc225692310"第三章并行服务器技术Rac10HYPERLINK\l"_Toc225692311"3.1Rac技术特点10HYPERLINK\l"_Toc225692312"3.2Rac体系结构11HYPERLINK\l"_Toc225692313"3.2.1自动存储管理11HYPERLINK\l"_Toc225692314"3.2.2Rac对网络的需求12HYPERLINK\l"_Toc225692315"第四章建立容灾体系20HYPERLINK\l"_Toc225692316"4.1建立容灾体系的指导方法20HYPERLINK\l"_Toc225692317"4.2建立本地的数据备份21HYPERLINK\l"_Toc225692318"4.2.1通过Exp备份本地数据21HYPERLINK\l"_Toc225692319"4.2.2通过Rman备份本地数据23HYPERLINK\l"_Toc225692320"4.3建立用户错误的数据容灾27HYPERLINK\l"_Toc225692321"4.3.1安装Logminer27HYPERLINK\l"_Toc225692322"4.3.2创建数据字典文件27HYPERLINK\l"_Toc225692323"4.3.3创建日志文件列表28HYPERLINK\l"_Toc225692324"4.3.4日志分析29HYPERLINK\l"_Toc225692325"4.3.5观察分析结果30HYPERLINK\l"_Toc225692326"4.4建立本地应用容灾30HYPERLINK\l"_Toc225692327"4.4.1硬件环境30HYPERLINK\l"_Toc225692328"4.4.2操作系统及数据库软件30HYPERLINK\l"_Toc225692329"4.4.3操作系统准备31HYPERLINK\l"_Toc225692330"4.4.4共享磁盘设备34HYPERLINK\l"_Toc225692331"4.4.5安装Ocm36HYPERLINK\l"_Toc225692332"4.4.6安装Oracle软件39HYPERLINK\l"_Toc225692333"4.4.7创建数据库41HYPERLINK\l"_Toc225692334"4.4.8启动第二个节点实例45HYPERLINK\l"_Toc225692335"4.4.9测试使用RAC46HYPERLINK\l"_Toc225692336"第五章测试容灾系统49HYPERLINK\l"_Toc225692337"5.1测试大量数据丢失49HYPERLINK\l"_Toc225692338"5.1.1使用Imp恢复数据库49HYPERLINK\l"_Toc225692339"5.1.2使用Rman恢复数据库50HYPERLINK\l"_Toc225692340"5.1.3测试分析52HYPERLINK\l"_Toc225692341"5.2测试用户错误修改数据52HYPERLINK\l"_Toc225692342"5.2.1使用Logminer恢复数据52HYPERLINK\l"_Toc225692343"5.2.2测试分析555.3测试并行数据库中某节点失效HYPERLINK\l"_Toc225692345"5.3.1Rac负载均衡测试55HYPERLINK\l"_Toc225692346"5.3.2Rac失败切换测试56HYPERLINK\l"_Toc225692347"5.3.3测试分析58HYPERLINK\l"_Toc225692348"第六章结论59参考文献……………………………………………………………………..61HYPERLINK\l"_Toc225692349"致谢62CONTENTSABSTRACT……………………………………………………………………………IChapter1Introduction……………………………………………………………11.1Thesystemdevelopsbackground……………………………………………11.2researchpresentcondition………………………………………………21.3Keyproblemofresolve……………………………………………………31.4Textualmainwork…………………………………………………………41.5Theorganizationstructure……………………………………………5Chapter2Relatedknowledgeoverview…………………………………………62.1oraclebackup………………………………………………………………62.2Backupanddisaster………………………………………………………72.2.1Archivemode…………………………………………………………72.2.2Noarchivemode……………………………………………………82.3scopeofdisaster………………………………………………………9Chapter3Rac………………………………………………………………………103.1Ractechniquecharacteristics………………………………………103.2Racsystemstructure……………………………………………………113.2.1Autosavetomanage………………………………………………113.2.2NeedofRactonetwork………………………………………..12Chapter4establishmentpermitsdisastersystem…………………………204.1methodofdisastersystem……………………………………………..204.2Theestablishmentnativedatabackup……………………………….214.2.1PasstheExpbackupnativedata………………………………214.2.2PassthenativedataoftheRmanbackup………………....234.3customer'smistakespermitdisaster………………………..…….274.3.1InstallLogminer………………………………………………….274.3.2Establishdatadictionary………………………………………274.3.3Establishthedailyrecord…………………………………...284.3.4Analytical……………………………………………………….294.3.5Observationanalysisresult…………………………………304.4nativeapplicationdisaster……………………………………….304.4.1Hardwareenvironments………………………………………..304.4.2Operatesystemsanddatabasesoftware…………………..304.4.3Operatesystemsprepare……………………………………..314.4.4Sharediskequipments………………………………………..344.4.5InstallOcm………………………………………………………364.4.6InstallOraclesoftware……………………………………..394.4.7Establishadatabase………………………………………….414.4.8Startthesecondexample…………………………………….454.4.9TestsuseRAC…………………………………………………..46Chapter5testpermitsdisastersystem…………………………………….495.1testdatatothrowtolose………………………………………..495.1.1UsageImpinstaurationdatabases………………………….495.1.2UsageRmans…………………………………………………….505.1.3Testsareanalytical……………………………………....525.2testcustomerfalsemodificationdata………………………..525.2.1InstaurationdataoftheusageLogminers…………….525.2.2Testsareanalytical……………………………………….545.3testsomenodewrong……………………………………………..555.3.1Racloadsabalancedtest…………………………………555.3.2Racfailurecutsoveratest…………………………….565.3.3Testsareanalytical………………………………………..57Chapter6conclusion…………………………………………………………59References………………………………………………………………………….61Thanks……………………………………………………………………………62摘要随着企业的快速发展，对应用系统的依赖程度越来越高，需要应用系统提供高可用性、高可靠性的系统。基于这种需求，从而建立容灾系统，来满足企业生产的需要。容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。冗余会带来额外的资金投入，但是对于关键性的应用却是十分必要的。无论是人为灾难还是自然灾难，灾难总会发生。这意味着必须有一个安全的系统，在发生服务器故障时能够把恢复时间尽量减少到最少，使用户感觉不到停机时间。本文的目的是为了完善和改进传统的容灾方式。首先分析数据库应用的现状，采用数据库的EXP技术和Rman技术备份本地数据，使用Logminer恢复用户修改的数据。在此基础上，建立本地应用容灾的环境，安装OCM、Oracle，并创建数据库，配置节点，设置容灾体系的环境。然后，测试大量数据丢失的情况。首先使用IMP、Rman进行恢复，结果显示需要的时间较长，对连续性应用有较大影响。其次使用Logminer恢复数据，结果说明所需时间较短，但只能对一部分用户的修改进行恢复。最后采用Rac技术进行数据测试。结果证明，Rac技术可以保证数据库系统不间断提供服务，即使集群中有的节点出现故障，只要集群中存在一个可用节点，客户端的应用程序就不受影响，而且连接到故障节点的客户端会被自动转移到有效节点上。这个过程用户是感觉不到的。通过上述实践过程，证明了Rac技术可以预防单节点数据库失败的情况，能够达到预期的本地数据库容灾应用的目的。关键词：Oracle;容灾;数据备份;并行数据库;日志ABSTRACTAlongwiththefastdevelopmentofbusinessenterprise,moreandmoredependencetotheapplysystem,itneedtoapplysystemprovideusableanddependablesystem.Accordingtothiskindofneed,thenbuildupdisastersystemtosatisfythedemandthatthebusinessproduction.Thedisastersystemmeanstobethesystemthatbeenseparatedfartherland,sobuilduptwosetsorseveralITsystemsoffunctionhomologies,mutualsystemscancarryonhealthyappearancesurveillanceandfunctiontocutoverandbeasystemstopbecauseofaccident(likeafire,earthquake...etc.)work,thewholeappliedsystemcancutoveranotherpalace,makethatsystemfunctionbeabletocontinuenormalwork.Theredundancywillbringadditionalfundsdevotion,butfordecisiveapplication,itisverynecessary.Neitherregardlessartificialdisasternoranaturaldisaster,disastercan'tavoid.Thismeanmusthaveasafetysystemcanasfaraspossiblereducetimeofinstaurationtoatleast.Theresearchpurposeofthisarticleisforsolvingtoexistentrelativelyfallbehindofmethod.Firstthepresentconditionofanalyticaldatabaseapplication,EXPtechniqueandthebackupnativedataoftheRmantechniqueofadoptiondatabase,usagelogminerinstaurationthecustomermodifyofdata.Builduptheenvironmentthatthenativeapplicationpermitsadisasteronthisfoundation,thenOCM,Oracle,andestablishadatabase,installnode;theconstitutionpermitstheenvironmentofdisastersystem.Then,testagreatdealofcircumstancethatthedatathrowstolose.UseIMP,Rmantocarryoninstaurationfirst,thetimeofresultmanifestationislonger,tocontinuousapplicationinfluenced.SecondlyuseaLogminerinstaurationdata,resulttimethatelucidationneedbeshorter,butcancarryoninstaurationtoapartofcustomer’smodification.FinallyadoptaRactechniquetocarryonadatatest.ProveasaresultthattheRactechniquecanwithoutabreakprovideaservicebyassurancedatabasesystemandevengathertohaveintheclusterofthenodeappearbreakdown,aslongasgathertoexist1intheclustercanusenode,thecustomercarryoftheappliedprocedurebeuninfluenced,andlinktobreakdownnodeofcustomer'scarrywillbetransferredvalidnodeautomaticallyup.Throughabove-mentionedpracticeprocess,provetheRactechniquecanpreventsinglenodedatabasefromfailofcircumstance,canattainthepurposethattheanticipantnativedatabasepermitsadisasterapplication.KEYWORD:Oracle、Disaster、Backup、Rac、Logminer第1章绪论1.1系统开发背景计算机系统在为业务的迅猛发展提供信息技术基础架构的同时，也带来了以往我们不曾发觉的负面因素。例如由于信息和处理的高度集中使业务运转过度依赖于IT系统，并会因为IT系统的突发问题而受到很大影响，严重的甚至可以导致业务系统无法正常进行。这些问题包括了进行系统检修和升级带来长时间的系统停机，系统自身的或者人为的因素或事故发生后连锁性的扩大，以及不可预见的故障和突发性灾难等等。如何避免业务运转受到影响，或者使业务影响尽可能降到最低，这是每一个企业管理者必须考虑和重视的问题。可想而知，业务中断或者数据丢失将对企业产生巨大的影响。以金融业为例，在灾难停机2天内所受损失为日营业额的50%，如两星期内无法恢复信息系统，75%的公司将业务停顿，43%的公司将再也无法开业。这并非耸人听闻。在这个数据为王的年代，我们就要千方百计地保护数据，不仅要让系统本身日趋完美，还要考虑到问题出现后的应急措施，也就是我们通常所说的容灾备份。提高IT系统的高可靠性以及IT系统的容灾建设已不再是新鲜的话题了，随着许多用户实施业务系统大集中，针对IT系统的高可靠性和容灾能力的需求日渐突出。然而，目前大多数容灾系统的建设还是存在许多问题的。这些问题中不仅有技术层面的缺陷，还有在流程和人员方面的不足。这些问题可能导致的直接后果就是当发生灾难时，根本无法实现应用系统的快速恢复，甚至可能导致业务运转的长时间灾难性中断。我们可以列举出其中的一些：  1.仅从产品功能层面考虑问题，最终建设的容灾环境仅是一个多种产品的堆积。仅实现了数据的远程复制或者离线存放，没有进行灾难的各种场景测试和灾难预演，并缺乏灾难恢复机制和危机应对流程。发生灾难时，不知道到底数据或者系统能否恢复正常。  2.进行了一定的测试和预演，但是缺少相应的灾难恢复 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 和特殊情况下的行动指南，更没有全面的业务连续性计划。在真正发生灾难时，百废待兴、千头万绪的情况下，没有依据和参考，可能无法顺利进行有关操作。  3.有了灾难恢复计划等必要文档，但是没有及时的将IT系统，业务流程和管理人员等不断变化的信息更新，导致容灾 手册 华为质量管理手册 下载焊接手册下载团建手册下载团建手册下载ld手册下载 成为一纸空文。  4.具备了以上的要素，但是容灾系统的建设局限在IT部门，缺少业务部门的参与和管理高层的介入和全力支持。发生灾害时，IT系统能够恢复但是业务流程仍无法恢复运转。1.2国内外研究现状早在上世纪50年代，国外一些公司就开始对自己的重要数据进行备份保护。这些数据有的是纸介质形式，有的是电子数据，人们将其副本放置在另一个相对安全的地点（即现在我们说的灾备中心的雏形）存放，以达到数据安全的目的。70年代的时候这种类似的数据容灾保护形式越来越普遍，到了80年代，美国市场上已经有了上百个专业公司。备份数据异地灾备中心存储模式的灾难恢复解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 被那些视数据为生命，数据量巨大且数据集中的金融公司广泛采用。1983年美国联邦货币监管中心要求金融机构起草了有关数据灾难备份及恢复的指导性文件，主要强调数据库的备份和恢复，通过运送备份磁带到专门的存储地实现安全。此文件一直使用到1989年，联邦货币监管中心有了更详尽更成熟的一套数据安全相关资料。进入九十年代，计算机的迅速发展和普及冲击了灾难恢复行业。过去集中式的计算机使用模式变成了如今分布式的网络架构使用，这种改变也给容灾行业带来了新的市场和机遇，更过的硬、软件产品有了用武之地。九十年代的中后期，出现了业务连续性的概念，并开始逐渐取代单纯的灾难恢复。与灾难恢复相比，业务连续性不只局限于传统的IT系统，而是涵盖了包括人为操作失误、网络故障、流程中断等。回顾以往，2001年9月11日，美国世贸中心双子大厦遭受了严重的恐怖袭击。根据GartnerGroup的相关调查统计，在这两栋大楼中，共有1200家公司，其中仅400家公司执行了灾难恢复预案，而大多数公司因为没有建立灾难恢复系统，数据损毁、丢失，导致业务无法恢复，最后只能宣布倒闭。美国德克萨斯州大学的调查显示：只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。美国明尼苏达大学的研究也表明，在遭遇灾难的同时又没有灾难恢复计划的企业中，将有超过60%的企业在两到三年后退出市场。而随着企业对数据处理依赖程度的递增，该比例还有上升的趋势。国际调查机构GartnerGroup的调查显示，在经历大型灾难而导致系统停运的公司中有2/5再也没有恢复运营，剩下的公司中也有1/3在两年内破产。“9.11”事件后，GlobeContinuityInc.对美国、英国、澳大利亚及加拿大共565个公司使用灾难备份中心的情况进行了调查，发现在拥有或租用了灾难备份中心的公司中，56%使用了商业化的灾难备份服务，29%使用自有的灾难备份中心，15%在商业化灾难备份服务的基础上同时拥有自己的备份设施。两项相加，使用灾难备份服务外包的比例达到了71%。美国财政部金融局、美国联邦金融机构检查委员会、全美证券交易商协会、美国联邦金融机构检查委员会、美国联邦储备委员会、证券交易委员会、英国金融服务管理局、新加坡金融管理局、香港金融管理局等对金融行业的业务连续性都提出了明确的政策监管要求。反观我国，计算机行业发展相对较为滞后，近十几年才有比较快速的飞跃。在为业务的迅猛发展提供信息技术基础架构的同时，也带来了以往我们不曾发觉的负面因素。例如由于信息和处理的高度集中使业务运转过度依赖于IT系统，并会因为IT系统的突发问题而受到很大影响，严重的甚至可以导致业务系统无法正常进行。这些问题并不是经常会发生，但是一旦出现，后果将会很严重，会对企业的生产和经营带来很不利的后果。1.3解决的主要问题数据库是一个很复杂的事物，对于它的数据保存，也有很多种方式方法，各种方法都有各自的优点与缺点。通过下面的实际情况进行分析：数据库应用的效率：基于FOC数据库有十几个应用系统，应用的特点各不相同，有的应用系统是联机事物处理（OLTP），有的是基于数据仓库的数据分析系统（OLAP）。OLTP系统要求数据库能够对用户的请求作出快速响应，OLAP系统对数据库产生巨大的数据量请求和计算分析，两个应用系统同时存在一台数据库服务器上会影响应用系统的工作效率。现有的单台服务器无法做到把OLTP和OLAP两种不同类型的应用分开,在同一台服务器上使用相同的CPU与内存资源，资源的争用情况严重。数据库的数据备份方式：FOC数据库的数据备份方式采用的是物理备份和逻辑备份，这两种备份方式能够保证数据的不丢失，但是两种备份方式在进行恢复数据库的时间可能要长达数小时，在恢复过程中所用的应用系统都无法访问数据库，会严重的影响企业的生产运行。数据库的应用备份方式：现有的FOC数据库没有应用备份，如果数据库服务器崩溃短，时间内无法恢复，需要准备一台新的备用服务器、安装操作系统、Oracle数据库软件，然后使用数据备份进行恢复，整个恢复过程可能需要一天的时间。在恢复过程中所用的应用系统都无法访问数据库，会严重的影响企业的生产运行。解决用户错误：现有的FOC数据库没有针对用户错误的处理方案，但是用户错误是经常出现的，当用户错误修改了数据或者数据库管理员错误的删除了表，需要进行数据库的恢复，恢复时间可能需要数小时。从上面的分析能够看出，现有的FOC数据库无法满足应用系统高可用性的需要，为了不让信息系统成为企业生产运行的瓶颈，必须要解决现有的容灾系统存在的问题。除了以上列出的问题之外，还有许多问题如容灾系统的负载能力估计不足，实施过程中没有严格遵循高可靠标准，实施过程工作界面过多沟通不足，日常运维管理方面存在不足和漏洞，缺少厂商、系统集成商的后续支持服务等等都可能导致业务持续性系统建设的失败。另一类问题是项目小组仅将目光放在了大型灾难等突发事件的应对之上，而忽略了计划性停机对业务运行的影响。根据有关统计，非计划性停机只占13%的停机概率，而在非计划停机中大型自然灾难占的比例就更低了。所以在项目实施时，未能很好的优化现有系统和流程，没有充分发掘现有潜力，未能将日常操作流程和业务持续性目标充分整合，虽然实现了容灾但是仍没有从本质上解决持续性问题。1.4本文的主要工作在现有数据库的基础上，分析了数据容灾的多种方法，并结合容灾思想的理论，设计了Rac数据库的容灾体系。第一，本文讨论了系统的开发背景以及所面对的问题，介绍了在新形势下面临的挑战和机遇。在此基础上简单说明了本文中涉及到数据库的一些概念，并进行了业务操作设计以及系统化工作。阐述数据库的备份与数据库的容灾概念不同，并着重介绍了Rac并行服务器技术，以及Rac的技术特点和体系结构。其次，在系统的详细设计中，建立容灾体系。先用oracle数据库提供的工具，EXP、RMAN建立本地的备份数据；再用数据挖掘技术恢复用户修改的数据。然后，建立本地应用容灾系统。安装数据库，并创建实例等等。再次，在系统的实现与测试中，对系统的总体实现加以简单介绍，给出了系统的效果图。然后着重对测试的结果进行了详细分析。对数据进行了应用多种恢复方式的测试，先采用Imp、Rman做数据恢复，然后使用创建的Rac系统，进行负载均衡测试和失败切换测试。最后，本文对本设计的应用情况作了简单介绍，并对系统的设计和实现进行了 总结 初级经济法重点总结下载党员个人总结TXt高中句型全总结.doc高中句型全总结.doc理论力学知识点总结pdf ，并提出了对数据库容灾技术的改进建议。1.5论文的组织结构第1章引言。主要描述数据库容灾技术的开发背景、国内外现状，本文解决的主要问题和完成的工作。第2章相关知识综述。首先进行了数据库相关概念的概述。其次描述了该系统的系统目标和解决的问题。最后对容灾与备份的区别与共同点进行描述。第3章并行服务器技术Rac。主要进行对并行服务器技术Rac的相关方面研究。首先对Rac的技术特点进行了阐述。其次，对并行服务器技术的体系结构进行了说明，并对后面要用到的文件做了设置。第4章建立容灾体系。本章主要进行系统设计。首先在系统部分，从Exp和Rman两个方面讨论了系统的设计，并且应用上述的两个工具对本地数据进行了备份。其次，建立用户错误的数据容灾，采用数据挖掘技术恢复用户修改的数据。最后，建立本地应用容灾系统。构建操作系统，安装数据库和实例，搭建并行服务器的平台。第5章测试容灾系统。首先测试大量数据丢失的情况，采用Imp和Rman技术做数据恢复。其次，测试用户错误修改数据的情况。最后，测试并行数据库出现某节点失效的情况，并进行Rac负载均衡测试和失败切换测试。第6章对论文进行了总结，并对系统的进一步提升提出了改进意见。第2章相关知识综述2.1oracle备份概述冷备份是Oracle最简单的一种备份，执行冷备份前必须正常关闭数据库，然后使用操作系统工具（例如copy命令）或者第三方工具备份所有相关的数据库文件。如果数据库在不正常的情况下关闭，数据库的控制文件和数据文件头以及联机重做日志可能处于不同步的状态，这种情况下进行冷备份无效。冷备份只是适合数据量不大，而且不要求应用系统必须7*24小时提供服务的情况。热备份相对于冷备份而言，就是不关闭数据库时做的备份。理解Oracle的热备份必须要先理解数据库归档的运行模式。数据库能够在两种模式下运行:归档、非归档。归档就是把联机重做日志进行备份，联机重做日志至少有2组，当一组联机重做日志写满后，发生日志切换，LGWR进程会向另一组联机重做日志中写入，ARCn进程把刚记录满的一组联机重做日志拷贝到归档路径下。非归档模式就是数据库不使用ARCn进程进行归档，当日志进行切换时不会产生归档日志文件。Oracle数据库自身附带有备份工具，其中包括Exp工具。Exp是可以把用户数据以表为单位进行导出的工具，导出dmp格式的文件。Oracle的Imp工具可以读取dmp文件，并且把数据导入某个帐户下进行数据恢复。Exp仅仅备份的是某个用户的数据，包括用户的表、索引、数、触发器等等，不能备份数据库级别的一些文件，包括控制文件、数据文件、归档文件、口令文件、参数文件。Exp的原理是把数据库中用户的对象全部进行处理，对象的定义转变成DDL语句写入dmp文件，表中的数据转化成insert的语句写入dmp文件中，在Imp导入时候重新建立用户下的对象，并且通过dmp文件中的DDL语句建立对象，通过insert语句写入数据。用Imp导入数据时还会产生大量的日志写入联机日志文件中，恢复的速度比较慢。而且Exp，Imp工具在不同的Oracle数据库版本之间还有一定的限制，只能遵循由相同版本或者低版本的Exp来导出高版本数据库的数据，然后再由相同版本或者低版本的Imp向目标数据库中导入。Exp和Imp工具应用起来恢复速度较慢，但也有一定的优点。第一、Exp可以跨操作系统平台进行数据的备份恢复，由Windows上的Oracle数据库导出的dmp文件可以导入到Unix的Oracle数据库中。第二、可以在数据库不关闭的情况下做备份。可以作为数据库热备份的一种工具。可以用于归档或者非归档的数据库。第三、支持以表为单位导出数据，甚至可以支持导出表中的部分数据。Rman是Oracle提供的另一种强大的备份工具，可以用于备份归档或者非归档的数据库，可以备份用户的数据文件、控制文件、归档日志文件、参数文件、口令文件。我们可以使用nocatalog方式来使用RMAN，此时控制信息记录在目标数据库的控制文件中，但这样不安全，因为一旦目标数据库的控制文件损坏就意味着所有的RMAN 备份失效。Rman的优点主要包括：第一、可在表空间或数据库文件级备份，备份的时间短。备份操作和恢复操作都可以并行，而且恢复时也不产生日志，加快备份和恢复的速度。第二、备份时数据库仍可使用。备份时不影响用户的操作，用户几乎没有感觉。第三、可达到秒级时间点恢复（恢复到某一时间点上）。使用数据库有效的备份和从有效备份开始到最新的归档日志，进行恢复时可以恢复到任何一个时间点。第四、可对所有数据库实体做恢复。适用于7*24不间断运行的关键应用系统。2.2备份与容灾的区别上文对备份的概念作了简述，备份仅仅是数据的备份方式，能够保证用户数据的不丢失。不管使用何种备份方式，在恢复的时候都需要考虑下面几个方面。2.2.1当数据库运行在非归档模式下准备硬件与操作系统平台，安装Oracle数据库软件，当用冷备份恢复时候需要使用操作系统级别的拷贝命令。当用Imp命令恢复时候需要先创建数据库，手工建立参数文件和控制文件，要保证新创建的数据库与原数据库的表空间、用户等完全一样，然后再使用Imp命令进行数据的恢复。2.2.2当数据库运行在归档模式下准备硬件与操作系统平台，安装Oracle数据库软件，使用Rman把数据文件，控制文件，参数文件恢复，然后应用归档日志对数据库作完全恢复，能够保证用户的数据不丢失。运行模式备份工具备份的范围关闭数据库恢复的范围备份、恢复速度非归档Exp用户数据不需要不完全恢复慢，使用DDL和DML语句冷备份所有的物理文件需要不完全恢复慢，受限制于操作系统Rman所有的物理文件不需要不完全恢复较快，可以使用并行归档Exp用户数据不需要不完全恢复慢，使用的DDL和DML语句冷备份所有的物理文件需要不完全恢复慢，受限制于操作系统Rman所有的物理文件不需要完全恢复较快，可以使用并行图2-1备份工具的比较综上所述，数据库的容灾和备份应该是属于两个不同层次的概念，备份只是一种容灾的手段。通过备份数据只能保证数据的不丢失，不能保证数据库应用的连续性。容灾一般是采用冗余来预防单点故障的发生，冗余可以包括服务器的冗余，数据的冗余，网络的冗余等等。2.3容灾的范围与衡量指标容灾的范围大体有下面几点：1)用户错误的解决：这是最常见的情况，但是很多系统都没有当用户错误对数据进行修改后采取的方案来做规划。用户的错误一般分为：使用应用系统的一般用户的错误：当用户更新一个错误的表或者更新错误的值时，这种类型的错误很难发现，也很难解决，因为它们对于数据库来说是很正常的事物，而不是错误。一般情况下用户的错误并不明显，而且总是伴随着大量的正确的事物的，如何能从所有的事物中找出可能错误的事物是用户错误容灾要考虑的问题。数据库管理人员的错误：数据库管理人员和一般用户相比，由于对数据库操作不同，所以可能发生不同的错误。比如误删除了一个表，对表的数据做更新不同，删除表是个灾难性的错误，它和平常的DML语句不同，是不能回滚的。一旦发出drop命令表就被删除。还有一种可能是truncate命令，它也是一条DDL语句，DDL语句都是不能回滚的，一旦发出truncate命令，表中的数据立刻会被清除，不产生任何的日志，虽然表的结构和约束等信息仍然存在但是数据却可能无法恢复。如何能从上述的错误中快速的部分的恢复数据而不需要对数据库进行完全恢复也是用户错误的容灾要考虑的问题。2)数据的容灾：数据的容灾主要还是依靠传统的备份方式来完成的，前面有详细的讨论，这里不再说明。3)应用的容灾：本地提供应用的服务器可能会发生单点故障，如果发生单点故障时，需要用户等待很长的时间来恢复应用，显然是不符合实际要求的。所以如何建立应用的容灾系统能够防止应用的容灾是非常重要的。最坏的情况总是会发生，如果对本地的应用建立了容灾系统，但是如果发生了大规模的自然灾害，导致本地的所有系统无法使用。为了预防这种情况的发生，异地的容灾系统也是需要考虑的问题。日志挖掘技术（logminer）也是一个重要的技术。联机日志文件和归档日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有DML语句。Logminer工具既可以用来分析联机日志文件，也可以用来分析归档日志文件，既可以分析本身自己数据库的重作日志文件，也可以用来分析其他数据库的重作日志文件。Logminer技术能够从所有的事物中找出可能由于用户错误引起的错误的事物，并且可以使用Logminer技术对错误的事物进行回滚，不用全部恢复数据库就可以恢复数据库的某个变化。可以使用Logminer技术来完成用户错误的容灾。第三章并行服务器技术Rac3.1Rac技术特点Oracle中提供Rac技术来实现并行服务器。并行服务器方式是多个服务器构成的集群，集群里面的每一个服务器都有自己的CPU和实例内存，它们同时对一个数据库进行操作。并行服务器方式至少需要双机支持，支持平衡负载，对于大量用户访问环境，可以在多个服务器上同时处理用户的请求。在这种多机环境中如果尚有一台服务器正常运行，不会造成整个应用的停止。RAC技术的优点有高可用性和高可扩展性。高可用性，是指除了提供所需性能和协调单个服务器工作外，同时提供容错功能以保证系统最大的正常工作时间。实现群集的完全冗余，让数据库在某个群集组件（服务器、交换机、磁盘、内部连接器等）失效的情况下能继续正常工作。它提供了真正的高可用性解决方案，关键的突破是在数据库恢复期间能提供完整的数据库访问。这使得RealApplicationClusters成为系统应用所要求的24x7可用性的最佳平台。RAC高可用性在三个关键领域胜出。第一，提供了数据库恢复期间的数据块访问。第二，透明的失效转移，对最终用户屏蔽了系统失效。第三，N-1节点失效的容错能力，只要有一个数据库节点幸存，RAC就能够提供完全的数据库访问和相对不间断的操作。高可扩展性，是指支持活动群集。通过它，多台服务器可平行工作于共同的数据上，通过一个群集内部连接技术，共享数据库存储，使企业可以用低成本的小群集开始部署并随着需求的增大而不断加入节点。Oracle在集群中多个节点之间自动平衡用户负载，不同节点上的RealApplicationClusters数据库实例预订所有数据库服务或者部分子集数据库服务。虽然每一个节点有一个不同的物理IP地址，但应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。3.2Rac体系结构集群的硬件主要有节点(Node)、结点间内部连接网络(Interconnect)、共享磁盘子系统(SharedDiskSubsystem)。最简单的集群组成必须至少有2个节点，节点之间使用Interconnect互相联结进行通讯，每个节点都有连接能够访问到共享磁盘系统，如果集群中的节点个数多于两个就要求所有的节点之间都有能够进行内部连接的Interconnect来进行内部通讯。集群软件是在集群硬件的基础上提供集群服务的，它基于操作系统，在Unix下集群软件由厂商提供，在Windows下则由Oracle的专用集群软件支持。集群软件包括三个部分：集群管理器、节点监视器、内部通讯。3.2.1自动存储管理自动存储管理使用裸设备。所谓裸设备，是一种没有经过格式化，不被Unix通过文件系统来读取的特殊字符设备。它由应用程序负责对它进行读写操作，不经过文件系统的缓冲。因为使用裸设备避免了再经过Unix操作系统这一层，数据直接从Disk到Oracle实例进行传输，所以使用裸设备对于读写频繁的数据库应用来说，可以极大地提高数据库系统的性能。由于使用的是原始分区，没有采用文件系统的管理方式，对于Unix来看，维护文件系统的开销也都没有了，比如不用再维护I-Node、空闲块等，这也能够导致性能的提高。如果磁盘读写确实非常频繁，以至于磁盘读写成为系统瓶颈的情况成立，那么采用裸设备确实可以大大提高性能，最大甚至可以提高至40％，非常明显。如果对共享文件使用裸设备，那么就放弃了使用文件系统。由于没有文件系统，所以要对每个共享的文件生成一个单独的分区，然后创建到裸设备的软链接，Oracle通过链接名把数据写入裸设备。使用裸设备虽然能够提高数据库的I/O性能，也是共享存储的需要，但是它的维护比较复杂，而且在裸设备上不能存储归档日志，因为归档日志文件的个数是不断增加的。自动存储管理由Oracle进行完全管理。从许多方面看，这都消除了维护裸设备的复杂度，而且仍然保留裸设备提供的I/O速度的优势。使用自动存储管理时，所有的文件管理（包括进行备份）必须在数据库内部进行。虽然使用自动存储管理可以把归档日志存储在自动存储管理磁盘组上，但是Oracle的二进制文件（Oracle软件安装后的程序文件）不可以这样做，因此需要在各个节点安装驱动程序。3.2.2Rac对网络的需求Rac为了能保证节点在故障时能更快的进行故障切换，使用了虚拟IP地址技术（VirtualIPAddress，VIP）。每个节点不仅有网络管理员分配的静态IP地址，而且还需要一个虚拟IP地址。每个节点上的侦听器侦听的是该节点上的虚拟IP地址，客户端的应用程序连接数据库也是针对虚拟IP地址来的。一旦某个节点发生故障，虚拟IP地址将进行实际的故障切换，并在集群中的其他节点上继续保持联机。如果某个节点故障，该节点的虚拟IP会自动分配到另外一个节点，这样做并不是为了让客户端程序通过该虚拟IP能够与数据库保持连接，而是为了缩短客户端程序知道该节点已经故障的时间。如果IP进行故障切换并从其他节点上进行响应，那么正在与该VIP连接的客户端程序会立刻得到一个响应，只是响应的内容并不是连接成功而是连接失败，说明该VIP代表的节点的实例是故障的。这时客户端程序能够立刻尝试地址列表上的其他地址再次进行连接，从而成功的与集群中其他的节点VIP正常进行连接。使用虚拟IP地址的原因是‘TCP超时’，TCP超时对应用程序的可用性有很大的影响。当Rac环境中的某个节点发生故障时，客户端是没法知道的。客户端可能先向一个已经故障的节点发出连接请求，如果请求失败，客户端会向Rac的其他节点发出请求，直到建立连接。但是当客户端发出请求多长时间会返回连接失败的信息是和TCP超时的设置有关的，TCP超时的设置一般由客户端操作系统的平台决定，超出了Rac的控制范围。因此对所有用户的修改可能是很麻烦的，因为可能会需要很多的客户端和很多配置改变。改变超时的值可能会给客户端正在运行的其他应用程序造成不良的后果，因为其他的应用程序可能出于某种原因，需要设置一个较高的TCP超时值。操作系统平台的超时值可能从几秒到2分钟，让客户端等待2分钟再返回一个无法连接的信息，是不能忍受的。所以假设a节点故障，a节点的VIPa将指向集群中的另一个b节点，VIPa在b节点能够正常的响应ping和连接请求，当用户从客户端的地址列表中向a节点的VIPa发出连接请求，此时VIPa在可用的b节点上，VIPa会给客户端一个Oracle错误，说明没有可用的侦听器，客户端收到这个返回后，会自动的在地址列表中找到b节点的地址，然后发出请求。通过这种处理方式，跳过了TCP超时等待。图3-1双节点Rac的网络环境上图是典型的双节点Rac的网络，每个节点必须至少有两块网卡，一块网卡用于公共网络的客户程序通信，另一块网卡用于专用的集群网络的通信，另外还有VIP的虚拟地址。为了使用这种配置，首先必须在每个节点上配置Hosts文件。这个文件是根据TCP/IP的标准来工作的，它的作用是包含IP地址和Hostname(主机名)的映射关系，是一个映射IP地址和Hostname的规定，规定要求每段只能包括一个映射关系，IP地址要放在每段的最前面，空格后再写上映射的Hostname。根据系统规定，在进行DNS请求以前，系统会先检查自己的Hosts文件中是否有这个地址映射关系，如果有则调用这个IP地址映射，如果没有再向已知的DNS服务器提出域名解析，也就是说Hosts的请求级别比DNS高。文件在Unix下的是/etc/Hosts，在Windows下是c:\winnt\system32\drivers\etc\Hosts。在图例中文件的配置内容应为:Rac1172.16.7.4(使用公网接口，实际网卡的对外IP地址)Rac2172.16.7.5(使用公网接口，实际网卡的对外IP地址)VIP1172.16.7.1(使用公网接口，虚拟网卡的对外IP地址)VIP2172.16.7.2(使用公网接口，虚拟网卡的对外IP地址)priv1172.16.8.1(使用私有接口，实际网卡的用于集群通信的内部IP地址)pviv2172.16.8.2(使用私有接口，实际网卡的用于集群通信的内部IP地址)在使用Rac技术时有一个关键问题:客户端的配置。首先来说Oracle的网络结构SQL*NET，基本网络结构也就是如下图这种情况。Oracle的服务器和客户端通信主要依靠三个配置文件：Listener.ora、Sqlnet.ora、Tnsnames.ora图3-2Rac的主要配置文件第一、通过这个Sqlnet.ora文件来决定如何找一个连接中出现的连接字符串。例如我们在客户端输入　　SQLPLussys/Oracle@orcl　　客户端的Sqlnet.ora如下配置SQLNET.AUTHENTICATION_SERVICES=(NTS)　　NAMES.DIRECTORY_PATH=(TNSNAMESS,HOSTNAME)　　客户端就会首先在Tnsnames.ora文件中找orcl的记录。如果没有相应的记录则尝试把orcl当作一个主机名，通过网络的途径去解析它的IP地址,然后去连接这个IP上GLOBAL_DBNAME=orcl这个实例。第二、通过Tnsnames.ora文件，决定到主机名或者IP的对应，只有当Sqlnet.ora中类似NAMES.DIRECTORY_PATH=(TNSNAMESS)这样，也就是客户端解析连接字符串的顺序中有TNSNAMESS时，才会尝试使用这个文件。文件内容如下：sdfoc=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.8.201)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=focdb)))其中：sdfoc是所要连接的时候输入的TNSNAMES(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.8.201)(PORT=1521))是这个TNSNAMES对应的主机、端口、协议。第三、通过Listener.ora文件，服务器端监听进程的配置文件，接受远程对数据库的接入申请并转交给Oracle的服务器进程。所以如果不是使用远程的连接，Listener进程就不是必需的，同样，如果关闭Listener进程并不会影响已经存在的数据库连接。如下是Listener.ora文件的例子：　　#GeneratedbyOracleconfigurationtools.　#下面定义LISTENER进程为哪个实例提供服务　#这里是ORCL，并且它对应的Oracle_HOME和GLOBAL_DBNAME　#其中GLOBAL_DBNAME不是必需的除非使用HOSTNAME做数据库连接　　SID_LIST_LISTENER=　　(SID_LIST=　(SID_DESC=　　(GLOBAL_DBNAME=boway)　　(Oracle_HOME=E:\Oracle\product\10.1.0\Db_2)　　(SID_NAME=ORCL)))#监听器的名字，一台数据库可以有不止一个监听器#再向下面是监听器监听的协议，IP，端口等，这里使用的是tcp1521#端口，并且使用主机名　　LISTENER=　　　　(DESCRIPTION=　　　　(ADDRESS=(PROTOCOL=TCP)(HOST=boway)(PORT=1521)))　通过以上三个文件的配置，当输入SQLPLussys/O