“Tiến sĩ, tôi lo lắng về hiệu suất Máy chủ SQL của mình.”
Đó không phải là điều bạn nghe thấy từ hầu hết các bệnh nhân. Nhưng sau đó, với tư cách là một chuyên gia được trả lương, tôi đã được đào tạo để đối phó với tất cả - ngay cả những khoảng thời gian khó khăn khi trở thành quản trị viên cơ sở dữ liệu.
"Thật sự? Chúng ta hãy khám phá điều đó, phải không? ”
“Chắc chắn rồi, Tiến sĩ. Ý tôi là, đôi khi nó cảm thấy rất áp đảo. Tôi đã nghĩ rằng mọi thứ sẽ tự hoạt động một mình một khi tôi đã cam kết với nó. Nhưng trước khi tôi biết điều đó, tôi đã bắt đầu gặp vấn đề về hiệu suất trong SQL Server 2012, 2014, rồi 2017. Tôi thậm chí không muốn nghĩ đến SQL Server 2019. ”
"Tôi thấy. Chà, mối quan hệ tốt đẹp với SQL Server không chỉ tự nó xảy ra. Bạn phải làm việc tại đó. Hãy cho tôi biết, bạn đã làm việc với các kỹ thuật điều chỉnh hiệu suất SQL Server của mình chưa? ”
“Ơ, không, Tiến sĩ. Tôi thực sự không biết bất kỳ kỹ thuật nào trong số đó. ”
"Đừng lo. Chúng tôi có thể làm việc trên chúng. Máy chủ SQL của bạn có thể đang bị bỏ quên. Bạn phải theo dõi nó để đảm bảo bạn luôn dẫn đầu trò chơi. Điều đó cần sự giám sát của SQL Server. ”
"Giám sát? Làm thế nào để bạn làm điều đó? ”
“Bạn phải hiển thị SQL Server mà bạn quan tâm. Bạn phải chú ý đến các số liệu nhất định. Chúng tôi cũng có thể làm việc đó. ”
“Được rồi, tiến sĩ. Dù bạn nói gì. Tôi sẵn sàng thử bất cứ điều gì vào thời điểm này. Mọi thứ không thể trở nên tồi tệ hơn bây giờ. ”
“Vậy thì tốt. Hãy bắt đầu nào."
Số liệu hiệu suất của SQL Server - Rất nhiều bộ phận chuyển động
Bệnh nhân đã đúng:theo dõi hiệu suất SQL Server của bạn có thể cảm thấy quá tải. Bạn không thể ngừng chú ý đến nó một khi nó bắt đầu hoạt động. Bạn phải tiếp tục thể hiện rằng bạn quan tâm.
SQL Server có rất nhiều phần chuyển động liên tục tạo ra các số liệu. Biết được những nội dung nào cần xem và sau đó thực sự dành thời gian trong ngày bận rộn của bạn để theo dõi chúng có thể rất nhiều công việc đối với một DBA.
Vì vậy, tôi đã đi qua một số lĩnh vực chính của số liệu hiệu suất SQL Server với bệnh nhân.
Chỉ mục
Một trong những nơi đầu tiên cần xem xét khi bạn gặp sự cố về hiệu suất với SQL Server là chỉ mục. Dữ liệu của bạn luôn phát triển, do đó, các chỉ mục của bạn cũng luôn phát triển. Nhưng chúng phải tuân theo các điều kiện như phân mảnh và tách trang có thể làm chậm phản hồi cho các truy vấn.
Điều gì đang xảy ra trong cơ sở dữ liệu ngày này qua ngày khác? Người dùng đang tạo, chỉnh sửa và xóa các bản ghi. Các chỉ mục theo kịp vị trí của tất cả các phần của bản ghi, nhưng theo thời gian, sự phân mảnh chỉ mục cản trở hiệu suất.
Sau đó, có hệ số lấp đầy chỉ mục, một tham số bạn có thể định cấu hình trong SQL Server để kiểm soát số lượng chia trang và tăng hiệu quả truy vấn. Nhưng sự cân bằng giữa việc chia tách trang nhiều hơn và ít hơn sẽ ảnh hưởng đến hiệu suất theo những cách khác.
Xem số liệu trong hệ số lấp đầy , I / O và phân mảnh là một cách tốt để giữ cho các ngón tay của bạn theo dõi tình trạng của chỉ mục SQL Server.
Bộ đệm đệm
Hãy làm cho điều này đơn giản:Đĩa, chậm; bộ đệm cache, nhanh chóng. Bộ đệm đệm là bản sao trong bộ nhớ của các trang cơ sở dữ liệu được sử dụng gần đây. Nếu SQL Server không tìm thấy những gì nó đang tìm kiếm ở đó, thì nó phải chuyển sang đĩa để tìm nó, điều này làm chậm hiệu suất.
SQL Server cho phép bạn chỉ định dung lượng bộ nhớ hệ thống để phân bổ cho bộ đệm cache, nhưng bạn phải đánh đổi bộ nhớ còn lại cho các tác vụ khác. Mục tiêu của bạn là phân bổ nhiều nhất có thể mà không cản trở hiệu suất của SQL Server trong các lĩnh vực khác.
Một điều quan trọng nữa là tuổi thọ của trang, lượng thời gian một trang thông tin từ cơ sở dữ liệu dành trong bộ đệm mà không bị truy cập lại. SQL Server liên tục loại bỏ các trang khỏi bộ đệm đệm để nhường chỗ cho những trang được sử dụng gần đây hơn. Nhưng càng ít trang hữu ích mà nó tìm thấy ở đó, thì nó càng phải đọc nhiều từ đĩa, điều này làm chậm hiệu suất.
Các chỉ số như tuổi thọ trang và tỷ lệ số lần truy cập thành công trong bộ đệm ẩn giúp bạn đưa ra quyết định về việc loại bỏ các trang ít thường xuyên hơn hoặc tăng kích thước bộ nhớ cache.
T-SQL
SQL Server sử dụng một ngôn ngữ truy vấn được gọi là T-SQL. Thay vì chạy các câu lệnh SQL một cách ngẫu nhiên, SQL Server cố gắng cải thiện hiệu suất bằng cách phân phối chúng, biên dịch chúng dưới dạng kế hoạch thực thi và lưu vào bộ nhớ đệm. Nó cũng cố gắng giảm thiểu tần suất biên dịch và sử dụng lại các kế hoạch thực thi thường xuyên nhất có thể. Nếu nó không thể sử dụng lại kế hoạch thực thi - chẳng hạn như do cơ sở dữ liệu đã thay đổi quá nhiều - thì nó sẽ biên dịch lại kế hoạch. Tốt nhất là giữ cho số lần biên dịch lại câu lệnh SQL càng thấp càng tốt, vì quá trình này có thể tiêu tốn một lượng lớn CPU và làm giảm hiệu suất.
Nhu cầu biên dịch và biên dịch lại là một chức năng của thực hành mã hóa tốt, giống như sử dụng các thủ tục được lưu trữ và tham số hóa các truy vấn. Các DBA giám sát các số liệu như tốc độ biên dịch SQL và biên dịch lại SQL có thể sửa đổi gợi ý truy vấn SQL Server để cải thiện hiệu suất.
Các quá trình khóa, chờ và bị chặn
Thật khó chịu khi phát hiện ra rằng ai đó khác đang sửa đổi nội dung nào đó cùng lúc với bạn. Vì vậy, cơ sở dữ liệu sẽ tự động khóa những thứ như hàng và bàn để ngăn nhiều người nấu ăn ra khỏi bếp. Tất nhiên, sự đánh đổi cho sự bảo vệ đó là tất cả những người dùng khác phải đợi cho đến khi tài nguyên được mở khóa. Và, thật khó để đảm bảo rằng việc khóa chỉ diễn ra ở mức cần thiết.
Với các số liệu cho thấy tần suất và mức độ ảnh hưởng của việc khóa rộng rãi đến các hoạt động khác, DBA có thể xác định nhu cầu cần thêm tài nguyên hệ thống vật lý để xử lý giao dịch nhanh hơn. Nó cũng có thể là SQL Server đang khóa ở mức thấp không cần thiết. Tần suất khóa chờ và rộng hơn là số lượng quy trình bị chặn có thể giúp xác định vị trí tắc nghẽn.
Loại bỏ tắc nghẽn với điều chỉnh hiệu suất SQL
“Chúa ơi, Tiến sĩ, bạn nói đúng về tất cả các bộ phận chuyển động. Bây giờ tôi thấy cách tôi không thể chỉ cài đặt SQL Server, đặt nó và quên nó đi. Tôi cần phải nuôi dưỡng mối quan hệ. Nhưng tất cả điều này vẫn cảm thấy quá tải. Làm thế nào tôi có thể giữ được rất nhiều thứ khác nhau thẳng thắn và luôn dẫn đầu trò chơi? ”
"Đó là phần tốt nhất. Có những công cụ có thể trợ giúp hiệu suất SQL Server của bạn. Bạn không cần phải đi một mình. ”
“Chà! Điều đó thật yên tâm. Tôi không biết về điều đó. ”
"Đúng rồi. Các công cụ giám sát hiệu suất máy chủ SQL của bạn và báo cáo tất cả các số liệu này để bạn có thể áp dụng các kỹ thuật điều chỉnh và loại bỏ tắc nghẽn. ”
“Thật không?”
"Đảm bảo. Và chúng ta có thể làm việc đúng như vậy - ôi, chúng ta đã hết thời gian cho tuần này. Vui lòng đặt lịch hẹn với lễ tân của tôi và chúng tôi sẽ đón vào tuần tới. ”
“Cậu nhóc, bốn giờ trôi qua thật nhanh, Tiến sĩ! Thời gian chắc chắn sẽ trôi qua khi bạn đang giải quyết các vấn đề về hiệu suất xung quanh phân mảnh, sử dụng tài nguyên và tỷ lệ truy cập bộ nhớ đệm , phải không? ”
“Có, và tôi chắc chắn rằng một khi bạn trao đổi cởi mở về những vấn đề đó với Máy chủ SQL của mình, tất cả các vấn đề về hiệu suất của bạn sẽ là lịch sử.”
Nghe thấy phiên họp của chúng tôi, bệnh nhân rời đi. Lần tới, chúng tôi sẽ làm việc để giám sát các nút cổ chai về hiệu suất của SQL Server. Tôi sẽ viết blog về nó, vì vậy hãy theo dõi.
Trong khi đó, hãy tin tôi. Tôi là một chuyên gia được trả tiền và tôi khuyến khích bạn thử những điều này trong mối quan hệ của riêng bạn với cơ sở dữ liệu của bạn. Làm cho Máy chủ SQL của bạn cảm thấy muốn. Hãy chú ý đến các chỉ số hiệu suất của nó.
Không bao giờ là quá muộn để thử.
