угу угу а мы тут примус починяем:) и баз данных десятки-террабайтных у нас нет:)
Да кстати все вышесказанное - на что тратится основная масса времени при импорте данных при миграции и уж тем более сбор статистики очень мало имеет отношения к ограничениям по DISK I/O - на что Вы как раз и сослались....

Библию читать конечно очень полезно - но не всегда слово божье закон.

но при стандартной миграции - да - downtime 4 часа - это нереально. Надо искать другие возможности.

Да а кстати у меня вопрос - а с чем связано такое решение - миграция системы продуктивной эксплуатации на другую платформу? Было бы интересно услышать обоснование такой необходимости.

Личный опыт - перенос системы из одного ЦОДа в другой - 10 Тб - Downtime - максимум час - засомневалась... или мы брали три - уже два года прошло однако) - коллеги поправят если заметят мой пост. Но тут не было смены платформы - был оракл - использовали как раз технологию создания standby - Downtime понадобился на докат базы до актуального состояния (ретейл, нагрузка большая), переключение в primary и поднятие системы уже на другом сервере и системе хранения. НО - между восстановлением базы данных и актуализацией standby - прошло четыре дня минимум. Так что бывают варианты и вне библии - иногда можно еще и подключить один орган мозг называется:)

Xa-Xа, а у Вас тут весело, террабайтами можно меряться...

Что-ж тогда постоянно крутиться и жужжит (кроме вентиляторов) когда ваши бесценные данные извлекаются из БД, если не Диски? Песня ещё была такая - "КРУТЯТСЯ ДИСКИ"

Никто не отрицает силу русской смекалки, но, что если блоха как у Левши прыгать перестанет? Отлучение от САП суппорта за непослушание зто серьёзная кара в такое тяжёлое для всего бизнеса время, when Production system is down or malfunctioning for the unknown reason и таких примеров у меня есть, так что копите деньги на сертифицированного OS/DB Migration консультанта и не выпендривайтесь

не все так грустно в датском королевстве... прыгучесть блохи это вполне измеряемая и прогнозируемая величина - особенно если точно известно ее физическое состояние...

Но мы отвлеклись от темы.

RE: прыгучесть блохи это вполне измеряемая и прогнозируемая величина

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

есть еще граничные условия. Вот условия топика. По каким-то неизвестным нам причинам принято решение копирования системы продуктивной эксплуатации в гетерогенной среде. Первое, что необходимо было сделать в этом случае (ну например, если бы я в этом случае выступала со стороны внешнего консалта) - ДО принятия решение - предупредить бизнес, что будет необходима миграция системы продуктивной эксплуатации (судя по всему работающая в режиме 24x7) и будет необходим останов продуктивной системы - я бы лично взяла минимум с пятницы вечера до понедельник утра. И должно было быть принято такое решение на самом высоком уровне, учитывая риски простоя продуктивной системы. Для уточнения времени останова - необходимо сделать тестовую миграцию - если конечно существует физическая возможность.
Судя по первому посту этого не было сделано. И появилось условие - время простоя максимум 4 часа.
Сейчас говорить, что это невозможно - может быть уже довольно поздно.
Кстати при чем тут велосипед? Этот велосипед давно изобретен - многими поколениями администраторов баз данных - чьими наработками в данном случае разумней всего пользоваться. Согласитесь, что их квалификация для процедуры переноса базы данных - выше, чем любого сертифицированного сапера по os/db миграции:) Судя по топику смены СУБД не происходит. Потому как если например еще и переходить с DB2 на Oracle - тогда вариантов кроме библии не существует в принципе.

А в моем случае - это было сделать просто необходимо с минимальным временем останова - разводить руками, ссылаясь на стандартную процедуру копирования системы по библии САП и остановить систему минимум на 24 часа - слишком большие финансовые потери компании. На это пойти было нельзя. Просто для каждого действия необходимо выбирать наиболее надежный и подходящий инструмент.

Нет такой буквы в этом слове, а есть САП нота 82478 для благоверных DBA , всем остальным веротступникам - в топик "как сломать SAP"

service.sap.com alias - note освоен - зачет:)
Да кстати - я бы посоветовала привлечь к работам именно грамотного DBA. А не сертифицированного os/db migration сапера:)

ЗЫ - а автор топика пропал.... Мне действительно интересны причины такого решения - смена платформы.

С Вами неинтересно общаться. Вы считаете себя истиной в последней инстанции. Хотя при ответе на вопрос умудряетесь противоречить самому себе. Вас спрашивают про реальность ограничений по скорости ввыда/вывода, Вы начинаете рассказывать про R3load и о том, как Вы зарабатываете на жизнь. Несерьезно, как-то. Не находите?

Вы это так преподносите, как будто будете каждую эту операцию делать лично. Так надо с клиентом разговаривать, чтобы убедить его в своей компетентности. А вот с коллегами так разговаривать не стОит.
И кто Вам сказал, что 750 Gb - это большой объем базы, чтобы обо всех этих операциях говорить аж с придыханием?
На этом объеме я бы даже сказал, что запуск продуктива не обязан предваряться сбором статистики.
А если Вам так уж нравится ссылаться на Библию - то Вам, как сертифицированному консультанту по SAP OS/DB Migration, рекомендую почитать раздел 4.4 стандартной документации по гетерогенному копированию. И обратить внимание на текст "parallel export/import". Ну и про статистику и ее сбор после импорта знания обновите.
Да, забыл, Вы все время ссылаетесь на Unicode Conversion. У нас здесь об этом речь не идет. У нас обычное гетерогенное копирование.

Возвращаясь к топику: повторюсь - попробуйте начать операцию гетерогенного копирования. Вы сумеете оценить время, потребное на экспорт. Если сумеете уложиться в экспорт за час-полтора, то я бы рискнул попробовать уложить всю процедуру за требуемое время. Но подготовка должна быть хорошей. С расписанием по шагам, которые надо выполнить и времени, которые эти шаги занимают.

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

я тоже про аутсорсинг подумала. Миграция разработки и теста - это довольно обычная операция. Но вот временный вариант размещения продуктива - база уже выросла до 750 гиг - хм...
хотя чего только не бывает...

Заклевали вы меня Я не хотел никого обидеть, а про "Крутятся Диски" - так они у меня уже в печёнках сидят после нескольких десятков миграций , которые я делал ЛИЧНО для жадных американских империалистов как раз с использованием Distribution Monitor, Parallel export/import, Unsorted Export, Table split, поблоковой - loadprocedure fast, и много чего еще, о чем простые смертные даже не догадываются, именно для того, чтобы уместиться в прокрустово ложе отведённого downtime.

Теперь про Гетерогенную Копию и Unicode Conversion: это та-же Ж, но только в профиль; UC лишь требует предварительного uptime сканирования всей SAP системы на предмет присвоения правильной Code Page каждой буковке в служебных U-tables, а весь экспорт-импорт производится всё той-же утилитой R3load под чутким руководством MIGMON, cо слегка увеличенными требованиями к CPU и производительности БД по причине необходимости доступа экспортных R3load к вышеупомянутым U-tables в процессе Unicode conversion. Импортным R3load кроме сформированных дата-дампов и заранее приготовленной и оптимизированной для записи full-size базы данных ничего не надо и они могут работать параллельно с экспортом splitted tables, который и занимает основную часть времени.

Так что не ругайте меня, а всецело доверьтесь, т.к. я дело говорю, выстраданное на ЛИЧНОМ ГОРЬКОМ ОПЫТЕ!
См. SAP OS/DB Migration Check – Frequently Asked Questions: http://service.sap.com/osdbmigration

А что касается OS/DB сертификации, так её каждый легко может получит после класса TADM70 при наличии любой Basis certification 620, 640 или 7.0. Но дорого яичко к Христову дню! т.к. этот класс не всегда и не для всех бывает доступен, а миграцию надо делать "здесь и сейчас" и получить от SAP migration & license key и клятвенные заверения в продолжении поддержки продуктивной системы на новой платформе без положительных результатов проверки (OS/DB Migration Check) не прокатит и услуги сертифицированного акушера клиенту всё таки придётся оплатить. На внутреннем сайте SAP есть глобальный список из ~2100 таких акушеров, с которым SAP Support сверяется при проведении проверки. Русских фамилий там всего две (включая мою ).

Видите ли коллега, особенность российского САПа - тут на сертификацию не молятся:) наелись сертифицированных саперов в свое время по самое не могу - прошедших сертификацию после трехмесячного обучения. В общем-то наличие или отсутствие данной бумажки для коллег значения большого не имеет. САП России деревня маленькая - и единственное, что имеет значение - проектная репутация.
Да и кстати узкая специализация тоже не особо распространена.

Это из серии Диски:) - а Вы уверены, что это именно диски медленно крутятся?:) Система ввода вывода СХД - это далеко не только диски однако:) И чаще всего проблема далеко не в дисках....

Но это так.... что-то спать не хочется. Да и по теме все уже всё сказали.

Не хочу показаться занудой, но кто такие "простые смертные"? Это те, кто не удосужился прочитать общедоступные документы? Если я не ошибаюсь все, Вами перечисленное, не является секретной информацией и есть в документации по копированию систем

ЗЫ: На это можно не отвечать.

Я имел в виду OVERALL STORAGE PERFORMANCE и все что с этим связано. Надеюсь я доходчиво рассказал про возможности использования дополнительных серверов для параллельного экспорта-импорта c с целью существенного ускорения процесса, но исходная БД всё равно одна и, скорее всего, клиента не устраивает именно своей производительностью Если вам не удаётся полностью развернуть кластерные таблицы R/3 в shared memory на сервере БД все ваши CPU will idle, а вот диски будут дымиться.

Короче, всё что я тут понаписал не rocket science, но за 4 часа с 750 GB гетерогенной копии явно не управиться. Тут и сказочке конец, а кто слушал - молодец!

P.S. Касательно "не для смертных" - см. Internal SAP Note 1043380. про ROWID Tables splitting скрипт

ээээээээ первый раз слышу - что i-юзверь прилагается к бумажке сертификации:) если мне не изменяет память даже глобальные партнеры имеют c-юзверя. i-юзверь - это принадлежность к SAP AG. Хотя память мне может и изменять конечно:)