Коли база даних SQL Server знаходиться в простому режимі, вам не доведеться дбати про накопичення журналу транзакцій. Але в простому режимі журнал транзакцій, схоже, зростає, як і в ПОВНОМУ режимі. Чи врізається автоматично в якийсь момент часу? Або я повинен обрізати / зменшити її вручну?
Відповіді:
Він скорочується автоматично, але це дуже різко зменшиться. Урізання повертає простір журналу для повторного використання, зменшення фізично зменшує розмір файлу, щоб звільнити простір назад в ОС. Якщо ваш журнал виріс до свого поточного розміру, ймовірно, що він знову зросте, якщо ви його зменшите.
Я б запропонував ознайомитись із типовим та максимальним використанням журналу для вашої системи. Поданий нижче запит (не мій, підсилений із сценаріїв DMV Glen Berrys) можна запустити вручну або ви можете зафіксувати висновок до таблиці за допомогою завдання агента. Якщо ви впишете його в таблицю протягом тижня або близько того, ви отримаєте зображення типового використання і, що ще важливіше, коли процес змушує журнал зростати понад те, що ви очікуєте.
SELECT
db.[name] AS [Database Name]
, db.recovery_model_desc AS [Recovery Model]
, db.log_reuse_wait_desc AS [Log Reuse Wait Description]
, ls.cntr_value AS [Log Size (KB)]
, lu.cntr_value AS [Log Used (KB)]
, CAST(
CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)
AS DECIMAL(18,2)
) * 100 AS [Log Used %]
, db.[compatibility_level] AS [DB Compatibility Level]
, db.page_verify_option_desc AS [Page Verify Option]
, db.is_auto_create_stats_on, db.is_auto_update_stats_on
, db.is_auto_update_stats_async_on, db.is_parameterization_forced
, db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%'
AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
AND ls.cntr_value > 0
OPTION (RECOMPILE);Укорочення журналу транзакцій описує, коли і чому відбувається усічення журналу.
Якщо записи журналів ніколи не були видалені з журналу транзакцій, він врешті заповнить все дискове місце, доступне для фізичних файлів журналу. Укорочення журналу автоматично звільняє простір у логічному журналі для повторного використання журналом транзакцій.
Фактори, які можуть затримати скорочення журналу, є корисним посиланням для розуміння того, чому ваш журнал може не врізатися і тому зростати більшими, ніж очікувалося.
Як вже було сказано раніше, ні це автоматично не скоротиться. Однак прибиратиме сміття.
Причина полягає в тому, що в повній моделі відновлення ви говорите SQL, що ви хочете робити резервні копії для відновлення поточного часу, таким чином він зберігає запис про всі транзакції, здійснені проти бази даних.
Оскільки ви говорите йому, що вам хочеться відновити час, вам потрібно зробити повні резервні копії та реєструвати резервні копії. Коли ви закінчите резервні копії tlog, він змиє вміст журналу (крім хвостового кінця) і почне спочатку.
Це може допомогти, якщо ви вважаєте ці файли контейнерами.
Моя пропозиція: якщо облоги стали великими і некерованими, виріжте повну резервну копію. Перемикання в SIMPLE відновлення моделі і SHRINK файл TLOG. Поверніться до повної моделі відновлення та виконайте обслуговування фрагментації *. Як і інші, хто опублікував це, це не найкраща практика і призведе до високого рівня фрагментації.
Плануйте і розпочніть резервний режим після цього.
* Операції перебудови / реорганізації операцій та дефрагментації рівня диска . Це не є частиною обслуговування журналу: ви зберігаєте свої T журнали, створюючи резервну копію. Це контейнери, які виростають, коли вони наближаються до місткості. Перебудова / реорганізація може допомогти відновитись після неправильного управління журналом, що призводить до великого використання накопичувача.