[SQL Server] Automatic tuning

SQL Server 2017提供自動調整功能,可以自動偵測執行計畫變更所造成的效能問題,

並自動(或手動)套用最佳執行計畫來修正效能問題,而Azure SQL Database則還多了自動索引管理,

可幫我們識別那些是重複索引、那些索引又可以刪除,

這項功能,我個人覺得,未來也會出現在SQL Server 2017。

...繼續閱讀 »

[SQL Server]dependent transaction with In-Memory table

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

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

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

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

...繼續閱讀 »

[SQL Server]In-Memory table with columnstore Indexes

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

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

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

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

...繼續閱讀 »

[SQL Server]Let's Clear Checkpoint process of In-Memory

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

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

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

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

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

...繼續閱讀 »

[SQL Server]partition table and In-memory table

partition table對資料維護的效率是一直吸引我的主因,

透過switch partition可說秒殺insert+delete操作,

不僅lock request少,且又可降低交易紀錄檔使用量,整體對我來說好處不少,

但以前經驗告訴我,partition table影響insert和update效能,

我想如果這部分能使用In-Memory table來接管的話那真是太美妙了,可惜In-Memory table並不支援partition,

但我們依然可以透過SQL2016來模擬partition,讓我們同時享有高效率的資料維護和高效能的交易處理。

...繼續閱讀 »