Trace Flag 4199 - Kích hoạt trên toàn cầu?

Điều này có thể thuộc danh mục ý kiến, nhưng tôi tò mò nếu mọi người đang sử dụng cờ theo dõi 4199 làm tham số khởi động cho SQL Server. Đối với những người đã sử dụng nó, trong trường hợp nào bạn đã trải qua hồi quy truy vấn?

Nó chắc chắn có vẻ như là một lợi ích hiệu suất tiềm năng trên toàn ban, tôi đang xem xét cho phép nó trên toàn cầu trong môi trường phi sản xuất của chúng tôi và để nó ngồi trong một vài tháng để giải quyết bất kỳ vấn đề nào.

Các bản sửa lỗi trong 4199 có được đưa vào trình tối ưu hóa theo mặc định vào năm 2014 (hoặc 2016) không? Mặc dù tôi hiểu trường hợp không đưa ra các thay đổi kế hoạch bất ngờ, nhưng có vẻ kỳ lạ khi giữ tất cả các bản sửa lỗi này ẩn giữa các phiên bản.

Chúng tôi đang sử dụng 2008, 2008R2 và chủ yếu là 2012.

Cá nhân, bất cứ khi nào tôi xây dựng một máy chủ mới cho một dự án mới, tôi luôn kích hoạt TF4199 trên toàn cầu. Điều tương tự cũng áp dụng khi tôi nâng cấp các phiên bản hiện có lên các phiên bản mới hơn.

TF cho phép sửa lỗi mới sẽ ảnh hưởng đến hành vi của ứng dụng, nhưng đối với các dự án mới, rủi ro hồi quy không phải là vấn đề. Đối với các phiên bản được nâng cấp từ các phiên bản trước, sự khác biệt giữa phiên bản cũ và phiên bản mới là mối quan tâm của riêng họ và dù sao cũng phải đối phó với hồi quy kế hoạch, vì vậy tôi thích chiến đấu với nó với TF4199 được kích hoạt.

NHƯ liên quan đến cơ sở dữ liệu hiện có, chỉ có một cách để biết: kiểm tra nó. Bạn có thể nắm bắt một khối lượng công việc trên thiết lập hiện có và phát lại nó sau khi bật cờ. Tiện ích RML có thể giúp bạn tự động hóa quy trình, như được mô tả trong câu trả lời này .

Rõ ràng, cờ ảnh hưởng đến toàn bộ thể hiện, vì vậy bạn sẽ phải kiểm tra tất cả các cơ sở dữ liệu đang ngồi ở đó.

Tìm kiếm của tôi về chủ đề đã đưa tôi đến đây, vì vậy tôi chỉ muốn chia sẻ kinh nghiệm gần đây của tôi về chủ đề này.

Tôi đã chạy SQL 2014, vì vậy tôi nhận ra rằng tôi sẽ an toàn khi phải quan tâm đến 4199 một chút ... nhưng điều đó không đúng ...

Cách chẩn đoán nếu bạn cần 4199

Nếu truy vấn của bạn có vẻ chạy kém , đặc biệt là khi bạn cảm thấy không nên, thì hãy thử thêm phần sau vào phần cuối của câu hỏi để xem nó có khắc phục được tất cả các vấn đề của bạn không, vì bạn có thể cần 4199 ("Kích hoạt tất cả các bản sửa lỗi Trình tối ưu hóa truy vấn." )

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

Trong tình huống của tôi, tôi đã có một mệnh đề top 10 thổi bùng lên một truy vấn chạy tốt mà không có, đó là điều khiến tôi nghĩ rằng điều gì đó đáng nghi đang xảy ra, và 4199 có thể giúp ích.

Khoảng 4199

Bất kỳ sửa lỗi / hiệu suất Trình tối ưu hóa truy vấn SQL Server nào được tạo sau khi phát hành phiên bản chính mới thực sự bị ẩn và chặn. Đây là trong trường hợp họ thực sự có thể gây hại cho một số chương trình tối ưu hóa hoàn hảo về mặt lý thuyết. Vì vậy, cài đặt các bản cập nhật như bạn có thể, các thay đổi tối ưu hóa truy vấn thực tế không được bật theo mặc định. Do đó, một khi một sửa chữa hoặc cải tiến duy nhất đã được thực hiện, 4199 trở thành một điều cần thiết nếu bạn muốn tận dụng nó. Khi nhiều bản sửa lỗi xuất hiện, cuối cùng bạn sẽ thấy mình bật cái này lên khi một trong số chúng ảnh hưởng đến bạn. Các bản sửa lỗi này thường được gắn với cờ theo dõi riêng của chúng, nhưng 4199 được sử dụng làm chủ "Bật mọi sửa chữa".

Nếu bạn biết bản sửa lỗi nào bạn cần, bạn có thể kích hoạt chúng theo bữa ăn thay vì sử dụng 4199. Nếu bạn muốn bật tất cả các bản sửa lỗi, hãy sử dụng 4199.

Ok, bạn muốn 4199 trên toàn cầu ...

Chỉ cần tạo Công việc Tác nhân SQL chạy mỗi sáng với dòng sau để bật cờ theo dõi trên toàn cầu. Điều này đảm bảo nếu bất cứ ai tắt chúng hoặc vv, rằng chúng được bật lại. Bước công việc này có sql khá đơn giản:

DBCC TRACEON (4199, -1);

Trong đó -1 chỉ định phần Toàn cầu trong DBCC TRACEON. Để biết thêm thông tin xem:

https://msdn.microsoft.com/en-us/l Library / ms187329.aspx? f = 255 & MSPPError =-2347217394

Kế hoạch truy vấn "biên dịch lại"

Trong nỗ lực gần đây nhất của tôi, tôi đã phải kích hoạt 4199 trên toàn cầu và sau đó cũng xóa các gói truy vấn được lưu trong bộ nhớ cache hiện có :

sp_recompile 'dbo.SomeTable'

https://msdn.microsoft.com/en-us/l Library / ms181647.aspx? f = 255 & MSPPError =-2347217394

Trong đó thủ tục lưu trữ biên dịch lại tìm thấy bất kỳ kế hoạch truy vấn nào liên quan đến đối tượng cơ sở dữ liệu (như bảng) và xóa các kế hoạch truy vấn đó, yêu cầu lần thử tiếp theo để chạy một truy vấn tương tự để biên dịch chúng.

Vì vậy, trong trường hợp của tôi, 4199 giữ cho các kế hoạch truy vấn xấu không được tạo, nhưng tôi cũng phải xóa những kế hoạch vẫn được lưu trong bộ nhớ cache thông qua sp_recompile. Chọn bất kỳ bảng nào từ truy vấn đã biết bị ảnh hưởng và bạn nên thử lại truy vấn đó, giả sử bạn đã bật 4199 trên toàn cầu và xóa kế hoạch truy vấn được lưu trong bộ nhớ cache vi phạm.

Kết luận về 4199

Khi bạn sử dụng các chỉ mục, tối ưu hóa kế hoạch truy vấn thông minh trở nên quan trọng để thực sự sử dụng các chỉ mục đó một cách thông minh và giả sử rằng theo thời gian, một số sửa chữa cho quy trình tối ưu hóa truy vấn sẽ được phát hành, nói chung bạn đang ở trong nước an toàn để chạy với 4199 trên toàn cầu, miễn là bạn nhận ra rằng một số sửa chữa mới có thể không thực sự chơi tốt với cơ sở dữ liệu được tối ưu hóa cao đã được tối ưu hóa như vậy trong môi trường trước đó trước khi sửa. Nhưng 4199 làm gì? Nó chỉ cho phép tất cả các bản sửa lỗi.

Tôi muốn chia sẻ kinh nghiệm của tôi với cờ theo dõi 4199.

Tôi vừa chẩn đoán xong vấn đề về hiệu năng trên hệ thống khách hàng chạy SQL Server 2012 SP3. Khách hàng đã chuyển một cơ sở dữ liệu báo cáo ra khỏi máy chủ OLTP sản xuất của họ sang một máy chủ mới. Mục tiêu của khách hàng là loại bỏ sự cạnh tranh về tài nguyên với các truy vấn OLTP. Thật không may, khách hàng cho biết máy chủ báo cáo mới rất chậm.

Một truy vấn mẫu chạy trên hệ thống OLTP hoàn thành sau 1,6 giây. Kế hoạch truy vấn đã thực hiện tìm kiếm chỉ mục trên bảng hàng ~ 200 triệu là một phần của chế độ xem.

Trên máy chủ mới, cùng một truy vấn hoàn thành trong 10 phút 44 giây. Nó thực hiện quét chỉ mục trên cùng bảng ~ 200 triệu hàng.

Dữ liệu máy chủ báo cáo là bản sao của dữ liệu OLTP, do đó, nó dường như không phải là một sự khác biệt trong dữ liệu.

Tôi đã bối rối cho đến khi tôi nhớ lại rằng phần mềm của chúng tôi (chạy hệ thống OLTP của họ) đã kích hoạt một số cờ theo dõi khi khởi động. Một trong số đó, 4199, tôi nhớ lại là một bản sửa lỗi tối ưu hóa truy vấn.

Tôi đã thử nghiệm bật cờ theo dõi 4199 trên máy chủ báo cáo mới của khách hàng và truy vấn báo cáo hoàn thành sau 0,6 giây. (Wow!) Tôi đã tắt cờ theo dõi và truy vấn đã trở lại hoàn thành sau 10 phút 44 giây. Đã bật cờ: trở lại 0,6 giây. Rõ ràng, việc bật cờ theo dõi cho phép trình tối ưu hóa sử dụng chỉ mục tìm kiếm vào chế độ xem trên bảng hàng 200 triệu.

Trong trường hợp này, tối ưu hóa truy vấn được kích hoạt bởi cờ theo dõi 4199 đã tạo ra một sự khác biệt rất lớn. Kinh nghiệm của bạn có thể thay đổi. Tuy nhiên, dựa trên kinh nghiệm này, nó chắc chắn có giá trị cho phép tôi.