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