Резервное копирование журнала транзакций, наконец-то!

04.12.23

База данных - Администрирование СУБД

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

Здравствуйте! Уже который год сталкиваюсь с задачами администрирования баз данных 1С на MS SQL и постоянно слышу это слово "FULL" ("Полная", в смысле модель восстановления - по-русски). Долгое время данная тема существовала для меня на уровне: для рабочей базы пусть стоит Полная модель, не трогай, но если переполнится или срочно (!) надо место почистить - ставишь Простую, делаешь "шринк", вертаешь обратно, [выбиваешь долотом на стенке туалета специальную метку, чтобы не забыть вернуть Полную]. Нет, я знал, что такое транзакция, проходил когда-то давно курс баз данных, на котором слышал про журнал и даже про фишку его использования при резервном копировании что-то припоминал, но вот подход ... явно требовал доработки. Не буду рассказывать, как пришел к необходимости (если что - ни один котик не пострадал) изменения подхода, но опишу результат и некоторую теорию.

 

    Введение
    Подготовка к автоматизации резервного копирования
        Создание процедуры актуализации логических имен файлов БД
    Создание (настройка) планов обслуживания
        Скрипт для резервного копирования журнала транзакций
        Скрипт для резервного копирования базы данных с уменьшением размера файла журнала
     Настройка оповещений на почту при ошибках
     Заключение (с небольшим бонусом)
     Постскриптум 

 

Глава 1. Введение

Для начала расскажу про журнал транзакций. Думаю, файл со своей базой данных все видели и понимают, что в этой корзине хранятся, что называется, "все яйца" и гадать о том, что произойдет при повреждении этой корзины не хочется, да и Господь говорит "не думай о завтрашнем дне". Кроме того, идеальных приложений, как и пользователей, не поедающих над своей клавиатурой вкусного печенья - просто не бывает. Поэтому разработчиками баз данных еще в давние времена был придуман журнал транзакций, в который будут записываться все операции с базой данных в том виде, чтобы можно было по конкретной записи (набору записей) установить какие строки, в каких таблицах и главное КАК были изменены в определенный момент времени. 

При полной модели восстановления транзакции фиксируются достаточно подробно, поэтому воспользовавшись таким журналом (в случае MS SQL - его архивными копиями, текущий их не устраивает, поскольку это еще одна большая корзина), а также полной резервной копией мы сможем восстановить состояние базы на любой описываемый журналом транзакций момент времени (после момента начальной резервной копии базы данных, конечно). Соответственно, получив сведения о критической ошибке с базой данных, если мы уже располагаем резервными копиями журнала транзакций, можно зайти в SSMS и выбрать точный момент времени, на который база данных будет восстановлена:


 Выбор момента времени восстановления базы данных

 

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

Если мы считаем (по какому-то стечению обстоятельств, не иначе), что резервных копий баз данных нам достаточно, чтобы "закрыть" вопрос сбережения ценных данных окончательно, то можно использовать Простую модель восстановления. Тогда в журнале будут записаны только те транзакции, которые активны сейчас (по каким-то причинам). Когда же логика сервера определит, что они более не нужны - журнал будет очищен, таким образом сохраняя свой (заданный) небольшой размер в файловой системе. В этом ее единственное преимущество. 

Кстати! Развею популярное заблуждение: Полная резервная копия базы данных не сохраняет все содержимое журнала транзакций, а только текущие транзакции (по сути - как при Простой модели) и заданный размер журнала.

Для тех, кому важно порой восстановить последовательность операций в каком-то разрезе, а с резервным копированием они разобрались в другом ключе, можно использовать третий режим - С неполным протоколированием. На момент времени посредством такого журнала базу данных не восстановить, но задача выяснить, как получилось то, что получилось - будет вполне решаема.

 

Глава 2. Подготовка к автоматизации резервного копирования

Для большинства случаев актуальна первая модель, поэтому ее и рассмотрим. Нам понадобятся:

1. Настроенная административная учетная запись SQL-сервера;

