RiCo技術農場

SQL2017針對In-Memory OLTP又改善不少，這篇來整理一下和SQL2016的比較。

Replication這高可用技術，從SQL2005來幾乎沒有多大改變(參考自己以前寫的文章)，

交易複寫我個人也很常用，不過，我對雙向複寫就很感冒了，因為以前我有一陣子時間，

每天上班都要花不少時間處理雙向replication問題，

這篇來看看搭配In-Memory OLTP有那些注意事項。

SQL2016 AlwaysOn的redo log效能和log傳送吞吐量有很大改善(是SQL2014的4~5倍)，

這篇來回顧一下AlwaysOn和In-Memory OLTP一些注意事項。

分享個人使用In-Memory OLTP注意事項和技巧

SQL2014開始，Memory table的交易處理，有最大相依交易8的數量限制，只會發生在驗證和commit階段，

一般來說In-Memory的交易過程是非常短暫的，但這並不表示你的交易就不會失敗，

實務上，我一定會簡化Memory資料表相依(複雜)性，

雖然SQL2016 In-Memory table支援很多功能(FK、trigger、LOB..)，但這不代表一定有效率。

之前將old sp移轉至native compiled sp時，

執行SP有2點需要注意，因為對執行效能有一些影響。

之前評估現有相關disk table，移轉至In-Memory table需多少記憶體，

我得老實說這還真的無法準確評估，因為未來資料成長量是一個主要因素，

其次則是讀寫頻率也讓人困擾。

Columnstore indexes主要可以改善大量scan/aggregate操作(可達10倍)，

因為採用xVelocity壓縮儲存方式(但無法對in-memory table壓縮)，

可大大節省disk space(壓縮大約10倍以上，取決於資料表中所有資料型別)，

所以和傳統row存放方式不同，通常會在fact table上建立來改善Data Mart/Data Warehouse彙熜效能。 

In-Memory table在Query performance方面表現如何呢?我用這篇來記錄我一些簡單測試。

之前我寫過一篇使用In-memory table variables來提高交易效能，這篇記錄當時一些額外測試。

Disk的checkpoint主要是將記憶體中的dirty pages和交易紀錄資訊寫入disk，

所以dirty pages的數量和checkpoint作業時間為線性關係，SQL Server會自動調整checkpoint作業頻率(預設60秒)，

這樣做是要降低其他應用程式所受到的效能影響，如果減少頻率，則會拉長完成時間，

增加頻率，則會影響效能(資料庫一般I/O活動會大幅增加)，

如果沒有特別理由，建議由SQL Server自行決定checkpoint頻率。

當你建立In-Memory table和index時，你無須考慮non-index key 的欄位，

因為In-Memory世界都是Cover query。

Native compiled SP效能真的很吸引人，改寫上說麻煩也不麻煩，

但有時候確實也很麻煩，但改寫後的效能結果目前還不曾讓我失望。

Hash index只能建立在In-memory table，並且提供point更快速的搜尋效能，

SQL2016開始可透過rebuild index方式修改bucket_count，無須drop and create。

IN-Memory OLTP的Range Index使用類似B-tree的BW-tree結構，

透過BW-tree有效改善Range和point搜尋效率，並節省更多記憶體開銷，

尤其更適合DATE, DATETIME and DATETIME2。

大量使用In-Memory table功能後，那當然就得監控並掌握每個memory object記憶體使用量，

避免發生任何記憶體意外。

當你要將old sp移轉為native sp，千萬不要忘記Native Compilation Advisor這好朋友。

SQL2016 In-Memory OLTP，現在可以讓我們很方便將資料存放至Memory table。

SQL2016新功能時態表我以前寫過兩篇，這功能去年我也正式使用在一個線上OLTP系統，

我得老實說這功能確實省下我不少時間，但往往方便就會忽略一些細節，

這篇紀錄一下和Memory table使用的情況。

SQL Server預設將交易隔離等級套用至disk和memory table，

而共同目標都是要達到交易完整性，

而交易初始模式(Transaction Initiation Modes)將直接影響我們要使用那種isolation level，

開發人員有必要了解其中差異，以避免交易更新資料發生非預期錯誤或資料不一致情況。