Сервер Sql - найкращі практики для вирощування файлів баз даних

Я спостерігаю за зростанням файлів за допомогою колектора даних на сервері sql 2008 r2 протягом двох тижнів. База даних постійно зростає близько 35 (МБ) / день. БД ще не досяг початкового розміру 2 Гб.

Автоматичне зростання файлів БД встановлено на 5 МБ, і я хотів би спробувати інший підхід, тому я шукаю пропозиції та коментарі.

Існує завдання з налаштування, яке виконується щотижня в ніч на неділю о 1:30 ранку. Завдання:

• Перевірте цілісність бази даних
• Зменшити файл журналу - (це нормально, оскільки режим ведення журналу простий)
• Зменшити базу даних
• Реорганізувати індекс
• Перебудувати індекс
• Оновити статистику
• Очищення історії

Я хотів би додати ще два кроки до плану щотижневої настройки:

1. Зростіть файл бази даних на 500 МБ, якщо використаний простір досягає певного порогу або загального розміру.
2. Зростіть файл журналу на 250 МБ (після зменшення), якщо використаний простір досягає певного порогу загального розміру.

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

У мене є два питання, що стосуються файлів автоматичного зростання.

• Найкраще розмістити кроки росту файлів - до поточних кроків чи після?
• Якщо я використовую ALTER DATABASE|MODIFY FILEдля вирощування файлу, то як я можу визначити, чи є SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)?

Ви повинні прагнути якнайшвидшого автоматичного зростання. Сім разів на день викликає біль, навіть при миттєвій ініціалізації файлів.

Не робіть бази скорочення. Колись. Стислий файл, можливо, але лише після надзвичайної події. Скорочення його лише для того, щоб знову вирости - це вправність у марності, і насправді його слід називати авто-фрагментом.

Якщо модель відновлення проста, на землі немає жодного способу, вам потрібно буде збільшити файл журналу на 250 ГБ. Використовуваний простір у файлі автоматично очиститься з часом, якщо ви не розпочали транзакцію місяць тому і не маєте наміру ніколи вчиняти її, ні повертати назад.

Тож моя порада буде:

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

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

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

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

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

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

SELECT instance_name,
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
       into ##Logsize
FROM
(
   SELECT *
   FROM sys.dm_os_performance_counters
   WHERE counter_name IN
   (
       'Data File(s) Size (KB)',
       'Log File(s) Size (KB)',
       'Log File(s) Used Size (KB)',
       'Percent Log Used'
   )
     AND instance_name = 'database your interested in' 
) AS Src
PIVOT
(
   MAX(cntr_value)
   FOR counter_name IN
   (
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
   )
) AS pvt 
go
declare @logsize int
Select @logsize = [Percent Log Used] from ##Logsize

If @logsize > the maximum percent you want the log to fill too i.e 90
    BEGIN
        --Do your thing here
    END

Drop table ##Logsize

Звичайно, це можна запланувати як роботу.