外文翻译---sql服务器中的软件容错(编辑修改稿)

外文翻译---sql服务器中的软件容错(编辑修改稿)内容摘要：

is kind of situation now. Fault tolerance may take multiple forms, ., additional (possibly purposebuilt but relatively simple) ponents performing protective wrapping, watchdog, monitor ing, auditing functions, to detect undesired behaviour of the OTS ponents, pre vent their producing serious consequences, and possibly effecting recovery of the ponents’ states。 or even fullfledged replication with diverse versions of the ponents. Such “diverse modular redundancy” seems desirable because it offers endtoend protection via a fairly simple architecture, and protection against the identical faults that would be present in replicas within a nondiverse modularredundant system. The cost of procuring two or even more OTS ponents (some of which may be free) would still be far less than that of developing one’s own. All these design solutions are well known. The questions, for the developers of a system using OTS ponents, are about the dependability gains, implementation difficulties and extra costs that they would bring for that s pecific system. To study these issues, we have selected a category of widely used, fairly plex OTS ponents: SQL database servers. Faults in the currently available SQL servers are mon. For evidence one can just look at the long list of bug fixes s upplied by the vendors with every new release of their products. Further reliability improvement of SQL servers seems only possible if faulttolerance through design diversity is employed [3]. Given the many available OTS SQL servers and the growing standardisation of their functionality (SQL 92, SQL 99), it seems reasonable to build a faulttolerant SQL server from available OTS servers. We have developed an experimental testbed which implements a diverseredundant SQL server by wrapping a redundant set of SQL servers, so that multiple users run their transactions concurrently on the wrapped SQL servers. We are running experiments to determine the dependability gains achieved through fault tolerance [4]. In this paper, we report on experience gained about the design aspects of building fault tolerance with these specific OTS ponents: ? regarding diverse modular redundancy, we consider Nversion programming (NVP) and Nversion selfchecking programming (NSCP) – to use the terminology of [5]. In NVP, the system’s output is formed by a vote on the replicated outputs. In NSCP, each diverse “version” is supposed to fail cleanly, so that anyone of the replicated outputs can be used as the system’s output. Both solutions depend on guaranteed consistency between the states of the diverse replicas of the database. This problem of replica consistency, despite having been under scrutiny for a long time, is still far from being solved in general for database servers [6], [7]。 ? regarding protective wrapping, we have outlined elsewhere [8] the idea of protective wrapping for OTS ponents. Wrappers intercept both incorrect and potentially dangerous munications between OTS ponents and the rest of the system, thus protecting them against each other’s faults. For an OTS SQL server, the protective wrapper protects the clients against faults of the server, the server against faults of the clients, and also each client against the indirect effects of faults of the other clients. In our design approach we assume no changes to the OTS SQL servers, since we do not have access to their internals. By necessity, therefore, our solutions are based on restricting the interaction between the clients and the SQL server(s). 2 The Experimental Environment for OTS SQL Servers The testbed has been built in collaboration between the Centre for Software Reliabil ity at City University, London, and the Technical University in Plovdiv, Bulgaria. It allows one to run various client applications concurrently against diverse SQL servers which use a significant subset of the entrylevel SQL92 language. The testbed contains a wrapper for the SQL servers, implemented as a DCOM ponent, accessed by the client applications. Fig. 1 shows its architecture. The testbed was created to allow experiments with 3 functionally parable OTS SQL servers, Oracle , MS SQL , Interbase . The servers can run under any oper。