SQL2014 開發者實做研討會筆記
今天感謝公司讓我去聽百敬老師的SQL Server 2014課程 ，課程中記了一些筆記，利用BLOG先記錄下來，內容 不全然跟SQL 2014有關(小弟不懂的都會記一下)
◎Page為一個Lock及Update的單位。
◎Index跟Data可以利用不同的FileGroup存放在不同的硬碟來降低硬碟IO。
◎Hekaton資料庫重啟需花費較長的時間，因為In Memory Table要都完全載入記憶體後（Index及資料）DB才可以使用。
◎Update的動作是先Delete後再Insert資料。
◎傳統資料表資料搬進Memory後做Table Scan其實不會比Hekton的Memory Table差，Hekton會快主要是原生編譯預存程序（Native Compiler Store Procedure）的關係。
◎Native Compiler Store Procedure在Compiler當下執行計畫就已經確定，如需更新執行計畫就要重新Compiler Store Procedure。
◎Linq會自動產生平行運算的語法，因為大多數的PG並不會寫Multi Thread。
◎大量同時存取熱點，會因為Lock或Latches，就算多CPU也無用武之地。
Lock：鎖資料邏輯，由Session決定鎖多久。
Latches：硬體鎖，防止兩個Thread搶同一塊資源，因此會短暫鎖住硬體資源，過程很快。
◎其他廠商也有開發In Memory的產品，但都是另外的產品，需另買。
◎多CPU會因為資源爭用，導致CPU數雖然成長到6倍，但效能卻僅增加2.52倍。但如果能避開熱點則效能可以增加5倍左右。
◎100萬筆資料為2的20次方，因此以B Tree的結構來看，最多20次搜尋即可找到資料。
◎Hekton中建立Hash Index時須設定Bucket Count，基本上Hash Index跟資料是1對1最好，所以有足夠的Bucket Count讓Table中的資料用是最好的。例如：你資料表有100萬筆資料，而Bucket Count卻只有設定10個。此時每一個Bucket底下就包含10萬筆資料（效能非常低落），Hash Index沒有經過排序，因此如果查詢是By Range的話效能會很慘（單筆很快），B Tree的索引才適合Range查詢。
◎Hekton的In Memory Table在記憶體滿了之後就會變成『唯讀』。
◎64位元系統在記憶體中的一筆Bucket是8個Bytes，因此一開始建立TABLE時如就設定100萬筆Bucket，那就會馬上吃掉8M Bytes的記憶體。
◎Hekton的In Memory Table 最多支援8個索引。
◎SQL2014正式版In Memory Table支援Identity欄位，也支援Default。
◎Sys.Tables新增兩個關於In Memory的欄位。
◎Native Compiler Store Procedure在Compiler時需指定Excute As XXX，Excute As有4種。Owner、Self 、Caller、user_name，這4種模式中Native Compiler Store Procedure不支援Excute As Caller。
◎TempTable可改用Hekton的In Memory Table來取代，這樣就不會有硬碟IO，可是得用Native Compiler Store Procedure來增、刪、修資料。
◎Hekton中的Table內資料列（ROW）都是以Version來控制，因此每一筆Row會有多Version。
◎Hash Index的Bucket Count如果一開始就給1000萬筆，但TABLE的實際資料量只有100萬筆，那此時的查詢用Hash Index掃瞄跟用Table掃瞄來比的話，Table 掃瞄會快非常多，因為Hash一定要掃完1000萬筆（就算內容是空的也要掃）。
◎SQL Server中已有In Memory的Table存在，此時故意將SQL的Max Memory縮小到無法存在該Table時，SQL Server馬上掛點。
◎SQL Server硬碟用完，Table也是變成唯讀。
◎記憶體不足的情況下，無法Attach Hekton的資料庫上去。
◎Bucket Count的筆數最好是資料筆數的2倍，因為每一筆記錄會有多Version。
◎SQL Cluster架構的Instance要注意如果有Hekton的DB在的話，在FailOver時會需要相當長的時間，因為要先將Hekton的DB Table都載入記憶體後該Instance才能Work。
◎Database在 Begin Tran後，預設是無限等待。而AP的Connection預設是30秒就TimeOut，因此當DB被卡住，等待30秒後AP就告知DB不要做了，放棄。
◎非同步延遲交易持久性，語法：ALTER DATABASE SET DELAYED_DURABILITY。啟用該功能後可以減少IO LDF的次數（拉長寫入LDF的時間），啟用此功能需注意萬一Instance重啟了，但還有很多資料沒進入LDF檔，此時會有資料不完整的問題存在。
◎Delta檔案：In Memory Table記錄已刪除的資料檔。
Data檔案：In Memory Table記錄寫入的資料檔。
◎Sys.fn_dblog(null,null) ß 可以檢視LDF檔案每一筆記錄寫入的情形。
◎In Memory Table是先將交易寫入LDF檔，當In Memory的Checkpoint發生時，再將LDF檔案中關於In Memory Table的資料寫入Data及Delta檔案中。
◎Hekton的In Memory Table交易要Commit才會寫入到LDF檔案，且在寫入LDF時會將多筆交易集合壓縮後才做寫入，因此會降低IO（最多一筆記錄為24KB）。因為只有Commit的資料會寫入LDF，因此In Memory Table只會有ReDo的動作，不會有UnDo。
◎SQL2014 Recovery動作步驟：
（1）分析
（2）載入Hekton
（3）ReDo（傳統SQL TABLE跟IN MEMORY TABLE）
（4）UnDo（傳統SQL TABLE）
◎當AlwaysOn架構有Hekton的Table時，注意該Table建立時需保留Schema and Data，這樣子主要複本才能根據LDF檔把In Memory Table的異動做變更。
◎Hekton不支援Trigger。
我是ROCK
rockchang@mails.fju.edu.tw
