Phân mảnh tệp vật lý cơ sở dữ liệu SQL

Tôi biết rằng thực sự có ba loại phân mảnh mà tôi cần quan tâm khi là một DBA:

1. Phân mảnh chỉ mục trong các tệp dữ liệu SQL, bao gồm phân mảnh chỉ mục (bảng) phân cụm. Xác định điều này bằng cách sử dụng DBCC SHOWCONTIG (trong SQL 2000) hoặc sys.dm_ db_ index_ vật lý thống kê (trong năm 2005+).

2. Phân mảnh VLF bên trong các tệp Nhật ký SQL. Chạy DBCC LOGINFO để xem có bao nhiêu VLF trong mỗi tệp nhật ký SQL của bạn.

3. Phân mảnh tệp vật lý của các tệp cơ sở dữ liệu trên ổ cứng. Chẩn đoán điều này bằng cách sử dụng tiện ích "Disk Defragmenter" trong Windows. (lấy cảm hứng từ bài viết blog tuyệt vời này )

Rất nhiều sự chú ý được trả cho việc phân mảnh chỉ mục (xem câu trả lời Serverfault tuyệt vời này của Paul Randall), vì vậy đó không phải là trọng tâm của câu hỏi của tôi.

Tôi biết tôi có thể ngăn phân mảnh vật lý (và phân mảnh VLF) khi cơ sở dữ liệu ban đầu được tạo bằng cách lập kế hoạch tệp dữ liệu dự kiến ​​hợp lý và kích thước nhật ký, vì phân mảnh này xảy ra thường xuyên nhất do tăng và thu nhỏ thường xuyên, nhưng tôi có một số câu hỏi về cách khắc phục phân mảnh vật lý một khi nó được xác định:

• Trước hết, sự phân mảnh vật lý thậm chí có liên quan trên Enterprise SAN không? Tôi có thể / nên sử dụng Windows Defragmenter trên ổ đĩa SAN hay nhóm SAN nên sử dụng các tiện ích chống phân mảnh nội bộ? Phân tích phân mảnh tôi nhận được từ công cụ Windows có chính xác không khi chạy trên ổ SAN?

• Làm thế nào lớn của một thỏa thuận là phân mảnh vật lý trên hiệu suất SQL? (Giả sử một mảng ổ đĩa nội bộ, đang chờ kết quả của câu hỏi trước.) Đây có phải là một thỏa thuận LỚN hơn so với phân mảnh chỉ mục nội bộ không? Hoặc nó thực sự là cùng một loại vấn đề (ổ đĩa phải thực hiện đọc ngẫu nhiên thay vì đọc tuần tự)

• Việc chống phân mảnh (hoặc xây dựng lại) chỉ mục có lãng phí thời gian nếu ổ đĩa bị phân mảnh vật lý không? Tôi có cần sửa cái này trước khi tôi giải quyết cái kia không?

• Cách tốt nhất để sửa phân mảnh tệp vật lý trên hộp SQL sản xuất là gì? Tôi biết tôi có thể tắt các dịch vụ SQL và chạy Windows Defrag, nhưng tôi cũng đã nghe về một kỹ thuật mà bạn thực hiện sao lưu toàn bộ, bỏ cơ sở dữ liệu, sau đó khôi phục từ bản sao lưu vào ổ đĩa trống. Đây có phải là kỹ thuật sau? Có phải khôi phục từ một bản sao lưu như thế này cũng xây dựng các chỉ mục từ đầu, loại bỏ phân mảnh chỉ mục nội bộ? Hoặc nó chỉ đơn giản là trả lại thứ tự trang giống như khi sao lưu được thực hiện? (Chúng tôi đang sử dụng bản sao lưu Quest Lightspeed có nén, nếu điều đó quan trọng.)

CẬP NHẬT : Các câu trả lời tốt cho đến nay về việc có nên chống phân mảnh ổ đĩa SAN (NO) hay không và liệu phân mảnh chỉ mục có còn đáng giá trên các ổ đĩa bị phân mảnh vật lý (CÓ) hay không.

Bất cứ ai khác quan tâm để cân nhắc về các phương pháp tốt nhất để thực sự chống phân mảnh? Hoặc một ước tính về khoảng thời gian bạn mong đợi sẽ mất để phân mảnh ổ đĩa bị phân mảnh lớn, giả sử là 500 GB? Rõ ràng là có liên quan, vì đó là thời gian máy chủ SQL của tôi sẽ ngừng hoạt động!

Ngoài ra, nếu bất kỳ ai có bất kỳ thông tin tổng quát nào về các cải tiến hiệu suất SQL mà bạn đã thực hiện bằng cách sửa lỗi phân mảnh vật lý, điều đó cũng sẽ rất tuyệt. Bài đăng trên blog của Mike nói về việc phát hiện ra vấn đề, nhưng không cụ thể về loại cải tiến mà nó đã thực hiện.

Tôi nghĩ rằng bài viết này cung cấp một cái nhìn tổng quan tuyệt vời về phân mảnh ổ đĩa SAN

http://www.las-solanas.com/st Storage_virtualization / san_volume_defrag sắc tố.php

Điểm cơ bản là phân mảnh không được khuyến nghị trên bộ lưu trữ SAN vì khó tương quan vị trí vật lý của các khối trên đĩa khi vị trí đã được SAN ảo hóa khi trình bày LUN.

Nếu bạn đang sử dụng ánh xạ thiết bị RAW hoặc bạn có quyền truy cập trực tiếp vào bộ RAID là LUN mà bạn đang làm việc, tôi có thể thấy việc khử nhiễu có tác động tích cực, nhưng nếu bạn được cấp LUN "ảo" thì chia sẻ RAID- 5 bộ, không.

Nhiều phần cho câu hỏi và câu trả lời này:

Phân mảnh tệp vật lý không thực sự phù hợp với lưu trữ Enterprise SAN, như Kevin đã chỉ ra - vì vậy không có gì để thêm vào đó. Nó thực sự đi xuống hệ thống con I / O và khả năng bạn có thể làm cho các ổ đĩa chuyển từ I / O ngẫu nhiên hơn khi thực hiện quét sang I / O tuần tự hơn khi thực hiện quét. đối với DAS, nhiều khả năng bạn sẽ, đối với một lát cắt phức tạp SAN, có lẽ là không.

Chống phân mảnh cấp hệ thống tệp - chỉ thực hiện khi tắt SQL. Tôi chưa bao giờ gặp vấn đề ở đây (vì tôi chưa bao giờ thực hiện phân mảnh tệp trực tuyến, mở tệp cơ sở dữ liệu SQL) nhưng tôi đã nghe thấy nhiều bằng chứng giai thoại từ khách hàng và khách hàng về các vấn đề tham nhũng kỳ lạ xảy ra. Sự khôn ngoan chung là không làm điều đó với SQL trực tuyến.

Phân mảnh chỉ mục là hoàn toàn trực giao để phân mảnh tập tin. SQL Server không có ý tưởng phân mảnh tệp - quá nhiều lớp virtualizatin ở giữa để có bất kỳ hy vọng nào có thể thực hiện các hình học hệ thống con I / O thực tế. Phân mảnh chỉ mục, tuy nhiên, SQL biết tất cả mọi thứ về. Không lặp lại quá nhiều từ câu trả lời mà bạn đã tham chiếu, phân mảnh chỉ mục sẽ ngăn SQL thực hiện đọc phạm vi quét phạm vi hiệu quả, bất kể các tệp bị phân mảnh (hoặc không) ở cấp độ hệ thống tệp. Vì vậy - tuyệt đối bạn nên giảm thiểu phân mảnh chỉ mục nếu bạn thấy hiệu suất truy vấn giảm.

Bạn không phải thực hiện những việc này theo bất kỳ thứ tự cụ thể nào, mặc dù nếu bạn quan tâm đến việc phân mảnh hệ thống tệp và sau đó xây dựng lại tất cả các chỉ mục của bạn và gây ra sự phân mảnh hệ thống tệp nhiều hơn bằng cách tăng nhiều tệp trên một ổ đĩa bị phân mảnh, có lẽ bạn sẽ được đánh dấu Nó sẽ gây ra bất kỳ vấn đề hoàn hảo mặc dù? Như đã thảo luận ở trên, nó phụ thuộc :-D

Hi vọng điêu nay co ich!

Cách tốt nhất để sửa phân mảnh tệp vật lý trên hộp SQL sản xuất là gì?

Tôi chạy contig của SYSINTERNALS trên các tệp cơ sở dữ liệu của mình.

Xem http://technet.microsoft.com/en-us/sysiternals/bb897428.aspx

Tôi sẽ khuyên bạn nên định cỡ db một cách thích hợp, tắt máy chủ sql xuống, sao chép tệp cơ sở dữ liệu sang mảng đĩa khác và sau đó sao chép lại để chống phân mảnh. Nhanh hơn nhiều so với sử dụng phân mảnh windows theo kinh nghiệm của tôi.

Tôi đã cố gắng chống phân mảnh các đĩa vật lý trong một giải pháp scsi một lần, nhưng có ít hoặc không tăng hiệu năng. Bài học tôi học được là nếu bạn gặp phải hiệu năng chậm do hệ thống đĩa, thì nó không liên quan gì đến việc phân mảnh, theo như chúng ta nói về tệp dữ liệu, vì nó đang sử dụng truy cập ngẫu nhiên.

Nếu các chỉ mục của bạn được phân mảnh và số liệu thống kê được cập nhật (rất quan trọng) và bạn vẫn thấy I / O là nút cổ chai, thì bạn phải chịu đựng những thứ khác ngoài sự phân mảnh vật lý. Bạn đã sử dụng hơn 80% ổ đĩa? Bạn có đủ ổ đĩa không? Các truy vấn của bạn đã được tối ưu hóa đủ chưa? Bạn có đang thực hiện quét Bảng hay thậm chí tệ hơn rất nhiều tìm kiếm chỉ mục theo sau là tra cứu chỉ mục theo cụm? Nhìn vào các kế hoạch truy vấn và sử dụng "thiết lập số liệu thống kê io" để tìm hiểu điều gì đang thực sự xảy ra với truy vấn của bạn. (tìm kiếm số lượng lớn các lần đọc logic hoặc vật lý)

Xin vui lòng cho tôi biết nếu tôi hoàn toàn sai.

/ Håkan Winther

Có thể các chỉ mục không được tối ưu hóa đủ cho ứng dụng của bạn và bạn không có Veritas I3 để tối ưu hóa cơ sở dữ liệu của mình, sau đó bạn có thể sử dụng một câu lệnh như thế này để tìm các chỉ mục bị thiếu:

       SELECT
      mid.statement,
      mid.equality_columns,
      mid.inequality_columns,
      mid.included_columns,
      migs.user_seeks,
      migs.user_scans,
      migs.last_user_seek,
      migs.avg_user_impact,
      user_scans,
      avg_total_user_cost,
      avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) AS [weight]--, migs.*--, mid.*
   FROM
      sys.dm_db_missing_index_group_stats AS migs
      INNER JOIN sys.dm_db_missing_index_groups AS mig
         ON (migs.group_handle = mig.index_group_handle)
      INNER JOIN sys.dm_db_missing_index_details AS mid
         ON (mig.index_handle = mid.index_handle)
   ORDER BY
      avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) DESC ;

Hoặc một câu lệnh như thế này để tìm các chỉ mục không được sử dụng trong các câu lệnh chọn và giảm hiệu suất cập nhật / chèn:

    CREATE PROCEDURE [ADMIN].[spIndexCostBenefit]
    @dbname [nvarchar](75)
WITH EXECUTE AS CALLER
AS
--set @dbname='Chess'
declare @dbid nvarchar(5)
declare @sql nvarchar(2000)
select @dbid = convert(nvarchar(5),db_id(@dbname))

set @sql=N'select ''object'' = t.name,i.name
        ,''user reads'' = iu.user_seeks + iu.user_scans + iu.user_lookups
        ,''system reads'' = iu.system_seeks + iu.system_scans + iu.system_lookups
        ,''user writes'' = iu.user_updates
        ,''system writes'' = iu.system_updates
from '+ @dbname + '.sys.dm_db_index_usage_stats iu
,' + @dbname + '.sys.indexes i
,' + @dbname + '.sys.tables t
where 
    iu.database_id = ' + @dbid + '
and iu.index_id=i.index_id
and iu.object_id=i.object_id
and iu.object_id=t.object_id
AND (iu.user_seeks + iu.user_scans + iu.user_lookups)<iu.user_updates
order by ''user reads'' desc'

exec sp_executesql @sql

set @sql=N'SELECT
   ''object'' = t.name,
   o.index_id,
   ''usage_reads'' = user_seeks + user_scans + user_lookups,
   ''operational_reads'' = range_scan_count + singleton_lookup_count,
   range_scan_count,
   singleton_lookup_count,
   ''usage writes'' = user_updates,
   ''operational_leaf_writes'' = leaf_insert_count + leaf_update_count + leaf_delete_count,
   leaf_insert_count,
   leaf_update_count,
   leaf_delete_count,
   ''operational_leaf_page_splits'' = leaf_allocation_count,
   ''operational_nonleaf_writes'' = nonleaf_insert_count + nonleaf_update_count + nonleaf_delete_count,
   ''operational_nonleaf_page_splits'' = nonleaf_allocation_count
FROM
   ' + @dbname + '.sys.dm_db_index_operational_stats(' + @dbid + ', NULL, NULL, NULL) o,
   ' + @dbname + '.sys.dm_db_index_usage_stats u,
    ' + @dbname + '.sys.tables t
WHERE
   u.object_id = o.object_id
   AND u.index_id = o.index_id
    and u.object_id=t.object_id
ORDER BY
   operational_reads DESC,
   operational_leaf_writes,
   operational_nonleaf_writes'

exec sp_executesql @sql

GO

Tôi có một số câu lệnh SQL khác mà tôi đang sử dụng khi phân tích các vấn đề về hiệu năng trong môi trường sản xuất, nhưng hai câu lệnh này là một khởi đầu tốt mà tôi nghĩ.

(Tôi biết, bài đăng này có một chút chủ đề, nhưng tôi nghĩ bạn có thể quan tâm vì nó liên quan đến chiến lược lập chỉ mục)

/ Håkan Winther