Yo.!locky[quot Dimitry Sibiryakov]
Транзакция - это не только A, но и D.
И добиться D (при определённых, пусть и редких, условиях) невозможно (со 100% гарантией).

зато А легко, разве что если аппаратные сбои не начнут подделывать SCN и контрольные суммы блоков одновременно.
Ну, если сделать акцент на any, то не так уж и легко, если подумать :)

Dimitry Sibiryakov
ЛПТоварисч, тебе пояснить значение слов "any failure"?

Ага, пояснить. Причём на конкретном примере. А то пока всё звучит как "я
не знаю как, но Рабинович вчера насвистел, что какой-то сбой может
заставить Оракул нарушить атомарность транзакции". В процитированном
определении атомарности чётко сказано: "всё или ничего". Выдумать сбой,
который оставит "ничего" - легко. Ещё легче - такой, который оставит
"всё". Ну а кто не сможет выдумать такой, который оставит половину -
может потереть своё "any" о волосы и...

Честно говоря, я не знаю, как оно ТАМ в оракле, но если там таки используется write ordering, то, видимо, достаточно попутать при записи два финальных блока - и вуаля! Транзакция неатомарна, ибо записана только частично.
Отказ может быть как на уровне СУБД, так и на уровне контроллера дисков.

Yo.!locky
Ну, если сделать акцент на any, то не так уж и легко, если подумать :)
повторяю, чтоб получить нарушение Atomicity понадобится, чтоб железо начало подделывать не только SCN но и контрольную сумму блока, причем чтоб еще и записало это дело 2 раза, сначала в транзакшен логе, потом в датафайле. я не вижу реальных шансов даже если рядом 100 мегатонн рванет, в то время какая хрень с Atomicity происходит в фокспро я уже демонстрировал
Достаточно ошибки в софте, собственно.
Софт ведь не 100% надежен, всегда может что-то найтись.

Другое дело что, скажем, в случае с ораклом если очччень не повезёт, то база рухнет, а с тем же фоксом - если повезёт, то не рухнет.

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

Yo.!locky
Честно говоря, я не знаю, как оно ТАМ в оракле, но если там таки используется write ordering, то, видимо, достаточно попутать при записи два финальных блока - и вуаля!
и что вы со слетевшими контроллерами никогда не сталкивались ? у попутаных блоков контрольные суммы не сойдуться. путая блоки или недозаписывая их ничего не добиться, именно подделывать контрольные суммы каждого блока нужно.
Сталкивался :)
Рассыпалось всё нафиг :)
Значит, минус одна дырка для нормальной СУБД.