Apex hvladА кто сказал, что он вчерашний ? На то он и инкрементальный, что делается быстро, и, кстати, может занимать намного меньше места чем журнал. Так шта - делайте хоть каждые 5 мин.
Если делать инкрементальный бэкап очень часто - то по сути это будет имитация журнала транзакций, но с худшей реализацией. Смысла в ней я не вижу.а) Это ни в коем случае не будет имитацией журнала тр-ций. Слишком разные процессы
б) С отсутствием жизненной необходимости журнала тр-ций мы уже смирились, не так ли ? :)
в) Реализация не обязана быть худшей

Apex hvlad
Скорость теряется за счёт не упорядоченной по физическим номерам страниц записи на диск. С логом (последовательно записываемым) этой проблемы нет. Но есть другая - нужно писать в лог намного больше инф-ции , а потом её же (не всю конечно) писать ещё раз в БД.

Есть страница, содержащая данные как-то таблицы, меняем одну строку, говорим commit - что уходит на диск? Мне кажется что целиком вся страница. Поправьте если не так.Конечно.
А что пойдёт в журнал тр-ций ? Даже если только изменённые данные + данные до изменения (а не старая + новая страницы), то что пойдёт в журнал при изменении 10 записей на странице в 10 разных апдейтах в однй тр-ции ?

Apex hvlad
б) С отсутствием жизненной необходимости журнала тр-ций мы уже смирились, не так ли ? :)

Не так. Про жизненную необходимость я и не говорил, я говорил про возможности восстановления. Если у тебя полетит один из дисков - т.е. только часть БД, то все что ты поимеешь - базу по состоянию, пусть даже 5 минут назад (последний инкрементальный бэкап). В случае с журналом я поимею ее вплоть до последней зафиксированной транзации перед сбоем. Разница есть.Я спорил не с наличием разницы. А с утверждением о несерьёзности систем без явных журналов. Shadow позволяет иметь не меньшую степень надёжности

ApexОК. Давай рассуждать дальше. Итак, имеем 10 измененных строк в 10 разных страницах. Перед commit без журнала надо сбросить на диск все 10. Так? С журналом надо сбросить только одну страницу, содежращую записи обо всех изменения+некую доп. информацию - что в совокупности ненамного больше самой изменившейся информации, но гораздо меньше 10 страниц данныхНе совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

ApexИдем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз)Да. Но это только если эти тр-ции работают строго последовательно. Т.е. тр-ция2 не трогает страницу, изменённую тр-цией1 пока тр-ция1 не закоммитится. А это характерно только для невысокой нагрузки.

ApexС журналом уходит 10 старниц журнала с измененными данными + 10 страниц грязных данных. Поправь меня, если я где-то допустил ошибку.В журнал таки пойдёт несколько больше 10-и страниц. А именно - не менее 210 "записей" (100 о старых данных, 100 о новых, 10 о коммитах). Но не в этом суть...

О чём спорим ?
а) о призводительности
б) о надёжности
в) о сравнительном объёме журнала и инкрементного бекапа
г) о "серьёзности" (не знаю что это такое)
?

Apex забанен hvlad
Shadow позволяет иметь не меньшую степень надёжности

При бОльших требованиях к аппаратному обеспечению (обеспечить журнализацию проще, чем работу еще одного сервера).Нет. Читайте внимательнее - я уже говорил, что shadow располагается на том же сервере. Это страничная копия файла БД

Apex забанен hvlad ApexИдем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз)Да. Но это только если эти тр-ции работают строго последовательно. Т.е. тр-ция2 не трогает страницу, изменённую тр-цией1 пока тр-ция1 не закоммитится. А это характерно только для невысокой нагрузки.

А если все-таки трогает, до того как первая закомитилась? Т1 внесла изменения в страницу А, Т2 внесла изменения в А, Т1 сказала commit - страница пошла на диск(?), Т2 сказала commit - что тогда? Страница опять пошла на диск или проверила, что она уже была сброшена на диск после чего Т2 в нее не вносла изменений и повторно можно не сбрасывать?Грязная страница, будучи сброшенной на диск, перестаёт быть грязной :) Конечно она будет записана только 1 раз

Apex забанен hvlad
Но не в этом суть...

О чём спорим ?
а) о призводительности
б) о надёжности
в) о сравнительном объёме журнала и инкрементного бекапа
г) о "серьёзности" (не знаю что это такое)
?
Я считаю, что СУБД с журналом транзакций имееют приимущество по совокупности пунктов а и б, перед СУБД не имеющими таковой.Считать что угодно и как угодно - ваше право. Истина от этого не зависит

PS А чего забанен-то ? Али я пропустил самое интересное ?

landy hvladНе совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

Не совсем понятно - зачем? В журнал пишутся только новые закоммиченные данные
Накат журнала - это взять бэкап(со старыми данными) и последовательно провести изменения по журналу на новые данные.
Сделав n-1 таких операций - будем иметь "старые данные"Затем, что журнал позволяет не только накат закоммиченного, но и откат не закоммиченного.

landyНу насколько я понял - все свалилось к обсуждению вопроса - нужны ли журналы транзакций?
Для меня - пока в Postgres не было механизмов наката по журналам(PITR) я его смотрел, но не рассматривал
как БД для серьезного использвания.
Насчет инкрементальных бэкапов - насколько я понимаю - они должны делаться относительно какой-то точки отсчета(первоначальный бэкап БД). Кроме того(во всяком случае в RDB это так) каждый последующий инкрементальный бэкап содержит все изменения с полного бэкапа(т е он растет). Для восстановления БД нужно накатить последний инкрементальный бэкап на полный бэкап БД.
В других БД это так же я думаю(т е как выполняя последующие инкрементальные бжкапы мы можем узнать что забэкапили на предыдущем, т е точка отсчета все равно полный бэкап)?В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап