Sử dụng DBCC CLONEDATABASE và Cửa hàng truy vấn để kiểm tra

Mùa hè năm ngoái, sau khi SP2 cho SQL Server 2014 được phát hành, tôi đã viết về việc sử dụng DBCC CLONEDATABASE không chỉ đơn giản là điều tra sự cố hiệu suất truy vấn. Một nhận xét gần đây về bài đăng của một độc giả khiến tôi nghĩ rằng tôi nên mở rộng những gì tôi có trong đầu về cách sử dụng cơ sở dữ liệu nhân bản để thử nghiệm. Peter đã viết:

Vâng, Peter, của bạn đây. Tôi hy vọng điều này sẽ hữu ích!

Thiết lập

DBCC CLONEDATABASE đã được cung cấp trong SQL Server 2016 SP1, vì vậy đó là những gì chúng tôi sẽ sử dụng để thử nghiệm vì đây là bản phát hành hiện tại và vì tôi có thể sử dụng Cửa hàng truy vấn để thu thập dữ liệu của mình. Để làm cho cuộc sống dễ dàng hơn, tôi đang tạo cơ sở dữ liệu để thử nghiệm, thay vì khôi phục một mẫu từ Microsoft.

 SỬ DỤNG [master]; XÓA CƠ SỞ DỮ LIỆU NẾU TỒN TẠI [CustomerDB], [CustomerDB_CLONE]; ĐI / * Thay đổi vị trí tệp nếu thích hợp * / TẠO CƠ SỞ DỮ LIỆU [CustomerDB] BẬT CHÍNH (NAME =N'CustomerDB ', FILENAME =N' C:\ Databases \ CustomerDB.mdf ', SIZE =512MB, MAXSIZE =UNLIMITED, FILEGROWTH =65536KB) ĐĂNG NHẬP (NAME =N'CustomerDB_log', FILENAME =N'C:\ Databases \ CustomerDB_log.ldf ', SIZE =512MB, MAXSIZE =UNLIMITED, FILEGROWTH =65536KB); ĐI THÊM CƠ SỞ DỮ LIỆU [CustomerDB] ĐẶT PHỤC HỒI ĐƠN GIẢN; 

Bây giờ, hãy tạo một bảng và thêm một số dữ liệu:

 SỬ DỤNG [CustomerDB]; ĐI TẠO BẢNG [dbo]. [Khách hàng] ([CustomerID] [int] NOT NULL, [FirstName] [nvarchar] (64) NOT NULL, [LastName] [nvarchar] (64) NOT NULL, [EMail] [nvarchar] (320) NOT NULL, [Active] [bit] NOT NULL DEFAULT 1, [Đã tạo] [datetime] NOT NULL DEFAULT SYSDATETIME (), [Đã cập nhật] [datetime] NULL, CONSTRAINT [PK_Customers] KHÓA CHÍNH ĐÃ ĐIỀU CHỈNH ([CustomerID])); ĐI / * Điều này thêm 1.000.000 hàng vào bảng; Vui lòng thêm bớt * / INSERT dbo.Customers WITH (TABLOCKX) (CustomerID, FirstName, LastName, EMail, [Active]) SELECT rn =ROW_NUMBER () OVER (ORDER BY n), fn, ln, em, a FROM ( CHỌN ĐẦU (1000000) fn, ln, em, a =MAX (a), n =MAX (NEWID ()) TỪ (CHỌN fn, ln, em, a, r =ROW_NUMBER () HẾT (PHẦN CỦA em ĐẶT HÀNG CỦA em ) FROM (CHỌN ĐẦU (20000000) fn =LEFT (o.name, 64), ln =LEFT (c.name, 64), em =LEFT (o.name, LEN (c.name)% 5 + 1) + '.' + LEFT (c.name, LEN (o.name)% 5 + 2) + '@' + RIGHT (c.name, LEN (o.name + c.name)% 12 + 1) + LEFT ( RTRIM (CHECKSUM (NEWID ())), 3) + '.com', a =CASE WHEN c.name LIKE '% y%' THEN 0 ELSE 1 END FROM sys.all_objects AS o CROSS JOIN sys.all_columns NHƯ c LỆNH THEO NEWID ()) AS x) AS y WHERE r =1 GROUP BY fn, ln, em ORDER BY n) AS z ORDER BY rn; ĐI TẠO CHỈ SỐ KHÔNG CHỈ ĐỊNH [PhoneBook_Customers] TRÊN [dbo]. [Khách hàng] ([LastName] , [FirstName]) BAO GỒM ([EMail]); 

