Làm cách nào để đặt các trang chỉ mục SQL Server trên mỗi đoạn?


7

Tôi có SQL Server 2008 và một số cơ sở dữ liệu. Tôi đã phát hiện ra rằng một trong các chỉ mục của bảng của tôi cực kỳ phân mảnh (Làm thế nào tôi biết: http://msdn.microsoft.com/en-us/l Library / ms189858.aspx )

Con avg_fragmentation_in_percentsố khổng lồ 97% trở lên và số lượng mảnh vỡ là hàng ngàn. Rất thú vị, avg_fragment_size_in_pageschỉ hơn 1. Tôi có thể chống phân mảnh, điều này có ích, nhưng tôi muốn ngăn điều này xảy ra ngay từ đầu.

Tại sao các trang trên mỗi mảnh quá thấp? Tôi có FILEGROWTH = 128MBtoàn bộ DB, nhưng bảng đặc biệt này hoạt động mạnh nhất - vậy có cách nào để bảo SQL Server phân bổ tăng trưởng nhiều hơn cho bảng hoặc chỉ mục này để tỷ lệ trang trên mỗi phân đoạn cao hơn không?


Tôi cũng cần lưu ý rằng bảng phân mảnh này có rất nhiều phần chèn, nhưng rất hiếm khi xóa.

2
Bạn đang sử dụng gì cho một khóa cụm cho bảng? Đây có phải là một giá trị tăng đơn điệu (như INDENTITY) hay là ngẫu nhiên (ví dụ: GUID hoặc chuỗi ký tự). Nếu đó là cái sau bạn có thể bị chia tách trang do dữ liệu phải được chèn vào một trang hiện có.
Stuart Moore

2
Fillfactor là gì? Kích thước của bảng này là gì? Và kích thước hàng?
gbn

Stuart - Đó có thể là nó. Tôi có 3 chỉ số trên bảng này. Chỉ số IX về cơ bản là tuần tự và 5% phân mảnh, 6 trang cho mỗi phân đoạn. Chỉ số PK theo thứ tự thời gian và được phân mảnh 85% và Index SX là không gian và bị phân mảnh 97%. Cả PK và SX đều có 1 trang cho mỗi đoạn. gbn - Tôi dường như không thiết lập fillfactor; Mặc định là gì? Và giá trị tốt nhất cho việc này là gì?
Sugrue

2
Bạn nên khắc phục nguyên nhân gốc của sự phân mảnh - không chỉ áp dụng một bản vá cho nó .... tại sao bảng bị phân mảnh như vậy? Khóa cụm của bạn là gì (cột nào, kiểu dữ liệu nào)? Sửa cái đó trước đi!
marc_s

Câu trả lời:


15

Trước hết bạn nên đánh giá tác động của sự phân mảnh. Sự phân mảnh quá thường xuyên được coi là nguyên nhân xấu xa cuối cùng của tất cả các vấn đề máy chủ với bất kỳ sự xem xét nào về tác động thực tế của nó. Sự phân mảnh tác động đến một số khía cạnh:

  • Làm chậm quá trình quét do ảnh hưởng đến hiệu quả đọc trước và kích thước IO nhỏ (trang so với phạm vi)
  • IO kém hiệu quả do hàng thấp trên mỗi trang vì thường xuyên bị chia tách
  • Tỷ lệ bộ đệm bộ đệm bộ đệm thấp hơn (ví dụ: tuổi thọ trang thấp hơn) do giống như trên
  • Tác động chi phí cao hơn của INSERT do chia tách thường xuyên

Tất cả ở trên là xấu, nhưng đây là vấn đề thực sự: bạn có thể bị phân mảnh 97% với bất kỳ triệu chứng nào ở trên . Phân mảnh cao thực sự có thể gây ra tất cả những vấn đề này, nhưng chỉ khi khối lượng công việc cụ thể của bạn thực sự tương tác với phân mảnh theo cách gây ra các triệu chứng này xuất hiện.

Tôi sẽ khuyên bạn nên sử dụng phương pháp Chờ và Hàng đợi để xác định các tắc nghẽn hiệu suất thực tế của bạn và khẳng định chúng một cách thích hợp. Bạn rất có thể xác nhận rằng phân mảnh có tác động nghiêm trọng và sẽ yêu cầu lược đồ và có thể thay đổi ứng dụng để giải quyết vấn đề, nhưng bạn có thể phát hiện ra rằng vấn đề nằm ở một nơi khác và giải pháp hoàn toàn khác.

Và cuối cùng: bạn cũng có thể khám phá ra rằng $ 5k đã chi cho nhiều RAM hơn và một vài ổ SSD tốt giúp giảm bớt hoàn toàn các vấn đề bạn gặp phải. Trước khi bạn nhún vai kinh hoàng với một phương thuốc như vậy (cái gì, không có nguyên nhân gốc rễ nào được giải quyết? Anathema!) Hãy xem xét rủi ro và chi phí liên quan đến thay đổi ứng dụng ...


Cảm ơn Remus, tôi có các vấn đề làm chậm có thể đo lường được với chỉ số này (thời gian chờ là điều khiến tôi chú ý đến nó). Mua thêm ram không phải là một lựa chọn trong trường hợp này vì cơ sở dữ liệu được tạo và sử dụng bởi khách hàng trên máy của họ.
Sugrue

1
Thời gian chờ của máy khách, như thời gian chờ .Net SqlCommand mặc định là 30 giây?
Remus Rusanu

có, "System.Data.SqlClient.SqlException (0x80131904): Hết thời gian hết hạn. Thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi." Nó hiếm khi xảy ra, nhưng thường xuyên hơn khi phân mảnh cao. Tìm kiếm cũng nhiều, chậm hơn nhiều.
Sugrue

3
Không có cách nào phân mảnh gây ra điều đó. 30 giây sẽ đến từ những thứ như tăng trưởng tệp hoặc xung đột khóa (có thể do quét). Tôi sẽ tập trung vào việc hiểu những gì xảy ra khi những khoảng thời gian này xảy ra.
Remus Rusanu

4
Bất kỳ câu trả lời tôi sẽ mạo hiểm sẽ là đầu cơ. Hãy thử chờ đợi và xếp hàng. Thu thập quầy hoàn hảo. Đo lường.
Remus Rusanu
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.