Здравствуйте, LaFut, Вы писали:
LF>Когда сервер созраняет новые значения в логе, неужели при изменении блобов там они записываются целиком?
Все зависит от типа модели восстановления, если речь идет о MS SQL.
Для модели Bulk logged, данные не записываются в лог транзакций, вместо этого измененные страницы помечаются особым образом, и записываются в архив лога транзакций, когда соответствующая операция архивирования будет вызвана.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, LaFut, Вы писали:
LF>>Когда сервер созраняет новые значения в логе, неужели при изменении блобов там они записываются целиком?
AS>Все зависит от типа модели восстановления, если речь идет о MS SQL.
AS>
AS>Для модели Bulk logged, данные не записываются в лог транзакций, вместо этого измененные страницы помечаются особым образом, и записываются в архив лога транзакций, когда соответствующая операция архивирования будет вызвана.
1.а как же тогда происходит восстановление?
2. то есть при full recovery значения записываются целиком?
ЗЫ. в общем вопрос не касался конкретно MS SQL, интерсовало как это делается в общем при ведение redo-лога.
Как обычно.
LF>2. то есть при full recovery значения записываются целиком?
При full recovery model и simple recovery model они просто записываются. При bulk recovery model они не записываются.
LF>ЗЫ. в общем вопрос не касался конкретно MS SQL, интерсовало как это делается в общем при ведение redo-лога.
Здравствуйте, LaFut, Вы писали:
LF>Когда сервер созраняет новые значения в логе, неужели при изменении блобов там они записываются целиком?
В общем случае да. Иначе как их восстанавливать, если что?
Хотя в конкретных реализациях могут быть варианты лога с неполным восстановлением, в которых блобы не пишутся.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Что есть redo-log?
Есть две модели построения лога транзакций: redo и undo . Кратко говоря, в undo-логе созраняются предыдущие значения, и если сбой произошел во время commit'а транзакции, то при восстановлении происходит откат на предыдущие значения. В redo-лог пишутся новые значения — и соответственно при сбое записываются новые значения. Есть еще комбинированный лог undo/redo, там в логе хранятся и предыдущие значения и новые. При его использовании (вот этого я точно не знаю) можно как откатится на предыдущие значения, так и на новые.
Здравствуйте, LaFut, Вы писали:
LF>Здравствуйте, Alexey Shirshov, Вы писали:
LF> В redo-лог пишутся новые значения — и соответственно при сбое записываются новые значения.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, LaFut, Вы писали:
LF>>Здравствуйте, Alexey Shirshov, Вы писали:
LF>> В redo-лог пишутся новые значения — и соответственно при сбое записываются новые значения.
DAS> Имеются в виду подтвержденные изменения ?
ну да! вот приблизительное устройство
redo-log
start(t)
set(t, x, newval)
set(t, y, newval)
commit (t)
write (x, newval)
write (y, newval)
end commit (t)
то есть если сбой произошел между commit и end commit то при восстановлении просто заново выполняются действия от start до commit, если сбой произошел до commit'а, то ничего делать не надо, так как изменения были сделаны только в оперативной памяти и на диск попасть не успели.
undo-log
start(t)
(t, x, oldval)
(t, y, oldval)
commit (t)
write (x, newval)
write (y, newval)
end commit (t)
здесь если сбой произошел между commit и end commit то при восстановлении взвращаются к старым значениям.
плюс не рассматривается система checkpoints (хм, как это по русски), для очистки лога.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Откуда дровишки? Или сам сочиняешь?
Дровишки от одного, всем известного верблюда, тоесть из теории RDBMS.
Вот первое, что под руку подвернулось:
Write Ahead Logging (WAL) is a standard approach to transaction logging. Its detailed description may be found in most (if not all) books about transaction processing. Briefly, WAL's central concept is that changes to data files (where tables and indices reside) must be written only after those changes have been logged — that is, when log records have been flushed to permanent storage. When we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages will first be redone from the log records (this is roll-forward recovery, also known as REDO) and then changes made by uncommitted transactions will be removed from the data pages (roll-backward recovery — UNDO).
(с) Vadim Mikheev and Oliver Elphick
PostgreSQL 7.1.1 Documentation
Это все у Кнута было.
Речь идет о реализации лога транзакций. Я не знал что есть разные типы логов.
Операции redo и undo это понятно. А вот лог redo это что-то новое для меня.
LF>Когда сервер созраняет новые значения в логе, неужели при изменении блобов там они записываются целиком?
AS>Все зависит от типа модели восстановления, если речь идет о MS SQL. AS>При full recovery model и simple recovery model они просто записываются. При bulk recovery model они не записываются.
AS>Операции redo и undo это понятно. А вот лог redo это что-то новое для меня.
Ааа... Сорьки, не догнал сразу, мне опять за внимательность незачет..
На самом деле способов организации лога примерно три:
Есть Undo Log:
Сначало все пишем в базу, потом, после коммита в лог, если в лог commit не успели, значит все откатываем взад беря старые данные из лога.
Недостатки очевидны, слишком много IO операций, тоесть каждая транзакция должна быть записана на диск не только в логе, но и в самой базе.
Есть Redo Log:
Все пишем в лог, но в базу до commit'а мы записать ничего не можем, так как вслучае сбоя старые значения незафиксированных транзакций неоткуда будет взять. Отсюда могут быть проблемы с памятью при больших транзакциях или при большем количестве транзакций.
Ну и есть Redo/Undo:
В этом случае в логе хранится два значения старое и новое, соответственно в случае сбоя для всех закоммиченных транзакций накатываем новое значение, для всех незакоммиченых старое.
Мы уже победили, просто это еще не так заметно...
