Проще всего в таком случае гетерогенное копирование. Со штатной сменой сида
Да и экспорт/импорт манданта никто не отменял. Всяко проще, чем с бэкапом возиться.

Гомо или гетеро - это уже вопрос второй, смотря на какой платформе копия поднимается. Гомо, таки, проще. ИМХО Можно экспорт/импорт не делать.

Ну не знаю. На моей памяти две последних попытки копирования манданта не очень-то больших баз - 200 и 260 гиг всего. Там системы были старые, 4.6 и 4.7 соответственно. Это значит, что объем собственно содержимого манданта не сильно от объема базы отличался.
Первую удалось скопировать, но процесс шел недели две. Вторая за две недели не успела, а там уже дольше ждать было невозможно. Ведь в этот момент в целевой системе работать невозможно. Ну на, такие сроки. С бэкапа поднять быстрее по-любому. С базами большего размера мы это теперь даже и не пытаемся.

кто нибудь использует реально возможности дисковых хранилищ по созданию снапшотов разделов?

кстати, как другие базы (кроме оракла) в этом случае, поднимаются?

На HP XP и EVA эти штуки работают и с Oracle и с MS SQL.

В топку таких аутсорсеров. Куда они бекапы-то делали ?

Для проверки валидности бекап-файла в DB2 используется команда db2ckbkp
Если бекап делается на TSM, то в команде db2adutl есть опция проверки бекапов VERIFY
Правда, если использовать TDP+TSM, то тогда придется выгружать бекап в файл (TDP не умеет чекать бекапы) и потом уже db2ckbkp

Чем закончилось, если не секрет ? Базу восcтановили ?


"На основании этого", я бы рекомендовал послать такого аутсорсера лесом .... пока не поздно.
Жесть какая - аутсорсер без клиентских бекапов.
Это у нас тут в РФ SLAем никого не напугаешь, а вот "за бугром" для такого "аутсорсера" это бы вылилось в очень некислые штрафы.

Ну не знаю. На моей памяти две последних попытки копирования манданта не очень-то больших баз - 200 и 260 гиг всего. Там системы были старые, 4.6 и 4.7 соответственно. Это значит, что объем собственно содержимого манданта не сильно от объема базы отличался.
Первую удалось скопировать, но процесс шел недели две. Вторая за две недели не успела, а там уже дольше ждать было невозможно. Ведь в этот момент в целевой системе работать невозможно. Ну на, такие сроки. С бэкапа поднять быстрее по-любому. С базами большего размера мы это теперь даже и не пытаемся.[/quote]

2 НЕДЕЛИ? 200 гигов? так не бывает.... - ну пара дней - это еще понять можно да и то с трудом если честно. Экспорт манданта максимум сутки на таких объемах да и то это с очень медленными дисками....

Это наверно если размер экспорта получился 200ГБ, правда все равно долго.
На базах от терабайта копии мандантов уже работают неприлично долго, что экспорт/импорт, что SCC9, хоть как параллель, все равно долго, а еще частенько на чем то споткнется... поэтому восстановление из бэкапа либо онлайн копия бртулзами самое оно.

по рассказам коллег, знаю работает такое на фуджиках, бд - оракл, сам не использовал, поэтому деталей не знаю.

Восстановили 2 битые таблицы USR12 и USH12 из системы DEV.
В бекапах таблицы битые оказались.

Из зарубежного опыта: я сейчас у одного крупного аутсоусера в проекте, так коллеги рассказали актуальный случай, что новый клиент хочет DB2, а не хочет Oracle, потому что в DB2 есть функция компримирования данных, которая позволяет экономить место на дисковом пространстве. Однако в Oracle 11G тоже имеется данная фича (как и несколько других нововведений), но о ней, видимо, клиенту этому не рассказали.

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

В смысле компрессирования?
Есть такое в Oracle 11g, говорят не плохо работает. Просто САП очередной раз поцапался с Ораклом вот и продвигают ДБ2, не скуль же им продвигать. Я например слабо себе представляю скульную базу в 5 терр.

Всмысле - сжатия.
На одной линии протестированно, пока - работает.

Возможно ещё один плюс для больших баз данных (> 1TB) в пользу Oracle - возможность, в случае необходимости, быстрого переноса базы данных между платформами с помощью O2O и tripple-O.

в DB2 комрессия действительно очень помогает. у одного клиента базу с 6 ТБ ужали до 3х. Но комперссия рулит только в последней версии 9.7 потому как там есть index compression. в оракле тоже используется но я бы сказал для несколько иных целей. в DB2 комрессию рассматривают как данность, ее включают чуть ли не на этапе блюпринта и дла очень большого кол-ва таблиц/индексов. а в Оракле ее рекомендуют использовать только когда есть какие=то определенные проблемы которые можно этой компрессий решить. например индекс там сжать чтобы места в буфере не занимал. хотя за 11ю версию сказать точно не могу ибо с ней не работал еще.



вы кстати разграничивайте дб2. они же разные бывают по классификации САП: DB2 это DB2 под Z/OS, DB4 это DB2 под OS400 и DB6 - DB2 под LUW(Linux, Unix, Windows). вот если вам рекомендуют DB6 то я SAP прекрасно понимаю ибо "некоторые разногласия с ораклом" и плюс САП работает в очень тесной связке с девелоперами DB2 LUW. этой связке пророчат большое будущее да и поддержка там на очень хорошем уровне.

+1 За Oracle. 14 Тб - полет нормальный.
MS Sql Для небольших баз, имхо.
DB2 вроде тоже неплох, однако компетентных специалистов на него найти очень сложно. Год назад думали о переходе с Oracle 9 на DB6 в результате не нашли специалистов и перешли на Oracle 10.2.0.4.
По поводу компрессии: в оракле тоже есть сжатие и в 10 ке и в 11, разница в том, что 11 версия поддерживает сжатие данных "на лету", а 10ка только при потоковом вводе. Плюс к этому 11 поддерживает несколько уровней компрессии, правда за отдельную плату.
А рекомендации DB2 в основном политические, поссорились они с сапом...