АнатоЛой
Вопрос (НЕ риторический): если у меня table1 размазана по dbspace1, dbspace2 и dbspace3 (причём ROUNDROBIN'ом), а FK из неё ссылаются на table4, хранящуюся в dbspace 4 , и я прошу ontape восстанавить dbspace1, разве ontape при восстановлении затронет какие-то данные в dbspace2, dbspace3 или dbspace 4?
Второй вопрос: если таки не затронет, ведь при таком восстановлении у меня в dbspace1 для table1 может потребоваться восстановление данных, ссылающихся на строки table4 (в dbspace 4), которых там уже давно нет... Что получим: ошибку восстановления, отключенный кострейнт, или просто констрейнт, который не гарантирует то, что от него требуется (а-ля в ситуациях со слетевшим индексом)?
Насколько я помню, при восстановлении ontape-ом одного дб-пространства ты будешь обязан логически докатить его до текущего состояния, в котором находятся и все остальные дб-пространства. Т.е. проблемы согласования данных быть не должно. Говоря другими словами, после физического восстановления dbspace ты не можешь остановиться, а продолжишь выполнять логическое восстановление этого dbspace.

АнатоЛойЭто, правда, не отвечает на первоначальный вопрос о том, почему же нет в ontape функциональности "физического" архива отдельного взятого dbspace (ну, пусть будет плюс служебные...)
Так ведь риторические вопросы ответа, вроде, не требуют ? :)
Утилита onbar это делает (архив отдельного ДБ-пространства). Т.е. такая функциональность в сервере присутствет.
Почему ontape не делает ? Ну, так она много чего не делает :)

Кстати, не совсем понятен в данном контексте термин "физического" архива отдельного взятого dbspace
Какой вообще в нем смысл и зачем он тебе нужен (если я правильно понял твой термин) ?

АнатоЛой
Есть один экземпляр сервера и несколько БД, разделённых по dbspace (или разработчики готовы схему одной БД разделить на пару частей, где могут пойти на разрыв пары-тройки связей FK). Одна БД (или часть схемы) намного более важная и менее объёмная чем вторая.
Ты так и не сказал, почему нельзя использовать onbar. Вопрос религии ?
Я как то не понимаю вопроса в принципе - возможность то ведь есть и родная, без всяких внешних приблуд и заморочек.

АнатоЛой
А "полный" архив 0-го уровня длится слишком долго и слишком большой для того, чтобы хранить циклически достаточную историю. Хотелось бы более важную часть архивировать чаще (и быстрее...).
Да пожалуйста. Кто не дает использовать инкрементальные архивы (легко решает задачу, хотя и усложняет жизнь) или тот же экспорт отдельной БД (выделенная наиболее важная часть общей БД), если время устраивает ?

sysmasterИнтересно, а почему Informix не умеет делать бэкап отдельной базы?
Или я что-то забыл. :)
А что такое "бэкап отдельной базы" в вашем понимании ?
P.S. понятие "база" у И. и О. сильно отличаются :)

АнатоЛойvasilis
Ты так и не сказал, почему нельзя использовать onbar. Вопрос религии ?

Это уже другое обсуждение - зачем нужен и ontape и onbar %).
Огромная благодарность Информиксу, что с появлением onbar он не "убил" ontape (сколько скриптов было написано для бэкапирования до появления onbar...) и продолжил его развивать. По моему, тут не о чем дискутировать. Нужны обе.
АнатоЛой
Можно. Использование onbar предполагает большие трудозатраты на подготовку (как админа, так и процесса). Я не говорю что нельзя.
Уже лучше :)
Но нельзя и "рыбку съесть и ... юшку выпить". Тем более, что это разовые затраты, которые потом окупятся (сокращением времени архивирования).
АнатоЛойvasilis
Да пожалуйста. Кто не дает использовать инкрементальные архивы (легко решает задачу, хотя и усложняет жизнь)

Тоже можно. Но осадок остался. Инкрементальный архив ВСЁ РАВНО ЧИТАЕТ ВСЕ чанки. Зачем оно мне?
"Вам шашечки или ехать?" Где было условие, что нельзя читать все чанки ?
Скорость бэкапа возрастает ? Ну и отлично. Все равно скорость не устраивает ? Тогда давайте определяться, какое время бэкапа допустимо, а какое уже нет. А то ведь без критериев будем долго "дискутировать" :) Например, 10 часов ночью не хватает для архива ? Или хватает, но просто жалко винты шебуршить ?
Зачем вообще частые бэкапы, если есть логи и место под них ?
Вам что, часто восстанавливать приходится или очень жесткий регламент по восстановлению ? Может легче его пересмотреть - все равно менеджемент в этих вопросах слабо разбирается :)