SQL Server 2016 新功能搶先看 - Live Query Statistics / JSON
承之前一篇 「SQL Server 2016 新功能搶先看 - Stretch Database / Managed Backup」一文，今天要直接帶大家搶先看其他新功能！
本文將帶大家了解以下新功能：
Live Query Statistics
說明
當應用程式發生效能問題，常常會發生這樣的情境，開發人員抱怨 DBA 資料庫沒管好，DBA 抱怨開發人員程式寫的差，因而造成彼此對立，無法真正有效釐清效能問題的瓶頸所在與有效將之排除。
DBA 可以用來調校效能的工具除了 Windows 效能監視器，最常用的不外乎是 SQL Server 內建的活動監視器、SQL Trace、SQL Server Profiler、Performance Dashboard 等工具，或是利用執行計畫來查看查詢的成本等。
為了讓 DBA 有更多的工具來有效掌握上述問題的癥結點，SQL Server 2016 推出多項全新的功能，讓您更能了解 SQL Server 如何處理應用程式所要求的查詢，其中一項是 Live Query Statistics（LQS），這項功能公開了以往比較不容易看到的執行時期資訊，像是查詢過程的統計資料，藉由這項功能有效的幫助您，找出長時間執行的查詢（long-running query）真正的問題點。
學習目標
透過本文的介紹，有助於您了解下列的內容：
一、 如何檢視正在執行的查詢狀態。
二、 在執行計畫中如何向下鑽研（drill down）。
三、 Live Query Statistics如何運作以及可能對效能的影響。
啟用 Live Query Statistics
啟用 Live Query Statistics 非常簡單，只需在 SQL Server Management Studio 工具列，分別按一下【Include Live Query Statistics】和【Include Actual Execution Plan】圖示，並執行您所要執行的查詢。
此時可以在 Live Query Statistics 頁籤看到查詢所使用到的運算子，正在統計查詢耗費的時間，另外在頁籤的左上角也可以看到整體的完成度。
使用 Live Query Statistics 會對效能有一定程度的衝擊，您會發現當查詢較為複雜時，所需等待的時間也會隨之增加，並且在過程中會耗用不少的運算資源（例如CPU），因此在使用的時機必須審慎，否則效能問題還沒查出來，反而造成資料庫更加忙碌就得不償失了。
提示
若只啟用【Include Live Query Statistics】，而未【Include Actual Execution Plan】在 Include Query Statistics 頁籤所看到的經過時間和完成率會都是 0。
在執行計畫中向下鑽研（drill down）
在 Live Query Statistics 執行過程當中，您可以點選任何一個執行計畫中的運算子，來查看運算子層級的統計資料，例如經過時間（Elapsed time）、運算子的處理進度（operator progress）、目前CPU/記憶體使用率等，藉此查看每個運算子的相關資訊，幫助您找出影響效能的瓶頸所在。
另外，當查詢仍在執行時可以切換至活動監視器，在新增加的 Active Expensive Queries 頁籤裡看到目前正在活動的費時查詢，直到該查詢執行完畢。
Live Query Statistics 運作原理
Live Query Statistics 的背後其實是透過動態管理檢視（DMV）來收集資訊，然後呈現在 Live Query Statistics 頁籤之中，進而讓 DBA 可以不需要自行查詢這些 DMV，直接以圖形化介面來快速找到長時間執行的查詢是在哪個環節耗費最多的時間及成本。
下列為 Live Query Statistics 所使用的 DMV，若您對執行時期相關的資訊有興趣，也可以直接使用這些 DMV 來收集相關的統計資料。
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_query_memory_grants
- sys.dm_exec_query_plan
- sys.dm_exec_query_profiles
限制
目前 Live Query Statistics 尚不支援下列情境：
- 資料行存放區索引（columnstore indexes）。
- 記憶體最佳化資料表（memory optimized tables）。
- 原生編譯預存程序（Natively compiled stored procedures）。
JSON
說明
SQL Server 2005 開始支援 XML 資料格式，提供原生的 XML 資料類型、XML 索引以及各種管理 XML 或輸出 XML 格式的函式。在 SQL Server 相隔 4 個版本之後，終於在 Microsoft Ignite 2015 大會上宣布，新一代的 SQL Server 2016 正式支援另一種應用系統中常用的資料格式 — JSON（JavaScript Object Notation）。
SQL Server 2016 並未打算為 JSON 新增專屬的資料類型，而是將重心放在提供一個方便使用的框架，幫助使用者在資料庫層級處理 JSON 資料，您不需要為此改變既有的結構描述，依然可以將 JSON 文件儲存在 NVARCHAR 資料類型的資料行裡，同時相容於現有的記憶體最佳化、資料行存放區索引、預存程序或使用者自訂函式、全文檢索搜尋等功能，應用程式更不需要因此而配合修改。
您不需要像過去在應用程式裡自行撰寫程式或透過 JSON.Net 這類的工具來剖析或處理 JSON 資料，利用 SQL Server 內建用來處理 JSON 資料格式的函式，就可以輕鬆將查詢結果輸出為 JSON 格式，或是搜尋 JSON 文件的內容，接下來請見下面的示範。
本文以 AdventureWorks2014 做為範例資料庫，若您想要跟著本文練習，可以先到 CodePlex 下載。
使用 JSON AUTO 輸出 JSON 格式
要將 SELECT 的查詢結果以 JSON 格式輸出，最簡單的做法就是在查詢敘述的最後面加上 FOR JSON AUTO。
下圖第一段 T-SQL 指令碼為一般的查詢敘述，預設是以表格的型態呈現查詢結果，的二段則搭配【FOR JSON AUTO】敘述，SQL Server 會直接將查詢結果轉換成 JSON格式。
將查詢結果改成文字型態會是查看 JSON 格式比較好的方式，資料行預設的顯示長度為 256 個字元，您可以點選【Tools>Options>Query Results>Results to Text】來修改可顯示的字元數，例如改成 8192 個字元。
修改完畢之後開啟新的視窗重新執行即可看到如下圖的結果，輸出文字不再被截斷，您可以在文字模式中自行調整顯示的結果。
若您想為 FOR JSON 加上 Root Key，可以用 ROOT 選項來自訂 Root Key 的名稱。
使用 JSON PATH 輸出 JSON 格式
當您想要自行定義輸出 JSON 格式的結構時，必須使用 JSON PATH 敘述，若 SELECT 的資料行名稱相同，必須以別名方式來重新命名輸出的資料行名稱才可正常值行查詢。
此外，預設內容為 NULL 的資料行輸出 JSON 時會被忽略，若您想要讓 NULL 的資料行也顯示出來，可以加上 INCLUDE_NULL_VALUES 選項（該選項一樣適用於 JSON AUTO 敘述）。
將 JSON 資料匯出到 Azure DocumentDB
假設您尚未建立任何 Azure DocumentDB 帳戶，請依照下列步驟建立，否則您可以直接跳到匯出 JSON 資料到 DocumentDB 的部分。
首先打開瀏覽器，輸入【https://portal.azure.com】連接預覽版 Azure 入口網站。登入之後於首頁依次點選【新增>Data + Storage>Azure DocumentDB】，於 DocumentDB帳戶刀鋒視窗輸入帳戶識別碼及設定所要使用的資源群組，並選擇要將 DocumentDB 帳戶建立在哪個 Azure 訂用帳戶之中，最後則是選定所要使用的資料中心所在區域，輸入完畢後按建立。
當您按下建立之後需等待幾分鐘，待 Azure DocumentDB 帳戶完成後點選開始面板上的圖示就可以看到如下圖的結果。
Azure DocumentDB 帳戶建立完成後接著點選視窗上方的【加入資料庫】，輸入資料庫識別碼之後按確定。
在 Azure DocumentDB 帳戶刀鋒視窗下方即可看到您所建立的資料庫，點選該資料庫並於資料庫刀鋒視窗上方按【加入集合】，輸入集合的識別碼之後按確定。
回到 SSMS 2016 於查詢輸入視窗輸入下列 T-SQL 指令碼：
select b.ProductModelID,b.Name as [ProductModel.Name],a.ProductID,a.Name ,ProductNumber,MakeFlag,FinishedGoodsFlag,Color,Size ,SafetyStockLevel,ReorderPoint,SellStartDate from Production.Product a join Production.ProductModel b on a.ProductModelID = b.ProductModelID where Color is null for json path,include_null_values,root('ProductModel') |
執行查詢前先在查詢編輯視窗按滑鼠右鍵，選擇【Result To>Result to File】。
由於前一步驟已經設定要將查詢結果存到檔案，因此按 F5 執行查詢時，會跳出儲存檔案的對話視窗要求指定檔案名稱及路徑。
儲存查詢結果後請用文字編輯器（如記事本）開啟前面所儲存的檔案，將不必要的內容（下圖紅色方框以外）刪除，只保留 JSON 文件本體。
回到預覽版 Azure 入口網站，點選您前面所建立的【Azure DocumentDB帳戶>資料庫>集合】，於集合的刀鋒視窗上方點選加入文件，選擇利用 SQL Server 2016 所產生的JSON 文件之後按上傳。
Azure DocumentDB 會檢查您所上傳的檔案是否符合 JSON 格式，若格式正確即可看到檔案上傳結果呈現成功。
若要查看儲存在 Azure DocumentDB 裡的 JSON 文件內容，可以在 DocumentDB 帳戶下方點選【文件總管>所要查看的文件識別碼】，即可看到如下圖的結果。
若您想要對 JSON 文件篩選或查詢，不需要學習其他程式語言，只要在查詢總管利用 SQL 語法就可以與 JSON 文件做互動。
更多 JSON 相關功能
目前 SQL Server 2016 CTP2 相關支援 JSON 的功能有限，更多內建用來處理 JSON 格式的函式，像是 ISJSON（判斷是否為 JSON 格式）、JSON_VALUE（剖析 JSON文件並擷取純量值）以及 OPENJSON（將 JSON 文件轉成資料表）等，必須等到 CTP3 才會陸續釋出。