SQL Server 2005/2008 - кілька файлів / груп файлів - скільки? Чому?

Я по душі розробник - але раз у раз у замовника немає пристойної DBA для вирішення цих питань, тому я закликаний вирішити ....

Які ваші стратегії / найкращі практики, коли мова заходить про роботу з базами даних SQL Server із досить великим розміром (що-небудь більше, ніж Northwind або AdventureWorks; приблизно 2–4 ГБ даних плюс індекси тощо) - чи використовуєте ви кілька файлів / груп файлів?

Якщо так: скільки? І чому?

Які ваші критерії, щоб вирішити, коли відійти від підходу "одна файлова група на все":

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

Якщо ви використовуєте кілька груп файлів, скільки ви використовуєте? Один для даних, один для індексу, один для журналу? Кілька (скільки) для даних? Які причини вашого вибору - чому ви використовуєте саме таку кількість груп файлів :-)

Дякуємо за будь-які підказки, вказівки, думки!

Ура, Марк

Основне правило - розділити файли на різні томи, щоб уникнути суперечок, однак кількість отриманих результатів, які ви отримуєте, різко змінюється залежно від підсистеми вводу / виводу та навантаження. Наприклад, декілька файлів на одному фізичному шпинделі будуть засмоктуватись, наскільки продуктивність, але однакова композиція з обсягом, що знаходиться на SAN LUN з кількома сотнями накопичувачів з масивів RAID 10, може бути просто чудово. Лічильники довжини черги дисків - ваш друг як найпростіший спосіб визначити, чи є у вас вузьке місце вводу / виводу.

Ви дивитеся на шаблони вводу-виводу в базах даних - лише для читання, в основному для читання, для читання-запису, переважно для запису, лише для запису - і базуєте на цьому речі. Вам також потрібно вибрати правильний рівень RAID і переконатися, що ваш зсув розділу диска, розмір смуги RAID та розмір одиниці розподілу NTFS правильно встановлені. Деякі люди хочуть розділяти некластеризовані індекси на окрему файлову групу, але підвищення продуктивності тут змінюється так само, як я пояснював вище.

Окрім продуктивності, слід враховувати керованість та відновлення. Наявність єдиного монолітного файлу даних для бази даних 100 ГБ означає, що ваш файл відновлення - це файл. Розділивши його на 4 групи файлів розміром 25 ГБ, ви можете використовувати часткову доступність бази даних та відновлювати частинку, щоб відновити лише одну файлову групу лише у випадку її пошкодження. За допомогою таблиць розділів та індексів у декількох групах файлів ви також можете обмежити, на які частини бази даних впливають операції технічного обслуговування (наприклад, видалення фрагментації індексу).

Tempdb - це зовсім окремий випадок, і я накажу вам на своєму блозі, в якому пояснюється все про те, чому і як розділити tempdb - там є багато помилок.

Не даючи вам тут рекомендації щодо "узагальнюючого узагальнення", я вкажу вам на купу білих повідомлень і публікацій в блозі, які ви можете прочитати:

• Довідка: Дизайн зберігання фізичних баз даних
• Технічний опис: перед розгортанням I / O Best Practices
• Довідка: Розділені таблиці та індекси у SQL Server 2005

• Довідка: Часткова доступність бази даних

• Повідомлення в блозі: Помилкові уявлення про TF 1118 (макет tempdb)

• Повідомлення в блозі: чи правильно встановлені компенсації розділу диска, розміри смуг RAID та одиниці розподілу NTFS? (із посиланням на папір розділу розділу диска)

Сподіваюся, це допоможе вам!

Рішення про поділ бази даних на різні групи файлів слід приймати після аналізу поточного розміру та майбутнього зростання ваших таблиць. На мою думку, якщо у вас є велика база даних або таблиці з мільйонами рядків, ви повинні ретельно обміркувати плюси і мінуси, оскільки ви, в кінцевому підсумку, можете створити більше проблем з продуктивністю, ніж виправите.

Є деякі сценарії, які можуть бути цікавими в певних приміщеннях:

• 2 групи файлів: дані та індекс
• 3 групи файлів: таблиці лише для читання, таблиці для читання та запису, індекс
• декілька груп файлів: лише для читання, читання-запису, індексу, ключової таблиці 1, ключової таблиці 2, ...

Ви повинні проаналізувати своє оточення, щоб вирішити, чи допоможуть групи файлів у ваших потребах зростання, використання та продуктивності SQL Server.

Деякі основні показники для переміщення до кількох файлових груп (з цієї статті ):

• Коли чергування дисків викликає проблеми із програмою та користувачем
  • Якщо це так, розгляньте можливість використання додаткових дискових накопичувачів за допомогою нових файлових груп, що містять інтенсивні таблиці IO
• Коли конкретні таблиці складають 10% або більше бази даних
  • Якщо це так, розгляньте можливість переміщення цих особливо великих таблиць у окремі групи файлів на окремих базових дисках
  • Залежно від розміру таблиці пропорційно решті таблиць, розгляньте можливість створення групи файлів для окремих таблиць
• Якщо некластеризований простір індексів та даних є рівним у великих таблицях
  • Якщо це так, розглянемо розбиття даних та кластерний індекс від некластеризованих індексів
• Коли в базі даних існує майже рівний відсоток даних лише для читання і запису
  • Якщо це так, розгляньте розділення даних лише для читання в окремій групі файлів як дані для читання-запису
• Коли не вистачає часу для обслуговування баз даних
  • Якщо це так, розгляньте розділення великих таблиць на окремі файлові групи на різних базових дисках та виконайте технічне обслуговування паралельно
• Коли бізнес або додаток значно зміниться, і дані будуть рости значно більшими темпами
  • Якщо це так, розгляньте можливість співпраці з користувачами, щоб зрозуміти потенційний ріст
• Коли архівовані дані знаходяться в тій же базі даних, що і виробничі дані
  • Якщо це так, розгляньте окремі групи файлів або одну або декілька методів у цій підказці - Архівування даних у SQL Server

Якщо ви виявите, що групи файлів могли б покращити продуктивність вашої бази даних, напишіть код і протестуйте процес у стадійному середовищі, перш ніж застосовувати зміни на своїх виробничих серверах. Підготуйте деякі вимірювання, перш ніж впровадити зміни та порівняйте їх до / після. Оскільки ці процеси можуть бути дуже трудомісткими та забирати багато часу, виконайте ці процедури протягом періоду технічного обслуговування.

Не забувайте, створюючи нові об’єкти (таблиці та індекси), будьте впевнені, що об’єкти створені у правильній групі файлів, щоб забезпечити очікувану продуктивність та періодично перевіряти, що об’єкти бази даних знаходяться у правильних файлових групах та виправляйте за потребою.