Сжатие лога БД SQL при простой модели восстановления
Добрый день!
SQL 2012, база данных размером 32 ГБ, неожиданно вырос размер лога до 50 ГБ.
Конфа постоянно дорабатывается, в определенный момент стали долго проводиться некоторые документы, возникали конфликты блокировок.
Проблему решил ТИИ с опцией ПересчетИтоговРегистровНакопления.
Подозреваю, что лог вырос в данный момент.
Для БД используется Simple модель восстановления, бэкапы делаются ежедневно, но лог почему то не урезается автоматически (ведь должен?).
Вопрос - могу ли я сделать сжатие лога средствами SQL Studio или для начала стоит пробовать другие варианты (какие?). Если да, то могут ли быть проблемы?
Клонировал рабочую базу в тестовую, выполнил сжатие - лог ужался с 50 ГБ до 1МБ! На первый взгляд проблем не наблюдается.
Пробовал также вручную делать backup/restore - размер лога не изменился...
SQL 2012, база данных размером 32 ГБ, неожиданно вырос размер лога до 50 ГБ.
Конфа постоянно дорабатывается, в определенный момент стали долго проводиться некоторые документы, возникали конфликты блокировок.
Проблему решил ТИИ с опцией ПересчетИтоговРегистровНакопления.
Подозреваю, что лог вырос в данный момент.
Для БД используется Simple модель восстановления, бэкапы делаются ежедневно, но лог почему то не урезается автоматически (ведь должен?).
Вопрос - могу ли я сделать сжатие лога средствами SQL Studio или для начала стоит пробовать другие варианты (какие?). Если да, то могут ли быть проблемы?
Клонировал рабочую базу в тестовую, выполнил сжатие - лог ужался с 50 ГБ до 1МБ! На первый взгляд проблем не наблюдается.
Пробовал также вручную делать backup/restore - размер лога не изменился...
По теме из базы знаний
- Шринк лога транзакций MS SQL 2008/2012 в экстренном случае или боремся с ошибкой HRESULT=80040E14
- Автоматизируй это!
- TMSSQL - работа с базами данных MS SQL Server в скриптах на OneScript и из командной строки
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Резервное копирование журнала транзакций, наконец-то!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Не должен. Сколько места забрал столько будет использовать, перезаписывая данные по кругу.
(1)
Можно сделать SHRINK как скриптом, так и из контектстного меню базы. Других вариантов нет. Проблем не будет
Для БД используется Simple модель восстановления, бэкапы делаются ежедневно, но лог почему то не урезается автоматически (ведь должен?).
Не должен. Сколько места забрал столько будет использовать, перезаписывая данные по кругу.
(1)
Вопрос - могу ли я сделать сжатие лога средствами SQL Studio или для начала стоит пробовать другие варианты (какие?). Если да, то могут ли быть проблемы?
Можно сделать SHRINK как скриптом, так и из контектстного меню базы. Других вариантов нет. Проблем не будет
(2)Спасибо большое за ответ!
У меня еще вопрос, возможно не совсем корректный - БД .mdf занимает 30 ГБ, при выгрузке в .dt - всего 4 ГБ. Это нормально? Дисковое пространство ограничено, еще не успел разобраться с планом обслуживания...
У меня еще вопрос, возможно не совсем корректный - БД .mdf занимает 30 ГБ, при выгрузке в .dt - всего 4 ГБ. Это нормально? Дисковое пространство ограничено, еще не успел разобраться с планом обслуживания...
(3) Это нормально. В dt данные лежат в архиве. Быстрое обращение к ним невозможно. Можете снять архивную копию базы средствами SQL и сравнить с dt , размеры будут сопоставимы.
База .mdf устроена так чтобы с неё быстро читались данные.
Можно сравнить автомобиль с кубиком металла/пластика того же веса. Объем сильно разный, а состав вроде тот же
База .mdf устроена так чтобы с неё быстро читались данные.
Можно сравнить автомобиль с кубиком металла/пластика того же веса. Объем сильно разный, а состав вроде тот же
(3)
Дисковое пространство это самое дешевое что есть сейчас. Купить серверный ssd на террабайт несоизмеримо дешевле чем стоимость данных на этом диске или любые услуги программистов по уменьшению базы.
Дисковое пространство ограничено
Дисковое пространство это самое дешевое что есть сейчас. Купить серверный ssd на террабайт несоизмеримо дешевле чем стоимость данных на этом диске или любые услуги программистов по уменьшению базы.
(2)
В разных источниках нахожу примерно следующее
То есть, SHRINK должен происходить автоматически при создании контрольной точки...
В свойствах базы есть параметр Автоувеличение/макс. размер, у меня это 10% и 2097152 МБ соответственно. Могу я ограничить размер лога здесь?
Не должен. Сколько места забрал столько будет использовать, перезаписывая данные по кругу.
В разных источниках нахожу примерно следующее
log truncation will occur automatically after a checkpoint (if the database is in SIMPLE recovery model) or after a log backup (if the database is in FULL or BULK-LOGGED recovery model).
То есть, SHRINK должен происходить автоматически при создании контрольной точки...
В свойствах базы есть параметр Автоувеличение/макс. размер, у меня это 10% и 2097152 МБ соответственно. Могу я ограничить размер лога здесь?
(6) Путаете truncate и shrink. Это как пометка на удаление и собственно удаление. Транкейт помечает логические блоки внутри лог файла как ненужные, но не сжимает файл. Шринк сжимает файл, но только если внутри есть блоки отмеченные как ненужные. Шринк не является полезной операцией, в идеале он не выполняется вообще никогда. Просто под лог файл отдаётся отдельный диск целиком и там по кругу бегает запись.
(11)(4)(9) Спасибо большое!С проблемой разобрался. Роста лога был связана с неподтвержденными транзакциями, которые возникали при проведении некоторых док-ов, в результате чего лог не урезался долгое время и, соответственно, рос в размерах. После сжатия лога средствами SQL Studio, спустя 3 дня лог в районе 300 МБ, при размере базы в 30 ГБ
вот здесь написано как уменьшить лог файл
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Простая(Simple) - OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем освободить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) -
указать приемлемый размер лога.
проблем не возникало
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Простая(Simple) - OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем освободить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) -
указать приемлемый размер лога.
проблем не возникало
(7) Спасибо большое, это я уже сделал! Просто хотелось бы понять, как наиболее корректно ограничить размер лога на будущее, и можно ли это делать вообще. Во многих источниках не рекомендуют этого делать, как и сжимать лог вообще...
Проверил, в свойствах сервера значение Интервал восстановления = 0 (минут).
В данном случае (информация с сайта MS),
И опять же
В данном случае (информация с сайта MS),
На практике это означает время восстановления менее минуты и создание контрольных точек приблизительно раз в минуту для активно используемых баз данных.
И опять же
log truncation will occur automatically after a checkpoint (if the database is in SIMPLE recovery model)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот