Rock的SQL筆記本

當資料表中有nvarchar(max)這種大型欄位時，該資料表資料存放就會有兩個部分，一個是Row Data一個是LOB，當單一筆資料進來時該大型欄位資料內容過大無法在單一Page存放時，就會被SQL放到LOB區域去。

而LOB在建立資料表時不指定存放區則預設會放到Primary這一個File Group中。但如果我們事後想調整更換時該怎麼做呢?

今日一新系統上線，30分鐘後AP同仁傳了系統錯誤訊息給我，如下圖所示。從字面上來看就是系統的資料庫發生了DeadLock。我先開始錄SQL的Trace來抓DeadLock事件，但似乎只有系統開始運作的前30分鐘有發生，後來就沒再發生DeadLock事件。於是乎我就透過預設的Extented Event來檢視之前DeadLock事件是那些資源互咬，並檢視當下時間所執行的語法。但我怎麼看當時執行的語法都覺得不至於產生DeadLock啊。

某日有同仁表示自己撰寫的一張報表有時執行成功，但有時候又會失敗，然而他將該TSQL語法直接在SSMS執行時卻都不會失敗。

近日在檢視索引時對幾個重複索引做完整併後欲將多餘的索引刪除時發生3723錯誤，並且無法順利刪除索引。

今天收到一個需求得修改資料表值參數類型的欄位長度，但使用者定義資料表值參數類型無法使用Alter來異動，只能Drop後Create來異動。一旦該Table Type有被Stored Procedure參照的話，我們還無法Drop掉…….

日前將一個正式資料庫還原至測試機上，但因為測試機不需要實際資料，因此我就Truncate所有Table後再壓縮資料庫來減少測試機器的硬碟佔用空間。

很久以前就聽聞過SQL的計畫指南功能，但我一直沒有用過。可以從字面上初步了解就是針對某些查詢我們可以干涉最佳化引擎，讓SQL根據我們的需求來跑執行計畫。一些官方文件的舉例就是在不異動查詢語句的狀況下讓管理者可以針對語句下hint(如MAXDOP設定及OPTIMIZE FOR或Recompile等)。

今天開啟一部SQL主機，該主機是階段性使用，因此已經一年沒開機了。主機安裝兩個Instance，Instance A會鏡像一個DB到Instance B去。

最近由於SQL2008R2即將EOS，所以陸陸續續將資料庫升級到SQL2017的版本。而升級完成後有部分功能居然查詢時間太久導致Web TimeOut，經一番查詢後發現是新版SQL Server已在SQL2014採用新的基數估計(Cardinality Estimation簡稱CE)。而某些查詢會因為採用新版CE來估計統計反而誤用效能不好的執行計畫，官網分析有下列特性的查詢就可能發生查詢變慢的狀況。

相信很多情境下會在資料表的欄位設計上用到所謂的計算欄位(Computed Column)，顧名思義該欄位存放的值就是經過計算的一個結果。然而計算欄位的資料內容一般常會是取出資料後即時運算並顯示結果，但有時候也會因為某些需求希望能將運算結果真實寫入在page中，而這個需求只要在建立資料欄位時加入一個關鍵字Persisted即可。

今日收到一個錯誤告警，顯示因為頁面層級鎖定已經停用導致REORGANIZE索引發生失敗。

日前一位開發同仁反應他透過SSMS的UI要修改自己的密碼時都會顯示權限不足而無法修改，我試了一下發現的確如此

日前發現一個資料庫定序跟其他資料庫不同，為求一致性，我們可以單純用Alter Database去改資料庫的定序。但這樣的改法並不會修正該資料庫中其他資料表欄位原有的定序，只會影響未來新增的資料表。所以如果舊資料表欄位也要更改定序的話會需要Alter Table Alter Column 或 建立新資料表並重倒資料。

近期在撰寫TSQL做資料匯入時，會因為目的資料表有Identity型態的欄位，所以得在該資料表開啟IDENTITY_INSERT後再寫入資料。

今天Alter一張千萬筆的資料表中一個欄位為NOT NULL，結果爆了LDF 

NULL在資料庫中一直以來常會被拿出來警世，也看過一些書籍或聽一些演講都會提到盡量不要讓欄位是可以允許NULL的。

一直以來，很多文章或書籍都會提到資料庫在對資料做增刪修都會因為資料異動導致Page Splits的產生。一旦過度的分割就會提高所謂的邏輯片段，而要降低邏輯片段就得對資料表或索引做Rebuild或Reorganize，今天心血來潮突然想LAB看看SQL對Page Splits的運作原理為何，所以簡易做個實驗。

一直以來有個觀念就是Session ID小於50的就是SQL系統用的System Process。

今天檢視前一日的SQL 效能報表時發現下班前到晚上8點持續有BatchRequest偏高的趨勢

之前看了一些關於Partition Table可以透過Switch的方式轉移某個Partition到另一個非Partition Table上，來降低Insert Into大量資料會造成IO的問題。