Dừng (các) dịch vụ SQL Server trước khi phân mảnh ổ đĩa?


8

Các tệp dữ liệu của cơ sở dữ liệu SQL Server 2005 sản xuất của chúng tôi nằm trên một ổ đĩa vật lý riêng biệt, công cụ Disk Defragmenter của Microsoft Windows 2003 báo cáo là phân mảnh 99%.

Chúng tôi đã lên lịch một nhiệm vụ để chống phân mảnh ổ đĩa này vào lúc 3:00 sáng vào thứ bảy. Công việc hoàn thành sau 40 phút không có lỗi rõ ràng. Tuy nhiên, ổ đĩa vẫn bị phân mảnh nặng nề.

Chúng ta có nên dừng (các) dịch vụ SQL Server trước khi chống phân mảnh không?

BỐI CẢNH

Theo yêu cầu cho ngữ cảnh: Chúng tôi có phiên bản Microsoft SQL Server 2005 (9.00.5324.00) chạy Windows Server 2003 (SP2) 32 bit trên phần cứng Dell PowerEdge 2950, ​​vào khoảng năm 2007, với RAM 4GB. PowerEdge 2950 có bốn ổ 68 GB được cấu hình là RAID-1 để tạo hai đĩa ảo 68 GB: (1) C (boot và OS) & D (pagefile, dữ liệu khác linh tinh); và (2) E (dữ liệu SQL). Theo hiểu biết của tôi, nhân viên CNTT chưa bao giờ chống phân mảnh bất kỳ ổ đĩa nào ... Disk Defragmenter báo cáo phân mảnh tệp 66% (C), 77% (D) và 99% (E). Giám sát hiệu suất báo cáo kết quả trung bình sau: "Tệp hoán trang:% cách sử dụng" = ~ 6,8% ; "Máy chủ SQL: Trình quản lý bộ đệm - Tuổi thọ trang" = 20 giây ; và "PhysDisk: Trung bình đĩa sec / ghi, ổ E" = trong khoảng từ 300 đến 1,. Chúng tôi sẽ nâng cấp phần cứng và SQL Server rất cần thiết trong một vài tháng tới (viz., Phần cứng mới, Windows Server 2012 bit 64, SQL Server 2012 bit, RAM 12 GB), nhưng do kết thúc hiệu suất người dùng, muốn giảm bớt vấn đề càng nhiều càng tốt. Do đó, suy nghĩ phân mảnh tệp có thể giúp cho ổ E, ổ dữ liệu SQL chính.

Như một bên, tuần trước chúng tôi đã kéo hai ổ đĩa thất bại và xây dựng lại mảng ... không chắc chắn đó là vấn đề. Chúng tôi hợp đồng với một nhóm CNTT khác để duy trì máy chủ, vì vậy chúng tôi không có quyền truy cập trực tiếp vào thiết bị ... tổ chức của chúng tôi chỉ trả tiền cho các dịch vụ.

Chúng tôi có thể đủ khả năng ngừng hoạt động trong các cửa sổ bảo trì thường xuyên theo lịch trình (hàng tuần) cũng như thời gian ngừng hoạt động ngoài băng, khi cần thiết, qua đêm.


6
Bạn có bất kỳ phép đo nào để chỉ ra rằng sự phân mảnh đĩa vật lý đang có một tác động đáng kể? Bạn có thể đủ khả năng thời gian chết?
Remus Rusanu

2
@RemusRusanu - làm thế nào người ta có thể biết liệu bất kỳ mức độ phân mảnh nhất định nào có ảnh hưởng tổng thể tiêu cực đến hệ thống mà không thực sự chống phân mảnh không? Việc kiểm tra số lượng I / O phân tách thông qua Trình theo dõi hiệu suất có thể giúp ích mặc dù sẽ rất khó để tương quan điều đó với hoạt động trong SQL Server. Nhân tiện, đây không phải là một cuộc đối đầu - tôi thực sự tò mò!
Max Vernon

