Обслуговування журналу транзакцій при переході до простого відновлення

Фон:

Нещодавно я успадкував 50+ SQL серверів із 450+ базами даних. Нічні резервні копії становлять приблизно 8 ТБ, і, що вже говорити, ми використовуємо більше дискового простору, ніж нам би хотілося. Усі бази даних встановлені на повне відновлення, а журнали транзакцій ніколи не створювалися резервними копіями. Я пройшов усі сервери SQL і виявив ті, що мають низький пріоритет, для яких потрібна лише нічна резервна копія і де прийнятний день втрати даних.

Питання:

Я перемикаю багато баз даних з низьким пріоритетом у SIMPLEрежим відновлення FULL. Чи будуть усічені журнали транзакцій усічені (коли створені контрольні точки)? Деякі з існуючих журналів транзакцій є 50-100 ГБ; який найкращий підхід у визначенні того, до чого я повинен їх зменшити, щоб рухатися вперед? Я, очевидно, не хочу залишати їх такими великими. Або вони згодом скоротяться самостійно (я не думаю, що будуть)?

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

Щоб зменшити LDFфайл до максимально можливого розміру, виконайте кроки Кімберлі Тріпп тут: 8 кроків для покращення пропускної здатності журналу транзакцій

1. Зачекайте часу, коли в базі даних низька активність

2. Запуск у SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Змініть розмір файлу журналу транзакцій:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Я перемикаю багато баз даних у ПРОСТИЙ режим відновлення з режиму ПОВНОГО відновлення (T-журнали та відновлення моменту часу не потрібні). Чи будуть усічені журнали транзакцій усічені (коли створені контрольні точки)?

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

Якщо у вас не відбудуться тривалі операції, які затримають усічення журналу, автоматична контрольна точка буде усікати невикористану частину T-журналу.

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

Якщо у вас модель відновлення бази даних встановлена ​​на ПОПУСКУ для цієї бази даних з 50-100 ГБ T-журналів, вам доведеться почати робити часті резервні копії T-журналів. Пам'ятайте, що в повній моделі відновлення після встановлення ланцюга резервного копіювання журналу навіть автоматичні контрольні точки не змусять журнал усікати.

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

Або вони згодом скоротяться самостійно (я не думаю, що будуть)?

Як вказував @TomTom, це ручна робота.

Прочитайте:

• Управління розміром файлу журналу транзакцій
• ЯК ПОРУЧИТИ ЛОГІЙ SQL SERVER - Відмінно запишіться.
• Як працюють контрольно-пропускні пункти і що відбувається реєстрація - Автор: Пол Рандал

На багато питань ми не можемо відповісти. Як довгий шматок струни?

Деякі з існуючих журналів транзакцій мають розмір 50-100 ГБ, що є найкращим підходом до визначення того, до чого я повинен їх зменшити, щоб рухатися вперед.

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

Нічні резервні копії становлять приблизно 8 ТБ і не потрібно говорити, що ми використовуємо більше дискового простору, ніж нам би хотілося.

То навіщо перетворювати їх на прості? Я маю на увазі, серйозно.

Усі бази даних встановлені на повне відновлення, а журнали транзакцій ніколи не створювалися резервними копіями.

Трохи логіки підкаже вам, що якщо ви будете усікати їх, то ви, швидше за все, використовуватимете МНОГО менше місця для резервного копіювання їх у будь-якому випадку. Результатом може бути те, що ви цілком можете тримати їх у повному режимі відновлення. Спробуйте це спочатку. Якщо вони зібрані з низьким рівнем гучності тощо, тоді в майбутньому резервні копії журналу будуть набагато меншими.

Я пройшов усі сервери SQL та визначив низькі пріоритетні, для яких потрібна лише нічна резервна копія та втрата даних на день, навіть у випадку катастрофи, не буде проблемою (бази даних факсів тощо).

Так. Це до тих пір, поки ви не опинитеся в суді і не здасте дупу за відсутність критичних юридичних документів. Чи знаєте ви, що журнали факсів можуть бути частиною того, що ви повинні зберігати роками як релевантну для бізнесу інформацію? Це так у моїй юрисдикції (10 років). Якщо ви є акціонерною компанією U, там можуть бути схожі здивування (SOX). Якщо цього не зробити, це ДУЖЕ погано в суді, якщо ви хочете довести, що ви не отримали факсу. Або надіслав один. Нікого не цікавить, чи це сталося щомісяця назад, і у вас є новіші журнали - ви не відповідаєте вимогам закону. Переконайтеся, що це підписано ДУЖЕ високо, адже ваш бізнес не є критичним.

Або вони згодом скоротяться самостійно (я не думаю, що будуть)?

Ні. І вони не повинні цього робити. Повторне розміщення журналу - це ручна операція, за винятком баз даних з невеликим обсягом.