2. Место для хранения резервных копий;

3. Базовые навыки программирования (будут скрипты);

4. Учетная запись почты с паролем для приложения (желательно).

5. Установленная в Автоматический запуск служба Агент SQL Server (#ИмяВашегоЭкземпляраСервера#)

6. Последняя версия программы MSSQL Server Management Studio (сейчас 19.2) - все действия будут производиться в ней

Вообще, для резервного копирования журнала транзакций существует три варианта действий:

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

2. создание Плана обслуживания (вот, пример статьи по настройке таким способом)

3. создание резервных копий с применением языка T-SQL (план обслуживания тоже используется)

Третий вариант хорош тем, что позволяет нормальным образом обрабатывать ошибки на лету или, например, задавать свою маску файлов1.

Перед тем как приступить к его реализации, необходимо учесть момент, с которым нередко сталкиваются при использовании создания служебных копий баз данных с их переименованием: администраторы порой ограничиваются тем, что задают новое название в Обозревателе объектов, забывая о том, что для целей администрирования необходимо указать его и в реквизитах файлов. К счастью, можно написать довольно простую процедуру2 для такого переименования:

Выполнив данный скрипт на вашем сервере единожды (Alt+Т на русском, вставить текст и F5-Выполнить), вы сможете обеспечить благосостояние цветочных магазинов на долгие годы, потому что будете возвращаться домой счастливыми создать совсем уже простой скрипт для проверки и исправления этого неловкого момента (разумеется, если вы уже знаете как обойти весь список ваших рабочих баз, а не знаете - сейчас покажу):

 
Скрипт для исправления неактуальных логических названий файлов баз данных 

 

Глава 2 (с хвостиком) Добавление процедуры для отлова ВСЕХ ошибок при исполнении пакета инструкции

В ходе работы над статьей выяснилось, что системная переменная @@Error, как и все остальные источники информации об ошибках выдают либо только последнюю ошибку, либо свои независимые коды и текст содержания ошибки. В случае, например, если мы в течение дня обрезаем журнал регистрации у какой-либо базы, не создав при этом свежей полной резервной копии базы, мы получим ошибку 4214 (Инструкцию BACKUP LOG невозможно выполнить, так как не существует резервной копии текущей базы данных.). Но из кода этого не увидим, потому как там будет более общая и весьма, надо сказать, обширная по возможным проблемам ошибка 3013. Но ... мы же можем просто создать-таки полную копию и не мотать администратора (хотя метнуть ручкой, там - нет, я не призываю, но ...  можно). Поэтому, а также с целью получать более информативные сообщения об ошибках (вместо "Не удалось завершить задание. Запуск задания был произведен Расписание 9 (Рабочий.ВложенныйПлан_1). Последним выполнявшимся шагом был шаг 1 (ВложенныйПлан_1). ДЛИТЕЛЬНОСТЬ: 4 сек. ... ") воспользуемся методом, обнаруженном мною на сайте Пауло Сантоса (источник), только исправим небольшие ошибки и переведем на русский и рабочие рельсы - то есть обеспечим использование в скриптах автоматизации 3 степени (когда к их работе обращаются только при ошибках):

 
 Скрипт для вывода строк с сообщениями о всех ошибках в ходе исполнения инструкций одного пакета

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

Глава 3. Создание (настройка) планов обслуживания

0. Итак, надеюсь, самый первый скрипт (для создания процедуры переименования) вы уже выполнили, поскольку не добавить запуск данной процедуры в оба плана обслуживания будет неправильно - эта строчка там будет. Приступим!

1. Переходим в Управление / Планы обслуживания. Нажимаем правой кнопкой Создать план обслуживания, даем ему название.

2. Перед нами откроется вкладка с нашим планом, у которого необходимо задать три момента:

 

 

3. В Управлении соединениями вместо Проверки подлинности Windows указываем нашего администратора SQL, чтобы задание выполнялось независимо от факта присутствия непонятно зачем авторизованного на сервере администратора Windows:

 

 

4. Настраиваем Расписание. Я использую ежедневное, каждые 30 минут, с 4 утра до полуночи. В промежуток, не охватываемый заданием обычно выполняются регламентные задания, которые очень сильно увеличивают размер нашего журнала транзакций, но восстанавливать что-то на этот момент, как минимум странно, дальше объясню почему - мы это потом обрежем (не будем сохранять)

 

Расписание

 

5. Добавляем этап задания в область задач: идем Вид \ Панель элементов, разворачиваем Задачи плана обслуживания (если свернуты - не пугаемся) и переносим оттуда Задачу "Выполнение инструкций T-SQL". Естественно, изменяем ее название - на "Резервное копирование журналов транзакций пользовательских баз". Пишем скрипт, обращая внимание на переменную @ARCHIEVE_PATH, поскольку в ней хранится название вашего каталога с бэкапами для всех исследуемых баз (в скрипте автоматически подхватываются только пользовательские), а также название учетной записи оператора (для отправки сообщений по почте):

6. Сохраняем и в течение получаса получаем первую резервную копию журнала транзакций или выполняем задание вручную (из обозревателя объектов)

7. Итак, резервные копии журнала создаются, что дальше? Поскольку у нас Полная модель восстановления, при резервном копировании журнала транзакций, устаревшие (неактивные) транзакции из рабочего файла с расширением *.ldf удаляются (иногда чуть позже, логика сервера сама определяет подходящий момент), но файл может достаточно быстро разрастись при некоторых задачах (например, Реструктуризация таблиц), да и ночные "бдения" лучше поутру сразу забывать, поэтому нужно создать еще один план обслуживания - для очистки файла журнала транзакций и грамотного резервного копирования самой базы. Если у вас уже есть настроенный план ночного обслуживания базы данных, сами выбирайте куда добавить следующий скрипт, но я предлагаю добавлять его в конце, поскольку начальное состояние базы до всех регламентных операций можем получить из вчерашней полной резервной копии и архивов журналов транзакций, а новую копию лучше делать после всех действий - для очистки их следов и уборки одноразовой посуды. Так что создаем (если нет) новый план обслуживания, теперь уже ночного и добавляем туда инструкцию SQL следующего содержания:  

Данный скрипт, проверяет и в случае расхождения исправляет на актуальное название базы данных, меняет модель восстановления на Простую, сжимает (обрезает) файл журнала транзакций и возвращает на место указанную Вами(!) Полную модель восстановления (все облегченно выдыхают) и сохраняет резервную копию уже самой базы данных. Для обслуживания всех пользовательских баз используется обход по курсору базы данных (@DBCURSOR), из которого мы берем название базы (@dbName) и вставляем в команду обслуживания вместе с сгенерированным именем резервной копии - выполняем!

 

Глава 4. Настройка оповещений по почте при ошибках (неисправленных)

Раз уж мы настроились на спокойное и уверенное администрирование, было бы неплохо сделать оповещение об ошибках в выполнении наших Планов обслуживания. Особо рассказывать не буду, Мастер настройки компонента Database Mail достаточно простой и удобный, просто расскажу основные шаги:

1. Находите в Обозревателе объектов раздел Управление элемент Компонент Database Mail, щелкаете по нему правой кнопкой - Настроить ... - запускается Мастер, в котором нам в общем случае нужно выбрать первый пункт, т.е. создать новый профиль (название запомните), ввести для него настройки доступа к почте по кнопке Добавить, у меня такие:

 

Настройки профиля почтовых оповещений

 

4. На следующем экране указать данный профиль для отправки по умолчанию:

 

 

3. Добавить оператора оповещений с указанием допустимых дней и времени отправки оповещений. Находим в Обозревателе объектов Агент SQL Server / Операторы - щелкаем правой кнопкой Создать, заводим имя, почту и время отправки оповещений

4. Включить оповещение о предупреждениях в ходе работы Агента SQL Server, который, собственно, и выполняет Планы обслуживания, - щелкаем по нему правой кнопкой, заходим в Свойства и указываем следующее:

 

Настройка возможности отправки предупреждений на почту Агентом

 

5. Ну а дальше осталось только в том же разделе Агент SQL Server раскрыть ветку Задания, найти там свое и в его Свойствах настроить уведомления:

 

Включение уведомлений для задания

 

6. Радоваться, мы закончили!

Глава 5. Заключение

Что хотелось бы сказать насчет выбора момента создания резервной копии. Словами "он важен" мы выскажем только наши догадки, а если по делу, то необходимо понимать, что программная логика сервера SQL, конечно, умна, но она не может знать и учитывать логики прикладного решения, поэтому, например, создав полную резервную копию во время выполнения сложных расчетов (но без архива журнала транзакций) мы рискуем при восстановлении такой копии получить некое переходное состояние, вот только сложный расчет уже запущен не будет и "досчитать" свою работу не сможет - только если будет запущен снова (если все срастется, ведь программисты были правильные). Механизмы SQL уже используют журнал транзакций для правильного сохранения резервной копии базы данных (если коротко: пока база пишется, она может быть изменена "сотни" раз, а для сохранения копии на конкретный момент времени подхватываются свежие транзакции из журнала - для приведения в соответствие). Хорошее дело - присоединяемся:

 
Скрипт для получения таблицы поминутной статистики количества транзакций по архивной копии Журнала

Выполнив данный скрипт единожды, далее мы сможем запускать данную процедуру, указывая только последнюю строку с полным названием файла архива, чтобы даже при достаточно большом объеме всех сохраненных получасовых копий журнала и сложности в определении подходящего момента в Журнале регистрации 1С (ну вдруг, мало ли - я вообще-то для другого с этим ковырялся, но должно же это кому-то пригодиться))). В результате получаем результат, по которому нам понятно, что первые 7 минут сервер "отдыхал" - "действие" началось позже:

 

Таблица количества транзакций по минутам

 

1. Хотелось сделать наименование архивов журналов, включающие поминутную нагрузку в виде количества транзакций в текущей базе, для более уверенного восстановления (если не на случай ЧП - в таком случае обычно все же на события опираются, но когда хочется получить базу на момент затишья), но выяснилось вполне благоразумная вещь: текущий журнал транзакций оптимизирован для максимально быстрой записи, а читается медленно, а вот архивная копия оптимизирована разработчиком уже в обратном направлении, причем разница в разы, почти на порядок в моем случае (например, архив лога на 30 ГБ и 6 миллионов записей анализируется за 8 минут, а тот же лог до архивирования - 74 минуты - есть разница?). Так что отступать от тактики, предложенной разработчиком, и создавать дополнительную нагрузку при сохранении копии не стал и другим советовать не буду.

2. Очень полезно хранить полезные скрипты где-нибудь, но бывает еще удобнее создать процедуру с понятным именем и просто вызывать ее при необходимости, тем более для нее можно указывать входные параметры.

 

Постскриптум

Если вы внимательно читали, то наверняка заметили, что в ходе написания статьи возникла проблема, требующая тщательного изучения и разработки - отображалась только крайняя ошибка из происшедших в ходе выполнения инструкции, а она не самая важная. Так вот указанное в статье решение ущербное, поскольку требует выполнения нескольких команд и не забывать про очистку буфера, не учитывает очередность сообщений, когда в ходе их записи в буфер произошел переход с конца буфера в его начало и, как было замечено неоднократно, почему-то иногда смесь команд, очистки буфера и особенностей выполнения приводит к тому, что сообщения не ловятся (в буфере появляются в урезанном виде или не появляются вовсе). Поэтому было придумано решение: требующие проверки на ошибки команды передаются на вход процедуры в виде текста, а там внутри уже происходит небольшая магия с метками начала и окончания отслеживания ошибок и на выход выдается итоговый текст. Так сообщения будут "отфильтрованы" (за неполным исключением ошибок, крушащих пакет) и код упростится до такого вызова:

EXEC dbo.uspExecWithErrorListing @command, @errorText OUT

Текст процедуры поиска сообщений об ошибках там также переписан, но утратил свою первоначальную лаконичность (нравятся мне эти ветки - хоть убейте!). По этой причине и возросшей сложности решения (около десятка служебных процедур) в статью не включаю. Приведенное решение можно скачать с "нашего" GIT-агрегатора по ссылке scholarnick/SQL Output Message Listing: Чтение сообщений (gitflic.ru)

резервирование восстановление момент времени T-SQL администрирование

См. также

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

19200 руб.

15.05.2017    42322    10    24    

38

BackUPv8 - система резервного копирования баз 1С

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014    14600    11    6    

15

Инструкция по установке Postgres для OLTP приложений и 1С. Часть 1. Базовая конфигурация

Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

В Postgres достаточно подробная документация, и, видимо, поэтому при инсталляции Postgres для 1С большинство параметров приходится выставлять самим. Параметров в Postgres много, а составить эффективную комбинацию не так просто. Все упрощается, если рассмотреть профиль нагрузки, например, 1С это прежде всего профиль OLTP нагрузки – так устроены его метаданные (объекты). Если сосредоточиться на оптимизации профиля OLTP, понимание Postgres сразу упростится.

15.02.2024    1979    1CUnlimited    14    

26

Как запустить сервер лицензирования 1С на примере облачной платформы

Администрирование СУБД Россия Бесплатно (free)

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

25.01.2024    1383    doctor_it    15    

16

Обслуживание индексов MS SQL Server: как, когда и, главное, зачем?

Администрирование СУБД Бесплатно (free)

Казалось бы, базовое знание: «индексы надо обслуживать, чтобы запросы выполнялись быстро». Но обслуживание индексов выполняется долго и может мешать работе пользователей. Кроме того, в последнее время популярны разговоры о том, что индексы можно вообще не обслуживать – насколько это оправданно? Рассмотрим: на что влияет обслуживание индексов, когда надо и когда не надо его выполнять, и если надо – как это сделать так, чтобы никому не помешать?

16.01.2024    4995    Филин    10    

42

Мигрируем с MS SQL на PostgreSQL

Администрирование СУБД Бесплатно (free)

Переход с MS SQL на PostgreSQL сопряжен с рисками для бизнеса и неизбежно вызывает множество вопросов. Статья посвящена тому, как заранее подготовиться к предстоящей миграции, провести нагрузочное тестирование, выявить возможные проблемы перехода и провести необходимую оптимизацию.

13.11.2023    9663    ivanov660    31    

72

Неочевидный баг Истории данных, убивающий rphost

Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Расследование о том, почему команда ИсторияДанных.ОбновитьИсторию() убивала rphost.

08.11.2023    5833    dsdred    48    

71
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. redfred 04.12.23 13:27 Сейчас в теме
Понятно желание написать собственный велосипед, чтоб разобраться в теме, но уж лучше бы на примере настройки скриптов Халленгрена проиллюстрировали
7. JohnyDeath 301 04.12.23 17:22 Сейчас в теме
(1) я тоже ими пользуюсь. Отличный инструмент.
Если вдруг кто не знает: https://ola.hallengren.com/sql-server-backup.html
Там есть и FULL, и DIFF, и LOG.

И до кучи скрипт, который восстанавливает последнюю копию, собирая их из FULL+ все последующие DIFF/
Этим же скриптом можно быстренько развернуть самую свежую копию рабочей базы ;)
EXEC dbo.sp_DatabaseRestore 
  @Database = @ibNameSource, 
  @RestoreDatabaseName = @ibNameTarget,
  @BackupPathFull = @pathFull,
  @BackupPathLog = @pathLog,
  @ContinueLogs = 0, 
  @RunRecovery = 1;
;

