db2crash
оракл не менее автоматически сделает crash recovery откроет бд, запустит юзеров и в фоне будет вычищать датафайлы откатывая незавершенные транзакции. т.е. быстрей чем дб2 востановит работоспособность.

Не всегда, мне не один раз приходилось поднимать oracle датафайлы из offline накатывая логи вручную.

про ДБ2 не скажу, а Informix не откроет базу для юзеров пока полностью не выполнит crash recovery.

Оракл выполняет crash recovery быстрее, но иногда лажается.
Informix делает это дольше, но надежнее.

vasilisonstat-Оракл выполняет crash recovery быстрее, но иногда лажается.
Informix делает это дольше, но надежнее.
Информикс тоже лажается (я сторонник объективности :)
Конечно же, сильно зависит от условий, версии, уровня администрирования и платформы.
Я несколько раз уже описывал свои наблюдения за несколькими сотнями инстансов с одной и той же прикладной системой, но в тяжелых условиях эксплуатации (интел платформа и винда, отсутствие стабильного энергопитания в регионах, частое отсутствие упсов, слабое или отсутствующее администрирование и т.п.). Да, в 99-и случаях из 100 (а может и в 999 из 1000) Информикс корректно обработает аварийное выключение компа, тем не менее, обычно несколько раз в год приходилось разбирать ситуации, когда сервер не мог накатить транзакции из лога и fast recovery не мог выполниться.
Руками самому воспроизвести это никогда не получалось :)

Это и понятно, база наверное была в bufferеd log, и документация об этом кажись( насколько я помню) предупреждает, что могут быть неприятные моменты с crash recovery.

Если база в unbeffered log, то таких ситуаций я не видел, и вероятность их возникновения
ниже, по понятным ( архитектурным) причинам.

Если быть объективным то недостаток информикса в том, что только логическими журналами
ситуацию не исправишь, нужно ресторить и даже не чанк , а дбспейс польностью + журналы
или вообще всю базу.

p.s. За надежность всегда нужно платить, как правило производительностью.

db2crash

onstat- Не всегда, мне не один раз приходилось поднимать oracle датафайлы из offline накатывая логи вручную.
вы утверждаете что у оракла при целых датафайлах есть баг при котором он забывает "recover database" запустить или у вас все таки посложней ситуации были ;) ?


Аж на расссс, одна из причин( самая простая и даже не баг) oracle не знает как достать журналы которые уже сбекаплены и удалены rman-ом.


db2crash
у все этих субд есть лог транзакций, так что у всех принцип одинаков, просто у оракла еще фича с запуском базы и ролбека транзакций в фоне за счет версионности.

Лучше или хуже, это вопрос субъктивный, у вас есть опыт работы с 2 разными СУБД , что бы сравнивать?
ИМХО версионность тут не причем.

Informix в режиме unbuffered log мне не приходилось восстанавливать ниразу.

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

Контролфайлы ( на 9.2.06) падали даже без аварийного выключения питания, в ОС что то непонятное произошло.

db2crashonstat-
Аж на расссс, одна из причин( самая простая и даже не баг) oracle не знает как достать журналы которые уже сбекаплены и удалены rman-ом.
а что информикс в таком случае сам перематывает ленту и с нее достает лог ?


Informix не нуждается в заархивированных журналах для крешрековери.


db2crash
onstat-
Лучше или хуже, это вопрос субъктивный, у вас есть опыт работы с 2 разными СУБД , что бы сравнивать?
ИМХО версионность тут не причем.

oracle может пускать пользователей за счет того, что закомиченные версии строк затертые в датафайле вырублеными транзакциями можно читать из UNDO. имхо много опыта не нужно, чтоб что в информикс UNDO нет.


Informix имеет совсем другой механизм получения таких страниц. физический журнал называется.
UNDO ему не нужен.



db2crash
onstat-Informix в режиме unbuffered log мне не приходилось восстанавливать ниразу.
а у меня краш рековери всегда срабатывал ...

Значит нам повезло, мне с informix, Вас с oracle на этом основании невозможно обоснованно
доказать того что кто то из них нажедней.
Учитывая отсутствие у Вас элементарных знаний об архитектуре Infomix, спорить с Вами на эту тему - зря тратить время.

Что касается oracle, будучи объективным :), то основаная его солома, которую он себе подкладывает в том, что
дбврайтер практически никогда не делает мультиблочную запись, потому что вынужден писать
на диск в порядке SCN, а не в порядке физического расположения блоков в файле.
Это его плата производительностью за крешрековери.
У каждой СУБД она своя.

