Заваливаю всех своими проблемами. Отметился уже в нескольких постах. Имеется трёхсистемный ландшафт и еще одна система в него не входящая. Построено все на ERP 2004 +oracle 9.2+Solaris 10 (sрarc 64).

Поставлена задача - получить в тестовой системе консистентную копию продуктивного манданта. Размер БД продуктивной системе около 300 Гб, максимальное время остановки 9ч.

Попробованы следующие варианты:

1) SCC9 - само собой не получается, т.к. слишком большая база - не успеет перетечь за 9ч.

2) SCC8 - то же что и п.1

3) dbexport - опять всё упирается во время.

4) Копировать всю систему целиком на машину вне ландшафта и потом с неё спокойно любым (1м,2м,3м) способом получить консистентную копию - пока результаты невпечатляющи.

Что было сделано по пункту 4:
Созданы tar архивы каталогов (/oracle, /sapmnt, /usr/sap) продуктивной системы планируется выравнять SID'ы пользователей и групп на целевой системе и перекрестясь стартовать (сказали должно получиться). Но! Для того, чтобы разархивировать базу места просто нет. Было принято решение взять машину на FBSD (простая х86РС) и по NFS расшарить дисковое пространство (стоимость дисков на РС и на Sun Fire очень сильно отличается). Для того, чтобы попробовать как всё будет работать, была предварительно сделана копия аналогичных каталогов системы вне ландшафта и примонтирована вместо локальных на том же сервере (то есть изменились лишь точки монтирования, что в любом случае произойдёт при восстановлении из архива).
Стартуем:
1) su - orasid -c "lsnrctl start"
Всё хорошо, сообщение при загрузке символ в симол повторяет аналогичное сообщение при старте с локального диска.
2) su - sidadm -c "sapstart"
Стартует saposcol, загрузка продолжается, выводится собщение о проверке БД и всё... просто виснет без возможности даже прервать процесс - приходится рубить консоль. В логе старта инстанции сказано " БД еррор 12 (база не существует)"

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

Идти по этому пути можно
для начала неплохо было бы поднять оракл не с помощью startsap собственно средствами оракл ну а дальше смотреть где косяки, скорее всего профили юзеров sidadm и orasid не скопированы

Я пытаюсь запустить ту же систему, что и стояла - отмонтировав каталог /oracle, монтирую его копию из tar'a но через NFS (попытка решить проблему с диском). То есть sid'ы не менялись.

Я не очень понимаю о каких инструментах идёт речь? Скажите пожалуйста названия - я на сервис-портале посмотрю. Или речь об оракл клиенте не поставляемом с SAP'ом?

Задача поставлена некорректно. Единственно правильный вариант решения этой задачи – SCC9. Все остальные тупо убивают тестовую систему как таковую.

1) Насколько я читал в других топиках - существуют способы копирования системы целиком.

2) Есть бизнес, который ставит задачи и есть технические специалистыих решающие. (извините за пафос)

А еще есть, извините за пафос, идеология САП, где тестовая система предназначена для тестирования разработок, а не для хранения копии продуктива.

На Вашем месте я бы сказал бизнесу правду. При решении задачи мы получаем копию продуктивной системы, отказываемся от своего ландшафта и теста. Оформив все это в документарном виде, чтобы потом не возникло вопросов, “мы говорили, а мы не так поняли”.

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

1) Сначала необходимо определиться, какая именно копия продуктивной системы нужна: с/без манданто-независимых настроек. В зависимости от этого уже и плясать. Т.е. копирование манданта не затрагивает манданто-независимые настройки. Скажите, у вас в компании есть вариант восстановления продуктивной системы, если полностью накроется "медным тазом" продуктивный сервер? По идее должен быть сервер с достаточным свободным местом для восстановления... И должен быть отлаженный регламент в случае краха продуктива. И должно проводиться тестовое восстановления, хотя-бы для тестирования способа восстановления и времени, которое потребуется. 300ГБ... Бизнесу наверное не критична остановка продуктива на неделю?

2) Это мы уже проходили... Это всё из-за того, что функциональные консультанты, которым лень пользоваться транспортной системой, ваяют в тесте, продуктиве, а потом просят, чтобы всё выравнили, так как уже не помнят, что, где и когда...

А какова цель получения копии продуктива? Они хотят тестировать на продуктивных данных? Чтобы была? Обучение пользователей?

Здесь можно спорить. SCC9 годится на объемах в сотни МБ, дальше - тупик, время копирования будет измеряться несколькими сутками.
Никто продуктив на такой период не остановит.
IMHO восстановление в тестовую систему, при наличии достаточного свободного пространства в файловой системе, online/offline backup'a продуктивной системы легко решает проблему.

Поправлю, в сотни ГБ. Терабайты действительно непросто прокачать. А что делать с запросами, которые тестируются в данный момент в тестовой системе? Вопрос риторический и возможно к автору темы не применим, т.к. деталей проекта мы не знаем. По любому, подобные манипуляции в ландшафте некорректны. Нужна копия продуктива, значит нужна какая-то отдельная железяка, но не тестовая.

По сути - это проблемы всего отдела , мы как специалисты не смогли своевременно определить потребности системы в свободном месте и это наша ошибка. Идеология САП - это прекрасная утопия.

Бизнес глух =) Я не могу говорить напрямую с бизнесом через голову начальства, думаю, Вы меня понимаете. Произошло то, что произошло. И я как человек, который пытается стать хорошим специалистом не могу себе позволить тратить время на поиск виноватых (опять пафос ).

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

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

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

Я скорее всего сумбурно выразил свои проблемы , приношу извинения, все эти манипуляции делаются на машине вне ландшафта, и потом с неё планируется осуществить резервное копирование или экспорт.

Категорически не согласен. Транспортная система, настроенная и работающая - это наше все!

У Вас холодный бэкап делается? Вам хватает 9-ти часов? Тогда должно хватить и для экспорта манданта. Если не успеваете сделать экспорт по сетке - цепляйте диск локально. Потом импортируйте.
Не забудьте остановить на время этих процедур все переносы в тестовую систему и донести до продуктива все транспорты, чтобы потом не решать новые проблемы.
Лучшим вариантом все равно будет предварительный эксперимент на отдельной железке. Поставьте, в конце концов, обычный десктоп с SATA дисками, 4 Gb памяти Вам хватит для опытов.

хм... а копирование гомогенное или гетерогенное?

если гетерогенное - а как я понимаю - соляра - линукс?:) то танцы с бубнами обеспечены - с восстановлением из бэкапа:)
хоть по информации оракул 10 и умеет это делать - перенос файлов между системами - но не так же в лоб

А вообще есть хороший документ по копированию систем - как гомо так и гетеро генны