4
@MaxVernon: Vì lý thuyết, tôi đoán XPerf . Người ta cũng có thể đo cạnh nhau bằng cách tạo cơ sở dữ liệu không phân mảnh trên cùng một đĩa và chạy một khối lượng công việc đã bắt. Tuy nhiên, vì tất cả lý do thực tế, khả năng các vấn đề hiệu suất phổ biến trong ứng dụng so với phân mảnh là quá lớn.
Remus Rusanu

3
Kinh nghiệm của tôi cho tôi biết 99 lần trong số 100 (hoặc hơn) tôi chắc chắn sẽ đồng ý. Các vấn đề về hiệu suất rất có thể là kết quả của việc một số ORM hoạt động ở SELECT *mọi nơi hoặc một số lỗi khác.
Max Vernon

1
Trước khi bạn thực hiện bất kỳ thay đổi nào khác và chắc chắn trước khi thử chống phân mảnh, bạn muốn đảm bảo các mảng đã được xây dựng lại hoàn toàn. Và một lời khuyên cho hệ thống mới của bạn - hãy lấy càng nhiều RAM càng tốt - bạn muốn có càng nhiều dữ liệu SQL được truy cập thường xuyên trong bộ nhớ vì RAM nhanh hơn 1.000 lần so với các đĩa nhanh nhất.
Max Vernon

Câu trả lời:


2

Cá nhân tôi đã sử dụng Raxco PerfectDisk (không liên kết với công ty hoặc bất kỳ nhân viên nào của họ theo bất kỳ cách nào) để thực hiện các phân đoạn trực tuyến của SQL Server LUNs. Hoạt động hoàn hảo, nếu nó làm chậm máy chủ một chút. Tôi sẽ khuyên bạn nên làm điều đó trong thời gian hoạt động nhẹ hơn. Khi tôi nói "hoạt động hoàn hảo", tôi đang đề cập đến nó không làm hỏng khối lượng hoặc tệp dữ liệu SQL.

Trình chống phân mảnh tích hợp thực hiện công việc rất kém nếu các cấu trúc nhất định bị phân mảnh trên ổ đĩa. PerfectDisk cho bạn thấy chi tiết về tất cả các mục bị phân mảnh bao gồm bảng phân bổ NTFS, thư mục, luồng tệp thay thế, v.v.

Liệu PerfectDisk chống phân mảnh cơ sở dữ liệu SQL? http://support.raxco.com/KB/a106/does-perinfdisk-defragment-sql-database.aspx

Xem bản lưu trữ này của Tạp chí Technet News về SQL Server và phân mảnh: http://web.archive.org/web/20100803204458/http://www.microsoft.com/technet/abouttn/flash/tips/tips_083104.mspx


2
Nhưng nhận xét của Remus có nhiều công đức hơn là chỉ vào một số sản phẩm. Tôi không tin rằng tôi đã từng chống phân mảnh một đĩa Windows có SQL và chưa bao giờ thấy một dấu hiệu mạnh mẽ nào mà tôi cần. Windows có thể nói rằng một ổ đĩa bị phân mảnh nhưng điều quan trọng là liệu SQL Server có gặp phải bất kỳ sự cố nào không. Trong rất nhiều trường hợp tôi nghi ngờ nó thực sự không thành vấn đề và không cần phải chạy phân mảnh cấp độ hệ thống. Bạn nói nó "hoạt động hoàn hảo" nhưng bạn đã thực sự quan sát sự cải thiện có thể đo lường được chưa? Bạn có thể cung cấp chi tiết?
Aaron Bertrand

1
Tôi đồng ý, Aaron, đối với hầu hết các trường hợp phân mảnh vật lý trên SQL Server được thiết kế đúng cách sẽ có hiệu quả rất tối thiểu. Ngay cả trong trường hợp này, người dùng đang báo cáo phân mảnh 99%. Tuy nhiên, nếu người dùng có cơ sở dữ liệu SQL của mình trên cùng LUN với O / S và điều đó xảy ra trên một đĩa đơn hoặc một mảng RAID với một trục nhỏ của trục chính, sự phân mảnh quá mức có thể có tác động.
Max Vernon

