oracle 7技术与技巧数据库高可用第一集

管理24×7工作方式的站点需要具有非常高的前摄能力。即便如此，某些不可预测的紧急也可能会导致自己先前的数据库正常工作时间统计值大幅度降低。例如，公司有可能仅仅因为年终的一次系统停工，而使得可用性统计值为99.9％（一年中大约有9个小时的停工时间。但是，也许上星期一次严重的系统停工有可能使这种可用性统计值急剧下降。因此，熟悉那些对于本公司的数据库系统会造成影响的紧急并且采取相应的防护措施就显得极为重要。经验表明，对这些紧急的预防处理能够减少系统恢复时间以及减少所需的管理人员。此外，本章给出了各种可能的紧急列表，用来帮助数据库管理员进行系统恢复。最后列出了在Oracle特定环境下可能出现的各种紧急以及相应的应付方法。在24×7工作方式下，什么是紧急呢？从现在或者非常短的时期来看，任何当前或者潜在的、能够对系统的可用性与性能造成严重的都称为紧急。在出现紧急时，必须分析以下问题：最佳解决方案是什么？在这里，所谓最佳解决方案是指能够系统停工，或者，在不可避免地会产生系统停工的情况下，能够最大限度地减少停工时间的方案。在实际应用中，那种在满足SLA需求的情况下能够最大限度地限制MTTR的方案将被作为最佳解决方案。一般来说，与数据库系统性能相关的紧急相对于系统可用性来说似乎处于次要地位。但是，对于许多24×7客户，一个性能很差的数据库系统几乎与没有任何数据库系统相同。如果数据库系统的运行速度过慢，就会导致顾客不再使用此系统，即使是那些关键用户也会拒绝使用此系统。笔者可以用一个自己的亲身经历来说明这个问题：我曾经改变过自己的eb电子邮件服务提供商，其原因是本人在利用这个电子邮件服务提供商所提供的服务来收发电子邮件时延迟过大。可以说，每次服务商出现这种情况，都会导致一批用户的流失。这时，这些用户要么在较长的一段时间内不使用这种服务，或者干脆转而使用另一个服务商所提供的服务。如果某公司的数据库系统在性能与可用性方面经常出现类似的问题，那么公司的市场竞争能力将受到严峻的，这种情况在电子商务领域中表现得尤其突出。如果某个eb对于新用户所输入的URL响应过慢，那么这个公司就可能会永久性地失去这个客户。例如， 26第一部分 而om站点。因此，任何采用24×7工作方式的公司，都必须像重视系统可用性一样重视系统性能。当然，在可用性与性能发生时，还是应该优先考虑可用性问题。数据库系统的复杂性对于紧急的发生频率有非常重要的影响。系统的紧急由许多因素决定，包括数据库大小、模式(schema)与段数目，模式与段之间的关系，并发用户与批处理工作的数目、系统中所包括的硬件组件与软件应用程序数目、表空间与数据文件数目GB(吉字节)或者几TB(万亿字节)，那么这个数据库系统中就会包含许多组件（比如磁盘、数据文件、表等等，而且每个组件都非常容易导致失败。同时，随着数据库不断增大，要从失败中恢复数据库也变得更为。这样，数据库的复杂性将是决定系统恢复时间的一个重要因素。在第1中根据系停类型的同将系统工间分为为假信号硬件/软件问题、环境问题以及自然/人为。基于这种划分方法，公司必须为自己的特定环境准备相应的一些恢复。这些最初可以由24×7小（包括DBA、系统管理员、网络管理员等等）成员的个人经历来决定。在进行这些的准备阶段，应该尽可能地设想出各种可能的潜在失败，同时给出推荐的解决方案或者进行系统恢复的步骤。有些情况下，对于同一个系统失败可能有多种解决方案，而且从不同的角度来看各有优缺点。那么这时就不应该在宏观的级别上将针对这样一个系统失败的所有解决方案罗列出来，而应该对这些解决方案进行系统分析，然后给出一个解决这个问题的最佳方案。也就是说，不应该将关于某个问题的所有解决方案罗列出来，靠系统管理人员去自己识别所应该采用的方案；而是应该列出最佳的解决方案以便减少系统管理人员使用的盲目性。如果在现实环境下，确实不能将解决方案减少到只剩下一个最后的最佳方案，也应该尽可能地减少可选方案的数目。可以说，这也是进行解决方案列举的一个目标。当然，这样做并不是解决方案的选择自身有什么问题，而是在系统停工期间，由于系统管理人员承受着较大的压力，因此很容易在当时条件下做出错误的判断，从而使得系统恢复工作所花费的时间开销更大。在笔者的观察中，经常看到这种情况：在数据库发生问题之后，数据库管理人员在没有进行深入的分析以及对所造成的危害进行估计之时，就急于试图修复这些问题。而且，他们在对系统进行修复之前没有进行任何备份，以便在恢复动作不能成功时可以退回到恢复之前的状态。即使是一个老练、经验丰富的数据库管理人员在心理压力比较大的情况下也可能会做出错误的判断。人们很难预测哪个数据库管理人员能够最终解决数据库系统所出现的问题；解决这种问题所需要的技能是什么；数据库管理人员在进行系统修复过程中可能会造成何种破坏；根据当前的系统信息，数据库管理人员会做出何种分析；为了进行系统恢复，管理人员会采取何种措施等等。因此，在每种数据库系统失败的情况中，最好能够给出一种最佳的系统失败解决方案，使得所有的系统管理人员都能够采取相同的动作。如果所要说明的解决方案比较复杂，不能在有限的篇幅内说明，应在这个列表上给出一个关于 某个文档的参考信息，然后在参考信息中给出解决方案的细节描述。本章后面的紧急例子列表中就给出了在某种情况下采用什么措施的列表，或者其他更为详细的参考说明或者第解决方案手册。虽然有些类型的系统失败可能会同时属于多种系统失败类型，但是对于这些系统失败问题的处理或多或少都有一些共同的特点，现列出如下：采取一些前摄措施，系统失败的发生。这就是先前所说的前摄任务，例如检查数据库运行情况、锁定、空间问题（段是否可以按需增长）等等。查找可能会引起失败的信号。就是要经常监视系统，并且经常分析这些监视的结果以便检测到潜在的系统失败。如果失败措施不能有效地失败的发生，就应该将数据库系统的运行环境尽量在系统失败之后，必须及时通知适当的系统管理人员以及其他相关人员（例如高级管理者、终端用户、顾客等等。恢复常态。这个过程包括重新启动数据库、重新启动程序、重新启动应用程序以及通知管理员、终端用户和其他数据库系统所服务的对象。如果发现恢复后的系统与原始系统不同，就应该保证系统能够恢复到改变前的状态。如果被恢复的系统能够像原始系统一样工作，那么它就可以继续作为主数据库系统使用，而原始系统则作为备份数据库系统；直到下一次再发生数据库系统失败的情况，当前主系统又可以被作为备份系统使用。进行系统失败原因的剖析。这种剖析包括对系统失败点、失败原因以及失败的方法进行完全的分析。进行这种分析的作用是帮助制定防止出错的策略以及能够适用于出错时下面将列的紧急表能够接上述第6、7和8步提供支持。此外，这种列表也能够作为给上述每个步骤提供详细解决方案的一部分。也许，上面的一些步骤只是性的，但是在发生系统故障的关键时期，这种往往容易被忽略。根据笔者所见到的一些实际情况，发生系统故障的关键时期，人们常常会忽略性的措施。因此，完全有必要把公司的那些数据库系统管理人员假想为对于应付紧急情况并不熟练，从而需要为他（她）提供详细的紧急处理步骤。也许读者已经注意到，前面所给出的那些步骤都是针对系统/数据库失败恢复(或称失败克服)动作而。因此必须保证有足够多的恢复措施可供选择，从而在必要时数据库管理人员能够及时找到相应的解决措施。需要说明的是，如果进行失败克服动作所花费的时间开销高于对当前出错系统进行修复的时间开销，那么这种失败克服动作就变得毫无意义。在进行失败克服的过程中，必须尽量保证主数据库系统与备份数据库系统之间切换的平滑性，使得这种切换对于终端用户的影响最小，这就必须保证所有的客户连接都能够非常平滑地切换到备份数据库系统上。第6章将讨论在进行切换操作的过程中所采用克服策略，而在15～第1828第一部分简 表2-1中给出了一个紧急列表的例子，用来帮助读者建立关于紧急列表的整体结构与其内容的印象。当然，完全没有必要照搬所给出的这种形式，只要能够系统地列出所有的紧急以及相应的文档，就可以采用自己认为合适的任何紧急列表形式。在这个紧急列表实例中所给出的关于紧急列表的内容并不完全，因为它们没有囊括每种紧急列表分类中的所有紧急。因此，在套用这种紧急列表格式之前，必须根据自己特定的系统环境对这个列表进行充实。本章后面将给出一个在Oracle环境下关于紧急的更详细列表。在这个紧急列表实例中列出了所有的已调度与未调度，这是因为系统中出现了紧急并不意味着不能在紧急发生之前采取相应的预防措施。相反，在出现紧急之前，多数情况下都会有一些预示系统会出现某种的征兆，从而系统管理员可以根据这些征兆进行相应的动作。此外，只要在进行前摄之前预先告知终端用户与顾客，就能够非常容易地进行调度。表2-1紧急列表格式实描述原因 复方 调度（N所发生的次N0如果没有打开失败克服功能，停工时间为60分钟；如果打开了失败克服功能，停N0采用一个新硬盘作RAID5RAID5息，请参见“N0N0软件组件操作系统（Solaris7） 0分钟到15分 描述原因调度（Y/N描述原因调度（Y/N软件组件Oracle8达到Maxextent（ 段集合的 1628到ORA-1632以 理参数设中的第12 中的第12 描述原因 调度（Y/）数据文件被N0间的用户，停工时间“8012为60表空间是关键性表空间，那么就有可能打开了失败克服功能，停工时间为3联机备份日N0“8012N2可能会导致停工，

“8012 细信息，请参见“8012A，第79

可能会导致停工，而且停工时间动态可

本年度此平均恢复 调度（所发生的次数

的必Y自动Y管理人员处于Y确保所有

导致停工，时间动态导致停工，时间动态30第一部分 调度（N所发生的次

于这个问题的详细方法，Document于这个问题的详细方法，Document9124A,第45页”于这个问题的详细方法，Document于这个问题的详细方法，Document于这个问题的详细方法，Document9124A,第45页”于这个问题的详细方法，DocumentN0N0N0

本表“推荐的恢复方法”中所列出的所有参考文档，都只是一些例子，而不是实际的参考资料。读者在创建自己的紧急列表时，可以真正参考一些相关的文档、书籍、手册等等。本表的“停工时间”中，在括号里所列出的3分钟停工时间，是指在使用失败克服操作进行系统修复时所花费的时间。当然，这里所说的“3分钟”只是一个例子，根据所采用系统中不同组件所引起都会导致硬件失败（例如：硬盘、控制器、CPU、内存、路由器、网关、电缆、磁带驱动器、风扇等等。通常，产生硬件失败之后都要修复或者更换导致硬件失败的相应组件。这个动作完成之后，就可以重新启动系统正常的工作功能。对于那些经常会硬件失败的组件，最好能够保持它们的多个备份。可以说，单一失败点是导致高停工时间的最常见原因。例如，在拥有双硬盘（通过两个节点进行连接）或者镜像硬盘的情况下，即使是其中的一个节点或者镜像硬盘发生故障，也能够保证系统的正常工作（在出现某个节点发生故障时，根据所采用克服解决方案的不同，有可能会短暂的系统停工。但是，如果仅仅有一个这样的组件，那么在组件被修复/替换期间（就是所谓的修复窗口，服务将被终止。有时，恢复某个组件的时间会长得惊人。例如，当在客户站点上烧坏了一个硬盘控制器时，硬件工程师将会认为应该对这个组件进行完全替换。这样，如果此硬件在当地买不到，需要从外地采购，从而至少要花费两天的时间才能将这个问题解决。这种类型的情况会导致非常巨大的停工时间，从某种角度来看，如果某公司的服务终止两天，将有可能使公司在商业意义上造成巨大的损失。为了避免这种情况的发生，许多公司都与硬件组件生产厂家之间签订了关于“组件可获取性保 ”的合同，要求硬件生产厂家必须保证那些可能会导致失败的特定组件能够从本 ，或者在可接受的预定义时间内从某个定的源获取，以确保组件能够得到及时更换。因此，必须为系统定义所有的关键组件并保证组件之间的兼容性。此外，所有的硬件必须被非常安全地，从而最大限度地防止偶然的（或者是故意的）破坏。必须严格遵守硬件组件使用手册上所列出的各项条款（例如工作温度、与其他设备的接近情况等等。必须尽量保证硬件设备各种连线的规整性，不能将这些连线放置在人们经常经过的地方。例如，数据中心的地板就能够很好地防止出现这类意外事故。在建立紧急列表之前，必须将软件进行单独的分类。归属于不同软件组件的紧急事件必须在紧急列表中分别详细地列出。常见的软件组件包括操作系统（OS、RDBMS、RAID、容量管理软件、介质（/硬盘）管理软件、自定义应用程序软件以及中间件（例如TP监视器）等等。软件问题未必会导致紧急，但它必须进行常规的，而这种则有可能会导致系统停工。因此，必须列出所有的这些动作并且给出此动作对于系统停工时间的影响。有些任务可以在某种意义上限制系统的高停工时间，并且某些紧急的发生。某些高可用性（HA）解方案（例如OracleParallelServer、备份数据库与）在硬件失败软件失败的过程中由于允许执行失败克服动作，从而大大提高了系统的可用性。有效的系统备份对于确保站点在受到人为的假后恢复到原先的正常状态非常重要。例如，如果有某个非常重要的表在系统工作的期被DBA意外地删除了，那么如果使（Point-in-time）恢复或者输出转储文件，就有可能相对较快地恢复系统。但是，如果需要在恢复执行过程中服务也不中断，那么就应该考虑采用备用数据库或者非资源密集（15章。电源断电是许多站点所遇到的环境失败问题。这种问题的最佳解决方法就是与相关管理部门达成协议，请求在电源断电之前进行预先。例如，在某个客户站点上，公司就与4个小时或者更长时间的停电之前，必须保证于72小时之前就通知站点管理员。当然，这种协议并不能杜绝随机出现的电源断电现象。因此，除了不间断电源（UPS）之外，没有其他办法能够保证为系统提供不间断的电源支持能力。可以说，任何需要建立24×7数据库工作方式的站点，就应该为他们所有的数据中心（包括主设备与备份设备）提供UPS。与其他硬件设备一样，这些UPS系统也必须封装在一个保护盒里面，并且只允许极少的人（如UPS）接近它。必须将电子插座放置在大多数人不/故意地切换电源或者UPS系统。如果需要实现能够防止自然/人为的高可用性解决方案，其开销是非常巨大的。在不同的地理位置上通过镜像进行相互备份的数据中心（硬件和软件）能够确保在发生的过程中数据库的可用性。正如前面所说的，公司完全有必要分析在发生的过程中提供系统可用性的必要性。例如，在发生的过程中，提供系统可用性也许就是没有必要的。当然，这个问题实际上最终还是取决于公司业务范围以及市场范围。例如，如果公司所销售的产品或者服务的市场范围在地理位置上没有受到的影响，或者公司在没有受到影响的国家有分支机构，或者公司销售的是关键性的防御设备，那么它就完全有必要即使是在时仍然保证数据库系统可性。对于这些问题的分析，必须在紧急发生之前就准备好了，并且集成到服务级协议（SLA）中。紧急列表任务的一个方面就是记录各种紧急的发生次数。在一段时间之内，对紧急 发生次数的统计能够帮助分析站点最有可能发生的紧急。基于这些信息，就32第一部分 可以采取相应的措施来有效地防止这些紧急的经常发生。紧急列表的目标就是提供关于潜在失败问题的信息，从而使得系统管理人员能够在压力相对较小的情况下，减除他们的紧张因素以便作出正确的判断，进而采取正确的紧急预防措施（这是因为，对于系统管理人员来说，他们所承受的压力越大，那么引起错误的可能性也就越高。即使是在紧急事件发生之后，由于紧急列表中系统地列出了相应的处理步骤，从而能够最快地进行系统恢复，使得系统停工时间最小。为了保证紧急列表的精确性，相关管理人员应该经常性表2-2中列出了Oracle环境下最常发生的紧急列表，在这里，此列表也是不完全的。可以这样说，想要给出一个完全的紧急列表很，而且几乎是不可能的。因为这种紧急列表不可能在一开始就完全创建出来，随着数据库系统的不断运行，紧急列表将会不断地发展完善。也许某些时候，数据库管理人员会遇到一些难以预料的紧急，像这类紧急也应该在紧急列表中罗列出来，从而使得数据库管理小组能够对本站点的所有紧急有更深入的了解，并且能够非常熟练地知道系统可能发生的紧急。只有对紧急有了一定的预见性之后，才能保证有效地防止它们的发生。在紧急事件列表中必须列出因一个原因或者多个原因导致系统停工的所有。这类包括：使得整个数据库系统停止工作的、使得单个表停止工作的以及使得使用这个表的应用程序停止工作的等等。假设某公司的数据库系统一直在正常运行，但是如果运行于这个系统上的工作经常失败，那么用户将难以完成他们的工作。那么作为管理人员，就应该分析是什么使得备用数据库系统不能被或者是否数据库中的数据提交功能不能为用户提供数据。然后列出所有能够想到的，并且采用相应的方法来最大限度地减少这些发生的频率。如果这些不可避免，那么就应该选择那些MTTR能够满足要求的紧急处理方法。在创建紧急列表的过程中，管理人员的经历对于罗列各种不同类型的“常见”紧急与“不常见”紧急非常关键。在表2-2中的“恢复步骤”中，许多地方都给出了对其他章节参考信息的，读者可以在相应的地方找到这些参考信息。类似地，如果读者适应了这种列表方法之后，也可以在自己的紧急列表中给出指向自己的文档、书籍或者Oracle表2-2，有关于Oracle的（包括内部逻辑与外部物理）都被罗列出来了。在这个表的“平均恢复时间”与“所导致的停工时间”中，分别给出了整个操作的过程以及实际的停工时间。对于某些特定的，这里的“平均时间”可能会引起误会，因为在这些发生之后所进行的恢复时间以及系统的停工时间可能会变化很大。对于这类，笔者采用“动态可变”这个词来描述它们的平均时间与系统停工时间，而没有给出一个确切的时间值。 Oracle8 请参见第11 本年度此所发生的次 根据的原因不同，恢复时间动态可 改变段以增加Maxextent值将Maxextent值设置为UNLIMITED(v7.3前）(extent)数目更小（ 平均恢复时间 进行段的改变需要花费几秒钟的时间。但是，如果在这个段上有一个或者多个会话，那么这些会话必须在进行段改变之前被终止，这是因为进行段改变需要对此段进行上锁处理。段重建所需要的时间长短取决于段大小 是动态可变的。如果这种紧急很早就被发现，那么段就可以迅速被改变从而其停工时间也就很小。但如果这种紧急在相当长时间内都没有被发现，那么这个段的应用程序的停工时间就会很长。同时，段重建的动作可能会导致所有这个段的应用程序的停工时间也比较长。如果发生问题的这个段是一个回滚段(rollback)或者临时段（而不是一个表或者索引段，那么其停工时间就会很小。当然，对于大的表或者大的索引来说，其停工时间还是不小的 对可用的空闲空间簇进行合并，以增大连续空闲空间的大小（可以使用v7.3以及更高版本中的ATERTABLESPACE命令完成此动作，或者将这个表空间的PCTINCREASE设置为一个大于0的值，以便于允许SMON完成空闲空间合并动作。笔者推荐使用后法，关于这种方法的详细信息，请参见第12章） 平均恢复时间 添加另一个数据文件或者改变现有数据文件大小所花费的时间取决于数据文件的大小。进行空闲空间的合并动作速度较快，但有可能不能产生任何满足要求的连续空闲空间。因此，前两种方法更为可靠 所花费的时间取决于应用程序识别段（不能进行扩展的段）故障的时间早晚。同时，添加大的数据文件也可能会花费较长的时间（笔者曾经见到一个2GB25分钟才能被创建起来。造成这种延迟的主要原因是需要进行大量的写操作，从而导致I/O。在这种情况下，就应该考虑使用一个比较小的数据文件（100MB，以便快速度过目前的紧急情况，从而减少停工时间。然后，为了保证与其他数据文件的一致性，可以再将这个小的数据文件进行扩展。当然，必须确保数据文件大于目前正在出现问题的段所需要分配的空间大小34第一部分 表硬件问题操作系统Oracle应用程序是否已调度（Y/N） 本年此所发生的次数 紧急描 与“表”中所讨论的原因相同（此外，SQL*Loader中的绝对路径也有可能会导致索引处于UNUSABLE状态） 检查造成索引的原因删除并且重新创建索引（但不能使用ALTERINDEXREBUILD命令进行） 本年此所发生的次 紧急描 原因 与“表”中所讨论的原因相同（此外，直接对数据字典进行操作也有可能会导致系统中的段。例如，在对数据字典表中的列进行改名时就有可能会导致数据字典，特别是在操作错误的情况下更是如此。此外，对Oracle安装/配置的错误也有可能会导致这种） 本年此所发生的次 紧急描 回滚段(Rollbacksegment 检查造成回滚段的原因 本年此所发生的次 情况，从而使得使用这些应用程序的用户不能正常工作。此外，用来检测导致这种回滚段的原因所采取的步骤也是要花费时间的（所完成的动作包括查找到正确的转储文件、查找发生的数据块地址(dba)以及回滚段所属的DB等等） 在表上所执行的DML操作过重恢复步骤 重新组织表（从另一个表上或者导出的转储文件中重新获取数据，删除表然后利用更加合适的参数重建表，使数据更为密集。所设置的新参数应该能够有效地防止出现表的严重碎片现象 根据表大小、所涉及的物理资源（硬盘/控制器等等）以及其他因素的影 动态可变。第8章将讨论在进行表的重新组织时减少停工时间的方法 在索引上所执行的DML操作过重 并行与不可恢复/不作日志的方式进行。在DSS环境下，在进行大的数据加 骤 表中带有LONG/BLOB列的行链是不可避免会出现的，但是，如果行链是由于LONG/BLOB列造成的，那么就可以考虑使用以下步骤来去除不必修改表中的参数，以便防止再出现新的行链分析表，查出所有的形成行链的行（也就是在CHAINED_ROWS表中查看ROWID）36第一部分 本年此所发生的次 Oracle8 紧急描 删除当前版本中存在的严重恢复步骤 可以使用更新版本中所提供的MigrationUtility或者，可以在保护数据不变的情况下，升级数据库（也就是删除老版本的数据库，安装新版本，然后为每个新的需求创建新数据库的方法，然后在新数据库上恢复所保存的数据 本年此所发生的次 紧急描 重新Oracle可执行程 本年此所发生的次 紧急描 本年此所发生的次 SYSTEM数据文件丢失/硬件问题操作系统其他的软件bug（VolumeManager、RAID等等的bug）动态可变（日志数目等等 动态可变（由于牵涉到SYSTEM表空间，使得整个数据库都必须停工） TEMP数据文件丢失/破坏 应用程序数据表空间的数据文件丢失/破 紧急描 应用程序索引表空间的数据文件丢失/破 38第一部分 恢复步骤 与“应用程序数据表空间的数据文件丢失破坏”中所讨论的恢复步骤相同。或者，可以删除与那个数据文件相对应的索引表空间，然后在可靠的硬盘上重新创建这个索引表空间并重新创建必要的索引。其中，后一种恢复方法有可能不需要进行任何停工（特别是在索引不是特别重要时尤为如此） 本年此所发生的次 紧急描 RBS数据文件丢失/破 _CORRUPT_ROLLBACK_SEGMENTS可以被设置为将RBS表空间中的rollback段标记为被破坏，然后打开数据库。数据库打开之后，RBS表空间就可以被脱机、删除以及重新创建，从而使用新的回滚段。但是，这种方法可能会引起数据库的逻辑，因此必须进行数据库的重新组织 本年此所发生的次 紧急描 当前的联机重作日志被丢失/破 本年此所发生的次 紧急描 非当前的联机未归档的重作日志被丢失/破 执行SHUTDOWNABORT（如果实例尚未）启动这个实例并装配数据库（STARTUPMOUNT）将数据库运行方式改变为NOARCHIVELOG（这个步骤是删除一个未归档ARCHIVELOG方式下试图进行上述动作，将会产生ORA-350再次启动实例并且装配数据库（STARTUPMOUNT）将数据库改变到ARCHIVELOG方式（由于需要执行实例恢复动作，因此不能在删除丢失/破坏重作日志之后立刻将数据库设置为ARCHIVELOG方式。同样，必须重新启动数据库，执行实例恢复动作，正常关闭数据库，然后将数据库设置为ARCHIVELOG方式。否则，将会产生ORA-265 平均恢复时间 短路由需要7分钟（根据执行实例恢复需要的时间，可能会稍有不同）对于长路由，平均恢复时间动态可变（根据从备份中进行数据恢复的时 非当前联机归档的重作日志丢失/破 已归档的重作日志（尚未备份）丢失/破 某个控制文件丢失/破 执行SHUTDOWNABORT（如果实例尚未） 所有的控制文件丢失/破 执行SHUTDOWNABORT（如果实例尚未）启动实例（STARTUPNOMOUNT）（转储文件的创建需要在使用DTABASEBACKUPCONTROLFILETOTRAC命令的过程中作为每次备份的一部分进行）创建一个新的控制文件。如果转储文件不存在，那么就应该手工地创建控制文件创建（在这样的过程中，将所有当前的数据库文件名/路径罗列出来会有所帮助） 本年此所发生的次 40第一部分 5分钟（如果需要手工地创建控制文件创建，那么可能需要更长的时 紧急描 与“SYSTEM数据文件丢失/破坏”中的原因相同。在维持有备用数据库的环境下，主数据库系统上的各种都会对备用数据库造成一定的影响。例 本年此所发生的次 了问题，那么就没有备份数据库可供使用。从而可能造成较高的停工时间。因此，必须尽可能使得备用数据库能够正常运行 Oracle8 紧急描 所有的非SYSTEM回滚段被删 本年此所发生的次 5分钟（如果用来重新创建回滚段的不可用，那么就需要花费一些时间来创建这个。因此，应该总是在硬盘上保存数据库DLL，这些数据库DLL可用来创建表空间、用户、回滚段、权限等等 紧急描 如果数据库正运行于ARCHIVELOG方式（任何24×7数据库通常都运行于使数据文件处理联机状态（通过ALTERDATABASE命令从的热备份中恢复数据文件并且使用已归档的重作日志修改数据库的 本年此所发生的次 紧急描 如果某个表空间被脱机或