Design e desempenho para migrações Oracle

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

Descrição geral

Devido ao custo e à complexidade de manter e atualizar ambientes Oracle legados no local, muitos usuários Oracle existentes querem aproveitar as inovações fornecidas pelos ambientes de nuvem modernos. Os ambientes de nuvem de infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS) permitem delegar tarefas como manutenção de infraestrutura e desenvolvimento de plataforma ao provedor de nuvem.

Embora o Oracle e o Azure Synapse Analytics sejam bancos de dados SQL que usam técnicas de processamento paralelo maciço (MPP) para obter alto desempenho de consulta em volumes de dados excepcionalmente grandes, há algumas diferenças básicas na abordagem:

• Os sistemas Oracle herdados geralmente são instalados no local e usam hardware relativamente caro, enquanto o Azure Synapse é baseado em nuvem e usa recursos de computação e armazenamento do Azure.

• Atualizar uma configuração Oracle é uma tarefa importante que envolve hardware físico extra e reconfiguração de banco de dados potencialmente demorada, ou despejo e recarga. Como 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.

• Você pode pausar ou redimensionar o Azure Synapse conforme necessário para reduzir a utilização de recursos e o custo.

O Microsoft Azure é um ambiente de nuvem globalmente disponível, altamente seguro e escalável que inclui o Azure Synapse e um ecossistema de ferramentas e recursos de suporte. O diagrama seguinte resume o ecossistema do Azure Synapse.

O Azure Synapse fornece o melhor desempenho de banco de dados relacional usando técnicas como MPP e cache automático na memória. Você pode ver os resultados dessas técnicas em benchmarks independentes, como o executado recentemente pela GigaOm, que compara o Azure Synapse a outras ofertas populares de data warehouse na nuvem. Os clientes que migram para o ambiente do Azure Synapse veem muitos benefícios, incluindo:

• Melhor desempenho e preço/desempenho.

• Maior agilidade e menor tempo de valorização.

• Implantação de servidor e desenvolvimento de aplicativos mais rápidos.

• Escalabilidade elástica — pague apenas pelo uso real.

• Maior segurança/conformidade.

• Custos reduzidos de armazenamento e recuperação de desastres.

• Menor TCO geral, melhor controle de custos e despesas operacionais simplificadas (OPEX).

Para maximizar esses benefícios, migre dados e aplicativos novos ou existentes para a plataforma Azure Synapse. Em muitas organizações, a migração inclui a movimentação de um data warehouse existente de uma plataforma local herdada, como a Oracle, para o Azure Synapse. Em um alto nível, o processo de migração inclui estas etapas:

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

Considerações de design

Âmbito da migração

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

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

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

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

• Permita que sua equipe técnica interna ganhe experiência relevante com os processos e ferramentas que eles usarão quando migrarem outras áreas.

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

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

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

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

O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar os recursos e benefícios do ambiente do Azure Synapse, mas não muito grande para demonstrar valor rapidamente. Um tamanho na faixa de 1-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 você veja rapidamente os benefícios do ambiente de nuvem do Azure. As abordagens a seguir limitam o escopo da migração inicial apenas aos data marts e não abordam aspetos mais amplos da migração, como migração de ETL e migração de dados históricos. No entanto, você pode abordar esses aspetos em fases posteriores do projeto, uma vez que a camada de data mart migrada é preenchida com dados e os processos de compilação necessários.

Migração de elevação e deslocamento versus abordagem faseada

Em geral, existem dois tipos de migração, independentemente da finalidade e do âmbito da migração planeada: o lift and shift no estado em que se encontra e uma abordagem faseada que incorpora alterações.

Migração lift-and-shift

Em uma migração de elevação e deslocamento, um modelo de dados existente, como um esquema em estrela, é migrado inalterado para a nova plataforma Azure Synapse. Essa abordagem minimiza o risco e o tempo de migração, reduzindo o trabalho necessário para obter os benefícios da mudança para o ambiente de nuvem do Azure. A migração de elevação e deslocamento é uma boa opção para estes cenários:

• Você tem um ambiente Oracle existente com um único data mart para migrar, ou
• Você tem um ambiente Oracle existente com dados que já estão em um esquema de estrela ou floco de neve bem projetado, ou
• Você está sob pressão de tempo e custo para migrar para um ambiente de nuvem moderno.

