Скорочення файлу журналу не зменшує розмір

У мене є база даних, що містить 350 МБ файлів даних (.mdf) та файл журналу 4,9 ГБ (.ldf). Модель відновлення встановлена ​​на FULL.

Коли я намагаюся зменшити файл журналу, він не скорочується.

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

Коли я бігав

DBCC SQLPerf(logspace) 

Я виявив, що розмір журналу становить 4932 МБ, а використаний простір журналу - 98,76% !

Тоді я спробував цю команду

USE <databasename>;
DBCC loginfo;

Зараз майже всі VLF є "статусом 2", що означає, що всі використовуються.

Я спробував зробити резервну копію журналу, а потім зменшити файл журналу. Скорочення не зменшило розмір.

Я змінив модель відновлення SIMPLEі знову спробував скоротитись, але це також не допомогло.

Я перевірив на наявність відкритих транзакцій

DBCC opentran (database);

і виявив, що наразі жодна транзакція не відкрита.

Що заважає мені скорочувати файл журналу? Як я можу це вирішити?

Ось відповідь на моє власне питання.

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

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

Я отримав такий результат:

log_reuse_wait_desc
-------------------
REPLICATION 

В базі даних залишилися деякі об'єкти, пов'язані з реплікацією, навіть після видалення реплікації.

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

Рішенням було імпортувати вміст бази даних до іншої бази даних, використовуючи опцію імпорту SQL Server.

Кроки для усадки колоди не будуть

Реєструйте журнал транзакцій через SSMS або T-SQL, а потім виконайте зменшення

команди для SSMS знаходяться під завданнями, якщо ви клацніть правою кнопкою миші ім'я бази даних

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

Вам, мабуть, доведеться це робити кілька разів

Якщо транзакція або завдання блокують дію, використовуйте монітор активності, щоб визначити процес та знищити його, або використовуйте монітор активності завдання SQL Agent, щоб закінчити завдання.

джерело: http://support.microsoft.com/kb/907511

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

Спочатку потрібно створити резервну копію, залежно від моделі резервного копіювання, яка встановлена ​​для бази даних, перш ніж ви зможете зменшити базу даних.

Ви можете спробувати це запустити:

USE <databasename>
GO

BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO

Або ви можете зробити це з SSMS та скористатися наявними графічними інструментами (детальніше див. Тут: http://msdn.microsoft.com/en-us/library/ms187510.aspx )

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

Сподіваюся, це допомагає.

Я виявив, що мені потрібно виконати 2 або 3 резервних копій як бази даних, так і журналу транзакцій, щоб журнал транзакцій фактично зменшився в розмірі. У мене є база даних, яка була створена за допомогою моделі повного відновлення. Щовечора він виконує резервні копії бази даних та журналу транзакцій, але неминуче журнал транзакцій, здається, постійно зростає протягом 2-3 тижнів. Коли залишився диск на 1 ГБ, я побачу, що журнал транзакцій становить близько 30 ГБ. Я дотримувався кроків, рекомендованих корпорацією Майкрософт, і після 4-ї чи 5-ї ітерацій резервного копіювання як бази даних, так і журналу транзакцій журнал трансакцій остаточно звільнить зайве місце та зменшиться. Потім я повертаюсь назад і видаляю кілька створених резервних копій.

Моя робота над Реплікацією, яка блокує файл журналу, що скорочується:

1. Встановіть модель відновлення БД простою
2. Візьміть DB офлайн
3. Створіть резервну копію файлу журналу (про всяк випадок)
4. Видалити файл журналу
5. Донесіть DB до Інтернету

У моєму випадку це спрацювало. Після залучення БД онлайн-журнал був створений автоматично і його розмір склав 512 Кб замість 70 ГБ. Але це лише обхідне рішення. Коренева проблема не вирішена. У моєму випадку ми використовуємо реплікацію.