Automação autônoma de Database Reliability Engineering (DBRE) para migração e otimização de memória em instâncias Oracle Database (19c e 26ai), migrando de AMM (Automatic Memory Management) para ASMM (Automatic Shared Memory Management) em ambientes Linux com restrições de recursos (ex.: VMs de 4GB a 8GB).
Em instâncias Oracle com AMM (MEMORY_TARGET / MEMORY_MAX_TARGET > 0), a instância tenta gerenciar dinamicamente a alocação de memória entre a SGA (Shared Global Area) e a PGA (Program Global Area) a cada segundo.
- Contenção e Overhead de CPU: O daemon
MMON/MMNLe as chamadas do sistema para redimensionar granulações de SGA em tempo de execução consomem ciclos valiosos de CPU. - Incompatibilidade com HugePages / Linux
/dev/shm: O AMM requer POSIX Shared Memory (/dev/shm), impedindo a alocação de Linux HugePages (2MB/1GB), o que gera alto uso de espaço na página de tabelas do Kernel. - Swap Thrashing: A volatilidade da alocação de memória faz com que partes da SGA sejam descarregadas para a partição Swap do SO quando há picos de concorrência, gerando gargalo em I/O de disco.
- Risco de OOM Killer: Em máquinas virtuais com limitação de RAM (ex.: 4GB com instâncias 19c ou 26ai ativos), o rebalanceamento dinâmico do AMM frequentemente causa estouro de memória virtual e resulta no encerramento forçado do processo
pmonpelo OOM (Out-Of-Memory) Killer do Linux Kernel. - Toil Operacional: A necessidade recorrente de rodar scripts manuais via SSH, validar baselines ANTES/DEPOIS e registrar relatórios manualmente consome tempo dos engenheiros de banco de dados.
O projeto utiliza o Model Context Protocol (MCP) integrado ao Antigravity Agent Framework, utilizando agentic skills para orquestrar e executar o tuning de forma padronizada, segura e idempotente.
- Desativação do AMM:
MEMORY_TARGET = 0eMEMORY_MAX_TARGET = 0desativam o gerenciamento dinâmico via/dev/shm. - Fixação da SGA:
SGA_TARGET = 1000MeSGA_MAX_SIZE = 1000Mgarantem uma área compartilhada estável, de alta velocidade e previsível. - PGA Otimizada:
PGA_AGGREGATE_TARGET = 300Mdimensiona a memória por processo de forma eficiente. - Hard Cap de Segurança:
PGA_AGGREGATE_LIMIT = 2Gimpõe um limite máximo à PGA, prevenindo que sessões com vazamento de memória excedam a RAM do servidor e acionem o OOM Killer.
flowchart TD
A[1. Baseline Capture] -->|Salva Métricas SO & DB| B[2. Safety Backup]
B -->|CREATE PFILE FROM SPFILE| C[3. Parameter Tuning]
C -->|ALTER SYSTEM SCOPE=SPFILE| D[4. Safe Restart]
D -->|SHUTDOWN IMMEDIATE & STARTUP| E[5. Validation & Report]
E -->|Gera tuning_report_*.txt| F[Relatório em reports/]
O repositório está organizado segundo as melhores práticas de DBRE e infraestrutura como código:
Automacao_Tuning_Performance/
├── .gitignore # Regras de exclusão (*.env, *.log, *.tmp, *.swp, prechecks)
├── .skills/ # Antigravity / MCP Agent Skills
│ ├── oracle_memory_tuning.md # Skill com regras de execução CLI e gatilhos autônomos
│ └── senhas_seguras_gestao.md # Skill com políticas de senhas, segredos e mascaramento
├── docs/ # Documentação técnica e guias de referência
│ ├── POST_ORACLE_MEMORY_TUNING_REWRITTEN.md # Material comparativo para publicações técnicas
│ ├── PROMPT_Automacao_Oracle_Memory_Tuning.md # Especificação funcional e requisitos do prompt
│ ├── QUICK_START_MCP.md # Guia rápido de integração MCP
│ ├── README_CLI_Automation.md # Manual completo da CLI de automação
│ └── README_GITHUB.md # Versão complementar de documentação técnica
├── reports/ # Relatórios de execução gerados pela automação
│ └── tuning_report_*.txt # Logs e relatórios comparativos ANTES x DEPOIS
├── scripts/ # Scripts Bash de automação e orquestração (chmod +x)
│ ├── EXEMPLO_USO_COMPLETO.sh # Orquestrador lab (comparativo 26ai vs 19c)
│ ├── oracle_memory_tuning_26ai.sh # Script principal de migração AMM -> ASMM
│ └── oracle_memory_tuning_26ai_IMPROVED.sh# Script estendido com pré-validações avançadas
└── README.md # Documentação técnica mestre do repositório
- Conectividade SSH: Chave SSH pública configurada no host remoto (
ssh-copy-id oracle@<HOST>). - Usuário Oracle: Permissões de
SYSDBAe executávelsqlplusno PATH do servidor remoto. - Permissão de Execução: Scripts em
scripts/com permissão+x.
Para rodar o tuning em uma VM remota:
./scripts/oracle_memory_tuning_26ai.sh -h <HOST_IP> -u oracle -d <DB_NAME> [-o <ORACLE_HOME>]Exemplo:
./scripts/oracle_memory_tuning_26ai.sh -h 192.168.1.101 -u oracle -d ODB26AI-h HOST: Endereço IP ou Hostname da VM remota (obrigatório).-u USER: Usuário Linux para conexão SSH (padrão:oracle).-d DB_NAME: Nome da instância Oracle / SID (obrigatório, ex.:ODB26AI,ORCL19C).-o ORACLE_HOME: Caminho completo doORACLE_HOME(opcional, auto-detectado se omitido).
Para executar o tuning nas duas VMs de teste (26ai e 19c) e gerar o relatório comparativo consolidado:
./scripts/EXEMPLO_USO_COMPLETO.shValores coletados em teste real em VM de 4GB RAM (Oracle 26ai / 19c):
| Parâmetro / Métrica | ANTES (AMM) | DEPOIS (ASMM) | Impacto / Benefício |
|---|---|---|---|
| MEMORY_TARGET | 1906M (Dinâmico) |
0 (Desativado) |
Elimina rebalanceamento via /dev/shm |
| SGA_TARGET | Dynamic Auto | 1000M (Fixo) |
Memória compartilhada estável e rápida |
| PGA_AGGREGATE_TARGET | Dynamic Auto | 300M |
Alocação por processo sob demanda |
| PGA_AGGREGATE_LIMIT | Unlimited / Dynamic | 2G (Hard Cap) |
Impede runaway de memória e OOM Killer |
| RAM Usada no SO | ~2.4 GiB |
~1.9 GiB |
Redução imediata na pressão sobre o SO |
| Uso de Swap | 37 MB+ |
< 5 MB (Praticamente 0) |
Fim do Swap Thrashing e I/O contention |
| Comportamento | Oscilante / Risco OOM | Previsível / Estável | Alta disponibilidade e resistência a carga |
- Conforme detalhado em
.skills/senhas_seguras_gestao.md, nenhuma senha é armazenada em código ou exibida em logs. - A autenticação é realizada via chaves SSH protegidas e acesso local via OS Authentication (
/ as sysdba). - Arquivos
.env, logs de execução e arquivos de substituição de processo são ignorados via.gitignore.