Replication這高可用技術，從SQL2005來幾乎沒有多大改變(參考自己以前寫的文章)，
交易複寫我個人也很常用，不過，我對雙向複寫就很感冒了，因為以前我有一陣子時間，
每天上班都要花不少時間處理雙向replication問題，
這篇來看看搭配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，
開發人員有必要了解其中差異，以避免交易更新資料發生非預期錯誤或資料不一致情況。
In recently, I tried to enhance performance of some operator api on our company system.
I found some operator api so fast on our system.
All queries using index seeks and no more than 3ms.
This post , I will show you how to improve its query performance.
partition table對資料維護的效率是一直吸引我的主因，
透過switch partition可說秒殺insert+delete操作，
不僅lock request少，且又可降低交易紀錄檔使用量，整體對我來說好處不少，
但以前經驗告訴我，partition table影響insert和update效能，
我想如果這部分能使用In-Memory table來接管的話那真是太美妙了，可惜In-Memory table並不支援partition，
但我們依然可以透過SQL2016來模擬partition，讓我們同時享有高效率的資料維護和高效能的交易處理。
Recovery model選項，可以控制交易的紀錄方式，以及可用的還原交易類型，
大家也一定都知道，Simple將使用最少交易紀錄，Full使用最多交易紀錄，
但對In-Memory table 是否有ㄧ樣的關聯呢 ?
