ПРОСТА чи ПОВНА модель відновлення для баз даних?

Коли я повинен використовувати повну модель відновлення і коли я повинен використовувати просту модель відновлення для баз даних?

Я завжди використовував повну модель відновлення, оскільки це за замовчуванням, але сьогодні я зіткнувся з цією помилкою:

Постачальник баз даних Microsoft OLE для SQL Server (0x80040E14) Журнал транзакцій для бази даних "ІМЯ ДАТАБАЗИ" заповнений. Щоб дізнатися, чому простір у журналі не можна повторно використовувати, перегляньте стовпець log_reuse_wait_desc у sys.databases

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

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

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

Це допомогло, але тепер мені потрібно зрозуміти, ЧОМУ це допомогло, ЯК така ситуація почалася і ЯК запобігти цьому в майбутньому?

Редагувати:

Щовечора о 1 годині ми робимо сценарій резервного копіювання кожної бази даних на сервері. Це робиться за сценарієм 31 рядок, де є найважливіша частина

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

Чи буде нова модель відновлення та зшивання баз даних конфліктувати з цим сценарієм?

Ми не робимо жодного іншого резервного копіювання баз даних, а отже, не журналів транзакцій, чи не так?

Коли я повинен використовувати повну модель відновлення і коли я повинен використовувати просту модель відновлення для баз даних?

Ви повинні використовувати повну модель відновлення, коли вам потрібно буде своєчасно відновити вашу базу даних. Ви повинні використовувати просту модель відновлення тоді, коли вам не потрібно одразу відновити вашу базу даних і коли остання повна або диференціальна резервна копія є достатньою для точки відновлення. (Примітка. Існує інша модель відновлення з масовим входом. Докладнішу інформацію про модель відновлення в груповому режимі див. У цьому посиланні )

Постачальник баз даних Microsoft OLE для SQL Server (0x80040E14) Журнал транзакцій для бази даних "ІМЯ ДАТАБАЗИ" заповнений. Щоб дізнатися, чому простір у журналі не можна повторно використовувати, перегляньте стовпець log_reuse_wait_desc у sys.databases

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

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

......

Це допомогло, але тепер мені потрібно зрозуміти ЧОМУ це допомогло, ЯК така ситуація почалася і ЯК запобігти цьому в майбутньому?

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

Уривок / цитата, взята з цієї довідки MSDN :

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

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

Читання варто витратити трохи часу на:

1. Моделі відновлення
2. Керування журналами транзакцій (Gail Shaw)
3. Фактори, які можуть затримати скорочення журналу

РЕДАКТУВАТИ після редагування :

Чи буде нова модель відновлення та зшивання баз даних конфліктувати з цим сценарієм?

Ця BACKUP DATABASEкоманда буде працювати з будь-якими моделями відновлення. Щодо звичайної скорочення бази даних ... НЕ РОБИТИ !!!! Серйозно розміріть свою базу даних відповідно, і якщо ви використовуєте повну модель відновлення, то переконайтеся, що ви робите звичайні та часті файли журналу транзакцій, а не просто для збереження розміру журналу транзакцій, але і для задоволення об'єктів точки відновлення.

Ми не робимо жодного іншого резервного копіювання баз даних, а отже, не журналів транзакцій, чи не так?

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

Що стосується того, яку модель відновлення використовувати (проста проти повної), ми не можемо прийняти це рішення за вас. Тільки ви, ваша бізнес-команда та ваші угоди про домовленості у угоді можуть.