Abordagem faseada que incorpora alterações

Se um data warehouse herdado tiver evoluído durante um longo período de tempo, talvez seja necessário reprojetá-lo para manter os níveis de desempenho necessários. Você também pode ter que fazer uma nova engenharia para dar suporte a novos dados, como fluxos de Internet das Coisas (IoT). Como parte do processo de reengenharia, migre para o Azure Synapse para obter os benefícios de um ambiente de nuvem escalável. A migração pode incluir uma alteração no modelo de dados subjacente, como uma mudança de um modelo Inmon para um cofre de dados.

A Microsoft recomenda mover seu modelo de dados existente no estado em que se encontra para o Azure e usar o desempenho e a flexibilidade do ambiente do Azure para aplicar as alterações de reengenharia. Dessa forma, você pode usar os recursos do Azure para fazer as alterações sem afetar o sistema de origem existente.

Usar recursos da Microsoft para implementar uma migração orientada por metadados

Você pode automatizar e orquestrar o processo de migração usando os recursos do ambiente do Azure. Essa abordagem minimiza o impacto no desempenho no ambiente Oracle existente, que pode já estar sendo executado 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 de procedimento. O SSMA dá suporte ao Azure Synapse como um ambiente de destino.

O SSMA para Oracle pode ajudá-lo a migrar um data warehouse ou data mart Oracle para o Azure Synapse. O SSMA foi projetado para automatizar o processo de migração de tabelas, exibições e dados de um ambiente Oracle existente.

O Azure Data Factory é um serviço de integração de dados baseado na nuvem que suporta a criação de fluxos de trabalho orientados por dados na nuvem que orquestram e automatizam a movimentação e a transformação de dados. Você pode usar o Data Factory para criar e agendar fluxos de trabalho controlados por dados (pipelines) que ingerem dados de armazenamentos de dados diferentes. O Data Factory pode processar e transformar dados usando serviços de computação como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

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

Os Serviços de Migração de Banco de Dados do Azure podem ajudá-lo a planejar e executar uma migração de ambientes como o Oracle.

Quando você estiver planejando usar os recursos do Azure para gerenciar o processo de migração, crie metadados que listem todas as tabelas de dados a serem migradas e sua localização.

Diferenças de design entre Oracle e Azure Synapse

Como mencionado anteriormente, há algumas diferenças básicas na abordagem entre os bancos de dados Oracle e Azure Synapse Analytics. O SSMA para Oracle não só ajuda a preencher essas lacunas, mas também automatiza a migração. Embora o SSMA não seja a abordagem mais eficiente para volumes muito altos de dados, ele é útil para tabelas menores.

Vários bancos de dados versus um único banco de dados e esquemas

O ambiente Oracle geralmente contém vários bancos de dados separados. Por exemplo, pode haver bancos de dados separados para: tabelas de ingestão e preparo de dados, tabelas de depósito principais e data marts, às vezes chamada de camada semântica. O processamento em pipelines ETL ou ELT pode implementar junções entre bancos de dados e mover dados entre bancos de dados separados.

Por outro lado, o ambiente do Azure Synapse contém um único banco de dados e usa esquemas para separar tabelas em grupos logicamente separados. Recomendamos que você use uma série de esquemas no banco de dados Synapse do Azure de destino para imitar os bancos de dados separados migrados do ambiente Oracle. Se o ambiente Oracle já usa esquemas, talvez seja necessário usar uma nova convenção de nomenclatura ao mover as tabelas e exibições Oracle existentes para o novo ambiente. Por exemplo, você pode concatenar o esquema Oracle existente e os nomes de tabela no novo nome de tabela do Azure Synapse e usar nomes de esquema no novo ambiente para manter os nomes de banco de dados separados originais. Embora você possa usar exibições SQL sobre as tabelas subjacentes para manter as estruturas lógicas, há desvantagens potenciais nessa abordagem:

• As exibições no Azure Synapse são somente leitura, portanto, todas as atualizações dos dados devem ocorrer nas tabelas base subjacentes.

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

Considerações sobre a tabela

Quando você migra tabelas entre ambientes diferentes, normalmente apenas os dados brutos e os metadados que os descrevem são migrados fisicamente. Outros elementos de banco de dados do sistema de origem, como índices, geralmente 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 você pode adicionar otimização de desempenho no novo ambiente. Por exemplo, se as consultas no ambiente Oracle de origem usarem frequentemente índices mapeados por bits, isso sugere que um índice não clusterizado deve ser criado no Azure Synapse. Outras técnicas nativas de otimização de desempenho, como a replicação de tabelas, podem ser mais aplicáveis do que a criação direta de índices semelhantes. O SSMA para Oracle pode ser usado para fornecer recomendações de migração para distribuição e indexação de tabelas.

Tipos de objeto de banco de dados Oracle não suportados

Os recursos específicos do Oracle geralmente podem ser substituídos pelos recursos do Azure Synapse. No entanto, alguns objetos de banco de dados Oracle não têm suporte direto no Azure Synapse. A lista a seguir de objetos de banco de dados Oracle sem suporte descreve como você 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 equivalente direto no Azure Synapse.

  Você pode descobrir quais colunas são indexadas e o tipo de índice da seguinte forma:

  • Consultando tabelas e exibições do catálogo do sistema, como ALL_INDEXES, DBA_INDEXES, USER_INDEXESe DBA_IND_COL. Você pode usar as consultas internas no Oracle SQL Developer, conforme mostrado na captura de tela a seguir.

    

    Ou, 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 visualizações ou v$object_usage quando o dba_index_usage monitoramento está habilitado. Você pode consultar essas exibições no Oracle SQL Developer, conforme mostrado na captura de tela a seguir.

    

  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 equivalente direto na Sinapse do Azure. Recomendamos que você primeiro migre os dados e, em seguida, no Azure Synapse, execute as consultas Oracle que usam índices baseados em função para avaliar 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 você configura o ambiente do Azure Synapse, faz sentido implementar apenas índices em uso. Atualmente, o Azure Synapse dá suporte aos tipos de índice mostrados aqui:

  

  Os recursos do Azure Synapse, como processamento de consultas paralelas e cache de dados e resultados na memória, tornam provável que menos índices sejam necessários para que os aplicativos de data warehouse atinjam as metas de desempenho. Recomendamos que você use os seguintes tipos de índice no Azure Synapse:

  • Índices columnstore clusterizados: quando nenhuma opção de índice é especificada para uma tabela, o Azure Synapse por padrão cria um índice columnstore clusterizado. As tabelas columnstore clusterizadas oferecem o mais alto nível de compactação de dados, melhor desempenho geral de consulta e, geralmente, superam as tabelas de índice ou heap clusterizadas. Um índice columnstore clusterizado geralmente é a melhor opção para tabelas grandes. Ao criar uma tabela, escolha columnstore clusterizado se não tiver certeza de como indexar sua tabela. No entanto, há alguns cenários em que os índices columnstore clusterizados não são a melhor opção:

    • As tabelas com dados de pré-classificação em uma ou mais chaves de classificação podem se beneficiar da eliminação de segmento habilitada por índices columnstore agrupados ordenados .
    • Tabelas com tipos de dados varchar(max), nvarchar(max) ou varbinary(max), porque um índice columnstore clusterizado não suporta esses tipos de dados. Em vez disso, considere o uso de um heap ou índice clusterizado.
    • Tabelas com dados transitórios, porque as tabelas columnstore podem ser menos eficientes do que as tabelas de pilha ou temporárias.
    • Tabelas pequenas com menos de 100 milhões de linhas. Em vez disso, considere o uso de tabelas de heap.

  • Índices columnstore clusterizados ordenados: ao permitir a eliminação eficiente de segmentos, os índices columnstore agrupados ordenados nos pools SQL dedicados do Azure Synapse fornecem um desempenho muito mais rápido ignorando grandes quantidades de dados ordenados que não correspondem ao predicado de consulta. O carregamento de dados em uma tabela CCI ordenada pode levar mais tempo do que uma tabela CCI não ordenada devido à operação de classificação de dados, no entanto, as consultas podem ser executadas mais rapidamente depois com a CCI ordenada. Para obter mais informações sobre índices columnstore agrupados ordenados, consulte Ajuste de desempenho com índice columnstore clusterizado ordenado.

  • Índices clusterizados e não clusterizados: os índices clusterizados podem superar os índices columnstore clusterizados quando uma única linha precisa ser recuperada rapidamente. Para consultas em que uma única pesquisa de linha, ou apenas algumas pesquisas de linha, devem ser executadas em velocidade extrema, considere o uso de um índice de cluster ou índice secundário não clusterizado. A desvantagem de usar um índice clusterizado é que apenas consultas com um filtro altamente seletivo na coluna de índice clusterizado serão beneficiadas. Para melhorar a filtragem em outras colunas, você pode adicionar um índice não clusterizado às outras colunas. No entanto, cada índice adicionado a uma tabela usa mais espaço e aumenta o tempo de processamento para carregar.

  • Tabelas de heap: quando você está temporariamente aterrissando dados no Azure Synapse, você pode descobrir que usar uma tabela de heap torna o processo geral mais rápido. Isso ocorre porque o carregamento de dados em tabelas de pilha é mais rápido do que o carregamento de dados em tabelas de índice e, em alguns casos, leituras subsequentes podem ser feitas a partir do cache. Se você estiver carregando dados apenas para prepará-los antes de executar mais transformações, é muito mais rápido carregá-los em uma tabela de pilha do que em uma tabela columnstore clusterizada. Além disso, carregar dados em uma tabela temporária é mais rápido do que carregar uma tabela para armazenamento permanente. Para pequenas tabelas de pesquisa com menos de 100 milhões de linhas, as tabelas de pilha geralmente são a escolha certa. As tabelas columnstore de cluster começam a atingir a compactação ideal quando contêm mais de 100 milhões de linhas.

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

  No Azure Synapse, você pode obter resultados semelhantes usando tabelas materializadas e/ou replicadas, porque esses tipos de tabela minimizam a E/S necessária no tempo de execução da consulta.

• Visualizações materializadas: a Oracle suporta exibições materializadas e recomenda o uso de uma ou mais para tabelas grandes com muitas colunas onde apenas algumas colunas são usadas regularmente em consultas. As visualizações materializadas são atualizadas automaticamente pelo sistema quando os dados na tabela base são atualizados.

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

• Gatilhos no banco de dados: no Oracle, um gatilho pode ser configurado para ser executado automaticamente quando ocorre um evento de acionamento. Os eventos desencadeadores podem ser:

  • Uma instrução DML (linguagem de manipulação de dados), como INSERT, UPDATEou DELETE, é executada em uma tabela. Se você definiu um gatilho que é acionado antes de uma INSERT instrução em uma tabela do cliente, o gatilho será acionado uma vez antes que uma nova linha seja inserida na tabela do cliente.

  • Uma instrução DDL, como CREATE ou ALTER, é executada. Esse gatilho é frequentemente usado para fins de auditoria para registrar alterações de esquema.

  • Um evento do sistema, como inicialização ou desligamento do banco de dados Oracle.

  • Um evento de usuário, como entrada ou saída.

  Você pode obter uma lista dos gatilhos definidos em um banco de dados Oracle consultando as ALL_TRIGGERSexibições , DBA_TRIGGERSou USER_TRIGGERS . A captura de tela a seguir mostra uma DBA_TRIGGERS consulta no Oracle SQL Developer.

  

  O Azure Synapse não oferece suporte a gatilhos de banco de dados Oracle. No entanto, você pode adicionar funcionalidade equivalente usando o Data Factory, embora isso exija que você refatore os processos que usam gatilhos.

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

  Atualmente, o Azure Synapse não oferece suporte à definição de sinônimos, embora se um sinônimo no Oracle se referir a uma tabela ou exibição, você poderá definir um modo de exibição no Azure Synapse para corresponder ao nome alternativo. Se um sinônimo em Oracle se refere a uma função ou procedimento armazenado, então no Azure Synapse você pode criar outra função ou procedimento armazenado, com um nome para corresponder ao sinônimo, que chama o destino.

• Tipos definidos pelo usuário: o Oracle suporta objetos definidos pelo usuário que podem conter uma série de campos individuais, cada um com sua própria definição e valores padrão. Esses objetos podem ser referenciados dentro de uma definição de tabela da mesma forma que os tipos de dados internos, como NUMBER ou VARCHAR. Você pode obter uma lista de tipos definidos pelo usuário em um banco de dados Oracle consultando as ALL_TYPESexibições , DBA_TYPESou USER_TYPES .

  Atualmente, o Azure Synapse não oferece suporte a tipos definidos pelo usuário. Se os dados que você precisa migrar incluírem tipos de dados definidos pelo usuário, "nivele-os" em uma definição de tabela convencional ou, se forem matrizes de dados, normalize-os em uma tabela separada.

Mapeamento de tipo de dados Oracle

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

O Oracle também oferece suporte à definição de objetos definidos pelo usuário que podem conter uma série de campos individuais, cada um com sua própria definição e valores padrão. Esses objetos podem ser referenciados dentro de uma definição de tabela da mesma forma que os tipos de dados internos como NUMBER ou VARCHAR. Atualmente, o Azure Synapse não oferece suporte a tipos definidos pelo usuário. Se os dados que você precisa migrar incluírem tipos de dados definidos pelo usuário, "nivele-os" em uma definição de tabela convencional ou, se forem matrizes de dados, normalize-os em uma tabela separada.

Fornecedores terceirizados 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 em uso no ambiente Oracle, use essa ferramenta para implementar quaisquer transformações de dados necessárias.

Diferenças de sintaxe do SQL DML

Existem diferenças de sintaxe do SQL DML entre o Oracle SQL e o Azure Synapse T-SQL. Essas diferenças são discutidas em detalhes em Minimizar problemas SQL para migrações Oracle. Em alguns casos, você pode automatizar a migração DML usando ferramentas da Microsoft, como SSMA para Oracle e Serviços de Migração de Banco de Dados do Azure, ou produtos e serviços de migração de terceiros .

Funções, procedimentos armazenados e sequências

Ao migrar um data warehouse de um ambiente maduro como o Oracle, você provavelmente precisará migrar elementos diferentes de tabelas e exibições simples. Verifique se as ferramentas no ambiente do Azure podem substituir a funcionalidade de funções, procedimentos armazenados e sequências, porque geralmente é mais eficiente usar ferramentas internas do Azure do que recodificá-las para o Azure Synapse.

Como parte da fase de preparação, crie um inventário de objetos que precisam ser migrados, defina um método para manipulá-los e aloque recursos apropriados em seu plano de migração.

Ferramentas da Microsoft, como SSMA para Oracle e Serviços de Migração de Banco de Dados do Azure, ou produtos e serviços de migração de terceiros , podem automatizar a migração de funções, procedimentos armazenados e sequências.

As seções a seguir discutem ainda mais a migração de funções, procedimentos armazenados e sequências.

Funções

Como acontece com a maioria dos produtos de banco de dados, o Oracle suporta funções definidas pelo sistema e pelo usuário dentro de uma implementação SQL. Quando você migra uma plataforma de banco de dados herdada para o Azure Synapse, as funções comuns do sistema geralmente podem 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. Você pode obter uma lista de funções em um banco de dados Oracle consultando a ALL_OBJECTS exibição com a cláusula apropriada WHERE . Você pode usar o Oracle SQL Developer para obter uma lista de funções, conforme mostrado na captura de tela a seguir.

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

Procedimentos armazenados

A maioria dos produtos de banco de dados modernos suporta procedimentos de armazenamento dentro do banco de dados. A Oracle fornece a linguagem PL/SQL para este fim. Um procedimento armazenado normalmente contém instruções SQL e lógica de procedimento e retorna dados ou um status. Você pode obter uma lista de procedimentos armazenados em um banco de dados Oracle consultando a ALL_OBJECTS exibição com a cláusula apropriada WHERE . Você pode usar o Oracle SQL Developer para obter uma lista de procedimentos armazenados, conforme mostrado na próxima captura de tela.

O Azure Synapse dá suporte a procedimentos armazenados usando T-SQL, portanto, você precisará recodificar quaisquer procedimentos armazenados migrados nesse idioma.

Sequências

Em Oracle, uma sequência é um objeto de banco de dados nomeado, criado usando CREATE SEQUENCE. Uma sequência fornece valores numéricos exclusivos através dos CURRVAL métodos e NEXTVAL . Você pode usar os números exclusivos gerados como valores de chave substituta para chaves primárias.

O Azure Synapse não implementa CREATE SEQUENCE, mas você pode implementar sequências usando colunas IDENTITY ou código SQL que gera o próximo número de sequência em uma série.

Extraindo metadados e dados de um ambiente Oracle

Geração de linguagem de definição de dados

O padrão 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 recursos específicos de implementação, como indexação, distribuição de tabela e opções de particionamento.

