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

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

Considerações sobre migração de dados

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

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

Ao planejar uma migração de um ambiente Oracle existente, considere as seguintes perguntas relacionadas a dados:

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

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

• Ao migrar data marts: mantenha-se físico ou virtual?

As próximas seções discutem esses pontos no contexto de uma migração do Oracle.

Migrar tabelas não utilizadas?

Faz sentido migrar apenas tabelas que estão em uso. As 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 arquivos de log em vez de documentação para determinar quais tabelas estão em uso, porque a documentação pode estar desatualizada.

As tabelas e logs do catálogo do sistema Oracle contêm informações que podem ser usadas para determinar quando uma determinada tabela foi acessada pela última vez — que, por sua vez, podem ser usadas para decidir se uma tabela é ou não candidata à migração.

Se você licenciou o Oracle Diagnostic Pack, tem acesso ao Histórico de Sessão Ativo, que pode ser usado para determinar quando uma tabela foi acessada pela última vez.

Aqui está um exemplo de consulta que procura o uso de uma tabela específica dentro de uma determinada janela de tempo:

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;

Essa consulta pode demorar um pouco para ser executada se você estiver executando várias consultas.

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

Essa pergunta surge com frequência porque as empresas podem querer diminuir o impacto das mudanças no modelo de dados do data warehouse para melhorar a agilidade. As empresas geralmente veem uma oportunidade de modernizar ou transformar ainda mais seus dados durante uma migração de ETL. Esta abordagem acarreta um risco mais elevado porque altera múltiplos fatores em simultâneo, dificultando a comparação dos resultados do sistema antigo com o novo. Fazer alterações no modelo de dados aqui também pode afetar trabalhos de ETL upstream ou downstream para outros sistemas. Devido a esse risco, é melhor redesenhar nessa escala após a migração do data warehouse.

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

Migração de data mart: mantenha-se físico ou virtual?

Em ambientes de data warehouse Oracle legados, é prática comum criar muitos data marts estruturados para fornecer um bom desempenho para consultas e relatórios de autoatendimento ad hoc para um determinado departamento ou função de negócios dentro de uma organização. Um data mart normalmente consiste em um subconjunto do data warehouse que contém versões agregadas dos dados em um formulário que permite aos usuários consultar facilmente esses dados com tempos de resposta rápidos. Os usuários podem usar ferramentas de consulta fáceis de usar, como o Microsoft Power BI, que oferece suporte a interações de usuários corporativos com data marts. A forma dos dados em um data mart é geralmente um modelo de dados dimensionais. Um uso dos data marts é expor os dados em um formato utilizável, mesmo que o modelo de dados de armazém subjacente seja algo diferente, como um cofre de dados.

Você pode usar data marts separados para unidades de negócios individuais dentro de uma organização para implementar regimes robustos de segurança de dados. Restrinja o acesso a data marts específicos que sejam relevantes para os usuários e elimine, ofusque ou anonimize dados confidenciais.

Se esses data marts forem implementados como tabelas físicas, eles exigirão recursos de armazenamento e processamento adicionais para criá-los e atualizá-los regularmente. Além disso, os dados no mercado estarão tão atualizados quanto a última operação de atualização e, portanto, podem ser inadequados para painéis de dados altamente voláteis.

Com o advento de arquiteturas MPP escaláveis de baixo custo, como o Azure Synapse, e suas características de desempenho inerentes, você pode fornecer funcionalidade de data mart sem instanciar o mart como um conjunto de tabelas físicas. Um método é virtualizar efetivamente os data marts por meio de visualizações SQL no data warehouse principal. Outra maneira é virtualizar os data marts por meio de uma camada de virtualização usando recursos como exibições no Azure ou produtos de virtualização de terceiros . Essa abordagem simplifica ou elimina a necessidade de armazenamento extra e processamento de agregação e reduz o número total de objetos de banco de dados a serem migrados.

Há outro benefício potencial dessa abordagem. Ao implementar a lógica de agregação e junção dentro de uma camada de virtualização e apresentar ferramentas de relatório externas por meio de uma exibição virtualizada, o processamento necessário para criar essas exibições é empurrado para o data warehouse. O data warehouse é geralmente o melhor lugar para executar junções, agregações e outras operações relacionadas em grandes volumes de dados.

Os principais drivers para implementar um data mart virtual sobre um data mart físico são:

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

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

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

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

Migração de dados do Oracle

Compreender os seus dados

