103年地特 三等資料庫 - 考試

您好：


從你的應答中發現幾個觀念偏差的地方

處理交易時，若只能循序處理，會造成資源浪費。
例如：
T1 若要執行 10 分鐘，在後面排隊的 T2、T3、T4 .... 每個人都要等 10 分鐘。
不符合經濟效益，所以要做「並行控制」，讓大家的交易可以穿插著執行。

但是，問題就來了：

循序處理 --> 除了浪費時間要等待，沒什麼大問題。
並行控制 --> 會發生「死結、活結、飢餓」，這很嚴重。

而且並行控制的不好，演算法太爛，還會發生：

遺失更新(Lost Update)
不一致分析(Inconsistent Analysis)
未確認相依(Uncommitted Dependency)


這二邊要分的清楚，一個是不想要循序處理所以讓交易並行。
另一個是並行的機制做的不好，引發其它問題。

要知道他們二邊有一點點不同，但事實上最後會黏在一起(後面會說明)。

這裡也不難想像，並行控制雖會引發一大堆問題，但我們還是硬要做並行控制
，這代表它帶來的效益遠超過缺點。


為了避免發生「死結、活結、飢餓」所以我們用：
wait - die
wound - wait
來解決問題。



為了避免發生：
遺失更新(Lost Update)
不一致分析(Inconsistent Analysis)
未確認相依(Uncommitted Dependency)

所以我們用：
鎖定(Locking)
時間戳記(Timestamp)
多重版本並行控制(Multi-version Concurrency Control)

來解決問題。

此為第一個偏差的地方。你把他們混為一談了。
(我知道他們可以合在一起，但先分開看，後面會解釋)






再來。

當優先權與數字搞在一起，就會混淆不清：

數字：1、2、3、4、5
優先：5、4、3、2、1
這是種 First Come First Service(FCFS)，就像在銀行、郵局排隊時抽號碼牌，
數字小的，優先權大。

另一種

數字：1、2、3、4、5
優先：1、2、3、4、5

這種就相反，數字小的，優先權小。



但是 Timestamp 強調的是「早、晚」的問題。

當要進行交易 Tx 時，只要去看時戳「有沒有比我晚的已經做過交易了」?

有：我要 roll back transaction
沒有：我可以進行交易，然後把時戳改成我的。

它的演算法就這麼簡單！

唐箏是這樣教的，陳士杰(高手)的講義也這麼寫，有兩位神的加持，看到其它不
同的，就別管它了吧。

細節的地方來了，當「有比我晚的已經做過交易了」，我只能一味 roll back 嗎?
這時再來談：
wait - die
wound - wait

但是，但是，但是！這是在實作資料庫時才用的到，我們在考試的時候，並不用在
Timestamp 裡面考慮 wait die、wound wait

我們現在在考試，不是要幫公司寫一套資料庫管理系統。
也就是說，不用考慮 wait die、wound wait，答案還是寫的出來。

此其二也。


謝謝各位，祝大家都上榜。

各位高手，承讓。


閒聊：

去年地特三的資料庫，改的很嚴，尤其第三大題。
另外，第一大題沒有人發現那裡不對勁嗎? 我站在旁邊觀察很久，版上都沒人提出來。
好吧，讀書去。



--