【正文】 nts to the server, with no concurrency between the clients. The threads representing the clients are synchronised (using critical sections) and the servers are supplied with only one transaction at a time. The next transaction (ing from any of the peting clients) is only initiated after the previous transaction is either mitted or rolled back。V activities – are either impossible or infeasible without costs parable to those of bespoke development. This situation may well change in the future, if customers with serious dependability requirements achieve more clout in their dealings with OTS ponent developers, but this possibility does not help system integrators who are in this 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。選擇后者可能是更有效的，但它是管理和正確實(shí)施更加修復(fù)和任何后續(xù)的升級(jí)，它必須在所有客戶端應(yīng)用程序的復(fù)制。另一種方法殺線程塊頂部 ?鏈也有其成本。我們已經(jīng)找到了另一種完全自動(dòng)化的解決方案，這種方案，可以改變舊版客戶端的情況下并包裝在一起。對(duì)于每個(gè)詳細(xì)的事件日志做實(shí)驗(yàn)記錄，例如，作為發(fā)送的查詢，所提出的所有異常， ping響應(yīng)，查詢和響應(yīng)的時(shí)間與數(shù)據(jù)庫(kù)進(jìn)行比較。由服務(wù)器提供的交易之間的隔離級(jí)別設(shè)置為 serialisable， 但沒(méi)有機(jī)制（如原子廣播）是在測(cè)試平臺(tái)實(shí)施控制查詢被傳遞到單個(gè)服務(wù)器。與“倉(cāng)庫(kù)”的客戶端應(yīng)用程序，數(shù)據(jù)庫(kù)中的表進(jìn)行比較，檢查是否在預(yù)定的時(shí)間間隔里保持?jǐn)?shù)據(jù)庫(kù)一致，為了檢測(cè)服務(wù)器已在分歧的情況下失敗。必要性，因此，我們的解決方案是基于限制的客戶端和 SQL服務(wù)器（ S）之間的相互作用。在 NSCP，每一個(gè)不同的“版本”應(yīng)該失敗干凈，使任何人都可以復(fù)制的產(chǎn)出作為系統(tǒng)的輸出使用。在現(xiàn)有的 SQL 服務(wù)器是常見的故障。通常情況下，不能改善 OTS 的組件，執(zhí)行額外的 V＆ V 活動(dòng)是不可行的。至少在非安全關(guān)鍵 CAL行 業(yè)，供應(yīng)商往往把不能接受甚至反感的現(xiàn)成組件的查詢質(zhì)量。 畢 業(yè) 設(shè) 計(jì) （ 論 文 ） 英 文 翻 譯 中文： SQL 服務(wù)器中的軟件容錯(cuò) 摘要： 對(duì)現(xiàn)在大多數(shù)軟件，軟件容錯(cuò)幾乎只意味著可以保證為現(xiàn)成軟件提供了更好的可靠性，相比沒(méi)有定制開發(fā)或額外的成本高很多，我們公布一個(gè)自身實(shí)驗(yàn)裝置的經(jīng)驗(yàn)，就拿現(xiàn)成 SQL數(shù)據(jù)庫(kù)服務(wù)器來(lái)說(shuō)。這將創(chuàng)建任何嚴(yán)格的可靠性要求的集成問(wèn)題。我們認(rèn)為容錯(cuò)往往是獲取所需可靠性方式的唯一辦法，在系統(tǒng)升級(jí)中，使用 OTS 的組件。為了研究這些問(wèn)題，我們已選定了廣泛的應(yīng)用，相當(dāng)復(fù)雜的 OTS的組件類別：SQL 數(shù)據(jù)庫(kù)服務(wù)器。 NVP系統(tǒng)的輸出是由復(fù)制輸出的一票。在我們的設(shè)計(jì)方法，我們假設(shè) OTS的 SQL服務(wù)器沒(méi)有改變，因?yàn)槲覀儧](méi)有進(jìn)入其內(nèi)部。 我們用到兩個(gè)應(yīng)用程序 （ i）在現(xiàn)實(shí)生活中的倉(cāng)庫(kù)應(yīng)用程序的變化； （ ii） 對(duì)于一個(gè)簡(jiǎn)化的銀行應(yīng)用程序，在資金總額不變的條件下資金賬戶之間的轉(zhuǎn)移 是保持不變的，允許整體系列是否正確處理服務(wù)器（ S）的一個(gè)簡(jiǎn)單的正確性檢查。 免費(fèi)模式，即不受限制地接觸到所有客戶端的服務(wù)器。 數(shù)據(jù)庫(kù)中的 SERVING間 隔 ERS 檢查他們是否仍在運(yùn)行。明確處理在客戶端應(yīng)用程序的問(wèn)題僅僅是的 SATIS工廠。當(dāng)然，我們簡(jiǎn)單的解決方案的成本，回滾多個(gè)交易：不一定是成本高。當(dāng)已知問(wèn)題留由供應(yīng)商開放，系統(tǒng)集成商引入保護(hù)包裝，或在客戶端應(yīng)用程序建立一個(gè)解決的唯一選擇。 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。 ? 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,