Миграция данных, ETL и нагрузок из Oracle
Эта статья представляет собой вторую из семи статей, посвященных рекомендациям по миграции данных из Oracle в Azure Synapse Analytics. Эта статья посвящена рекомендациям по переносу процессов ETL и нагрузки.
Рекомендации по переносу данных
При переносе данных, ETL и нагрузок из устаревшего хранилища данных и киосков данных Oracle в Azure Synapse следует учитывать множество факторов.
Первоначальные решения о переносе данных из Oracle
При планировании миграции из существующей среды Oracle рассмотрите следующие вопросы, связанные с данными:
Следует ли переносить неиспользуемые структуры таблиц?
Какой подход к миграции лучше всего подходит для минимизации рисков и последствий для пользователей?
При переносе киосков данных они должны оставаться физическими или виртуальными?
В следующих разделах эти моменты рассматриваются в контексте миграции из Oracle.
Переносить неиспользуемые таблицы?
Переносить целесообразно только используемые таблицы. Неактивные таблицы можно архивировать, а не переносить, чтобы данные были доступны при необходимости в будущем. Для определения того, какие таблицы используются, лучше всего использовать системные метаданные и файлы журналов, а не документацию, так как документация может быть устаревшей.
Если этот параметр включен, таблицы и журналы системных каталогов Oracle содержат сведения, которые позволяют определить время последнего доступа к конкретной таблице, что, в свою очередь, может быть использовано для принятия решения о том, является ли таблица кандидатом на миграцию.
Если у вас есть лицензия на пакет диагностики Oracle, у вас есть доступ к журналу активных сеансов, который можно использовать для определения времени последнего доступа к таблице.
Совет
В устаревших системах таблицы нередко становятся избыточными с течением времени. В большинстве случаев их не нужно переносить.
Ниже приведен пример запроса, который ищет использование определенной таблицы в течение заданного периода времени:
SELECT du.username,
s.sql_text,
MAX(ash.sample_time) AS last_access ,
sp.object_owner ,
sp.object_name ,
sp.object_alias as aliased_as ,
sp.object_type ,
COUNT(*) AS access_count
FROM v$active_session_history ash
JOIN v$sql s ON ash.force_matching_signature = s.force_matching_signature
LEFT JOIN v$sql_plan sp ON s.sql_id = sp.sql_id
JOIN DBA_USERS du ON ash.user_id = du.USER_ID
WHERE ash.session_type = 'FOREGROUND'
AND ash.SQL_ID IS NOT NULL
AND sp.object_name IS NOT NULL
AND ash.user_id <> 0
GROUP BY du.username,
s.sql_text,
sp.object_owner,
sp.object_name,
sp.object_alias,
sp.object_type
ORDER BY 3 DESC;
Выполнение этого запроса может занять некоторое время, если вы выполняете многочисленные запросы.
Каков оптимальный подход к миграции для минимизации рисков и воздействия на пользователей?
Этот вопрос возникает часто, так как компании хотят снизить влияние изменений на модель данных хранилища данных для повышения гибкости. Компании часто видят возможность дальнейшей модернизации или преобразования данных во время миграции ETL. Такой подход сопряжен с более высоким риском, поскольку он изменяет несколько факторов одновременно, что затрудняет сравнение результатов старой и новой систем. Внесение изменений в модель данных также может повлиять на задания ETL для других, вышестоящих или нижестоящих, систем. Из-за этого риска лучше изменить масштаб после переноса хранилища данных.
Даже если модель данных планово изменяется в рамках общей миграции, рекомендуется перенести существующую модель в Azure Synapse "как есть", а не выполнять какие-либо изменения на новой платформе. Такой подход позволяет свести к минимуму влияние на существующие рабочие системы, а также использовать производительность и эластичное масштабирование платформы Azure для одноразовых задач повторной разработки.
Совет
Переносите существующую модель "как есть", даже если в будущем планируется изменение модели данных.
Миграция киоска данных: остаться в физической среде или перейти в виртуальную?
В устаревших средах хранилища данных Oracle рекомендуется создавать множество киосков данных, структурированных для обеспечения хорошей производительности для нерегламентированных запросов самообслуживания и отчетов для определенного отдела или бизнес-функции в организации. Киоск данных обычно состоит из подмножества хранилища данных, которое содержит агрегированные версии данных в форме, которая позволяет пользователям легко запрашивать эти данные и быстро получать ответ. Пользователи могут использовать удобные средства запросов, такие как Microsoft Power BI, которые поддерживают взаимодействие бизнес-пользователей с киосками данных. Форма данных в киоске данных обычно является многомерной моделью данных. Помимо прочего, киоски данных предоставляют данные в пригодной для использования форме, даже если базовая модель данных отличается, например имеет вид хранилища ("сейфа") данных.
Для отдельных подразделений в организации можно использовать отдельные киоски данных, что позволит установить надежные режимы безопасности данных. Можно ограничить пользователю доступ к определенным актуальным для него киоскам данных, а также исключить, маскировать или анонимизировать конфиденциальные данные.
Если эти киоски данных реализованы как физические таблицы, для их размещения потребуются дополнительные ресурсы хранения, а для их регулярной сборки и обновления необходимы дополнительные возможности обработки. Кроме того, данные в киоске будут актуальны только на момент последней операции обновления и поэтому могут быть непригодными для панелей мониторинга данных с высокой степенью изменчивости.
Совет
Виртуализация киосков данных позволяет сэкономить на ресурсах для хранения и обработки.
С появлением более бюджетных масштабируемых архитектур MPP, таких как Azure Synapse, и присущих таким архитектурам характеристик производительности, вы сможете обеспечить функциональность киоска данных, не создавая экземпляр киоска в виде набора физических таблиц. Одним из способов является эффективная виртуализация киосков данных с помощью представлений SQL в основном хранилище данных. Другой способ — виртуализация киосков данных с помощью слоя виртуализации с помощью таких функций, как представления в Azure или сторонних продуктах виртуализации. Такой подход уменьшает или исключает необходимость в дополнительном хранилище и обработке агрегирования и сокращает общее количество переносимых объектов базы данных.
Существует еще одна потенциальная выгода от такого подхода. Реализация логики агрегирования и объединения на уровне виртуализации и отображение внешних инструментов отчетности в виртуализированном представлении переносит обработку, необходимую для создания этих представлений, в хранилище данных. Хранилище данных обычно является оптимальным местом для запуска соединений, операций агрегирования и других связанных операций с большими объемами данных.
Ниже приводятся основные доводы в пользу реализации виртуального, а не физического киоска данных:
Гибкость — виртуальный киоск данных изменить легче, чем физические таблицы и связанные с ним процессы извлечения, преобразования и загрузки.
Более низкая совокупная стоимость владения: меньшее количество хранилищ данных и копий данных в виртуализированной реализации.
Исключение заданий извлечения, преобразования и загрузки при миграции и упрощение архитектуры хранилища данных в виртуализированной среде.
Производительность: несмотря на то, что в прошлом физические киоски данных имели преимущество с точки зрения производительности, технологии интеллектуального кэширования, реализованные в современных системах виртуализации, нивелировали это преимущество.
Совет
Производительность и масштабируемость Azure Synapse обеспечивает виртуализацию без ущерба для производительности.
Перенос данных из Oracle
Расшифровка данных
При планировании миграции необходимо подробно определить объем данных, которые необходимо перенести, так как это может повлиять на выбор способа миграции. Для определения физического пространства, занимаемого необработанными данными в таблицах для переноса, используйте системные метаданные. В этом контексте термин "необработанные данные" означает объем пространства, используемого строками данных в таблице, за исключением издержек, таких как индексы и сжатие. Самые большие по объему таблицы фактов обычно составляют более 95 % данных.
Этот запрос позволяет получить общий размер базы данных в Oracle:
SELECT
( SELECT SUM(bytes)/1024/1024/1024 data_size
FROM sys.dba_data_files ) +
( SELECT NVL(sum(bytes),0)/1024/1024/1024 temp_size
FROM sys.dba_temp_files ) +
( SELECT SUM(bytes)/1024/1024/1024 redo_size
FROM sys.v_$log ) +
( SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 controlfile_size
FROM v$controlfile ) "Size in GB"
FROM dual
Размер базы данных равен размеру (data files + temp files + online/offline redo log files + control files). Общий размер базы данных включает использованное и свободное пространство.
В следующем примере запроса приводится разбивка дискового пространства, используемого табличными данными и индексами:
SELECT
owner, "Type", table_name "Name", TRUNC(sum(bytes)/1024/1024) Meg
FROM
( SELECT segment_name table_name, owner, bytes, 'Table' as "Type"
FROM dba_segments
WHERE segment_type in ('TABLE','TABLE PARTITION','TABLE SUBPARTITION' )
UNION ALL
SELECT i.table_name, i.owner, s.bytes, 'Index' as "Type"
FROM dba_indexes i, dba_segments s
WHERE s.segment_name = i.index_name
AND s.owner = i.owner
AND s.segment_type in ('INDEX','INDEX PARTITION','INDEX SUBPARTITION')
UNION ALL
SELECT l.table_name, l.owner, s.bytes, 'LOB' as "Type"
FROM dba_lobs l, dba_segments s
WHERE s.segment_name = l.segment_name
AND s.owner = l.owner
AND s.segment_type IN ('LOBSEGMENT','LOB PARTITION','LOB SUBPARTITION')
UNION ALL
SELECT l.table_name, l.owner, s.bytes, 'LOB Index' as "Type"
FROM dba_lobs l, dba_segments s
WHERE s.segment_name = l.index_name
AND s.owner = l.owner
AND s.segment_type = 'LOBINDEX')
WHERE owner in UPPER('&owner')
GROUP BY table_name, owner, "Type"
HAVING SUM(bytes)/1024/1024 > 10 /* Ignore really small tables */
ORDER BY SUM(bytes) desc;
Кроме того, команда Microsoft по миграции баз данных предоставляет множество ресурсов, включая артефакты скриптов инвентаризации Oracle. Этот ресурс включает в себя запрос PL/SQL, который осуществляет доступ к системным таблицам Oracle и возвращает количество объектов по типам схем, типам объектов и состоянию. Он также дает приблизительную оценку объема "необработанных данных" и размера таблиц в каждой схеме. Результаты сохраняются в формате CSV. Включенная электронная таблица с калькулятором принимает CSV-файл в качестве входных данных и предоставляет данные по размеру.
Для любой таблицы можно точно спрогнозировать объем переносимых данных путем извлечения репрезентативной выборки данных, например одного миллиона строк, в несжатый неструктурированный файл данных ASCII с разделителями. Затем по размеру этого файла можно определить средний размер необработанных данных на строку. Наконец, умножьте этот средний объем на общее количество строк в полной таблице, чтобы получить объем необработанных данных в таблице. Используйте этот объем необработанных данных при планировании.
Использование запросов SQL для поиска типов данных
Запросив представление словаря статических данных Oracle DBA_TAB_COLUMNS, можно определить, какие типы данных используются в схеме и нужно ли изменить какие-либо из этих типов данных. Используйте SQL-запросы, чтобы найти столбцы в любой схеме Oracle с типами данных, которые напрямую не сопоставляются типам данных в Azure Synapse. Аналогичным образом можно использовать запросы для подсчета количества вхождений каждого типа данных Oracle, который не сопоставляется напрямую Azure Synapse. Используя результаты этих запросов в сочетании с таблицей сравнения типов данных, можно определить, какие типы данных необходимо изменить в среде Azure Synapse.
Чтобы найти столбцы с типами данных, которые не сопоставляются с типами данных в Azure Synapse, выполните следующий запрос после замены <owner_name> соответствующим владельцем схемы:
SELECT owner, table_name, column_name, data_type
FROM dba_tab_columns
WHERE owner in ('<owner_name>')
AND data_type NOT IN
('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE')
ORDER BY 1,2,3;
Чтобы подсчитать количество несопоставляемых типов данных, используйте следующий запрос:
SELECT data_type, count(*)
FROM dba_tab_columns
WHERE data_type NOT IN
('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE')
GROUP BY data_type
ORDER BY data_type;
Microsoft предлагает помощник по миграции Microsoft SQL Server (SSMA) для Oracle, позволяющий автоматизировать перенос хранилищ данных из устаревших сред Oracle, включая сопоставление типов данных. Для планирования и выполнения миграции из таких сред, как Oracle, также можно использовать службы миграции Azure Database Migration Service. Сторонние поставщики также предлагают инструменты и сервисы для автоматизации миграции. Если в среде Oracle уже используется сторонний инструмент для извлечения, преобразования и загрузки (ETL) данных, можно воспользоваться им для выполнения всех необходимых преобразований с данными. В следующем разделе рассматривается миграция существующих процессов извлечения, преобразования и загрузки.
Рекомендации по миграции ETL
Первоначальные решения о миграции ETL из Oracle
Для обработки ETL/ELT устаревшие хранилища данных Oracle часто используют пользовательские скрипты, сторонние инструменты ETL или сочетание подходов, которые развивались с течением времени. При планировании миграции в Azure Synapse необходимо определить оптимальный способ реализации необходимой обработки ETL/ELT в новой среде, а также минимизировать затраты и риски.
Совет
Планируйте подход к миграции ETL заранее и используйте средства Azure, где это необходимо.
В этой блок-схеме обобщенно представлен один из подходов:
Как показано в блок-схеме, начальным шагом всегда является создание инвентаризации процессов ETL/ELT, которые необходимо перенести. Благодаря стандартным встроенным функциям Azure некоторые существующие процессы, возможно, переносить не потребуется. В целях планирования важно понимать масштабы миграции. Далее рассмотрим вопросы в дереве принятия решений блок-схемы:
Перейти в собственную среду Azure? Ответ зависит от того, выполняется ли миграция в полностью собственную среду Azure. Если вы переходите в собственную среду Azure, рекомендуется перепроектировать обработку ETL с помощью конвейеров и действий в фабрике данных Azure или конвейеров Azure Synapse.
Используется ли сторонний инструмент ETL? Если вы не переходите на собственную среду Azure, проверьте, не используется ли имеющийся сторонний инструмент ETL. В среде Oracle может оказаться, что некоторые или все операции обработки ETL выполняются пользовательскими скриптами с помощью таких служебных программ Oracle, как Oracle SQL Developer, Oracle SQL*Loader или Oracle Data Pump. В этом случае следует выполнить перепроектирование с использованием фабрики данных Azure.
Поддерживает ли сторонний поставщик выделенные пулы SQL в Azure Synapse? Оцените, были ли сделаны значительные инвестиции в обучение работе со сторонним ETL-инструментом и используется ли этот инструмент в существующих рабочих процессах и расписаниях. В этом случае определите, можно ли с помощью этого инструмента эффективно осуществлять поддержку Azure Synapse в качестве целевой среды. В идеале это средство будет включать в себя встроенные соединители, которые могут использовать такие средства Azure, как PolyBase или COPY INTO, для наиболее эффективной загрузки данных. Но даже без собственных соединителей обычно можно вызывать внешние процессы, такие как PolyBase или
COPY INTO, и передавать соответствующие параметры. В этом случае используйте существующие навыки и рабочие процессы с Azure Synapse в качестве новой целевой среды.Если вы используете Oracle Data Integrator (ODI) для обработки ELT, вам потребуются модули знаний ODI для Azure Synapse. Если эти модули недоступны в вашей организации, но у вас есть ODI, вы можете использовать ODI для создания неструктурированных файлов. Эти неструктурированные файлы затем можно переместить в Azure и принять в Azure Data Lake Storage для загрузки в Azure Synapse.
Выполняются ли ETL-инструменты в Azure? Если вы решите сохранить существующее средство ETL стороннего производителя, можно запустить это средство в среде Azure (а не на существующем локальном сервере ETL), а фабрика данных Azure будет выполнять общую оркестрацию существующих рабочих процессов. Таким образом, нужно решить, следует ли оставить существующее средство запущенным как есть или переместить его в среду Azure для получения преимуществ в области стоимости, производительности и масштабируемости.
Совет
Рассмотрите возможность запуска ETL-инструментов в Azure, чтобы использовать преимущества в области производительности, масштабируемости и стоимости.
Перепроектирование существующих скриптов Oracle
Если некоторые или все существующие операции обработки ETL/ELT хранилища Oracle обрабатываются пользовательскими скриптами, которые используют специальные служебные программы Oracle, такие как Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader или Oracle Data Pump, необходимо перекодировать эти скрипты для среды Azure Synapse. Аналогично, если процессы ETL были реализованы с помощью хранимых процедур в Oracle, необходимо перекодировать эти процессы.
Некоторые элементы процесса ETL переносятся легко, например путем простой массовой загрузки данных в промежуточную таблицу из внешнего файла. Возможно, эти части процесса даже можно автоматизировать, например, с помощью Azure Synapse COPY INTO или PolyBase вместо SQL*Loader. Другие части процесса, которые содержат произвольные сложные SQL и (или) хранимые процедуры, потребуют больше времени для повторной перепроектировки.
Совет
Список задач ETL для переноса должен включать скрипты и хранимые процедуры.
Одним из способов тестирования Oracle SQL на совместимость с Azure Synapse является запись нескольких репрезентативных инструкций SQL из соединения Oracle v$active_session_history и v$sql и получения sql_text, а затем добавления в эти запросы EXPLAIN в качестве префикса. Если в Azure Synapse используется аналогичная перенесенная модель данных, выполните эти инструкции EXPLAIN в Azure Synapse. При наличии несовместимого SQL возникнет ошибка. Эту информацию можно использовать, чтобы определить масштаб задачи перекодирования.
Совет
Используйте EXPLAIN для обнаружения несовместимостей SQL.
В худшем случае может потребоваться перезапись вручную. Тем не менее, существуют предоставляемые партнерами Microsoft продукты и службы, которые помогут перепроектировать код Oracle.
Совет
Партнеры предлагают продукты и навыки для перепроектирования кода Oracle.
Использование сторонних ETL-инструментов
Во многих случаях существующая устаревшая система хранилища данных заполняется и поддерживается с использованием сторонних продуктов ETL. Список действующих партнеров Microsoft по интеграции данных для Azure Synapse см. в статье Партнеры по интеграции данных в Azure Synapse Analytics.
Сообщество Oracle часто использует несколько популярных продуктов ETL. В следующих абзацах рассматриваются наиболее популярные инструменты ETL для хранилищ Oracle. Вы можете запустить все эти продукты на виртуальной машине в Azure и использовать их для чтения и записи баз данных и файлов Azure.
Совет
Используйте уже приобретенные сторонние средства, чтобы снизить затраты и риски.
Загрузка данных из Oracle
Доступные варианты при загрузке данных из Oracle
При подготовке к переносу данных из хранилища данных Oracle необходимо решить, как данные будут физически перемещаться из существующей локальной среды в Azure Synapse в облаке и какие инструменты будут использоваться для передачи и загрузки. Ответьте на следующие вопросы, обсуждаемые в следующих разделах.
Вы будете извлекать данные в файлы или перемещать их непосредственно через сетевое подключение?
Оркестрация процесса будет выполняться из исходной системы или из целевой среды Azure?
Какие инструменты будут использоваться для автоматизации и контроля процесса миграции?
Передача данных должна осуществляться через файлы или сетевое подключение?
После создания таблиц базы данных, которые будут перенесены в Azure Synapse, можно переместить данные для заполнения этих таблиц из устаревшей системы Oracle в новую среду. Существует два основных подхода:
Извлечение в файл: извлечение данных из таблиц Oracle в неструктурированные файлы с разделителями, как правило в формате CSV. Данные таблицы можно извлечь несколькими способами:
- Используйте стандартные средства Oracle, такие как SQL*Plus, SQL Developer и SQLcl.
- Используйте Oracle Data Integrator (ODI) для создания неструктурированных файлов.
- Используйте соединитель Oracle в фабрике данных для параллельной выгрузки таблиц Oracle, чтобы обеспечить загрузку данных по секциям.
- Используйте сторонний ETL-инструмент.
Примеры извлечения табличных данных Oracle см. в приложении.
Для этого подхода требуется место для размещения извлеченных файлов данных. Пространство может быть локальным для базы данных-источника Oracle (если доступно достаточно места в хранилище) или удаленным в хранилище BLOB-объектов Azure. Оптимальная производительность достигается при локальной записи файла, так как это позволяет избежать сетевых издержек.
Чтобы свести к минимуму требования к хранилищу и сетевой передаче, рекомендуется сжать извлеченные файлы данных с помощью служебной программы, например gzip.
После извлечения переместите неструктурированные файлы в Хранилище BLOB-объектов Azure. Microsoft предоставляет различные варианты перемещения больших объемов данных, в том числе:
- AzCopy для перемещения файлов по сети в службу хранилища Azure.
- Azure ExpressRoute для перемещения массовых данных через частное сетевое подключение.
- Azure Data Box для перемещения файлов на физическое устройство хранения, которое вы отправляете в центр обработки данных Azure для загрузки.
Дополнительные сведения см. в разделе Передача данных в Azure и обратно.
Прямое извлечение и загрузка по сети: целевая среда Azure отправляет запрос на извлечение данных( обычно с помощью команды SQL) в устаревшую систему Oracle для извлечения данных. Результаты отправляются по сети и загружаются непосредственно в Azure Synapse без необходимости помещать данные в промежуточные файлы. Ограничивающим фактором в этом сценарии обычно является пропускная способность сетевого подключения между базой данных Oracle и средой Azure. Для очень больших объемов данных такой подход может оказаться нецелесообразным.
Совет
Определите объем данных, которые необходимо перенести, и доступную пропускную способность сети, так как эти факторы влияют на решение о подходе к миграции.
Существует также гибридный подход, при котором используются оба метода. Например, для небольших таблиц измерений и образцов больших таблиц фактов можно использовать метод непосредственного извлечения по сети, чтобы быстро предоставить тестовую среду в Azure Synapse. Для таблиц исторических фактов большого объема можно использовать метод извлечения и передачи файлов с помощью Azure Data Box.
Оркестрация осуществляется из Oracle или Azure?
При переходе на Azure Synapse рекомендуется координировать извлечение и загрузку данных из среды Azure, используя SSMA или фабрику данных. Для максимально эффективной загрузки данных используйте связанные служебные программы, такие как PolyBase или COPY INTO. Этот подход позволяет использовать встроенные возможности Azure и облегчает создание конвейеров загрузки данных для многократного использования. Для автоматизации миграции можно использовать конвейеры загрузки данных на основе метаданных.
Рекомендуемый подход также снижает нагрузку с точки зрения производительности на существующую среду Oracle в процессе загрузки данных, так как процессы управления и загрузки выполняются в Azure.
Существующие инструменты миграции данных
Преобразование и перемещение данных — основная функция всех продуктов ETL. Если инструмент миграции данных уже используется в существующей среде Oracle и поддерживает Azure Synapse в качестве целевой среды, рассмотрите возможность использования этого инструмента для упрощения миграции данных.
Даже если существующий инструмент ETL не используется, партнеры по интеграции данных Azure Synapse Analytics предлагают инструменты ETL для упрощения миграции.
Наконец, если вы планируете использовать инструмент ETL, рассмотрите возможность запуска этого инструмента в среде Azure, чтобы воспользоваться преимуществами облака Azure с точки зрения производительности, масштабируемости и затрат. Такой подход также освобождает ресурсы в центре обработки данных Oracle.
Итоги
Ниже приведены рекомендации по переносу данных и связанных процессов ETL из Oracle в Azure Synapse:
Планируйте заранее, чтобы обеспечить успешную миграцию.
Как можно скорее создайте подробный список данных и процессов, которые необходимо перенести.
Используйте системные метаданные и файлы журналов, чтобы получить точное представление об использовании данных и процессов. Не полагайтесь на документацию, так как она может быть устаревшей.
Определите объем данных, которые необходимо перенести, и пропускную способность сети между локальным центром обработки данных и облачными средами Azure.
Рассмотрите возможность использования экземпляра Oracle на виртуальной машине Azure в качестве промежуточного этапа для облегчения миграции из устаревшей среды Oracle.
Используйте стандартные встроенные функции Azure, чтобы свести к минимуму рабочую нагрузку миграции.
Определите и изучите наиболее эффективные средства для извлечения и загрузки данных в средах Oracle и Azure. Используйте соответствующие средства на каждом этапе процесса.
Используйте такие средства Azure, как фабрика данных, для оркестрации и автоматизации процесса миграции, минимизируя влияние на систему Oracle.
Приложение. Примеры методов извлечения данных Oracle
Вы можете использовать несколько методов для извлечения данных Oracle при миграции из Oracle в Azure Synapse. В следующих разделах показано, как извлечь данные Oracle с помощью Oracle SQL Developer и соединителя Oracle в фабрике данных.
Использование Oracle SQL Developer для извлечения данных
Пользовательский интерфейс Oracle SQL Developer можно использовать для экспорта данных таблицы во множество форматов, включая CSV, как показано на следующем снимке экрана:
Другие параметры экспорта включают JSON и XML. В пользовательском интерфейсе можно добавлять набор табличных имен в "корзину", а затем выполнять операции экспорта со всем набором в корзине:
Также для экспорта данных Oracle можно использовать командную строку Oracle SQL Developer (SQLcl). Этот параметр поддерживает автоматизацию с помощью скрипта оболочки.
Для относительно небольших таблиц этот метод может оказаться полезным при возникновении проблем с извлечением данных через прямое подключение.
Использование соединителя Oracle в фабрике данных Azure для параллельного копирования
Соединитель Oracle в фабрике данных можно использовать для параллельной выгрузки больших таблиц Oracle. Соединитель Oracle предоставляет встроенную функцию секционирования данных для параллельного копирования из Oracle. Параметры секционирования данных можно найти на вкладке Источник действия копирования.
Сведения о настройке соединителя Oracle для параллельного копирования см. в статье Параллельное копирование из Oracle.
Дополнительные сведения о производительности и масштабируемости действий копирования в фабрике данных см. в Руководстве по производительности и масштабируемости действий копирования.
Следующие шаги
Сведения об операциях безопасного доступа см. в следующей статье этой серии Безопасность, доступ и операции при миграции из Oracle.