Design e desempenho das migrações oracle

Este artigo é a primeira 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 de design e desempenho.

Descrição Geral

Devido ao custo e complexidade da manutenção e atualização de ambientes Oracle legados no local, muitos utilizadores existentes da Oracle querem tirar partido das inovações fornecidas pelos ambientes de cloud modernos. Os ambientes de cloud de infraestrutura como serviço (IaaS) e de plataforma como serviço (PaaS) permitem-lhe delegar tarefas como a manutenção da infraestrutura e o desenvolvimento de plataformas ao fornecedor de cloud.

Dica

Mais do que apenas uma base de dados— o ambiente do Azure inclui um conjunto abrangente de capacidades e ferramentas.

Embora o Oracle e o Azure Synapse Analytics sejam bases de dados SQL que utilizam técnicas de processamento paralelo em massa (MPP) para alcançar um elevado desempenho de consultas em volumes de dados excecionalmente grandes, existem algumas diferenças básicas na abordagem:

• Os sistemas Oracle legados são frequentemente instalados no local e utilizam hardware relativamente caro, enquanto Azure Synapse é baseado na cloud e utiliza recursos de armazenamento e computação do Azure.

• Atualizar uma configuração oracle é uma tarefa importante que envolve hardware físico adicional e reconfiguração de bases de dados potencialmente longas ou captura e recarregamento. Uma vez que os recursos de armazenamento e computação são separados no ambiente do Azure e têm capacidade de dimensionamento elástico, esses recursos podem ser dimensionados para cima ou para baixo de forma independente.

• Pode colocar em pausa ou redimensionar Azure Synapse conforme necessário para reduzir a utilização e o custo dos recursos.

O Microsoft Azure é um ambiente de cloud globalmente disponível, altamente seguro e dimensionável que inclui Azure Synapse e um ecossistema de ferramentas e capacidades de suporte. O diagrama seguinte resume o ecossistema Azure Synapse.

Azure Synapse proporciona o melhor desempenho da base de dados relacional ao utilizar técnicas como mPP e colocação em cache automática na memória. Pode ver os resultados destas técnicas em referências independentes, como a executada recentemente pela GigaOm, que compara Azure Synapse com outras ofertas populares do armazém de dados na cloud. Os clientes que migram para o ambiente de Azure Synapse vêem muitas vantagens, incluindo:

• Desempenho e preço/desempenho melhorados.

• Maior agilidade e tempo mais curto para valorizar.

• Implementação de servidor e desenvolvimento de aplicações mais rápido.

• Escalabilidade elástica — pague apenas a utilização real.

• Segurança/conformidade melhoradas.

• Custos de armazenamento e recuperação após desastre reduzidos.

• TCO global mais baixo, melhor controlo de custos e despesas operacionais simplificadas (OPEX).

Para maximizar estes benefícios, migre dados novos ou existentes e aplicações para a plataforma de Azure Synapse. Em muitas organizações, a migração inclui mover um armazém de dados existente de uma plataforma no local legada, como o Oracle, para Azure Synapse. A um nível elevado, o processo de migração inclui estes passos:

    Preparação 🡆

• Definir âmbito — o que deve ser migrado.

• Crie o inventário de dados e processos para migração.

• Definir alterações ao modelo de dados (se existirem).

• Definir o mecanismo de extração de dados de origem.

• Identifique as ferramentas e funcionalidades adequadas do Azure e de terceiros a utilizar.

• Treinar pessoal no início da nova plataforma.

• Configure a plataforma de destino do Azure.

    Migração 🡆

• Comece de forma pequena e simples.

• Automatize sempre que possível.

• Tire partido das ferramentas e funcionalidades incorporadas do Azure para reduzir o esforço de migração.

• Migrar metadados para tabelas e vistas.

• Migrar dados históricos a serem mantidos.

• Migrar ou refatorizar procedimentos armazenados e processos empresariais.

• Migrar ou refatorizar processos de carregamento incremental ETL/ELT.

    Pós-migração

• Monitorizar e documentar todas as fases do processo.

• Utilize a experiência adquirida para criar um modelo para futuras migrações.

• Reengenheirar o modelo de dados, se necessário (utilizando o desempenho e escalabilidade da nova plataforma).

• Testar aplicações e ferramentas de consulta.

• Referenciar e otimizar o desempenho das consultas.

Este artigo fornece informações gerais e diretrizes para otimização do desempenho ao migrar um armazém de dados de um ambiente Oracle existente para Azure Synapse. O objetivo da otimização do desempenho é alcançar o mesmo ou melhor desempenho do armazém de dados no Azure Synapse após a migração.

Considerações de design

Âmbito da migração

Quando estiver a preparar-se para migrar a partir de um ambiente Oracle, considere as seguintes opções de migração.

Escolher a carga de trabalho para a migração inicial

Normalmente, os ambientes Oracle legados evoluíram ao longo do tempo para abranger várias áreas temáticas e cargas de trabalho mistas. Quando decidir por onde começar um projeto de migração, escolha uma área onde poderá:

• Prove a viabilidade da migração para Azure Synapse ao proporcionar rapidamente os benefícios do novo ambiente.

• Permita que os seus técnicos internos obtenham experiência relevante com os processos e ferramentas que irão utilizar quando migrarem outras áreas.

• Crie um modelo para migrações adicionais específicas para o ambiente Oracle de origem e as ferramentas e processos atuais que já estão implementados.

Um bom candidato para uma migração inicial a partir de um ambiente Oracle suporta os itens anteriores e:

• Implementa uma carga de trabalho de BI/Analytics em vez de uma carga de trabalho de processamento de transações online (OLTP).

• Tem um modelo de dados, como um esquema de star ou floco de neve, que pode ser migrado com modificações mínimas.

Dica

Crie um inventário de objetos que precisam de ser migrados e documente o processo de migração.

O volume de dados migrados numa migração inicial deve ser suficientemente grande para demonstrar as capacidades e os benefícios do ambiente Azure Synapse, mas não demasiado grande para demonstrar rapidamente valor. Um tamanho no intervalo de 1 a 10 terabytes é típico.

Uma abordagem inicial para um projeto de migração é minimizar o risco, o esforço e o tempo necessários para que veja rapidamente os benefícios do ambiente da cloud do Azure. As abordagens seguintes limitam o âmbito da migração inicial apenas aos data marts e não abordam aspetos de migração mais amplos, como a migração etl e a migração de dados históricos. No entanto, pode abordar esses aspetos em fases posteriores do projeto assim que a camada do data mart migrada for preenchida novamente com dados e os processos de compilação necessários.

Migração lift-and-shift vs. Abordagem faseada

Em geral, existem dois tipos de migração, independentemente da finalidade e do âmbito da migração planeada: migração lift-and-shift tal como está e uma abordagem faseada que incorpora alterações.

Migração lift-and-shift

Numa migração lift-and-shift, um modelo de dados existente, como um esquema de star, é migrado inalterado para a nova plataforma de Azure Synapse. Esta abordagem minimiza o risco e o tempo de migração ao reduzir o trabalho necessário para tirar partido das vantagens de mudar para o ambiente de cloud do Azure. A migração lift-and-shift é uma boa opção para estes cenários:

• Tem um ambiente Oracle existente com um único data mart para migrar ou
• Tem um ambiente Oracle existente com dados que já se encontram num esquema de star ou floco de neve bem estruturado ou
• Está com pouco tempo e pressões de custos para mudar para um ambiente de cloud moderno.

Dica

A migração lift-and-shift é um bom ponto de partida, mesmo que as fases subsequentes implementem alterações ao modelo de dados.

Abordagem faseada que incorpora alterações

Se um armazém de dados legado tiver evoluído durante um longo período de tempo, poderá ter de o voltar a criar para manter os níveis de desempenho necessários. Também poderá ter de voltar a criar engenharia para suportar novos dados, como fluxos de Internet das Coisas (IoT). Como parte do processo de reengenharia, migre para Azure Synapse para obter os benefícios de um ambiente de cloud dimensionável. A migração pode incluir uma alteração no modelo de dados subjacente, como uma mudança de um modelo do Inmon para um cofre de dados.

A Microsoft recomenda mover o modelo de dados existente tal como está para o Azure e utilizar o desempenho e a flexibilidade do ambiente do Azure para aplicar as alterações de reengenharia. Dessa forma, pode utilizar as capacidades do Azure para fazer as alterações sem afetar o sistema de origem existente.

Utilizar instalações da Microsoft para implementar uma migração condicionada por metadados

Pode automatizar e orquestrar o processo de migração com as capacidades do ambiente do Azure. Esta abordagem minimiza o desempenho atingido no ambiente Oracle existente, que pode já estar em execução perto da capacidade.

O Assistente de Migração do SQL Server (SSMA) para Oracle pode automatizar muitas partes do processo de migração, incluindo em alguns casos funções e código processual. O SSMA suporta Azure Synapse como um ambiente de destino.

O SSMA para Oracle pode ajudá-lo a migrar um armazém de dados oracle ou data mart para Azure Synapse. O SSMA foi concebido para automatizar o processo de migração de tabelas, vistas e dados de um ambiente Oracle existente.

Azure Data Factory é um serviço de integração de dados baseado na cloud que suporta a criação de fluxos de trabalho baseados em dados na cloud que orquestram e automatizam o movimento de dados e a transformação de dados. Pode utilizar o Data Factory para criar e agendar fluxos de trabalho baseados em dados (pipelines) que ingerem dados de arquivos de dados diferentes. O Data Factory pode processar e transformar dados através de serviços de computação como o Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

O Data Factory pode ser utilizado para migrar dados na origem para SQL do Azure destino. Este movimento de dados offline ajuda a reduzir significativamente o tempo de inatividade da migração.

O Azure Database Migration Services pode ajudá-lo a planear e efetuar uma migração a partir de ambientes como o Oracle.

Quando estiver a planear utilizar as instalações do Azure para gerir o processo de migração, crie metadados que listem todas as tabelas de dados a migrar e a respetiva localização.

Diferenças de estrutura entre o Oracle e o Azure Synapse

Conforme mencionado anteriormente, existem algumas diferenças básicas na abordagem entre o Oracle e as bases de dados do Azure Synapse Analytics. O SSMA para Oracle não só ajuda a colmatar estas lacunas como também automatiza a migração. Embora o SSMA não seja a abordagem mais eficiente para volumes de dados muito elevados, é útil para tabelas mais pequenas.

Várias bases de dados vs. base de dados individual e esquemas

O ambiente Oracle contém frequentemente várias bases de dados separadas. Por exemplo, podem existir bases de dados separadas para: ingestão de dados e tabelas de teste, tabelas de armazém de núcleos e data marts, por vezes referidas como camada semântica. O processamento em pipelines ETL ou ELT pode implementar associações entre bases de dados e mover dados entre bases de dados separadas.

Por outro lado, o ambiente de Azure Synapse contém uma base de dados individual e utiliza esquemas para separar tabelas em grupos logicamente separados. Recomendamos que utilize uma série de esquemas na base de dados de destino Azure Synapse para imitar as bases de dados separadas migradas do ambiente Oracle. Se o ambiente Oracle já utilizar esquemas, poderá ter de utilizar uma nova convenção de nomenclatura quando mover as tabelas e vistas Oracle existentes para o novo ambiente. Por exemplo, pode concatenar os nomes de esquema e tabela oracle existentes no novo nome da tabela Azure Synapse e utilizar nomes de esquema no novo ambiente para manter os nomes de bases de dados separados originais. Embora possa utilizar vistas SQL sobre as tabelas subjacentes para manter as estruturas lógicas, existem potenciais desvantagens para essa abordagem:

• As vistas no Azure Synapse são só de leitura, pelo que todas as atualizações aos dados têm de ser realizadas nas tabelas base subjacentes.

• Pode já existir uma ou mais camadas de vistas e adicionar uma camada adicional de vistas pode afetar o desempenho.

Dica

Combine várias bases de dados numa única base de dados dentro de Azure Synapse e utilize nomes de esquemas para separar logicamente as tabelas.

Considerações sobre tabelas

Quando migra tabelas entre ambientes diferentes, normalmente apenas os dados não processados e os metadados que o descrevem migram fisicamente. Normalmente, outros elementos da base de dados do sistema de origem, como índices, não são migrados porque podem ser desnecessários ou implementados de forma diferente no novo ambiente.

As otimizações de desempenho no ambiente de origem, como índices, indicam onde pode adicionar otimização de desempenho no novo ambiente. Por exemplo, se as consultas no ambiente Oracle de origem utilizarem frequentemente índices mapeados por bits, isso sugere que deve ser criado um índice não agrupado no Azure Synapse. Outras técnicas nativas de otimização do desempenho, como a replicação de tabelas, podem ser mais aplicáveis do que a criação de índices semelhantes à reta. O SSMA para Oracle pode ser utilizado para fornecer recomendações de migração para distribuição e indexação de tabelas.

Dica

Os índices existentes indicam candidatos para indexação no armazém migrado.

Tipos de objetos de base de dados Oracle não suportados

Muitas vezes, as funcionalidades específicas do Oracle podem ser substituídas por Azure Synapse funcionalidades. No entanto, alguns objetos da base de dados Oracle não são suportados diretamente no Azure Synapse. A seguinte lista de objetos de base de dados Oracle não suportados descreve como pode obter uma funcionalidade equivalente no Azure Synapse.

• Várias opções de indexação: no Oracle, várias opções de indexação, como índices mapeados por bits, índices baseados em funções e índices de domínio, não têm equivalentes diretos no Azure Synapse.

  Pode descobrir quais as colunas indexadas e o tipo de índice ao:

  • Consultar tabelas e vistas do catálogo de sistemas, tais como ALL_INDEXES, DBA_INDEXES, USER_INDEXESe DBA_IND_COL. Pode utilizar as consultas incorporadas no Oracle SQL Developer, conforme mostrado na seguinte captura de ecrã.

    

    Em alternativa, execute a seguinte consulta para localizar todos os índices de um determinado tipo:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Consultar as dba_index_usage vistas ou v$object_usage quando a monitorização está ativada. Pode consultar essas vistas no Oracle SQL Developer, conforme mostrado na seguinte captura de ecrã.

    

  Os índices baseados em funções, em que o índice contém o resultado de uma função nas colunas de dados subjacentes, não têm equivalentes diretos em Azure Synapse. Recomendamos que migre primeiro os dados e, em seguida, em Azure Synapse executar as consultas Oracle que utilizam índices baseados em funções para medir o desempenho. Se o desempenho dessas consultas no Azure Synapse não for aceitável, considere criar uma coluna que contenha o valor pré-calculado e, em seguida, indexar essa coluna.

  Quando configura o ambiente Azure Synapse, faz sentido implementar apenas índices em utilização. Azure Synapse atualmente suporta os tipos de índice apresentados aqui:

  

  Azure Synapse funcionalidades, como o processamento paralelo de consultas e a colocação em cache dentro da memória de dados e resultados, tornam provável que sejam necessários menos índices para que as aplicações do armazém de dados alcancem objetivos de desempenho. Recomendamos que utilize os seguintes tipos de índice no Azure Synapse:

  • Índices columnstore agrupados: quando não são especificadas opções de índice para uma tabela, Azure Synapse por predefinição cria um índice columnstore em cluster. As tabelas columnstore em cluster oferecem o nível mais elevado de compressão de dados, o melhor desempenho geral das consultas e, geralmente, superam as tabelas de índices ou áreas dinâmicas para dados em cluster. Normalmente, um índice columnstore em cluster é a melhor opção para tabelas grandes. Quando criar uma tabela, selecione columnstore em cluster se não tiver a certeza de como indexar a tabela. No entanto, existem alguns cenários em que os índices columnstore em cluster não são a melhor opção:

    • As tabelas com dados de pré-ordenação numa(s) chave(s) de ordenação podem beneficiar da eliminação do segmento ativada por índices columnstore agrupados ordenados .
    • Tabelas com tipos de dados varchar(max), nvarchar(max) ou varbinary(max), porque um índice columnstore em cluster não suporta esses tipos de dados. Em vez disso, considere utilizar uma área dinâmica para dados ou um índice em cluster.
    • Tabelas com dados transitórios, porque as tabelas columnstore podem ser menos eficientes do que a área dinâmica para dados ou tabelas temporárias.
    • Tabelas pequenas com menos de 100 milhões de linhas. Em vez disso, considere utilizar tabelas de área dinâmica para dados.

  • Índices columnstore em cluster ordenados: ao permitir a eliminação eficiente de segmentos, os índices columnstore em cluster ordenados no Azure Synapse conjuntos de SQL dedicados proporcionam um desempenho muito mais rápido ao ignorar grandes quantidades de dados ordenados que não correspondem ao predicado da consulta. O carregamento de dados para uma tabela CCI ordenada pode demorar mais do que uma tabela CCI não ordenada devido à operação de ordenação de dados. No entanto, as consultas podem ser executadas mais rapidamente posteriormente com CCI ordenada. Para obter mais informações sobre índices columnstore agrupados ordenados, veja Otimização do desempenho com índice columnstore agrupado ordenado.

  • Índices agrupados e não agrupados: os índices em cluster podem superar os índices columnstore em cluster quando uma única linha precisa de ser rapidamente obtida. Para consultas em que uma única pesquisa de linha, ou apenas algumas pesquisas de linhas, têm de ser executadas a uma velocidade extrema, considere utilizar um índice de cluster ou um índice secundário não agrupado. A desvantagem de utilizar um índice em cluster é que apenas as consultas com um filtro altamente seletivo na coluna de índice agrupado irão beneficiar. Para melhorar a filtragem noutras colunas, pode adicionar um índice não agrupado às outras colunas. No entanto, cada índice que adicionar a uma tabela utiliza mais espaço e aumenta o tempo de processamento a carregar.

  • Tabelas de área dinâmica para dados: quando estiver temporariamente a colocar dados no Azure Synapse, poderá descobrir que a utilização de uma tabela de área dinâmica para dados torna o processo geral mais rápido. Isto acontece porque o carregamento de dados para tabelas de área dinâmica para dados é mais rápido do que carregar dados para tabelas de índice e, em alguns casos, as leituras subsequentes podem ser feitas a partir da cache. Se estiver a carregar dados apenas para os testar antes de executar mais transformações, é muito mais rápido carregá-lo para uma tabela de área dinâmica para dados do que uma tabela columnstore em cluster. Além disso, carregar dados para uma tabela temporária é mais rápido do que carregar uma tabela para armazenamento permanente. Para tabelas de referência pequenas com menos de 100 milhões de linhas, as tabelas de área dinâmica para dados são normalmente a escolha certa. As tabelas columnstore de cluster começam a obter uma compressão ideal quando contêm mais de 100 milhões de linhas.

• Tabelas agrupadas: as tabelas Oracle podem ser organizadas para que as linhas de tabela que são frequentemente acedidas em conjunto (com base num valor comum) sejam fisicamente armazenadas em conjunto para reduzir a E/S do disco quando os dados são obtidos. O Oracle também fornece uma opção de cluster hash para tabelas individuais, que aplica um valor hash à chave de cluster e armazena fisicamente linhas com o mesmo valor hash em conjunto. Para listar clusters numa base de dados Oracle, utilize a SELECT * FROM DBA_CLUSTERS; consulta. Para determinar se uma tabela está dentro de um cluster, utilize a SELECT * FROM TAB; consulta, que mostra o nome da tabela e o ID do cluster para cada tabela.

  No Azure Synapse, pode obter resultados semelhantes ao utilizar tabelas materializadas e/ou replicadas, uma vez que esses tipos de tabela minimizam a E/S necessária no tempo de execução da consulta.

• Vistas materializadas: o Oracle suporta vistas materializadas e recomenda a utilização de uma ou mais para tabelas grandes com muitas colunas em que apenas algumas colunas são utilizadas regularmente em consultas. As vistas materializadas são atualizadas automaticamente pelo sistema quando os dados na tabela base são atualizados.

  Em 2019, a Microsoft anunciou que Azure Synapse suportará vistas materializadas com a mesma funcionalidade da Oracle. As vistas materializadas são agora uma funcionalidade de pré-visualização no Azure Synapse.

• Acionadores na base de dados: no Oracle, um acionador pode ser configurado para ser executado automaticamente quando ocorre um evento de acionamento. Acionar eventos pode ser:

  • Uma instrução de linguagem de manipulação de dados (DML), como INSERT, UPDATEou DELETE, é executada numa tabela. Se tiver definido um acionador que é acionado antes de uma instrução INSERT numa tabela de cliente, o acionador será acionado uma vez antes de uma nova linha ser inserida na tabela do cliente.

  • Uma instrução DDL, como CREATE ou ALTER, é executada. Este acionador é frequentemente utilizado para fins de auditoria para registar alterações de esquema.

  • Um evento de sistema, como o arranque ou o encerramento da base de dados Oracle.

  • Um evento de utilizador, como início de sessão ou fim de sessão.

  Pode obter uma lista dos acionadores definidos numa base de dados Oracle ao consultar as ALL_TRIGGERSvistas , DBA_TRIGGERSou USER_TRIGGERS . A seguinte captura de ecrã mostra uma DBA_TRIGGERS consulta no Oracle SQL Developer.

  

  Azure Synapse não suporta acionadores de base de dados Oracle. No entanto, pode adicionar funcionalidades equivalentes com o Data Factory, embora isso exija que refatorize os processos que utilizam acionadores.

• Sinónimos: o Oracle suporta a definição de sinónimos como nomes alternativos para vários tipos de objetos de base de dados. Esses tipos de objeto incluem: tabelas, vistas, sequências, procedimentos, funções armazenadas, pacotes, vistas materializadas, objetos de esquema de classe Java, objetos definidos pelo utilizador ou outro sinónimo.

  Azure Synapse não suporta atualmente a definição de sinónimos, embora se um sinónimo no Oracle se referir a uma tabela ou vista, pode definir uma vista no Azure Synapse para corresponder ao nome alternativo. Se um sinónimo no Oracle se referir a uma função ou procedimento armazenado, em Azure Synapse pode criar outra função ou procedimento armazenado, com um nome que corresponda ao sinónimo, que chama o destino.

• Tipos definidos pelo utilizador: o Oracle suporta objetos definidos pelo utilizador que podem conter uma série de campos individuais, cada um com a sua própria definição e valores predefinidos. Esses objetos podem ser referenciados numa definição de tabela da mesma forma que os tipos de dados incorporados, como NUMBER ou VARCHAR. Pode obter uma lista de tipos definidos pelo utilizador numa base de dados Oracle ao consultar as ALL_TYPESvistas , DBA_TYPESou USER_TYPES .

  Azure Synapse não suporta atualmente tipos definidos pelo utilizador. Se os dados que precisa de migrar incluir tipos de dados definidos pelo utilizador, "achatá-los" numa definição de tabela convencional ou se forem matrizes de dados, normalize-os numa tabela separada.

Mapeamento do tipo de dados Oracle

A maioria dos tipos de dados Oracle tem um equivalente direto no Azure Synapse. A tabela seguinte mostra a abordagem recomendada para mapear tipos de dados Oracle para Azure Synapse.

Tipo de Dados Oracle	Tipo de Dados Azure Synapse
BFILE	Não suportado. Mapear para VARBINARY (MAX).
BINARY_FLOAT	Não suportado. Mapear para FLOAT.
BINARY_DOUBLE	Não suportado. Mapear para DOUBLE.
BLOB	Não suportado diretamente. Substitua por VARBINARY(MAX).
CARÁTER	CARÁTER
CLOB	Não suportado diretamente. Substitua por VARCHAR(MAX).
DATA	DATA no Oracle também pode conter informações de hora. Dependendo do mapa de utilização para DATA ou CARIMBO DE DATA/HORA.
DECIMAL	DECIMAL
DUPLO	PRECISÃO DUPLA
FLOAT	FLOAT
INTEGER	INT
INTERVALO ANO A MÊS	Os tipos de dados INTERVAL não são suportados. Utilize funções de comparação de datas, como DATEDIFF ou DATEADD, para cálculos de data.
INTERVALO DIA A SEGUNDO	Os tipos de dados INTERVAL não são suportados. Utilize funções de comparação de datas, como DATEDIFF ou DATEADD, para cálculos de data.
LONGO	Não suportado. Mapear para VARCHAR(MAX).
LONG RAW	Não suportado. Mapear para VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NÚMERO	FLOAT
NCLOB	Não suportado diretamente. Substitua por NVARCHAR(MAX).
NUMÉRICO	NUMÉRICO
Tipos de dados de multimédia ORD	Não suportado
RAW	Não suportado. Mapear para VARBINARY.
REAL	REAL
ROWID	Não suportado. Mapear para GUID, que é semelhante.
Tipos de dados geoespaciais do SDO	Não suportado
SMALLINT	SMALLINT
CARIMBO DE DATA/HORA	DATETIME2 ou a função CURRENT_TIMESTAMP()
CARIMBO DE DATA/HORA COM FUSO HORÁRIO LOCAL	Não suportado. Mapear para DATETIMEOFFSET.
CARIMBO DE DATA/HORA COM FUSO HORÁRIO	Não suportado porque a TIME é armazenada com a hora do relógio de parede sem um desvio do fuso horário.
Tipo de URI	Não suportado. Armazene num VARCHAR.
UROWID	Não suportado. Mapear para GUID, que é semelhante.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Não suportado. Armazene dados XML num VARCHAR.

O Oracle também suporta a definição de objetos definidos pelo utilizador que podem conter uma série de campos individuais, cada um com a sua própria definição e valores predefinidos. Em seguida, esses objetos podem ser referenciados numa definição de tabela da mesma forma que os tipos de dados incorporados, como NUMBER ou VARCHAR. Azure Synapse não suporta atualmente tipos definidos pelo utilizador. Se os dados que precisa de migrar incluir tipos de dados definidos pelo utilizador, "achatá-los" numa definição de tabela convencional ou se forem matrizes de dados, normalize-os numa tabela separada.

Dica

Avalie o número e o tipo de tipos de dados não suportados durante a fase de preparação da migração.

Os fornecedores de terceiros oferecem ferramentas e serviços para automatizar a migração, incluindo o mapeamento de tipos de dados. Se uma ferramenta ETL de terceiros já estiver a ser utilizada no ambiente Oracle, utilize essa ferramenta para implementar as transformações de dados necessárias.

Diferenças de sintaxe da DML SQL

Existem diferenças de sintaxe de DML SQL entre o Oracle SQL e o T-SQL Azure Synapse. Estas diferenças são abordadas em detalhe em Minimizar problemas do SQL para migrações do Oracle. Em alguns casos, pode automatizar a migração de DML com ferramentas da Microsoft, como o SSMA para Oracle e o Azure Database Migration Services, ou produtos e serviços de migração de terceiros .

Funções, procedimentos armazenados e sequências

Ao migrar um armazém de dados a partir de um ambiente maduro como o Oracle, provavelmente terá de migrar elementos que não sejam tabelas e vistas simples. Verifique se as ferramentas no ambiente do Azure podem substituir a funcionalidade de funções, procedimentos armazenados e sequências, porque normalmente é mais eficiente utilizar ferramentas incorporadas do Azure do que recodificá-las para Azure Synapse.

Como parte da fase de preparação, crie um inventário de objetos que precisam de ser migrados, defina um método para os processar e aloque os recursos adequados no seu plano de migração.

As ferramentas da Microsoft, como o SSMA para Oracle e o Azure Database Migration Services, ou produtos e serviços de migração de terceiros , podem automatizar a migração de funções, procedimentos armazenados e sequências.

As secções seguintes abordam ainda mais a migração de funções, procedimentos armazenados e sequências.

Funções

Tal como acontece com a maioria dos produtos de base de dados, o Oracle suporta funções definidas pelo sistema e pelo utilizador numa implementação do SQL. Quando migra uma plataforma de base de dados legada para Azure Synapse, as funções comuns do sistema podem normalmente ser migradas sem alterações. Algumas funções do sistema podem ter uma sintaxe ligeiramente diferente, mas quaisquer alterações necessárias podem ser automatizadas. Pode obter uma lista de funções numa base de dados Oracle ao consultar a ALL_OBJECTS vista com a cláusula adequada WHERE . Pode utilizar o Oracle SQL Developer para obter uma lista de funções, conforme mostrado na seguinte captura de ecrã.

Para funções do sistema Oracle ou funções arbitrárias definidas pelo utilizador que não têm equivalente no Azure Synapse, recodifigue essas funções com uma linguagem de ambiente de destino. As funções definidas pelo utilizador oracle são codificadas em PL/SQL, Java ou C. Azure Synapse utiliza a linguagem Transact-SQL para implementar funções definidas pelo utilizador.

Procedimentos armazenados

A maioria dos produtos de base de dados modernos suportam o armazenamento de procedimentos na base de dados. O Oracle fornece a linguagem PL/SQL para este fim. Normalmente, um procedimento armazenado contém instruções SQL e lógica processual e devolve dados ou um estado. Pode obter uma lista de procedimentos armazenados numa base de dados Oracle ao consultar a ALL_OBJECTS vista com a cláusula adequada WHERE . Pode utilizar o Oracle SQL Developer para obter uma lista de procedimentos armazenados, conforme mostrado na captura de ecrã seguinte.

Azure Synapse suporta procedimentos armazenados através do T-SQL, pelo que terá de recodificar quaisquer procedimentos armazenados migrados nesse idioma.

Sequências

No Oracle, uma sequência é um objeto de base de dados com nome, criado com CREATE SEQUENCE. Uma sequência fornece valores numéricos exclusivos através dos CURRVAL métodos e NEXTVAL . Pode utilizar os números exclusivos gerados como valores de chave de substituição para chaves primárias.

Azure Synapse não implementa CREATE SEQUENCE, mas pode implementar sequências com colunas IDENTITY ou código SQL que gera o número de sequência seguinte numa série.

Extrair metadados e dados de um ambiente Oracle

Geração de Linguagem de Definição de Dados

A norma ANSI SQL define a sintaxe básica para comandos DDL (Data Definition Language). Alguns comandos DDL, como CREATE TABLE e CREATE VIEW, são comuns ao Oracle e ao Azure Synapse, mas também fornecem funcionalidades específicas de implementação, como a indexação, a distribuição de tabelas e as opções de criação de partições.

Pode editar oracle CREATE TABLE e CREATE VIEW scripts existentes para obter definições equivalentes no Azure Synapse. Para tal, poderá ter de utilizar tipos de dados modificados e remover ou modificar cláusulas específicas do Oracle, como TABLESPACE.

No ambiente Oracle, as tabelas de catálogo do sistema especificam a tabela atual e a definição de vista. Ao contrário da documentação mantida pelo utilizador, as informações do catálogo de sistema estão sempre completas e sincronizadas com as definições de tabela atuais. Pode aceder a informações do catálogo de sistemas com utilitários como o Oracle SQL Developer. O Oracle SQL Developer pode gerar CREATE TABLE instruções DDL que pode editar para criar tabelas equivalentes no Azure Synapse.

Em alternativa, pode utilizar o SSMA para Oracle para migrar tabelas de um ambiente Oracle existente para Azure Synapse. O SSMA para Oracle aplicará os mapeamentos de tipos de dados adequados e os tipos de tabela e distribuição recomendados, conforme mostrado na seguinte captura de ecrã.

Também pode utilizar ferramentas de migração e ETL de terceiros que processam informações do catálogo de sistemas para obter resultados semelhantes.

Extração de dados do Oracle

Pode extrair dados de tabelas não processados de tabelas Oracle para ficheiros delimitados simples, como ficheiros CSV, através de utilitários Oracle padrão, como Oracle SQL Developer, SQL*Plus e SCLcl. Em seguida, pode comprimir os ficheiros delimitados simples com gzip e carregar os ficheiros comprimidos para Armazenamento de Blobs do Azure com o AzCopy ou as ferramentas de transporte de dados do Azure, como o Azure Data Box.

Extraia os dados da tabela da forma mais eficiente possível, especialmente ao migrar tabelas de factos grandes. Para tabelas Oracle, utilize paralelismo para maximizar o débito de extração. Pode alcançar o paralelismo ao executar vários processos que extraem individualmente segmentos discretos de dados ou através de ferramentas capazes de automatizar a extração paralela através da criação de partições.

Dica

Utilize o paralelismo para a extração de dados mais eficiente.

Se estiver disponível largura de banda de rede suficiente, pode extrair dados de um sistema Oracle no local diretamente para tabelas de Azure Synapse ou o Armazenamento de Dados de Blobs do Azure. Para tal, utilize processos do Data Factory, Azure Database Migration Service ou migração de dados de terceiros ou produtos ETL.

Os ficheiros de dados extraídos devem conter texto delimitado no formato CSV, OrC (Optimized Row Columnar) ou Parquet.

Para obter mais informações sobre a migração de dados e ETL a partir de um ambiente Oracle, veja Migração de dados, ETL e carregamento para migrações Oracle.

Recomendações de desempenho para migrações oracle

O objetivo da otimização do desempenho é o mesmo ou melhor desempenho do armazém de dados após a migração para Azure Synapse.

Semelhanças nos conceitos de abordagem de otimização do desempenho

Muitos conceitos de otimização do desempenho para bases de dados Oracle são verdadeiros para bases de dados Azure Synapse. Por exemplo:

• Utilize a distribuição de dados para colocar os dados a associar no mesmo nó de processamento.

• Utilize o tipo de dados mais pequeno para uma determinada coluna para poupar espaço de armazenamento e acelerar o processamento de consultas.

• Certifique-se de que as colunas a associar têm o mesmo tipo de dados para otimizar o processamento de associação e reduzir a necessidade de transformações de dados.

• Para ajudar o otimizador a produzir o melhor plano de execução, certifique-se de que as estatísticas estão atualizadas.

• Monitorize o desempenho com as capacidades de bases de dados incorporadas para garantir que os recursos estão a ser utilizados de forma eficiente.

Dica

Priorize a familiaridade com Azure Synapse opções de otimização no início de uma migração.

Diferenças na abordagem de otimização do desempenho

Esta secção destaca as diferenças de implementação de otimização do desempenho de baixo nível entre o Oracle e o Azure Synapse.

Opções de distribuição de dados

Para o desempenho, Azure Synapse foi concebido com arquitetura de vários nós e utiliza o processamento paralelo. Para otimizar o desempenho da tabela no Azure Synapse, pode definir uma opção de distribuição de dados nas CREATE TABLE instruções com a DISTRIBUTION instrução . Por exemplo, pode especificar uma tabela distribuída por hash, que distribui linhas de tabela pelos nós de computação através de uma função hash determinista. Muitas implementações do Oracle, especialmente sistemas no local mais antigos, não suportam esta funcionalidade.

Ao contrário do Oracle, Azure Synapse suporta associações locais entre uma pequena tabela e uma tabela grande através de uma pequena replicação de tabela. Por exemplo, considere uma tabela de dimensão pequena e uma tabela de factos grande dentro de um modelo de esquema star. Azure Synapse pode replicar a tabela de dimensão mais pequena em todos os nós para garantir que o valor de qualquer chave de associação para a tabela grande tem uma linha de dimensão disponível localmente correspondente. A sobrecarga da replicação da tabela de dimensão é relativamente baixa para uma tabela de dimensão pequena. Para tabelas de dimensão grande, uma abordagem de distribuição de hash é mais adequada. Para obter mais informações sobre as opções de distribuição de dados, veja Orientações de conceção para utilizar tabelas replicadas e Documentação de Orientação para a conceção de tabelas distribuídas.

Dica

A distribuição hash melhora o desempenho das consultas em tabelas de factos grandes. A distribuição round robin é útil para melhorar a velocidade de carregamento.

A distribuição hash pode ser aplicada em múltiplas colunas para uma distribuição mais uniforme da tabela base. A distribuição de várias colunas permite-lhe escolher até oito colunas para distribuição. Isto não só reduz a distorção de dados ao longo do tempo, como também melhora o desempenho das consultas.

Nota

A distribuição de várias colunas está atualmente em pré-visualização do Azure Synapse Analytics. Pode utilizar a distribuição de várias colunas com CREATE MATERIALIZED VIEW, CREATE TABLE e CREATE TABLE AS SELECT.

Assistente de Distribuição

No Azure Synapse SQL, a forma como cada tabela é distribuída pode ser personalizada. A estratégia de distribuição de tabelas afeta substancialmente o desempenho das consultas.

O assistente de distribuição é uma nova funcionalidade no SQL do Synapse que analisa consultas e recomenda as melhores estratégias de distribuição para tabelas para melhorar o desempenho das consultas. As consultas a considerar pelo assistente podem ser fornecidas por si ou retiradas das consultas históricas disponíveis no DMV.

Para obter detalhes e exemplos sobre como utilizar o assistente de distribuição, visite o Assistente de Distribuição no AZURE SYNAPSE SQL.

Indexação de dados

Azure Synapse suporta várias opções de indexação definíveis pelo utilizador que têm uma operação e utilização diferentes em comparação com os mapas de zona geridos pelo sistema no Oracle. Para obter mais informações sobre as diferentes opções de indexação no Azure Synapse, veja Índices em tabelas de conjuntos de SQL dedicadas.

As definições de índice num ambiente Oracle de origem fornecem uma indicação útil da utilização de dados e das colunas candidatas para indexação no ambiente Azure Synapse. Normalmente, não terá de migrar todos os índices de um ambiente Oracle legado porque Azure Synapse não depende excessivamente de índices e implementa as seguintes funcionalidades para obter um desempenho excecional:

• Processamento paralelo de consultas.

• Dados dentro da memória e colocação em cache do conjunto de resultados.

• Distribuição de dados, como a replicação de tabelas de dimensão pequena, para reduzir a E/S.

Criação de partições de dados

Num armazém de dados empresarial, as tabelas de factos podem conter milhares de milhões de linhas. A criação de partições otimiza a manutenção e a consulta destas tabelas ao dividi-las em partes separadas para reduzir a quantidade de dados processados. No Azure Synapse, a CREATE TABLE instrução define a especificação de criação de partições para uma tabela.

Só pode utilizar um campo por tabela para a criação de partições. Esse campo é frequentemente um campo de data porque muitas consultas são filtradas por data ou intervalo de datas. É possível alterar a criação de partições de uma tabela após a carga inicial com a CREATE TABLE AS instrução (CTAS) para recriar a tabela com uma nova distribuição. Para uma discussão detalhada sobre a criação de partições no Azure Synapse, veja Criar partições de tabelas no conjunto de SQL dedicado.

PolyBase ou COPY INTO para carregamento de dados

O PolyBase suporta o carregamento eficiente de grandes quantidades de dados para um armazém de dados através de fluxos de carregamento paralelos. Para obter mais informações, veja Estratégia de carregamento de dados do PolyBase.

COPY INTO também suporta ingestão de dados de alto débito e:

• Obtenção de dados de todos os ficheiros numa pasta e subpastas.
• Obtenção de dados de várias localizações na mesma conta de armazenamento. Pode especificar várias localizações com caminhos separados por vírgulas.
• Azure Data Lake Storage (ADLS) e Armazenamento de Blobs do Azure.
• Formatos de ficheiro CSV, PARQUET e ORC.

Dica

O método recomendado para o carregamento de dados é utilizar COPY INTO juntamente com o formato de ficheiro PARQUET.

Gestão de cargas de trabalho

A execução de cargas de trabalho mistas pode colocar desafios de recursos em sistemas ocupados. Um esquema de gestão de cargas de trabalho bem-sucedido gere recursos de forma eficaz, garante uma utilização de recursos altamente eficiente e maximiza o retorno do investimento (ROI). A classificação de cargas de trabalho, a importância da carga de trabalho e o isolamento da carga de trabalho dão mais controlo sobre a forma como a carga de trabalho utiliza os recursos do sistema.

O guia de gestão de cargas de trabalho descreve as técnicas para analisar a carga de trabalho, gerir e monitorizar a importância da carga de trabalho e os passos para converter uma classe de recursos num grupo de cargas de trabalho. Utilize as consultas portal do Azure e T-SQL em DMVs para monitorizar a carga de trabalho para garantir que os recursos aplicáveis são utilizados de forma eficiente.

Passos seguintes

Para saber mais sobre o ETL e a carga para a migração oracle, veja o próximo artigo desta série: Migração de dados, ETL e carga para migrações Oracle.