Может кто-нибудь рассказать что-то про эту фичу (https://docs.microsoft.com/en-us/sql/relational-databases/logs/control-transaction-durability?view=sql-server-2017)?
1) Действует ли она на любые типы таблиц в базе?
2) Насколько в целом это безопасно, если сбоев сервера, фактически, не бывает?
3) Что означает "Only transactions that have been made durable are included in the backup. " — что в бэкап логов транзакции попадут в момент фактической записи на диск, или что они вообще не будут в нём отражены?
Здравствуйте, Somescout, Вы писали:
S>1) Действует ли она на любые типы таблиц в базе?
При чем здесь таблицы когда эта опция для транзакций?
S>2) Насколько в целом это безопасно, если сбоев сервера, фактически, не бывает?
Даже презерватив не дает полной гарантии...
S>3) Что означает "Only transactions that have been made durable are included in the backup. " — что в бэкап логов транзакции попадут в момент фактической записи на диск, или что они вообще не будут в нём отражены?
Может попадут а может и нет, на то он и отложенный коммит... Т.е. клиету/приложению может придти коммит а в базе его не будет, в том вся и соль... Там вроде доступно же в статье все описано...
Здравствуйте, Somescout, Вы писали:
S>1) Действует ли она на любые типы таблиц в базе?
Ограничений я не встречал, да и не должно их быть, т.к. данный режим может устанавливаться на БД в принудительном порядке для всех транзакций.
S>2) Насколько в целом это безопасно, если сбоев сервера, фактически, не бывает?
Это не безопасно при любых раскладах, существует риск потерять данные. Здесь нужно понимать процессы, которые происходят при использовании отложенных транзакций, а они просты. Вызывая инструкцию COMMIT TRANSACTION WITH (DELAYED_DURABILITY = ON) вы получаете управление обратно в программу, не дожидаясь завершения транзакции, точнее записи в журнал транзакций. Все изменения фиксируются в буфере и только после наступления определенного события (свободный размер буфера заканчивается или выполнили полную транзакцию или явно вызвали сброс буфера) пишутся на диск (в журнал транзакций). Соответственно в случае, если до сброса буфера с отложенными транзакциями на диск (в журнал транзакций) произойдет сбой, например, отключили электричество, то данные будут утеряны, т.к. их просто неоткуда взять при восстановлении (операции Undo/Redo).
S>3) Что означает "Only transactions that have been made durable are included in the backup. " — что в бэкап логов транзакции попадут в момент фактической записи на диск, или что они вообще не будут в нём отражены?
Как я понял (догадался или предположил) — в бэкап попадут только те транзакции, которые были записаны на диск (журнал транзакций).
Спасибо за ответ.
S>>2) Насколько в целом это безопасно, если сбоев сервера, фактически, не бывает?
O>Это не безопасно при любых раскладах, существует риск потерять данные. Здесь нужно понимать процессы, которые происходят при использовании отложенных транзакций, а они просты. Вызывая инструкцию COMMIT TRANSACTION WITH (DELAYED_DURABILITY = ON) вы получаете управление обратно в программу, не дожидаясь завершения транзакции, точнее записи в журнал транзакций. Все изменения фиксируются в буфере и только после наступления определенного события (свободный размер буфера заканчивается или выполнили полную транзакцию или явно вызвали сброс буфера) пишутся на диск (в журнал транзакций). Соответственно в случае, если до сброса буфера с отложенными транзакциями на диск (в журнал транзакций) произойдет сбой, например, отключили электричество, то данные будут утеряны, т.к. их просто неоткуда взять при восстановлении (операции Undo/Redo).
Питание серверной резервируется двумя УПСами + генератором, программных сбоев пока не было. Так что со стороны аппаратной части ничего вроде не грозит.
S>>3) Что означает "Only transactions that have been made durable are included in the backup. " — что в бэкап логов транзакции попадут в момент фактической записи на диск, или что они вообще не будут в нём отражены?
O>Как я понял (догадался или предположил) — в бэкап попадут только те транзакции, которые были записаны на диск (журнал транзакций).
Вот тоже не понимаю этой фразы — очень расплывчато. Логически это должно означать именно транзакции записанные на диск, иначе при delayed_durability = forced, в лог бы вообще ничего не попадало. Буду тестировать.
Ещё такой вопрос: а если операция обновления (или вставки) идёт внутри большой и долгой транзакции, будет ли на неё влиять этот параметр? То есть стартует транзакция в полчаса длительностью, и в процессе неё происходят запросы, вставка новых данных и т.п. — но, как мне кажется, Durability должна обеспечиваться именно в конце транзакции при выполнении commit'а, а не при каждой вставке данных. Так ли это и так ли это на практике с SQL Server?
Здравствуйте, Somescout, Вы писали:
S>Питание серверной резервируется двумя УПСами + генератором, программных сбоев пока не было. Так что со стороны аппаратной части ничего вроде не грозит.
Очень сильное заблуждение. Мат. часть может отказать и при наличии электропитания.
O>>Как я понял (догадался или предположил) — в бэкап попадут только те транзакции, которые были записаны на диск (журнал транзакций).
Совершенно верно. Причем перед бэкапом сброс лога на диск автоматом не идет. По крайней мере, такой вывод можно сделать из прочтенной документации.
S>Вот тоже не понимаю этой фразы — очень расплывчато. Логически это должно означать именно транзакции записанные на диск, иначе при delayed_durability = forced, в лог бы вообще ничего не попадало. Буду тестировать.
С чего вдруг? Попасть должно в итоге всё (при отсутствии сбоев, разумеется). Просто клиент не будет ждать, пока оно на диск попадет. И ты рискуешь потерять именно те данные, что клиент изменил, но лог пока не записал на диск. Лог записывается при delayed durability при достижении чего-то одного — либо набора данных достаточно большого размера (чтобы получить преимущество batched дисковой операции), либо по таймеру (что бы не терять давно закоммиченные данные, если обновлений мало). Еще можно вручную это сделать через sys.sp_flush_log.
S>Ещё такой вопрос: а если операция обновления (или вставки) идёт внутри большой и долгой транзакции, будет ли на неё влиять этот параметр? То есть стартует транзакция в полчаса длительностью, и в процессе неё происходят запросы, вставка новых данных и т.п.
Клиент будет всё это ждать вплоть до коммита. Просто коммит не пишется синхронно на диск во время транзакции, вот и вся разница в скорости.
S> — но, как мне кажется, Durability должна обеспечиваться именно в конце транзакции при выполнении commit'а, а не при каждой вставке данных. Так ли это и так ли это на практике с SQL Server?
Блин, вот не помню уже тонкостей традиционной записи в лог... Т.е., обеспечивается-то она при коммите, но вот как именно всё записывается в файл лога — операция за операцией синхронно, или может ждать записи на диск вплоть до коммита — я уже не помню.
Здравствуйте, _ABC_, Вы писали:
S>>Питание серверной резервируется двумя УПСами + генератором, программных сбоев пока не было. Так что со стороны аппаратной части ничего вроде не грозит. _AB>Очень сильное заблуждение. Мат. часть может отказать и при наличии электропитания.
Можно подробнее? ОС стабильна, синих экранов и внезапных перезагрузок не было, питание стабильно — в каких случаях может возникнуть проблема?
S>>Вот тоже не понимаю этой фразы — очень расплывчато. Логически это должно означать именно транзакции записанные на диск, иначе при delayed_durability = forced, в лог бы вообще ничего не попадало. Буду тестировать. _AB>С чего вдруг? Попасть должно в итоге всё (при отсутствии сбоев, разумеется). Просто клиент не будет ждать, пока оно на диск попадет. И ты рискуешь потерять именно те данные, что клиент изменил, но лог пока не записал на диск. Лог записывается при delayed durability при достижении чего-то одного — либо набора данных достаточно большого размера (чтобы получить преимущество batched дисковой операции), либо по таймеру (что бы не терять давно закоммиченные данные, если обновлений мало). Еще можно вручную это сделать через sys.sp_flush_log.
т.е. в худшем случае будут просто потеряны транзакции. А может возникнуть ситуация, что когда последовательно выполнены транзакции "A->B" (в режиме delayed_durability=forced), транзакция B записалась на диск, а транзакция A — не успела?
S>>Ещё такой вопрос: а если операция обновления (или вставки) идёт внутри большой и долгой транзакции, будет ли на неё влиять этот параметр? То есть стартует транзакция в полчаса длительностью, и в процессе неё происходят запросы, вставка новых данных и т.п. _AB>Клиент будет всё это ждать вплоть до коммита. Просто коммит не пишется синхронно на диск во время транзакции, вот и вся разница в скорости.
Нет, я имел в виду что клиент открывает транзакцию и начинает слать туда команды — в течении долгого времени, а потом в конце шлёт commit чтобы её завершить — будет ли delayed_durability влиять на команды выполняемые внутри такой транзакции?
S>> — но, как мне кажется, Durability должна обеспечиваться именно в конце транзакции при выполнении commit'а, а не при каждой вставке данных. Так ли это и так ли это на практике с SQL Server? _AB>Блин, вот не помню уже тонкостей традиционной записи в лог... Т.е., обеспечивается-то она при коммите, но вот как именно всё записывается в файл лога — операция за операцией синхронно, или может ждать записи на диск вплоть до коммита — я уже не помню.
В том и вопрос — может ли delayed_durability ускорить работу такой транзакции?
Здравствуйте, Somescout, Вы писали:
S>Можно подробнее? ОС стабильна, синих экранов и внезапных перезагрузок не было, питание стабильно — в каких случаях может возникнуть проблема?
Сегодня у тебя всё стабильно, завтра откажет, допустим, плашка памяти и привет BSOD.
S>т.е. в худшем случае будут просто потеряны транзакции. А может возникнуть ситуация, что когда последовательно выполнены транзакции "A->B" (в режиме delayed_durability=forced), транзакция B записалась на диск, а транзакция A — не успела?
Транзакции атомарны, вообще говоря. Но, ЕМНИП, такая ситуация невозможна в связи с технической реализацией процесса сброса лога на диск. Правда это ЕМНИП — дело такое. Я с этой фичей разбирался годы назад.
S>Нет, я имел в виду что клиент открывает транзакцию и начинает слать туда команды — в течении долгого времени, а потом в конце шлёт commit чтобы её завершить — будет ли delayed_durability влиять на команды выполняемые внутри такой транзакции?
В смысле будет ли он писать синхронно логи по ним на диск при delayed durability? Нет, не будет, конечно.
S>В том и вопрос — может ли delayed_durability ускорить работу такой транзакции?
Однозначно может. В любом случае ты при delayed durability ты не будешь ждать записи лога на диск и не важно, как это происходит традиционно — команда за командой, или сброс всей или части транзакции во время коммита. Вопрос только в том, сколько ты выиграешь. Если у тебя нет проблем с ожиданием записи лога, то мало ты выиграешь.
Здравствуйте, Somescout, Вы писали: S>Ещё такой вопрос: а если операция обновления (или вставки) идёт внутри большой и долгой транзакции, будет ли на неё влиять этот параметр?
Нет. Вообще, этот параметр влияет исключительно на поведение COMMIT. Вплоть до COMMIT, никаких изменений нету (что логично, т.к. при настройке DELAYED_RURABILITY = ALLOWED сервер и не знает вплоть до подачи клиентом команды COMMIT о том, в каком режиме её выполнять).
Обычно в рамках "большой и долгой транзакции" коммит стоит относительно мало, так что ничего особенного на нём не наиграешь.
Режим сделан в ответ на популярные NoSQL и внетранзакционные режимы всяких мускулов, которые достигают феноменальных скоростей на вставку благодаря отказу от фиксации коммитов.
То есть основной выигрыш достигается там, где идёт плотный поток мелких транзакций, в которых стоимость flush превышает стоимость собственно записи данных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте.
S>Может кто-нибудь рассказать что-то про эту фичу (https://docs.microsoft.com/en-us/sql/relational-databases/logs/control-transaction-durability?view=sql-server-2017)? S>1) Действует ли она на любые типы таблиц в базе? S>2) Насколько в целом это безопасно, если сбоев сервера, фактически, не бывает? S>3) Что означает "Only transactions that have been made durable are included in the backup. " — что в бэкап логов транзакции попадут в момент фактической записи на диск, или что они вообще не будут в нём отражены?
Там есть чёткий ответ:
If a fully durable transaction or sp_flush_log successfully commits, all previously committed delayed durability transactions are guaranteed to have been made durable.
Т.е. все транзакции попадают гарантированно и в backup и в log shipment (1) или при выполнении sp_flush_log (2) или если комитится любая обычная транзакция (с выключенным Deleyed Durabity)
А вообще прикольная тема.
Интересно насколько все быстрее работает если на всё включить Deleyed Durabity = On?
Скажем простой сценарий типа hangfire/асинхронная очередь — W потоков пишут в таблицу сообщения и R потоков сообщения "удаляют" (помечают обработанными).
Там вроде доступно же в статье все описано... 
