SQL Server 2K / 2K5 / 2K8 và Đĩa trạng thái rắn: Tối ưu hóa cụ thể?

Có ai ở đây đang chạy SQL Server trên các ổ đĩa trạng thái rắn không? Bạn đã tìm thấy bất kỳ lời khuyên tối ưu hóa cụ thể? Tôi đặc biệt quan tâm đến các cách để giảm tần suất SQL Server thực hiện các thao tác ghi ngẫu nhiên nhỏ vì chúng là kẻ thù của hiệu suất SSD, đặc biệt là các ổ SSD MLC.

Tất nhiên, có một số tối ưu hóa rõ ràng có thể làm: dữ liệu nặng đọc được phục vụ từ SSD và những thứ nặng ghi nên được để lại cho các đĩa quay truyền thống. Điều đó bao gồm nhật ký giao dịch, một cách tự nhiên!

Tất nhiên, khi có đủ ngân sách, người ta sẽ muốn sử dụng các ổ SSD SLC như X25-E hoặc sê-ri Vertex Ex hoặc các dịch vụ cấp doanh nghiệp khác nhau. Nhưng tôi cũng quan tâm đến các mẹo có thể có lợi cho việc thiết lập SSD MLC. Tôi nghĩ đó là một khu vực thú vị. Một trong những khách hàng của khách hàng của tôi có ngân sách nhỏ và bộ dữ liệu đã tăng lên rất nhiều và họ phải đối mặt với việc viết lại hoàn toàn gần một trăm truy vấn để duy trì mức hiệu suất tốt. Tuy nhiên, tôi có một nghi ngờ lén lút rằng ít hơn 500 đô la RAM và dung lượng SSD có thể giúp họ tăng hiệu suất lớn hơn hàng ngàn (có thể hàng chục nghìn đô la) thời gian của nhà phát triển.

Không chắc chắn ý của bạn bằng cách giảm số lượng ghi nhỏ, ngẫu nhiên mà SQL Server thực hiện. SQL Server chỉ ghi các trang dữ liệu trong các điểm kiểm tra - vì vậy cách duy nhất để hạn chế số lần ghi là thay đổi khoảng thời gian điểm kiểm tra hoặc không thực hiện quá nhiều thao tác IUD. Có phải ý của bạn là thứ khác?

Trong tất cả các triển khai SSD mà tôi đã thấy (một số ít), nó trái ngược với những gì bạn đề xuất - việc sử dụng SSD tốt nhất dường như là dành cho nhật ký giao dịch nặng và tempdb - về cơ bản là lớn nhất / O tắc nghẽn hệ thống con và gắn SSD vào đó - vì thời gian tìm kiếm và độ trễ được giảm xuống một hằng số thấp.

Kiểm tra tài liệu nghiên cứu này mà MS đã tạo ra (rất tiếc là không chi tiết về các chi tiết cụ thể của SQL Server): Di chuyển lưu trữ máy chủ sang SSD: Phân tích sự đánh đổi .

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

Bạn không thể sửa đổi các cấu trúc SQL Máy chủ IO. Đơn vị cơ bản của truy cập đĩa, đối với các tệp dữ liệu, là một trang 8Kb. Nó sẽ viết chúng chủ yếu trong một điểm kiểm tra, nhưng cũng sẽ lười viết chúng khi có thể.
SQL không đợi ghi vào đĩa dữ liệu để hoàn thành trước khi quay trở lại, đó chỉ là ghi nhật ký phải được hoàn thành. Nếu bạn chỉ có thể giữ một bản ghi cơ sở dữ liệu trên một đĩa thì nó sẽ được ghi tuần tự và sẽ ổn trên các đĩa cứng nhanh thông thường.
Hiệu suất đạt được theo quan điểm của SQL là khi nó phải đọc các đĩa. Nếu bạn có thể cung cấp cho nó nhiều bộ nhớ hơn thì SQL sẽ chứa nhiều trang dữ liệu hơn trong bộ nhớ, nhanh hơn bất kỳ loại đĩa, SSD nào khác. Rõ ràng bạn cũng có thể giảm số lần đọc đĩa bằng cách tạo các chỉ mục thích hợp. Tôi hy vọng một ổ SSD cũng sẽ giúp ích cho những lần đọc này bởi vì chúng có thể là ngẫu nhiên và được giữ chờ đợi đầu ổ đĩa di chuyển.
Tôi không biết kích thước cơ sở dữ liệu mà chúng ta đang nói ở đây, nhưng bạn có thể muốn xem qua HyperOS. Họ tạo ra các đĩa sata thực sự chỉ là một thanh ram DDR2, với ổ SSD hoặc 2,5 inch làm bản sao lưu. Mẫu truy cập của máy chủ sẽ không thành vấn đề. Tôi sẽ không đặt nhật ký vào bất cứ điều gì như thế này. Nhật ký là thứ giữ cho dữ liệu của bạn nhất quán, chúng cần phải ở trên một phương tiện đáng tin cậy và mặc dù có SSD và pin dự phòng và máy chủ có thể có UPS, v.v., tôi vẫn cảm thấy không dễ dàng khi không có nhật ký của mình trên ổ cứng thực sự trong một số loại mảng RAID chịu đựng thất bại.

Các hoạt động ngẫu nhiên nhỏ là kẻ thù của các đĩa truyền thống, do độ trễ tìm kiếm đầu ... SSD rất tốt trong việc giải quyết chính xác điều này.

Với các hoạt động liên tục, dài, các đĩa tiêu chuẩn hoạt động khá tốt, do đó sẽ không có mục đích sử dụng SSD (tất nhiên là từ quan điểm hiệu suất).

Chưa có điểm nào khó khăn để thêm vào luồng nhận xét, nhưng nếu bạn đặt kích thước trang / số lần đọc của DB cho bất kỳ thứ gì trên ổ SSD thành nhiều kích thước trang của SSD thì đây không phải là vấn đề.

Tôi đã không làm việc trên SQL Server trong một thời gian dài vì vậy tôi không chắc các tùy chọn này có sẵn ở đó không. Tôi đã làm Oracle và DB2 trong vài năm qua và điều này sẽ giải quyết mối quan tâm của bạn vì DB sẽ được điều chỉnh đúng với các đặc điểm của đĩa.

Tôi muốn giới thiệu phân vùng căn chỉnh nơi lưu trữ các tệp cơ sở dữ liệu.

Tôi cũng khuyên bạn nên quyết định những gì xảy ra với RAID 0 cho perf (ldf và TempDB) và đặt dữ liệu quan trọng trên RAID 1 (mdf).

Thứ ba, bạn thực sự nên cập nhật phần sụn của ổ đĩa cũng như phần sụn / trình điều khiển SATA. Bằng cách đó, bạn cung cấp cho công ty phần cứng và nhà phát triển của họ cơ hội tối ưu hóa sự hoàn hảo cho bạn.