畢業(yè)設(shè)計(jì)（論文）外文翻譯--sql服務(wù)器中的軟件容錯(cuò)

1、<p>　　畢 業(yè) 設(shè) 計(jì)（論 文）</p><p><b>　　英 文 翻 譯</b></p><p><b>　　中文：</b></p><p>　　SQL服務(wù)器中的軟件容錯(cuò)</p><p>　　摘要：對(duì)現(xiàn)在大多數(shù)軟件，軟件容錯(cuò)幾乎只意味著可以保證為現(xiàn)成軟件提供了更好的可靠性，相比沒(méi)有

2、定制開(kāi)發(fā)或額外的成本高很多，我們公布一個(gè)自身實(shí)驗(yàn)裝置的經(jīng)驗(yàn)，就拿現(xiàn)成SQL數(shù)據(jù)庫(kù)服務(wù)器來(lái)說(shuō)。首先，我們描述了一個(gè)防護(hù)性包裝來(lái)掩蓋錯(cuò)誤的影響，在其中一臺(tái)服務(wù)器，而不從供應(yīng)商哪里去等待足夠的修復(fù)。然后，我們討論如何結(jié)合成一個(gè)多元化的模塊化冗余配置（N版本軟件或N種自檢軟件）成各種各樣的服務(wù)器。通過(guò)包裝保證了數(shù)據(jù)庫(kù)不同副本之間的一致性，并為多個(gè)CLI廢除限制并發(fā)客戶之間的交易，實(shí)踐表明，對(duì)于數(shù)據(jù)庫(kù)不同的保護(hù)性包裝模塊化冗余是可行的，復(fù)雜的甚至

3、都可以實(shí)現(xiàn)容錯(cuò)現(xiàn)成組件。</p><p><b>　　1、介紹</b></p><p>　　對(duì)于用（OTS）的軟件元件在會(huì)議上各方各持己見(jiàn)。本文中，我們側(cè)重于可靠性概率LEMS、OTS的組件構(gòu)成的系統(tǒng)集成介紹，他們的文檔通常僅限于定義良好的接口，簡(jiǎn)單的示例應(yīng)用程序演示了如何可以在一個(gè)系統(tǒng)集成的組件。組件廠商很少提供有關(guān)信息的質(zhì)量和使用的V＆V程序。這將創(chuàng)建任何嚴(yán)格的可

4、靠性要求的集成問(wèn)題。至少在非安全關(guān)鍵CAL行業(yè)，供應(yīng)商往往把不能接受甚至反感的現(xiàn)成組件的查詢質(zhì)量。這也是目前系統(tǒng)集成商所面臨的。</p><p>　　我們所使用的“組件”一詞在通用工程意義稱為組裝，它可形成一個(gè)系統(tǒng)，并且是在他們自己的權(quán)利系統(tǒng)基礎(chǔ)上建立的。“組件”可能是任何一件事，在軟件庫(kù)中用于組裝應(yīng)用，并可以作為獨(dú)立系統(tǒng)使用的應(yīng)用程序。我們一起審議現(xiàn)成的商業(yè)和非商業(yè)（COTS），例如：開(kāi)放資源組件在我們的討論中

5、并不顯著。但是源代碼是可用的，可以利用它的規(guī)模和復(fù)雜特性。可能會(huì)拒絕優(yōu)勢(shì)通常采取授予時(shí)的源代碼是可用的系統(tǒng)集成商不能信任的組成部分，充分可靠的系統(tǒng)的需求，往往不是系統(tǒng)的建設(shè)任務(wù)。我們認(rèn)為容錯(cuò)往往是獲取所需可靠性方式的唯一辦法，在系統(tǒng)升級(jí)中，使用OTS的組件。通常情況下，不能改善OTS的組件，執(zhí)行額外的V＆V活動(dòng)是不可行的。這種情況很可能在未來(lái)改變，如果客戶強(qiáng)烈要求實(shí)現(xiàn)與OTS的組件開(kāi)發(fā)，其交易影響力是可想而知的，但這種可能性并不能幫助當(dāng)

6、下的系統(tǒng)集成商。容錯(cuò)可采取多種形式。例如，額外的（可能是特制的，但相對(duì)簡(jiǎn)單）組件進(jìn)行保護(hù)性包裝，像看門狗，顯示器，對(duì)OTS的組件還具有審計(jì)職能，前檢測(cè)意外是為了防止程序產(chǎn)生嚴(yán)重后果，甚至影響組件的狀態(tài)恢復(fù)全面復(fù)制。這種“不同的模塊化冗余”似乎是可取的，通過(guò)一個(gè)非常簡(jiǎn)單的架構(gòu)達(dá)到端與端連接，以及</p><p>　　2、OTS的SQL服務(wù)器的實(shí)驗(yàn)環(huán)境</p><p>　　軟件實(shí)驗(yàn)中心在倫敦城

