Дополнения отмечены жирным шрифтом:
1. Модификация данных "пользователями"
Денис_88
при внесении изменений в БД с дискового пространства в буферный пул копируется неизменённая страница,к которой будут применены изменения, и перед применением изменений помещается в буфер физ. журнала. После этого страница изменяется и содержится в буфер пуле области памяти,также в это время логическое изменение записывается в буфер логического журнала.


2. Сброс данных на "диск"

Денис_88Буфера логического и физ журнала находятся в памяти и сбрасываются на диск в логический и физ. журнал по заполнению или по checkpoint(при условии что БД находится в режиме buffered).

Много обобщений. Поэтому переформулирую:
Буфер физического журнала сбрасывается на диск по заполнению или в первую очередь (даже незаполненным) при необходимости других сбросов на диск (буфера логического журнала, изменённых страниц из буферного пула, чекпоинт). Поэтому буферов физического журнала даже два - пока один сбрасывается, второй наполняется сервером.

Чекпоинт - не просто процесс сброса данных на диск. Чекпоинт - такой сброс данных, при котором в пространствах БД имеем целостную и непротиворечивую информацию. В предыдущем описании процесса отсутствует немаловажный процесс - чистильщики буферов. Что видно из следующей фразы:

Денис_88Буфер пул сбрасывается в табличные пространства по checkpoint'у.

Изменённые страницы буфер пул а сбрасыва ю тся в табличные пространства чистильщиками буферов . Этот процесс идёт параллельно процессу "1. Модификация данных "пользователями"". Чекпоинт - получение непротиворечивой информации в пространствах БД на диске - приводит в том числе к принудительному сбросу изменённых страницы буфер, не давая до окончания этого процесса править пользователям страницы в буферном пуле (в итоге - в БД).

Денис_88При наступлении к.т. физический журнал сбрасывается, потому что измененные страницы уже в табличных пространствах и хранить неизмененные копии нет смысла.

Лог. журнал заполняется циклически и необходимо делать архивирование "файлов" журнала периодически (ontape -a или onbar...) или другими способами для возможности дальнейшей записи. Если этого не сделать, то сервер будет ждать от нас архивирования лог. журнала. Сам логический журнал необходим для применения изменений после последнего к.т. в случае внезапного сбоя.


Далее куча замечаний к пониманию резервного копирования и восстановления, но на комментарии времени пока не хватает - жена гонит в постель :)

Денис_88Восстановление БД. Случаи:
1)восстановление после сбоя.
При переводе сервера в стабилизированный, административный или подключенный (online) режим из отключенного (offline) режима
сервер автоматически и всегда без какого-либо вмешательства админа смотрит в физ. журнал, и если видит что он не пуст, то понимает,что прекращение работы было некорректно.Он берет из физ журнала страницы и накатывает на свои табличные пространства,а потом обращается к лог. журналу,находит там запись о посл. к.т. и применяет все изменения завершённые транзакции после этой к.т.,тем самым приводя БД в консистентное состояние на момент сбоя(не считая тех данных,которые остались несброшенными из буферов лог. и физ журналов).

Т.е. самый основной минус использования буферов-возможная потеря данных,которые не были сброшены на диск в журнал,но плюс в увеличении производительности.

приблизительно всё ок

Денис_88Во время делания бэкапа архивируются все лог. журналы.Это делается за тем,чтобы при восстановлении с бэкапа 0 уровня накатить архивные логи,которые содержат изменения за время делания бэкапа,чтобы базу привести в консистентное состояние на момент окончания бэкапа.

Вот тут какой-то сумбур.

В общем, бекап есть двух видов:
1) бекап логических журналов
2) бекап пространств БД.

Бекап логических журналов вроде прост и понятен - забираем из логического журнала "файлы", которые наполнены новыми данными, кроме того, в который сейчас пишутся данные.

Бекап физических пространств делится на два вида:
1) 0-ого уровня - нулевой - полный
2) 1-го и 2-ого уровня - инкрементальные.

0-ой бекап - полная копия согласованных пространств БД без прекращения работы пользователей.

Перед 0-ым бекапом автоматически делается к.т. - приводим пространства БД в согласованное состояние.
После окончания к.т. пользователи продолжают работать практически как ни в чём не бывало.

А сервер начинает запихивать в архив копии страниц пространств БД с одним нюансом:
у каждой страницы есть метка времени последней модификации, и сервер сравнивает эту метку с меткой начала 0-го бекапа. Соответственно, если оказывается, что страница в пространстве уже изменена благодаря вышеописанному процессу "1. Модификация данных пользователями", сервер берёт старую копию этой страницы на момент начала 0-го бекапа из физического журнала. Как Вы понимаете, чтобы гарантировать наличие такой копии в физ журнале, на время выполнения 0-го бекапа не происходит очистка физического журнала (а значит физический журнал по размерам должен соответствовать "объёмам" модификаций данных пользователями, которые могут произойти за время выполнения 0-го бекапа).
Таким образом в архиве 0-го уровня хранится согласованная версия данных на момент к.т. непосредственно перед выполнением бекапа. И сервер сохраняет в своих метаданных эту метку времени.

Бекап 1-го уровня - работает аналогично бекапу 0-го с одним дополнительным условием:
в бекап 1-го уровня попадают только те страницы, у которых метка времени модификации позже, чем метка времени у последнего 0-го бекапа. Таким образом в бекапе 1-го уровня хранятся не все страницы пространств, а только изменившиеся с момента 0-го бекапа.

Бекап 2-го уровня - работает по отношению к 1-му, как 1-ый - к 0-му.

Поэтому 1-ый и 2-ой уровень - инкрементальные: для использования 1-го сначала нужно восстановить 0-ой уровень, а для использования 2-го - сначала восстановить 0-ой и сразу за ним 1-ый.

Бекапы логических журналов позволяют последовательно докатить БД от момента времени 0/1/2 бекапа до конца...

Денис_88АнатоЛой,
1)то есть получается,что лог. журнал нужен только для наката завершенных транзакций,измененных после последней к.т. в случае сбоя и все что ли???
ведь если мы остановим сервер корректно,то перед остановкой он сделает к.т.,тем самым приведет БД в согласованное состояние и при переводе в режим online БД просто прочтет страницы из табл пространств и все,так?Ну естесственно при поднятии сервер после восстановления табл. пространств обратится к лог журналу,прочтет данные о дате посл к.т. и увидит,что никаких изменений после нее не было и сервер перейдет в раб. режим,да?


ещё лог.журнал нужен для резервного восстановления на точку времени Ч, которое больше чем время начала 0-го, 1-го или 2-го бекапа...
Ещё может пригодиться для создания репликационной пары HDR (это на затравку, троллю понемногу )

Денис_88
2)Если мы, например, сделали бекап табл. пространств 0 уровня и никаких изменений больше не вносили, то получается достаточно восстановить базу из бэкапа и лог. журналы вообще не нужны,правильно я понимаю?


Да, но для этого нужно быть уверенным, что изменения после таки не вносили.

Денис_882)если у нас есть бэкап 0 уровня и 1 уровня.Я восстанавливаю сначала бэкап 0 уровня,а потом сразу можно бэкап 1 уровня или необходимо найти и накатывать лог. журнал,содержащий изменения между 0 и 1 уровнями?Я считаю,что это делать не надо,так ли это?

да.
варианты восстановления:
1) 0
2) 0, бекапы логич. журналов ( логи с момента 0 - по интересующее вас время, логи в строгой последовательности)
3) 0, 1
4) 0, 1, бекапы логич. журналов ( с момента 1....)
5) 0, 1, 2
6) 0, 1, 2, бекапы логич. журналов ( с момента 2....)

Состояние БД получите на время последнего в перечне восстановлённых бекапов.


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



Денис_88НО также я прочел о том,что если в onconfig прописать ltapedev /dev/null, то лог.журнал будет архивироваться самостоятельно автоматически сразу после заполнения,но куда он складывает архив?

Соответственно - в /dev/null - то бишь в пустое устройство, то бишь в никуда.

Этот приём используется либо на конфигурациях, которым не потребуется восстановление, либо в некоторые моменты административной подготовки сервера, либо ... по незнанию (а также некоторые инсталляции Informix могут выставить такой параметр по умолчанию, а молодой админ просто ещё не бит жизнью - и не озабочен вопросами правильного резервного копирования...)

Денис_884)если теряется лог. журнал,то что будет?


КВНИнтуитивно, конечно, я догадываюсь, о чём Вы спрашиваете.
Если речь о потере бекапа файла или файлов логического журнала, то:
если у вас нет бекапа 0-го, 1-го или 2-го уровня после даты-времени потерянного журнала,
то в случае критического сбоя (например, оборудования с потерей винта с БД), вы сможете восстановить БД только до момента времени потерянного бекапа файла журнала. В этом случае не удастся перескочить через потерянный файл журнала и восстановить БД на более позднюю точку времени.

Денис_88, вот тут при уже запущенной в рабочем режиме репликации, данные для вторичного сервера поступают не из логического журнала, а отдельно параллельно дублируются ещё на этапе сброса данных из буфера логического журнала на диск - то есть для репликации у первичного сервера есть свой буфер репликации, в который пишутся те же данные, что и в логжурнал, но параллельно.

Денис_88по поводу репликации мне известно,но вопрос был в том,что основной сервер ночью не знал о репликации и репликационного буфера у него не было
Да, я прочитал 1-ый вопрос, а 2-ой вдогонку не заметил. Тем не менее, если нижеописанное даже полностью совпадёт с вашим текущим пониманием - значит, таки всё хорошо :)

Денис_88вопрос такой: поднимается репликация HDR, резервный сервер восстановлен после ночного бэкапа с основного сервера,но за утро на основном сервере было много изменений и лог. журнал №1 заполнился и перескочил на лог журнал №2.Т.к. в параметрах стоит /dev/null, то сервер по идее должен был заархивировать лог. журнал №1 и переместить его в никуда,но ведь после включения репликации лог. журнал с основного передается начиная с бэкапа,то есть лог. журнал №1 тоже передается.
Если изменить параметр ltapedev--все становится ясно,что основной сервер берет лог. журнал и передает его.


Если параметр LTAPEDEV на первичном не /dev/null - это ещё не значит, что первичный сервер может передать журнал №1. За время прошедшее с ночного бекапа 0-го уровня, ваши логические журналы уже могли успеть восемь раз по кругу быть отправлеными в архив и перезаписаться. При восстановлении вторичного сервера после физического восстановления и при попытке перевести вторичный сервер собственно в режим вторичного, может не обнаружиться нужного лог.журнала №1 на первичном (поскольку был уже бекапирован на ленту и перезаписан, например, лог.журналом с номером N+1 ). И поэтому вторичный запросит у админа "ленту" с бекапами логических журналов по пути LTAPEDEV, указанном на вторичном сервере ... И вот когда вы скормите ему "N" бекапов логических журналов - попытается найти на первичном сервере ещё не перезаписанный N+1-ый - и докатится непосредственно с логжурналов первичного.