1、 毕 业 设 计 （ 论 文 ） 英 文 翻 译 中文： SQL 服务器中的软件容错 摘要： 对现在大多数软件，软件容错几乎只意味着可以保证为现成软件提供了更好的可靠性，相比没有定制开发或额外的成本高很多，我们公布一个自身实验装置的经验，就拿现成 SQL 数据库服务器来说。首先，我们描述了一个防护性包装来掩盖错误的影响，在其中一台服务器，而不从供应商哪里去等待足够的修复。然后，我们讨论如何结合成一个多元化的模块化冗余配置（ N 版本软件或 N 种自检软件）成各种各样的服务 器。通过包装保证了数据库不同副本之间的一致性，并为多个 CLI废除限制并发客户之间的交易，实践表明，对于数据库不同的保护性
2、包装模块化冗余是可行的，复杂的甚至都可以实现容错现成组件。 1、介绍 对于用（ OTS）的软件元件在会议上各方各持己见。本文中，我们侧重于可靠性概率 LEMS、 OTS 的组件构成的系统集成介绍，他们的文档通常仅限于定义良好的接口，简单的示例应用程序演示了如何可以在一个系统集成的组件。组件厂商很少提供有关信息的质量和使用的 V V 程序。这将创建任何严格的可靠性要求的集成问题。至少在非安全关键 CAL 行 业，供应商往往把不能接受甚至反感的现成组件的查询质量。这也是目前系统集成商所面临的。 我们所使用的“组件”一词在通用工程意义称为组装，它可形成一个系统，并且是在他们自己的权利系统基础上建立的
3、。“组件”可能是任何一件事，在软件库中用于组装应用，并可以作为独立系统使用的应用程序。我们一起审议现成的商业和非商业（ COTS），例如：开放资源组件在我们的讨论中并不显著。但是源代码是可用的，可以利用它的规模和复杂特性。可能会拒绝优势通常采取授予时的源代码是可用的系统集成商不能信任的组成部分，充分可靠的系统的需求，往往不 是系统的建设任务。我们认为容错往往是获取所需可靠性方式的唯一办法，在系统升级中，使用 OTS 的组件。通常情况下，不能改善 OTS 的组件，执行额外的 V V 活动是不可行的。这种情况很可能在未来改变，如果客户强烈要求实现与 OTS 的组件开发，其交易影响力是可想而知的，但
4、这种可能性并不能帮助当下的系统集成商。容错可采取多种形式。例如，额外的（可能是特制的，但相对简单）组件进行保护性包装，像看门狗，显示器，对 OTS 的组件还具有审计职能，前检测意外是为了防止程序产生严重后果，甚至影响组件的状态恢复全面复制。这种“不同的模块化 冗余”似乎是可取的，通过一个非常简单的架构达到端与端连接，以及防止相同的故障，将保护在副本内非多样的模块化冗余。两个或两个甚至更多的在职培训组件（其中有些可能是免费的）采购成本远远比自己开发的少很多。众所周知，使用 OTS 的组件系统开发问题，是有关的可靠性收益，实施困难和该特定系统的将给他们带来额外费用。为了研究这些问题，我们已选定了广
5、泛的应用，相当复杂的 OTS 的组件类别：SQL 数据库服务器。在现有的 SQL 服务器是常见的故障。可以看看修复其产品的每一个新版本的供应商所提供的清单。 SQL 服务器的进一步改进可靠 性，似乎唯一可能的是通过设计多样性容错。鉴于许多可用的 SQL 服务器的在职培训和不断增长其功能（ SQL 92， SQL 99）建立一个容错性的 OTS 服务器和 SQL 服务器是合理的。我们已经开发了一个实验测试平台，它实现了一个多样化的冗余 SQL 服务器通过包装 SQL 服务器的冗余，使多个用户同时包裹的 SQL 服务器上运行他们的交易。我们正在运行的实验，以确定通过容错来实现可靠性收益。在本文中，
6、我们报告关于建设 OTS 的这些具体的组成部分容错设计方面取得的经验：我们认为对于不同的模块化冗余， N 版本编程（ NVP）和 N-版本自检 编程（ NSCP）使用的术语。 NVP系统的输出是由复制输出的一票。在 NSCP，每一个不同的“版本”应该失败干净，使任何人都可以复制的产出作为系统的输出使用。这两种解决方案都依赖于保证数据库的不同副本的状态之间的一致性。这个副本一致性的问题审议了很长一段时间，仍然解决了一般数据库服务器关于保护性包装，我们提出的保护理念 t OTS 的组件包装。包装不正确的和潜在的 之间的在职培训计划的组 成部分和其余 危险通信拦截系统，从而保护了对方的故障。对于 OTS SQL 服务器，保护包装保护客户端，服务器对服务器的故障对故 障的客户，每个客户对故障的间接影响其他客户。在我们的设计方法，我们假设 OTS 的 SQL 服务器没有改变，因为我们没有进入其内部。必要性，因此，我们的解决方案是基于限制的客户端和 SQL 服务器（ S）之间的相互作用。