db2crash
onstat-
Контролфайлы ( на 9.2.06) падали даже без аварийного выключения питания, в ОС что то непонятное произошло.
а у информикса при повреждении файлов бд по вине ОС они сами выпрыгивают из бэкапа ?

Нет конечно, в информикс нет контролфайлов, и соотвественно выпрыгивать они отуда не могут
и пересоздавать их не нужно.

db2crashonstat-
Informix не нуждается в заархивированных журналах для крешрековери.
а в заархивированых logical logs он нуждается ? в чем принципиальное отличие от оракловых арклогов от logical-log backups ?


Принипиальных отличий в логах нет, есть отличия в архитектуре сервера, одной из которых есть отсутствие UNDO.

db2crash
onstat-Informix имеет совсем другой механизм получения таких страниц. физический журнал называется.
UNDO ему не нужен.
нет никакого другого механизма есть банальный Write ahead log, с помощью этого лога на последней стадии рекавери откатывает незавершенные транзакции,

Почитайте, что происходит на первой. Это очень важно с точки зрения понимания
как происходит fast recovery, и почему вероятность появления битых страниц после падения
OS + informix снижается в режиме unbufferd log.

Очень хорошо что вы начали читать документацию informix :).

db2crash
пользователи информикса в это время курят.

Я этого не скрывал.

db2crash
в оракле на этой стадии уже работают, а незавершенные транзакции откатываются в фоне, пока идет этот процесс пользователи видят последние закомиченые данные из UNDO, аналога которому в информиксе нет.

Даже те кто делают select for update ?

Если это действительно так, я не знаю, то это не крешрековери , а реклама шелковистых волос, как любит говорить Yo!

Если select for update выполнить нельзя, то не нужно говорить о востановлении полнофункциональной работы во время фонового наката логов.
Давайте будем объективными.

db2crash
onstat-
Нет конечно, в информикс нет контролфайлов, и соотвественно выпрыгивать они отуда не могут
и пересоздавать их не нужно.
ну тады с нетерпением ждем пояснений, чем servername.servernum принципиально отличается от ораклового контрол-файла и почему вы решили, что oncfg_servername.servernum не нужен при рековери ?

Давайте не будем путать крешрековери и рековер после рестора.

[quote автор]
database server uses the oncfg_servername.servernum file when it salvages logical-log files during a whole-system restore[ /quote]

1.Для крешрековери этот файл не нужен, он нужен только для утилиты onbar при полном востановлении.
другая утилита бекапирования (ontape ) в нем не нуждается ( во всяком случае не нуждалась когда я последний раз ею пользовался).

2. В этом файле нет SCN или какого либо другого значения отражающего порядок следования транзакций в разрезе файлов. Он великолепно правится руками в отличие от controlfile.

db2crashonstat-
Принипиальных отличий в логах нет, есть отличия в архитектуре сервера, одной из которых есть отсутствие UNDO.
давайте конкретно, в отличие от ораклового рековери, который не находит арклоги удаленные рманом, информикс рековери найдет удаленный ontape logical-log, вы это утверждаете ?


я утверждаю что заархивированные логи , которые находятся на ленте либо в каком либо другом месте
недоступном серверу , но доступном утилите востановления ( onbar, ontape ) не нужны
серверу при fast - recovery. Сервер следит за тем что бы у него вся информация
необходимая для fast recovery была в доступных ему логических журналах.

То что журнал уже заархивирован и перенесен в архив не значит что он уже недоступен серверу.
Полная аналогия с редо.


db2crash
прочел, в данном тексте вижу описание совершенно стандартного Write-ahead log, не вижу ни одного принципиального отличия от накатывания ораклового REDO. можно более развернутые пояснения.


Что хранится в физическом журнале вы прочитали ( поняли ) ?
Насколько я понял вы пока не видите разницы между физическим и логическим журналами.

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




db2crash
onstat-
Давайте не будем путать крешрековери и рековер после рестора.
хорошо, что произойдет если в процессе работы oncfg_servername по вине ОС будет запорот мусором ?

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

Кстате вспомнил, этот файл нужен при востановлении базы на новом сервере, или если
rootdbs, логические и физические журналы доступны, то onbar может взять всю информацию
из базы sysutils, это аналогия recovery catalog.

Скажу чесно и объективно, до настройки sysutils для для onbar на другом сервере у меня руки не дошли .


Что касается востановления файловой системы средствами ОС после падения
для минимизации битых страниц в СУБД , то порядок действий на этом форуме описывался, воспользуйтесь поиском.

2 db2crash с вами вcе ясно.

Тролей в Informix форуме не кормят.