1. SantiouS 08.10.19 10:59 Сейчас в теме

Бэкапы SQL 2014 & 1c

В SQL 2014 есть три варианта бэкапа:
- полный;
- разностный;
- журнала транзакций.
Для восстановления в любом случае должен быть полный бэкап БД, к которому можно добавить уже разностные, либо журнала транзакций.
Вот например я в 5:00 сделал полный бэкап, и после планом обслуживания каждый час делал разностные и журналы транзакций. Какая разница будет при восстановлении с бэкапа в 22:13, если я возьму связку полного бэкапа, созданного в 5:00 и всех часовых разностных, ЛИБО полного бэкапа, созданного в 5:00 и всех часовых журналов транзакций?
Какая разница между разностным и журналом транзакций? Все утро читаю и никак не могу понять.
Найденные решения
12. nomad_irk 40 08.10.19 12:54 Сейчас в теме
(11) Скажем так: то, что разностный бэкап нагружает систему - без сомнения.

Всех тонкостей не знаю, но в общем понимаю происходящее следующим образом:

Для создания разностного бэкапа СУБД должна знать идентификатор транзакции, на которую был сделан предыдущий разностный бэкап и идентификатор транзакции, на которую будет выполнен текущий. Все факты изменения таблиц/записей в таблицах при этом находятся в журнале транзакций, при этом не важна динамика изменений данных, а важно состояние на момент предыдущего бэкапа и текущего.

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

Другими словами: в первом случае необходимо сравнить два состояния БД, разнесенных во времени, понять, где произошли изменения и сохранить только измененные данные(их текущие значения), в другом случае необходимо постоянно держать некий объем данных + накапливать данные с минимально возможными задержками.
SantiouS; +1 Ответить
Остальные ответы
Избранное Подписка Сортировка: Древо
3. EVKash 3 08.10.19 11:36 Сейчас в теме
4. SantiouS 08.10.19 11:37 Сейчас в теме
(3) Спасибо, прочитаю. На инфостарте тоже есть замечательная статья: https://infostart.ru/public/101210/
Но именно особенность, которую спросил, так и не понял.
2. nomad_irk 40 08.10.19 11:27 Сейчас в теме
с помощью бэкапа транзакций вы сможете восстановить данные с точностью до транзакции. Из разностного - только на момент создания разностного бэкапа.
5. SantiouS 08.10.19 11:40 Сейчас в теме
(2) Бекап транзакции тоже будет ведь иметь транзакции только до момента создания этого бєкапа :)
Как я понимаю, то разностные бэкапы актуальны только для простой модели восстановления (в которой журнал транзакций грубо говоря не ведется). Также разностный бэкап еще целесообразнее использовать, так как с ним разворачивается все быстрее чем с кучей бэкапов файлов транзакции.
Вот это как я понимаю, думал узнать остаточный вопрос у понимающих людей :)
6. nomad_irk 40 08.10.19 11:43 Сейчас в теме
(5)Понятие быстро-медленно напрямую зависит от количества этих самых бэкапов разностных/журналов транзакций. Если точность восстановления данных до транзакции не важна, то делайте разностные бэкапы.
7. SantiouS 08.10.19 11:47 Сейчас в теме
(6) Например у меня люди активно работают в бд. В 4:00 я сделал полныйбэкап.
Два варианта:
1) В 5:00 я делаю разностный бэкап в 5:00 и получаю файл.
2) Делаю в 5:00 бэкап журнала транзакций и получаю файл.
Если я возьму фулл бэкап и файл транзакций = получаю БД.
Если я возьму фулл бэкап и разностный бэкап = получаю БД.
Как будет прослеживаться в них разница?
8. nomad_irk 40 08.10.19 12:15 Сейчас в теме
Говорю же, разница будет в возможности указать идентификатор транзакции, на момент которой произойдет восстановление БД из бэкапа в случае 2).
В случае 1) база восстановится ровно на момент создания разностного бэкапа.

Если за период с 4:00 до 5:00 в базе зарегистрирована одна транзакция, то разницы не будет вообще никакой.
9. SantiouS 08.10.19 12:25 Сейчас в теме
(8) То есть журнал транзакций делается не нагружая систему, в отличии от разностного бэкапа, но ещё и более гибкий при развертывании?
10. nomad_irk 40 08.10.19 12:35 Сейчас в теме
(9)Ну как сказать "не нагружая систему".....Если в вашем понимании "возможность держать объем данных больше, чем в самой БД где-то рядом с данными БД" + накапливать данные с максимально возможной скоростью, иначе будет все тупить, есть "не нагружая систему", хорошо, пусть будет так.
Более гибкий - да, но нужна ли такая гибкость в случае с 1С - вопрос скорее риторический :)
SantiouS; +1 Ответить
11. SantiouS 08.10.19 12:39 Сейчас в теме
(10) Везде написано что разностный бэкап нагружает систему, а бэкап журнала транзакций вовсе не ощущается пользователями и его можно делать хоть каждые 5 минут. Что имеется виду под "нагружает систему" - интересный вопрос, но как я понимаю, то это тормоза при роботе в 1с (в моем случае). Да и про вес ваше сравнение не совсем понял, Вы имеете ввиду что разностный бэкап за 1 час работы будет весить меньше чем журнал транзакции за тот же час?
12. nomad_irk 40 08.10.19 12:54 Сейчас в теме
(11) Скажем так: то, что разностный бэкап нагружает систему - без сомнения.

Всех тонкостей не знаю, но в общем понимаю происходящее следующим образом:

Для создания разностного бэкапа СУБД должна знать идентификатор транзакции, на которую был сделан предыдущий разностный бэкап и идентификатор транзакции, на которую будет выполнен текущий. Все факты изменения таблиц/записей в таблицах при этом находятся в журнале транзакций, при этом не важна динамика изменений данных, а важно состояние на момент предыдущего бэкапа и текущего.

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

