Práticas recomendadas para migrações do Oracle para o banco de dados do Azure para PostgreSQL
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
Os cenários a seguir descrevem alguns dos desafios potenciais encontrados durante uma migração do Oracle para o Azure Postgres. As soluções recomendadas podem ser úteis para superar esses desafios ao planejar e executar sua(s) própria(s) migração(ões).
Cenário: Dois aplicativos cliente separados, de baixa latência e alta taxa de transferência foram descobertos independentemente operando no mesmo banco de dados. Cada aplicativo estava inadvertidamente retirando as consultas em cache do outro dos buffers. A carga compartilhada e a contenção de recursos combinados criaram uma situação em que os buffers compartilhados do banco de dados estavam sendo liberados com muita frequência, resultando em desempenho degradado em ambos os sistemas.
Solução recomendada: Certifique-se de que suas avaliações iniciais estejam capturando TODOS os aspetos do ambiente da plataforma de banco de dados, incluindo o consumo de memória e os padrões de utilização das estruturas de memória de área global (SGA) e área global do programa (PGA) dos sistemas. Selecione a família de computação apropriada que corresponda aos seus requisitos de recursos e certifique-se de que sua capacidade planejada do Postgres seja ajustada conforme necessário.
Gorjeta
A extensão pg_buffercache fornece um meio para examinar a utilização e permite observar o que está acontecendo no cache de buffer compartilhado em tempo real.
Taxa de acertos do cache de buffer
Examinar as taxas de acertos permite avaliar a eficácia do cache e determinar se o tamanho do buffer compartilhado é apropriado. Uma boa taxa de acertos do cache é um sinal de que a maioria das solicitações de dados está sendo atendida a partir da memória em vez do disco, proporcionando um desempenho ideal:
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
Tabelas acessadas com mais freqüência & índices
Examinar quais tabelas e índices são acessados com mais frequência e/ou ocupam mais espaço no cache do buffer pode ajudar a identificar pontos críticos que estão sendo armazenados em cache na memória:
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
Contenção de cache de buffer
Uma contenção significativa no cache do buffer indica que várias consultas podem estar lutando pelo mesmo espaço de buffer, levando a gargalos de desempenho. Examinar a localização e a frequência do acesso ao buffer pode ajudar no diagnóstico de tais problemas:
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
Cenário: Um esforço de migração foi iniciado entre e abrangendo versões dos ciclos de lançamento da plataforma Postgres. Apesar de novos recursos e melhorias estarem disponíveis na versão mais recente, a versão selecionada no início da migração permaneceu inalterada. Esforço, tempo e despesas adicionais subsequentes foram exercidos para atualizar a versão do banco de dados Postgres após a migração inicial, a fim de alcançar o desempenho ideal e novos recursos.
Solução recomendada: Sempre que possível, priorize a adoção da versão mais recente do Postgres ao migrar. As equipes de desenvolvimento da comunidade Postgres trabalham incrivelmente duro para espremer cada pedaço de desempenho e estabilidade em cada nova versão, e segurar essencialmente se traduz em deixar o desempenho de lado. Além disso, aproveite ao máximo os novos recursos do Azure. Os novos recursos do Azure Postgres incluem: armazenamento SSDv2, a mais recente família de servidores de infraestrutura e recursos automatizados de ajuste de índice e ajuste de parâmetros de servidor autônomo.
Cenário: As organizações que migram para o Postgres pela primeira vez podem não estar familiarizadas com as práticas e abordagens recomendadas ao identificar consultas de execução lenta. Deve ter-se especial cuidado e atenção ao implementar adequadamente novos tipos de índices. Notavelmente, o mecanismo de banco de dados Postgres foi projetado para otimizar o desempenho da consulta sem a necessidade ou a capacidade de especificar dicas de consulta.
Solução recomendada: As extensões são parte integrante do que torna o Postgres tão poderoso. Há várias extensões que podem fornecer recursos importantes, permitindo que você garanta que seu banco de dados esteja operando com desempenho máximo. Algumas das principais extensões a considerar incluem:
auto_explain: registra automaticamente os planos de execução para consultas que são executadas além de um limite definido. Permite que os administradores de banco de dados diagnostiquem problemas de desempenho e otimizem o desempenho da consulta sem executar manualmente EXPLAIN em cada consulta.
pg_trgm: fornece funções e operadores para determinar a semelhança de dados baseados em texto por meio de correspondência de trigramas. Esta extensão é útil para tarefas que envolvem pesquisa de texto, correspondência difusa e consultas baseadas em similaridade. Combinado com índices GIN ou GIST em colunas de texto oferece melhor desempenho em consultas LIKE e pesquisas de similaridade.
pg_cron: Permite o agendamento e gerenciamento de tarefas periódicas diretamente no banco de dados. Integra o agendamento de tarefas semelhante ao cron no Postgres, permitindo a automação de tarefas de manutenção de rotina, processamento de dados e operações repetitivas semelhantes.
Gorjeta
Se as operações do banco de dados envolverem uma quantidade significativa de criação e exclusão repetidas de objetos de banco de dados, as tuplas mais antigas da tabela do sistema pg_catalog aumentarão, levando ao "inchaço" da tabela. Como pg_catalog é uma tabela do sistema envolvida em muitas operações de banco de dados, a manutenção não atenuada nessa tabela pode resultar em desempenho degradado em todo o banco de dados. Garantir que pg_catalog seja adequadamente mantido e aspirado adequadamente pode ser assegurado através da configuração de um cronograma de pg_cron recorrente.
- pg_hint_plan: O Postgres tem como objetivo fornecer um desempenho consistente e confiável sem a necessidade de intervenção manual, resultando na decisão intencional de design de não incluir dicas de consulta. Para alguns cenários em que é necessário um controle específico e preciso sobre os designs de plano de consulta, pg_hint_plan fornece uma maneira de influenciar as decisões do planejador de consultas usando dicas incorporadas em comentários SQL. Essas dicas permitem que os administradores de banco de dados orientem o planejador de consultas a escolher planos específicos para otimizar consultas complexas ou resolver problemas de desempenho que o planejador pode não ser capaz de lidar sozinho.
Nota
Esses exemplos estão apenas arranhando a superfície do incrivelmente vasto conjunto de extensões disponíveis para seu banco de dados Postgres. Nós encorajamos você a explorar totalmente essas extensões para turbinar seu banco de dados Postgres. Além disso, você pode considerar a possibilidade de criar suas próprias extensões onde você vê o potencial de expandir o Postgres além de seus recursos atuais. A arquitetura de extensão poderosamente flexível garante que o Postgres sempre será capaz de se adaptar e evoluir com os requisitos da sua plataforma.
Cenário: Em alguns casos, as estratégias de partição de tabela herdada resultaram na criação de milhares de partições. Embora isso possa ter sido eficaz quando usado anteriormente, essas estratégias podem diminuir o desempenho da consulta no Postgres em determinadas circunstâncias. Em casos muito específicos, o planejador de consultas pode não conseguir determinar a chave de partição apropriada ao analisar a consulta. O comportamento resultante gera um tempo de planejamento estendido e faz com que o planejamento da consulta demore mais do que a execução real da consulta.
Solução recomendada: Reavalie a necessidade de estratégias de particionamento gerando um número excessivamente grande de partições. O mecanismo de banco de dados Postgres pode não exigir mais a mesma segmentação de dados e reduzir o número de partições provavelmente melhorará o desempenho. Se um esquema de particionamento herdado for avaliado e for determinado que é necessário, considere reestruturar sua consulta em operações discretas para primeiro identificar e extrair chaves de partição dinâmicas e, posteriormente, usar as chaves de partição em suas operações de consulta.
Cenário: Às vezes, dependências externas e circunstâncias ambientais podem exigir cenários de banco de dados híbrido em que os bancos de dados Oracle e Azure Postgres precisam coexistir. Por exemplo, pode haver ocasiões em que migrações em fases sejam necessárias para acessar e consultar dados Oracle diretamente do Azure Postgres sem a sobrecarga de importar dados ou modificar processos ETL complexos. Em outros casos, executar a validação paralela de dados comparando conjuntos de dados equivalentes em ambientes Oracle e Azure Postgres simultaneamente pode ajudar a garantir a consistência e a integridade dos dados durante e/ou após a migração.
Solução recomendada: As extensões FDW (Foreign Data Wrapper) do PostgreSQL são um recurso chave do Postgres que permite acessar e manipular dados armazenados em sistemas externos como se esses dados residissem nativamente no banco de dados do Azure Postgres. Os FDWs permitem que o Azure Postgres funcione como um banco de dados federado, permitindo a integração com qualquer número de fontes de dados externas, incluindo bancos de dados Oracle. FDWs criam definições de tabela estrangeira em seu banco de dados Postgres e essas tabelas estrangeiras atuam como um proxy para sua fonte de dados externa definida, permitindo que os usuários consultem essas tabelas estrangeiras usando consultas SQL regulares. Internamente, o mecanismo Postgres usa a definição FDW externa para se comunicar e coordenar dados sob demanda da fonte de dados remota.
oracle_fdw: (Foreign Data Wrapper for Oracle) é uma extensão do Postgres que permite acessar bancos de dados Oracle de dentro do Azure Postgres. Ao migrar do Oracle para o Azure Postgres, oracle_fdw pode desempenhar um papel crucial fornecendo acesso a dados, validação de dados, migração incremental e sincronização de dados em tempo real. É importante ter em mente as seguintes considerações principais ao usar FDWs:
- A execução de consultas através do oracle_fdw incorrerá em sobrecarga na forma de comunicações de rede e negociação de autenticação enquanto os dados são processados e buscados no servidor Oracle remoto
- Alguns tipos de dados podem precisar de manipulação ou conversão especial para garantir que os tipos de dados sejam mapeados corretamente entre os sistemas.
O uso eficaz de oracle_fdw pode potencialmente ajudar a simplificar a transição do banco de dados e garantir a acessibilidade dos dados, permitindo que seus aplicativos e dados permaneçam acessíveis durante todo o processo geral de migração.