Bây giờ, chúng tôi sẽ bật Query Store:

 SỬ DỤNG [master]; ĐI ALTER DATABASE [CustomerDB] SET QUERY_STORE =ON; Thay đổi cơ sở dữ liệu [clientDB] Đặt query_store (operation_mode =read_write, cleanup_policy =(stale_query_threshold_days =30), data_flush_interval_seconds 

 Khi chúng tôi đã tạo và điền cơ sở dữ liệu cũng như đã định cấu hình Cửa hàng truy vấn, chúng tôi sẽ tạo một quy trình được lưu trữ để kiểm tra:
 
 SỬ DỤNG [CustomerDB]; XÓA THỦ TỤC NẾU TỒN TẠI [dbo]. [usp_GetCustomerInfo]; ĐI TẠO HOẶC THỦ TỤC THAY THẾ [dbo]. [usp_GetCustomerInfo] (@LastName [nvarchar] (64)) NHƯ CHỌN [CustomerID], [ FirstName], [LastName], [Email], CASE WHEN [Active] =1 THÌ 'Đang hoạt động' ELSE 'Không hoạt động' HẾT [Trạng thái] TỪ [dbo]. [Khách hàng] WHERE [LastName] =@LastName; 
 

 Lưu ý:Tôi đã sử dụng cú pháp CREATE OR ALTER PROCEDURE mới tuyệt vời có sẵn trong SP1. 
 

 Chúng tôi sẽ chạy thủ tục đã lưu trữ của mình một vài lần để lấy một số dữ liệu trong Cửa hàng truy vấn. Tôi đã thêm WITH RECOMPILE vì tôi biết rằng hai giá trị đầu vào này sẽ tạo ra các kế hoạch khác nhau và tôi muốn đảm bảo nắm bắt được cả hai. 
 
 EXEC [dbo]. [usp_GetCustomerInfo] 'name' WITH RECOMPILE; GOEXEC [dbo]. [usp_GetCustomerInfo] 'query_cost' WITH RECOMPILE; 
 

 Nếu chúng ta xem trong Query Store, chúng ta sẽ thấy một truy vấn từ thủ tục được lưu trữ của chúng ta và hai gói khác nhau (mỗi gói có plan_id riêng). Nếu đây là môi trường sản xuất, chúng tôi sẽ có nhiều dữ liệu hơn đáng kể về thống kê thời gian chạy (thời lượng, IO, thông tin CPU) và nhiều lần thực thi hơn. Mặc dù bản trình diễn của chúng tôi có ít dữ liệu hơn, nhưng lý thuyết vẫn giống nhau. 
 
 SELECT [qsq]. [query_id], [qsp]. [plan_id], [qsq]. [object_id], [rs]. [count_executions], DATEADD (MINUTE, - (DATEDIFF (MINUTE, GETDATE (), GETUTCDATE ())), [qsp]. [Last_execution_time]) AS [LocalLastExecutionTime], [qst]. [Query_sql_text], ConversionPlan =TRY_CONVERT (XML, [qsp]. [Query_plan]) TỪ [sys]. [Query_store_query] [ qsq] JOIN [sys]. [query_store_query_text] [qst] ON [qsq]. [query_text_id] =[qst]. [query_text_id] JOIN [sys]. [query_store_plan] [qsp] ON [qsq]. [query_id] =[ qsp]. [query_id] JOIN [sys]. [query_store_runtime_stats] [rs] ON [qsp]. [plan_id] =[rs]. [plan_id] WHERE [qsq]. [object_id] =OBJECT_ID (N'usp_GetCustomerInfo '); 
 

   Truy vấn Lưu trữ dữ liệu từ truy vấn thủ tục được lưu trữ Truy vấn Lưu trữ dữ liệu sau khi thực hiện thủ tục được lưu trữ (query_id =1) với hai gói khác nhau (plan_id =1, plan_id =2)  
   Kế hoạch truy vấn cho plan_id =1 (input value ='name')    Kế hoạch truy vấn cho plan_id =2 (input value ='query_cost')  

 Sau khi có thông tin cần thiết trong Cửa hàng truy vấn, chúng ta có thể sao chép cơ sở dữ liệu (dữ liệu Cửa hàng truy vấn sẽ được đưa vào bản sao theo mặc định):
 
 DBCC CLONEDATABASE (N'CustomerDB ', N'CustomerDB_CLONE'); 
 

 Như tôi đã đề cập trong bài đăng CLONEDATABASE trước của mình, cơ sở dữ liệu nhân bản được thiết kế để sử dụng cho hỗ trợ sản phẩm nhằm kiểm tra các vấn đề về hiệu suất truy vấn. Do đó, nó ở chế độ chỉ đọc sau khi được nhân bản. Chúng tôi sẽ vượt xa những gì DBCC CLONEDATABASE hiện được thiết kế để làm, vì vậy, một lần nữa, tôi chỉ muốn nhắc bạn về lưu ý này từ tài liệu của Microsoft:
 Cơ sở dữ liệu mới tạo được tạo từ DBCC CLONEDATABASE không được hỗ trợ để sử dụng làm cơ sở dữ liệu sản xuất và chủ yếu dành cho mục đích chẩn đoán và gỡ rối. 

 Để thực hiện bất kỳ thay đổi nào cho quá trình thử nghiệm, tôi cần đưa cơ sở dữ liệu ra khỏi chế độ chỉ đọc. Và tôi đồng ý với điều đó vì tôi không định sử dụng nó cho mục đích sản xuất. Nếu cơ sở dữ liệu nhân bản này nằm trong môi trường sản xuất, tôi khuyên bạn nên sao lưu và khôi phục cơ sở dữ liệu đó trên máy chủ thử nghiệm hoặc nhà phát triển và thực hiện thử nghiệm ở đó. Tôi không khuyên bạn nên thử nghiệm trong sản xuất, cũng không khuyên bạn nên thử nghiệm  chống lại  phiên bản sản xuất (ngay cả với một cơ sở dữ liệu khác). 
 
 / * Làm cho nó đọc ghi (sao lưu và khôi phục nó ở một nơi khác để bạn không hoạt động trong quá trình sản xuất) * / ALTER DATABASE [CustomerDB_CLONE] SET READ_WRITE WITH NO_WAIT; 
 

 Bây giờ tôi đang ở trạng thái đọc-ghi, tôi có thể thực hiện các thay đổi, thực hiện một số thử nghiệm và nắm bắt các chỉ số. Tôi sẽ bắt đầu với việc xác minh rằng tôi nhận được cùng một gói mà tôi đã làm trước đây (xin nhắc lại, bạn sẽ không thấy bất kỳ đầu ra nào ở đây vì không có dữ liệu nào trong cơ sở dữ liệu nhân bản):
 
 / * xác minh rằng chúng tôi nhận được cùng một gói * / USE [CustomerDB_CLONE]; GOEXEC [dbo]. [usp_GetCustomerInfo] 'name'; GOEXEC [dbo]. [usp_GetCustomerInfo] 'query_cost' WITH RECOMPILE; 
 

 Khi kiểm tra Cửa hàng truy vấn, bạn sẽ thấy giá trị plan_id giống như trước đây. Có nhiều hàng cho kết hợp query_id / plan_id do các khoảng thời gian khác nhau mà dữ liệu được thu thập (được xác định bởi cài đặt INTERVAL_LENGTH_MINUTES, mà chúng tôi đặt thành 5). 
 
 SELECT [qsq]. [query_id], [qsp]. [plan_id], [qsq]. [object_id], [rs]. [count_executions], DATEADD (MINUTE, - (DATEDIFF (MINUTE, GETDATE (), GETUTCDATE ())), [qsp]. [Last_execution_time]) AS [LocalLastExecutionTime], [rsi]. [Runtime_stats_interval_id], [rsi]. [Start_time], [rsi]. [End_time], [qst]. [Query_sql_text] , ConversionPlan =TRY_CONVERT (XML, [qsp]. [Query_plan]) TỪ [sys]. [Query_store_query] [qsq] JOIN [sys]. [Query_store_query_text] [qst] ON [qsq]. [Query_text_id] =[qst]. [query_text_id] JOIN [sys]. [query_store_plan] [qsp] ON [qsq]. [query_id] =[qsp]. [query_id] JOIN [sys]. [query_store_runtime_stats] [rs] ON [qsp]. [plan_id] =[rs]. [plan_id] JOIN [sys]. [query_store_runtime_stats_interval] [rsi] BẬT [rs]. [runtime_stats_interval_id] =[rsi]. [runtime_stats_interval_id] WHERE [qsq]. [object_id] =OBJECTp_IDGetC; ĐI 
 

   Truy vấn Lưu trữ dữ liệu sau khi thực hiện quy trình được lưu trữ dựa trên cơ sở dữ liệu nhân bản  
 
 Thay đổi mã thử nghiệm 
 

 Đối với thử nghiệm đầu tiên của chúng tôi, hãy xem cách chúng tôi có thể kiểm tra thay đổi đối với mã của mình - cụ thể là, chúng tôi sẽ sửa đổi quy trình đã lưu trữ của mình để xóa cột [Hoạt động] khỏi danh sách CHỌN. 
 
 / * Thay đổi quy trình sử dụng CREATE OR ALTER (xóa [Active] khỏi truy vấn) * / CREATE OR ALTER PROCEDURE [dbo]. [usp_GetCustomerInfo] (@LastName [nvarchar] (64)) AS SELECT [CustomerID], [FirstName ], [LastName], [Email] FROM [dbo]. [Khách hàng] WHERE [LastName] =@LastName; 
 

 Chạy lại quy trình đã lưu trữ:
 
 EXEC [dbo]. [usp_GetCustomerInfo] 'name' WITH RECOMPILE; GOEXEC [dbo]. [usp_GetCustomerInfo] 'query_cost' WITH RECOMPILE; 
 

 Nếu bạn tình cờ hiển thị kế hoạch thực thi thực tế, bạn sẽ nhận thấy rằng cả hai truy vấn hiện sử dụng cùng một kế hoạch, vì truy vấn được bao phủ bởi chỉ mục không phân biệt mà chúng tôi đã tạo ban đầu. 
 

   Kế hoạch thực thi sau khi thay đổi quy trình được lưu trữ để xóa [Đang hoạt động]  
 

 Chúng tôi có thể xác minh với Query Store, gói mới của chúng tôi có plan_id là 41:
 
 SELECT [qsq]. [query_id], [qsp]. [plan_id], [qsq]. [object_id], [rs]. [count_executions], DATEADD (MINUTE, - (DATEDIFF (MINUTE, GETDATE (), GETUTCDATE ())), [qsp]. [Last_execution_time]) AS [LocalLastExecutionTime], [rsi]. [Runtime_stats_interval_id], [rsi]. [Start_time], [rsi]. [End_time], [qst]. [Query_sql_text] , ConversionPlan =TRY_CONVERT (XML, [qsp]. [Query_plan]) TỪ [sys]. [Query_store_query] [qsq] JOIN [sys]. [Query_store_query_text] [qst] ON [qsq]. [Query_text_id] =[qst]. [query_text_id] JOIN [sys]. [query_store_plan] [qsp] ON [qsq]. [query_id] =[qsp]. [query_id] JOIN [sys]. [query_store_runtime_stats] [rs] ON [qsp]. [plan_id] =[rs]. [plan_id] JOIN [sys]. [query_store_runtime_stats_interval] [rsi] BẬT [rs]. [runtime_stats_interval_id] =[rsi]. [runtime_stats_interval_id] WHERE [qsq]. [object_id] =OBJECTp_IDGetC; 
 

   Truy vấn Lưu trữ dữ liệu sau khi thay đổi quy trình được lưu trữ  
 

 Bạn cũng sẽ nhận thấy ở đây có một query_id (40) mới. Cửa hàng truy vấn thực hiện đối sánh văn bản và chúng tôi đã thay đổi văn bản của truy vấn, do đó, một query_id mới được tạo ra. Cũng lưu ý rằng object_id được giữ nguyên, vì việc sử dụng đã sử dụng cú pháp CREATE OR ALTER. Hãy thực hiện một thay đổi khác, nhưng sử dụng DROP và sau đó TẠO HOẶC ALTER. 
 
 / * Thay đổi quy trình bằng cách sử dụng DROP và sau đó TẠO HOẶC ALTER (nối [Tên đầu] và [Tên cuối]) * / THỦ TỤC HỎI NẾU TỒN TẠI [dbo]. [usp_GetCustomerInfo]; TẠO HOẶC THAY THẾ THỦ TỤC [dbo]. [usp_GetCustomerInfo] (@LastName [nvarchar] (64)) NHƯ CHỌN [CustomerID], RTRIM ([FirstName]) + '' + RTRIM ([LastName]), [Email] FROM [dbo]. [Khách hàng] WHERE [LastName] =@ LastName; 
 

 Bây giờ, chúng tôi chạy lại quy trình:
 
 EXEC [dbo]. [usp_GetCustomerInfo] 'name'; GOEXEC [dbo]. [usp_GetCustomerInfo] 'query_cost' WITH RECOMPILE; 
 

 Bây giờ đầu ra từ Cửa hàng truy vấn trở nên thú vị hơn và lưu ý rằng vị từ Cửa hàng truy vấn của tôi đã thay đổi thành WHERE [qsq]. [Object_id] <> 0. 
 
 SELECT [qsq]. [query_id], [qsp]. [plan_id], [qsq]. [object_id], [rs]. [count_executions], DATEADD (MINUTE, - (DATEDIFF (MINUTE, GETDATE (), GETUTCDATE ())), [qsp]. [Last_execution_time]) AS [LocalLastExecutionTime], [rsi]. [Runtime_stats_interval_id], [rsi]. [Start_time], [rsi]. [End_time], [qst]. [Query_sql_text] , ConversionPlan =TRY_CONVERT (XML, [qsp]. [Query_plan]) TỪ [sys]. [Query_store_query] [qsq] JOIN [sys]. [Query_store_query_text] [qst] ON [qsq]. [Query_text_id] =[qst]. [query_text_id] JOIN [sys]. [query_store_plan] [qsp] ON [qsq]. [query_id] =[qsp]. [query_id] JOIN [sys]. [query_store_runtime_stats] [rs] ON [qsp]. [plan_id] =[rs]. [plan_id] JOIN [sys]. [query_store_runtime_stats_interval] [rsi] ON [rs]. [runtime_stats_interval_id] =[rsi]. [runtime_stats_interval_id] WHERE [qsq]. [object_id] <> 0;  

   Truy vấn Lưu trữ dữ liệu sau khi thay đổi quy trình đã lưu bằng DROP rồi TẠO HOẶC ALTER  
 

 Object_id đã thay đổi thành 661577395 và tôi có query_id mới (42) vì văn bản truy vấn đã thay đổi và plan_id mới (43). Mặc dù kế hoạch này vẫn là một tìm kiếm chỉ mục của chỉ mục không hợp nhất của tôi, nhưng nó vẫn là một kế hoạch khác trong Cửa hàng truy vấn. Hiểu rằng phương pháp được đề xuất để thay đổi đối tượng khi bạn đang sử dụng Cửa hàng truy vấn là sử dụng ALTER thay vì mẫu DROP và CREATE. Điều này đúng trong sản xuất và để thử nghiệm như vậy, vì bạn muốn giữ nguyên object_id để giúp việc tìm kiếm các thay đổi dễ dàng hơn. 
 
 Kiểm tra Thay đổi Chỉ mục 
 

 Đối với Phần II của thử nghiệm, thay vì thay đổi truy vấn, chúng tôi muốn xem liệu chúng tôi có thể cải thiện hiệu suất bằng cách thay đổi chỉ mục hay không. Vì vậy, chúng tôi sẽ thay đổi thủ tục đã lưu trữ trở lại truy vấn ban đầu, sau đó sửa đổi chỉ mục. 
 
 TẠO HOẶC THỦ TỤC THAY THẾ [dbo]. [usp_GetCustomerInfo] (@LastName [nvarchar] (64)) NHƯ CHỌN [CustomerID], [FirstName], [LastName], [Email], CASE WHEN [Active] =1 THEN 'Đang hoạt động' ELSE 'Không hoạt động' KẾT THÚC [Trạng thái] TỪ [dbo]. [Khách hàng] WHERE [LastName] =@LastName; ĐI / * Sửa đổi chỉ mục hiện có để thêm [Đang hoạt động] để bao gồm truy vấn * / TẠO CHỈ SỐ KHÔNG ĐƯỢC ĐIỀU CHỈNH [PhoneBook_Customers] BẬT [dbo]. [Khách hàng] ([LastName], [FirstName]) BAO GỒM ([EMail], [Active]) VỚI (DROP_EXISTING =ON); 
 

 Vì tôi đã bỏ quy trình được lưu trữ ban đầu, nên kế hoạch ban đầu không còn trong bộ nhớ cache. Nếu tôi đã thực hiện thay đổi chỉ mục này trước, như một phần của thử nghiệm, hãy nhớ rằng truy vấn sẽ không tự động sử dụng chỉ mục mới trừ khi tôi buộc biên dịch lại. Tôi có thể sử dụng sp_recompile trên đối tượng hoặc tôi có thể tiếp tục sử dụng tùy chọn WITH RECOMPILE trong quy trình để xem tôi nhận được cùng một kế hoạch với hai giá trị khác nhau (hãy nhớ rằng ban đầu tôi có hai kế hoạch khác nhau). Tôi không cần VỚI RECOMPILE vì kế hoạch không có trong bộ nhớ cache, nhưng tôi vẫn để nó hoạt động vì lợi ích của tính nhất quán. 
 
 EXEC [dbo]. [usp_GetCustomerInfo] 'name' WITH RECOMPILE; GOEXEC [dbo]. [usp_GetCustomerInfo] 'query_cost' WITH RECOMPILE; 
 

 Trong Query Store, tôi thấy một query_id mới khác (vì object_id khác với ban đầu!) Và một plan_id mới:
 

   Truy vấn Lưu trữ dữ liệu sau khi thêm chỉ mục mới  
 

 Nếu tôi kiểm tra kế hoạch, tôi có thể thấy rằng chỉ mục đã sửa đổi đang được sử dụng. 
 

   Kế hoạch truy vấn sau khi [Hoạt động] được thêm vào chỉ mục (plan_id =50)  
 

 Và bây giờ tôi có một kế hoạch khác, tôi có thể tiến thêm một bước nữa và cố gắng mô phỏng khối lượng công việc sản xuất để xác minh rằng với các tham số đầu vào khác nhau, quy trình được lưu trữ này tạo ra cùng một kế hoạch và sử dụng chỉ mục mới. Tuy nhiên, có một cảnh báo ở đây. Bạn có thể đã nhận thấy cảnh báo trên toán tử Tìm kiếm chỉ mục - điều này xảy ra vì không có thống kê trên cột [Tên cuối]. Khi chúng tôi tạo chỉ mục với [Hoạt động] làm cột được bao gồm, bảng đã được đọc để cập nhật thống kê. Không có dữ liệu trong bảng, do đó thiếu số liệu thống kê. Đây chắc chắn là điều cần lưu ý khi kiểm tra chỉ mục. Khi thiếu số liệu thống kê, trình tối ưu hóa sẽ sử dụng phương pháp phỏng đoán có thể thuyết phục hoặc không thuyết phục trình tối ưu hóa sử dụng kế hoạch mà bạn đang mong đợi. 
 
 Tóm tắt 
 

 Tôi là một người hâm mộ lớn của DBCC CLONEDATABASE. Tôi thậm chí còn là một người hâm mộ lớn hơn của Cửa hàng truy vấn. Khi bạn đặt hai trong số chúng lại với nhau, bạn có khả năng tuyệt vời để kiểm tra nhanh các thay đổi chỉ mục và mã. Với phương pháp này, bạn chủ yếu xem xét các kế hoạch thực thi để xác thực các cải tiến. Bởi vì không có dữ liệu trong cơ sở dữ liệu nhân bản, bạn không thể nắm bắt việc sử dụng tài nguyên và số liệu thống kê về thời gian chạy để chứng minh hoặc bác bỏ một lợi ích được nhận thấy trong một kế hoạch thực thi. Bạn vẫn cần khôi phục cơ sở dữ liệu và kiểm tra dựa trên toàn bộ dữ liệu - và Query Store vẫn có thể giúp ích rất nhiều trong việc thu thập dữ liệu định lượng. Tuy nhiên, đối với những trường hợp xác thực gói là đủ hoặc đối với những người trong số các bạn hiện không thực hiện bất kỳ thử nghiệm nào, DBCC CLONEDATABASE cung cấp nút dễ dàng mà bạn đang tìm kiếm. Cửa hàng truy vấn làm cho quá trình này trở nên dễ dàng hơn. 
 

  Một số điều cần lưu ý: 
 

 Tôi không khuyên bạn nên sử dụng WITH RECOMPILE khi gọi các thủ tục được lưu trữ (hoặc khai báo chúng theo cách đó - xem bài đăng của Paul White). Tôi đã sử dụng tùy chọn này cho bản trình diễn này vì tôi đã tạo một quy trình được lưu trữ nhạy cảm với tham số và tôi muốn đảm bảo các giá trị khác nhau tạo ra các gói khác nhau và không sử dụng một gói từ bộ nhớ cache. 
 

 Hoàn toàn có thể chạy các bài kiểm tra này trong SQL Server 2014 SP2 với DBCC CLONEDATABASE, nhưng rõ ràng là có một cách tiếp cận khác để nắm bắt các truy vấn và số liệu, cũng như xem xét hiệu suất. Nếu bạn muốn xem phương pháp thử nghiệm tương tự này mà không cần Cửa hàng truy vấn, hãy để lại nhận xét và cho tôi biết!