Оптимизация исходной системы — расширенная

Завершено

Это более подробное руководство может быть полезно для экспорта исходных систем VLDB:

Разделение таблицы идентификаторов строк Oracle

Компания SAP выпустила заметку SAP № 1043380, которая содержит сценарий, преобразующий предложение WHERE в файле WHR в значение идентификатора строки. Кроме того, последние версии SAPInst автоматически создают идентификатор СТРОКИ, разделенные WHR-файлы, если SWPM настроен для миграции Oracle в Oracle R3load. Файлы STR и WHR, создаваемые SWPM, не зависят от операционной системы и базы данных (как и все аспекты процесса миграции ОС/БД).

Примечание OSS содержит инструкцию "Разделение таблицы ROWID НЕ МОЖЕТ использоваться, если целевая база данных не является базой данных Oracle". Технически файлы дампа R3load независимы от базы данных и операционной системы. Однако во время импорта в SQL Server невозможно перезапустить пакет. В этом сценарии необходимо удалить всю таблицу, а все пакеты для таблицы перезапущены. Всегда рекомендуется прерывать задачи R3load для определенной разделенной таблицы, ОБРЕЗАТЬ таблицу и перезапускать весь процесс импорта, если один разделенный R3load прерывается. Причина этого заключается в том, что процесс восстановления, встроенный в R3load, включает в себя выполнение одиночных инструкций DELETE от строки к строке для удаления записей, загруженных процессом R3load, который прерывается. Это медленный процесс, который часто вызывает ситуации блокировки базы данных. Опыт показывает, что быстрее будет начать импорт этой конкретной таблицы с самого начала, поэтому ограничение, упомянутое в заметке SAP № 1043380, не является ограничением.

Идентификатор строки имеет недостаток, заключающийся в том, что вычисление разделения должно выполняться во время простоя — см. заметку SAP № 1043380.

Создайте несколько "клонов" базы данных источника и экспортируйте их параллельно.

Одним из способов увеличения производительности экспорта является экспорт из нескольких копий одной и той же базы данных. Если базовая инфраструктура, включая серверы, сеть и хранилище, масштабируема, то такой подход, как правило, является линейно масштабируемым. Экспорт из двух копий одной и той же базы данных выполняется в два раза быстрее, четыре копии — четыре раза быстрее. Монитор миграции настроен на экспорт выбранного количества таблиц из каждого "клона" базы данных. В следующем случае рабочая нагрузка экспорта распределяется примерно на 25 % на каждом из четырех серверов баз данных.

• Сервер базы данных 1 и сервер экспорта 1 — выделенный для крупнейших таблиц 1-4 (в зависимости от того, как распределение данных находится в исходной базе данных)
• Сервер базы данных 2 и сервер экспорта 2 — выделенный для таблиц с разделением таблиц
• Сервер базы данных 3 и сервер экспорта 3 — выделенный для таблиц с разделением таблиц
• Сервер базы данных 4 и экспорт сервера 4 — все остальные таблицы

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

Этот метод является простым и дешевым с стандартным оборудованием Intel, но также возможен для клиентов, работающих с собственным оборудованием UNIX. Существенные аппаратные ресурсы высвобождаются к середине проекта миграции ОС/БД, когда Песочница, Разработка, Оценка качества, Обучение и Системы аварийного восстановления уже перенесены в Azure. Нет строгого требования, чтобы серверы-"клоны" имели идентичные аппаратные ресурсы. При достаточной производительности ЦП, ОЗУ, диска и сети добавление каждого клона увеличивает производительность.

Если дополнительная производительность экспорта по-прежнему требуется, откройте инцидент SAP в BC-DB-MSS для дополнительных шагов для повышения производительности экспорта (только расширенные консультанты).

Ниже приведены действия по реализации нескольких параллельных операций экспорта.

1. Резервное копирование базы данных-источника и восстановление на число серверов n (где n = число клонов). В этом примере предполагается, что n = 3 сервера, что составляет всего четыре сервера базы данных.
2. Восстановление резервного копирования на трех серверах.
3. Установите доставку журналов с сервера первичной исходной базы данных на три целевых сервера клонирования.
4. Отслеживайте отправку журналов в течение нескольких дней и убедитесь, что отправка журналов работает надежно.
5. В начале простоя завершите работу всех серверов приложений SAP, кроме PAS. Убедитесь, что вся пакетная обработка остановлена и весь трафик RFC остановлен.
6. В транзакции SM02 введите текст "Контрольная точка PAS Выполняется". При этом обновляется таблица TEMSG.
7. Остановите работу основного сервера приложений. Теперь работа SAP завершена. В исходной базе данных не может быть других действий записи. Убедитесь, что ни одно из приложений, не связанных с SAP, не подключено к базе данных-источнику (такого не должно быть, но проверьте наличие сеансов, не относящихся к SAP на уровне базы данных).
8. Выполните этот запрос на первичном сервере БД: SELECT EMTEXT FROM [schema].TEMSG;
9. Запустите оператор уровня исходной СУБД: INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss” (точный синтаксис зависит от исходной СУБД. ВСТАВИТЬ в EMTEXT)
10. Остановите автоматическое резервное копирование журналов транзакций. Вручную выполните последнее резервное копирование журнала транзакций на сервере Основной базы данных. Убедитесь, что резервная копия журнала скопирована на серверы-клоны.
11. Восстановите окончательную резервную копию журнала транзакций на всех трех узлах.
12. Восстановите базу данных на 3 узлах-"клонах".
13. Выполните следующую инструкцию SELECT на всех четырех узлах: SELECT EMTEXT FROM [schema].TEMSG;
14. Захватить результаты экрана инструкции SELECT для каждого из четырех серверов базы данных (основной и трех клонов). Не забудьте тщательно включить каждое имя узла, чтобы служить доказательством того, что клонирование базы данных и основной идентичны и содержат одни и те же данные с той же точки во времени.
15. Запустите файл export_monitor.bat на каждом сервере экспорта Intel R3load.
16. Запустите процесс копирования файла дампа в Azure (AzCopy или Robocopy).
17. Запустите import_monitor.bat на Виртуальные машины Azure R3load.

На следующей схеме показана существующая доставка журналов рабочей базы данных сервера для "клонирования" баз данных. Каждый сервер базы данных имеет один или несколько серверов Intel R3load.