How TVP Affect SQL Server Memory

之前有寫過一篇文章,其中的Root Cause就是TVP+SQL Profiler所造成的記憶體內存問題。原本以為tvp中的欄位如果沒有varchar(max)理應不會對SQL Server造成問題。但在測試結果下,如果Application沒有對字串限制長度,還是會造成上述的記憶體內存問題。同時也感謝Rock撥空測試幫助我驗證以下結論。

大概有幾個手段可以解決問題

  1. 限制Application 字串長度
  2. 升級CU Hotfix
//Sample Code for limit string length
DataSet dataSet = new DataSet();

DataTable customTable = new DataTable();
DataColumn dcName = new DataColumn("Name", typeof(string));
dcName.MaxLength= 500;
customTable.Columns.Add(dcName);

dataSet.Tables.Add(customTable);

至於原理跟測試,有興趣的可以看這篇文章

DataTable objects are most commonly used as TVP values. DataTables are easy to use and can serve as containers for data beyond just TVP usage. But unlike DbDataReader and IEnumerable objects, a big gotcha with a DataTable is that the default data type String with maximum length of -1 (2GB LOB). This is the .NET equivalent of the SQL Server nvarchar(MAX) data type and has many insidious and negative implications with a TVP.

SQL Replication Agent Profile 效能調教

高頻交易在使用交易式複寫時,如果使用的Agent Profile是Defaut值,會有效能問題。 這篇文章會介紹用UI以及用TSQL的作法調整Agent Profile,使得交易式複寫獲得效能改善。

每個Subscription都有自己的Distribution Agent,因此不同的Subscription都可以調整不同的Distribution Agent Profile。

但是Log Agent 則是一個DB只有一個。所以會有很多Publication共用同一個Log Agent。

繼續閱讀 “SQL Replication Agent Profile 效能調教"

[BUG] OBJECTSTORE_LBSS

這次遇到的問題,大概查了將近兩周才查出結果,OBJECTSTORE_LBSS這個Waittype在官網和網路上都找不到太多的資源。

遇到的問題:

突然發現有大量的Session 都在等Latch(ACCESS_METHODS_ACCESSOR_CACHE)的資源,並且造成效能低落。往Latch和 ACCESS_METHODS_ACCESSOR_CACHE查都沒有太多的方向。

繼續閱讀 “[BUG] OBJECTSTORE_LBSS"

升級SQL 2014,統計資訊(Statistics)的重要性?

統計資訊到底重不重要?

很多人都會說統計資訊的正確性很重要,因此要定時維護。事實上在SQL Server 2008的時候,我都仰賴自動更新而沒有設過任何排成維護。但是我在升級SQL Server 2014時,吃了一個大悶虧是關於統計資訊。原先CPU 好好的,升級後突然CPU高到接近100%。

自動更新的Option如下圖
「sql statistics auto update option」的圖片搜尋結果

先說說為什麼維護統計資訊很重要

  1. SQL Server產生執行計畫Execution Plan會依據統計資訊產生
  2. 所以不好的統計資訊會讓SQL Server誤用執行計畫
  3. 要特別注意統計資訊更新後會促發執行計畫重新編譯 (Recompile)

繼續閱讀 “升級SQL 2014,統計資訊(Statistics)的重要性?"

SQL 2014 Database Mail 導致 high CPU

某一次升版到SQL Server 2014後,CPU開始不尋常的升高,但是SQL Server不忙,看了一下Task Manger發現DatabaseMail占用很多資源。

2018-05-16_111943.png

於是上網一查,發現這個問題在SQL SERVER 2016也有,是個BUG…….
https://support.microsoft.com/en-nz/help/3197879/fix-sql-server-2016-database-mail-causes-high-cpu-usage-after-many-ema

2018-05-16_112456.png
繼續閱讀 “SQL 2014 Database Mail 導致 high CPU"

Begin Transaction 會不會影響 SQL Performance?

今天同事剛好問我這個問題,這個問題很有趣,也被很多人討論過。 首先,我們需要了解到 MS SQL的Default是Auto Commit,意思就是說縱使你沒有Commit Transaction,你的交易還是會被自動Commit。這點和Oracle不太一樣,算是MS SQL的特色之一(?)

我們先講結論,如果再大量Insert的時候加入Begin Transaction,效能會遠比沒有加好。

Why?–原理很簡單,假如沒有加入Begin Tran,因為MS SQL Default 是 Auto Commit,因此每Insert一筆資料Log都會有Begin Tran, Commit的紀錄,如果有十萬筆就會有十萬筆的Begin Tran, Commit。 如此一來效能就會很差….

所以如果在一開始加入Begin Tran,在Insert 十萬筆資料後再Commit,就會節省十萬筆的Begin Tran, Commit。所以效能就會好很多。

繼續閱讀 “Begin Transaction 會不會影響 SQL Performance?"