Сильно растущий журнал транзакции SQL 2008
Здравствуйте!
Подскажите пожалуйста, перенесли базу на SQL2008, модель восстановления FULL, настроены следующие планы обслуживания. Полный бэкап 1 раз в день ночью и каждый день каждый час бэкап журнала транзакции. Так же настроены в порядке выполнения следующие планы обслуживания
1) Update Statistic Task
2) Reorganize Task Index
3) Shrink Database Task
Все это выполняется ежедневно плюс 1 раз в неделю
Rebuild Index Task
При всем это неумолимо растет журнал транзакции, уже превышает 100 Гб, подскажите способ его уменьшить
Подскажите пожалуйста, перенесли базу на SQL2008, модель восстановления FULL, настроены следующие планы обслуживания. Полный бэкап 1 раз в день ночью и каждый день каждый час бэкап журнала транзакции. Так же настроены в порядке выполнения следующие планы обслуживания
1) Update Statistic Task
2) Reorganize Task Index
3) Shrink Database Task
Все это выполняется ежедневно плюс 1 раз в неделю
Rebuild Index Task
При всем это неумолимо растет журнал транзакции, уже превышает 100 Гб, подскажите способ его уменьшить
Найденные решения
Пару лет назад бился с очень похожей фигней, порвано было много бубнов - результатов ноль. Вылечилось весьма неожиданно - делаешь Deatach бызы, руками убиваешь лог файл, потом Atach базу, а вот потом настройки авторасширения... Я понимаю, что звучит весьма бредово, но что делать.. А что и как делает Shrink, это вообще интересная тема.
Отменить
Журнал очень сильно растет во время реорганизации индекса. Перед выполнением плана обслуживания можно переводить на простую модель восстановления (ALT ER DATABASE base SET RECOVERY SIMPLE WITH NO_WAIT), после (но до резервного копирования) обратно на полную. Естественно в течении дня бэкапы журнала делаются. За предыдущие дни бэкапы журнала удаляются. При таком варианте и журнал не растет, и есть возможность восстановить базу на любой момент времени после после последнего полного бэкапа.
Отменить
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Гость, делать шринк крайне не рекомендуется, влияет на скорость работы с базой.
я бы на вашем месте сделал так:
1) сделал бекап лога транзакций;
2) тут же сделал шринк (да, пусть снизится быстродействие но зато размер уменьшится);
3) полез бы в свойства базы и на закладке Файлы изменил бы параметр Авторасширение от тех что проставлены по умолчанию. Данные увеличение размера в мегабайтах: 200 (рост не ограничен), журнал так же увеличение в мегабайтах: 100 (рост ОГРАНИЧЕН). Чтобы SQL не слишком часто увеличивал файлы выделяя свободное место, тем самым снижая быстродействие, особенно заметно на медленных дисковых подсистемах;
4) ну и теперь поправить план копирования, в части копирования лога транзакций, сделайте копирование раз в 30 минут, и смотрите будет ли он так же катастрофически увеличиваться или нет. Если рост "застынет", значит все ок, если будет расти, пусть не так быстро, то уменьшайте интервал копирования лога транзакций, до тех пор пока рост прекратится.
Удачи. И не надо делать SHRINK после каждого копирования. Это крайняя мера! А ограничение роста достигается своевременным "сбросом" лога в бекап, после чего система использует освобожденное в логе место и тем самым рост файла с логом прекращается. Надеюсь мысль мою поняли :)
я бы на вашем месте сделал так:
1) сделал бекап лога транзакций;
2) тут же сделал шринк (да, пусть снизится быстродействие но зато размер уменьшится);
3) полез бы в свойства базы и на закладке Файлы изменил бы параметр Авторасширение от тех что проставлены по умолчанию. Данные увеличение размера в мегабайтах: 200 (рост не ограничен), журнал так же увеличение в мегабайтах: 100 (рост ОГРАНИЧЕН). Чтобы SQL не слишком часто увеличивал файлы выделяя свободное место, тем самым снижая быстродействие, особенно заметно на медленных дисковых подсистемах;
4) ну и теперь поправить план копирования, в части копирования лога транзакций, сделайте копирование раз в 30 минут, и смотрите будет ли он так же катастрофически увеличиваться или нет. Если рост "застынет", значит все ок, если будет расти, пусть не так быстро, то уменьшайте интервал копирования лога транзакций, до тех пор пока рост прекратится.
Удачи. И не надо делать SHRINK после каждого копирования. Это крайняя мера! А ограничение роста достигается своевременным "сбросом" лога в бекап, после чего система использует освобожденное в логе место и тем самым рост файла с логом прекращается. Надеюсь мысль мою поняли :)
Это решение
(1) Гость, недавно настраивал планы в одной из контор, там была ситуация схожая с вашей,
так вот после описанных выше телодвижений, рост лога замер, теперь суммарный размер 3х баз (данные + лог) не превышает 20 гигов и цифра эта держится 3ю неделю.
так вот после описанных выше телодвижений, рост лога замер, теперь суммарный размер 3х баз (данные + лог) не превышает 20 гигов и цифра эта держится 3ю неделю.
Это решение
(6) wowkai, ну если у вас места мало на диске то можете сделать, да по идее можно сделать, быстродействие конечно после этого будет не максимальное, но постепенно все выровняется. Смысл в том чтобы подобрать время между копиями лога таким образом чтобы лог не рос! Но бывают конечно случаи, когда роста не избежать, например при обновлении или переиндексации/проверки базы средствами 1С. Тут уж каждый сам для себя решает что делать. Я все таки делаю шринк и после него лог сам разрастается постепенно до нужных ему для комфортной работы размеров. Т.е. операции обновления и переиндексации/проверки базы не такие частоы, то и проблема не часто возникает. Можно делать эти вещи в выходные например.
Это решение
Пару лет назад бился с очень похожей фигней, порвано было много бубнов - результатов ноль. Вылечилось весьма неожиданно - делаешь Deatach бызы, руками убиваешь лог файл, потом Atach базу, а вот потом настройки авторасширения... Я понимаю, что звучит весьма бредово, но что делать.. А что и как делает Shrink, это вообще интересная тема.
Отменить
Журнал очень сильно растет во время реорганизации индекса. Перед выполнением плана обслуживания можно переводить на простую модель восстановления (ALT ER DATABASE base SET RECOVERY SIMPLE WITH NO_WAIT), после (но до резервного копирования) обратно на полную. Естественно в течении дня бэкапы журнала делаются. За предыдущие дни бэкапы журнала удаляются. При таком варианте и журнал не растет, и есть возможность восстановить базу на любой момент времени после после последнего полного бэкапа.
Отменить
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот