Không phải bạn, mà là tôi (xử lý sự cố I / O)

Tác giả khách mời:Monica Rathbun (@SQLEspresso)

Đôi khi các vấn đề về hiệu suất phần cứng, chẳng hạn như độ trễ I / O của Đĩa, dẫn đến khối lượng công việc không được tối ưu hóa hơn là phần cứng hoạt động kém. Nhiều quản trị viên cơ sở dữ liệu, bao gồm cả tôi, muốn ngay lập tức đổ lỗi cho việc lưu trữ chậm chạp. Trước khi đi và chi hàng đống tiền cho phần cứng mới, bạn phải luôn kiểm tra khối lượng công việc của mình để tìm các I / O không cần thiết.

Những điều cần kiểm tra

Chỉ mục không được sử dụng

Tất cả chúng ta đều biết sức mạnh của một chỉ mục. Việc có các chỉ mục thích hợp có thể tạo ra sự khác biệt nhiều năm về tốc độ truy vấn. Tuy nhiên, có bao nhiêu người trong chúng ta liên tục duy trì các chỉ mục của mình ở trên và ngoài việc xây dựng lại và cài đặt lại chỉ mục? Điều quan trọng là phải thường xuyên chạy tập lệnh chỉ mục để đánh giá chỉ mục nào đang thực sự được sử dụng. Cá nhân tôi sử dụng các truy vấn chẩn đoán của Glenn Berry để thực hiện việc này.

Bạn sẽ ngạc nhiên khi thấy rằng một số chỉ mục của bạn hoàn toàn không được đọc. Các chỉ mục này gây căng thẳng về tài nguyên, đặc biệt là trên một bảng có tính giao dịch cao. Khi xem kết quả, hãy chú ý đến những chỉ số có số lần ghi cao kết hợp với số lần đọc thấp. Trong ví dụ này, bạn có thể thấy tôi đang lãng phí những lần viết. Chỉ mục không phân cụm đã được ghi tới 11 triệu lần, nhưng chỉ được đọc hai lần.

Tôi bắt đầu bằng cách vô hiệu hóa các chỉ mục thuộc danh mục này, sau đó loại bỏ chúng sau khi tôi xác nhận rằng không có vấn đề nào phát sinh. Thực hiện bài tập này thường xuyên có thể giảm đáng kể việc ghi I / O không cần thiết vào hệ thống của bạn, nhưng hãy nhớ rằng số liệu thống kê sử dụng trên các chỉ mục của bạn chỉ tốt như lần khởi động lại cuối cùng, vì vậy hãy đảm bảo rằng bạn đã thu thập dữ liệu cho một chu kỳ kinh doanh đầy đủ trước khi xóa một chỉ mục là "vô dụng".

Thiếu chỉ mục

Thiếu chỉ mục là một trong những điều dễ dàng nhất để sửa chữa; Xét cho cùng, khi bạn chạy một kế hoạch thực thi, nó sẽ cho bạn biết nếu không tìm thấy bất kỳ chỉ mục nào nhưng điều đó sẽ hữu ích. Nhưng chờ đã, tôi hy vọng bạn không chỉ thêm chỉ mục một cách tùy tiện dựa trên đề xuất này. Làm điều này có thể tạo ra các chỉ mục trùng lặp và các chỉ mục có thể có mức sử dụng tối thiểu, và do đó lãng phí I / O. Một lần nữa, quay lại các tập lệnh của Glenn, anh ấy cung cấp cho chúng ta một công cụ tuyệt vời để đánh giá mức độ hữu ích của chỉ mục bằng cách cung cấp các lượt tìm kiếm của người dùng, tác động của người dùng và số lượng hàng. Hãy chú ý đến những người có lượt đọc cao cùng với chi phí và tác động thấp. Đây là một nơi tuyệt vời để bắt đầu và sẽ giúp bạn giảm I / O đã đọc.

Chuyển đổi ngầm định

Chuyển đổi ngầm định thường xảy ra khi truy vấn so sánh hai hoặc nhiều cột với các loại dữ liệu khác nhau. Trong ví dụ dưới đây, hệ thống đang phải thực hiện thêm I / O để so sánh cột varchar (max) với cột nvarchar (4000), dẫn đến chuyển đổi ngầm và cuối cùng là quét thay vì tìm kiếm. Bằng cách sửa các bảng để có kiểu dữ liệu phù hợp hoặc chỉ cần chuyển đổi giá trị này trước khi đánh giá, bạn có thể giảm đáng kể I / O và cải thiện số lượng (các hàng ước tính mà trình tối ưu hóa sẽ mong đợi).