7、市大學(xué)，理工大學(xué)，保加利亞的普羅夫迪夫已初見(jiàn)成效。它允許一個(gè)客戶端運(yùn)行各種應(yīng)用程序，同時(shí)針對(duì)不同的SQL服務(wù)器使用入門級(jí)的SQL-92語(yǔ)言子集。該試驗(yàn)臺(tái)作為一個(gè)DCOM組件包裝實(shí)現(xiàn)客戶端應(yīng)用程序訪問(wèn)SQL服務(wù)器。圖1為它的架構(gòu)。創(chuàng)建測(cè)試平臺(tái)，允許3個(gè)功能相媲美的SQL服務(wù)器，Oracle 8.0.5，MS SQL7.0，Interbase6.0進(jìn)行實(shí)驗(yàn)。服務(wù)器可運(yùn)行在任何操作系統(tǒng)，其中我們用于實(shí)驗(yàn)的三個(gè)服務(wù)器的Windows 2000專

8、業(yè)版適用本產(chǎn)品，</p><p>　　我們已經(jīng)嘗試用1和100之間的客戶數(shù)目反映每個(gè)不等的客戶端動(dòng)作，其中包括查詢或修改數(shù)據(jù)庫(kù)（選擇）（INSERT，UPDATE，DELETE）觸發(fā)器和存儲(chǔ)過(guò)程。我們用到兩個(gè)應(yīng)用程序</p><p>　　（i）在現(xiàn)實(shí)生活中的倉(cāng)庫(kù)應(yīng)用程序的變化；</p><p>　?。╥i）對(duì)于一個(gè)簡(jiǎn)化的銀行應(yīng)用程序，在資金總額不變的條件下資金賬戶之

9、間的轉(zhuǎn)移是保持不變的，允許整體系列是否正確處理服務(wù)器（S）的一個(gè)簡(jiǎn)單的正確性檢查。與“倉(cāng)庫(kù)”的客戶端應(yīng)用程序，數(shù)據(jù)庫(kù)中的表進(jìn)行比較，檢查是否在預(yù)定的時(shí)間間隔里保持?jǐn)?shù)據(jù)庫(kù)一致，為了檢測(cè)服務(wù)器已在分歧的情況下失敗。第三個(gè)應(yīng)用是在發(fā)展的TPC-C進(jìn)行基準(zhǔn)測(cè)試。測(cè)試平臺(tái)配置參數(shù)是允許改變的，如：客戶數(shù)量和每一個(gè)實(shí)驗(yàn)中提交的查詢; 客戶“需求概況”，集中定義一個(gè)概率分布查詢使用。測(cè)試平臺(tái)選擇查詢類型和參數(shù)值，AC盤帶用戶設(shè)置的概率分布。存在一個(gè)“

10、模板編輯器”工具延長(zhǎng)交易集和概率分布，這樣就可以嘗試使用更廣泛服務(wù)器上的負(fù)載;</p><p>　　并發(fā)控制的各種模式之間的客戶。</p><p>　　免費(fèi)模式，即不受限制地接觸到所有客戶端的服務(wù)器。由服務(wù)器提供的交易之間的隔離級(jí)別設(shè)置為serialisable，但沒(méi)有機(jī)制（如原子廣播）是在測(cè)試平臺(tái)實(shí)施控制查詢被傳遞到單個(gè)服務(wù)器?？蛻舳耸嵌嗑€程的，每一個(gè)服務(wù)器是一個(gè)單獨(dú)的線程談話。<

11、/p><p>　　瓶頸模式，一個(gè)非常嚴(yán)格的客戶端訪問(wèn)服務(wù)器的訂單總額，與客戶之間的任何并發(fā)。代表客戶的線程同步（使用的關(guān)鍵部分）和服務(wù)器在同一時(shí)間只有一個(gè)事務(wù)提供。下一交易（來(lái)自任何競(jìng)爭(zhēng)的客戶端）啟動(dòng)后，以前的事務(wù)被提交或回滾。</p><p>　　Write Bottleneck模式，在包裝允許的情況下，目前的觀測(cè)（即只讀）交易被發(fā)送到服務(wù)器，但任意數(shù)量的并發(fā)之間沒(méi)有修改交易（其中包含至少在

12、INSERT，DELETE或UPDATE聲明）。其只能修改交易開(kāi)始后的對(duì)于以前的修改交易完成（提交或回滾）。</p><p>　　數(shù)據(jù)庫(kù)中的SERV-ING間??隔ERS檢查他們是否仍在運(yùn)行。對(duì)于每個(gè)詳細(xì)的事件日志做實(shí)驗(yàn)記錄，例如，作為發(fā)送的查詢，所提出的所有異常，ping響應(yīng)，查詢和響應(yīng)的時(shí)間與數(shù)據(jù)庫(kù)進(jìn)行比較。</p><p><b>　　3、服務(wù)器故障包裝</b>

13、</p><p>　　容錯(cuò)是一種明確的處理與已知的故障。我們以Microsoft SQL V7.0服務(wù)器為例，發(fā)現(xiàn)，當(dāng)客戶數(shù)量超過(guò)20人次，創(chuàng)建SQL服務(wù)器競(jìng)爭(zhēng)線程之間客戶服務(wù)共享鎖停止正常工作。一個(gè)奇特的情況可能會(huì)出現(xiàn)一些客戶獲得他們所需要的鎖，但仍然在“等待”狀態(tài)，從而保持持續(xù)（這種不正常的情況是不是死鎖的所有其他客戶端試圖獲取同一個(gè)鎖），其中服務(wù)器將檢測(cè)和處理回滾所有競(jìng)爭(zhēng)性的交易，但是問(wèn)題在于并發(fā)客戶端數(shù)量

14、增大時(shí)，頻率也隨之增加。我們后來(lái)發(fā)現(xiàn)，微軟的SQL服務(wù)器的故障（錯(cuò)誤＃56013）問(wèn)題。一個(gè)解決的是應(yīng)用程序管理員 - 或 - 檢測(cè)情況，并介入殺害的線程持有的所有鎖，但仍然在“睡眠”狀態(tài)（即是在封鎖鏈的根線程）。然而，由管理員手動(dòng)除是昂貴的，如果所有的客戶端能正確處理這種情況可能仍然允許前正在開(kāi)展的大延誤。明確處理在客戶端應(yīng)用程序的問(wèn)題僅僅是的SATIS工廠。我們已經(jīng)找到了另一種完全自動(dòng)化的解決方案，這種方案，可以改變舊版客戶端的情況

15、下并包裝在一起。它采用了PA的MSSQL，LOCK_TIMEOUT，可以明確設(shè)置為每個(gè)查詢的具體。它的默認(rèn)值是0，即阻塞的線程將等待永遠(yuǎn)為所需要的鎖。設(shè)置鎖超時(shí)過(guò)期時(shí)</p><p><b>　　外文資料</b></p><p>　　Software Fault-Tolerance with Off-the-Shelf SQL Servers</p>&

16、lt;p>　　P. Popov1, L. Strigini1, A. Kostov2, V. Mollov2, and D. Selensky2 </p><p>　　1 Centre for Software Reliability, City University, London, UK </p><p>　　{ptp,strigini}@csr.city.ac.uk </

17、p><p>　　2 Department of Computing, Technical University, Plovdiv, Bulgaria </p><p>　　alex@obs.bg,vmollov@yahoo.com,selensky@bigfoot.com </p><p>　　Abstract:With off-the-shelf software,

18、software fault tolerance is almost the only means available for assuring better dependability than the off-the-shelf software offers, without the much higher costs of bespoke development or extra V&V. We report our e

19、xperience with an experimental setup we have developed with off-the-shelf SQL database servers. First, we describe the use of a protective wrapper to mask the effects of a bug in one of the servers, without depending o

20、n an adequate fix from the</p><p>　　1 Introduction </p><p>　　The audience of this conference is well aware of the pros and cons of using off-theshelf (OTS) software components1. In this paper w

21、e focus on the dependability problems that OTS components pose to system integrators: their documentation is usually limited to well defined interfaces, and simple example applications demonstrating how the components c

22、an be integrated in a system. Component vendors rarely provide information about the quality and V&V procedures used. This creates problems for any</p><p>　　1 We use the term “components” in the generic

23、 engineering meaning of “pieces that are assembled to form a system, and are systems in their own right”. “Components” may be anything ranging from software libraries, used to assemble applications, to complete applica

24、tions that can be used as stand-alone systems. We consider together commercial-off-the-shelf (COTS) and non-commercial off-the-shelf, e.g. open-source, components: the difference is not significant in our discussion. Eve

25、n when the sou</p><p>　　R. Kazman and D. Port (Eds.): ICCBSS 2004, LNCS 2959, pp. 117–126, 2004. © Springer-Verlag Berlin Heidelberg 2004 </p><p>　　with the task of building systems out of

