Журнал SQL Server 2008 не будет усекаться

Question

Я считаю себя очень опытным человеком SQL. Но я не могу сделать эти две вещи:

• Уменьшить размер выделенного журнала.

• Усечение журнала.

  DBCC sqlperf (пространство журнала)

возвращается:

Database Name   Log Size (MB)   Log Space Used (%)  Status
ByBox       1964.25     30.0657         0

Следующее не работает с SQL 2008

DUMP TRANSACTION ByBox WITH TRUNCATE_ONLY

Выполнение следующего ничего не делает

DBCC SHRINKFILE ('ByBox_1_Log' , 1)
DBCC shrinkdatabase(N'bybox')

Я пробовал резервные копии. Я также попытался установить для свойств базы данных - «Восстановить модель» значения «ПОЛНЫЙ» и «ПРОСТОЙ», а также комбинацию всего вышеперечисленного. Я также попытался установить совместимость с SQL Server 2005 (я использую этот параметр, так как я хочу соответствовать нашему производственному серверу) и SQL Server 2008.

Независимо от того, что я пытаюсь, журнал остается на 1964,25 МБ, используется 30%, и он продолжает расти.

Я бы хотел, чтобы журнал вернулся на 0% и уменьшил размер файла журнала, скажем, до 100 МБ, что вполне достаточно. Моя база данных должна ненавидеть меня; он просто игнорирует все, что я прошу сделать с журналом.

Еще одно замечание. В производственной базе данных имеется довольно много реплицированных таблиц, которые я отключаю, когда выполняю восстановление своего блока разработки с помощью следующего:

-- Clear out pending replication stuff
exec sp_removedbreplication
go
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL,
     @numtrans = 0, @time = 0, @reset = 1
go

Попытка:

SELECT log_reuse_wait, log_reuse_wait_desc
FROM sys.databases
WHERE NAME='bybox'

Возвращает

log_reuse_wait  log_reuse_wait_desc
0   NOTHING

Как я могу исправить эту проблему?

---

Глядя на это и устанавливая модель восстановления в ПОЛНОЕ Я пробовал следующее:

USE master
GO

EXEC sp_addumpdevice 'disk', 'ByBoxData', N'C:\<path here>\bybox.bak'

-- Create a logical backup device, ByBoxLog.
EXEC sp_addumpdevice 'disk', 'ByBoxLog', N'C:\<path here>\bybox_log.bak'

-- Back up the full bybox database.
BACKUP DATABASE bybox TO ByBoxData

-- Back up the bybox log.
BACKUP LOG bybox TO ByBoxLog

которые вернули:

Processed 151800 pages for database 'bybox', file 'ByBox_Data' on file 3.
Processed 12256 pages for database 'bybox', file 'ByBox_Secondary' on file 3.
Processed 1 pages for database 'bybox', file 'ByBox_1_Log' on file 3.
BACKUP DATABASE successfully processed 164057 pages in 35.456 seconds (36.148 MB/sec).

Processed 2 pages for database 'bybox', file 'ByBox_1_Log' on file 4.
BACKUP LOG successfully processed 2 pages in 0.056 seconds (0.252 MB/sec).

Отлично! Но это не так.

И DBCC SHRINKFILE ('ByBox_1_Log', 1) теперь возвращается с

DbId    FileId  CurrentSize MinimumSize UsedPages   EstimatedPages
7   2   251425  251425  251424  251424

и DBCC SQLPERF (LOGSPACE) по-прежнему сообщает об использовании 30%.

Я думаю, что мне, возможно, придется смириться с тем фактом, что в SQL Server 2008 вполне может быть ошибка или что мой файл журнала каким-то образом поврежден. Тем не менее, моя база данных находится в хорошем рабочем состоянии, что заставляет меня думать, что есть ошибка (содрогается при мысли) .

Answer 1

В моей ситуации у меня была база данных на 650 МБ с файлом журнала на 370 ГБ в SQL Server 2008. Независимо от того, что я пробовал, я не смог заставить его сжаться. Я попробовал все перечисленное здесь как ответы, но все равно ничего не получилось.

