Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Что значит любого изменения? Если оно нарушает какое-нибудь ограничение? Или речь все же про валидные изменения?
S>Про любые. Если мы вообще собрались вносить в базу изменение, то в RAM можно резвиться как угодно, но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись.
S>А если вас беспокоят deferred constraints, то они проверяются между получением от пользователя команды commit transaction и внесением в WAL записи commit(TID). Если какие-то из констреинтов окажутся нарушенными, то информация из журнала будет использована для отката этой транзакции.

Непонятно. Все-таки в WAL всегда приезжают валидированные данные, а не просто некий факт добавления в бд? А то может
быть там есть отдельное поле про валидность вставленных данных в целях оптимизации записи и т.п.

S>>Что значит любого изменения? Если оно нарушает какое-нибудь ограничение? Или речь все же про валидные изменения?
S>Про любые. Если мы вообще собрались вносить в базу изменение, то в RAM можно резвиться как угодно, но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись.

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

S>>Про любые. Если мы вообще собрались вносить в базу изменение, то в RAM можно резвиться как угодно, но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись.

Gt_>не верно. в оракле даже не зафиксированная транзакция вполне может менять данные на диске, просто старое значение уедет в undo лог. конкурирующие транзакции из undo читают.

Что именно не верно?
Первое действие это запись в журнал (копии старых данных или новых данных в зависимости от типа журнала).
Только потом изменения в БД.

Здравствуйте, m2user, Вы писали:

S>>>Про любые. Если мы вообще собрались вносить в базу изменение, то в RAM можно резвиться как угодно, но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись.

Gt_>>не верно. в оракле даже не зафиксированная транзакция вполне может менять данные на диске, просто старое значение уедет в undo лог. конкурирующие транзакции из undo читают.

M>Что именно не верно?
M>Первое действие это запись в журнал (копии старых данных или новых данных в зависимости от типа журнала).
M>Только потом изменения в БД.

вот это не так " но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись."

Gt_>вот это не так " но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись."

Я полагаю, что и это утвержденние и Ваши контрпримеры про Oracle/MSSQL соответствуют алгоритму в моем комменте https://rsdn.org/forum/db/8961830?tree=tree

Автор: m2user
Дата: 08.07 15:48

Разница только в типе журнала.

Gt_> если транзакция крупнее ram, не так много вариантов.

Записать измененные данные в журнал (WAL). По завершению транзакции перенести в основной файл БД (cинхронно или асинхронно).

Здравствуйте, Gt_, Вы писали:


S>>>Что значит любого изменения? Если оно нарушает какое-нибудь ограничение? Или речь все же про валидные изменения?
S>>Про любые. Если мы вообще собрались вносить в базу изменение, то в RAM можно резвиться как угодно, но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись.

Gt_>не верно. в оракле даже не зафиксированная транзакция вполне может менять данные на диске, просто старое значение уедет в undo лог.
Ваше утверждение никак не противоречит моему.

Здравствуйте, Gt_, Вы писали:

Gt_>вот это не так " но на диск это изменение не должно попасть до того, как в WAL уедет соответствующая запись."
Совершенно именно так, как я написал.

Здравствуйте, Sharov, Вы писали:

S>Непонятно. Все-таки в WAL всегда приезжают валидированные данные, а не просто некий факт добавления в бд? А то может
S>быть там есть отдельное поле про валидность вставленных данных в целях оптимизации записи и т.п.
В классический WAL приезжают старые + новые данные. Всё. В нём нам не особо нужна информация про валидность данных.
Если речь про обычные (немедленные) ограничения, то их СУБД проверяет непосредственно перед тем, как выполнить изменение.
Например, если у нас стоит сheck(quantity % 2 == 0), то никакая СУЬД не будет складывать update T set quantity=17 where id = 42 в WAL.
Сначала будет выполнена проверка check constraint, и если она сфейлится (получится false), то изменение не будет применено. Блокировочник не станет изменять запись в буфере, версионник не станет создавать новую версию строки. Там в зависимости от окружающего такую операцию кода будет получен отказ, а то и вся транзакция будет откачена.

И только если констреинт удовлетворён, в журнал будет добавлена запись UPDATE(tid=17, table=T, tuple = PK(42), quantity_old = 8, quantity_new = 16).
После этого будет изменено содержимое буфера, содержащего копию кусочка файла данных.

Точно так же проверяются ограничения уникальности и внешнего ключа: проверка наличия нарушений выполняется до применения изменения, и ошибочная операция отменяется.
Отложенные ограничения отличаются тем, что нарушения не отменяют запрошенную операцию, а добавляются в журнал нарушений (обычно ведётся в памяти, т.к. ему не нужно переживать сбои).
Тогда да — в журнал попадает запись про изменение, изменение применяется к буферу в памяти, и мы едем дальше.
И только в момент коммита СУБД достаёт журнал нарушений, и начинает их перепроверять. Если хотя бы одно нарушение всё ещё актуально, транзакция отменяется (в зависимости от модели движка мы либо бежим назад по WAL и восстанавливаем испорченные значения, либо просто фиксируем статус нашей транзакции и оставляем тупиковые версии строк/страниц для сборки мусора).

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, paucity, Вы писали:

P>>Если память не изменяет, в любой момент после записи лога, не обязательно дожидаясь записи самих данных на диск, или нет?
S>После того, как будет выполнен flush log после добавления в журнал записи commit(TID).
S>Запись "самих данных" на диск тут полностью асинхронна — она может завершиться ещё до этого момента; может даже и не начаться к этому моменту; может быть частично выполнена к этому моменту.

P>>что данные добавлены, после добавления данных в лог или когда в сам файл данных будет комит?
S>Современные СУБД не делают "коммит в файл данных". Это слишком дорого. Файл данных лениво синхронизуется с памятью более-менее независимо от коммитов транзакций. То есть в каждый момент в "файле данных" на диске находится каша из изменений, которые внесены незавершёнными транзакциями; устаревших копий страниц, изменённых завершенными транзакциями, но ещё не сброшенных на диск, и прочего мусора.
S>Но при этом в каждый момент у нас есть на руках фрагмент журнала, который позволяет нам гарантированно навести в этом мусоре порядок.

Не то чтобы независимо... Всегда есть определенные правила синхронизации. Иначе может возникнуть ситуация что количество коммитов такое большое что "файл данных" становится все менее и менее актуальным. Результатом будет то что восстановление при сбое будет занимать все большее и большее время. Поэтому асинхронность записи в "файл данных" как правило ограничена — или по объему запаздывающих данных или по времени. Если этот лимит превышается, включается принудительная синхронизация, пока мы не достигнем требуемого лимита.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Enomay, Вы писали:


S>>>Ответ от сервера когда приходит, очевидно, что не сразу после записи в лог, а если данные не валидны?
E>>После коммита транзакции.

S>Ага, т.е. после записи в файл бд?

Ну смотря что понимается под "файлом бд".
Как тут уже говорили, запись в "файл бд" чаще делается асинхронной. Если они лежат в страничном кеше и читаются оттуда, и могут быть восставлены из лога при сбое,
то "файл бд" тоже превращается в своего рода кеш (для лога). Если данные вытесняются из страничного кеша, тогда они могут писаться на диск (как кеш второго уровня).
Но это все равно вторично. Что первично — это запись в лог. Это все конечно по разному работает в разные DBMS, в зависимости от того на чем фокусируются / что оптимизируют разработчики.
И тем более по разному в разных типах БД — в аналитических оптимизируют совсем другое, в embedded тоже, а в in-memory вообще нет "файла бд" .