Você pode editar Oracle CREATE TABLE e CREATE VIEW scripts existentes para obter definições equivalentes no Azure Synapse. Para fazer isso, talvez seja necessário usar 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 exibição. Ao contrário da documentação mantida pelo usuário, as informações do catálogo do sistema estão sempre completas e sincronizadas com as definições de tabela atuais. Você pode acessar as informações do catálogo do sistema usando utilitários como o Oracle SQL Developer. O Oracle SQL Developer pode gerar CREATE TABLE instruções DDL que você pode editar para criar tabelas equivalentes no Azure Synapse.

Ou, você pode usar o SSMA for Oracle para migrar tabelas de um ambiente Oracle existente para o Azure Synapse. O SSMA para Oracle aplicará os mapeamentos de tipo de dados apropriados e os tipos de tabela e distribuição recomendados, conforme mostrado na captura de tela a seguir.

Você também pode usar ferramentas de migração e ETL de terceiros que processam informações do catálogo do sistema para obter resultados semelhantes.

Extração de dados do Oracle

Você pode extrair dados brutos de tabelas Oracle para arquivos delimitados simples, como arquivos CSV, usando utilitários Oracle padrão como Oracle SQL Developer, SQL*Plus e SCLcl. Em seguida, você pode compactar os arquivos delimitados simples usando gzip e carregar os arquivos compactados para o Armazenamento de Blobs do Azure usando AzCopy ou ferramentas de transporte de dados do Azure, como o Azure Data Box.

Extraia dados de tabelas da forma mais eficiente possível, especialmente ao migrar grandes tabelas de fatos. Para tabelas Oracle, use paralelismo para maximizar a taxa de transferência de extração. Você pode obter paralelismo executando vários processos que extraem individualmente segmentos discretos de dados ou usando ferramentas capazes de automatizar a extração paralela por meio do particionamento.

Se houver largura de banda de rede suficiente, você poderá extrair dados de um sistema Oracle local diretamente para tabelas do Azure Synapse ou para o Armazenamento de Dados de Blob do Azure. Para fazer isso, use os processos do Data Factory, o Serviço de Migração de Banco de Dados do Azure ou a migração de dados de terceiros ou produtos ETL.

Os arquivos de dados extraídos devem conter texto delimitado em formato CSV, Optimized Row Columnar (ORC) ou Parquet.

Para obter mais informações sobre como migrar dados e ETL de um ambiente Oracle, consulte Migração de dados, ETL e carga para migrações Oracle.

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

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

Semelhanças nos conceitos da abordagem de ajuste de desempenho

Muitos conceitos de ajuste de desempenho para bancos de dados Oracle são válidos para bancos de dados do Azure Synapse. Por exemplo:

• Use a distribuição de dados para colocar os dados a serem associados no mesmo nó de processamento.

• Use o menor tipo de dados para uma determinada coluna para economizar espaço de armazenamento e acelerar o processamento de consultas.

• Certifique-se de que as colunas a serem unidas tenham o mesmo tipo de dados para otimizar o processamento de junçã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 estejam atualizadas.

• Monitore o desempenho usando recursos internos de banco de dados para garantir que os recursos estejam sendo usados de forma eficiente.

Diferenças na abordagem de ajuste de desempenho

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

Opções de distribuição de dados

Para desempenho, o Azure Synapse foi projetado com arquitetura de vários nós e usa processamento paralelo. Para otimizar o desempenho da tabela no Azure Synapse, você pode definir uma opção de distribuição de dados em CREATE TABLE instruções usando a DISTRIBUTION instrução. Por exemplo, você pode especificar uma tabela distribuída por hash, que distribui linhas de tabela entre nós de computação usando uma função de hash determinística. Muitas implementações Oracle, especialmente sistemas locais mais antigos, não suportam esse recurso.

Ao contrário do Oracle, o Azure Synapse oferece suporte a junções locais entre uma tabela pequena e uma tabela grande por meio da replicação de tabela pequena. Por exemplo, considere uma tabela de dimensões pequenas e uma tabela de fatos grande dentro de um modelo de esquema em estrela. O Azure Synapse pode replicar a tabela de dimensão menor em todos os nós para garantir que o valor de qualquer chave de associação para a tabela grande tenha uma linha de dimensão correspondente disponível localmente. A sobrecarga de replicação de tabela de dimensão é relativamente baixa para uma tabela de dimensão pequena. Para tabelas de grandes dimensões, uma abordagem de distribuição de hash é mais apropriada. Para obter mais informações sobre opções de distribuição de dados, consulte Diretrizes de design para usar tabelas replicadas e Orientação para projetar tabelas distribuídas.

