Комментарии 3
Насколько мне известно, в 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 здесь ни при чем, он просто повышает вероятность некоторых вещей
Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать …