Комментарии 17
Насколько мне известно, в tempdb всегда используется DD. Собственно, исторически там она и возникла, а потом эту опцию вынесли и для других баз
Мне не очень понятно, о каких проблемах при восстановлении с DD вы говорите. С DD любая транзакция либо записана, либо незаписана целиком. Проблемы возможны либо по согласованности с внешними системами, либо по нарушению каких то договорённостей верхнего уровня внутри базы, но тогда сразу вопрос, если важна согласованность, то почему это делается в разных транзакциях, а не одной?
На SQL 2019 на tempdb Delayed durability стоял по умолчанию в Disabled. Понятно что там мы вообще ничего не потеряем даже если tempdb держать в оперативной памяти. Но для порядка поставил в forced
Проблемы восстановления о которых я говорил на уровне объектной модели, например документ и регистр сведений которые на субд отражаются в несколько таблиц. Да формально можно изменение обоих объектов заключит в транзакцию, но фактически при разработке это не всегда удобно. Особенно если делать параллельную обработку наборами объектов. И поэтому возникает понятие согласованность на уровне ORM , я привел пример в конце статьи. Те кто постоянно работает с ORM меня поймут
На tempdb DD всегда включен, а опции DD в GUI игнорируются для этой базы (типа магия)
Если вас важно согласование многих транзакций, то чем это отличается от случаев: Disaster recovery с асинхронным always on, когда часть транзакций может быть потеряна? Или восстановление из бэкапа, где кусок после последнего transaction log может быть потеряна? Или краха самой 1С посередине работы? DD здесь ни при чем, он просто повышает вероятность некоторых вещей
Если вас важно согласование многих транзакций, то чем это отличается от случаев: Disaster recovery с асинхронным always on, когда часть транзакций может быть потеряна? Или восстановление из бэкапа, где кусок после последнего transaction log может быть потеряна?
Просто код для связанных объектов как правило последовательный,
НачатьТранзакцию();
ДокументОбъект.Записать();
ЗавершитьТранзакцию();
//Подтоговка данных для записи в регистр, запросы на чтение справочников
НачатьТранзакцию();
НаборЗаписей.Записать();
ЗавершитьТранзакцию();А Delayed durability с большой вероятностью распараллелит фиксацию. Т.е. без DD я в праве ожидать, что только набор записей в регистр не запишется. А с DD тут лотерея может либо документ либо набор записей. Мы же не знаем как внутри он организован, а несколько фактических сессий 1С могут висеть на одном rphost который и общается с MS SQL
В доке от МС написано, что при DD транзакции помещаются в буфер в оперативке, а на диск попадают при заполнении буфера, либо, как было указано, при ручном sp_flush_log.
В вашем сценарии обе транзакции попадут в этот буфер - и я сомневаюсь, что если закоммитится транзакция 2, то транзакция 1 пропадёт. Всё-таки содержимое буфера (с обеими транзакциями) будет записываться на диск целиком.
DD в SQL Server увеличивает риски в сценарии "выдернули вилку из розетки". И только. В классическом варианте закоммиченные транзакции сразу попадают на диск (в лог транзакций) и если серсис СУБД резко остановится, их можно будет восстановить по логу. В случае DD есть риск, что транзакции не попадут в лог и будут утеряны навсегда
По сути, тут идёт размен RPO на скорость параллельной работы пользователей. По моему опыту, в OLTP чаще выбирали RPO, но кто-то может позволить себе повысить риски за счёт общего ускорения. В любом случае, это нужно обсуждать с бизнесом
В принципе , если делать асинхронную репликацию с задержкой 2 минуты для меня бы DD сталобы полностью надежным и отказоустойчивым. Но для 1С нужно смотреть в сторону Postgres и как там с этим обстоит дело, поскольку MS и Oracle для РФ уже будут только на существующих инсталляциях
Другими словами: "для меня RPO в 2 минуты - это допустимый сценарий" (и ещё раз: а что по этому поводу думает бизнес?)
В PG, судя по описанию, механизм работает аналогично (оно и понятно, идея-то простая). Поэтому первоначальный вопрос должен стоять так же: могу ли я (и бизнес!) позволить себе безвозвратную потерю нескольких последних минут работы пользователей? А дальше уже - детали реализации.
Такая нагрузка как правило создается автоматической генерацией движений либо перерасчетами. В мире 1С легко согласятся. Озоны Амазоны где миллионы пользователей, это другая лига у них хватит денег на Oracle RAC либо сами напишут Migrate from Oracle RAC to AWS: Alternatives on AWS | AWS Database Blog (amazon.com)
Однако можно выбирать при начале транзакции ее тип, если не использовать forced. Ну и всякие данные типа кликов и лайков точно можно и нужно с DD
Oracle RAC - далеко не панацея, проблем у него хватает. По сути, сейчас RAC используется больше для отказоустойчивости, чем для масштабирования. Идея кластера провалилась, и виной тому - реализация менеджера блокировок в Oracle. DB2 горизонтально масштабируется лучше, но у IBM хуже с маркетингом. Слышали ли вы что-то про DB2 PureScale? То-то же.
А вообще у вас получается очень интересный цикл статей. Но боюсь, без переписывания самого ORM 1С кардинально проблему производительности не решить.
DB2 горизонтально масштабируется лучше, но у IBM хуже с маркетингом. Слышали ли вы что-то про DB2 PureScale? То-то же.
Видимо с маркетингом да, я ведь искал альтернативы Oracle RAC и IBM там не загуглился. Почитал Распределённые СУБД для энтерпрайза / Хабр (habr.com) открыл для себя много нового. По поводу реализации Oracle RAC это личный опыт? или проверенная информация из других источников.
Что касается IBM DB2 - 1С поддерживает ее, но для меня IBM всегда ассоциировался с завышенными ценниками и ореолом какой то элитности, которая не сочетается с 1С даже на больших объемах поэтом для проектов ее даже не рассматривал.
Почитал Распределённые СУБД для энтерпрайза / Хабр (habr.com) открыл для себя много нового.
Хорошая статья, да :))
По поводу реализации Oracle RAC это личный опыт
Это и чтение документации и статей, и личный опыт, и рекомендации Oracle ACS.
и ореолом какой то элитности,
Нет там никакой элитности. Рынок баз данных IBM сдала Oracle почти без боя. Насколько я понимаю, даже Informix, который был куплен IBM‘ом, был популярнее, чем DB2. DB2 весьма популярна на мэйнфреймах (System z) и AS/400 (которые System i) в виду отсутствия внятных альтернатив и традиций, уходящих корнями глубоко_в. А DB2/LUW – какое-то нелюбимое дитя.
Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать …