Сегодня я получил электронное письмо, в котором говорится, что у нас есть файл журнала, размер которого увеличен до 278 ГБ, и с вопросом, поддерживает ли его кто-нибудь. Я уже знаю ответ на этот вопрос - нет, потому что у нас нет dba (кроме меня. Я довольно много знаю о sql, но я разработчик).
Наша база данных умеренно большая; некоторые таблицы содержат сотни миллионов записей. Хотя это кажется довольно большим для файла журнала, и я хотел бы получить какое-то направление в выяснении, является ли это ненормальным, можем ли мы настроить что-то лучше или лучшее решение - просто признать, что нам нужно кормить зверя больше места на жестком диске.
Если есть дополнительная информация, которую я мог бы опубликовать здесь, которая поможет мне лучше ответить, пожалуйста, дайте мне знать, что.
Похоже, для базы данных установлен режим ПОЛНОГО восстановления и не выполняется резервное копирование журнала транзакций. Это очень распространенная проблема.
Если вы не хотите выполнять восстановление на определенный момент времени, доставку журналов или что-то в этом роде, и вам удобно только восстановить до точки, на которой завершилось последнее полное резервное копирование, установите для своей базы данных режим восстановления ПРОСТОЙ и сократите файл журнала до чего-нибудь разумного.
Если вы выполняете резервное копирование журналов, убедитесь, что они работают без ошибок, и подумайте об увеличении их частоты.
Также возможно, что что-то начало транзакцию несколько часов / дней / недель / месяцев назад и никогда не совершало ее. Активные части журнала не могут быть усечены, и эти части не станут неактивными до тех пор, пока транзакция не зафиксируется или не откатится. Используйте DBCC OPENTRAN (MSDN в настоящее время не работает, поэтому я не могу предоставить ссылку) для устранения этой проблемы, она покажет вам информацию о самой продолжительной транзакции в базе данных. Если вы обнаружите, что у вас есть длительная транзакция, у вас могут возникнуть проблемы с фиксацией приложения. Конечно, вы можете отключить это соединение, но вы потеряете все изменения базы данных, сделанные за эти часы / дни / недели / месяцы. Возможно, вам понадобится исправить код где-нибудь в приложении.
Опять же, после того, как вы решите проблему, вы захотите сжать файл журнала до чего-нибудь разумного. Вы можете использовать системный монитор, чтобы увидеть, сколько места фактически используется с течением времени. В качестве общего числа «выстрел от бедра» я бы нацелился на размер, который в 1,25 раза больше размера вашей самой большой таблицы (измеряется в ГБ, а не в строках), и оставил бы файл настроенным на рост.
Похоже, вы не делаете резервные копии журналов. Резервная копия журнала обрезает файл журнала, поэтому, если он выходит из-под контроля, создается впечатление, что резервное копирование журнала не выполнялось.
редактировать У меня был неправильный тип бэкапа, поправил спасибо darin.