1.DeadLocks 死鎖 Cycle of transactions waiting for locks to be released by each other. 2.Handle: (1) DeadLocks prevention Based on timestamps; Wait-Die ...
1.DeadLocks 死鎖
Cycle of transactions waiting for locks to be released by each other.
2.Handle:
(1) DeadLocks prevention
Based on timestamps;
Wait-Die
Wound-wait
(2) DeadLocks detection
wait-for graph(check for them and fix them if a deadlocks was found, abort/rollback this transactions)
3.發生死鎖的四個必要條件：
(1)互斥條件
主體對於資源是獨占的，上圖中每條汽車道只能跑一隊汽車，不能跑第二隊。
(2)請求和等待條件
指主體已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它主體占有，此時請求主體阻塞，但又對自己已獲得的其它資源保持不放。在上圖中，每隊汽車已經占有了一條車道，又想獲得另一條由其它車隊占有的車道，造成阻塞。
(3)不剝奪條件
指的是主體已經獲得的資源在完成其目標之前不能被釋放。在上圖中，目標指的是汽車可以通過車道，不剝奪指的是在完成這個目標之前，車隊並不會讓出其已占的車道。
(4)環路等待條件
指在發生死鎖時，必然存在一個主體——資源的環形鏈，即主體集合{P0，P1，P2，···，Pn}中的P0正在等待一個P1占用的資源；P1正在等待P2占用的資源，……，Pn正在等待已被P0占用的資源。在圖1中可以看出，四條車道和四隊汽車正好符號環路等待的條件，車隊1希望獲得車隊2占有的車道，車隊2希望獲得車隊3占有的車道，車隊3希望獲得車隊4占有的車道,車隊4反過來又希望獲得車隊1占有的車道，形成一個環路。
4.死鎖的預防
(1)破壞互斥條件
假如資源不被獨占，那麼死鎖就不會發生。
(2)破壞占有和等待條件
只要禁止進程在執行中請求其他資源，就不會發生死鎖. [讓每個進程在執行前就分配好它所需要的所有資源，但是存在一個問題:許多進程在執行時才知道自己需要多少資源. 假設我們知道每個進程所需要資源數，可以使用銀行家演算法來避免死鎖]
(3)破壞不可搶占條件
對於某些特殊資源，可以使用虛擬化方式來實現.
(4)破壞環路等待條件
如果進程要請求另一個資源，則必須放棄前面已掌握的資源，這就可以避免環路出現.
5.線程調度演算法
(1)"先進先出"策略
所有線程組成一個隊列，新的線程加入隊列末尾，每次取出隊首來執行。但是存在一個缺陷:新生成的線程如果是緊急操作，需要系統儘快響應，則該方法不滿足要求.
(2)按照優先順序調度
每個線程有自己的優先等級，並且是可被操作系統修改的. 然而這種方法也存在缺陷。也就是所謂的饑餓 如果一個線程"看似無關緊要",被賦予一個很低的優先順序，假設以後每個線程的優先等級都比它高，那麼該線程一直得不到執行。(一個解決方法是隨著時間的推移而提升線程的優先順序)
6.線程狀態以及轉化：
(1)已初始化(Initialized)
(2)運行(Running)
(3)備份(Standby)
(4)已終止(Terminated)
(5)等待(Waiting)
(6)轉移(Transition)
(7)延遲的就緒(DeferredReady)
(8)門等待(Gatewait)
7.SQL Server中死鎖的檢測
(1)通過服務端的Trace來做
當死鎖發生後，通過服務端的Trace就可以將死鎖信息傳到日誌。在SQL Server 2000時代，只能通過Trace flag 1204來開啟，由於Trace flag 1204並不能提供XML死鎖圖，在SQL Server 2005以及之後的版本被Trace flag 1222所取代。
為了在服務端針對所有的Session開啟Trace flag 1222。可以通過如下代碼所示。
DBCC TRACEON(1222,-1)
針對所有Session開啟1222這個Trace Flag
除去上述代碼之外，還可以通過在啟動SQL Server實例之前，對加啟動參數 –t1222。這裡就不再細說了。
此時，當發生死鎖後，就能從日誌看到相關的記錄，如下圖所示。
(2)通過SQL Profiler
另一種方法是開啟Profiler來捕捉,Profiler捕捉到的圖示死鎖信息內容就更直觀了，Profiler的設置如下圖所示。
所抓到的死鎖圖如下圖所示。
8.SQL Server中產生死鎖的一些情況
(1)由書簽查找產生的死鎖
這類死鎖產生的原因是書簽查找和更新數據產生的僵持狀態。簡單來說,就是由於Update語句對基本表產生X鎖，然後需要對錶上的索引也進行更新，而表上的索引正好被另一個連接進行查找，加了S鎖，此時又產生書簽查找去基本表加了X鎖的數據進行書簽查找，此時形成死鎖，這個概念可以從下圖看到。
這種死鎖可以通過Include列來減少書簽查找，從而減少這種類型死鎖發生的概率。
(2)由外鍵產生的死鎖
這類死鎖產生的原因來自外鍵約束。當主表(也就是主鍵是從表外鍵的那個表)更新數據時，需要查看從表，以確定從表的外鍵列滿足外鍵約束。此時會在主表上加X鎖，但這並不能阻止同一時間，另一個SPID向從表添加被修改的主表主鍵，為瞭解決這個問題，SQL Server在進行這類更新時，使用Range鎖，這種鎖是當隔離等級為序列化時才有的，因此在這時雖然隔離等級可能是預設的已提交讀，但是行為卻是序列化。這很可能就會導致死鎖。
解決辦法之一是向外鍵列添加索引，使得Range鎖加在索引上，而不是表本身。從而降低了死鎖發生的概率。
(3)由於推進順序不當產生的死鎖
在多個事務對資源的使用順序不當，形成死鎖環路而引發的。解決方法是儘量是資源的使用順序一致。這也是死鎖問題出現最多的一種情況.
9.如何減少死鎖
(1)預防死鎖
(a)破壞互斥條件
(b)破壞請求和等待條件
(c)破壞不剝奪條件
(d)破壞環路等待條件
(2)避免死鎖:資源有限條件下，主題爭用資源不形成環路，使用銀行家演算法
(3)檢測死鎖:通過系統所設置的監測機構及時地檢測出死鎖的發生，然後採用適當措施，清除死鎖.
(4)解除死鎖:與檢測死鎖相配套的措施,
(a)撤銷或者是掛起一些進程
(b)分配資源給阻塞狀態的進程,使進程轉為就緒狀態.
10.規範化問題的提出
(1)函數依賴
(2)範式
(3)模式設計
11.關係模式的存儲異常問題
SCD(SNO,SN,AGE,DEPT,MN,CNO,SCORE)
SCD:教學管理系統 SNO:學生學號 SN:學生姓名
AGE:學生年齡 DEPT:學生所在院系 MN:系主任姓名
CNO:課程號 SCORE:學生成績
出現的問題：
(1)數據冗餘
(2)插入異常(某個系沒有招生，尚無學生，系名以及系主任的信息無法插入到表中)
(3)刪除異常(這個系所有學生畢業,還沒招生,刪除所有的學生，則系名以及系主任信息也被刪除，但是現實中該系仍然存在，卻在表中無法找到相應的信息)
(4)更新異常(某個學生改名)
12.函數依賴的定義以及性質
(1)定義R(U,F)，U是屬性全集，F是U上的函數依賴集，X和Y為U的子集.若對於每一個X的具體值，Y都有唯一的具體值與之對應，則稱X決定函數Y 或者 Y函數依賴於X. 記做: X—>Y (X叫做決定因素,Y叫做依賴因素)
當Y不依賴X時: X -/->Y
當X—>Y且Y—>X 時記做 X <—>Y (等價條件)
舉例:
知道某個學生學號 —>對應的身份證號
知道某個學生的身份證號 —>對應的學號
因此得到： 學生學號<—>學生身份證號
(2)函數依賴是語義範疇的概念
當學生不存在重名時: SN—>AGE 以及 SN—>DEPT
函數依賴反映了一種語義完整性約束
(3)函數依賴關係的存在與時間無關
(a)元組增加、刪除、更新都不能破壞這種函數依賴
(b)因此,必須通過語義來確定屬性之間的函數依賴，而不能單憑某一時刻關係中的實際數據來確定函數依賴
(4)函數依賴可以保證關係分解的無損連接性
wǒ bú xìn nǐ huì zhè mē wú liáo dē bǎ wǒ zhè jù huà dú yí biàn . rú guǒ nǐ zhēn dē dú lē . wǒ zhǐ xiǎng gào sù ni . wǒ xǐ huan ni .
