Dr. Hasan Dalmaz
Administrador de Banco de Dados Sênior · Oracle & PostgreSQL
DBAtlas — o atlas de operações para DBAs
Equivalências de comandos em 7 bancos de dados, soluções de erros, árvores de decisão e playbooks passo a passo — tudo o que um DBA precisa durante um incidente, em um só lugar.
- comandos
- 1.480+
- comandos
- soluções de erros
- 426
- soluções de erros
- árvores de decisão
- 40
- árvores de decisão
- bancos de dados
- 7
- bancos de dados
DBAs usaram hoje
CONSOLE DE BANCOS DE DADOS
Um passeio rápido pelo mundo dos bancos de dados
Passe o cursor sobre um banco de dados ou conceito — veja sua diferença principal, ponto forte, ressalva e onde se encaixa.
› SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;
- ▸ CHAVE
- Com RAC, vários servidores executam o mesmo banco de dados em conjunto; se um falhar, o sistema continua no ar.
- ✓ PONTO FORTE
- A opção corporativa mais madura para disponibilidade contínua e recuperação de desastres (Data Guard).
- ⚠ RESSALVA
- Alto custo de licenciamento e exige especialização; excessivo para projetos pequenos.
- → IDEAL PARA
- Grandes sistemas corporativos que não toleram indisponibilidade: bancos, ERP.
› CREATE EXTENSION vector;
- ▸ CHAVE
- Código aberto; seus recursos podem ser ampliados com extensões — como dados de mapas ou busca vetorial para IA.
- ✓ PONTO FORTE
- Gratuito, poderoso e baseado em padrões; atende desde registros simples até consultas complexas.
- ⚠ RESSALVA
- Sistemas com muitos updates/deletes precisam de manutenção e tuning regulares de VACUUM.
- → IDEAL PARA
- Backends de apps web e mobile, mapas (GIS) e projetos de IA.
› CREATE AVAILABILITY GROUP ag_prod;
- ▸ CHAVE
- O banco de dados da Microsoft; integra-se perfeitamente ao universo Windows/.NET e traz ferramentas robustas (SSMS).
- ✓ PONTO FORTE
- Lida bem com transações do dia a dia e com relatórios/análises em um único sistema.
- ⚠ RESSALVA
- Funciona melhor no Windows; a licença da edição Enterprise é cara.
- → IDEAL PARA
- Aplicações corporativas .NET e sistemas de business intelligence/relatórios.
› START REPLICA;
- ▸ CHAVE
- O banco de dados mais popular da web; fácil de instalar e usar, com uma comunidade enorme.
- ✓ PONTO FORTE
- Leve e rápido; escala com facilidade, principalmente em sites com muita leitura.
- ⚠ RESSALVA
- Não é tão completo quanto Oracle/PostgreSQL para análises muito complexas e consultas avançadas.
- → IDEAL PARA
- Sites como WordPress e apps web de alto tráfego com muita leitura.
› db.orders.find({ status: "paid" })
- ▸ CHAVE
- Armazena os dados como “documentos” flexíveis (semelhantes a JSON) em vez de tabelas; não exige esquema rígido.
- ✓ PONTO FORTE
- Permite desenvolvimento rápido, lida bem com dados grandes e que mudam com frequência e escala horizontalmente com facilidade (sharding).
- ⚠ RESSALVA
- Um design ruim pode causar duplicação e inconsistência; não é a primeira opção quando se exige integridade relacional rigorosa.
- → IDEAL PARA
- Catálogos, gestão de conteúdo e apps com estruturas que mudam com frequência.
› SET session:42 online EX 3600
- ▸ CHAVE
- Mantém os dados na memória (RAM) em vez do disco, por isso responde quase instantaneamente.
- ✓ PONTO FORTE
- Extremamente rápido; perfeito para cache, sessões e contadores em tempo real.
- ⚠ RESSALVA
- Os dados precisam caber na RAM e a persistência precisa estar bem configurada; caso contrário, pode haver perda de dados.
- → IDEAL PARA
- Cache, armazenamento de sessões, rankings e qualquer cenário em que a velocidade importa.
› GET /products/_search?q=laptop
- ▸ CHAVE
- Um mecanismo feito para busca textual; seu índice invertido pesquisa milhões de documentos e ordena os resultados por relevância.
- ✓ PONTO FORTE
- Busca muito rápida, autocompletar e logs/análises (ELK stack); escala horizontalmente com facilidade.
- ⚠ RESSALVA
- Não é um banco de dados principal; normalmente funciona ao lado do banco principal como camada de busca/logs.
- → IDEAL PARA
- Busca em sites e de produtos, análise de logs e observabilidade.
› SELECT * FROM orders JOIN users USING (id);
- ▸ CHAVE
- Mantém os dados organizados em tabelas relacionadas e os consulta com SQL; um modelo comprovado ao longo de décadas.
- ✓ PONTO FORTE
- Consistência forte: uma transação acontece por completo ou não acontece (ACID). Muito poderoso para consultas complexas.
- ⚠ RESSALVA
- Difícil de distribuir entre muitas máquinas (sharding); alterar o esquema depois exige planejamento cuidadoso.
- → IDEAL PARA
- Dinheiro, estoque e qualquer sistema em que a exatidão seja crítica.
› { "user": "hd", "roles": ["dba"] }
- ▸ CHAVE
- Usa estruturas flexíveis em vez de tabelas rígidas (documento, chave-valor…); feito para grande escala.
- ✓ PONTO FORTE
- Distribui-se facilmente entre muitas máquinas e suporta bem cargas pesadas de escrita.
- ⚠ RESSALVA
- Geralmente não oferece as garantias de consistência forte do SQL nem junções de tabelas (JOIN).
- → IDEAL PARA
- Web em grande escala, análises em tempo real e dados de estrutura flexível.
› BEGIN; UPDATE acct SET bal = bal - 100; COMMIT;
- ▸ CHAVE
- Duas filosofias de consistência: ACID garante que toda transação seja concluída por inteiro; BASE flexibiliza isso em favor de velocidade e disponibilidade.
- ✓ PONTO FORTE
- ACID dá confiabilidade a dados críticos como dinheiro; BASE permite escala massiva e acesso constante.
- ⚠ RESSALVA
- Com BASE, os dados podem ficar brevemente “desatualizados”; a aplicação precisa levar isso em conta.
- → IDEAL PARA
- ACID: sistemas de pagamento. BASE: feeds de redes sociais, contagem de curtidas.
› -- OLTP: point writes · OLAP: aggregate scans
- ▸ CHAVE
- Dois tipos de carga: OLTP são muitas transações pequenas do dia a dia (pedidos, pagamentos); OLAP é análise sobre grandes volumes de dados.
- ✓ PONTO FORTE
- A separação certa acelera os dois: um cuida do trabalho diário, o outro dos relatórios.
- ⚠ RESSALVA
- Rodar os dois no mesmo sistema deixa ambos mais lentos, por isso costumam ser separados.
- → IDEAL PARA
- OLTP: pedidos/pagamentos. OLAP: relatórios, dashboards e data warehouses.
Contato
Tem alguma dúvida? Deixe uma mensagem.