Для работы требуется установка хранимок от https://www.brentozar.com/ . Но это вообще "мастхев" набор для любого сервера MSSQL
user2024794; olexi2012; webester; artbear; ardn; n_mezentsev; +6 Ответить
2. maksa2005 525 04.12.23 13:35 Сейчас в теме
Сколько sql поднимал никогда не пользовался почтовым агентом. Почему? то ли у меня руки не правильно росли в его настройки, то ли он не работает должным образом. Да и почта уже старый стек технологий
4. n_mezentsev 23 04.12.23 13:46 Сейчас в теме
(2)Да, у меня тоже не сразу поднялось - выяснилось, что почему-то несмотря на SSL работает только на порту 25 и/или не терпит изменения некоторых настроек - только новый профиль. Плюс "Настройка безопасности профиля" - поставить по умолчанию. А так, по мне - получать письмо с подробным описанием ошибок куда приятнее ждать проявления проблем, а уж по телеге или по почте - на моем телефоне - и то, и другое мигом)
JohnyDeath; +1 Ответить
5. redfred 04.12.23 13:53 Сейчас в теме
И каким путём получаете уведомления о проблемах?
6. n_mezentsev 23 04.12.23 13:57 Сейчас в теме
(1)
(5)Глава 4 (настройка профиля и привязка к Агенту + по условию отправка сообщения из скрипта (встроенная функция)
 EXECUTE msdb.dbo.sp_notify_operator @name=N'ВашаУчетнаяЗапись',	@subject=@errorText, @body=@messageText;
10. redfred 05.12.23 08:39 Сейчас в теме
(6)
(6) Я интересовался у человека который почту считает устаревшей
13. JohnyDeath 301 05.12.23 15:19 Сейчас в теме
(10) очевидно, что основной канал оповещения о проблемах - "звонок от пользователя" )
15. user2024794 07.12.23 10:11 Сейчас в теме
(13) есть же Мойра и Графана, они прекрасно в телегрм шлют алерты
16. redfred 08.12.23 16:25 Сейчас в теме
(15)
есть же Мойра и Графана, они прекрасно в телегрм шлют алерты


Если у меня джоб в агенте поломался - пришлют? Как они это мониторят?
3. n_mezentsev 23 04.12.23 13:41 Сейчас в теме
(1) За скрипты Ола Халленгрена спасибо - здорово, когда свой опыт перекладывают на подобные библиотеки - прям беговые дорожки для интересующихся (спортом), а насчет статьи - изначально цель донести важность резервного копирования журнала транзакций. А уж почему стандартного меню-функционала для полноценной работы не хватило - хочется действительно настроить и забыть, чтобы не играть в небольшую лотерею каждое утро
8. user2023479 05.12.23 01:03 Сейчас в теме
Человек открыл для себя резервное журнала транзакций, шёл 2023 год... Статей по резервному копированию уже стопицот миллионов...
Я-то думал, что ещё куда-то завезли, где не было..
11. n_mezentsev 23 05.12.23 10:10 Сейчас в теме
(1)
(8)Когда писал статью, вспоминал майские лекции 2008 года... А так благодаря скриптам есть небольшая изюминка - если в течении дня кто-то использовал шринк или что-то делал с резервными копиями - процесс резервирования журнала транзакций не прервется - благодаря более полному отлову ошибок, но я не убеждаю, просто сейчас такое время, мне кажется, когда впору вспомнить - а за что же мы ценим MS SQL и с этим багажом идти...
9. kpdozer 05.12.23 08:04 Сейчас в теме
Спасибо за статью.
Правда не совсем понял зачем вы изначально полную модель использовали если не бекапили + очищали журнал? В чем ее преимущество в этом случае?
12. n_mezentsev 23 05.12.23 10:13 Сейчас в теме
(9)Не поверите - в небольших фирмах, где у тебя очень много мелких обязанностей, многие вещи делаешь просто потому, что так было заведено. Да и не забывайте, если с диском и базой не все так плохо, никто не мешает на ходу сделать бэкап журнала - и после этого пытаться восстановить на момент времени.
14. пользователь 07.12.23 10:07
Сообщение было скрыто модератором.
...
Оставьте свое сообщение