Bạn dành bao nhiêu thời gian để khắc phục sự cố hiệu suất với tư cách là Quản trị viên hoặc Nhà phát triển cơ sở dữ liệu? Bạn đã bao giờ theo dõi nó chưa? Là tổng tỷ lệ phần trăm trung bình trong ngày của bạn, nó có thể không phải là nhiều thời gian, nhưng khi vấn đề nghiêm trọng, bạn có thể dành hàng giờ để theo dõi và làm việc thông qua phân tích nguyên nhân gốc rễ. Đôi khi vấn đề xảy ra mà bạn không biết nguồn gốc thực sự. Và thậm chí tệ hơn? Khi bạn phải chiến đấu với những vấn đề này vào nửa đêm hoặc vào cuối tuần. Bạn không chỉ loay hoay giải quyết vấn đề mà còn đang đánh mất thời gian rảnh rỗi của cá nhân mình. Làm thế nào để chúng tôi giảm bớt điều đó? Làm cách nào để chúng tôi loại bỏ thời gian và công sức ra khỏi phương trình, đồng thời sửa chữa hiệu suất?
Tính năng Điều chỉnh Tự động trong SQL Server 2017 Enterprise Edition và Cơ sở dữ liệu Azure SQL là bước đầu tiên giúp giảm thời gian các chuyên gia dữ liệu dành để khắc phục sự cố và giải quyết các vấn đề về hiệu suất. Tính năng này bao gồm Sửa kế hoạch Tự động và Quản lý Chỉ mục Tự động (chỉ có sẵn trong Cơ sở dữ liệu Azure SQL), được bật độc lập. Trong bài đăng này, tôi muốn tập trung vào tính năng Chỉnh sửa kế hoạch tự động. Với việc sửa chữa kế hoạch tự động, nếu SQL Server nhận thấy rằng một truy vấn đã thoái lui đáng kể, nó sẽ buộc kế hoạch tốt được biết đến cuối cùng cho truy vấn để ổn định hiệu suất. Về cơ bản, thay vì bạn, DBA hoặc Nhà phát triển, được gọi vào cuối tuần về hiệu suất hệ thống, SQL Server sẽ giải quyết vấn đề đó cho bạn. Nghe có vẻ quá dễ dàng phải không? Hãy cùng xem.
Dưới lớp phủ
Trước tiên, cần phải hiểu rằng Chỉnh sửa kế hoạch tự động sử dụng Cửa hàng truy vấn, vì vậy, nó phải được bật cho cơ sở dữ liệu. Thứ hai, Chỉnh sửa kế hoạch tự động chỉ đơn giản là buộc kế hoạch tự động. Mặc dù Query Store được tiếp thị dưới dạng máy ghi chuyến bay cho cơ sở dữ liệu của bạn để theo dõi văn bản truy vấn, kế hoạch, thống kê thời gian chạy và thống kê chờ, nó cũng cho phép bạn bắt buộc lập kế hoạch cho một truy vấn để cho phép đạt được hiệu suất nhất quán. Chỉnh sửa kế hoạch tự động là kế hoạch bắt buộc mà không có sự can thiệp của bạn.
Bật sửa kế hoạch tự động
Như đã đề cập, Query Store trước tiên phải được kích hoạt cho cơ sở dữ liệu người dùng. Điều này có thể được thực hiện trong SSMS, với T-SQL và với API REST cho Azure SQL DB. Lưu ý rằng Cửa hàng truy vấn được bật theo mặc định cho cơ sở dữ liệu trong Azure và đã có từ Q4 năm 2016.
Bật Cửa hàng truy vấn thông qua SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Bật Cửa hàng truy vấn bằng T-SQL
Đoạn mã trên là T-SQL mặc định từ SSMS nếu bạn viết nó ra. Trong Cơ sở dữ liệu Azure SQL, bạn không chạy câu lệnh USE. Nếu bạn muốn thay đổi bất kỳ tùy chọn mặc định nào, vui lòng đọc bài đăng Cài đặt cửa hàng truy vấn của tôi về những tùy chọn đó là gì và cân nhắc đối với các giá trị thay thế.
Sau khi Cửa hàng truy vấn được bật, bạn có thể sử dụng Cổng Azure, T-SQL hoặc API EST để bật Sửa kế hoạch tự động trong Cơ sở dữ liệu Azure SQL ((và C # và PowerShell đang hoạt động). Nó chỉ có thể được bật với T-SQL trong SQL Server 2017.
Bật sửa quy hoạch tự động trong Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Bật sửa kế hoạch tự động trong T-SQL
Lưu ý rằng Chỉnh sửa kế hoạch tự động sẽ được bật theo mặc định cho cơ sở dữ liệu mới trong Azure trong tương lai gần. Bắt đầu từ tháng 1 năm 2018, Tự động điều chỉnh sẽ được bật cho Cơ sở dữ liệu Azure SQL chưa được bật, với thông báo được gửi đến quản trị viên để tùy chọn này có thể bị tắt nếu muốn.
Cách thức hoạt động
Với tính năng Tự động sửa kế hoạch được bật, SQL Server giám sát hiệu suất truy vấn bằng cách sử dụng dữ liệu Cửa hàng truy vấn. Nó tìm kiếm một sự thay đổi đáng kể * về hiệu suất của CPU ** với thời lượng 48 giờ ***. Lưu ý các dấu hoa thị trong câu đó… chúng có mục đích:
- * Ngưỡng cho những gì tạo thành một thay đổi đáng kể không được ghi lại bởi vì Microsoft bảo lưu quyền thay đổi nó.
- ** Số liệu được sử dụng để xác định sự thay đổi về hiệu suất (CPU) không được ghi lại vì Microsoft bảo lưu quyền thay đổi nó. Có nghĩa là, Microsoft có thể xem xét các kích thước bổ sung để xem xét hiệu suất nếu điều đó sẽ tốt hơn / hoạt động tốt hơn so với chỉ riêng CPU.
- *** Khoảng thời gian mà dữ liệu hiệu suất truy vấn được so sánh không được ghi lại vì lý do tương tự, Microsoft có quyền thay đổi nó.
- Lưu ý:mặc dù các mục nói trên không được ghi lại, tôi đã xác nhận với các cá nhân thích hợp tại Microsoft rằng thông tin này có thể được chia sẻ khi vi phạm bất kỳ NDA nào. Điều cực kỳ quan trọng là phải hiểu rằng các giá trị không cố định và có thể thay đổi, với kỳ vọng rằng chúng sẽ thay đổi để cải thiện độ tin cậy của đối tượng địa lý.
Việc thiếu tài liệu và khả năng thay đổi ngưỡng có thể gây khó chịu cho một số cá nhân, nhưng đây là điều thực sự quan trọng cần nhớ:
Microsoft thu thập hàng chục terabyte dữ liệu đo từ xa hoạt động từ Cơ sở dữ liệu SQL Azure hàng ngày và dữ liệu đó rất quan trọng đối với các tính năng tự động đang được phát triển. Dữ liệu này bao gồm những thứ như query_id, query_plan_id và query_hash, và Microsoft KHÔNG thu thập query_text hoặc query_plan (họ không xem dữ liệu thực tế của bạn). Microsoft không chỉ đơn giản lưu trữ phép đo từ xa hoạt động đó hoặc sử dụng nó để khắc phục sự cố, họ đang khai thác dữ liệu đó và sử dụng nó để phát triển các thuật toán và mô hình để cho phép SQL Server đưa ra các quyết định độc lập, thông minh.
SQL Server có thể tận dụng rất nhiều dữ liệu trong Cửa hàng truy vấn chi tiết hiệu suất của các truy vấn và việc sửa kế hoạch tự động bắt đầu bằng việc so sánh hiệu suất hiện tại cho một truy vấn với hiệu suất trong quá khứ để xác định xem có sự hồi quy về hiệu suất hay không. Hiệu suất có đi xuống hay trở nên tồi tệ hơn không và nếu có thì nó có đáng kể không?
Nếu đã có một hồi quy trong hiệu suất truy vấn, thì SQL Server sẽ buộc kế hoạch tốt được biết đến cuối cùng cho truy vấn đó, tất nhiên là kế hoạch này được lấy từ Cửa hàng truy vấn. Nhưng nó không dừng lại ở đó. Sau đó, SQL Server tiếp tục theo dõi hiệu suất - vẫn sử dụng Query Store - để xác nhận rằng kế hoạch bắt buộc vẫn là một kế hoạch tốt cho truy vấn đó, có nghĩa là truy vấn với kế hoạch buộc hoạt động tốt hơn phiên bản hồi quy. Nếu truy vấn đó không hoạt động tốt hơn, thì nó sẽ không bắt buộc kế hoạch. Một kế hoạch cũng có thể không bị ép buộc nếu có biên dịch lại hoặc nếu việc cưỡng chế không thành công.
Chu kỳ này vẫn tiếp tục; nếu một truy vấn có một kế hoạch bắt buộc và sau đó kế hoạch đó không bị bắt buộc vì một trong những lý do đã nêu ở trên, thì kế hoạch đó có thể bị buộc lại sau đó hoặc có thể có một kế hoạch khác bị ép buộc cho truy vấn đó sau đó. Đây là một quá trình liên tục xảy ra miễn là bạn đã bật tùy chọn Sửa kế hoạch Tự động cho cơ sở dữ liệu. Bây giờ, điều thú vị là bạn có thể xem cùng một thông tin mà tính năng này nắm bắt và sử dụng nó để bắt buộc các kế hoạch theo cách thủ công. Nghĩa là, trong SQL Server 2017 Enterprise Edition và trong Cơ sở dữ liệu Azure SQL, dữ liệu này đang được thu thập trong sys.dm_db_tuning_recommendations DMV ngay cả khi tính năng Sửa kế hoạch tự động không được bật, vì vậy bạn có thể kiểm tra dữ liệu đó và làm theo các đề xuất của nó để buộc các kế hoạch cho các truy vấn cụ thể của riêng bạn. Lưu ý rằng nếu bạn buộc một kế hoạch bằng cách sử dụng các đề xuất từ sys.dm_db_tuning_recommendations, nó sẽ không bao giờ tự động được hủy bắt buộc. Hơn nữa, nếu bạn đã bật Chỉnh sửa kế hoạch tự động và bạn buộc một kế hoạch theo cách thủ công, nó sẽ không bao giờ được tự động bỏ bắt buộc. Chỉ những kế hoạch bị ép buộc với tính năng Chỉnh sửa kế hoạch tự động sẽ được tự động bỏ bắt buộc.
Tôi có thực sự để cho SQL Server kiểm soát không?
Nếu bạn đang nghi ngờ và tự hỏi liệu bạn có thể thực sự tin tưởng SQL Server để đưa ra quyết định bắt buộc hay không, thì đây là điều tôi khuyến khích bạn nên nhớ:
- Tính năng này được phát triển với lượng dữ liệu đáng kinh ngạc được thu thập từ gần hai triệu Cơ sở dữ liệu Azure SQL. Đây là một tính năng mới trong SQL Server 2017, nhưng nó đã được cung cấp trên toàn cầu vào năm 2016 trong Azure, vì vậy tính năng này đã thực sự khả dụng hơn một năm và nó đã được tinh chỉnh.
- Các kỹ sư đã thực hiện các thay đổi đối với thuật toán theo thời gian, vì họ đã thu thập được nhiều dữ liệu hơn. Nó có thể không tìm thấy mọi hồi quy xảy ra - bởi vì một hồi quy có thể không đủ nghiêm trọng, nhưng tôi dám cá rằng nhiều người trong số các bạn muốn có tính năng này ít thường xuyên hơn.
- Trên hết, nếu một kế hoạch bị ép buộc nhưng cuối cùng lại gây ra sự cố, thì khả năng của SQL Server khôi phục từ đó và bỏ buộc kế hoạch là cực kỳ đáng tin cậy và diễn ra rất nhanh chóng.
Tóm tắt
Bạn có thể không cảm thấy thoải mái với ý tưởng về việc SQL Server giải quyết các vấn đề về hiệu suất cho bạn. Nhưng đó có phải là sự khó chịu vì bạn nghĩ rằng nó sẽ đưa ra một quyết định kém? Hay bạn lo ngại về việc tự động hóa sẽ tiếp quản công việc của bạn? Câu hỏi khá trực tiếp, tôi biết. Nếu đó là trước đây, thì khuyến nghị của tôi là xem dữ liệu được thu thập trong sys.dm_db_tuning_recommendations (mà không bật Sửa kế hoạch tự động) và xem SQL Server muốn làm gì. Nó có phù hợp với những gì bạn sẽ làm không? Nó có tìm thấy các hồi quy mà bạn có thể bỏ lỡ không? Nếu bạn không muốn bật tính năng này vì bạn sợ rằng mình đột nhiên không có đủ để làm, tôi khuyến khích bạn đọc bài đăng gần đây của Conor Cunningham, Tốc độ đám mây giúp SQL Server DBA như thế nào. Microsoft không cố gắng khiến bạn thất nghiệp. Họ chỉ đơn giản là đang cố gắng giải quyết những kết quả thấp kém để bạn có thể tập trung vào những nhiệm vụ quan trọng hơn.
