Microsoft SQL Server. Что означает, что журнал транзакций заполнен?

Question

Что означает, что журнал транзакций заполнен? У меня есть файл, установленный на 20% при необходимости. У меня осталось 4ГБ на диске. Как мне решить эту проблему навсегда? Выполнение этих команд временно решает проблему:

DBCC SHRINKFILE('MyDatabase_log', 1)
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY
DBCC SHRINKFILE('MyDatabase_log', 1)

Answer 1

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

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

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

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

Answer 2

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

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

И последнее: если вы выполняете операции массовой загрузки, вы также можете посмотреть на «Bulk-Logged» при выполнении массовых операций.

Answer 3

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

Answer 4

Резервное копирование часто, журнал транзакций очищается при каждом резервном копировании базы данных.

Answer 5

Вы должны посмотреть на Модели восстановления SQL Server . Краткий ответ - изменить модель восстановления на «Простую», но это имеет значение для резервного копирования / восстановления.

Answer 6

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

Answer 7

Есть много разных способов решить эту проблему. Это зависит от ваших требований к резервному копированию.

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

SQL Server 2005 имеет Простой режим восстановления (свойство / опция для самой базы данных), который я использую в основном в средах DEV и TEST, где ежечасные моментальные снимки не требуются, журнал транзакций только растет достаточно для обработки самой большой транзакции на сервере. Для этого режима восстановления не требуется никаких расписаний или планов обслуживания.

В SQL Server 2000 у вас был сценарий резервного копирования по расписанию, который запускал ту же команду, что и вы, ежечасно или около того:

BACKUP LOG MyDatabase WITH TRUNCATE_ONLY

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

Answer 8

Я бы не стал делать ставку в 20%. Это может иметь большие последствия, когда оно должно расти. Если бы он когда-нибудь вырос, скажем, до 100 ГБ, то при следующем росте он должен был бы увеличиться на 20 ГБ - будьте готовы к тому, чтобы ваша система замедлилась, а пока это происходит ... Скорее, я бы установил фиксированную скорость - скажем, 100 МБ. , Конечно, мы не знаем текущий размер, чтобы дать более точную рекомендацию.