Có chỉ số xây dựng lại thời gian phụ thuộc vào mức độ phân mảnh?

Là thời gian cần thiết để xây dựng lại chỉ số phụ thuộc vào mức độ phân mảnh?

Việc xây dựng lại một chỉ số bị phân mảnh 80% có mất khoảng 2 phút không nếu việc xây dựng lại cùng một chỉ mục bị phân mảnh 40% mất 1 phút?

Tôi đang yêu cầu RUNTIME (ví dụ tính bằng giây) có thể được yêu cầu để thực hiện hành động được yêu cầu, không phải về hành động nào được yêu cầu trong tình huống cụ thể. Tôi nhận thức được các thực tiễn tốt nhất cơ bản khi chỉ số reorg hoặc xây dựng lại / cập nhật thống kê nên được thực hiện.

Câu hỏi này KHÔNG hỏi về REORG và sự khác biệt giữa REORG và REBUILD.

Bối cảnh: Do thiết lập các công việc bảo trì chỉ số khác nhau (mỗi đêm, công việc nặng hơn vào cuối tuần ...) Tôi tự hỏi liệu công việc bảo trì chỉ số OFFLINE "cường độ nhẹ" hàng ngày có nên được thực hiện tốt hơn trên các chỉ mục phân mảnh trung bình thấp để giữ nhỏ thời gian - hoặc thậm chí không quan trọng và việc xây dựng lại trên một chỉ số bị phân mảnh 80% có thể mất thời gian giống như hoạt động tương tự trên cùng một chỉ mục bị phân mảnh 40%.

Tôi làm theo lời đề nghị và cố gắng tìm hiểu xem chuyện gì đang xảy ra. Thiết lập thử nghiệm của tôi: Trên máy chủ thử nghiệm KHÔNG làm gì khác và không được sử dụng bởi bất kỳ ai hoặc bất cứ thứ gì khác, tôi đã tạo một bảng có Chỉ mục cụm trên cột khóa chính của trình xác định duy nhất với một số cột bổ sung và các loại dữ liệu khác nhau [2 số, 9 datetime và 2 varchar (1000)] và chỉ cần thêm hàng. Đối với bài kiểm tra trình bày tôi đã thêm khoảng 305.000 hàng.

Sau đó, tôi đã sử dụng lệnh cập nhật và cập nhật ngẫu nhiên một phạm vi lọc hàng trên một giá trị số nguyên và thay đổi một trong các Cột VarChar với giá trị chuỗi thay đổi để tạo phân mảnh. Sau đó tôi đã kiểm tra avg_fragmentation_in_percentmức hiện tại sys.dm_db_index_physical_stats. Bất cứ khi nào tôi tạo phân mảnh "mới" cho điểm chuẩn của mình, tôi đã thêm giá trị này bao gồm physical_page_countgiá trị vào bản ghi của mình, sơ đồ sau được tạo bằng.

Sau đó, tôi Ran: Alter index ... Rebuild with (online=on); và chộp lấy CPU timebằng cách sử dụng STATISTICS TIME ONvào bản ghi âm của tôi.

Kỳ vọng của tôi: Tôi dự kiến ​​sẽ thấy ít nhất là dấu hiệu của một loại đường cong tuyến tính cho thấy sự phụ thuộc giữa mức độ phân mảnh và thời gian cpu.

Đây không phải là trường hợp. Tôi không chắc chắn nếu thủ tục này thực sự thích hợp cho một kết quả tốt. Có lẽ số lượng hàng / trang quá thấp?

Tuy nhiên, kết quả chỉ ra rằng câu trả lời cho câu hỏi ban đầu của tôi chắc chắn sẽ là KHÔNG . Có vẻ như thời gian cpu SQL Server cần thiết để xây dựng lại chỉ mục không phụ thuộc vào mức độ phân mảnh cũng như phụ thuộc vào Số lượng trang của chỉ mục cơ bản.

Biểu đồ đầu tiên cho thấy thời gian cpu cần thiết để REBUILD chỉ số so với mức phân mảnh trước đó. Như bạn có thể thấy đường trung bình là hằng số tương đối và hoàn toàn không có mối quan hệ nào giữa sự phân mảnh và thời gian cpu cần thiết có thể quan sát được.

Để tôn trọng ảnh hưởng có thể có của số lượng trang thay đổi trong chỉ mục sau các cập nhật của tôi có thể cần ít nhiều thời gian để xây dựng lại, tôi đã tính FRAGMENTATION LEVEL * PAGES COUNT và sử dụng giá trị này trong biểu đồ thứ hai cho thấy mối quan hệ về thời gian cpu cần thiết so với phân mảnh và số trang.

Như bạn có thể thấy, điều này cũng không chỉ ra rằng thời gian cần thiết để xây dựng lại bị ảnh hưởng bởi sự phân mảnh ngay cả khi số lượng trang thay đổi.

Sau khi đưa ra những tuyên bố đó, tôi đoán quy trình của tôi phải sai vì thời gian cpu cần thiết để xây dựng lại một chỉ số rất lớn và bị phân mảnh cao, sau đó chỉ có thể bị ảnh hưởng bởi số lượng hàng - và tôi không thực sự tin vào lý thuyết này.

Vì vậy, bởi vì tôi thực sự và chắc chắn muốn tìm hiểu điều này ngay bây giờ, bất kỳ ý kiến ​​và đề xuất nào khác đều rất đáng hoan nghênh .

Là thời gian cần thiết để xây dựng lại chỉ số tùy thuộc vào mức độ phân mảnh?

Tôi tin rằng đây sẽ không phải là tham số chính mà máy chủ SQL sẽ quyết định và mất thời gian để xây dựng lại \ sắp xếp lại chỉ mục:

Có nhiều yếu tố khác liên quan dựa trên "DATA" mà qua đó nó quyết định sẽ mất bao nhiêu thời gian: Các thông số như

Yếu tố 1: Kích thước bảng

Yếu tố 2: Mối quan tâm có sẵn

Yếu tố 3: Phân vùng

Yếu tố 4: Cột chỉ mục và tính độc đáo

Nếu bạn muốn đọc thêm về các yếu tố này, bạn có thể tham khảo tại đây .

Việc xây dựng lại một chỉ mục bị phân mảnh 80% sẽ mất khoảng 2 phút nếu việc xây dựng lại cùng một chỉ mục bị phân mảnh 40% mất 1 phút

Một lần nữa câu trả lời có thể là nó phụ thuộc! Đối với các số bạn sẽ cần kiểm tra kịch bản và xem kết quả đầu ra như thế nào. Theo dõi các chi tiết như đối với FRAG cấp 80, xây dựng lại mất X giờ \ phút \ giây và đối với Frag cấp 40, việc xây dựng lại mất Y giờ \ phút \ giây. Tính toán và lưu giữ lịch sử trong hơn 15 ngày, (tùy thuộc vào hoạt động bảo trì được lên lịch) và bạn có thể đưa ra kết luận về thời gian thực sự mất bao nhiêu thời gian để so sánh cả hai.

Ngoài ra :

Bạn có thể thu thập dữ liệu \ tính toán trên tiến trình xây dựng lại chỉ mục:

hoặc sử dụng DMV sys.dm_exec_Vquests HOẶC