26、components which cannot be trusted to be sufficiently dependable for the system’s needs, and often are not. As we argued elsewhere [2] fault-tolerance is often the only viable way of obtaining one’s required dependabilit

27、y at the system level, given the use of OTS components. In this common scenario, the alternatives – improving the OTS components, performing additional V&V activities – are either impossible or infeasible without cos

28、ts comparable to those</p><p>　　regarding diverse modular redundancy, we consider N-version programming (NVP) and N-version self-checking programming (NSCP) – to use the terminology of [5]. In NVP, the syst

29、em’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 o

30、n guaranteed consistency between the states of the diverse replicas of the database. This problem of repli</p><p>　　regarding protective wrapping, we have outlined elsewhere [8] the idea of protective wrapp

31、ing for OTS components. Wrappers intercept both incorrect and potentially dangerous communications between OTS components and the rest of the system, thus protecting them against each other’s faults. For an OTS SQL serv

32、er, </p><p>　　the protective wrapper protects the clients against faults of the server, the server </p><p>　　against faults of the clients, and also each client against the indirect effects of f

33、aults </p><p>　　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 r

34、estricting the interaction between the clients and the SQL server(s). </p><p>　　2 The Experimental Environment for OTS SQL Servers </p><p>　　The testbed has been built in collaboration between t

35、he Centre for Software Reliability 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 sig

36、nificant sub-set of the entry-level SQL-92 language. The testbed contains a wrapper for the SQL servers, implemented as a DCOM component, accessed by the client applications. Fig. 1 shows its architecture. The testbed w

37、as crea</p><p>　　Fig. 1. Architecture of the testbed</p><p>　　We have experimented with between 1 and 100 clients and varying numbers of transactions per client, which include queries (SELECT)

38、or modifications of the databases (INSERT, UPDATE, DELETE), “triggers” and “stored procedures”. We have used two applications: i) a variation of a real-life warehouse application; ii) a simplified banking application, in

39、 which funds are being transferred between accounts under the invariant condition that the total amount of funds remains constant. This invariant al</p><p>　　databases remain consistent, but no oracle exists

40、 to detect which of the servers has failed in case of disagreement. A third application is under development, based on the TPC-C benchmark [9]. The testbed allows different configuration parameters to be changed such as:

41、 ? the number of clients and of queries submitted by each in an experiment; ? the “demand profiles” of the clients, a probability distribution defined on the set of </p><p>　　queries used. The query types an

42、d parameter values are chosen by the testbed, according to user-set probability distributions. A “Template Editor” tool exists for extending the set of transactions and setting the probability distributions, so that one

43、 can experiment with a wide range of loads on the servers; </p><p>　　? various modes of concurrency control between the clients: </p><p>　　? Free mode, i.e. unrestricted access to servers by all

44、 clients. The level of isolation between the transactions provided by the servers is set to “serialisable”, but no mechanism (e.g. atomic broadcast) is implemented in the testbed to control the order in which the queries

45、 are delivered to the individual servers and hence executed by the servers. The clients are multithreaded, with a separate thread talking to each of the servers. </p><p>　　? Bottleneck mode, which imposes

46、a very restrictive total order of the access by the clients to the server, with no concurrency between the clients. The threads representing the clients are synchronised (using critical sections) and the servers are supp

47、lied with only one transaction at a time. The next transaction (coming from any of the competing clients) is only initiated after the previous transaction is either committed or rolled back; </p><p>　　? Writ

48、eBottleneck mode, in which the wrapper allows an arbitrary number of concurrent observing (i.e. read-only) transactions to be sent to the servers but no concurrency between the modifying transactions (which contain at l

49、east one INSERT, DELETE or UPDATE statement). A modifying transaction can only be started after the previous modifying transaction is completed (committed or rolled back). </p><p>　　? intervals for comparis

50、on of the tables in the databases and for “ping”-ing the serv</p><p>　　ers to check whether they are still functioning. For each experiment, a detailed log of events is recorded, including, e.g., all querie

51、s as sent, all exceptions raised, ping responses, results of database comparison, with timestamps for queries and responses. </p><p>　　3 Wrapping against Known Faults in a Server </p><p>　　A for

52、m of fault-tolerance is to deal explicitly with known faults. We give one example here. With the Microsoft SQL v7.0 server, we observed that when the number of clients exceeded 20, the sharing of LOCKS between the compe

53、ting threads created by the SQL server to serve its clients could cease to work properly. A peculiar situation could arise in which some clients acquired the locks they needed but remained in the “waiting” state, thus ke