dbo.table1 t1 JOIN dbo.table2 t2 
  ON t1.ObjectName = t2.TableName

Jonathan Kehayias đi sâu vào chi tiết hơn trong bài đăng tuyệt vời này:"Chuyển đổi ngầm định bên cột đắt như thế nào?"

Chức năng

Một trong những điều có thể tránh được, dễ sửa chữa nhất mà tôi từng gặp để tiết kiệm chi phí I / O là xóa các chức năng khỏi mệnh đề where. Một ví dụ hoàn hảo là so sánh ngày tháng, như được hiển thị bên dưới.

CONVERT(Date,FromDate) >= CONVERT(Date, dbo.f_realdate(MyField))
AND 
(CONVERT(Date,ToDate) <= CONVERT(Date, dbo.f_realdate(MyField))

Cho dù là trong câu lệnh JOIN hay trong mệnh đề WHERE, điều này khiến mỗi cột được chuyển đổi trước khi nó được đánh giá. Chỉ cần chuyển đổi các cột này trước khi đánh giá thành bảng tạm thời, bạn có thể loại bỏ rất nhiều I / O không cần thiết.

Hoặc, thậm chí tốt hơn, hoàn toàn không thực hiện bất kỳ chuyển đổi nào (đối với trường hợp cụ thể này, Aaron Bertrand nói ở đây về việc tránh các hàm trong mệnh đề where và lưu ý rằng điều này vẫn có thể không tốt mặc dù chuyển đổi sang ngày là có thể phân loại được).

ETL

Hãy dành thời gian để kiểm tra xem dữ liệu của bạn đang được tải như thế nào. Bạn có đang cắt bớt và tải lại các bảng không? Thay vào đó, bạn có thể triển khai Replication, một Bản sao AG chỉ đọc hoặc ghi nhật ký vận chuyển không? Có phải tất cả các bảng đang được viết để thực sự được đọc không? Bạn đang tải dữ liệu như thế nào? Nó thông qua các thủ tục được lưu trữ hay SSIS? Việc kiểm tra những thứ như thế này có thể giảm I / O đáng kể.

Trong môi trường của tôi, tôi thấy rằng chúng tôi đang cắt bớt 48 bảng mỗi ngày với hơn 120 triệu hàng mỗi sáng. Trên hết, chúng tôi đang tải 9,6 triệu hàng mỗi giờ. Bạn có thể tưởng tượng có bao nhiêu I / O không cần thiết đã tạo ra. Trong trường hợp của tôi, thực hiện nhân rộng giao dịch là giải pháp tôi lựa chọn. Sau khi triển khai, chúng tôi đã có ít người dùng phàn nàn hơn về sự chậm chạp trong thời gian tải của chúng tôi, điều này ban đầu được cho là do bộ nhớ chậm.

Đặt hàng theo &nhóm theo

Hãy tự hỏi, dữ liệu đó có phải được trả lại theo thứ tự không? Chúng ta có thực sự cần phải nhóm trong thủ tục hay chúng ta có thể xử lý điều đó trong một báo cáo hoặc ứng dụng không? Các thao tác Order By và Group By có thể khiến các lần đọc tràn ra đĩa, gây ra thêm I / O cho đĩa. Nếu những hành động này được bảo đảm, hãy đảm bảo rằng bạn có các chỉ mục hỗ trợ và số liệu thống kê mới về các cột đang được sắp xếp hoặc nhóm. Điều này sẽ giúp trình tối ưu hóa trong quá trình tạo kế hoạch. Vì đôi khi chúng ta sử dụng Order By và Group By trong các bảng tạm thời. đảm bảo rằng bạn đã Bật tự động tạo thống kê cho TEMPDB cũng như cơ sở dữ liệu người dùng của bạn. Số liệu thống kê càng cập nhật, trình tối ưu hóa có thể nhận được bản số tốt hơn, dẫn đến các kế hoạch tốt hơn, ít tràn hơn và ít I / O hơn.

Giờ đây, Group By chắc chắn có chỗ đứng khi tổng hợp dữ liệu thay vì trả về hàng tấn hàng. Nhưng mấu chốt ở đây là giảm I / O, việc bổ sung tổng hợp sẽ bổ sung thêm I / O.

Tóm tắt

Đây chỉ là những việc cần làm, nhưng là một nơi tuyệt vời để bắt đầu giảm thiểu I / O. Trước khi đổ lỗi cho phần cứng về các vấn đề độ trễ, hãy xem bạn có thể làm gì để giảm thiểu áp lực ổ đĩa.

Giới thiệu về tác giả