1. 程式人生 > >資料庫-事務處理的概念和理論簡介

資料庫-事務處理的概念和理論簡介

在看這一部分內容之前,我對資料庫一些基礎概念和基礎操作的認識十分淺薄,也沒有一些資料庫管理的經驗,因此當學這一部分的時候遇到了賊多理解上的誤區和困難。難受呀,基礎差真的不行。。。但是我已經沒有時間先從頭仔細學習資料庫基礎再學這一部分了,因此只能在泥濘中前行。即使在本文結束之前,好多概念我還是以猜測的方式去理解,因此肯定會有很多錯誤,請有緣人指正。

什麼是事務?為什麼資料庫系統要強調事務的概念?

http://www.hollischuang.com/archives/898
在上面博文的基礎上,我想說明事務的四大特性是其理想屬性,在併發控制的排程中我們的原則就是遵循事務的四大特性,但是難免會出現違反特性的情況,因此就需要採取正確的方法進行併發控制。

在多使用者系統中事務的併發執行意味著什麼?討論併發控制的必要性並給出一個常見的例子

在多使用者系統中事務的併發執行意味著事務存在同一資料資源的可能性,即可能會發生資料衝突,併產生一系列意想不到的錯誤。但是事務可以併發執行的確可以加快整個系統的執行效率,因此有必要對事務的併發執行做出控制,使之得到令人期望的效果。

上述提到的併發執行引起錯誤的型別有哪些?

  • 更新丟失:
  • 暫時更新(髒讀):
  • 錯誤求和:
  • 不可重複讀:

討論故障的不同型別。災難性的故障意味著什麼?

  • 計算機系統崩潰:系統在執行期間可能會發生硬體,軟體,網路等錯誤。還有硬體崩潰如主存錯誤。
  • 事務揮著系統錯誤:事務中的某些操作也會導致事務故障,如整數溢位或者除零。不正確的引數值或者邏輯程式設計也會導致事務故障。此外,使用者可能在事務執行期間進行中斷事務。
  • 併發控制仲裁:併發控制可能會因事務違反了可序列性,或幾個事務之間出現死鎖狀態從而需要做出撤銷事務的操作。被撤銷後的事務還可能需要在稍後被重啟。
  • 磁碟故障:一些磁碟可能會因為讀寫故障導致資料丟失。在事務進行讀寫期間可能會發生這種故障。
  • 物理問題:電源故障,蓄意損壞,誤寫磁碟以及操作員誤操作等。

討論這些故障的原因不言而喻。在設計資料庫系統時必須提前想到儘可能多的故障型別並根據需要對其中的故障型別提前準備好應對措施,儘可能的降低損失。

資料庫事務中讀寫操作

首先需要明白資料項的讀寫操作是發生在記憶體和磁碟之間,從磁碟到記憶體的資料傳輸基本單元是塊,記憶體中組織形勢是頁。在資料庫系統磁碟檔案管理模組中要注意兩者的聯絡與區別。

  • 讀(read_item):將資料庫項X讀到磁盤裡。為了簡化表示,假設程式變數名也是X
  1. 找到包含資料項X的磁碟塊地址。
  2. 將磁碟塊複製到記憶體的一個緩衝區頁面中。
  3. 將資料項X從緩衝區複製到名為X的程式變數中去。
  • 寫(write_item):
  1. 找到包含資料項X的磁碟地址。
  2. 將磁碟塊複製到記憶體的一個緩衝區頁面中。
  3. 將資料項X從程式變數X中複製到它在緩衝區的正確位置。
  4. 將更新後的塊從緩衝區寫回到磁碟中。

事務的狀態

事務狀態

系統日誌的作用?系統日誌中的典型記錄型別是什麼?什麼是事務的提交點?他們的重要性?

日誌是一些儲存在磁碟上的文字檔案,單純的用來記錄事務的一些操作。在記憶體緩衝區中有一部分內容用來記錄最晚的日誌內容,等到用於日誌快取的緩衝區滿或者達到其他條件時就將這部分內容追加到磁碟的文字內容中。一些典型的日誌記錄如下所示:

  • [start_transaction, T] : 表示事務T開始執行。
  • [write_item, T, X, old_value, new_value ] : 事務T對資料項X進行寫操作,還記錄了舊值和新值。
  • [read_item, T, X] : 事務T讀取資料項X。
  • [commit T] : 事務T被提交。表明事務T結束。
  • [abort T] : 事務T被撤銷。沒有更新到磁碟上的操作被忽視,已經更新到磁碟上的事務被回滾,撤銷對磁碟上內容做出的更改。
    事務被提交就意味著資料庫系統不能通過日誌對事務進行撤銷操作。比如說一條sql的更新語句,當這條更新語句的操作被提交之後,對資料所作的更改已經儲存到磁碟,當然不被提交也可以儲存到磁碟,資料庫系統不能自動的進行撤銷操作。但這不代表著這條語句不能被撤銷,可以人為的再進行update回原先的值。這是人為的又執行了另一條事務抵消了上一條事務的影響。當然瞭解到這裡並不代表資料庫系統不能自行撤銷,但這就意味著違反了事務的永續性。。。矛盾呀,這個矛盾肯定來自於這兩個地方的理解偏差。給自己留個坑吧。。。要是我設計的話我就允許系統可以根據日誌做出撤銷操作,當然也是我顯示的給出一條撤銷的指令。。。暈。。。
    事務提交點使用來表徵事務所有訪問資料庫的操作已經完成,並且日誌已經記錄了事務對資料庫產生的影響並已被儲存到磁碟。Mysql操作中savepoint

