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

Question

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

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

РЕДАКТИРОВАТЬ: Я не говорю, что мой журнал транзакций огромен (я знаю, что некоторые администраторы БД посмеялись бы над моей БД размером с соску), просто по отношению к файлу БД, я думаю, он огромен.

Answer 1

Э-э ... простите за очевидное кровотечение, но у вас есть запланированные резервные копии с "ЖУРНАЛОМ РЕЗЕРВНОГО КОПИРОВАНИЯ"

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Что касается общего руководства, я стараюсь поддерживать его на уровне менее 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)