none
Большой файл транзакций. RRS feed

  • Вопрос

  • Доброго времени суток.

    MS SQL 2008R2 (так говорит appwiz.cpl, емнип я накатывал R3, не уверен где это можно обнаружить), Windows Server 2012R2.

    В MS SQL я совершенно не волоку, у меня используется в качестве СУБД для VMware vCenter (обычно использую vapp с SLES на борту, но тут вот исключение), обнаружил что ldf файл вырос до размеров 28 ГБ, сама база 4 ГБ. Режим восстановления - full (полагаю, нужно изменить на simple?). Прошу порекомендовать, как шринкнуть файл транзакции без какого-либо импакта и избежать его роста в будущем.

    P.S. вообще, файл транзакции при таком режиме восстановления должен так расти только в случае если не выполняется резервное копирование базы. Veeam B&R в моем случае копирует логи транзакций (copy only, а не process transaction logs with this job), полагаю этого не достаточно, чтобы при таком режиме восстановления SQL считал что выполняется резервное копирование?

    20 августа 2016 г. 7:20

Ответы

  • вот инструкция по усечению: https://technet.microsoft.com/ru-ru/library/ms190757(v=sql.105).aspx

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

    По поводу литературы: я как-то давно читал вот эту книжку https://www.ozon.ru/context/detail/id/19688054/ 

    Мне она показалась очень просто написанной и доступной для понимания новичкам. Тем не менее, сам факт того, что руководство для начинающих ms sql 2012 занимает аж 800 страниц говорит о том, что продукт на самом деле не так уж и прост.

    29 августа 2016 г. 5:48
  • усечение журнала теоретически должно произойти после выполнения резервного копирования журнала, но не всегда.

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

    Как только перейдете на простой вариант восстановления, сделайте вручную усечение журнала. Разумеется перед усечением не помешает выполнить полное резервное копирование базы.

    Усечение журнала транзакций делается при резервном копировании журнала - при этом логически освобождается место в файле журнала, но сам файл не усекается. Поэтому при модели восстановления Full нужно переодически делать резервные копии журнала. Либо, если не делаете, то нужно переключиться на модель Simple. Это остановит рост файла журнала, но вот уменьшать размер файла придётся вручную.

    Я всегда сжимал чрезмерно разросшийся файл журнала транзакций базы данных MS SQL по такой процедуре:

    1. Резервное копирование журнала (с усечением), при этом освобождается значительная часть журнала, но, к сожалению - обычно в конце файла место остаётся занятым. Резервное копирование можно заменить переключением в режим восстановления Simple (плюс небольшое ожидание на очисткуЮ проконтролировать завершение можно по свойствам журнала - там указывается размер свободного места в файле)

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

    3. Для того, чтобы убрать занятый участок журнала в конце файла, я делал повторное резервное копирование. В режиме восстановления Simple можно просто подождать (если база время от времени обновляется, конечно). Сколько ждать - это я не скажу.

    4. После этого я делал усечение файла журнала транзакций до нужного размера с конца: когда усекаемый конец не используется (что достигается пп.1-3) то это - очень быстрая процедура, в отличие от сжатия журнала.


    Слава России!

    20 августа 2016 г. 14:32

