【正文】 一個實驗測試平臺，它實現(xiàn)了一個多樣化的冗余 SQL服務(wù)器通過包裝 SQL服務(wù)器的冗余，使多個用戶同時包裹的 SQL服務(wù)器上運行他們的交易。在現(xiàn)有的 SQL 服務(wù)器是常見的故障。這種“不同的模塊化 冗余”似乎是可取的，通過一個非常簡單的架構(gòu)達到端與端連接，以及防止相同的故障，將保護在副本內(nèi)非多樣的模塊化冗余。通常情況下，不能改善 OTS 的組件，執(zhí)行額外的 V＆ V 活動是不可行的。我們一起審議現(xiàn)成的商業(yè)和非商業(yè)（ COTS），例如：開放資源組件在我們的討論中并不顯著。至少在非安全關(guān)鍵 CAL行 業(yè)，供應(yīng)商往往把不能接受甚至反感的現(xiàn)成組件的查詢質(zhì)量。 介紹 對于用（ OTS）的軟件元件在會議上各方各持己見。 畢 業(yè) 設(shè) 計 （ 論 文 ） 英 文 翻 譯 中文： SQL 服務(wù)器中的軟件容錯 摘要： 對現(xiàn)在大多數(shù)軟件，軟件容錯幾乎只意味著可以保證為現(xiàn)成軟件提供了更好的可靠性，相比沒有定制開發(fā)或額外的成本高很多，我們公布一個自身實驗裝置的經(jīng)驗，就拿現(xiàn)成 SQL數(shù)據(jù)庫服務(wù)器來說。通過包裝保證了數(shù)據(jù)庫不同副本之間的一致性，并為多個 CLI廢除限制并發(fā)客戶之間的交易，實踐表明，對于數(shù)據(jù)庫不同的保護性包裝模塊化冗余是可行的，復(fù)雜的甚至都可以實現(xiàn)容錯現(xiàn)成組件。這將創(chuàng)建任何嚴格的可靠性要求的集成問題?！敖M件”可能是任何一件事，在軟件庫中用于組裝應(yīng)用，并可以作為獨立系統(tǒng)使用的應(yīng)用程序。我們認為容錯往往是獲取所需可靠性方式的唯一辦法，在系統(tǒng)升級中，使用 OTS 的組件。例如，額外的（可能是特制的，但相對簡單）組件進行保護性包裝，像看門狗，顯示器，對 OTS的組件還具有審計職能，前檢測意外是為了防止程序產(chǎn)生嚴重后果，甚至影響組件的狀態(tài)恢復(fù)全面復(fù)制。為了研究這些問題，我們已選定了廣泛的應(yīng)用，相當復(fù)雜的 OTS的組件類別：SQL 數(shù)據(jù)庫服務(wù)器。鑒于許多可用的 SQL服務(wù)器的在職培訓(xùn)和不斷增長其功能（ SQL 92， SQL 99）建立一個容錯性的 OTS 服務(wù)器和 SQL服務(wù)器是合理的。 NVP系統(tǒng)的輸出是由復(fù)制輸出的一票。t OTS 的組件包裝。在我們的設(shè)計方法，我們假設(shè) OTS的 SQL服務(wù)器沒有改變，因為我們沒有進入其內(nèi)部。該試驗臺作為一個 DCOM 組件包裝實現(xiàn)客戶端應(yīng)用程序訪問SQL 服務(wù)器。 我們用到兩個應(yīng)用程序 （ i）在現(xiàn)實生活中的倉庫應(yīng)用程序的變化； （ ii） 對于一個簡化的銀行應(yīng)用程序，在資金總額不變的條件下資金賬戶之間的轉(zhuǎn)移 是保持不變的，允許整體系列是否正確處理服務(wù)器（ S）的一個簡單的正確性檢查。 客戶“需求概況”，集中定義一個概率分布查詢使用。 免費模式，即不受限制地接觸到所有客戶端的服務(wù)器。代表客戶的線程同步（使用的關(guān)鍵部分）和服務(wù)器在同一時間只有一個事務(wù)提供。 數(shù)據(jù)庫中的 SERVING間 隔 ERS 檢查他們是否仍在運行。一個奇特的情況可能會出現(xiàn)一些客戶獲得他們所需要的鎖，但仍然在“等待”狀態(tài)，從而保持持續(xù)（這種不正常的情況是不是死鎖的所有其他客戶端試圖獲取同一個鎖），其中服務(wù)器將檢測和處理回滾所有競爭性的交易，但是問題在于并發(fā)客戶端數(shù)量增大時，頻率也隨之增加。明確處理在客戶端應(yīng)用程序的問題僅僅是的 SATIS工廠。設(shè)置鎖超時過期時將其設(shè)置為非零值（ 10 秒），使服務(wù)器提高異?！版i請求超時時間超過”。當然，我們簡單的解決方案的成本，回滾多個交易：不一定是成本高。一個復(fù)雜的查詢可能需要很長的輕負載下（例如執(zhí)行復(fù)雜的查詢與子查詢）完成，因此，所有查詢一個大的查詢超時設(shè)置是合理的。當已知問題留由供應(yīng)商開放，系統(tǒng)集成商引入保護包裝，或在客戶端應(yīng)用程序建立一個解決的唯一選擇。總之，在包裝實施修復(fù)，減少對供應(yīng)商的修 復(fù)的依賴，似乎總是比它在客戶端應(yīng)用程序?qū)崿F(xiàn)更好的選項，只要可行的，并在運行時所產(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,