Vị trí tối ưu của các tệp tempdb, mdf và ldf trong SQL Server 2012 trên SSD?


9

Tôi nhận ra đây có lẽ là một câu hỏi kết thúc rất mở và câu trả lời có thể khác nhau, nhưng vị trí tối ưu cho các tệp tempdb, mdf và ldf trong SQL Server 2012 khi nói về SSD là gì?

Trước khi mua mới, tôi đã có một ổ SSD hiện có với các tệp lõi SQL Server 2012 và tempdb được cài đặt trên và có cả mdf / ldf trên ổ cứng 7200rpm. Sau đó tôi đã mua 2 ổ SSD với mục đích ban đầu là đặt mdf trên một và ldf trên một.

Nhưng, từ việc đọc vào nó nhiều hơn, các đĩa vật lý riêng biệt cho các tệp mdf và ldf không thực sự áp dụng khi nói đến SSD. Chính xác?

Vì vậy, tôi đã nghĩ về những điều sau đây:

SSD 1 - SQL Server 2012 Core Files và Windows
SSD 2 - tempdb
SSD 3 - mdf và ldf

Nếu nó tạo ra sự khác biệt, điều này sẽ được dành riêng cho chỉ một cơ sở dữ liệu để không có bất kỳ sự tranh chấp nào giữa nhiều cơ sở dữ liệu.

Thiết lập "suy nghĩ" của tôi có tốt không hay chỉ đơn giản là lãng phí (tức là không có lý do gì để tách tempdb) khi tôi có thêm một ổ SSD để sử dụng ở nơi khác?


2
Là khả năng chịu lỗi là một tùy chọn với thiết lập của bạn? Nếu cơ sở dữ liệu của bạn hoàn toàn quan trọng, các ổ đĩa mdf và ldf nên được lưu trữ trên các ổ đĩa chịu lỗi riêng biệt (ví dụ như được nhân đôi).
datagod

3
Một vấn đề tiềm năng tôi thấy với thiết lập của bạn là bạn chưa tính đến một lỗi ổ đĩa. Nếu bạn chỉ có ba ổ SSD để làm việc, tôi khuyên bạn nên xem xét một mảng RAID5 và đặt tất cả các tệp liên quan đến Máy chủ SQL của bạn trên mảng đó.
Matt M

2
Đây có phải là máy chủ cấp sản xuất không, hoặc bạn có quan tâm nếu nó bị hỏng nếu ổ đĩa bị lỗi không?
Jon Seigel

1
Quên đề cập đến phần đó - khả năng chịu lỗi không phải là vấn đề đáng lo ngại vì dữ liệu được sao lưu đầy đủ, hàng đêm, nhưng chủ yếu là dữ liệu tĩnh mà tôi có thể dễ dàng thay thế ngay cả khi các bản sao lưu không phải là một tùy chọn. Dữ liệu động duy nhất chủ yếu là ghi nhật ký / kiểm toán không có phụ thuộc. Bất kỳ sự gián đoạn nhỏ nào trong dịch vụ tôi sẽ có trong việc cắt giảm một bản sao lưu, bằng tay, đều có thể chấp nhận được.
Kevin

Tôi đánh giá cao các câu trả lời, tất cả. Tôi có một câu hỏi tiếp theo liên quan đến "tốt nhất là định dạng các khối ssd thành 64k?", Nhưng tôi không quen với định dạng ở đây. Tôi có nên đăng nó như một câu hỏi mới hay điều này có ổn ở đây không?
Kevin

Câu trả lời:


5

Nhưng, từ việc đọc vào nó nhiều hơn, các đĩa vật lý riêng biệt cho các tệp mdf và ldf không thực sự áp dụng khi nói đến SSD. Chính xác?

Lý do ban đầu để tách các tệp nhật ký và dữ liệu ra khỏi các đĩa riêng biệt là 2 lần - độ trễ và băng thông trên các ổ đĩa.

SSD không loại bỏ những hạn chế này, nhưng chúng làm giảm / tăng giới hạn khá đáng kể (7,9ms cho một lần đọc với một ổ cứng so với 0,1ms cho một lần đọc trong một ổ SSD, khoảng).

Vì vậy, cuối cùng có và không - nó không áp dụng NHIỀU như với ổ cứng, nhưng những giới hạn đó vẫn còn đó và vẫn có thể được đáp ứng. Tất cả phụ thuộc vào khối lượng công việc của bạn.

Thiết lập "suy nghĩ" của tôi có tốt không hay chỉ đơn giản là lãng phí (tức là không có lý do gì để tách tempdb) khi tôi có thêm một ổ SSD để sử dụng ở nơi khác?

Giả sử rằng

  • Bạn có 3 ổ SSD vật lý
  • Bạn có 1 ổ cứng vật lý
  • Bạn cần dữ liệu để dự phòng, nhưng không nhất thiết là hệ thống

Thiết lập đề xuất của bạn sẽ có một vài vấn đề (như đã đề cập trước đó) và một ổ đĩa bị lỗi là vấn đề chính.

Bạn có thể đi cho một cái gì đó như thế này.

Ổ đĩa đơn 7200 vòng / phút -
mảng Windows OS RAID 5 (3 SSD) - Được chia thành 4 ổ (D cho Dữ liệu, L cho Nhật ký, S cho Hoán đổi và T cho Temp)

HOẶC LÀ

Ổ đĩa đơn 7200 vòng / phút - Hệ điều hành Windows
SSD đơn - Tạm thời và hoán đổi
RAID 1 mảng (2 SSD) - Dữ liệu và Nhật ký

Sở thích cá nhân của tôi là giảm tải Windows cho ổ đĩa không phải SSD khi bạn chỉ có số lượng giới hạn, nhưng điều này hoàn toàn phụ thuộc vào những gì máy chủ đang làm và mức độ rủi ro mà bạn sẵn sàng chịu.

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.