Como parte do planejamento da migração, você deve entender em detalhes o volume de dados a ser migrado, pois isso pode afetar 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 serem migradas. Nesse contexto, dados brutos significam a quantidade de espaço usada pelas linhas de dados dentro de uma tabela, excluindo despesas gerais, como índices e compactação. As maiores tabelas de fatos normalmente compreendem mais de 95% dos dados.

Esta consulta fornecerá o tamanho total do banco 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 do banco de dados é igual ao tamanho de (data files + temp files + online/offline redo log files + control files). O tamanho geral do banco de dados inclui espaço usado e espaço livre.

A consulta de exemplo a seguir fornece um detalhamento do espaço em disco usado pelos dados e índices da tabela:

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 equipe de migração de banco de dados da Microsoft fornece muitos recursos, incluindo os Artefatos de Script de Inventário Oracle. A ferramenta Oracle Inventory Script Artifacts inclui uma consulta PL/SQL que acessa tabelas do sistema Oracle e fornece uma contagem de objetos por tipo de esquema, tipo de objeto e status. A ferramenta também fornece uma estimativa aproximada de dados brutos em cada esquema e o dimensionamento de tabelas em cada esquema, com resultados armazenados em um formato CSV. Uma planilha de calculadora incluída usa o CSV como entrada e fornece dados de dimensionamento.

Para qualquer tabela, você pode estimar com precisão o volume de dados que precisa ser migrado extraindo uma amostra representativa dos dados, como um milhão de linhas, para um arquivo de dados ASCII simples delimitado não compactado. Em seguida, use o tamanho desse arquivo para obter um tamanho médio de dados brutos por linha. Por fim, multiplique esse tamanho médio pelo número total de linhas na tabela completa para fornecer um tamanho de dados brutos para a tabela. Use esse tamanho de dados brutos em seu planejamento.

Usar consultas SQL para localizar tipos de dados

Ao consultar a visualização do dicionário DBA_TAB_COLUMNS de dados estáticos Oracle, você pode determinar quais tipos de dados estão em uso em um esquema e se algum desses tipos de dados precisa ser alterado. Use consultas SQL para localizar as colunas em qualquer esquema Oracle com tipos de dados que não são mapeados diretamente para tipos de dados no Azure Synapse. Da mesma forma, você pode usar consultas para contar o número de ocorrências de cada tipo de dados Oracle que não são mapeados diretamente para o Azure Synapse. Usando os resultados dessas consultas em combinação com a tabela de comparação de tipos de dados, você pode determinar quais tipos de dados precisam ser alterados em um ambiente do Azure Synapse.

Para localizar as colunas com tipos de dados que não são mapeados para tipos de dados no Azure Synapse, execute a seguinte consulta depois de substituir <owner_name> pelo 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 Oracle para automatizar a migração de data warehouses de ambientes Oracle herdados, incluindo o mapeamento de tipos de dados. Você também pode usar os Serviços de Migração de Banco de Dados do Azure para ajudar a planejar e executar uma migração de ambientes como o Oracle. Fornecedores terceirizados também oferecem ferramentas e serviços para automatizar a migração. Se uma ferramenta ETL de terceiros já estiver em uso no ambiente Oracle, você poderá usar essa ferramenta para implementar quaisquer transformações de dados necessárias. A próxima seção explora a migração de processos ETL existentes.

Considerações sobre migração de ETL

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

Para o processamento de ETL/ELT, os data warehouses Oracle herdados geralmente usam scripts personalizados, ferramentas ETL de terceiros ou uma combinação de abordagens que evoluiu ao longo do tempo. Ao planejar uma migração para o Azure Synapse, determine a melhor maneira de implementar o processamento ETL/ELT necessário no novo ambiente e, ao mesmo tempo, minimizar custos e riscos.

O fluxograma a seguir resume uma abordagem:

Como mostrado no fluxograma, a etapa inicial é sempre construir um inventário dos processos ETL/ELT que precisam ser migrados. Com os recursos internos padrão do Azure, alguns processos existentes podem não precisar ser movidos. Para fins de planejamento, é importante que você entenda a escala da migração. Em seguida, considere as perguntas na árvore de decisão do fluxograma:

1. Mudar para o Azure nativo? Sua resposta depende se você está migrando para um ambiente completamente nativo do Azure. Em caso afirmativo, recomendamos que você faça uma nova engenharia do processamento de ETL usando Pipelines e atividades no Azure Data Factory ou nos pipelines do Azure Synapse.

2. Usando uma ferramenta ETL de terceiros? Se você não estiver mudando para um ambiente completamente nativo do Azure, verifique se uma ferramenta ETL de terceiros existente já está em uso. No ambiente Oracle, você pode achar que parte ou todo o processamento de ETL é executado 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, é reformular usando o Azure Data Factory.

3. O terceiro oferece suporte a pools SQL dedicados no Azure Synapse? Considere se há um grande investimento em habilidades na ferramenta ETL de terceiros ou se os fluxos de trabalho e agendas existentes usam essa ferramenta. Em caso afirmativo, determine se a ferramenta pode dar suporte eficiente ao Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores nativos que podem usar recursos do Azure como PolyBase ou COPY INTO para o carregamento de dados mais eficiente. Mas mesmo sem conectores nativos, geralmente há uma maneira de chamar processos externos, como PolyBase ou COPY INTO, e passar os parâmetros aplicáveis. Nesse caso, use habilidades e fluxos de trabalho existentes, com o Azure Synapse como o novo ambiente de destino.

   Se você estiver usando o Oracle Data Integrator (ODI) para processamento ELT, precisará dos Módulos de Conhecimento ODI para o Azure Synapse. Se esses módulos não estiverem disponíveis para você em sua organização, mas você tiver ODI, poderá usar ODI para gerar arquivos simples. Esses arquivos simples podem ser movidos para o Azure e ingeridos no Armazenamento do Azure Data Lake para carregamento no Azure Synapse.

4. Executar ferramentas ETL no Azure? Se você decidir manter uma ferramenta ETL de terceiros existente, poderá executar essa ferramenta no ambiente do Azure (em vez de em um servidor ETL local existente) e fazer com que o Data Factory trate da orquestração geral dos fluxos de trabalho existentes. Portanto, decida se deseja deixar a ferramenta existente em execução como está ou movê-la para o ambiente do Azure para obter benefícios de custo, desempenho e escalabilidade.

Reengenharia de scripts específicos da Oracle existentes

Se parte ou todo o processamento ETL/ELT do armazém Oracle existente for manipulado 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, você precisará recodificar esses scripts para o ambiente do Azure Synapse. Da mesma forma, se os processos ETL foram implementados usando procedimentos armazenados no Oracle, você precisará recodificar esses processos.

Alguns elementos do processo ETL são fáceis de migrar, por exemplo, por meio de uma simples carga de dados em massa para uma tabela de preparo a partir de um arquivo externo. Pode até ser possível automatizar essas partes do processo, por exemplo, usando o Azure Synapse COPY INTO ou PolyBase em vez de SQL*Loader. Outras partes do processo que contêm SQL complexo arbitrário e/ou procedimentos armazenados levarão mais tempo para serem reformuladas.

Uma maneira de testar a compatibilidade do Oracle SQL com o Azure Synapse é capturar algumas instruções SQL representativas de uma associação do Oracle v$active_session_history e v$sql obter sql_texte, em seguida, prefixar essas consultas com EXPLAIN. Supondo um modelo de dados migrado semelhante no Azure Synapse, execute essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível dará um erro. Você pode usar essas informações para determinar a escala da tarefa de recodificação.

Na pior das hipóteses, pode ser necessária uma recodificação manual. No entanto, existem produtos e serviços disponíveis de parceiros da Microsoft para ajudar na reengenharia de código específico da Oracle.

Usar ferramentas de ETL de terceiros existentes

Em muitos casos, o sistema de armazém de dados herdado existente já será preenchido e mantido por um produto ETL de terceiros. Consulte Parceiros de integração de dados do Azure Synapse Analytics para obter uma lista dos atuais parceiros de integração de dados da Microsoft para o Azure Synapse.

A comunidade Oracle usa frequentemente vários produtos ETL populares. Os parágrafos a seguir discutem as ferramentas de ETL mais populares para armazéns Oracle. Você pode executar todos esses produtos em uma VM no Azure e usá-los para ler e gravar bancos de dados e arquivos do Azure.

Carregamento de dados a partir do Oracle

Opções disponíveis ao carregar dados do Oracle

Quando estiver se preparando para migrar dados de um data warehouse Oracle, decida como os dados serão movidos fisicamente do ambiente local existente para o Azure Synapse na nuvem e quais ferramentas serão usadas para executar a transferência e o carregamento. Considere as seguintes questões, que são discutidas nas seções a seguir.

• Você vai extrair os dados para arquivos, ou movê-los diretamente através de uma conexão de rede?

• Você orquestrará o processo a partir do sistema de origem ou do ambiente de destino do Azure?

• Quais ferramentas você usará para automatizar e gerenciar o processo de migração?

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

Depois que as tabelas de banco de dados a serem migradas tiverem sido criadas no Azure Synapse, você poderá mover os dados que preenchem essas tabelas do sistema Oracle herdado para o novo ambiente. Existem duas abordagens básicas:

• Extração de arquivo: extraia os dados das tabelas Oracle para arquivos delimitados simples, normalmente em formato CSV. Você pode extrair dados da tabela de várias maneiras:

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

  Para obter exemplos de como extrair dados de tabela Oracle, consulte o apêndice do artigo.

  Essa abordagem requer espaço para pousar os arquivos de dados extraídos. O espaço pode ser local para o banco de dados de origem Oracle se houver armazenamento suficiente disponível ou remoto no Armazenamento de Blob do Azure. O melhor desempenho é alcançado quando um arquivo é gravado localmente, pois isso evita a sobrecarga da rede.

  Para minimizar os requisitos de armazenamento e transferência de rede, compacte os arquivos de dados extraídos usando um utilitário como o gzip.

  Após a extração, mova os arquivos simples para o Armazenamento de Blobs do Azure. A Microsoft fornece várias opções para mover grandes volumes de dados, incluindo:

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

  Para obter mais informações, consulte Transferir dados de e para o Azure.

• Extrair e carregar diretamente através da rede: o ambiente do Azure de destino envia uma solicitação de extração de dados, normalmente por meio de um comando SQL, para o sistema Oracle herdado para extrair os dados. Os resultados são enviados pela rede e carregados diretamente no Azure Synapse, sem a necessidade de colocar os dados em arquivos intermediários. O fator limitante neste cenário é normalmente a largura de banda da conexão de rede entre o banco de dados Oracle e o ambiente do Azure. Para volumes de dados excepcionalmente grandes, essa abordagem pode não ser prática.

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

Orquestrar a partir do Oracle ou do Azure?

A abordagem recomendada ao mudar para o Azure Synapse é orquestrar a extração e o carregamento de dados do ambiente do Azure usando SSMA ou Data Factory. Use os utilitários associados, como PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Essa abordagem se beneficia dos recursos internos do Azure e reduz o esforço para criar pipelines de carga de dados reutilizáveis. Você pode usar pipelines de carga de dados orientados por metadados para automatizar o processo de migração.

A abordagem recomendada também minimiza o impacto no desempenho no ambiente Oracle existente durante o processo de carregamento de dados, porque o processo de gerenciamento e carga é executado no Azure.

Ferramentas de migração de dados existentes

A transformação e movimentação de dados é 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 oferecer suporte ao Azure Synapse como um ambiente de destino, considere usar essa ferramenta para simplificar a migração de dados.

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

Por fim, se você planeja usar uma ferramenta ETL, considere executar essa ferramenta no ambiente do Azure para aproveitar o desempenho, a escalabilidade e o custo da nuvem do Azure. Essa abordagem também libera recursos no data center da Oracle.

Resumo

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

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

• Crie um inventário detalhado de dados e processos a serem migrados o mais rápido possível.

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

• Entenda os volumes de dados a serem migrados e a largura de banda de rede entre o data center local e os ambientes de nuvem do Azure.

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

• Use recursos internos padrão do Azure para minimizar a carga de trabalho de migração.

• Identifique e compreenda as ferramentas mais eficientes para extração e carregamento de dados em ambientes Oracle e Azure. Utilize as ferramentas adequadas em cada fase do processo.

• Use os recursos do Azure, como o Data Factory, para orquestrar e automatizar o processo de migração e, ao mesmo tempo, minimizar o impacto no sistema Oracle.

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

Você pode usar várias técnicas para extrair dados Oracle ao migrar do Oracle para o Azure Synapse. As próximas seções demonstram como extrair dados Oracle usando o Oracle SQL Developer e o conector Oracle no Data Factory.

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

Você pode usar a interface do usuário do Oracle SQL Developer para exportar dados de tabela para vários formatos, incluindo CSV, conforme mostrado na captura de tela a seguir:

Outras opções de exportação incluem JSON e XML. Você pode usar a interface do usuário para adicionar um conjunto de nomes de tabela a um "carrinho" e, em seguida, aplicar a exportação a todo o conjunto no carrinho:

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

Para tabelas relativamente pequenas, você pode achar essa técnica útil se tiver problemas para extrair dados por meio de uma conexão direta.

Usar o conector Oracle no Azure Data Factory para cópia paralela

Você pode 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. Você pode encontrar as opções de particionamento de dados na guia Origem da atividade de cópia.

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

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

Próximos passos

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 Oracle.