Yo.!dbpatchв операционке есть вызов fsync(), он гарантирует, что данные записаны на магнитный носитель (контроллер может тут обмануть, но это уже не уровень O/S), так что есть кеширование операционкой датафайлов или нет - это вообще никак на надежность и потерю данных не влияет, если у тебя само железо настроено верно.
глупости. что бы гарантировать запись на носитель fsync под линуксом надо O_DIRECT выставлять, а без него (без direct_io) оракл фигачит в кеш все с тем же fsync(), со всеми вытекающими для реду.

еще раз: писанина в кеш OS это совсем не то же самое что писанина в кеш сториджа. писанину сториджа батарейка спасет, а вот кеш OS ничего не спасет.

господи, вы там что, из одного детского сада наклонировались, документация не осиляторы?

https://linux.die.net/man/2/fsync fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present.

DВАdbpatchв операционке есть вызов fsync(), он гарантирует, что данные записаны на магнитный носитель (контроллер может тут обмануть, но это уже не уровень O/S), так что есть кеширование операционкой датафайлов или нет - это вообще никак на надежность и потерю данных не влияет, если у тебя само железо настроено верно.

Если мне не изменяет склероз, а он мне обычно не изменяет ), то вызов fsync использует только логврайтер, потому что именно ему предначертано заботиться о сохранности данных. Дибиврайтеры обходятся без него, поскольку файлы данных всегда могут донакатиться редозаписями.
Именно поэтому, опус что редо полетят первыми не сильно актуален - они хорошо защищены. Не 100-процентно, но лучше файлов данных, и им режим дирек-не директ по-боку

таки изменяет.

DBWR должен получить согласованную по checkpoint SCN версию датафайла/контролфайла - он не может записать ему хидер пока посланные на запись буферы будут грязными (не на диске), ибо при recovery он начнет накатывать логи не с того SCN

т.е. так и или иначе DBWR делает sync/flush

а вот для завершения юзерской транзакции да - датафайлы писать не нужно, достаточно удостовериться, что fsync() прошел по логам и изменить database buffers в памяти, которые DBWR уже потом и допишет когда сочтет нужным, в фоне

Q.Tarantinodbpatchгосподи, вы там что, из одного детского сада наклонировались, документация не осиляторы?

пропущено...

ты прям из pl/sql это умеешь вызывать?
ты откуда такой нарисовался то? :)

при чем тут PL/SQL? все эти fsync() вызовы реализованы в ядре Oracle в LGWR/DBWR процессах еще в 80-х годах, ничего с тех пор не изменилось.

а так да, даже в UTL_FILE есть вызов fsync(), просвещайся, нечитатель ты наш документации:

https://docs.oracle.com/cd/B19306_01/appdev.102/b14258/u_file.htm#i1003488

и да, ясен блин пончик, дернуть через UTL_FILE fsync() по лог и датафайлам у тебя не получится, там про другие файлы

DВАdbpatch,
да ну и пофиг, рековер он может начать с любого scn, не моложе нужного
лишнего не накатит, потому что на уровне блока тоже есть scn
да и речь тогда наверно все-таки про CKPT :)

нет, не пофиг, ибо там unordered запись, и если не флушить и внезапно упасть, то у тебя получится дейтафайл с незаписанными дырами в неизвестных местах, а Oracle при старте каждый блок не проверяет (с чего бы ему проверять, этож надо будет при старте прочитать все сотни терабайт, шутка-ли).