Наконец, я нашел очень короткий комментарий в другом месте, который работал. Это запустить это:

BACKUP LOG DatabaseName TO DISK = N'D:\Backup\DatabaseName_log.bak'
GO
DBCC SHRINKFILE('MyDatabase_Log', 1)
GO

Это привело к уменьшению размера файла журнала с 37 ГБ до 1 МБ. Уф!

Answer 2

Я нашел DBCC SHRINKFILE (Transact-SQL) (MSDN).

В следующем примере файл журнала в базе данных AdventureWorks сжимается до 1 МБ. Чтобы позволить команде DBCC SHRINKFILE сжать файл, файл сначала усекается путем установки модели восстановления базы данных на SIMPLE.

USE AdventureWorks;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks
SET RECOVERY FULL;
GO

Answer 3

Остерегайтесь последствий изменения моделей восстановления !!

А теперь еще одна трезвая мысль для всех вас производство администраторы баз данных , думающих об использовании сценария:

ПЕРЕД ИЗМЕНЕНИЕМ МОДЕЛИ ВОССТАНОВЛЕНИЯ ОТ ПОЛНОЙ К ПРОСТОЙ ... не беспокойтесь, если вы находитесь в среде разработки / QA . Но если вы находитесь в производственной среде, где вы несете ответственность за обеспечение полного восстановления данных в случае возникновения проблемы, вы можете поближе взглянуть на то, что BOL говорит об этом (см. BOL в разделе «Управление базами данных»). "->" Управление журналом транзакций "->" Модели восстановления и управление журналом транзакций "):

База данных может быть переключена на другую модель восстановления в любое время. Однако переход от простой модели восстановления кроется в необычности. Помните, что если вы переключитесь на модель полного восстановления во время массовой операции, запись массовой операции изменится с минимальной регистрации на полную, и наоборот.

После переключения с простой модели восстановления

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

После перехода на простую модель восстановления

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

В самом деле? « Мы настоятельно рекомендуем сделать резервную копию журнала непосредственно перед переключением, что позволяет восстановить базу данных до этого момента. « Я не могу понять, почему это мало Небольшая часть информации скрыта в разделе «После перехода к простой модели восстановления», заставляя большинство «нормальных людей» думать, что они могут пойти дальше и переключить ее, а затем продолжить или вернуться и прочитать это после изменения.

Рант

Майкрософт: Итак, пожалуйста, исправьте меня, если я ошибаюсь, если я не смогу выполнить резервное копирование t-журнала ПЕРЕД изменением с ПОЛНОГО на ПРОСТОЙ, и вот, моя база данных как-то повреждена (когда-либо слышал о Мерфи закон ?) прямо перед тем, как я смогу сделать резервную копию ... тогда я облажался, верно? Если переключение модели восстановления моей **** производственной **** базы данных с ПОЛНОГО на ПРОСТОЙ может привести к разрыву цепочки журналов резервного копирования, так что, если мне не удастся сделать резервную копию журнала транзакций перед этим (как это было предложено выше) Потенциально я потеряю данные , тогда ПОЧЕМУ ЧЕРТ ВЫ НЕ ВЫЯВЛЯЕТЕ, ЧТО В МЫШЛОМ МАРКИ ДЕЛАЕТЕ БОЛЬШЕ ДЕЛО, чем вы, кажется, ??! Вы должны буквально схватить меня за рубашку и дать мне пощечину, чтобы привлечь мое внимание (так сказать), и предупредить меня о важности этого UPFRONT !!

Answer 4

Другой простой способ уменьшить размер файла журнала:

• Резервное копирование журналов
• Полная резервная копия базы данных
• Сжатие файла журнала
• Резервное копирование журналов снова
• Сжать файл журнала еще раз

Таким образом, вам не нужно изменять какие-либо параметры базы данных, а размер файла журнала составляет 1 МБ.

Answer 5

Нашли решение!

Я добавил данные в базу данных, поэтому журнал был вынужден расширяться. Затем я удалил ненужные данные, чтобы вернуть базу данных в прежнее состояние.

Резервное копирование и вуаля, идеальный 0% журнал.

