>Как то за десять лет администрирования ни разу не видел подобногоЭто твои личные трудности. Объясняю на пальцах. Современный журнал это не просто один файл. Это _система_, которая может работать с файлами, а может и не работать с ними, например, журнал может быть в ОЗУ.
Журнальные файлы могут работать в режиме round-bobbin, в таком режиме транзакции пишутся по очереди, сначала в один файл, затем в другой, затем в третий, потом снова в первый. Альтернативно, журнальные файлы могут работать в режиме контрольных точек, в таком случае, в зависимости от левой пятки DBA, один (или несколько) файлов находятся в режиме RW, а остальные в RDONLY (они даже могут быть не открыты БД). И в том и другом случае обеспечивается определенный уровень надежности от сбоя -- откат произведется на самую последнюю верную транзакцию.
Поверх этого, накручивается система сжатия и архивирования журнальных файлов, т.е. посути 2й вариант выше, но предназначен для копирования журнальных файлов на внешние хосты (сервера) или внешние устройства (флешки, ленты и т.п.).
Журнальные файлы и их архивы активно применяются в современных БД по еще одной важной причине: в то время как файл БД может быть невероятно огромным, журнальные файлы (особенно в сжатом виде) весят _намного_ меньше. Стандартной практикой является фуллбэкап раз в 7-30 дней, а бэкапы журналов могут быть хоть по-часовыми (зависит от кол-ва коммитов).
Итого, сам смысл журнала никуда не девается. Это промежуточное звено между началом коммита и конечной записи его в файл БД. На основе расхождений данных и обеспечивается защита от сбоев (не 100%, т.к. диск может рассыпаться ... и без возможности восстановления). Другие технологии вроде полного бэкапа, UPS, рейды и т.п. решают _совершенно_ иные задачи (хоть и имеющие общую цель -- снизить риск утери _всех_ данных).
Поэтому, твой довод про то, что БД работает на файловом уровне не верен в корне. Если бы БД работала в raw-режиме, то ее не спасет тот же самый ресет, т.к. атомарность записи на диск не зависит от того как работает БД, а зависит от кол-ва данных, которые содержаться в транзакции. Тут-то и проявляется некомпетентность, т.к. считать что одна транзакция есть один insert это все что нужно. В сложных системах происходит десятки или даже сотни insert'ов в _одной_ транзакции. И если такая транзакция накроется, то и все insert'ы не попадут в файл БД и все будет тип-топ (т.е. не надо "до-инсерчивать" потерянные инсерты, как было бы в случае одиночных коммит=insert'ов).
