• postgres-daily-check – SKILL de verificação diária de instâncias PostgreSQL
• polardb-daily-check – SKILL de verificação diária de instâncias PolarDB
• postgresql-bi-agent – SKILL de análise de dados de negócios para instâncias PostgreSQL

Desenvolvido com IA

Copie o diretório da SKILL desejada para o diretório especificado pelo Agente de IA para armazenamento de SKILLs.

Inicie uma solicitação de verificação, por exemplo, usando a SKILL postgres-daily-check:

Verifique completamente o banco de dados PostgreSQL:
host 127.0.0.1 port 1922 user digoal dbname postgres password 123456

🔍 RELATÓRIO ABRANGENTE DE VERIFICAÇÃO DO POSTGRESQL

• Verificação realizada em: 2026-02-05 14:00:00
• Conexão: 127.0.0.1:1922/postgres
• Status geral: 🟠 ATENÇÃO

Configurações críticas:

• fsync: on ✅
• synchronous_commit: on ✅
• log_min_duration_statement: -1 (log de consultas lentas desabilitado)
• log_lock_waits: off (log de espera de lock desabilitado)
• track_io_timing: off (métrica de I/O desabilitada)

🟠 Segurança das conexões:

• Sem SSL
• Sem GSSAPI
• 0 conexões locais
• ⚠️ 1 conexão sem criptografia (192.168.65.1)
  Sugestão: ativar SSL em produção

❌ Taxa de acerto do cache (grave): 56,44% (muito abaixo do recomendado >95%)

• Possível causa: muitos full scans ou shared_buffers subdimensionado
• Ação: aumentar shared_buffers, otimizar consultas, avaliar aumento de RAM

✅ Taxa de rollback: normal (<5%)

🟡 Tabelas mais quentes (hot tables):

🟠 I/O: 7 arquivos temporários (956 MB), track_io_timing desabilitado

🟠 Background Writer: maxwritten_clean elevado (13.996) – precisa de ajuste

🟡 WAL: 144 GB gerados; WAL buffers full = 434.597

🟠 Checkpointer:

• Média de escrita por checkpoint = 23.272 ms ⚠️ (alta)
• Sugestão: verificar desempenho de armazenamento ou ajustar parâmetros de checkpoint

✅ SLRU: taxa de acerto do transaction SLRU = 97,94% (normal)

• Tamanho do diretório WAL: 1.024 MB
• Sugestão: ativar archive_mode e archive_command se houver necessidade de recuperação point-in-time

🟡 Tamanho dos bancos: postgres = 3.611 MB, gemini_test = 8 MB, outros pequenos

🟡 Maiores objetos:

• Tabelas: pgbench_accounts (2.346 MB), pgbench_history (640 MB)
• Índices: pgbench_accounts_pkey (428 MB), pgbench_tellers_pkey (32 MB)

❌ Inchaço (bloat) de tabelas (grave):

• Total desperdiçado: ~2,4 GB

❌ Inchaço de índices (grave):

✅ Autovacuum: sem processos ativos no momento
✅ Índices grandes não utilizados: nenhum
✅ Estatísticas desatualizadas: nenhuma
✅ Risco de esgotamento de sequências: nenhum
✅ Previsão de freeze: nenhuma tabela próxima do limite

1. Inchaço extremo de tabelas e índices

   • pgbench_tellers e pgbench_branches com ~100% de inchaço
   • pgbench_accounts desperdiça 1,9 GB
   • Ação: VACUUM FULL e REINDEX imediatos

2. Taxa de acerto do cache muito baixa (56%)

   • Ação: aumentar shared_buffers (ex.: 25% da RAM física), otimizar consultas com full scans, considerar mais memória

• Background Writer – ajustar parâmetros (bgwriter_lru_maxpages, bgwriter_lru_multiplier)
• Checkpointer – verificar armazenamento, ajustar checkpoint_completion_target e max_wal_size
• Conexões sem criptografia – ativar SSL em produção

• Arquivamento WAL desabilitado – ativar se precisar de PITR
• Monitoração – definir log_min_duration_statement (ex.: 1s) e ativar track_io_timing

Problemas encontrados:

• 2 graves (inchaço + cache)
• 3 médios (bgwriter, checkpointer, SSL)
• 2 baixos (arquivamento WAL, monitoração)

Prioridades recomendadas:

1. 🔴 Executar VACUUM FULL e REINDEX
2. 🔴 Aumentar shared_buffers
3. 🟠 Ajustar parâmetros de bgwriter e checkpointer
4. 🟡 Ativar SSL e arquivamento WAL

Avaliação geral:
O banco de dados apresenta problemas significativos de inchaço de armazenamento e subdimensionamento de memória – manutenção corretiva é necessária com urgência.