Найкращий спосіб резервного копіювання та скорочення журналів транзакцій за графіком

Я не DBA, але, будучи такими, якими вони є, я повинен носити шапку DBA і створювати плани обслуговування для мого екземпляра SQL Server.

Тому деякий час у мене в режимі SSIS протягом ночі виконується завдання Execute SQL для виконання резервних копій - в основному працює master.dbo.xp_create_subdirдля забезпечення існування папок призначення, а потім BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

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

Сценарій "ручного скорочення" виглядає так:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Так що я втомилася від цього, і я вирішив спробувати і зробити речі правильно замість цього, і виконуйте вказівки , наведеним тут і створити реальний план обслуговування :

Справа в тому, що я ніколи цього не робив, тому у мене є кілька питань:

• Чи створить резервне копіювання таких журналів транзакцій автоматично усічення, або мені потрібно щось ще зробити?
• Чи добре одночасно запускати резервні копії даних та журналів транзакцій? Якщо ні, то який правильний спосіб зробити це?
• Файли резервного копіювання збираються протягом ночі іншим процесом, який захоплює всі файли на сервері та зберігає їх в іншому місці - чи було б гарною ідеєю закінчити набір резервних копій через 2 дні? Чи потрібно, щоб вони взагалі закінчились?
• Завдання очищення відповідно видаляють "старі" файли .bak і .trn під папками G:\Backups. Чи має це сенс?
• Було б краще зробити це в SSIS, тому я можу зірвати свій ETL, якщо / коли резервні копії не вдаються? Або мій процес ETL навіть турбує?

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

Лише протягом ночі SSIS пише записи, вдень все читається - мені потрібно лише щоденне відновлення.

Ви повинні вибрати модель відновлення, виходячи з потреб вашого бізнесу:

• Скільки даних може втратити і одночасно вижити?

Виходячи з вищенаведеної відповіді, слід ретельно вибрати модель відновлення бази даних .

Простіше кажучи (не обговорюючи модель відновлення з масовою реєстрацією) ,

• Повна модель відновлення дозволяє створювати резервні копії журналу, що дозволяє здійснювати точне час відновлення.
  • Урізання журналу може статися, коли ви берете резервні копії журналу транзакцій, тобто простір файлів журналу буде повторно використаний після кожної резервної копії журналу та звичайного розширення!
• Проста модель відновлення дозволяє лише робити ПОЛІ резервні копії. Точне відновлення неможливо.
  • Урізання журналу може відбуватися лише тоді, коли відбувається контрольна точка (вручну або автоматично), тобто, якщо ви робите регулярні повні резервні копії, вам не доведеться турбуватися про журнал транзакцій, оскільки CHECKPOINT піклується про повторне використання неактивної частини файлу журналу.

Пам'ятайте, що усічення журналу НЕ фізичне зменшення розміру файлу журналу транзакцій. Це означає, що неактивна частина файлу журналу транзакцій позначена як багаторазова .

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

Я б настійно пропонував би вам скласти плани технічного обслуговування та виконувати [розумне рішення з технічного обслуговування - це легко, гнучко та слідкує за найкращими методами] - 5 . - Резервне копіювання рішення Ola (і рішення щодо технічного обслуговування Index ).

дозволяє вирішити ваші запитання:

Чи створить резервне копіювання таких журналів транзакцій автоматично усічення, або мені потрібно щось ще зробити?

Будь ласка, не додайте резервні копії та не встановлюйте їх термін дії. Вони створюють великий безлад. Використовуйте INITта приймайте окремі резервні копії журналу з печаткою дати. Легкий в обслуговуванні. Використовуйте для цього резервне рішення Ola. Рішення є гнучким і для видалення старих резервних копій.

Чи добре одночасно запускати резервні копії даних та журналів транзакцій? Якщо ні, то який правильний спосіб зробити це?

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

Крім того, резервне копіювання журналу під час повної резервної копії не уріже журнал транзакцій. Резервне копіювання журналу (пара) після завершення повної резервної копії журналу буде усічене.

Файли резервного копіювання збираються протягом ночі іншим процесом, який захоплює всі файли на сервері та зберігає їх в іншому місці - чи було б гарною ідеєю закінчити набір резервних копій через 2 дні? Чи потрібно, щоб вони взагалі закінчились?

Завдання очищення відповідно видаліть "старі" файли .bak та .trn під папками G: \ Резервні копії. Чи має це сенс? Було б краще зробити це в SSIS, тому я можу зірвати свій ETL, якщо / коли резервні копії не вдаються? Або мій процес ETL навіть турбує?

Для обох вище, використовуйте рішення щодо обслуговування резервного копіювання Ola. Він подбає про видалення старих файлів.