Все ответы

  • усечение журнала теоретически должно произойти после выполнения резервного копирования журнала, но не всегда.

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

    Как только перейдете на простой вариант восстановления, сделайте вручную усечение журнала. Разумеется перед усечением не помешает выполнить полное резервное копирование базы.

    20 августа 2016 г. 8:51
  • Спасибо за ответ.

    Т.е. если резюмировать:

    1. Меняю режим восстановления на simple.

    2. Делаю резервную копию базы, например по этой статье https://msdn.microsoft.com/ru-ru/library/ms187510.aspx.

    3. Сжимаю лог файл, например по этой статье https://technet.microsoft.com/ru-ru/library/ms190757(v=sql.105).aspx.

    Так?

    20 августа 2016 г. 8:59
  • усечение журнала теоретически должно произойти после выполнения резервного копирования журнала, но не всегда.

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

    Как только перейдете на простой вариант восстановления, сделайте вручную усечение журнала. Разумеется перед усечением не помешает выполнить полное резервное копирование базы.

    Усечение журнала транзакций делается при резервном копировании журнала - при этом логически освобождается место в файле журнала, но сам файл не усекается. Поэтому при модели восстановления Full нужно переодически делать резервные копии журнала. Либо, если не делаете, то нужно переключиться на модель Simple. Это остановит рост файла журнала, но вот уменьшать размер файла придётся вручную.

    Я всегда сжимал чрезмерно разросшийся файл журнала транзакций базы данных MS SQL по такой процедуре:

    1. Резервное копирование журнала (с усечением), при этом освобождается значительная часть журнала, но, к сожалению - обычно в конце файла место остаётся занятым. Резервное копирование можно заменить переключением в режим восстановления Simple (плюс небольшое ожидание на очисткуЮ проконтролировать завершение можно по свойствам журнала - там указывается размер свободного места в файле)

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

    3. Для того, чтобы убрать занятый участок журнала в конце файла, я делал повторное резервное копирование. В режиме восстановления Simple можно просто подождать (если база время от времени обновляется, конечно). Сколько ждать - это я не скажу.

    4. После этого я делал усечение файла журнала транзакций до нужного размера с конца: когда усекаемый конец не используется (что достигается пп.1-3) то это - очень быстрая процедура, в отличие от сжатия журнала.


    Слава России!

    20 августа 2016 г. 14:32

  • Усечение журнала транзакций делается при резервном копировании журнала - при этом логически освобождается место в файле журнала, но сам файл не усекается. Поэтому при модели восстановления Full нужно переодически делать резервные копии журнала. Либо, если не делаете, то нужно переключиться на модель Simple. Это остановит рост файла журнала, но вот уменьшать размер файла придётся вручную.


    Похоже я не совсем корректно выразился.

    суть в том, что если использовать простую модель восстановления и регулярно выполнять резервное копирование БД, то файл журнала будет занимать какой-то небольшой объем в зависимости от частоты бэкапа, интенсивности использования БД и её размера. Обычно этот объем значительно меньше самой БД. Думаю в этом случае даже шринкать его особо не нужно - пусть он постоянно занимает какой-то объем и не важно, что логически он может быть хоть на 90% пустым. Разумеется если стоит задача сжать ненормально разросшийся журнал, то это уже другой вопрос. Тут мне кажется в большинстве случаев вполне нормально перейти на simple-модель и бэкап журнала + бэкап БД + шринк

    20 августа 2016 г. 15:26
  • Ну, свободное место в журнале транзакций - это очень сложный предмет, почти как мёд. К примеру,  если программист, решивший на выходных "почистить базу" удаляет из неё половину данных в рамках одной транзакции, то журнал вырастет до размера не менее, чем занимавшееся удалёнными данными место, и модель Simple тут ничуть не поможет - до закрытия транзакции данные о ней удалять из журнала недопустимо.

    Ну, а у автора вопроса ситуация кристально ясна: модель full при отсутствии регулярного резервного копирования журнала транзакций. Если его не интересует возможность восстановления этой базы на определённый момент времени, то вполне логично перейти к модели simple и обрезать размер файла журнала транзакций


    Слава России!



    • Изменено M.V.V. _ 29 августа 2016 г. 7:16
    20 августа 2016 г. 16:35
  • Полностью с вами согласен. Транзакции, это уже совсем другая история, у тс все достаточно просто.

    Только один небольшой момент - поправьте, пожалуйста, у себя ссылку, а то она на сайт новостей ведет))

    20 августа 2016 г. 17:07
  • Спасибо всем за ответы. Извиняюсь за долгое отсутствие, был откомандирован, времени заниматься этим вопросом не было.

    >Если его не интересует возможность восстановления этой базы на определённый момент >времени, то >вполне логично перейти к модели simple и обрезать размер файла журнала >транзакций (процедура >- здесь)

    ссылка действительно ведет на новостной портал, можно рабочую?

    p.s. я практически не работаю с субд, но есть желание получить основные фундаментальные знания, на форуме не раз спрашивал о руководстве для администраторов, но ничего не посоветовали. Может вы что-то порекомендуете (желательно в виде книги, а не документации на технете)? Интересуют темы установка/обновление, обслуживание, резервное копирование/восстановление, кластеризация и траблшутинг.


    29 августа 2016 г. 4:04
  • вот инструкция по усечению: https://technet.microsoft.com/ru-ru/library/ms190757(v=sql.105).aspx

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

    По поводу литературы: я как-то давно читал вот эту книжку https://www.ozon.ru/context/detail/id/19688054/ 

    Мне она показалась очень просто написанной и доступной для понимания новичкам. Тем не менее, сам факт того, что руководство для начинающих ms sql 2012 занимает аж 800 страниц говорит о том, что продукт на самом деле не так уж и прост.

    29 августа 2016 г. 5:48
  • Да, в ваших ответах много информации, но я далеко не все понял. В описании процедуры резервного копирования журнала указано, что процедура предназначена только для моделей full и bulk_logged. К тому же, если я правильно понял перед резервным копированием журнала нужно создать резервную копию базы. Т.е. последовательность все же такая: 1. резервная копия базы 2. резервная копия журнала 3. смена модели восстановления 4. усечение журнала по вашей ссылке.
    29 августа 2016 г. 7:40
  • пункт 3 нужно выполнять первым.
    29 августа 2016 г. 8:58
  • Спасибо, все прошло нормально (журнал усекся на 99%). 

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

    29 августа 2016 г. 11:17
  • немного не понял о каком приложении, использующим БД, идет речь. 

    Например у меня ms sql-серверы используются для баз 1С, приложений антиспама, других бизнес-приложений. Вы их имеете в виду? Просто чтобы научиться выполнять резервное копирование/восстановление баз, не нужно, чтобы эта база обязательно кем-то использовалась.

    29 августа 2016 г. 12:12