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 a migração de dados
Existem muitos fatores a considerar ao migrar dados, ETL e carregamentos de um armazém de dados oracle legado e data marts para Azure Synapse.
Decisões iniciais sobre a migração de dados do Oracle
Quando estiver a planear uma migração a partir de um ambiente Oracle existente, considere as seguintes perguntas relacionadas com 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 utilizadores?
Ao migrar data marts: mantenha-se físico ou virtual?
As secções seguintes abordam estes pontos no contexto de uma migração do Oracle.
Migrar tabelas não utilizadas?
Faz sentido migrar apenas as tabelas que estão a ser utilizadas. 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 utilizar metadados do sistema e ficheiros de registo em vez de documentação para determinar quais as tabelas que estão a ser utilizadas, uma vez que a documentação pode estar desatualizada.
As tabelas e os registos do catálogo do sistema Oracle contêm informações que podem ser utilizadas para determinar quando uma determinada tabela foi acedida pela última vez — que, por sua vez, pode ser utilizada para decidir se uma tabela é ou não candidata à migração.
Se licenciou o Pacote de Diagnóstico do Oracle, terá acesso ao Histórico de Sessões Ativas, que pode utilizar para determinar a última vez que uma tabela foi acedida.
Dica
Nos sistemas legados, não é incomum que as tabelas se tornem redundantes ao longo do tempo. Estes não precisam de ser migrados na maioria dos casos.
Eis uma consulta de exemplo que procura a utilização de uma tabela específica numa 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;
Esta consulta pode demorar algum tempo a ser executada se tiver executado várias consultas.
Qual é a melhor abordagem de migração para minimizar o risco e o impacto nos utilizadores?
Esta pergunta surge frequentemente porque as empresas podem querer reduzir o impacto das alterações no modelo de dados do armazém de dados para melhorar a agilidade. Muitas vezes, as empresas veem uma oportunidade de modernizar ou transformar ainda mais os seus dados durante uma migração etl. Esta abordagem tem um risco mais elevado porque altera vários fatores em simultâneo, dificultando a comparação dos resultados do sistema antigo com o novo. Fazer alterações ao modelo de dados aqui também pode afetar tarefas ETL a montante ou a jusante para outros sistemas. Devido a esse risco, é melhor redesenhar nesta escala após a migração do armazém de dados.
Mesmo que um modelo de dados seja intencionalmente alterado como parte da migração geral, é uma boa prática migrar o modelo existente tal como está para 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 do Azure para tarefas de reengenharia únicas.
Dica
Migrar o modelo existente tal como está inicialmente, mesmo que esteja planeada uma alteração ao modelo de dados no futuro.
Migração do data mart: manter-se físico ou virtual?
Em ambientes legados do armazém de dados Oracle, é prática comum criar muitos data marts estruturados para proporcionar um bom desempenho para consultas e relatórios ad hoc self-service para um determinado departamento ou função empresarial numa organização. Normalmente, um data mart consiste num subconjunto do armazém de dados que contém versões agregadas dos dados num formulário que permite aos utilizadores consultar facilmente esses dados com tempos de resposta rápidos. Os utilizadores podem utilizar ferramentas de consulta fáceis de utilizar, como o Microsoft Power BI, que suporta interações de utilizadores empresariais com data marts. A forma dos dados num data mart é geralmente um modelo de dados dimensional. Uma utilização dos data marts é expor os dados numa forma utilizável, mesmo que o modelo de dados do armazém subjacente seja algo diferente, como um cofre de dados.
Pode utilizar data marts separados para unidades de negócio individuais numa organização para implementar regimes de segurança de dados robustos. Restringir o acesso a data marts específicos que são relevantes para os utilizadores e eliminar, ocultar ou tornar anónimos os dados confidenciais.
Se estes data marts forem implementados como tabelas físicas, necessitarão de recursos de armazenamento adicionais e processamento para criar e atualizá-los regularmente. Além disso, os dados no mart só estarão atualizados como a última operação de atualização, pelo que podem não ser adequados para dashboards de dados altamente voláteis.
Dica
A virtualização dos data marts pode poupar nos recursos de armazenamento e processamento.
Com o advento de arquiteturas MPP dimensionáveis de baixo custo, como Azure Synapse e as respetivas características de desempenho inerentes, pode fornecer funcionalidades do data mart sem instanciar o mart como um conjunto de tabelas físicas. Um método consiste em virtualizar eficazmente os data marts através de vistas SQL para o armazém de dados principal. Outra forma é virtualizar os data marts através de uma camada de virtualização com funcionalidades como vistas no Azure ou produtos de virtualização de terceiros . Esta abordagem simplifica ou elimina a necessidade de processamento adicional de armazenamento e agregação e reduz o número global de objetos de base de dados a serem migrados.
Há outro potencial benefício desta abordagem. Ao implementar a lógica de agregação e associação numa camada de virtualização e ao apresentar ferramentas de relatórios externos através de uma vista virtualizada, o processamento necessário para criar estas vistas é enviado para o armazém de dados. Geralmente, o armazém de dados é o melhor local para executar associações, agregações e outras operações relacionadas em grandes volumes de dados.
Os principais fatores para implementar um data mart virtual num 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 arquivos de dados e cópias de dados.
Eliminação de tarefas ETL para migrar e simplificar a arquitetura do armazém de dados num ambiente virtualizado.
Desempenho: embora os data marts físicos tenham tido um desempenho historicamente melhor, os produtos de virtualização implementam agora técnicas inteligentes de colocação em cache para mitigar esta 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
Compreender os seus dados
Como parte do planeamento da migração, deve compreender em detalhe o volume de dados a migrar, uma vez que isso pode afetar as decisões sobre a abordagem de migração. Utilize metadados do sistema para determinar o espaço físico ocupado pelos dados não processados nas tabelas a migrar. Neste contexto, os dados não processados significam a quantidade de espaço utilizado pelas linhas de dados numa tabela, excluindo a sobrecarga, como índices e compressão. Normalmente, as maiores tabelas de factos incluirão 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 geral da base de dados inclui espaço utilizado e espaço livre.
A consulta de exemplo seguinte fornece uma discriminação do espaço em disco utilizado 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 equipa de migração de bases de dados da Microsoft fornece muitos recursos, incluindo os Artefactos do Script de Inventário Oracle. A ferramenta Artefactos de Script de Inventário Oracle inclui uma consulta PL/SQL que acede a tabelas de 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 de dados não processados em cada esquema e o dimensionamento de tabelas em cada esquema, com resultados armazenados num formato CSV. Uma folha de cálculo de calculadora incluída utiliza 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 ao extrair uma amostra representativa dos dados, como um milhão de linhas, para um ficheiro de dados ASCII simples delimitado descomprimido. Em seguida, utilize o tamanho desse ficheiro para obter um tamanho médio de dados não processados por linha. Por fim, multiplique esse tamanho médio pelo número total de linhas na tabela completa para dar um tamanho de dados não processados à tabela. Utilize esse tamanho de dados não processados no seu planeamento.
Utilizar consultas SQL para localizar tipos de dados
Ao consultar a vista do dicionário DBA_TAB_COLUMNS de dados estáticos oracle, pode determinar que tipos de dados estão a ser utilizados num esquema e se algum desses tipos de dados precisa de ser alterado. Utilize consultas SQL para localizar as colunas em qualquer esquema Oracle com tipos de dados que não mapeiam diretamente para tipos de dados no Azure Synapse. Da mesma forma, pode utilizar consultas para contar o número de ocorrências de cada tipo de dados Oracle que não mapeia diretamente para Azure Synapse. Ao utilizar os resultados destas consultas em combinação com a tabela de comparação de tipos de dados, pode determinar que tipos de dados têm de ser alterados num ambiente 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 aplicáveis, utilize 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 Assistente de Migração do SQL Server (SSMA) para o Oracle automatizar a migração de armazéns de dados a partir de ambientes Oracle legados, incluindo o mapeamento de tipos de dados. Também pode utilizar o Azure Database Migration Services para ajudar a planear e efetuar uma migração a partir de ambientes como o Oracle. Os fornecedores de terceiros também oferecem ferramentas e serviços para automatizar a migração. Se uma ferramenta ETL de terceiros já estiver a ser utilizada no ambiente Oracle, pode utilizar essa ferramenta para implementar as transformações de dados necessárias. A secção seguinte explora a migração de processos ETL existentes.
Considerações sobre a migração de ETL
Decisões iniciais sobre a migração do Oracle ETL
Para o processamento ETL/ELT, os armazéns de dados Oracle legados utilizam frequentemente scripts personalizados, ferramentas ETL de terceiros ou uma combinação de abordagens que evoluiu ao longo do tempo. Quando estiver a planear uma migração para Azure Synapse, determine a melhor forma de implementar o processamento ETL/ELT necessário no novo ambiente, minimizando também o custo e o risco.
Dica
Planeie a abordagem à migração de ETL com antecedência e tire partido das instalações do Azure, sempre que adequado.
O fluxograma seguinte resume uma abordagem:
Conforme mostrado no fluxograma, o passo inicial é sempre criar um inventário de processos ETL/ELT que precisam de ser migrados. Com as funcionalidades do Azure incorporadas padrão, alguns processos existentes podem não ter de ser movidos. Para fins de planeamento, é importante que compreenda a escala da migração. Em seguida, considere as perguntas na árvore de decisões do fluxograma:
Mudar para o Azure nativo? A sua resposta depende se está a migrar para um ambiente completamente nativo do Azure. Em caso afirmativo, recomendamos que volte a criar o processamento etl com Pipelines e atividades em pipelines Azure Data Factory ou Azure Synapse.
Está a utilizar uma ferramenta ETL de terceiros? Se não estiver a mudar para um ambiente completamente nativo do Azure, verifique se já está a ser utilizada uma ferramenta ETL de terceiros existente. No ambiente Oracle, poderá descobrir que algum ou todo o processamento ETL é efetuado por scripts personalizados com utilitários específicos do Oracle, como o Oracle SQL Developer, Oracle SQL*Loader ou Oracle Data Pump. Neste caso, a abordagem consiste em voltar a criar Azure Data Factory.
Os conjuntos de SQL dedicados de terceiros suportam conjuntos de SQL no Azure Synapse? Considere se existe um grande investimento em competências na ferramenta ETL de terceiros ou se os fluxos de trabalho e agendamentos existentes utilizam essa ferramenta. Em caso afirmativo, determine se a ferramenta pode suportar de forma eficiente Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores nativos que podem utilizar instalações do Azure, como o PolyBase ou COPY INTO para o carregamento de dados mais eficiente. Mas mesmo sem conectores nativos, geralmente existe uma forma de chamar processos externos, como o PolyBase ou
COPY INTO, e transmitir parâmetros aplicáveis. Neste caso, utilize competências e fluxos de trabalho existentes, com Azure Synapse como o novo ambiente de destino.Se estiver a utilizar o Oracle Data Integrator (ODI) para processamento de ELT, precisa de Módulos de Conhecimento odi para Azure Synapse. Se esses módulos não estiverem disponíveis para si na sua organização, mas tiver ODI, pode utilizar o ODI para gerar ficheiros simples. Esses ficheiros simples podem então ser movidos para o Azure e ingeridos em Azure Data Lake Storage para serem carregados para Azure Synapse.
Executar ferramentas ETL no Azure? Se decidir manter uma ferramenta ETL de terceiros existente, pode executar essa ferramenta no ambiente do Azure (em vez de num servidor ETL no local existente) e fazer com que o Data Factory processe a orquestração geral dos fluxos de trabalho existentes. Por isso, decida se pretende deixar a ferramenta existente em execução tal como está ou movê-la para o ambiente do Azure para obter os benefícios de custo, desempenho e escalabilidade.
Dica
Considere executar ferramentas ETL no Azure para tirar partido do desempenho, escalabilidade e benefícios de custos.
Reengenheirar scripts específicos do Oracle existentes
Se algum ou todos os processamentos ETL/ELT existentes do armazém Oracle forem processados por scripts personalizados que utilizam utilitários específicos do Oracle, tais como Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader ou Oracle Data Pump, terá de recodificar estes scripts para o ambiente de Azure Synapse. Da mesma forma, se os processos ETL tiverem sido implementados através de procedimentos armazenados no Oracle, terá de recodificar esses processos.
Alguns elementos do processo ETL são fáceis de migrar, por exemplo, através da simples carga de dados em massa para uma tabela de teste a partir de um ficheiro externo. Pode até ser possível automatizar essas partes do processo, por exemplo, ao utilizar Azure Synapse COPY INTO ou PolyBase em vez de SQL*Loader. Outras partes do processo que contêm procedimentos arbitrários complexos de SQL e/ou armazenados demorarão mais tempo a voltar a criar.
Dica
O inventário de tarefas ETL a migrar deve incluir scripts e procedimentos armazenados.
Uma forma de testar o Oracle SQL para compatibilidade com Azure Synapse é capturar algumas instruções SQL representativas de uma associação ao Oracle v$active_session_history e obter sql_textev$sql, em seguida, prefixar essas consultas com EXPLAIN. Partindo do princípio de que um modelo de dados migrado semelhante para semelhante no Azure Synapse, execute essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível irá apresentar um erro. Pode utilizar estas informações para determinar a escala da tarefa de recodificação.
Dica
Utilize EXPLAIN para localizar incompatibilidades de SQL.
Na pior das hipóteses, a recodificação manual pode ser necessária. No entanto, existem produtos e serviços disponíveis dos parceiros da Microsoft para ajudar na reengenharia de códigos específicos da Oracle.
Dica
Os parceiros oferecem produtos e competências para ajudar a reengenhar código específico da Oracle.
Utilizar ferramentas ETL de terceiros existentes
Em muitos casos, o sistema de armazém de dados legado existente já será preenchido e mantido por um produto ETL de terceiros. Veja Azure Synapse Parceiros de integração de dados do Analytics para obter uma lista dos atuais parceiros de integração de dados da Microsoft para Azure Synapse.
A comunidade Oracle utiliza frequentemente vários produtos ETL populares. Os parágrafos seguintes abordam as ferramentas ETL mais populares para armazéns Oracle. Pode executar todos esses produtos numa VM no Azure e utilizá-los para ler e escrever bases de dados e ficheiros do Azure.
Dica
Tire partido do investimento em ferramentas de terceiros existentes para reduzir o custo e o risco.
Carregamento de dados a partir do Oracle
Opções disponíveis ao carregar dados do Oracle
Quando estiver a preparar-se para migrar dados de um armazém de dados Oracle, decida como os dados serão movidos fisicamente do ambiente no local existente para Azure Synapse na cloud e quais as ferramentas que serão utilizadas para efetuar a transferência e carregamento. Considere as seguintes perguntas, que são abordadas nas secções seguintes.
Irá extrair os dados para ficheiros ou movê-los diretamente através de uma ligação de rede?
Irá orquestrar o processo a partir do sistema de origem ou do ambiente de destino do Azure?
Que ferramentas irá utilizar para automatizar e gerir o processo de migração?
Transferir dados através de ficheiros ou ligação de rede?
Assim que as tabelas de bases de dados a migrar tiverem sido criadas no Azure Synapse, pode mover os dados que preenchem essas tabelas para fora do sistema Oracle legado e para o novo ambiente. Existem duas abordagens básicas:
Extração de Ficheiros: extraia os dados das tabelas Oracle para ficheiros delimitados simples, normalmente no formato CSV. Pode extrair dados de tabela de várias formas:
- Utilize ferramentas Oracle padrão, como SQL*Plus, SQL Developer e SQLcl.
- Utilize o Oracle Data Integrator (ODI) para gerar ficheiros simples.
- Utilize o conector Oracle no Data Factory para descarregar tabelas Oracle em paralelo para ativar o carregamento de dados por partições.
- Utilize uma ferramenta ETL de terceiros .
Para obter exemplos de como extrair dados da tabela Oracle, veja o apêndice do artigo.
Esta abordagem requer espaço para localizar os ficheiros de dados extraídos. O espaço pode ser local para a base de dados de origem oracle se estiver disponível armazenamento suficiente ou remoto no Armazenamento de Blobs do Azure. O melhor desempenho é alcançado quando um ficheiro é escrito localmente, uma vez que evita a sobrecarga de rede.
Para minimizar os requisitos de armazenamento e transferência de rede, comprima os ficheiros de dados extraídos com um utilitário como o gzip.
Após a extração, mova os ficheiros simples para Armazenamento de Blobs do Azure. A Microsoft fornece várias opções para mover grandes volumes de dados, incluindo:
- AzCopy para mover ficheiros através da 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 datacenter do Azure para carregamento.
Para obter mais informações, veja Transferir dados de e para o Azure.
Extrair e carregar diretamente através da rede: o ambiente do Azure de destino envia um pedido de extração de dados, normalmente através de um comando SQL, para o sistema Oracle legado para extrair os dados. Os resultados são enviados através da rede e carregados diretamente para Azure Synapse, sem necessidade de colocar os dados em ficheiros intermédios. O fator de limitação neste cenário é normalmente a largura de banda da ligação de rede entre a base de dados Oracle e o ambiente do Azure. Para volumes de dados excepcionalmente grandes, esta abordagem pode não ser prática.
Dica
Compreenda os volumes de dados a migrar e a largura de banda de rede disponível, porque estes fatores influenciam a decisão de abordagem de migração.
Existe também uma abordagem híbrida que utiliza ambos os métodos. Por exemplo, pode utilizar a abordagem de extração de rede direta para tabelas de dimensão mais pequenas 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 utilizar a abordagem de extração e transferência de ficheiros com o Azure Data Box.
Orquestrar a partir do Oracle ou do Azure?
A abordagem recomendada ao mudar para Azure Synapse é orquestrar a extração e o carregamento de dados a partir do ambiente do Azure com o SSMA ou o Data Factory. Utilize os utilitários associados, como o PolyBase ou COPY INTOo , para o carregamento de dados mais eficiente. Esta abordagem beneficia das capacidades incorporadas do Azure e reduz o esforço para criar 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 o desempenho atingido no ambiente Oracle existente durante o processo de carregamento de dados, uma vez que o processo de gestão e carregamento é executado no Azure.
Ferramentas de migração de dados existentes
A transformação e movimento de dados é a função básica de todos os produtos ETL. Se uma ferramenta de migração de dados já estiver a ser utilizada no ambiente Oracle existente e suportar Azure Synapse como um ambiente de destino, considere utilizar essa ferramenta para simplificar a migração de dados.
Mesmo que uma ferramenta ETL existente não esteja implementada, os parceiros de integração de dados do Azure Synapse Analytics oferecem ferramentas ETL para simplificar a tarefa de migração de dados.
Por fim, se planear utilizar uma ferramenta ETL, considere executar essa ferramenta no ambiente do Azure para tirar partido do desempenho, escalabilidade e custo da cloud do Azure. Esta abordagem também liberta recursos no datacenter Oracle.
Resumo
Para resumir, as nossas recomendações para migrar dados e processos 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 migrar o mais rapidamente possível.
Utilize metadados do sistema e ficheiros de registo para obter uma compreensão precisa dos dados e da utilização do processo. Não dependa da documentação, uma vez que pode estar desatualizada.
Compreenda os volumes de dados a migrar e a largura de banda de rede entre o datacenter no local e os ambientes na cloud do Azure.
Considere utilizar uma instância oracle numa VM do Azure como um passo para descarregar a migração do ambiente Oracle legado.
Utilize as funcionalidades padrão incorporadas do Azure para minimizar a carga de trabalho de migração.
Identifique e compreenda as ferramentas mais eficientes para a extração e carregamento de dados em ambientes Oracle e Azure. Utilize as ferramentas adequadas em cada fase do processo.
Utilize instalações do 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 oracle
Pode utilizar várias técnicas para extrair dados oracle ao migrar do Oracle para o Azure Synapse. As secções seguintes demonstram como extrair dados oracle com o Oracle SQL Developer e o conector Oracle no Data Factory.
Utilizar o Oracle SQL Developer para extração de dados
Pode utilizar a IU do Oracle SQL Developer para exportar dados de tabela para vários formatos, incluindo CSV, conforme mostrado na seguinte captura de ecrã:
Outras opções de exportação incluem JSON e XML. Pode utilizar a IU para adicionar um conjunto de nomes de tabelas a um "carrinho" e, em seguida, aplicar a exportação a todo o conjunto no carrinho:
Também pode utilizar a Linha de Comandos do Oracle SQL Developer (SQLcl) para exportar dados oracle. Esta opção suporta a automatização através de um script de shell.
Para tabelas relativamente pequenas, poderá considerar esta técnica útil se tiver problemas ao extrair dados através de uma ligação direta.
Utilizar o conector Oracle no Azure Data Factory para cópia paralela
Pode utilizar o conector Oracle no Data Factory para descarregar grandes tabelas Oracle em paralelo. O conector Oracle fornece a criação de partições de dados incorporadas para copiar dados do Oracle em paralelo. Pode encontrar as opções de criação de partições de dados no separador 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 escalabilidade da atividade de cópia do Data Factory, veja atividade Copy guia de desempenho e escalabilidade.
Passos seguintes
Para saber mais sobre as operações de acesso à segurança, veja o próximo artigo desta série: Segurança, acesso e operações para migrações oracle.