【正文】 一個(gè)實(shí)驗(yàn)測(cè)試平臺(tái)，它實(shí)現(xiàn)了一個(gè)多樣化的冗余 SQL服務(wù)器通過包裝 SQL服務(wù)器的冗余，使多個(gè)用戶同時(shí)包裹的 SQL服務(wù)器上運(yùn)行他們的交易。在現(xiàn)有的 SQL 服務(wù)器是常見的故障。這種“不同的模塊化 冗余”似乎是可取的，通過一個(gè)非常簡(jiǎn)單的架構(gòu)達(dá)到端與端連接，以及防止相同的故障，將保護(hù)在副本內(nèi)非多樣的模塊化冗余。通常情況下，不能改善 OTS 的組件，執(zhí)行額外的 V＆ V 活動(dòng)是不可行的。我們一起審議現(xiàn)成的商業(yè)和非商業(yè)（ COTS），例如：開放資源組件在我們的討論中并不顯著。至少在非安全關(guān)鍵 CAL行 業(yè)，供應(yīng)商往往把不能接受甚至反感的現(xiàn)成組件的查詢質(zhì)量。 介紹 對(duì)于用（ OTS）的軟件元件在會(huì)議上各方各持己見。 畢 業(yè) 設(shè) 計(jì) （ 論 文 ） 英 文 翻 譯 中文： SQL 服務(wù)器中的軟件容錯(cuò) 摘要： 對(duì)現(xiàn)在大多數(shù)軟件，軟件容錯(cuò)幾乎只意味著可以保證為現(xiàn)成軟件提供了更好的可靠性，相比沒有定制開發(fā)或額外的成本高很多，我們公布一個(gè)自身實(shí)驗(yàn)裝置的經(jīng)驗(yàn)，就拿現(xiàn)成 SQL數(shù)據(jù)庫服務(wù)器來說。通過包裝保證了數(shù)據(jù)庫不同副本之間的一致性，并為多個(gè) CLI廢除限制并發(fā)客戶之間的交易，實(shí)踐表明，對(duì)于數(shù)據(jù)庫不同的保護(hù)性包裝模塊化冗余是可行的，復(fù)雜的甚至都可以實(shí)現(xiàn)容錯(cuò)現(xiàn)成組件。這將創(chuàng)建任何嚴(yán)格的可靠性要求的集成問題?！敖M件”可能是任何一件事，在軟件庫中用于組裝應(yīng)用，并可以作為獨(dú)立系統(tǒng)使用的應(yīng)用程序。我們認(rèn)為容錯(cuò)往往是獲取所需可靠性方式的唯一辦法，在系統(tǒng)升級(jí)中，使用 OTS 的組件。例如，額外的（可能是特制的，但相對(duì)簡(jiǎn)單）組件進(jìn)行保護(hù)性包裝，像看門狗，顯示器，對(duì) OTS的組件還具有審計(jì)職能，前檢測(cè)意外是為了防止程序產(chǎn)生嚴(yán)重后果，甚至影響組件的狀態(tài)恢復(fù)全面復(fù)制。為了研究這些問題，我們已選定了廣泛的應(yīng)用，相當(dāng)復(fù)雜的 OTS的組件類別：SQL 數(shù)據(jù)庫服務(wù)器。鑒于許多可用的 SQL服務(wù)器的在職培訓(xùn)和不斷增長(zhǎng)其功能（ SQL 92， SQL 99）建立一個(gè)容錯(cuò)性的 OTS 服務(wù)器和 SQL服務(wù)器是合理的。 NVP系統(tǒng)的輸出是由復(fù)制輸出的一票。t OTS 的組件包裝。在我們的設(shè)計(jì)方法，我們假設(shè) OTS的 SQL服務(wù)器沒有改變，因?yàn)槲覀儧]有進(jìn)入其內(nèi)部。該試驗(yàn)臺(tái)作為一個(gè) DCOM 組件包裝實(shí)現(xiàn)客戶端應(yīng)用程序訪問SQL 服務(wù)器。 我們用到兩個(gè)應(yīng)用程序 （ i）在現(xiàn)實(shí)生活中的倉庫應(yīng)用程序的變化； （ ii） 對(duì)于一個(gè)簡(jiǎn)化的銀行應(yīng)用程序，在資金總額不變的條件下資金賬戶之間的轉(zhuǎn)移 是保持不變的，允許整體系列是否正確處理服務(wù)器（ S）的一個(gè)簡(jiǎn)單的正確性檢查。 客戶“需求概況”，集中定義一個(gè)概率分布查詢使用。 免費(fèi)模式，即不受限制地接觸到所有客戶端的服務(wù)器。代表客戶的線程同步（使用的關(guān)鍵部分）和服務(wù)器在同一時(shí)間只有一個(gè)事務(wù)提供。 數(shù)據(jù)庫中的 SERVING間 隔 ERS 檢查他們是否仍在運(yùn)行。一個(gè)奇特的情況可能會(huì)出現(xiàn)一些客戶獲得他們所需要的鎖，但仍然在“等待”狀態(tài)，從而保持持續(xù)（這種不正常的情況是不是死鎖的所有其他客戶端試圖獲取同一個(gè)鎖），其中服務(wù)器將檢測(cè)和處理回滾所有競(jìng)爭(zhēng)性的交易，但是問題在于并發(fā)客戶端數(shù)量增大時(shí)，頻率也隨之增加。明確處理在客戶端應(yīng)用程序的問題僅僅是的 SATIS工廠。設(shè)置鎖超時(shí)過期時(shí)將其設(shè)置為非零值（ 10 秒），使服務(wù)器提高異?！版i請(qǐng)求超時(shí)時(shí)間超過”。當(dāng)然，我們簡(jiǎn)單的解決方案的成本，回滾多個(gè)交易：不一定是成本高。一個(gè)復(fù)雜的查詢可能需要很長(zhǎng)的輕負(fù)載下（例如執(zhí)行復(fù)雜的查詢與子查詢）完成，因此，所有查詢一個(gè)大的查詢超時(shí)設(shè)置是合理的。當(dāng)已知問題留由供應(yīng)商開放，系統(tǒng)集成商引入保護(hù)包裝，或在客戶端應(yīng)用程序建立一個(gè)解決的唯一選擇。總之，在包裝實(shí)施修復(fù)，減少對(duì)供應(yīng)商的修 復(fù)的依賴，似乎總是比它在客戶端應(yīng)用程序?qū)崿F(xiàn)更好的選項(xiàng)，只要可行的，并在運(yùn)行時(shí)所產(chǎn)生的性能損失是能接受的。 SpringerVerlag Berlin Heidelberg 2020 with the task of building systems out of ponents which cannot be trusted to be sufficiently dependable for the system’s needs, and often are not. As we argued elsewhere [2] faulttolerance is often the only viable way of obtaining one’s required dependability at the system level, given the use of OTS ponents. In this mon scenario, the alternatives – improving the OTS ponents, performing additional Vamp。 we used Windows 2020 Professional edition for experiments with the three servers and several operating systems (Win2k, Win98 and RedHat Linux ) for experiments with Interbase. Fig. 1. Architecture of the testbed We have experimented with between 1 and 100 clients and varying numbers of transactions per client, which include queries (SELECT) or modifications of the databases (INSERT, UPDATE, DELETE), “triggers” and “stored procedures”. We have used two applications: i) a variation of a reallife warehouse application。 ? WriteBottleneck mode, in which the wrapper allows an arbitrary number of concurrent observing (. readonly) transactions to be sent to the servers but no concurrency between the modifying transactions (which contain at least one INSERT, DELETE or UPDATE statement). A modifying transaction can only be started after the previous modifying transaction is pleted (mitted or rolled back). ? intervals for parison of the tables in the databases and for “ping”ing the serv ers to check whether they are still functioning. For each experiment, a detailed log of events is recorded, including, ., all queries as sent, all exceptions raised, ping responses, results of database parison, with timestamps for queries and responses. 3 Wrapping against Known Faults in a Server A form of faulttolerance is to deal explicitly with known faults. We give one example here. With the Microsoft SQL server, we observed that when the number of clients exceeded 20, the sharing of LOCKS between the peting 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 keeping all the other clients (trying to acquire the same locks) from continuing (this abnormal situation is not a deadlock, which the server would detect and handle by rolling back all peting transactions but one). The problem only occurs when the number of concurrent clients is large,