sanyock2видел упоминания, что в дорогих редакциях DB2 есть интеграция со снэпшотами хранилищ для мгновеннчых бэкапов

думаю, как бы подобное сделать для ExpressC
...
или есть более правильные методы?Почитайте тут про Split mirror .
В Express-C это тоже должно работать.
sanyock2и потом один Federation их всех (если они на разных IP или портах одного IP) объеденит в одну большую базу (больше 15гиг) с относительно большим количеством вычислительных ресурсов?
но производительность federation, наверно, не ахти даже для локальных соединений на localhost?Федерацию в Express-C DB2 LUW <-> DB2 LUW делать можно. Вы можете завести для каждого экземпляра отдельную виртуалку, и там внетри каждая Express-C будет использовать 2 ядра и 16 GB памяти. И объединить это всё федерацией.
Не могу сказать, есть ли всё это смысл делать, и какая там производительность будет. Скорее всего, будет сильно зависить от запросов в системе.

sanyock2,


Using a split mirror to clone a database

sanyock2а результат моего способа чем то отличается по целостности данных от initdb?Есть определенные правила работы с split mirror копиями. Они описаны в документации. Среди них я не вижу команды restart database. Поэтому, я не знаю, что будет со split mirror копией после этого.
sanyock2насколько я понял initdb предназначен для создания новой базы

1)snapshot=клон: сразу после db2initdb запускается rollback - пишут, что:
"You cannot back up a cloned database , restore the backup image on the original system, or roll forward through log files produced on the original system."
т.е. это какая-то ущербная по функционалу база получится без возможности бэкапить её?Нет, вы не правильно поняли.
Когда вы инициализируются копию как snapshot, то все незавершенные транзакции на момент взятия копии откатываются. Вы получаете отдельную базу, более никак не связанную с оригинальной. Именно поэтому цитату надо понимать так, что вы не сможете более из архива этой новой базы (если вы его сделаете, например) пытаться восстанавливать объекты оригинальной базы. Или использовать журналы оригинальной базы для наката по ним в новой базе. Но это не значит, что новая база становится "ущербной", и для нее становится невозможно делать архивы. Она становится обычной отдельной базой.

serious_student,

Изначально было требование:
авторподразумевается БЕЗ rollforward ,

т.е. достаточно откатить транзакции, активные на момент создания снэпшота, без их завершения поэтому было посоветовано
db2inidb database_alias as snapshot
Другого способа "БЕЗ rollforward" нету.
Если теперь требование:
авторЯ то как раз хотел бы НЕ менять GUID, НЕ делать перекаталогизацию, т.е. чтобы база оставалась старой, оригинальной, НЕ новой, НЕ отдельной.

Есть ли какой-либо другой способ кроме моего "restart database write resume" для достижения этой цели сохранения старой базы и отката на ранний снэпшот в рамках этой старой базы?
То для этого:
Подробнее про особенности:
Using a split mirror as a backup image

В догонку:

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

sanyock2,

Если ваша база не использует режим архивирования журналов, то там всё равно, какую опцию db2inidb выбирать: snapshot иди backup. Всё равно текущие незавершенные транзацкии будут откачены.
Еще раз - пользуйтесь db2inidb, а не restart db.

sanyock2,

Как я уже говорил, restart db применяется в других случаях, и мне непонятно, зачем вы так хотите применять его там, где есть другие штатные средства. Я ничего не могу сказать по поводу того, чем restart db, может был лучше.
По-моему, db2inidb должна решать вашу задачу. Оно в том числе именно для этого и придумано. Если вы считаете, что нет - объясните, почему.