Огромный журнал транзакций - это нормально?

Question

У меня есть база данных 5 ГБ и журнал транзакций 20 ГБ (SQL Server 2005). Не уверен, почему это так велико или что произошло, чтобы сделать его таким большим, он составлял около 1/2 размера БД. DB растет примерно на 1 ГБ/месяц.

Существуют ли какие-либо рекомендации относительно того, насколько большой ваш журнал транзакций должен быть относительно вашего размера файла базы данных?

EDIT: Я не говорю, что мой журнал транзакций огромен (я знаю, что некоторые администраторы баз данных будут смеяться над моей размерной БД), как раз по отношению к файлу БД, я думаю, что он огромен.

Answer 1

Э ... простите кровотечение очевидно, но вы запланировали резервное копирование с помощью «BACKUP LOG»

Если модель восстановления ПОЛНАЯ то это должно произойти.

Есть другие, редкие варианты, которые я буду включать в себя (не исчерпывающий):

• Большой индекс таблицы перестраивать/обслуживание. Однако резервный журнал очистит это.
• Открытая транзакция предотвращения журнала резервного копирования удаление записей (поэтому она растет)
• соединение с SET IMPLICIT_TRANSACTIONS ON (см предыдущий пункт)

Answer 2

Если у вас много транзакционного поведения, это не редкость. Тем не менее, вам, вероятно, следует исследовать способы уменьшения его размера. Для этого существует немало вариантов, но, не зная вашей модели восстановления, я никогда не мог предположить, что вы сделаете рекомендацию. Начните с этого MSDN link, этого knowledge base article, затем перейдите оттуда. Внимательно. :)

Answer 3

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

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

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

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

Backup Log DatabaseName With Truncate_Only 
GO 

Declare @LogFileLogicalName sysname 
select @LogFileLogicalName=RTRIM(Name) from sysfiles where filename like '%.ldf%' 
--SELECT @LogFileLogicalName 
DBCC Shrinkfile(@LogFileLogicalName,2) 

Answer 4

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

Answer 5

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

Чтобы сделать это, вы можете использовать либо встроенные функции SQL Server fn_dblog, DBCC PAGE или fn_dump_dblog или какой-либо третьей инструмент стороной. Однако родные функции не документированы, и очень сложно понять полученные ими результаты. Что касается инструмента 3 партии, вы можете проверить Open LDF file and view LDF file content онлайн статью для более подробной информации и более глубокий анализ того, что требуется для прочтения информации журнала транзакций

Отказ от ответственности: я работаю в качестве поддержки продуктов Инженер по ApexSQL