Привет всем!
Есть две машины с AIX и установленными на них DB2 v9.1 Кластер DB2 построен на HACMP 5.4.1 Экземпляр БД db2inst1 находится на файловой системе /var/db2fs, она в свою очередь на разделяемом дисковом пространстве(DS4700). Табличные пространства БД (используются логические разделы AIX) находятся также на разделяемом диске. На DS4700 создано два диска (RAID6). Каждый из улов кластера (LPAR) видит эти два диска, и они зеркалируются средствами LVM AIXа (не самое лучшее решение, но так нужно по ТЗ, т.к. выход из строя 3 дисков не дожен приводить к остановке в работе и к потере данных). Есть WIn2003 с установленным на нее Tivoli Storage Manager 5.5.2 к ней подключена ленточная библиотека TS3100. На разделы установлен TSM API. Бэкап и восстановление вручную базы данных проходит успешно. База данных (назовем ее ARCH) на данный момент важных данных не содержит, кроме структуры и инициализационных данных, так что можно экспериментировать:) Это так сказать вступление.
ДБ2 я знаю не очень хорошо, но дали задание спроектировать и построить надежную систему бэкапа и восстановления на основании приведенных выше данных. Начал разбираться с TSM и DB2 и столкнулся с вещами которые пока никак не могу понять.
Теперь по порядку что мне не понятно. БД создана по умолчанию. т.е. используется "Циклическая запись журанала". Насколько я понял, чтобы сделать возможным восстановить транзакционные логи в случае поломки БД (но не перехода на резервный раздел) нужно использовать "Архивирование журналов". Т.е. журналы (это транзакции правильно я понял?) будут храниться в TSM(как один из вариантов) и после этого появится возможность :
"оперативного резервного копирования", "возможность восстановления до любого момента времени". Т.е. это что каждая транзакция будет помещаться на ленту? Если это так то это вроде бы должно привести к немеренным тормозам? Если продожить визард дальше то он спрашивает "Путь активного журнала" и предлагает по умолчанию значение "/var/db2fs/db2inst1/NODE0000/SQL00001/SQLOGDIR/" а что это имеется ввиду? Или именно этот файл будет архивироваться на ленту? Зеркалирование включать не вижу смысла т.к. резервирование дисков достаточное. Или это тоже не совсем верно? Надеюсь удалось донести смысл проблемы :) ?
Второе, что я не совсем понял, это ARCHIVESPOOL и BACKUPSPOOL в TSM. Я удалил эти пулы по умолчанию и создал уже новые в LTOPOOL (т.е. чтобы бэкапилось на ленту, а не на диски, где установлен TSM) В свойствах клиента на TSM есть политика и там указывается в какой пул должен бэкапиться данный узел. На данный момент у меня настроенно так: LTOPOOL1->BACKUPSPOOL Т.е. все бэкапы попадают в BACKUPSPOOL. Бэкапы я делаю с узла DB2 командой:
BACKUP DATABASE ARCH USE TSM ....
Имеет ли в моем случае смысл в этих двух пулах? Вроде бы в ARCHIVEPOOL должны попадать архивные копии, которые не должны удаляться. Но как они туда попадут? Каждый раз менять у клиента политику и делать фул бэкап? Ерунда какая то по моему...

И еще, почему то если бэкапить через GUI db2cc визард предлагает только full backup а инкрементальный и диференциальный не доступны для выбора. С чем это может быть связано?

Это пока все что удалось вспомнить :) Если подскажете каким образом построить систему бэкапа на имеющейся системе, хотя бы в общих словах буду премного благодарен :) А так же можно прокоментировать что сделано не правильно, дать какие-нибудь ссылки (типа best practices) или толковую литературу :)
Заранее всем спасибо!

Спасибо всем кто ответил!
Читал всю ночь "Data recovery and high availability" то что надо оказалось. Теперь все гораздо понятнее. Как я понял, если включено "архивирование журналов", то теперь нет необходимости использоват инкрементальный бэкап? Делам раз в неделю полный бэкап базы, а потом ДБ2 уже сам в автоматическом режиме(или гдето нужно сделать дополнительные настройки, чтобы он их в автоматическом режиме бкапил?) архивирует закрытые активные логи. Или я не прав? И остается настроить TSM так, чтобы он бэкапы месячной давности например удалял и вроде с бэкапом все?
Еще правда остался неясным момент в каком случае лучше использовать бэкап табличных пространств (ТП)... Как я понял, это нужно в том случае если скажем есть два ТП, на одном некие статичные данные, которые не меняются и их много, и на втором ТП данные которые постоянно апдейтятся. Вот в этом случае и имеет смысл использовать вариант с бэкапом ТП. Правильно я понял, или есть еще какой-то глубокий смысл в этом варианте? В моем случае используется одно большое пространство USERSPACE1 расположенное непосредственно на диске (DSM) и все таблицы лежат на нем. В нем определен один контейнер размером 20Гб (на первое время) соответственно все данные в одном контейнере. Может это не совсем правильно? Есть какие то рекомендации по размещению данных в конетйнерах, какого размера их лучше делать если планиркется хранить данные, где каждая запись около 1МБ вместе с LOB?
Кстати, еще обнаружил, что дисковая подсистема DS4700 куплена с функцией VolumeCopy. Нутром чую что можно ее как-то использовать для того чтобы бэкапить в TSM сразу диски, а не содержимое БД. На мой взгляд это было бы более правильное решение, и восстанавливать было бы быстрее чем сначала из полного бэкапа, а потом накатывать журналы. Но пока время не хватает на то чтобы разобраться с VolumeCopy, может кто работал с ней , ДБ2 и TSM или знает где описан пример такой связки?
Заранее всем спасибо!

авторБекап - это средство восстановления версии базы на момент бекапа, архивлоги - это средство для восстановления на момент времени (любой до аварии)
Какую стратегию резервирования (и восстановления) использовать обычно определяется требованиями к RPO (recovery point objective) и RTO (recovery time objective)


Мда, не хватает знаний по бэкапам, буду читать лит-ру, правда пока не понятно какую. Может книжку по идеологии бэкапирования какую посоветуете?
А задача простая - при восстановлении должно быть как можно меньше потерянных данных. Т.к. через систему проходят документы, то в идеальном случае данные вообще не должны быть потеряны. Время восстановления не важно, т.к. есть резервная система. Может исходя из этого посоветуете как настроить бэкап лучше для ДБ2?


авторЕсли нагрузка серьезная, то я бы положил ЛОБы в отдельный таблспейс на отдельном RAID-томе.

Нагрузка пока не серьезная, но почитав лит-ру, так и сделал уже. Спасибо.

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

И еще никак не могу понять с архивацией журналов. Я задал 15 праймари журналов и 5 секондари. Размер 4МБ. Настроил бэкапить их в TSM. Но вот я только не пойму, закрытый журнал будет записан в TSM:
1) как только закончится 15ый праймари лог
2) как только закончится 1ый праймари лог
3) это вообще нужно делать ручками, когда заполнятся все 15 праймари
4) еще какой либо вариант...
Есть еще чекбокс, кажется называется "Infinite archive log", а в каком случае его нужно использовать и для чего он нужен? Читаю и не могу разобраться :( Толи мозг уже инфу не воспринимает под конец недели, толи описания бестолковые, толи я такой бестолковый :)