Таким образом, решение заключается в расширении журнала.

Answer 6

Я всегда ненавидел то, как SQL Server обрабатывает физическое сжатие файлов журнала. Обратите внимание, что я всегда делал это через Enterprise Manager / SQL Server Management Studio, но кажется, что когда вы уменьшаете / усекаете файл журнала, физический размер файла журнала не уменьшается до тех пор, пока не будет выполнено полное резервное копирование базы данных файл данных, а затем снова создайте резервную копию файла журнала. Я никогда не смогу определить точную схему, но вы могли бы попытаться увидеть, какова точная последовательность. Однако это всегда включало создание полной резервной копии файла данных.

Answer 7

Наконец-то я нашел решение проблемы сокращения файла журнала. Все предыдущие варианты не работали для меня и не уменьшали размер файла журнала до необходимого. Решение, которое я нашел:

• Резервное копирование вашей базы данных
• Установить режим восстановления на простой
• Отключение базы данных с помощью SQL Server Management Studio
• Удалить файл журнала
• Присоединить базу данных без файла журнала. В нижней половине «экрана добавления» вы увидите строку, в которой говорится, что файл журнала отсутствует
• Нажмите удалить для этой строки и ОК для вложения
• Установить режим восстановления обратно на полный

Answer 8

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

При использовании SQL Server Management Studio после выполнения полного резервного копирования базы данных с последующим полным резервным копированием журнала транзакций на странице сжатых файлов отображается достаточно свободного места, но она не усекает файлы журнала.

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

После завершения второго резервного копирования я снова запускаю инструмент сжатия в студии управления. Он по-прежнему показывает, что свободного места достаточно, но на этот раз, когда я нажимаю кнопку ОК, размер файла журнала уменьшается.

Итак, попробуйте следующее.

1. Создайте полную резервную копию базы данных и файла журнала. Если вы проверите в инструменте сжатия, то увидите, что в файле журнала теперь достаточно свободного места. Однако нажатие OK не приведет к удалению свободного места.

2. Сделайте вторую полную резервную копию базы данных и файла журнала. Вы должны найти, что полная резервная копия базы данных по размеру похожа на первую полную резервную копию. Размер полной резервной копии журнала транзакций должен быть намного меньше.

3. Запустите инструмент сжатия для файла журнала и, если повезет, файл журнала должен уменьшиться в размере. В последний раз, когда я делал это, он уменьшился со 180 ГБ до 12 МБ, и инструмент сжатия утверждает, что в файле все еще есть 10 МБ свободного места.

Answer 9

Попробуйте запустить

DBCC OPENTRAN

чтобы проверить, есть ли открытые транзакции.

Answer 10

Читая ответы, я не верю, что они написаны администраторами баз данных. Основные золотые правила:

1. В любой базе данных перед выполнением какого-либо обслуживания, включая сжимая журнал, вы должны выполнить полное резервное копирование.

2. Выполнять любое обслуживание базы данных, включая сжатие, когда больше ничего не происходит в этой конкретной базе данных для всего продолжительность обслуживания. Если это необходимо, приостановить несущественные приложения. Всегда имейте в виду, что здоровый база данных - это душа любых приложений, взаимодействующих с ней.

После всего этого следующие команды для сжатия журнала транзакций базы данных всегда хорошо работали со мной на SQL Server 2005 и более поздних версиях SQL Server:

USE DatabaseName
GO
-- Truncate the Transaction log
ALTER DATABASE DatabaseName SET RECOVERY SIMPLE
CHECKPOINT
ALTER DATABASE DatabaseName SET RECOVERY FULL
GO
-- Shrink the Transaction Log as recommended my Microsoft.

DBCC SHRINKFILE ('database_txlogfilelogicalname', [n -size to shrink in MBytes])
GO
 -- Pass the freed pages back to OS control.
DBCC SHRINKDATABASE (DatabaseName, TRUNCATEONLY)
GO
-- Tidy up the pages after shrink
DBCC UPDATEUSAGE (0);
GO
-- IF Required but not essential
-- Force to update all tables statistics
exec sp_updatestats
GO