Другими словами: в первом случае необходимо сравнить два состояния БД, разнесенных во времени, понять, где произошли изменения и сохранить только измененные данные(их текущие значения), в другом случае необходимо постоянно держать некий объем данных + накапливать данные с минимально возможными задержками.
SantiouS; +1 Ответить
13. SantiouS 08.10.19 13:08 Сейчас в теме
(12) Очень интересно. Спасибо Вам большое что делитесь своим опытом. Возник ещё один вопрос. Сейчас мы общались скорее о БД, которая настроена на полную модель восстановления.
Если перевести такую БД в модель с неполным протоколированием (с помощью этой модели можно восстанавливать все данные, но невозможно восстановить только часть резервной копии, например выполнить восстановление до определенной метки), то мы получается на выходе имеем журнал транзакций и разностны бэкапы, которые равны по полезности для восстановления :) Так получается? Что думаете?
14. nomad_irk 40 08.10.19 13:26 Сейчас в теме
(13) При неполном протоколировании журнал транзакций носит скорее формальный характер. Да, в нем есть данные о том, какие транзакции были зафиксированы/отменены, но они нужны только для самой СУБД по-сути, чтобы делать эти самые разностные бэкапы. Для восстановления БД бэкап журнала транзакций в данном случае бесполезен, ну разве что, для случая, когда произошло повреждение файла журнала транзакций.
SantiouS; +1 Ответить
15. SantiouS 08.10.19 13:39 Сейчас в теме
(14) Но при неполном протоколировании я ведь могу все так же взять full бекап и журналі транзакций и восстановить БД на момент последнего журнала транзакций?
16. nomad_irk 40 08.10.19 13:43 Сейчас в теме
(15)Нет, на то оно и не полное протоколирование: регистрируется только сам факт транзакций, нет динамики изменений данных.
В этом случае есть возможность восстановиться только из full-бэкапа.
17. SantiouS 08.10.19 13:51 Сейчас в теме
(16) Понял. Немного резюмирую. Надеюсь я все правильно осознал :)
Получается есть 3 модели:
- Простая;
- Полная;
- С неполным протоколированием.
В простой вообще не ведется журнал транзакций.
В полной ведется полностью и им можно восстановиться.
В "с неполным протоколированием" журнал ведется, но разве что только для каких то служебных целей и для восстановления не может быть использован.
Выходит "добавкой" для всех моделей может быть разностный бэкап, а журнал транзакций только "добавка" для полной модели.
Верно?
18. SantiouS 08.10.19 13:52 Сейчас в теме
(16) Хотя все же нет. Я не прав. Вот:
Подобно полной модели восстановления, в модели восстановления с неполным протоколированием для восстановления базы данных используются резервные копии как базы данных, так и журнала. Однако в модели восстановления с неполным протоколированием требуется меньше места для следующих операций: CRE ATE INDEX, операции массовой загрузки, SELECT INTO, WRITETEXT и UPDATETEXT. Вместо хранения в журнале сведений об операциях в нем отмечается только наличие этих операций в виде разрядов в экстентах.

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

С помощью этой модели можно восстанавливать все данные, но невозможно восстановить только часть резервной копии, например выполнить восстановление до определенной метки.
19. nomad_irk 40 08.10.19 14:07 Сейчас в теме
Если в этих терминах говорить, то:
Простая - журнал транзакций чисто номинальный, бэкап журнала транзакций не возможен средствами СУБД.
С неполным протоколированием - журнал транзакций номинальный для случаев массовых изменений данных. Список таких изменений в документации на MSDN. Журнал транзакций ведется полностью для "обычных" изменений данных, и отражает факт "массовых" изменений данных. Восстановить сами данные(их последние значения) изменненных массово на момент транзакции нельзя, придется повторить массовое изменение данных. Бэкап журнала транзакций возможен, если необходимо восстанавливаться с точностью до транзакции.
Полная - журнал транзакций ведется полностью и с него можно восстановиться с точностью до транзакции.

При всем этом разностный бэкап возможен в любом из вариантов модели восстановления.

В случае с 1С, последние два случая - ну такое себе занятие. Массовых изменений точно не будет как класса, потому что 1с не умеет это делать от слова совсем.
SantiouS; +1 Ответить
20. SantiouS 08.10.19 14:40 Сейчас в теме
(19)
журнал транзакций номинальный для случаев массовых изменений данных. Список таких изменений в документации на MSDN. Журнал транзакций ведется полностью для "обычных" изменений данных, и отражает факт "массовых" изменений данных. Восстановить сами данные(их последние значения) изменненных массово на момент транзакции нельзя, придется повторить массовое изменение данных. Бэкап журнала транзакций возможен, если необходимо восстанавливаться с точностью до транзакции.


Все верно. В журнале транзакций при неполном протоколировании будет не последовательность операций, а грубо говоря их результат за период, по этому мы можем по журналу транзакций только на последний момент журнала переместиться, а не на его середину. Так, например 01.01.2019 в 5:00 фулл бекап, а в 5:05 транзакции. При полной модели можно на 5:03, например откатиться, а при неполном протоколировании только грубо на 5:05.
Думаю это сложные дебри начинаются )))
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Технический лидер, архитектор 1С, руководитель проектов
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Консультант-аналитик 1С
Набережные Челны
зарплата до 90 000 руб.
Полный день

Программист 1С
Набережные Челны
зарплата от 40 000 руб. до 110 000 руб.
Полный день

Программист 1С
Казань
зарплата от 40 000 руб. до 110 000 руб.
Полный день

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству