Сжатие лога БД SQL при простой модели восстановления

Форум Администрирование Сервер, сеть, оборудование (Hardware)

1. soulriwer 12.11.19 21:41 Сейчас в теме

Добрый день!

SQL 2012, база данных размером 32 ГБ, неожиданно вырос размер лога до 50 ГБ.

Конфа постоянно дорабатывается, в определенный момент стали долго проводиться некоторые документы, возникали конфликты блокировок.
Проблему решил ТИИ с опцией ПересчетИтоговРегистровНакопления.

Подозреваю, что лог вырос в данный момент.

Для БД используется Simple модель восстановления, бэкапы делаются ежедневно, но лог почему то не урезается автоматически (ведь должен?).

Вопрос - могу ли я сделать сжатие лога средствами SQL Studio или для начала стоит пробовать другие варианты (какие?). Если да, то могут ли быть проблемы?

Клонировал рабочую базу в тестовую, выполнил сжатие - лог ужался с 50 ГБ до 1МБ! На первый взгляд проблем не наблюдается.

Пробовал также вручную делать backup/restore - размер лога не изменился...

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Sapiens_bru 4 12.11.19 22:09 Сейчас в теме

(1)

Для БД используется Simple модель восстановления, бэкапы делаются ежедневно, но лог почему то не урезается автоматически (ведь должен?).

Не должен. Сколько места забрал столько будет использовать, перезаписывая данные по кругу.

(1)

Вопрос - могу ли я сделать сжатие лога средствами SQL Studio или для начала стоит пробовать другие варианты (какие?). Если да, то могут ли быть проблемы?

Можно сделать SHRINK как скриптом, так и из контектстного меню базы. Других вариантов нет. Проблем не будет

3. soulriwer 12.11.19 22:23 Сейчас в теме

(2)Спасибо большое за ответ!

У меня еще вопрос, возможно не совсем корректный - БД .mdf занимает 30 ГБ, при выгрузке в .dt - всего 4 ГБ. Это нормально? Дисковое пространство ограничено, еще не успел разобраться с планом обслуживания...

4. Sapiens_bru 4 12.11.19 22:35 Сейчас в теме

(3) Это нормально. В dt данные лежат в архиве. Быстрое обращение к ним невозможно. Можете снять архивную копию базы средствами SQL и сравнить с dt , размеры будут сопоставимы.
База .mdf устроена так чтобы с неё быстро читались данные.

Можно сравнить автомобиль с кубиком металла/пластика того же веса. Объем сильно разный, а состав вроде тот же

5. Sapiens_bru 4 12.11.19 22:40 Сейчас в теме

(3)

Дисковое пространство ограничено

Дисковое пространство это самое дешевое что есть сейчас. Купить серверный ssd на террабайт несоизмеримо дешевле чем стоимость данных на этом диске или любые услуги программистов по уменьшению базы.

6. soulriwer 13.11.19 10:48 Сейчас в теме

(2)

Не должен. Сколько места забрал столько будет использовать, перезаписывая данные по кругу.

В разных источниках нахожу примерно следующее

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 МБ соответственно. Могу я ограничить размер лога здесь?

11. Sapiens_bru 4 13.11.19 16:26 Сейчас в теме

(6) Путаете truncate и shrink. Это как пометка на удаление и собственно удаление. Транкейт помечает логические блоки внутри лог файла как ненужные, но не сжимает файл. Шринк сжимает файл, но только если внутри есть блоки отмеченные как ненужные. Шринк не является полезной операцией, в идеале он не выполняется вообще никогда. Просто под лог файл отдаётся отдельный диск целиком и там по кругу бегает запись.

12. soulriwer 15.11.19 11:55 Сейчас в теме

(11)(4)(9) Спасибо большое!С проблемой разобрался. Роста лога был связана с неподтвержденными транзакциями, которые возникали при проведении некоторых док-ов, в результате чего лог не урезался долгое время и, соответственно, рос в размерах. После сжатия лога средствами SQL Studio, спустя 3 дня лог в районе 300 МБ, при размере базы в 30 ГБ

7. yurikmellon 6 13.11.19 10:54 Сейчас в теме

вот здесь написано как уменьшить лог файл https://infostart.ru/public/168314/

Шаг 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) -
указать приемлемый размер лога.

проблем не возникало

8. soulriwer 13.11.19 10:59 Сейчас в теме

(7) Спасибо большое, это я уже сделал! Просто хотелось бы понять, как наиболее корректно ограничить размер лога на будущее, и можно ли это делать вообще. Во многих источниках не рекомендуют этого делать, как и сжимать лог вообще...

9. RustamZz 13.11.19 11:03 Сейчас в теме

(8) С ограниченным логом может не завершиться операция обновления базы или реструктуризации. Обычная работа пользователей не должна приводить к проблемам.

10. soulriwer 13.11.19 11:12 Сейчас в теме

Проверил, в свойствах сервера значение Интервал восстановления = 0 (минут).
В данном случае (информация с сайта MS),

На практике это означает время восстановления менее минуты и создание контрольных точек приблизительно раз в минуту для активно используемых баз данных.

И опять же

log truncation will occur automatically after a checkpoint (if the database is in SIMPLE recovery model)

Оставьте свое сообщение

E-mail: