Trong bài đăng cuối cùng của tôi, "Nhiều kế hoạch cho một truy vấn 'giống hệt nhau'", tôi đã nói về trường hợp bạn nhận được hai kế hoạch khác nhau cho những gì bạn nghĩ là cùng một truy vấn, cũng như trường hợp bạn nhận được hai bản sao của giống nhau kế hoạch (và thậm chí có thể không biết). Như chúng tôi đã xem xét ở đó, "giống hệt" có thể là một từ khá mạnh.
Một tình huống khác khiến mọi người phải lặp lại là trường hợp họ khôi phục cơ sở dữ liệu đến một máy chủ khác - ví dụ:khôi phục cơ sở dữ liệu sản xuất đến một máy chủ thử nghiệm "giống hệt nhau" - và họ nhận được các đặc điểm hiệu suất khác nhau hoặc các kế hoạch khác nhau cho cùng một truy vấn (không trích dẫn lần này - tôi thực sự đang nói về các truy vấn thực sự giống hệt nhau).
Các máy chủ có thực sự "giống hệt nhau" không?
Những chàng trai này có thể trông giống nhau, nhưng chúng không hoàn toàn giống nhau. Nếu bạn gặp trường hợp này, điều đầu tiên bạn cần tự hỏi bản thân là liệu hai máy chủ này có thực sự giống hệt nhau hay không. Một số điều cần kiểm tra:
- Phiên bản - Nhiều thay đổi hành vi truy vấn và trình tối ưu hóa được đẩy qua các gói dịch vụ và các bản cập nhật tích lũy. Tôi thường thấy mọi người nói, "Chà, cả hai đều là năm 2008!" - trên thực tế, khi một cái là 2008 và cái kia là 2008 R2, hoặc chúng ở các gói dịch vụ khác nhau hoặc thậm chí là các mức cập nhật tích lũy. Vì rất nhiều người đọc @@ VERSION nhầm thông tin gói dịch vụ hệ điều hành với thông tin gói dịch vụ SQL Server, tôi sẽ nói như sau là tốt hơn:
SELECTSERVERPROPERTY(N'ProductVersion');Tôi không thể nhấn mạnh đủ tầm quan trọng của việc sử dụng cùng một phiên bản chính xác để thực hiện các bài kiểm tra thực tế. Nếu đang sử dụng SQL Server 2012 trở lên, bạn có thể kiểm tra các bài đăng xây dựng của chúng tôi (SQL Server 2012 | SQL Server 2014) để xác định gói dịch vụ hoặc bản cập nhật tích lũy cần thiết để đảm bảo các phiên bản khớp với nhau.
- Ấn bản - Trong khi hy vọng rằng bạn đang sử dụng cùng một phiên bản trên cả hai máy chủ (hoặc tương đương, vì ngoài việc cấp phép, Nhà phát triển và Đánh giá giống như Doanh nghiệp), sự không khớp ở đây có thể dẫn đến hành vi rất khác nhau. Ví dụ:các phiên bản khác nhau có khả năng tính toán khác nhau cho các tính năng khác nhau và sau đó có những thứ tinh vi hơn như khả năng sử dụng chế độ xem được lập chỉ mục mà không có gợi ý NOEXPAND hoặc thực hiện các thay đổi lược đồ hoặc duy trì chỉ mục trực tuyến. Bạn có thể so sánh các phiên bản bằng cách sử dụng:
SELECTSERVERPROPERTY(N'Edition'); - Số lượng CPU - SQL Server chắc chắn sử dụng số lượng bộ lập lịch có sẵn trong quá trình tạo kế hoạch thực thi và không thể phủ nhận rằng số lượng lõi có thể ảnh hưởng đến hiệu suất thời gian chạy thực tế (hãy bỏ qua tốc độ đồng hồ, vì đó hiếm khi là một yếu tố quan trọng trong truy vấn màn biểu diễn). Không chỉ xác thực số lõi được cài đặt vật lý trong máy chủ bên dưới mà còn kiểm tra nhật ký lỗi của SQL Server để biết số CPU mà SQL Server thực sự có thể sử dụng do cấp phép. Ngay cả khi quên số lõi thô, trên hệ thống NUMA, các hạn chế nhân tạo ở đây có thể dẫn đến các cấu hình hiệu suất rất khác nhau. Để biết thêm thông tin, hãy xem bài đăng gần đây của Brent Ozar, "Tại sao lại quan trọng việc cấp phép dựa trên cốt lõi để điều chỉnh hiệu suất." Phiên bản cũng có mối quan hệ ở đây, kể từ trong SQL Server 2012 và 2014, Standard Edition chỉ có thể sử dụng 16 lõi bất kể cài đặt hoặc phần cứng vật lý của bạn có thể khiến bạn tin tưởng như thế nào. Các cài đặt khác có thể ảnh hưởng đến hiệu suất và lựa chọn gói dựa trên CPU khác nhau bao gồm Trình quản lý tài nguyên, MAXDOP trên toàn máy chủ, mối quan hệ với CPU và ngưỡng chi phí cho tính năng song song.
- Dung lượng bộ nhớ - Giống như CPU, trình tối ưu hóa đưa ra các lựa chọn kế hoạch dựa trên dung lượng bộ nhớ có sẵn. Và cũng giống như CPU, tôi không chỉ nói về dung lượng RAM được cài đặt trong hệ thống, mà còn là dung lượng bộ nhớ được cấp cho SQL Server và dung lượng nó thực sự đang sử dụng. Kiểm tra cài đặt bộ nhớ máy chủ tối đa, cũng như các bộ đếm hiệu suất cho tổng bộ nhớ đích và bộ nhớ mục tiêu, và thậm chí cả DBCC MEMORYSTATUS. Những thứ khác bạn có thể muốn xem lại bao gồm cài đặt Thống đốc tài nguyên và Khóa các trang trong bộ nhớ. Ngoài ra còn có một cài đặt, nếu khác nhau giữa hai máy chủ, có thể có ảnh hưởng đáng kể đến mức độ sử dụng của bộ đệm ẩn kế hoạch cho cùng một nhóm truy vấn:tối ưu hóa cho khối lượng công việc đặc biệt. Kimberly Tripp có một bài đăng tuyệt vời về điều này:Lập kế hoạch bộ nhớ cache và tối ưu hóa cho khối lượng công việc adhoc. Cuối cùng, nếu máy chủ là ảo, hãy lưu ý rằng môi trường có thể đóng một vai trò nào đó ở đây - đặc biệt là khi cài đặt bộ nhớ VM không phù hợp với quá trình sản xuất hoặc động.
- Vùng đệm / bộ nhớ cache kế hoạch - Khi bạn khôi phục cơ sở dữ liệu trên máy chủ thử nghiệm, có rất nhiều thứ đơn giản là chưa sẵn sàng cho bạn ngay lập tức. Vùng đệm không chứa bất kỳ dữ liệu nào có thể đã tồn tại trong máy chủ nguồn - vì vậy sẽ có I / O bổ sung cần thiết để đưa dữ liệu vào bộ nhớ trong lần đầu tiên nó được truy vấn. Và nếu vùng đệm bị hạn chế khác với sản xuất do một số yếu tố ở trên, có thể không đạt được các mẫu hiệu suất giống nhau ngay cả sau khi chạy truy vấn nhiều lần - Paul White (@SQL_Kiwi) nói về điều này trong câu trả lời của anh ấy trên Quản trị viên Cơ sở dữ liệu. Ngoài ra, bộ nhớ cache của kế hoạch sẽ không chứa bất kỳ kế hoạch nào đã tồn tại trong quá trình sản xuất, vì vậy ít nhất - ngay cả khi cùng một kế hoạch cuối cùng được biên dịch (điều này có thể không xảy ra do các thông số khác với khi kế hoạch được biên dịch trên bản gốc máy chủ) - bạn sẽ có thêm chi phí biên dịch. Và những điều này cũng có thể thay đổi nếu bạn có bất kỳ cờ theo dõi nào ảnh hưởng đến kế hoạch.
- Hệ thống con của đĩa - Mặc dù tốc độ và kích thước của (các) đĩa đang được sử dụng sẽ không ảnh hưởng trực tiếp đến lựa chọn gói, nhưng chúng chắc chắn có thể ảnh hưởng đến hiệu suất được quan sát, điều này có thể khiến bạn tự hỏi tại sao cùng một truy vấn, với cùng một gói, chạy nhanh hơn nhiều trên một hệ thống khác. I / O thường là nút thắt cổ chai lớn nhất của SQL Server và khá hiếm khi một máy chủ thử nghiệm thực sự có cùng một hệ thống con cơ bản giống như hệ thống sản xuất tương đương của nó. Vì vậy, nếu bạn thấy sự khác biệt về hiệu suất giữa hai hệ thống và kế hoạch và các yếu tố phần cứng khác giống nhau, thì đây có thể là nơi tốt nhất tiếp theo để kiểm tra. Và đừng quên rằng kể từ SQL Server 2014, Resource Governor có thể đặt ra những ràng buộc đối với hiệu suất I / O của bạn.
- Cờ theo dõi - Kiểm tra danh sách các cờ theo dõi toàn cầu được thiết lập trên cả hai máy chủ; có một số có thể ảnh hưởng đến tối ưu hóa, hành vi lập kế hoạch và hiệu suất nhận thức, ngay cả khi tất cả các cài đặt trên đều giống hệt nhau. Dưới đây là 10 điều phổ biến và đáng chú ý (mặc dù đây hoàn toàn không phải là sự chứng thực để bật bất kỳ điều nào trong số này mà không cần kiểm tra hồi quy kỹ lưỡng):
Flag Giải thích 2301 Ép buộc trình tối ưu hóa dành nhiều thời gian hơn để cố gắng tìm ra phương án tối ưu. 2312 Buộc công cụ ước tính bản số mới của SQL Server 2014. 2335 Khiến bộ nhớ được cấp nhiều hơn. 2453 Buộc TÙY CHỌN (RECOMPILE) cho các truy vấn tham chiếu đến các biến bảng. 2861 Cho phép SQL Server lưu vào bộ nhớ cache các gói nhỏ / không phí. 4136 Một cách hiệu quả, thêm TỐI ƯU HÓA CHO BỎ LỠ vào tất cả các truy vấn (để cản trở việc dò tìm tham số). 4199 Một ô chứa toàn bộ các bản sửa lỗi của trình tối ưu hóa. 8744 Tắt tính năng tìm nạp trước đối với các vòng lặp lồng nhau. 9481 Tắt công cụ ước tính cardinality mới của SQL Server 2014. Danh sách các cờ theo dõi đó không có nghĩa là đầy đủ; có nhiều người khác, bao gồm cả những người không có giấy tờ mà tôi đã được yêu cầu không đề cập đến. Nếu bạn đang sử dụng những người khác không được liệt kê ở trên (và không thể giải thích tại sao), bạn có thể tìm thấy manh mối trong KB # 920093, KB # 2964518, Cờ theo dõi (MSDN) hoặc Cờ theo dõi trong SQL Server (TechNet). Bạn cũng sẽ tìm thấy một số thông tin chi tiết có giá trị trong các bài đăng khác nhau của Paul White, tại đây hoặc tại sql.kiwi.
- Đồng tiền - Có lẽ hệ thống thử nghiệm được sử dụng cho những thứ khác với bất cứ thứ gì bạn hiện đang thử nghiệm. Và trừ khi bạn đang thực hiện một số loại phát lại, nó cũng có thể có một hồ sơ khối lượng công việc rất khác. Những khác biệt về khối lượng công việc này rõ ràng có thể có tác động trực tiếp đến sự sẵn có của các nguồn lực để phục vụ các yêu cầu bạn đang thử nghiệm và đến lượt nó là hiệu suất được nhận thức của các yêu cầu đó. Đừng quên kiểm tra các dịch vụ khác có thể không tồn tại trong quá trình sản xuất hoặc tồn tại nhưng được sử dụng theo những cách khác nhau (chẳng hạn như Dịch vụ phân tích, Dịch vụ báo cáo, dịch vụ Windows và thậm chí cả các ứng dụng của riêng bạn). Ngược lại, có thể có các dịch vụ như thế này trong quá trình sản xuất ảnh hưởng đến hiệu suất ở đó hoặc chi phí bổ sung trên bản thân phiên bản không được bắt chước trong thử nghiệm:ngoài khối lượng công việc sản xuất thực tế, hãy nghĩ về những thứ như theo dõi, sự kiện mở rộng, giám sát tác động cao, theo dõi thay đổi, thu thập dữ liệu thay đổi, kiểm tra, môi giới dịch vụ, duy trì chỉ mục, công việc sao lưu, kiểm tra DBCC, sao chép, nhân rộng, nhóm khả dụng và danh sách tiếp tục lặp lại…
Các cơ sở dữ liệu có còn "giống hệt nhau" không?
Giả sử tất cả các biến phần cứng và khối lượng công việc khớp đủ tốt, vẫn có thể là một thách thức để đảm bảo rằng các cơ sở dữ liệu vẫn giữ nguyên. Nếu bạn đang thực hiện sao lưu / khôi phục vào hệ thống thử nghiệm, cơ sở dữ liệu mới bắt đầu giống hệt với nguồn (ngoại trừ vị trí thực và bảo mật). Nhưng ngay sau khi bạn bắt đầu chạm vào nó theo bất kỳ cách nào, nó rất nhanh chóng chệch khỏi bản sao sản xuất, vì bạn có thể thực hiện bất kỳ hoặc tất cả những điều sau:
- Thay đổi dữ liệu, giản đồ hoặc cả hai.
- Vô tình bắt đầu tự động cập nhật thống kê.
- Thêm, chống phân mảnh hoặc xây dựng lại chỉ mục hoặc tạo hoặc cập nhật thống kê theo cách thủ công.
- Thay đổi cài đặt cơ sở dữ liệu như mức tương thích, mức cô lập, tham số bắt buộc, chỉ mục XML chọn lọc hoặc bất kỳ tùy chọn nào có tên "Tự động" -
. (Rất tiếc, ngay cả vị trí tệp nhật ký và dữ liệu cũng như cài đặt tăng trưởng có thể ảnh hưởng đến hiệu suất truy vấn và điều này bao gồm cả tempdb.) - Làm trống bộ nhớ cache của gói, vùng đệm hoặc cả hai, trực tiếp hoặc do tác dụng phụ của các sự kiện khác (chẳng hạn như TÁI TẠO hoặc khởi động lại dịch vụ).
Ngoài ra, khi bạn bắt đầu tạo kế hoạch truy vấn mới, ngay cả trước khi bất kỳ thay đổi nào ở trên diễn ra, bạn phải nhớ rằng chúng có thể dựa trên dữ liệu khác với dữ liệu được sử dụng để tạo kế hoạch cho cùng một truy vấn trong quá trình sản xuất. Ví dụ:bản số khi kế hoạch được biên soạn trong quá trình sản xuất có thể sai lệch đáng kể giữa thời điểm đó và thời điểm sao lưu, có nghĩa là kế hoạch mới sẽ được tạo dựa trên các thống kê và thông tin biểu đồ khác nhau.
Những điều này còn phân biệt hơn nữa nếu thực tế đây không phải là lần khôi phục gần đây - mà là hai lược đồ và tập dữ liệu bạn đang giữ được đồng bộ hóa theo những cách khác (chẳng hạn như triển khai thủ công lược đồ và / hoặc thay đổi dữ liệu hoặc thậm chí sao chép). Do giới hạn về dung lượng ổ đĩa, bạn cũng có thể chỉ lấy một tập hợp con của dữ liệu sản xuất hoặc thậm chí là bản sao chỉ thống kê - những khác biệt về dữ liệu này gần như chắc chắn sẽ dẫn đến các đặc điểm hiệu suất khác nhau cho tất cả các truy vấn, trừ những truy vấn đơn giản nhất, ngay cả khi bạn may mắn và nhận được các kế hoạch tương tự cho một số.
Các truy vấn có thực sự "giống hệt nhau" không?
Ngay cả khi mọi thứ ở trên đã kiểm tra xong, vẫn có trường hợp bạn nhận được một gói khác do cài đặt phiên (bạn có thể đang sử dụng một bản sao khác của SSMS, với các cài đặt khác nhau hoặc một công cụ khách khác hoàn toàn) hoặc các lược đồ mặc định khác ( bạn có thể đang kết nối với máy chủ thử nghiệm dưới dạng đăng nhập xác thực Windows hoặc SQL khác, chẳng hạn). Tôi đã nói rất nhiều về những điều này trong bài viết trước của mình.
Kết luận
Mặc dù có những cách để giảm thiểu một số khác biệt (kiểm tra DBCC OPTIMIZER_WHATIF để đánh lừa máy chủ thử nghiệm của bạn tin vào những điều phi thường về phần cứng cơ bản), sự thật là sẽ rất khó khăn để làm cho hai máy chủ hoạt động đáng tin cậy và đồng nhất, và rằng có rất nhiều lý do tại sao bạn có thể nhận được các gói khác nhau hoặc hiệu suất khác nhau trên hai máy chủ tương tự (hoặc thậm chí giống hệt nhau).
Bạn có thủ thuật cụ thể nào không? Bạn có bất kỳ điểm đau đớn nào với những ý tưởng trên (hoặc những ý kiến khác mà tôi đã bỏ qua) không? Hãy chia sẻ ở phần bình luận bên dưới!
