SQL Server 2005/2008 - nhiều tệp / nhóm tệp - bao nhiêu? Tại sao?

Tôi là một nhà phát triển trung tâm - nhưng thỉnh thoảng, một khách hàng không có một DBA tử tế để giải quyết các vấn đề này, vì vậy tôi được gọi đến để quyết định ....

Chiến lược / cách thực hành tốt nhất của bạn là gì khi xử lý cơ sở dữ liệu SQL Server có kích thước hợp lý (bất cứ thứ gì lớn hơn Northwind hoặc AdventureWorks; khoảng 2-4 GB dữ liệu cộng với chỉ mục, v.v.) - bạn có sử dụng nhiều tệp / nhóm tệp không?

Nếu vậy: bao nhiêu? Và tại sao?

Tiêu chí của bạn là gì để quyết định khi nào nên rời khỏi phương pháp "một tập đoàn cho mọi thứ":

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Nếu bạn sử dụng nhiều nhóm tập tin, bạn sử dụng bao nhiêu? Một cho dữ liệu, một cho chỉ mục, một cho nhật ký? Một số (bao nhiêu) cho dữ liệu? Lý do cho sự lựa chọn của bạn là gì - tại sao bạn sử dụng số lượng nhóm chính xác đó :-)

Cảm ơn cho bất kỳ gợi ý, con trỏ, suy nghĩ!

Chúc mừng, Marc

Nguyên tắc cơ bản là phân tách các tệp thành các khối khác nhau để tránh sự tranh chấp, tuy nhiên, kết quả đạt được về hiệu suất mà bạn nhận được rất khác nhau bởi hệ thống con I / O và khối lượng công việc. Ví dụ, nhiều tệp trên một trục chính vật lý sẽ giảm hiệu suất, nhưng cách sắp xếp tương tự với âm lượng trên SAN LUN với hàng trăm ổ đĩa từ mảng RAID 10 có thể vẫn ổn. Bộ đếm chiều dài hàng đợi đĩa là bạn của bạn như là cách đơn giản nhất để biết bạn có bị tắc nghẽn I / O hay không.

Bạn đang xem các mẫu I / O trên cơ sở dữ liệu - chỉ đọc, đọc chủ yếu, đọc, viết, chủ yếu, chỉ viết - và dựa trên những điều đó. Bạn cũng cần chọn đúng cấp độ RAID và đảm bảo độ lệch phân vùng đĩa, kích thước sọc RAID và kích thước đơn vị phân bổ NTFS được đặt chính xác. Một số người muốn tách các chỉ mục không bao gồm thành một nhóm riêng biệt, nhưng hiệu suất đạt được ở đây khác nhau như tôi đã giải thích ở trên.

Cũng như hiệu suất, bạn nên xem xét khả năng quản lý và khả năng phục hồi. Có một tệp dữ liệu nguyên khối duy nhất cho cơ sở dữ liệu 100 GB có nghĩa là đơn vị khôi phục của bạn là tệp đó. Việc chia thành 4 nhóm 25GB có nghĩa là bạn có thể sử dụng một phần cơ sở dữ liệu sẵn có và khôi phục từng phần để chỉ phải khôi phục một nhóm fileg duy nhất trong trường hợp nó bị hỏng. Bằng cách phân vùng bảng và chỉ mục trong nhiều nhóm, bạn cũng có thể giới hạn phần nào của cơ sở dữ liệu bị ảnh hưởng bởi các hoạt động bảo trì (ví dụ: loại bỏ phân mảnh chỉ mục).

Tempdb là một trường hợp đặc biệt và tôi sẽ chỉ cho bạn một bài đăng trên blog của tôi giải thích tất cả về lý do và cách chia tempdb - có rất nhiều quan niệm sai lầm ngoài kia.

Không đưa ra cho bạn một đề xuất 'khái quát hóa sâu rộng' ở đây, tôi sẽ chỉ cho bạn một loạt các trang trắng và bài đăng trên blog để bạn đọc:

• Whitepaper: Thiết kế lưu trữ cơ sở dữ liệu vật lý
• Whitepaper: Dự đoán I / O Thực tiễn tốt nhất
• Bảng trắng: Bảng và chỉ mục được phân vùng trong SQL Server 2005

• Whitepaper: Cơ sở dữ liệu một phần

• Bài đăng trên blog: Những quan niệm sai lầm xung quanh TF 1118 (bố cục tempdb)

• Bài đăng trên blog: Các phân vùng đĩa của bạn có bị lệch, kích thước sọc RAID và các đơn vị phân bổ NTFS được đặt chính xác không? (có liên kết đến whitepaper phân vùng đĩa)

Hy vọng điều này sẽ giúp bạn!

Quyết định tách cơ sở dữ liệu thành các nhóm khác nhau nên được đưa ra sau khi đã phân tích kích thước hiện tại và sự tăng trưởng trong tương lai của các bảng của bạn. Theo tôi, trừ khi bạn có một cơ sở dữ liệu lớn hoặc các bảng có hàng triệu hàng, bạn nên xem xét cẩn thận ưu và nhược điểm, vì cuối cùng bạn có thể tạo ra nhiều vấn đề về hiệu suất hơn là bạn sửa.

Có một số tình huống có thể thú vị trong các cơ sở nhất định:

• 2 nhóm: dữ liệu và chỉ mục
• 3 nhóm fileg: bảng chỉ đọc, bảng đọc-ghi, chỉ mục
• nhiều nhóm fileg: chỉ đọc, đọc-ghi, chỉ mục, bảng chính 1, bảng chính 2, ...

Bạn phải phân tích môi trường của mình để quyết định xem các nhóm fileg sẽ giúp với nhu cầu tăng trưởng, sử dụng và hiệu suất của SQL Server hay không.

Một số chỉ số chính để di chuyển đến nhiều nhóm (từ bài viết này ):

• Khi xếp hàng đĩa gây ra sự cố về ứng dụng và trải nghiệm người dùng
  • Nếu đây là trường hợp, hãy xem xét tận dụng các ổ đĩa bổ sung với các bảng chuyên sâu IO của các nhóm tập tin mới
• Khi các bảng cụ thể là 10% trở lên của cơ sở dữ liệu
  • Nếu đây là trường hợp, hãy xem xét di chuyển các bảng đặc biệt lớn này để tách các nhóm tệp trên các ổ đĩa riêng biệt bên dưới
  • Tùy thuộc vào kích thước bảng tỷ lệ với phần còn lại của các bảng, hãy xem xét việc xây dựng một nhóm fileg cho các bảng riêng lẻ
• Khi không chỉ mục cụm và không gian dữ liệu bằng nhau trên các bảng lớn
  • Nếu đây là trường hợp, hãy xem xét tách dữ liệu và chỉ mục cụm từ các chỉ mục không được phân cụm
• Khi tồn tại một tỷ lệ gần như bằng nhau của dữ liệu chỉ đọc và đọc ghi trong cơ sở dữ liệu
  • Nếu đây là trường hợp, hãy xem xét chia dữ liệu chỉ đọc trong một nhóm riêng biệt làm dữ liệu đọc-ghi
• Khi không đủ thời gian có sẵn để thực hiện bảo trì cơ sở dữ liệu
  • Nếu đây là trường hợp, hãy xem xét chia các bảng lớn thành các nhóm riêng biệt trên các đĩa bên dưới khác nhau và thực hiện bảo trì song song
• Khi doanh nghiệp hoặc ứng dụng sẽ thay đổi đáng kể và dữ liệu sẽ tăng lên với tốc độ cao hơn nhiều
  • Nếu đây là trường hợp, hãy xem xét làm việc với người dùng để hiểu được sự tăng trưởng tiềm năng
• Khi dữ liệu lưu trữ nằm trong cùng cơ sở dữ liệu với dữ liệu sản xuất
  • Nếu đây là trường hợp, hãy xem xét các nhóm tệp riêng biệt hoặc một hoặc nhiều kỹ thuật trong mẹo này - Lưu trữ dữ liệu trong SQL Server

Nếu bạn thấy rằng các nhóm fileg có thể cải thiện hiệu suất cơ sở dữ liệu của bạn, hãy viết mã và kiểm tra quy trình trong môi trường dàn dựng trước khi bạn thực hiện các thay đổi trên các máy chủ sản xuất của mình. Chuẩn bị một số phép đo trước khi bạn thực hiện các thay đổi và so sánh chúng trước / sau. Vì các quy trình này có thể rất tốn tài nguyên và tốn thời gian, nên thực hiện các quy trình này trong thời gian bảo trì.

Đừng quên, khi tạo các đối tượng mới (bảng và chỉ mục), hãy chắc chắn rằng các đối tượng được tạo trong nhóm chính xác để đảm bảo hiệu suất mong đợi và xác thực định kỳ các đối tượng cơ sở dữ liệu nằm trong nhóm fileg chính xác và chính xác khi cần.