Migração de dados, ETL e carregamento para migração do Oracle
Este artigo é a segunda parte de uma série de sete partes que oferece diretrizes para fazer a migração 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
Há muitos fatores a serem considerados ao migrar dados, ETL e cargas de um data warehouse e data marts Oracle herdados para o Azure Synapse.
Decisões iniciais sobre a migração de dados do 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?
Quando migrar data marts — continuar no físico ou usar o virtual?
As próximas seções discutem esses pontos dentro do contexto de uma migração do Oracle.
Migrar tabelas não utilizadas?
Faz sentido migrar apenas as tabelas que estão em uso. As tabelas que não estão ativas podem ser arquivadas em vez de migradas, de modo que os dados fiquem disponíveis, caso sejam necessários no futuro. É melhor usar os metadados do sistema e os arquivos de log em vez da documentação para determinar quais tabelas estão em uso, pois a documentação pode estar desatualizada.
As tabelas e logs de catálogo do sistema Oracle conterão informações que podem ser usados para determinar quando uma certa tabela foi acessada pela última vez, o que, por sua vez, pode ser usado para decidir se uma tabela é candidata à migração.
Se você licenciou o Oracle Diagnostic Pack, terá acesso ao Histórico de Sessão Ativa, que poderá usar para determinar quando uma tabela foi acessada pela última vez.
Dica
Em sistemas herdados, não é incomum que as tabelas se tornem redundantes com o tempo.Na maioria dos casos, não é necessário migrá-las.
Confira 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 poderá 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 sobre os usuários?
Esta questão surge com frequência porque as empresas podem querer diminuir o impacto das mudanças no modelo de dados de data warehouse para melhorar a agilidade. As empresas frequentemente veem uma oportunidade de modernizar ou transformar ainda mais seus dados durante uma migração ETL. Esta abordagem carrega um risco maior porque muda múltiplos fatores simultaneamente, tornando difícil comparar os resultados do sistema antigo com o novo. Fazer alterações no modelo de dados aqui também pode afetar os trabalhos de ETL upstream ou downstream para outros sistemas. Devido a esse risco, é melhor redesenhar nesta escala após a migração do data warehouse.
Mesmo que um modelo de dados seja alterado intencionalmente como parte da migração geral, é uma boa prática migrar o modelo existente como está para a Azure Synapse, em vez de fazer qualquer reengenharia na nova plataforma. Esta abordagem minimiza o efeito nos sistemas de produção existentes, enquanto se beneficia do desempenho e da escalabilidade elástica da plataforma Azure para tarefas pontuais de reengenharia.
Dica
Inicialmente, migre o modelo existente como está, mesmo que haja um plano de alteração do modelo de dados no futuro.
Migração de data mart: optar pelo físico ou pelo virtual?
Em ambientes herdados do data warehouse do Oracle, é prática comum criar vários 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 em uma organização. Um data mart normalmente é composto por um subconjunto do data warehouse que contém versões agregadas dos dados em um formulário que permite que os usuários consultem facilmente esses dados, com tempos de resposta rápidos. Os usuários podem usar ferramentas de consulta amigáveis, como o Microsoft Power BI, que dá suporte a interações de usuários de negócios com data marts. O formato dos dados em um data mart geralmente é um modelo de dados dimensional. Uma das utilizações dos data marts é expor os dados em um formato utilizável, mesmo que o modelo de dados do warehouse subjacente seja um pouco 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 de segurança de dados robustos. Limite o acesso a data marts específicos relevantes para os usuários e elimine, ofusque ou anonimize dados confidenciais.
Se esses data marts forem implementados como tabelas físicas, exigirão recursos de armazenamento e processamento extra para compilá-los e atualizá-los regularmente. Além disso, o nível de atualização dos dados no mart corresponderá à última operação de atualização e, portanto, podem ser inadequados para painéis de dados altamente voláteis.
Dica
A virtualização de data marts pode economizar recursos de armazenamento e de processamento.
Com o advento de arquiteturas MPP escalonáveis de custo mais baixo, como o Azure Synapse, e com 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 exibiçõ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 processamento extra de armazenamento e agregação e reduz o número geral de objetos de banco de dados a serem migrados.
Há outro benefício potencial dessa abordagem. Ao implementar a agregação e a lógica de junção em uma camada de virtualização e exibir relatórios externos em uma exibição virtualizada, é efetuado push do processamento necessário para criar essas exibições no 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 motivadores 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 mudar do que 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 data marts físicos tenham melhor desempenho historicamente, os produtos de virtualização agora implementam técnicas de cache inteligentes para mitigar essa diferença.
Dica
O desempenho e a escalabilidade do Azure Synapse permitem a virtualização sem sacrificar o desempenho.
Migração de dados do Oracle
Entender seus dados
Como parte do planejamento de migração, você deve entender detalhadamente 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 representam a quantidade de espaço usado pelas linhas de dados dentro de uma tabela, excluindo sobrecargas como índices e compactação. As maiores tabelas de dados normalmente abrangem mais de 95% dos dados.
Essa consulta informará 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 o espaço usado e o espaço livre.
A seguinte consulta de exemplo fornece um detalhamento do espaço em disco usado por índices e dados de 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 o Oracle Inventory Script Artifacts. 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 dos dados brutos e o dimensionamento de tabelas em cada esquema, com resultados armazenados em formato CSV. Uma planilha de calculadora incluída usa o CSV como entrada e fornece dados de dimensionamento.
Para qualquer tabela, você pode estimar precisamente o volume de dados que precisa ser migrado extraindo uma amostra representativa dos dados, por exemplo, 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 dar um tamanho dados brutos para a tabela. Use esse tamanho de dados brutos em seu planejamento.
Usar consultas SQL para localizar tipos de dados
Consultando a exibição DBA_TAB_COLUMNS do dicionário de dados estáticos Oracle, você pode determinar quais tipos de dados estão em uso em um esquema e se qualquer um deles 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 os 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 é mapeado diretamente para o Azure Synapse. Usando os resultados dessas consultas em conjunto 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 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 SSMA (Assistente de Migração do SQL Server) 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 transformações de dados necessárias. A próxima seção explora a migração de processos de ETL existentes.
Considerações sobre a migração de ETL
Decisões iniciais sobre a migração de ETL do Oracle
Para o processamento de ETL/ELT, os data warehouses Oracle herdados geralmente usam scripts personalizados, ferramentas de ETL de terceiros ou uma combinação de abordagens que evoluíram ao longo do tempo. Ao planejar uma migração para o Azure Synapse, determine a melhor maneira de implementar o processamento de ETL/ELT necessário no novo ambiente enquanto também minimiza o custo e o risco.
Dica
Planeje a abordagem para a migração de ETL com antecedência e aproveite as instalações do Azure quando apropriado.
O seguinte fluxograma resume uma abordagem:
Conforme mostrado no fluxograma, a etapa inicial sempre é criar um inventário de processos de ETL/ELT que precisam ser migrados. Com os recursos internos padrão do Azure, alguns processos existentes talvez não precisem ser movidos. Para fins de planejamento, é importante entender a escala da migração. Em seguida, considere as perguntas na árvore de decisão do fluxograma:
Mover para o Azure nativo? Sua resposta depende de você estar migrando para um ambiente completamente nativo do Azure. Se for esse o caso, recomendamos que você reprojete o processamento de ETL usando Pipelines e atividades no Azure Data Factory ou em Pipelines do Azure Synapse.
Está usando uma ferramenta de ETL de terceiros? Se você não estiver migrando para um ambiente completamente nativo do Azure, verifique se uma ferramenta de ETL de terceiros já está em uso. No ambiente Oracle, você pode descobrir que parte do processamento de ETL, ou todo ele, é executado por scripts personalizados usando utilitários específicos do Oracle, como o Oracle SQL Developer, o Oracle SQL*Loader ou o Oracle Data Pump. A abordagem nesse caso é reprojetar usando o Azure Data Factory.
O terceiro dá suporte a pools de SQL dedicados no Azure Synapse? Considere se há um grande investimento em habilidades na ferramenta de ETL de terceiros ou se fluxos de trabalho e agendamentos existentes usam essa ferramenta. Nesse caso, determine se a ferramenta pode dar suporte eficiente ao Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores nativos que podem aproveitar recursos como o 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 o PolyBase ou
COPY INTO, e passar parâmetros aplicáveis. Nesse caso, use as habilidades e os fluxos de trabalho existentes, com o Azure Synapse como o novo ambiente de destino.Se você estiver usando o ODI (Oracle Data Integrator) para processamento de ELT, precisará dos módulos de conhecimento do ODI para o Azure Synapse. Se esses módulos não estiverem disponíveis para você em sua organização, mas você tiver o ODI, poderá usar o ODI para gerar arquivos simples. Esses arquivos simples poderão ser movidos para o Azure e ingeridos no Azure Data Lake Storage para carregamento no Azure Synapse.
Executar ferramentas de ETL no Azure? Se você decidir manter uma ferramenta de ETL de terceiros existente, poderá executar essa ferramenta dentro do ambiente do Azure (em vez de em um servidor ETL local existente) e fazer o Data Factory lidar com a orquestração geral dos fluxos de trabalho existentes. Portanto, decida se você vai deixar a ferramenta existente em execução como está ou se vai movê-la para o ambiente do Azure, a fim de obter benefícios de custo, desempenho e escalabilidade.
Dica
Considere a execução de ferramentas de ETL no Azure para aproveitar o desempenho, a escalabilidade e os benefícios de custo.
Reprojetar scripts específicos do Oracle existentes
Se alguns ou todos os processamentos de ETL/ELT existentes do warehouse Oracle forem tratados por scripts personalizados que usam utilitários específicos da Oracle, como o Oracle SQL*Plus, o Oracle SQL Developer, o Oracle SQL*Loader ou o Oracle Data Pump, você precisará recodificar esses scripts para o ambiente do Azure Synapse. De maneira semelhante, se os processos de ETL tiverem sido implementados usando procedimentos armazenados no Oracle, você precisará recodificar esses processos.
Alguns elementos do processo de ETL são fáceis de migrar, por exemplo, por carregamento simples de dados em massa em uma tabela de preparo de um arquivo externo. Pode até ser possível automatizar essas partes do processo, por exemplo, usando o Azure Synapse COPY INTO ou o PolyBase em vez do SQL*Loader. Outras partes do processo que contêm SQL arbitrário complexo e/ou procedimentos armazenados levarão mais tempo para serem reprojetados.
Dica
O inventário de tarefas de ETL a serem migradas deve incluir scripts e procedimentos armazenados.
Uma maneira de testar o SQL do Oracle quanto à compatibilidade com o Azure Synapse é capturar algumas instruções SQL representativas de uma junção do v$active_session_history e do v$sql do Oracle para obter sql_text e prefixar essas consultas com EXPLAIN. Supondo um modelo de dados migrado similar no Azure Synapse, execute essas instruções EXPLAIN no Azure Synapse. Qualquer SQL incompatível retornará um erro. Você pode usar essas informações para determinar a escala da tarefa de recodificação.
Dica
Use EXPLAIN para encontrar incompatibilidades de SQL.
Na pior das hipóteses, a recodificação manual poderá ser necessária. No entanto, há produtos e serviços disponíveis de parceiros da Microsoft para auxiliar no processo de reprojetar código específico da Oracle.
Dica
Os parceiros oferecem produtos e habilidades para auxiliar no processo de reprojetar código específico da Oracle.
Usar ferramentas de ETL de terceiros existentes
Em muitos casos, o sistema de data warehouse herdado existente já terá sido preenchido e mantido por produtos de ETL de terceiros. Consulte Parceiros de integração de dados do Azure Synapse para obter uma lista dos parceiros atuais de integração de dados da Microsoft para o Azure Synapse.
A comunidade da Oracle frequentemente usa vários produtos de ETL populares. Os parágrafos a seguir abordam as ferramentas de ETL mais populares para warehouses Oracle. Você pode executar todos esses produtos em uma VM no Azure e usá-los para ler e gravar arquivos e bancos de dados do Azure.
Dica
Aproveite o investimento em ferramentas de terceiros existentes para reduzir o custo e o risco.
Carregamento de dados do Oracle
Opções disponíveis ao carregar dados do Oracle
Ao se preparar para migrar dados de um data warehouse Oracle, decida como eles 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 perguntas a seguir, que serão discutidas nas seções a seguir.
Você extrairá os dados para arquivos ou os moverá diretamente por meio de uma conexão de rede?
Você orquestrará o processo 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 por meio de arquivos ou conexão de rede?
Após a criação das tabelas de banco de dados a serem migradas no Azure Synapse, você poderá mover os dados que preenchem essas tabelas do sistema herdado do Oracle e carregá-los no novo ambiente. Há duas abordagens básicas:
Extração de arquivos: extraia os dados das tabelas Oracle para arquivos simples delimitados, normalmente no formato CSV. Você pode extrair dados de tabela de várias maneiras:
- Use ferramentas padrão do Oracle, como SQL*Plus, SQL Developer e SQLcl.
- Use o ODI (Oracle Data Integrator) para gerar arquivos simples.
- Use o conector do Oracle no Data Factory para descarregar tabelas Oracle em paralelo para habilitar o carregamento de dados por partições.
- Use uma ferramenta de ETL de terceiros.
Para obter exemplos de como extrair dados da tabela Oracle, consulte o apêndice do artigo.
Essa abordagem exige espaço para guardar os arquivos de dados extraídos. O espaço pode ser local para o banco de dados de origem do Oracle se houver armazenamento suficiente disponível ou remoto no Armazenamento de Blobs do Azure. O melhor desempenho é obtido quando um arquivo é gravado localmente, pois isso evita a sobrecarga de rede.
Para minimizar os requisitos de armazenamento e transferência de rede, compacte os arquivos de dados extraídos usando um utilitário como 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 usando uma conexão de rede privada.
- Azure Data Box para mover arquivos para um dispositivo de armazenamento físico que você envia para um data center do Azure para carregamento.
Para mais informações, confira Transferir dados de/para o Azure.
Extração e carregamento diretos pela rede: o ambiente de destino do Azure envia uma solicitação de extração de dados, normalmente por meio de um comando SQL, para o sistema herdado do Oracle para extração dos dados. Os resultados são enviados pela rede e carregados diretamente no Azure Synapse, sem a necessidade de "guardar" os dados em arquivos intermediários. O fator limitante nesse cenário normalmente é a largura de banda da conexão de rede entre o banco de dados do Oracle e o ambiente do Azure. Para volumes de dados excepcionalmente grandes, talvez essa abordagem não seja prática.
Dica
Entenda os volumes de dados a serem migrados e a largura de banda de rede disponível, pois esses fatores influenciam a decisão sobre como conduzir a migração.
Há também uma abordagem híbrida que usa os dois métodos. Por exemplo, você pode usar a abordagem de extração de rede direta para tabelas de dimensões menores e exemplos das tabelas de fatos maiores para fornecer rapidamente um ambiente de teste no Azure Synapse. Para tabelas de fatos históricos de grande volume, é possível usar a abordagem de extração e transferência de arquivo usando o Azure Data Box.
Orquestrar do Oracle ou do Azure?
A abordagem recomendada ao migrar para o Azure Synapse é orquestrar a extração e o carregamento de dados do ambiente do Azure usando o SSMA ou o Data Factory. Use os utilitários associados, como o PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Essa abordagem se beneficia de recursos internos do Azure e reduz o esforço para criar pipelines de carregamento de dados reutilizáveis. Você pode usar pipelines de carregamento de dados controlados por metadados para automatizar o processo de migração.
A abordagem recomendada também minimiza o impacto sobre o desempenho no ambiente Oracle existente durante o processo de carregamento de dados, pois o processo de gerenciamento e carregamento é executado no Azure.
Ferramentas de migração de dados existentes
A transformação e a movimentação de dados são a função básica de todos os produtos de ETL. Se uma ferramenta de migração de dados já estiver em uso no ambiente Oracle existente e der suporte ao Azure Synapse como um ambiente de destino, considere usá-la para simplificar a migração de dados.
Mesmo que uma ferramenta de ETL existente não esteja em vigor, 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 de ETL, considere executá-la 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 Oracle.
Resumo
Para resumir, nossas recomendações para migrar dados e processos de ETL associados do Oracle para o Azure Synapse são:
Planeje 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 de uso de dados e de 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 o uso de uma instância do Oracle em uma VM do Azure como um degrau para descarregar a migração do ambiente herdado do Oracle.
Use recursos padrão internos do Azure para minimizar a carga de trabalho de migração.
Identifique e entenda as ferramentas mais eficientes para extração e carregamento de dados em ambientes do Oracle e do Azure. Use as ferramentas apropriadas em cada fase do processo.
Use instalações do Azure, como o Data Factory, para orquestrar e automatizar o processo de migração, minimizando o impacto no sistema do 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 do 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 muitos formatos, incluindo CSV, conforme mostrado na seguinte captura de tela:
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 aplicar a exportação para todo o conjunto no carrinho:
Você também pode usar o SQLcl (linha de comando do Oracle SQL Developer) para exportar dados Oracle. Essa opção dá suporte à automação usando um script de shell.
Para tabelas relativamente pequenas, você poderá achar essa técnica útil se tiver problemas ao extrair dados por meio de uma conexão direta.
Usar o conector do Oracle no Azure Data Factory para cópia paralela
Você pode usar o conector do Oracle no Data Factory para descarregar tabelas Oracle grandes em paralelo. O conector do Oracle fornece particionamento de dados interno para copiar dados do Oracle em paralelo. Você pode encontrar opções de particionamento de dados na guia Origem da atividade de cópia.
Para obter informações sobre como configurar o conector do 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 Copy.
Próximas etapas
Para saber mais sobre operações de acesso à segurança, confira o próximo artigo desta série: Segurança, acesso e operações para migrações do Oracle.