事務的完整性
    1、原子性
	事務必須是原子的，在事務結束的時候，事務中的操作要么全部完成，要么什么也沒做。
   	如果事務中的某些操作被寫到了磁盤上，而另外一些沒有，就違反了原子性。
    2、一致性
	在事務執(zhí)行前數(shù)據(jù)庫應當處于一致狀態(tài)，而當事務結束的時候，數(shù)據(jù)庫又會回到一致性狀態(tài)。
	（銀行轉帳）
    3、隔離性
	每個事務都必須與其他事務產(chǎn)生的結果隔離開來。隔離性是兩個事務之間的屏障。
	驗證隔離性的方法即：在相同的初始數(shù)據(jù)集合上多次重復執(zhí)行一組的特定的事務集合，而每次得到相同的結果。
	例如：1用戶更新100行數(shù)據(jù)，在1用戶的事務正在執(zhí)行的時候，2用戶要刪除1用戶修改的數(shù)據(jù)，如果刪除真的發(fā)生了，說明1，2事務之間的隔離性還不夠。
	相對于單用戶來說，隔離性在多個用戶數(shù)據(jù)庫中更為重要。
    4、持久性
	指不管系統(tǒng)是否發(fā)生了故障，事務的處理結果都要永久保存。

事務的缺陷
    1、臟讀
	事務最明顯的缺陷是在事務提交之前，他對數(shù)據(jù)所做的修改就為其他事務所見。
	如果一個事務讀取了另外一個事務尚未提交的更新，就叫做臟讀。
Tran1-----------------------
begin transaction

use pubs
update jobs set job_desc = 'accp' where job_id = 1

Tran2-----------------------
begin transaction
set transaction isolation level read uncommitted (必須手動設計，否則會取默認值)
select * from jobs where job_id = 1

所以要結束第一個事務。

    2、不可重復讀
	類似于臟讀，只不過它發(fā)生在事務能看到其他事務已經(jīng)提交的數(shù)據(jù)更新的情況下。
	真正的隔離性指一個事務不會影響到另一個事務。
	在一個事務內進行同樣的讀操作，每次都應該得到相同的結果。
	如果兩次讀取的數(shù)據(jù)不一樣，說明出現(xiàn)了不可重復讀型事務缺陷。
Tran1-----------------------
begin transaction
use pubs
select * from jobs where job_id = 1

Tran2-----------------------
begin transaction
update jobs set job_desc = 'accp' where job_id = 1
commit transaction

重復Tran1
讀出的數(shù)據(jù)將發(fā)生改變

    3、幻影讀
	危害最小的事務完整性缺陷是幻影讀。
	和不可重復讀有些類似，幻影讀指的也是一個事務的更新結果影響到另一個事務的情況。
	與不可重復讀不同的是：用select獲取數(shù)據(jù)的時候，可能會獲取其他的數(shù)據(jù)。
Tran1-----------------------
begin transaction
update jobs set job_desc = 'accp' where job_id = 1
select * from jobs where job_desc = 'accp'

Tran2-----------------------
begin transaction
update jobs set job_desc = 'accp' where job_id = 1
commit transaction

重復事務1
得到兩個結果。

事務的隔離級別
    1、Read Uncommitted 未提交讀
	最不嚴格的隔離級別，它不能防止任何一種事務缺陷，根本就沒有在事務之間提供隔離。
	等同于nolock，這種設置適合報表或只讀的應用程序，這種鎖只能防止數(shù)據(jù)崩潰。

    2、Read Committed   提交讀
	默認的隔離級別，防止陷入過渡鎖爭用的泥潭。
    3、Repeatable Read  可重復讀
	可以防止臟讀和不可重復讀。
	
    4、Serializable     可串行讀(連續(xù)的)
	完全沒有事務的并發(fā)概念。用在銀行，帳務系統(tǒng)，股票市場。

鎖持續(xù)期
隔離級別		共享鎖持續(xù)期			排它鎖持續(xù)期
Read Uncommitted	無				持有鎖的時間僅能夠保證不會出現(xiàn)物理崩潰
Read Committed		在事務讀取數(shù)據(jù)的期間持有鎖	持有鎖直到事務提交
Repeatable Read		持有鎖直道事務提交		持有鎖直到事務提交
Serializable		持有鎖直道事務提交		持有鎖直到事務提交,同時還使用鍵鎖,防止插入


鎖的粒度
	行鎖：一行	（２５行可升級為一個頁鎖）
	頁鎖：一個頁面 8K
	擴展盤區(qū)鎖: 8個頁面
	表鎖：整個表
	數(shù)據(jù)庫鎖：
	鍵鎖：


鎖模式
	共享鎖：一個簡單的讀鎖。宣稱（“我正在讀取數(shù)據(jù)”）
	排它鎖：

死鎖：
系統(tǒng)會檢測完成工作量最少的事務作為犧牲品，但是不太準確。
既然系統(tǒng)幫我們檢索并處理死鎖，為什么我們還要手動處理死鎖呢？

1、兩個事務產(chǎn)生死鎖時，SQL Server會檢測到，但是三個事務出現(xiàn)死鎖：
   事務1等待事務2，事務2等待事務3，事務3等待事務1。
   雖然官方提供的幫助上面說可以檢測到，但實際上還是不理想。
2、我們可以手動的控制哪個事務放棄任務。

step1
use pubs
begin tran
update jobs set job_desc = 'vb' where job_id = 1


step 2
use pubs
begin tran
update jobs set job_desc = 'sql' where job_id = 2
update jobs set job_desc = 'asp' where job_id = 1

step3
use pubs
begin tran
update jobs set job_desc = 'c++' where job_id = 2