Migração de dados, ETL e carregamento para migrações Oracle

Este artigo é a segunda parte de uma série de sete partes que fornece orientações sobre como migrar do Oracle para o Azure Synapse Analytics. O foco deste artigo são as melhores práticas para ETL e migração de carga.

Considerações sobre migração de dados

Existem muitos fatores a considerar ao migrar dados, ETL e cargas de um data warehouse Oracle antigo e data marts para o Azure Synapse.

Decisões iniciais sobre a migração de dados da Oracle

Ao planear uma migração a partir de um ambiente Oracle existente, considere as seguintes questões relacionadas com dados:

• As estruturas de tabelas não utilizadas devem ser migradas?

• Qual é a melhor abordagem de migração para minimizar o risco e o impacto para os utilizadores?

• Ao migrar data marts: manter-se físico ou optar pelo virtual?

As secções seguintes discutem estes pontos no contexto de uma migração de Oracle.

Migrar tabelas não utilizadas?

Faz sentido migrar apenas as tabelas que estão em uso. Tabelas que não estão ativas podem ser arquivadas em vez de migradas, para que os dados estejam disponíveis se necessário no futuro. É melhor usar metadados do sistema e ficheiros de registo em vez de documentação para determinar quais as tabelas em uso, porque a documentação pode estar desatualizada.

As tabelas e registos de catálogo do sistema Oracle contêm informação que pode ser usada para determinar quando uma dada tabela foi acedida pela última vez — o que, por sua vez, pode ser usado para decidir se uma tabela é ou não candidata à migração.

Se licenciaste o Oracle Diagnostic Pack, então tens acesso ao Histórico de Sessões Ativas, que podes usar para determinar quando uma tabela foi acedida pela última vez.

Aqui está um exemplo de consulta que procura a utilização de uma tabela específica dentro de uma dada janela temporal:

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;

Esta consulta pode demorar algum tempo a ser executada se tiver feito várias consultas.

Qual é a melhor abordagem de migração para minimizar o risco e o impacto nos utilizadores?

Esta questão surge frequentemente porque as empresas podem querer reduzir o impacto das alterações no modelo de dados do data warehouse para melhorar a agilidade. As empresas veem frequentemente uma oportunidade para modernizar ou transformar ainda mais os seus dados durante uma migração ETL. Esta abordagem acarreta um risco maior porque altera múltiplos fatores simultaneamente, tornando difícil comparar os resultados do sistema antigo com o novo. Alterar o modelo de dados aqui pode também afetar trabalhos ETL a montante ou a jusante em outros sistemas. Por causa desse risco, é melhor redesenhar nesta escala após a migração do data warehouse.

Mesmo que um modelo de dados seja intencionalmente alterado como parte da migração global, é boa prática migrar o modelo existente as-is para o Azure Synapse, em vez de fazer qualquer reengenharia na nova plataforma. Esta abordagem minimiza o impacto nos sistemas de produção existentes, beneficiando ao mesmo tempo do desempenho e da escalabilidade elástica da plataforma Azure para tarefas pontuais de reengenharia.

Migração para data mart: manter-se físico ou optar pelo virtual?

Em ambientes de data warehouse Oracle legados, é prática comum criar muitos data marts estruturados para proporcionar bom desempenho para consultas e relatórios de autoatendimento ad hoc para um determinado departamento ou função de negócio dentro de uma organização. Um data mart consiste tipicamente num subconjunto do data warehouse que contém versões agregadas dos dados numa forma que permite aos utilizadores consultar facilmente esses dados com tempos de resposta rápidos. Os utilizadores podem usar ferramentas de consulta fáceis de usar como o Microsoft Power BI, que suporta interações empresariais com data marts. A forma dos dados num data mart é geralmente um modelo de dados dimensional. Uma das utilizações dos data marts é expor os dados numa forma utilizável, mesmo que o modelo de dados subjacente ao armazém de dados seja diferente, como um data vault.

Pode usar data marts separados para unidades de negócio individuais dentro de uma organização para implementar regimes robustos de segurança de dados. Restringir o acesso a data marts específicos que sejam relevantes para os utilizadores e eliminar, ofuscar ou anonimizar dados sensíveis.

Se estes data marts forem implementados como tabelas físicas, vão precisar de recursos e processamento extra de armazenamento para os construir e atualizar regularmente. Além disso, os dados no data mart só estarão atualizados até à última operação de atualização, podendo assim não ser adequados para dashboards que lidam com dados altamente voláteis.

Com o advento de arquiteturas MPP escaláveis e de menor custo, como o Azure Synapse, e as suas características de desempenho inerentes, pode fornecer funcionalidade de data mart sem instanciar o mart como um conjunto de tabelas físicas. Um método é virtualizar eficazmente os data marts através de vistas SQL para o armazém principal de dados. Outra forma é virtualizar os data marts através de uma camada de virtualização usando funcionalidades como vistas no Azure ou produtos de virtualização de terceiros . Esta abordagem simplifica ou elimina a necessidade de armazenamento extra e processamento de agregação e reduz o número total de objetos da base de dados a migrar.

Há outro benefício potencial desta abordagem. Ao implementar a lógica de agregação e junção dentro de uma camada de virtualização, e apresentar ferramentas externas de reporte através de uma vista virtualizada, o processamento necessário para criar estas vistas é empurrado para o data warehouse. O data warehouse é geralmente o melhor local para executar joins, agregações e outras operações relacionadas em grandes volumes de dados.

Os principais fatores para implementar um data mart virtual em vez de um data mart físico são:

• Mais agilidade: um data mart virtual é mais fácil de alterar do que tabelas físicas e os processos ETL associados.

• Menor custo total de posse: uma implementação virtualizada requer menos armazenamentos de dados e cópias dos mesmos.

• Eliminação de trabalhos ETL para migrar e simplificar a arquitetura de data warehouse num ambiente virtualizado.

• Desempenho: embora os data marts físicos tenham historicamente tido melhor desempenho, os produtos de virtualização implementam agora técnicas inteligentes de cache para mitigar esta diferença.

Migração de dados a partir da Oracle

Compreender os seus dados

Como parte do planeamento da migração, deve compreender em detalhe o volume de dados a migrar, pois isso pode influenciar as decisões sobre a abordagem de migração. Use metadados do sistema para determinar o espaço físico ocupado pelos dados brutos dentro das tabelas a migrar. Neste contexto, dados brutos referem-se à quantidade de espaço utilizada pelas linhas de dados dentro de uma tabela, excluindo sobrecarga como índices e compressão. As maiores tabelas de factos normalmente compreendem mais de 95% dos dados.

Esta consulta irá dar-lhe o tamanho total da base de dados no 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

O tamanho da base de dados é igual ao tamanho de (data files + temp files + online/offline redo log files + control files). O tamanho total da base de dados inclui espaço usado e espaço livre.

A seguinte consulta de exemplo apresenta uma divisão do espaço em disco utilizado pelos dados das tabelas e índices:

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;

Além disso, a equipa de migração de bases de dados da Microsoft disponibiliza muitos recursos, incluindo os Artefactos do Script Oracle Inventor. A ferramenta Oracle Inventory Script Artifacts inclui uma consulta PL/SQL que acede às tabelas do sistema Oracle e fornece uma contagem de objetos por tipo de esquema, tipo de objeto e estado. A ferramenta também fornece uma estimativa aproximada dos dados brutos em cada esquema e o dimensionamento das tabelas em cada esquema, com os resultados armazenados em formato CSV. Uma folha de cálculo incluída na calculadora recebe o CSV como entrada e fornece dados de dimensionamento.

Para qualquer tabela, pode estimar com precisão o volume de dados que precisa de ser migrado extraindo uma amostra representativa dos dados, como um milhão de linhas, para um ficheiro de dados plano ASCII delimitado e não comprimido. Depois, use o tamanho desse ficheiro para obter um tamanho médio de dados brutos por linha. Finalmente, multiplique esse tamanho médio pelo número total de linhas na tabela completa para obter um tamanho bruto dos dados para a tabela. Use esse tamanho de dados brutos no seu planeamento.

Use consultas SQL para encontrar tipos de dados

Ao consultar a vista do dicionário DBA_TAB_COLUMNS de dados estático da Oracle, pode determinar que tipos de dados estão em uso num esquema e se algum desses tipos precisa de ser alterado. Use consultas SQL para encontrar as colunas em qualquer esquema Oracle com tipos de dados que não correspondem diretamente aos tipos de dados no Azure Synapse. De forma semelhante, pode usar consultas para contar o número de ocorrências de cada tipo de dado Oracle que não corresponde diretamente ao Azure Synapse. Ao usar os resultados destas consultas em combinação com a tabela de comparação de tipos de dados, pode determinar quais os tipos de dados que precisam de ser alterados num ambiente Azure Synapse.

Para encontrar as colunas com tipos de dados que não correspondem aos tipos de dados no Azure Synapse, execute a seguinte consulta depois de substituir <owner_name> com o proprietário relevante do seu esquema:

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;

Para contar o número de tipos de dados não mapeáveis, use a seguinte consulta:

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;

A Microsoft oferece o SQL Server Migration Assistant (SSMA) para a Oracle para automatizar a migração de data warehouses a partir de ambientes Oracle legados, incluindo o mapeamento dos tipos de dados. Também pode usar o Azure Database Migration Services para ajudar a planear e realizar uma migração a partir de ambientes como o Oracle. Os fornecedores terceiros também oferecem ferramentas e serviços para automatizar a migração. Se já estiver em uso uma ferramenta ETL de terceiros no ambiente Oracle, pode usar essa ferramenta para implementar quaisquer transformações de dados necessárias. A secção seguinte explora a migração dos processos ETL existentes.

Considerações sobre migração ETL

Decisões iniciais sobre a migração do Oracle ETL

Para processamento ETL/ELT, os armazéns de dados Oracle legados frequentemente utilizam scripts personalizados, ferramentas ETL de terceiros ou uma combinação de abordagens que evoluiu ao longo do tempo. Quando planeia migrar para o Azure Synapse, determine a melhor forma de implementar o processamento ETL/ELT necessário no novo ambiente, minimizando ao mesmo tempo custos e riscos.

O seguinte fluxograma resume uma abordagem:

Como mostrado no fluxograma, o passo inicial é sempre construir um inventário dos processos ETL/ELT que precisam de ser migrados. Com as funcionalidades padrão incorporadas do Azure, alguns processos existentes podem não precisar de ser movidos. Para fins de planeamento, é importante que compreenda a dimensão da migração. De seguida, considere as perguntas na árvore de decisão do fluxograma:

1. Mudar para o Azure nativo? A tua resposta depende se estás a migrar para um ambiente completamente nativo do Azure. Se sim, recomendamos que reengenhar o processamento ETL usando pipelines e atividades no Azure Data Factory ou pipelines no Azure Synapse.

2. Usar uma ferramenta ETL de terceiros? Se não estiver a migrar para um ambiente totalmente nativo do Azure, verifique se já existe uma ferramenta de ETL de terceiros existente. No ambiente Oracle, pode encontrar que parte ou todo o processamento ETL é realizado por scripts personalizados usando utilitários específicos da Oracle, como Oracle SQL Developer, Oracle SQL*Loader ou Oracle Data Pump. A abordagem neste caso é reengenheirar usando o Azure Data Factory.

3. Os serviços de suporte de terceiros cobrem pools SQL dedicados no âmbito do Azure Synapse? Considere se há um grande investimento em competências na ferramenta ETL de terceiros, ou se os fluxos de trabalho e cronogramas existentes utilizam essa ferramenta. Se sim, determine se a ferramenta consegue suportar eficientemente o Azure Synapse como ambiente-alvo. Idealmente, a ferramenta incluirá conectores nativos que possam usar funcionalidades Azure como PolyBase ou COPY INTO para o carregamento de dados mais eficiente. Mas mesmo sem conectores nativos, geralmente há uma forma de chamar processos externos, como PolyBase ou COPY INTO, e passar parâmetros aplicáveis. Neste caso, utilize competências e fluxos de trabalho já existentes, tendo o Azure Synapse como novo ambiente-alvo.

   Se estiveres a usar o Oracle Data Integrator (ODI) para processamento de ELT, então precisas de módulos de conhecimento ODI para Azure Synapse. Se esses módulos não estiverem disponíveis na sua organização, mas tiver ODI, então pode usar ODI para gerar ficheiros planos. Esses ficheiros planos podem então ser movidos para o Azure e ingeridos no Azure Data Lake Storage para carregamento no Azure Synapse.

4. Executar ferramentas ETL no Azure? Se decidir manter uma ferramenta ETL de terceiros existente, pode executar essa ferramenta dentro do ambiente Azure (em vez de num servidor ETL local existente) e fazer com que o Data Factory trate da orquestração geral dos fluxos de trabalho existentes. Por isso, decida se deve deixar a ferramenta existente a correr as-is ou transferi-la para o ambiente Azure para obter benefícios de custo, desempenho e escalabilidade.

Reestruturar scripts específicos da Oracle existentes

Se parte ou todo o processamento ETL/ELT existente do armazém Oracle for tratado por scripts personalizados que usam utilitários específicos da Oracle, como Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader ou Oracle Data Pump, então precisa de recodificar estes scripts para o ambiente Azure Synapse. De forma semelhante, se os processos ETL foram implementados usando stored procedures no Oracle, então precisa de recodificar esses processos.

Alguns elementos do processo ETL são fáceis de migrar, por exemplo, através de simples carregamento em massa de dados para uma tabela de staging a partir de um ficheiro externo. Pode até ser possível automatizar essas partes do processo, por exemplo, usando Azure Synapse COPY INTO ou PolyBase em vez de SQL*Loader. Outras partes do processo que contenham SQL e/ou procedimentos armazenados complexos arbitrários vão demorar mais tempo a ser reengenheirada.

Uma forma de testar a compatibilidade do Oracle SQL com o Azure Synapse é capturar algumas instruções SQL representativas de uma junção da Oracle v$active_session_history e v$sql obter sql_text, depois prefixar essas consultas com EXPLAIN. Assumindo um modelo de dados migrado semelhante no Azure Synapse, execute essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível dará um erro. Pode usar esta informação para determinar a escala da tarefa de recodificação.

No pior dos casos, pode ser necessário regravar manualmente. No entanto, existem produtos e serviços disponíveis de parceiros da Microsoft para ajudar na reengenharia do código específico da Oracle.

Utilizar ferramentas ETL de terceiros existentes

Em muitos casos, o sistema de data warehouse legado já estará preenchido e mantido por um produto ETL de terceiros. Consulte Azure Synapse Analytics para uma lista dos parceiros atuais de integração de dados da Microsoft para Azure Synapse.

A comunidade Oracle utiliza frequentemente vários produtos ETL populares. Os parágrafos seguintes discutem as ferramentas ETL mais populares para armazéns Oracle. Podes correr todos esses produtos dentro de uma VM no Azure e usá-los para ler e escrever bases de dados e ficheiros do Azure.

Carregamento de dados a partir da Oracle

Escolhas disponíveis ao carregar dados da Oracle

Quando estiver a preparar a migração de dados de um Oracle data warehouse, decida como os dados serão fisicamente movidos do ambiente local existente para o Azure Synapse na cloud, e que ferramentas serão usadas para realizar a transferência e o carregamento. Considere as seguintes questões, que são discutidas nas secções seguintes.

• Vais extrair os dados para ficheiros ou movê-los diretamente através de uma ligação de rede?

• Vais orquestrar o processo a partir do sistema de origem ou do ambiente alvo Azure?

• Que ferramentas irá usar para automatizar e gerir o processo de migração?

Transferir dados através de ficheiros ou ligação à rede?

Depois de criadas as tabelas da base de dados a migrar no Azure Synapse, pode transferir os dados que preenchem essas tabelas do sistema Oracle antigo para o novo ambiente. Existem duas abordagens básicas:

• Extração de Ficheiro: extrair os dados das tabelas Oracle para ficheiros planos e delimitados, normalmente em formato CSV. Pode extrair dados de tabela de várias formas:

  • Use ferramentas padrão da Oracle como SQL*Plus, SQL Developer e SQLcl.
  • Utilize Oracle Data Integrator (ODI) para gerar ficheiros planos.
  • Use o conector Oracle na Data Factory para descarregar tabelas Oracle em paralelo e permitir o carregamento de dados por partições.
  • Usa uma ferramenta de ETL de terceiros .

  Para exemplos de como extrair dados de tabelas Oracle, consulte o artigo apêndice.

  Esta abordagem requer espaço para aterrar os ficheiros de dados extraídos. O espaço pode ser local para a base de dados de origem da Oracle se houver armazenamento suficiente disponível, ou remoto no Azure Blob Storage. O melhor desempenho é alcançado quando um ficheiro é escrito localmente, pois isso evita sobrecarga de rede.

  Para minimizar os requisitos de armazenamento e transferência de rede, comprima os ficheiros de dados extraídos usando uma ferramenta como o gzip.

  Após a extração, move os ficheiros planos para o Azure Blob Storage. A Microsoft oferece várias opções para mover grandes volumes de dados, incluindo:

  • AzCopy para mover ficheiros através da rede para o Azure Storage.
  • Azure ExpressRoute para mover dados em massa através de uma ligação de rede privada.
  • Azure Data Box para transferir ficheiros para um dispositivo de armazenamento físico que envia para um centro de dados Azure para carregamento.

  Para mais informações, consulte Transferir dados para e a partir do Azure.

• Extração direta e carregamento através da rede: o ambiente Azure alvo envia um pedido de extração de dados, normalmente via comando SQL, para o sistema Oracle legado para extrair os dados. Os resultados são enviados pela rede e carregados diretamente no Azure Synapse, sem necessidade de transferir os dados para ficheiros intermédios. O fator limitante neste cenário é normalmente a largura de banda da ligação de rede entre a base de dados Oracle e o ambiente Azure. Para volumes de dados excecionalmente grandes, esta abordagem pode não ser prática.

Existe também uma abordagem híbrida que usa ambos os métodos. Por exemplo, pode usar a abordagem de extração direta de rede para tabelas de dimensões menores e amostras das tabelas de factos maiores para fornecer rapidamente um ambiente de teste no Azure Synapse. Para tabelas de factos históricos de grande volume, pode usar a abordagem de extração e transferência de ficheiros usando o Azure Data Box.

Orquestrar a partir da Oracle ou do Azure?

A abordagem recomendada ao migrar para o Azure Synapse é orquestrar a extração e carregamento de dados a partir do ambiente Azure usando SSMA ou Data Factory. Use as utilidades associadas, como PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Esta abordagem beneficia das capacidades integradas do Azure e reduz o esforço para construir pipelines de carga de dados reutilizáveis. Pode utilizar pipelines de carregamento de dados orientados por metadados para automatizar o processo de migração.

A abordagem recomendada também minimiza a perda de desempenho no ambiente Oracle existente durante o processo de carregamento dos dados, porque o processo de gestão e carregamento corre no Azure.

Ferramentas existentes de migração de dados

A transformação e o movimento de dados são a função básica de todos os produtos ETL. Se uma ferramenta de migração de dados já estiver em uso no ambiente Oracle existente e suportar o Azure Synapse como ambiente alvo, considere usar essa ferramenta para simplificar a migração de dados.

Mesmo que não exista uma ferramenta ETL existente, os parceiros de integração de dados da Azure Synapse Analytics oferecem ferramentas ETL para simplificar a tarefa de migração de dados.

Por fim, se planeia usar uma ferramenta ETL, considere executá-la no ambiente Azure para tirar partido do desempenho, escalabilidade e custo na cloud Azure. Esta abordagem também liberta recursos no centro de dados Oracle.

Resumo

Para resumir, as nossas recomendações para migrar dados e processos ETL associados da Oracle para o Azure Synapse são:

• Planeie com antecedência para garantir um exercício de migração bem-sucedido.

• Construa um inventário detalhado de dados e processos a migrar o mais rapidamente possível.

• Use metadados do sistema e ficheiros de registo para obter uma compreensão precisa dos dados e do uso dos processos. Não confie na documentação, pois pode estar desatualizada.

• Compreenda os volumes de dados a migrar e a largura de banda da rede entre o centro de dados local e os ambientes cloud Azure.

• Considere usar uma instância Oracle numa VM Azure como trampolim para descarregar a migração do ambiente Oracle legado.

• Use funcionalidades padrão incorporadas no Azure para minimizar a carga de trabalho da migração.

• Identificar e compreender as ferramentas mais eficientes para extração e carregamento de dados tanto em ambientes Oracle como Azure. Use as ferramentas adequadas em cada fase do processo.

• Utilize funcionalidades Azure, como o Data Factory, para orquestrar e automatizar o processo de migração, minimizando o impacto no sistema Oracle.

Apêndice: Exemplos de técnicas para extrair dados da Oracle

Pode usar várias técnicas para extrair dados da Oracle ao migrar do Oracle para o Azure Synapse. As secções seguintes demonstram como extrair dados Oracle usando o Oracle SQL Developer e o conector Oracle no Data Factory.

Use o Oracle SQL Developer para extração de dados

Pode usar a interface Oracle SQL Developer para exportar dados de tabelas para vários formatos, incluindo CSV, como mostrado na seguinte captura de ecrã:

Outras opções de exportação incluem JSON e XML. Podes usar a interface para adicionar um conjunto de nomes de tabelas a um "carrinho" e depois aplicar a exportação a todo o conjunto no carrinho:

Também pode usar o Oracle SQL Developer Command Line (SQLcl) para exportar dados da Oracle. Esta opção suporta automação usando um script shell.

Para tabelas relativamente pequenas, pode achar esta técnica útil se tiver dificuldades em extrair dados através de uma ligação direta.

Use o conector do Oracle no Azure Data Factory para cópia em paralelo

Podes usar o conector Oracle no Data Factory para descarregar grandes tabelas Oracle em paralelo. O conector Oracle fornece particionamento de dados integrado para copiar dados do Oracle em paralelo. Podes encontrar as opções de particionamento de dados no separador Source da atividade de cópia.

Para informações sobre como configurar o conector Oracle para cópia paralela, veja Cópia paralela do Oracle.

Para mais informações sobre o desempenho e escalabilidade da atividade de cópia da Data Factory, consulte o guia de desempenho e escalabilidade da atividade de cópia.

Passos seguintes

Para saber mais sobre operações de acesso de segurança, consulte o próximo artigo desta série: Segurança, acesso e operações para migrações da Oracle.