A distribuição de hash pode ser aplicada em várias colunas para uma distribuição mais uniforme da tabela base. A distribuição de várias colunas permitirá que você escolha até oito colunas para distribuição. Isso não só reduz a distorção de dados ao longo do tempo, mas também melhora o desempenho da consulta.

Consultor de Distribuição

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

O supervisor de distribuição é um novo recurso do Synapse SQL que analisa consultas e recomenda as melhores estratégias de distribuição de tabelas para melhorar o desempenho da consulta. As consultas a serem consideradas pelo orientador podem ser fornecidas por você ou retiradas de suas consultas históricas disponíveis no Detran.

Para obter detalhes e exemplos sobre como usar o supervisor de distribuição, visite Distribution Advisor no Azure Synapse SQL.

Indexação de dados

O Azure Synapse dá suporte a várias opções de indexação definidas pelo usuário que têm uma operação e uso diferentes em comparação com mapas de zona gerenciados pelo sistema no Oracle. Para obter mais informações sobre as diferentes opções de indexação no Azure Synapse, consulte Índices em tabelas de pool SQL dedicadas.

As definições de índice em um ambiente Oracle de origem fornecem uma indicação útil do uso de dados e das colunas candidatas para indexação no ambiente do Azure Synapse. Normalmente, você não precisará migrar todos os índices de um ambiente Oracle herdado porque o Azure Synapse não depende excessivamente de índices e implementa os seguintes recursos para obter um desempenho excecional:

• Processamento paralelo de consultas.

• Dados na memória e cache de conjuntos de resultados.

• Distribuição de dados, como replicação de tabelas de pequenas dimensões, para reduzir E/S.

Criação de partições de dados

Em um data warehouse corporativo, as tabelas de fatos podem conter bilhões de linhas. O particionamento otimiza a manutenção e a consulta dessas tabelas, dividindo-as em partes separadas para reduzir a quantidade de dados processados. No Azure Synapse, a CREATE TABLE instrução define a especificação de particionamento para uma tabela.

Você só pode usar um campo por tabela para particionamento. Esse campo é frequentemente um campo de data porque muitas consultas são filtradas por data ou um intervalo de datas. É possível alterar o particionamento de uma tabela após o carregamento inicial usando a CREATE TABLE AS instrução (CTAS) para recriar a tabela com uma nova distribuição. Para obter uma discussão detalhada sobre particionamento no Azure Synapse, consulte Particionamento de tabelas no pool 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 usando fluxos de carregamento paralelos. Para obter mais informações, consulte Estratégia de carregamento de dados do PolyBase.

COPY INTO também suporta ingestão de dados de alta taxa de transferência e:

• Recuperação de dados de todos os arquivos dentro de uma pasta e subpastas.
• Recuperação de dados de vários locais na mesma conta de armazenamento. Você pode especificar vários locais usando caminhos separados por vírgula.
• Azure Data Lake Storage (ADLS) e Azure Blob Storage.
• Formatos de arquivo CSV, PARAT e ORC.

Gestão de cargas de trabalho

A execução de cargas de trabalho mistas pode representar desafios de recursos em sistemas ocupados. Um esquema de gerenciamento de carga de trabalho bem-sucedido gerencia efetivamente os recursos, garante uma utilização altamente eficiente dos recursos e maximiza o retorno sobre o investimento (ROI). A classificação da carga de trabalho, a importância da carga de trabalho e o isolamento da carga de trabalho oferecem mais controle sobre como a carga de trabalho utiliza os recursos do sistema.

O guia de gerenciamento de carga de trabalho descreve as técnicas para analisar a carga de trabalho, gerenciar e monitorar a importância da carga de trabalho e as etapas para converter uma classe de recurso em um grupo de carga de trabalho. Use o portal do Azure e as consultas T-SQL em DMVs para monitorar a carga de trabalho e garantir que os recursos aplicáveis sejam utilizados de forma eficiente.

Próximos passos

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