什麼是衝突?

衝突就是當事務按照不同的次序執行的時候最終得到的不同的結果,這就叫做衝突。

什麼是排程?介紹可恢復排程,無級聯排程,嚴格排程的定義,並比較他們的可恢復性。

  • 排程:當系統中存在幾個事務時,安排一種事務的執行次序就叫做排程。(每一個事務可以分為若干個操作,這若干個操作可以有交叉的執行)
  • 可恢復排程:事務的可恢復性是指當錯誤發生時,事務是可以恢復的。比如說因為斷電而違反了事務的原子性和永續性或一致性,那麼就可以採用一定的方法使資料庫系統恢復到一個一致性狀態。可恢復排程就是指:在一個排程S中,當存在這種情況的時候-T需要要讀取T‘ 寫過後的資料項X,發生這種情況的時候當且僅當滿足T’ 的寫操作先提交,而T的讀操作後提交,這樣的排程就 就叫做可恢復排程。因為排程只要滿足這種條件,並且日誌檔案中有足夠充分的記錄資訊,就可以從這個排程中設計一個恢復演算法進行恢復。(按照前面的定義,事務的讀取操作包括從磁碟中讀取某個資料項X,而不是直接在緩衝區尋找以前別的事務已經讀取過X,此時讀操作的提交代表真的從磁碟中讀取了這個資料項了,而不是我的操作語句處於掛起等待狀態,只是聲明瞭一下並沒有完全的執行;同樣事務的寫操作包括需要先把資料項X從磁碟讀取到緩衝區X中,然後再儲存程式變數的堆裡更改變數值,再複製到相應的緩衝區,再寫回到磁碟中,此時寫操作的提交代表整個過程已經完成,而不是隻執行了一部分,比如說資料項只是在緩衝區中做了修改,而沒有寫回到磁碟)。
  • 完備排程:存在衝突的操作順序在一個排程中和其所在的事務的排程順序是相同的。
    比如說一對寫寫衝突w1(x)和w2(x),在S中事務的執行次序是T1,T2,所以w1(x)的執行需要先於w2(x)的執行。
  • 嚴格排程:在某個事務的寫操作完成之前不允許別的事務中衝突操作執行。是完全可恢復的。
  • 級聯回滾:事務T讀了T’修改過的資料,但是T‘在撤銷之前被撤銷了,當然T也需要撤銷。這種級聯撤銷就叫做級聯回滾。

什麼是序列排程?什麼是可序列化的排程?Why is a serial schdule considered correct?Why is a serializable schdule considered correct?

這個很簡單,並沒有什麼理解上的障礙。。。所以不寫了。

介紹一下事務等價不同的衡量標準,衝突等價和檢視等價有什麼區別?

  • 衡量標準如:對資料庫的影響結果相同,比如說兩個事務對同一資料項進行修改後的值相等,但存在一定的偶然性,所以不用;另一個事務等價的定義就是在不同的事務中,對資料項修改的操作的相對順序相同就可以。。。
  • 衝突等價:在兩個排程中,衝突操作的相對順序相同。
  • 檢視等價:在兩個排程中,相同的讀操作讀到的內容來自於的各自排程中相同的寫操作產生的結果。

可序列化是怎麼用來進行併發控制的?

可以這樣理解:可序列化保證事務的排程是正確的,如果設計的併發控制協議保證了可序列化,那麼就可以保證事務排程的正確性。在這裡事務排程的正確性就是指可以保證事務的ACID特性。其中可序列化包括衝突可序列化和檢視可序列化,預測一個排程是否為衝突可序列化在實際中不可行,因為受到的影響因素太多;而檢測是否是檢視可序列化的演算法又被證明是NP難的問題,所以呀,在實際中都是通過設計一定的併發控制協議來保證排程的衝突可序列性或者檢視可序列性,從而來保證事務的ACID特性。

什麼是嚴格寫和非嚴格寫?

  • 嚴格寫表示一個事務中對資料項X進行寫操作之前需要現有讀操作。換句話說,寫操作的資料和讀操作的資料是一毛一樣的。

可序列性如何用於併發控制?為什麼可序列性過於嚴格?

在實際中很難在一個排程執行之前就可以做出其是否可行性的判斷。因此,實際中都是設定一定的協議或者演算法來保證排程是可序列性的。

描述SQL中四種隔離級別

在這裡插入圖片描述

給出下列情況引起的違規定義:髒讀,不可重複讀,幻想

  • 髒讀:一個事務修改了一個數據項的值,但沒有提交;而正好此時另一個事務讀取了這個沒有被提交的值;但是第一個事務又做出了撤銷操作,此時就會發生髒讀現象。
  • 不可重複讀:一個事務讀取了一個數據項,但是過一會再次讀取的時候這個值被另一個事務修改了,那麼就會發生前後兩次讀取的資料項的值不一致的情形,就叫做不可重複讀。(其實再這裡我感覺這是一個正常現象,有時候確實會發生這種情況,比如說,讀取的某個值被更新了,很正常,但在某些特殊場景下一個事務會兩次讀取這個資料值並要求這兩次讀取的資料值相等,按照我的感覺發生這樣事件的概率很小。。。但也不能忽略呀)
  • 幻像:當是一個事務做查詢時讀取了一些符合where條件的元組,但是一會另一個事務又插進去一些符合where條件的元組,這樣當第一個事務再做查詢時就會發生兩次查詢不一致的情況,而這種情況在某些實際場景下是不被允許的,就會產生錯誤。。。