1
"Thực sự quá mức", ý tôi là hàng ngàn trên hàng ngàn mảnh vỡ. Nghĩ hàng trăm ngàn. Tôi đã thấy điều đó. Không phải là tôi tự hào hay bất cứ điều gì!
Max Vernon

Như Brent Ozar đã nói, nếu bạn đang chạy Cơ sở dữ liệu SQL của mình trên SAN nơi dữ liệu được chia sẻ trên một mảng RAID khổng lồ, thực hiện phân mảnh vật lý (và thực sự là phân mảnh SQL logic) sẽ không có tác động tích cực có thể đo lường được trên tổng thể hiệu suất của hệ thống.
Max Vernon

Tôi đánh dấu đây là câu trả lời tốt nhất hiện tại, vì có vẻ như "Có" nếu chúng ta sử dụng đúng công cụ. Cảm ơn!
iokevins

7

Vấn đề của bạn không phải là phân mảnh đĩa. Vấn đề của bạn là RAM và quét bảng ứng dụng:

RAM 4GB ... 68GB ... Tuổi thọ trang 20 giây

Bạn cần cách thêm RAM. Như trong máy chủ mới của bạn nên có cách, cách, cách, cách hơn 12GB. Bắt đầu với 64 GB, chi phí cơ bản là dimes . Và có, sửa ứng dụng của bạn để sử dụng các chỉ mục. 20 giây là dấu hiệu rất rõ ràng về việc quét bảng quét rác vùng đệm. Bạn cần sửa ứng dụng, thêm các chỉ mục cần thiết và sửa các truy vấn của bạn . Đối với trường hợp của bạn, việc chống phân mảnh các ổ đĩa cũng giống như cá trích đỏ giống như cá trích đỏ.

Ồ, và vui lòng di chuyển nhật ký để tách các trục vật lý khỏi dữ liệu . Một mình.


Cảm ơn Remus; Giá như tôi thống trị thế giới .... Chúng tôi hợp đồng với một nhà cung cấp bên thứ ba cho ứng dụng, vì vậy không nằm trong sự kiểm soát trực tiếp của chúng tôi, thật đáng tiếc. Tôi đánh giá cao sự hiểu biết của bạn, cảm ơn bạn.
iokevins

1
Nhiều RAM và SSD có thể dễ dàng thoát ra với ngân sách khá mỏng. Nhưng ứng dụng cần một bản sửa lỗi.
Remus Rusanu

Theo dõi, sau khi chống phân mảnh ổ đĩa, hiệu suất chỉ được cải thiện một chút. Remus có vẻ đúng trong chẩn đoán về vấn đề RAM.
iokevins 18/03/13

@RemusRusanu có vấn đề gì khi cố gắng tối ưu hóa với các tệp được đặt trong các đĩa khác nhau trong các máy chủ ảo (vmware) không? Đây là một câu hỏi ảo hóa ảo hóa chung ...
diegohb

-4

Brad McGehee mô tả nó tốt ở đây:

http://www.bradmcgehee.com/2011/06/do-you-ever-physatics-defragment-your-sql-server-mdf-ldf-files/

... Nếu bạn để dịch vụ SQL Server chạy trong phân mảnh, các tệp cơ sở dữ liệu sẽ mở và do đó không được chống phân mảnh.


2
Hoàn toàn không chính xác. Ít nhất là trên các phiên bản gần đây của Windows. Như trong Windows Server 2003+ hoặc Windows XP +
Max Vernon

1
Tất cả các công cụ chống phân mảnh của Windows đều sử dụng API hệ thống để chống phân mảnh tệp và làm như vậy ở cấp độ cụm bên dưới API truy cập tệp. Đây là cách thư mục có thể được phân mảnh với âm lượng trực tuyến.
Max Vernon
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.