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 possíveis desafios que foram encontrados durante uma migração do Oracle para o Azure para PostgreSQL. As soluções recomendadas podem ser úteis para superar esses desafios ao planejar e executar suas migrações.
Cenário: dois aplicativos cliente separados, de baixa latência e de alta taxa de transferência foram descobertos em funcionamento de forma independente no mesmo banco de dados. Cada aplicativo estava tirando inadvertidamente as consultas armazenadas em cache de buffers do outro. A carga compartilhada e a contenção combinada de recursos 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: verifique se suas avaliações iniciais estão capturando TODOS os aspectos do ambiente da plataforma de banco de dados, incluindo os padrões de consumo de memória e uso das estruturas de memória SGA (área global de sistemas) e PGA (área global do programa). Selecione a família apropriada de computação que corresponda aos requisitos de recurso e verifique se a capacidade planejada do Postgres é ajustada conforme necessário.
Dica
A extensão pg_buffercache fornece um meio para examinar o uso e permite que você observe o que está acontecendo no cache do buffer compartilhado em tempo real.
Índice de Ocorrências no Cache do Buffer
Examinar as taxas de ocorrência permite avaliar a eficácia do cache e determinar se o tamanho do buffer compartilhado é adequado. Uma boa taxa de ocorrência de cache é um sinal de que a maioria das solicitações de dados está sendo atendida da memória em vez do disco, fornecendo o 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 e índices acessados com mais frequência
Examinar quais tabelas e índices são acessados com mais frequência e/ou ocupar mais espaço no cache do buffer pode ajudar a identificar pontos de acesso 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 do cache do buffer
Uma contenção significativa no cache do buffer indica que várias consultas podem estar brigando pelo mesmo espaço do buffer, levando a gargalos de desempenho. Examinar a localização e a frequência do acesso ao buffer pode ajudar a diagnosticar esses 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 aplicados para atualizar a versão do banco de dados Postgres após a migração inicial, para 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 muito para aproveitar cada parte do desempenho e estabilidade em cada nova versão, e reter significa deixar o desempenho de lado. Além disso, aproveite ao máximo os novos recursos do Azure. Os novos recursos do Azure para PostgreSQL incluem: armazenamento SSDv2, a família mais recente de servidores de infraestrutura e ajuste automatizado de índice e recursos de ajuste de parâmetro de servidor autônomo.
Cenário: organizações que migram para o Postgres pela primeira vez podem não estar familiarizadas com as práticas recomendadas e abordagens ao identificar consultas de execução lenta. Cuidado e atenção especiais devem ser aplicados ao implementar novos tipos de índice de forma adequada. 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 que permitem garantir que seu banco de dados esteja operando no desempenho de pico. Algumas extensões principais a serem consideradas incluem:
auto_explain: registra automaticamente 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 com base em texto por meio da correspondência de trigram. Essa extensão é útil para tarefas que envolvem pesquisa de texto, correspondência difusa e consultas baseadas em similaridade. Combinada com índices GIN ou GIST em colunas de texto, oferece melhor desempenho em consultas LIKE e pesquisas de similaridade.
pg_cron: permite agendamento e gerenciamento de tarefas periódicas diretamente no banco de dados. Integra o agendamento de trabalho semelhante a cron no Postgres, permitindo a automação de tarefas de manutenção de rotina, processamento de dados e operações repetitivas semelhantes.
Dica
Se suas operações de banco de dados envolverem uma quantidade significativa de criação e exclusão repetidas de objetos de banco de dados, as tuplas de tabela do sistema pg_catalog mais antigas aumentarão, levando à sobrecarga de tabela. Como pg_catalog é uma tabela do sistema envolvida em muitas operações de banco de dados, a manutenção não mitigada nesta tabela pode resultar em um desempenho degradado em todo o banco de dados. Garantir que pg_catalog seja mantido e limpo de forma adequada pode ser garantido configurando um agendamento de pg_cron recorrente.
- pg_hint_plan: o Postgres visa 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 são necessários controles específicos e precisos sobre designs de plano de consulta, pg_hint_plan fornece uma maneira de influenciar as decisões do planejador de consultas usando dicas inseridas nos comentários do SQL. Essas dicas permitem que os administradores de banco de dados guiem o planejador de consultas para escolher planos específicos para otimizar consultas complexas ou resolver problemas de desempenho que o planejador pode não ser capaz de lidar por conta própria.
Observação
Esses exemplos são apenas superficiais do conjunto incrivelmente vasto de extensões disponíveis para seu banco de dados Postgres. Incentivamos 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 em que você vê o potencial de expandir o Postgres além de suas funcionalidades atuais. A arquitetura de extensão poderosamente flexível garante que o Postgres sempre seja capaz de se adaptar e evoluir com seus requisitos de plataforma.
Cenário: em alguns casos, 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 instâncias muito específicas, 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 da consulta real.
Solução recomendada: reavaliar 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 pode melhorar o desempenho. Se um esquema de particionamento herdado for avaliado e for determinado que seja necessário, considere reestruturar sua consulta em operações discretas para primeiro identificar e extrair chaves de partição dinâmicas e, em seguida, 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íbridos em que os bancos de dados Oracle e do Azure para PostgreSQL precisam coexistir. Por exemplo, pode haver ocasiões em que migrações em fases são necessárias para acessar e consultar dados do Oracle diretamente do Azure para PostgreSQL sem a sobrecarga de importar dados ou modificar processos complexos de ETL. Em outros casos, a execução de validação de dados paralela comparando conjuntos de dados equivalentes em ambientes do Oracle e do Azure para PostgreSQL simultaneamente pode ajudar a garantir a consistência e a integridade dos dados durante e/ou após a migração.
Solução recomendada: extensões FDW (Foreign Data Wrapper) do PostgreSQL são um recurso essencial do Postgres que permite acessar e manipular dados armazenados em sistemas externos como se esses dados residissem no banco de dados do Azure para PostgreSQL nativamente. Os FDWs permitem que o Azure para PostgreSQL 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. Os FDWs criam definições de tabelas estrangeiras 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 do Postgres usa a definição de 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 para PostgreSQL. Ao migrar do Oracle para o Azure para PostgreSQL, 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:
- Executar consultas por meio de 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 do servidor remoto do Oracle
- Alguns tipos de dados podem precisar de tratamento ou conversão especial para garantir que os tipos de dados sejam mapeados corretamente entre sistemas.
Usar efetivamente oracle_fdw pode ajudar a simplificar a transição de banco de dados e garantir a acessibilidade de dados, permitindo que seus aplicativos e dados permaneçam acessíveis durante todo o processo de migração geral.