Резервное копирование журнала транзакций SQL 2012 не усекает журналы
Я новичок в администрировании БД, так что несите меня. У меня маленькая БД на 500 МБ с очень большим журналом транзакций (19 ГБ). Я хотел бы оставить это в режиме «Полное восстановление», поэтому не предлагайте «Простой» режим восстановления.
Я изучаю, как уменьшить размер журналов транзакций, и я пытаюсь реализовать предложения, но размер журнала не меняется.
Прежде всего, вот что я делаю: у меня есть ежедневная задача резервного копирования, которая создает резервные копии всех баз данных в рамках плана обслуживания. Это тип резервной копии «Полная», и, похоже, он работает хорошо. Я вижу каждый день резервное копирование одного файла, размер которого равен размеру самой БД.
Теперь, когда у меня есть полная резервная копия, я приступил к выполнению резервного копирования вручную типа «журнал транзакций» с опцией «усечь журнал транзакций».
Резервное копирование завершается через несколько секунд, создается файл размером в несколько мегабайт, но размер журналов транзакций остается прежним.
Что я делаю не так?
Ваша резервная копия журнала транзакций усекает журналы в том смысле, что освобождает место в существующем файле журнала для дополнительных транзакций. Если вы хотите сжать файл журнала, вам нужно выбрать опцию «сжать файл» в SSMS. Щелкните правой кнопкой мыши базу данных, чтобы найти эту опцию.
Если размер файла, до которого вы его уменьшите, недостаточно велик, в зависимости от того, сколько транзакций имеет ваша база данных и как часто вы выполняете резервное копирование журналов, он снова будет расти. Для предотвращения этого может потребоваться более частое резервное копирование журналов.
Похоже, вы вообще не выполняете резервное копирование журнала транзакций (кроме одного раза, когда вы запускали его вручную). Если да, то не только поэтому ваш журнал транзакций растет, но вы все равно не получаете преимуществ от полного восстановления. Запланируйте регулярное резервное копирование журнала транзакций. (Ежечасно было бы хорошим началом.)
Хорошо, первое, что нужно понять, это почему файл журнала имеет такой размер. Вы говорите, что объем данных 500 МБ, вы уверены? это очень маленький файл данных по сравнению с файлом журнала. Если это правда, то ЖУРНАЛ - это размер ПОЧЕМУ.
Итак, вы должны выяснить, почему ... вы загружали данные в БД? Любой процесс ETL / DTS, в котором выполняются данные, перестраиваются индексы и т. Д., И выполняются крупные транзакции? Вы проверили, нет ли незавершенных транзакций? (Выберите @@ trancount)
Вы можете проверить текущий статус журнала, проверив log_reuse_wait и log_reuse_wait_desc.
ВЫБЕРИТЕ [log_reuse_wait_desc] ОТ [master]. [Sys]. [Базы данных] WHERE [name] = N'Company ';
Неактивная часть журнала не может быть усечена, пока все записи журнала не будут сохранены в резервной копии журнала. Это необходимо для поддержания в цепочке журналов серии записей журнала, имеющих непрерывную последовательность порядковых номеров журнала (LSN). Журнал усекается при резервном копировании журнала транзакций, если существуют следующие условия:
1. Контрольная точка произошла с момента последнего резервного копирования журнала. Контрольная точка необходима, но недостаточна для усечения журнала в рамках модели полного восстановления или модели восстановления с неполным протоколированием. После контрольной точки журнал остается неизменным по крайней мере до следующего резервного копирования журнала транзакций.
2. Никакие другие факторы не препятствуют транзакции журнала.
Как правило, при регулярном резервном копировании пространство журнала регулярно освобождается для использования в будущем. Однако различные факторы, такие как длительная транзакция, могут временно предотвратить усечение журнала.
Оператор BACKUP LOG не указывает WITH COPY_ONLY.
Источник: https://technet.microsoft.com/en-us/library/ms189085(v=sql.105).aspx
Если файл журнала действительно должен быть такого размера, и вы его уменьшите, он будет только расти снова, и это само по себе является дорогостоящим процессом, поскольку база данных записывает журнал и нуждается в расширении файла, если у вас не включена мгновенная инициализация файла. для учетной записи службы sql server процесс будет ждать, пока файл не будет увеличен, а затем он будет писать, если это будет для фрагментов ГБ, у вас возникнут более серьезные проблемы.
Итак, теперь вам нужно посмотреть на активность базы данных, если вы выполняете только одну резервную копию журнала в день, например, этого может быть недостаточно для активности БД, в моей организации я делаю резервные копии каждые 15 минут или каждые 1 час. а в некоторых случаях на определенных БД каждые 5 минут. это позволяет журналу не увеличиваться слишком сильно (журналы были предварительно заданы на некоторых серверах), мы также используем жесткие RTO / RPO.
теперь, как заявил joeqwerty, если у вас нет жесткого SLA на этот ящик в отношении точек восстановления, возможно, не стоит запускать его в ПОЛНОМ или BULK-Logged, вы тратите свое время, если все, что вы делаете, это запускаете ПОЛНОЕ резервное копирование ежедневно и Компания не заботится о потере данных, не боритесь с этим, работайте с этим.
Если вас интересует только размер журнала, а не восстановление точки транскрипции, создайте резервную копию журнала и уменьшите его, а затем переключитесь на простой.
Вы говорите, что не предлагает Простое восстановление, но я не думаю, что вы полностью понимаете, что делаете с ПОЛНЫМ восстановлением.