Nếu bạn có các kế hoạch Bảo trì của Ola để lập chỉ mục lại - Sắp xếp lại, có một tùy chọn để lưu lịch sử của các hành động được thực hiện trong quá trình bảo trì trong bảng CommandLog như được giải thích trong SQL Server Index và Thống kê bảo trì . Sau khi dữ liệu được lưu, bạn có thể truy vấn loại lệnh `ALTER_INDEX - REBUILD 'và sự khác biệt giống nhau giữa các cột START TIME và END TIME

Đối với mọi người quan tâm, tôi đã tạo một biểu đồ hiển thị chỉ số Thời gian REBUILD của khoảng 2500 chỉ mục được xây dựng lại trong vòng vài tuần liên quan đến sự phân mảnh của chỉ mục và kích thước của nó trong các trang.

Dữ liệu này dựa trên 10 Máy chủ SQL, hàng trăm bảng và trên các quy trình tối ưu hóa của Ola Hallengren . Ngưỡng chung để xây dựng lại được đặt thành phân mảnh 5%.

Tôi đã cắt bỏ một số bảng lớn nhất (10 Mi + Pages) trong thống kê này để làm cho nó dễ đọc hơn.

Biểu đồ hiển thị thời gian cần thiết (thời lượng) là kích thước của các bong bóng. Giá trị của bong bóng lớn nhất là khoảng 220 giây. Nó cho thấy rằng thời gian cần thiết để xây dựng lại một chỉ mục không thực sự liên quan đến sự phân mảnh. Thay vào đó, nó dường như nhiều hơn tùy thuộc vào số lượng trang mà chỉ mục có. Ngoài ra, nó chỉ ra rằng sự phân mảnh ở mức độ thấp sẽ tốn nhiều thời gian hơn so với sự phân mảnh cao hơn.

Biểu đồ thứ hai chỉ được phóng to vào khu vực <= 200 K Pages. Nó cho thấy điều tương tự, phải mất nhiều thời gian hơn cho các chỉ mục lớn hơn, không phải cho phân mảnh nhiều hơn.

REBUILDcủa chỉ số không phụ thuộc vào sự phân mảnh. Nó giảm chỉ số hoàn toàn và tạo ra nó từ đầu.

REORGANZE chỉ mục - là để giảm phân mảnh mà không xây dựng lại chỉ mục, do đó không giảm và tạo.

MS khuyên sử dụng sắp xếp lại để phân mảnh 30% hoặc ít hơn. Đối với phân mảnh cao hơn Rebuild được ưa thích.

Đây là bài viết của MSDN về điều này: Sắp xếp lại và xây dựng lại các chỉ mục

CẬP NHẬT

Về thời gian thực hiện để hoàn thành hoạt động, rõ ràng nó phụ thuộc vào sự phân mảnh chỉ số. Việc xây dựng lại chỉ số bị phân mảnh quá lớn sẽ mất ít thời gian hơn so với việc sắp xếp lại; xây dựng lại chỉ số phân mảnh một chút sẽ mất nhiều thời gian hơn. Tôi sẽ đề nghị lấy hướng dẫn MS làm điểm bắt đầu và chạy một số bài kiểm tra trên các bảng của bạn. Điểm hòa vốn về tỷ lệ phân mảnh% sẽ phụ thuộc vào bảng cụ thể, kích thước chỉ mục và loại dữ liệu.

Việc xây dựng lại một chỉ số bị phân mảnh 80% có mất khoảng 2 phút không nếu việc xây dựng lại cùng một chỉ mục bị phân mảnh 40% mất 1 phút?

Thuật toán cho REBUILD so với REORG là khác nhau. REORG sẽ KHÔNG phân bổ các phạm vi mới trái ngược với REBUILD. Một REORG sẽ hoạt động với các trang hiện được phân bổ (phân bổ một trang ngẫu nhiên 8Kb để nó có thể di chuyển các trang xung quanh) và di chuyển chúng xung quanh và sau đó phân bổ lại các trang nếu cần.

Từ các ghi chú SQLSkills của tôi (trước đây là IE0) ....

Dành cho REBUILD:

• Nó có thể sử dụng nhiều CPU - có thể tận dụng sự song song để thực hiện công việc nhanh chóng.
• Đối với các chỉ mục bị phân mảnh nhiều (ví dụ 80% như trong ví dụ của bạn), REBUILD sẽ nhanh hơn nhiều so với REORG. REBUILD sẽ chỉ tạo một bản sao khác của chỉ mục so với REORG sẽ bị sa lầy trong việc loại bỏ phân mảnh và do đó sẽ chậm hơn. Đây là lý do mà Paul Randal đưa ra khuyến nghị chung của mình rằng sẽ rất tốt khi thực hiện REBUILD với chỉ số bị phân mảnh nặng nề.
• REBUILD sẽ cho phép bạn thay đổi chế độ khôi phục thành BULK_LOGGED để đăng nhập tối thiểu ở đó bằng cách tạo ra ít bản ghi nhật ký hơn .

Đối với chỉ số REORG:

• Nó luôn luôn là luồng đơn. Không song song.
• Nó chậm hơn đối với các chỉ mục bị phân mảnh mạnh và nhanh hơn đối với các chỉ mục bị phân mảnh nhẹ. Chi phí tạo ra một chỉ mục so với thực hiện reorg của một chỉ mục bị phân mảnh nhẹ là nhiều hơn và do đó, REORG sẽ nhanh hơn cho chỉ mục bị phân mảnh nhẹ.
• Một REORG luôn luôn được đăng nhập đầy đủ hoạt động.

Đọc tiếp - Ghi chú - Phân mảnh, loại và giải pháp SQL Server Index

Tôi biết rằng đó là chủ đề cũ, nhưng tôi nghĩ sẽ có ích khi chia sẻ bài đăng của Paul Randal tại đây.

Tốc độ thuật toán

Xây dựng lại chỉ mục sẽ luôn xây dựng một chỉ mục mới, ngay cả khi không có sự phân mảnh. Khoảng thời gian xây dựng lại có liên quan đến kích thước của chỉ mục, chứ không phải số lượng phân mảnh trong đó.

https://www.sqlskills.com/bloss/paul/sqlskills-sql101-rebuild-vs-reorganize/

Có, bởi vì thông thường, việc xây dựng lại cần quét chỉ mục gốc theo thứ tự trong khi truyền các hàng (theo thứ tự) vào một phân vùng chỉ mục vật lý mới. Sự phân mảnh làm tổn thương các bản quét không được quét, do đó, việc xây dựng lại sẽ mất nhiều thời gian hơn.

Bao lâu nữa phụ thuộc vào sự phân mảnh và vào cách CPU ràng buộc toàn bộ quá trình. Các hàng tuần tự khá tốn CPU nên có thể không có vấn đề gì. Hoặc, bạn có thể nhận được tốc độ IO ngẫu nhiên thường là 1,5 MB / giây, chậm hơn 5-10 lần so với việc xây dựng lại nhanh (tùy thuộc vào lược đồ và dữ liệu). Tùy thuộc vào các giả định mà bạn đưa ra, bạn có thể có thể đạt được bất cứ điều gì trong khoảng thời gian chậm lại từ 1 đến 100 lần.

Việc xây dựng lại một chỉ số bị phân mảnh 80% có mất khoảng 2 phút không nếu việc xây dựng lại cùng một chỉ mục bị phân mảnh 40% mất 1 phút?

Đó không phải là một mối quan hệ tuyến tính. Số liệu phân mảnh là một proxy rất thô cho việc mất bao nhiêu thời gian để quét một phân vùng.