SQL Server 2005/2008 - banyak file / filegroup - berapa banyak? Mengapa?

Saya seorang pengembang hati - tetapi setiap sekarang, pelanggan tidak memiliki DBA yang layak untuk menangani masalah ini, jadi saya dipanggil untuk memutuskan ....

Apa strategi / praktik terbaik Anda ketika berhadapan dengan database SQL Server berukuran cukup besar (sesuatu yang lebih besar dari Northwind atau AdventureWorks; kira-kira 2-4GB data plus indeks, dll.) - apakah Anda menggunakan banyak file / grup grup?

Jika demikian: berapa banyak? Dan mengapa?

Apa kriteria Anda untuk memutuskan kapan harus pindah dari pendekatan "satu grup grup untuk segalanya":

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

Jika Anda menggunakan beberapa grup file, berapa banyak yang Anda gunakan? Satu untuk data, satu untuk indeks, satu untuk log? Beberapa (berapa banyak) untuk data? Apa alasan Anda atas pilihan Anda - mengapa Anda menggunakan jumlah grup fileg yang tepat :-)

Terima kasih atas petunjuk, petunjuk, pemikiran!

Ceria, Marc

Aturan dasar praktis adalah memisahkan file ke volume yang berbeda untuk menghindari pertikaian, namun jumlah peningkatan kinerja yang Anda dapatkan sangat bervariasi menurut subsistem I / O dan beban kerja. Sebagai contoh, beberapa file pada satu spindel fisik akan menyedot sejauh kinerja berjalan, tetapi pengaturan yang sama dengan volume berada di SAN LUN dengan beberapa ratus drive dari array RAID 10 mungkin baik-baik saja. Penghitung panjang antrian disk adalah teman Anda sebagai cara paling sederhana untuk mengetahui apakah Anda mengalami bottleneck I / O.

Anda sedang melihat pola I / O pada basis data - baca-saja, baca-kebanyakan, baca-tulis, tulis-kebanyakan, tulis-saja - dan mendasarkan hal itu. Anda juga perlu memilih level RAID yang tepat dan memastikan offset partisi disk Anda, ukuran strip RAID, dan ukuran unit alokasi NTFS diatur dengan benar. Beberapa orang suka memisahkan indeks yang tidak dikelompokkan menjadi filegroup yang terpisah, tetapi peningkatan kinerja di sini bervariasi seperti yang telah saya jelaskan di atas.

Serta kinerja, Anda harus mempertimbangkan pengelolaan dan pemulihan. Memiliki satu, file data monolitik untuk database 100GB berarti unit pemulihan Anda adalah file itu. Membagi menjadi 4 25GB filegroup berarti Anda dapat menggunakan ketersediaan basis data parsial dan pengembalian sedikit demi sedikit hanya perlu mengembalikan satu filegroup jika rusak. Dengan mempartisi tabel dan indeks dalam beberapa grup file, Anda juga dapat membatasi bagian mana dari basis data yang dipengaruhi oleh operasi pemeliharaan (misalnya penghapusan indeks fragmentasi).

Tempdb adalah kasus khusus, dan saya akan menunjukkan Anda di posting blog saya yang menjelaskan semua tentang mengapa dan bagaimana membagi tempdb - ada banyak kesalahpahaman di luar sana.

Tanpa memberi Anda rekomendasi 'penyapuan generalisasi' di sini, saya akan mengarahkan Anda ke sekelompok whitepaper dan posting blog untuk Anda baca:

• Whitepaper: Desain Penyimpanan Database Fisik
• Whitepaper: Predeployment I / O Best Practices
• Whitepaper: Tabel dan Indeks Partisi dalam SQL Server 2005

• Whitepaper: Ketersediaan Basis Data Sebagian

• Posting blog: Kesalahpahaman di sekitar TF 1118 (tata letak tempdb)

• Posting blog: Apakah offset partisi disk Anda, ukuran garis RAID, dan unit alokasi NTFS diatur dengan benar? (dengan tautan ke whitepaper partisi disk)

Semoga ini bisa membantu Anda!

Keputusan untuk memecah basis data dalam filegroup yang berbeda harus diambil setelah menganalisis ukuran tabel saat ini dan pertumbuhan masa depan Anda. Menurut pendapat saya, kecuali jika Anda memiliki database atau tabel besar dengan jutaan baris, Anda harus mempertimbangkan pro dan kontra dengan hati-hati, karena pada akhirnya Anda dapat menciptakan lebih banyak masalah kinerja daripada yang Anda perbaiki.

Ada beberapa skenario yang mungkin menarik di tempat tertentu:

• 2 filegroup: data dan indeks
• 3 filegroup: tabel read-only, read-write tables, index
• beberapa filegroup: baca-saja, baca-tulis, indeks, tabel kunci 1, tabel kunci 2, ...

Anda harus menganalisis lingkungan Anda untuk memutuskan apakah filegroup akan membantu pertumbuhan SQL Server, penggunaan, dan kebutuhan kinerja Anda.

Beberapa indikator utama untuk berpindah ke beberapa grup fileg (dari artikel ini ):

• Ketika antrian disk menyebabkan masalah aplikasi dan pengalaman pengguna
  • Jika demikian, pertimbangkan untuk meningkatkan disk drive tambahan dengan filegroup baru yang menampung tabel intensif IO
• Ketika tabel tertentu 10% atau lebih dari database
  • Jika ini masalahnya, pertimbangkan untuk memindahkan tabel yang sangat besar ini untuk memisahkan grup file pada drive disk yang mendasarinya terpisah
  • Bergantung pada ukuran tabel sebanding dengan sisa tabel, pertimbangkan membangun filegroup untuk masing-masing tabel
• Ketika indeks non-clustered dan ruang data sama pada tabel besar
  • Jika demikian, pertimbangkan untuk memisahkan data dan indeks berkerumun dari indeks yang tidak berkerumun
• Ketika persentase yang hampir sama dari data read-only dan read-write ada dalam database
  • Jika ini masalahnya, pertimbangkan untuk membagi data read-only dalam filegroup terpisah sebagai data read-write
• Ketika tidak cukup waktu tersedia untuk melakukan pemeliharaan basis data
  • Jika ini masalahnya, pertimbangkan untuk membagi tabel besar menjadi grup-grup terpisah pada disk-disk dasar yang berbeda dan melakukan perawatan secara paralel
• Ketika bisnis atau aplikasi akan berubah secara signifikan dan data akan tumbuh pada tingkat yang jauh lebih tinggi
  • Jika ini masalahnya, pertimbangkan bekerja dengan pengguna untuk memahami potensi pertumbuhan
• Ketika data yang diarsipkan berada di database yang sama dengan data produksi
  • Jika demikian, pertimbangkan grup file terpisah atau satu atau lebih teknik dalam tip ini - Pengarsipan Data dalam SQL Server

Jika Anda menemukan bahwa filegroup dapat meningkatkan kinerja basis data Anda, tulis kode dan uji prosesnya dalam lingkungan pementasan sebelum Anda menerapkan perubahan pada server produksi Anda. Persiapkan beberapa pengukuran sebelum Anda menerapkan perubahan dan membandingkannya sebelum / sesudah. Karena proses ini dapat menjadi sangat intensif sumber daya dan memakan waktu, lakukan prosedur ini selama masa pemeliharaan.

Jangan lupa, saat membuat objek baru (tabel dan indeks), pastikan bahwa objek tersebut dibuat dalam grup grup yang benar untuk memastikan kinerja yang diharapkan dan secara berkala memvalidasi objek database dalam grup grup yang benar dan koreksi sesuai kebutuhan.