Кто-то запустил инструкцию обновления в рамках некоторого обслуживания, которое выполнило обновление перекрестного соединения для двух таблиц по 200 000 записей в каждой. Это 40 триллионов заявлений, которые объясняют часть о том, как лог вырос до 200Гб. У меня также не было ограничений для файла журнала, что является еще одной проблемой, которую я буду решать на всем сервере, где у нас находится почти 200 баз данных.
«Решение», которое я использовал, заключалось в том, чтобы сделать резервную копию базы данных, сделать резервную копию журнала с помощью truncate_only, а затем снова создать резервную копию базы данных. Затем я сжал файл журнала и установил ограничение на журнал.
Увидев, что на диске журналов используются другие базы данных, я немного торопился его очистить. Возможно, я смог бы создать резервную копию файла журнала на нашем резервном диске, надеясь, что никаким другим базам данных не потребуется увеличивать свой файл журнала.
Пол Рэндал из http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
Ни при каких обстоятельствах вы не должны удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд или просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY в BACKUP LOG (которые были удалены в SQL Server 2008). Эти параметры либо вызовут несогласованность транзакций (и, скорее всего, повреждение), либо исключат возможность правильного восстановления базы данных.
Были ли другие варианты, о которых я не знал?
Вы могли бы поместить базу данных в простую модель восстановления (затем использовать команду CHECKPOINT, чтобы убедиться, что журнал максимально усечен), а затем обратно в модель полного восстановления. Затем сделайте полную резервную копию базы данных, чтобы система поняла, что она полная.
Затем вы можете сжать журнал по своему усмотрению. Сжатие журнала не так ужасно, как сжатие базы данных, чего вам почти никогда не следует делать.
Вы не удалили журнал, вы просто его усекли, что лишает вас возможности восстановления на определенный момент времени. Так что сделайте полную резервную копию своей базы данных как можно скорее.
Также имейте в виду, что если ваш журнал не может расти, ваша база данных остановится. Так что оставить автоматическое увеличение - неплохой вариант ... но, возможно, настроить его так, чтобы он отправлял вам предупреждение, когда он заполняется.