Простая и полная модель восстановления в MS SQL

«А какую модель восстановления используете вы» ?

Спрашиваю я иногда на курсе: Администратор 1С своих студентов.

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

 

Давайте по порядку!

Сперва разберемся что такое «Модель восстановления», затем почему «новички» часто переводят базы в модель  «Simple», сравним эти режимы восстановления, разберем преимущества «Полной» и наконец узнаем, кому действительно стоит использовать режим восстановления «Простой».

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

Существует три модели восстановления:

  1. «Простая» – «Simple»
  2. «Полная» – «Full»
  3. «Модель с неполным протоколированием» – «Bulk-logged»

Обычно в базе данных используется модель полного восстановления (По умолчанию!) или простая модель восстановления. «Модель с неполным протоколированием» используют редко (Если мы говорим о базах 1С Предприятия).

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

«Simple» в «Full» и обратно.

Как посмотреть какая у Вас модель восстановления «Recovery model»  в MS SQL ?

Все просто!

Запускаем Management Studio «SSMS»

Находим базу, что нас интересует и кликаем свойства (Скрин ниже):

Простая и полная модель восстановления в MS SQL

Простая и полная модель восстановления в MS SQL

Затем в открывшимся окне кликаем «параметры» и смотрим режим восстановления, к слову там же его и можно сменить (как на скрине ниже).

Простая и полная модель восстановления в MS SQL

Конечно, если баз много, нам будет неудобно вот так каждую базу «тыкать».

Благо мы можем быстро получить информацию по всем базам вместе, используя простенький скрипт:

SELECT [name], DATABASEPROPERTYEX([name],’recovery’) AS Recovery_model

FROM sysdatabases

WHERE name not in (‘master’,’model’,’tempdb’,’msdb’)

ORDER BY Recovery_model, name

Так мы узнаем режимы восстановления сразу по всем базам, исключив системные.

Простая и полная модель восстановления в MS SQL

 

 

Как видим на скрине выше,  наши базы «BASE1» и «BASE2» находятся в полном режиме восстановления.

 

Теперь, когда мы знаем наш режим восстановления, давайте его подробно разберем.

«FULL» у нас по умолчанию, с него и начнем!

 

В «Полной» модели восстановления:

  • Все изменения в базе полностью журналируются.
  • Журнал транзакций не будет очищаться до тех пор, как не будет сделана резервная копия журнала транзакций, подробно можете почитать здесь >>>
  • Все опции восстановления доступны, когда база данных в полной модели восстановления! К примеру, мы можем «до секунды» восстановить нашу базу!

 

В «Простой» модели восстановления:

  • Изменения минимально журналируются.
  • Журнал транзакций (ЛОГ) автоматически очищается.
  • Создание резервных копий журнала транзакций невозможно, поэтому у вас остается самое ограниченное число опций по восстановлению.

Восстановление базы возможно только на момент когда был создан этот бэкап.

Конечно, это очень поверхностное сравнение, но оно должно вас разубедить, что не стоит сходу переводить базу в «Простой» режим восстановления.

Чтоб понять истинное преимущество «Полного» режима восстановления, давайте представим ситуацию, что у вас «Простой» режим и «упала» баз под конец рабочего дня, а бэкап естественно сделан ночью, то есть пропал день работы пользователей в 1С.

В «Полной» модели мы можем делать и делаем автоматически (например, каждые 30 мин) бэкап ЖТР (Журналов транзакций, «маленькие» файлы с зафиксированными изменениями) как и положено, и максимум, что мы можем потерять это 30 мин работы пользователей.

А представьте ситуацию, что база не «сломалась», а просто требуется откатить работу в конце рабочего дня на 12:05 когда допустили ошибку и «повело» все следующие документы которых добрая сотня. Конечно, это за минуту можно сделать в «Полной» модели и нереально в «Простой».

 

Да, в «Простой» модели, нам доступен «Разностный/Дифференциальный» бэкап который можно делать раза 2-3 в день, но и это не выход, когда в час создают с десяток документов в 1С. А если его делать чаще, тогда он по размеру быстро догонит «полную» копию, так как включает данные всех предыдущих, и дисковое пространство будет быстро заполнено такими разностными «бэкапами».

Безусловно, не рационально будет «лупить» и полный бэкап каждый час.

 

 

Так почему «новички» часто использую режим «Simple» когда преимущества «Полной» модели весьма очевидны ?

Первая причина это рост журнала транзакций «Растет лог».

Все изменения фиксируются в журнале транзакций (файл ldf) он растет до тех пор, пока не заполнит все дисковое пространство, а это может произойти довольно быстро, когда с базой активно работает много пользователей, или когда есть «кривые операции», что ведут к «распуханию» лога.

Лог разрастается в размерах и пользователь, не имея нужных знаний, + лень искать и разбираться в операциях, которые заставляют лог расти, находит быстрый способ, как побороть проблему, «волшебную таблетку» – так называемый «Шринк» лога, и просто его обрезает.

 

BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY

go

DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций)

go

 

Что дает, само собой только кратковременный эффект!

Затем пользователь, устав бодаться с вечно растущим логом, переводит базу в режим «Simple». Все! проблема решена, и ничего что «Мерседес» превратили в «Жигули» зато едет )

Второй причиной, является, нежелание заботится о базе, делать регламентные операции по ее обслуживанию, настраивать «Maintenance Plan» в MS SQL. Выполнять дефрагментацию индексов, обновлять статистику и тд.

И третья причина, это конечно «экономия»!

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

Если база занимает 100 гб, + 200 Гб лог, да, для многих это кажется «слишком», и может запускаться режим – сэкономить на дисках )

 

А теперь шутки в сторону, рассмотрим, что пишет Microsoft о «Простой» модели восстановления, точнее в каких случаях ее можно использовать:

Читать далее...

Зарегистрируйтесь, чтоб продолжить чтение статьи
Зарегистрироваться / Войти


Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Оставьте ответ

[an error occurred while processing the directive]
[an error occurred while processing the directive]