Administração e Operação de Banco¶

O que acontece depois de modelar e consultar: manter o banco seguro, disponível, rápido e recuperável. Consultas e modelagem em SQL e Modelagem de Dados; observabilidade geral em SRE.

Segurança do banco¶

Objetivo: confidencialidade, integridade e disponibilidade (ver tríade CIA em Segurança). Riscos: acesso indevido, exclusão acidental, vazamento e ataques.

flowchart LR
    A["Autenticação<br/>quem acessa"] --> B["Autorização<br/>o que pode fazer"]
    B --> C["Dados em trânsito<br/>TLS/SSL"]
    C --> D["Dados em repouso<br/>criptografia"]
    D --> E["Aplicação segura<br/>sem SQL injection"]
    E --> F["Auditoria<br/>registro de acessos"]

Camada	Prática
Autenticação	Senhas longas, únicas e protegidas; MFA quando possível; segredos fora do código e de repositórios; rotação de credenciais quando houver risco ou mudança de equipe; registrar falhas
Autorização	Cada usuário recebe apenas a permissão necessária (menor privilégio)
Dados em trânsito	Conexões com TLS/SSL; evite tráfego aberto
Dados em repouso	Criptografe discos, backups e dados sensíveis
Aplicação	Consultas parametrizadas; ver SQL injection
Atualizações	Mantenha o SGBD e as dependências corrigidos

Usuários, papéis e permissões¶

Usuário: identidade usada para conectar ao banco (leitor, editor, administrador, aplicação). Não use a mesma conta para todas as pessoas e sistemas.
Papel (role): agrupa permissões que podem ser atribuídas a vários usuários — facilita administrar permissões em equipes.
GRANT / REVOKE: concedem e removem permissões (SELECT, INSERT, UPDATE, DELETE, EXECUTE).

GRANT SELECT ON clientes TO leitor;
REVOKE SELECT ON clientes FROM leitor;

Cuidado: evite conceder acesso total às contas das aplicações; revise e remova acessos desnecessários.
Revisão de acessos: inventário periódico de usuários, papéis, serviços e contas técnicas; remova acessos antigos ou duplicados; evite contas compartilhadas; mantenha evidência de quem aprovou e revisou; repita após mudanças de equipe ou função.

Auditoria e logs¶

Registre usuário, ação, data/hora e resultado de eventos importantes (logins, falhas, alterações, exclusões). Ajuda a investigar erros e atividades suspeitas e permite alertas para falhas ou ações incomuns. Os próprios logs precisam de acesso controlado e retenção definida.

Privacidade e LGPD¶

Definição: LGPD

Lei Geral de Proteção de Dados (lei brasileira): estabelece regras para coletar, usar, guardar e compartilhar dados pessoais, para proteger a privacidade e dar transparência e controle às pessoas. As empresas respondem pelo tratamento, com finalidade clara, segurança e necessidade.

Tema	Resumo
Dado pessoal	Informação que identifica ou pode identificar alguém: nome, CPF, e-mail, telefone, endereço, localização, identificadores online
Dado sensível	Exige proteção maior: saúde, biometria, religião, origem racial; vazamento pode causar discriminação e impactos graves
Minimização	Colete e guarde apenas os campos necessários: menos dados, menos risco
Bases legais	Justificativas previstas em lei para tratar um dado: consentimento, contrato, obrigação legal, legítimo interesse (com avaliação de necessidade e respeito aos direitos da pessoa). Registre finalidade, base legal, responsável e dados envolvidos
Consentimento	Manifestação livre, informada e inequívoca para uma finalidade determinada; separado (não escondido em texto genérico), revogável com facilidade e comprovável: guarde data, versão do aviso, finalidade e ação realizada
Direitos do titular	Confirmação de tratamento, acesso, correção, eliminação (em alguns casos), portabilidade; crie canal de atendimento, valide e registre cada resposta
No banco	Permissões, criptografia, registros de acesso, políticas de retenção, máscara de dados em testes e monitoramento de consultas incomuns

Anonimização e pseudonimização¶

Anonimização: remove ou altera identificadores para reduzir a chance de reconhecer a pessoa (ex.: dados agregados e faixas de idade). Dados anonimizados não devem permitir identificação razoável.
Pseudonimização: substitui a identidade por um código, mas pode existir uma chave de reidentificação — por isso ainda exige proteção.
Cuidado: cruzar muitas fontes pode reidentificar pessoas; avalie o risco antes de divulgar.

Retenção de dados¶

Defina por quanto tempo cada dado deve permanecer armazenado: mantenha-o enquanto for necessário para o serviço, a obrigação ou a finalidade definida. Documente uma tabela de prazos (categoria, responsável, prazo, motivo e ação final), arquive dados pouco usados em armazenamento seguro e mais barato e, ao fim do prazo, exclua ou anonimize de forma verificável — incluindo backups, para que dados apagados não reapareçam sem controle. (Aplicação à engenharia de prompts em Engenharia de Prompt.)

Backup e recuperação¶

Backup: cópia dos dados para restaurar em caso de problema. Tipos: completo, incremental (só o que mudou desde o último backup) e diferencial (o que mudou desde o último completo).
Frequência: defina rotinas conforme a importância dos dados.
Boa prática: mantenha cópias em locais separados e seguros, criptografadas.
Um backup só é confiável quando a restauração é testada.

Simulado de restauração¶

Garanta que as cópias podem realmente recuperar o banco:

Restaure em ambiente isolado, para não afetar a produção.
Escolha o backup, restaure, aplique logs quando necessário e valide os dados.
Meça o tempo de recuperação e compare com o RTO definido; verifique se o ponto recuperado atende ao RPO e às necessidades do negócio.
Registre falhas do teste e ajuste o processo antes de um incidente real.

Definição: RTO e RPO

RTO (Recovery Time Objective): quanto tempo o serviço pode ficar parado. RPO (Recovery Point Objective): quanto de dado se pode perder (tempo entre o último ponto recuperável e a falha).

Disponibilidade e escala¶

Replicação¶

Mantém cópias sincronizadas do banco. O principal recebe as escritas e distribui as alterações; a réplica mantém uma cópia para leitura ou contingência. Ajuda a escalar leituras e a melhorar a disponibilidade. Atenção: a réplica pode ficar alguns instantes atrás do principal, e replicação não substitui backup (um erro ou exclusão também é replicado). Monitore a sincronização e tenha plano de recuperação.

Alta disponibilidade e failover¶

Definição: Alta disponibilidade

Arquitetura que reduz ao máximo as paradas do banco, mantendo o sistema no ar mesmo quando um servidor falha. Baseia-se em redundância (mais de uma máquina, réplicas, caminhos alternativos) e monitoramento que detecta queda, lentidão, disco cheio e erros. Mede-se com uptime, RTO e RPO.

Failover é a troca do serviço para um servidor de reserva após falha no principal: o monitor detecta a falha → promove a réplica → a aplicação reconecta → o serviço continua. Pode ser automático (menos indisponibilidade) ou manual (útil quando é preciso investigar antes). Pré-requisitos: réplicas atualizadas, monitoramento confiável e plano de reconexão. Cuidado com o split-brain: dois servidores atuando como principal ao mesmo tempo.

Particionamento¶

Divide uma tabela em partes menores (partições); para o usuário, continua parecendo uma tabela. Melhora consultas, manutenção e organização com milhões de registros.

Por faixa: por intervalos (pedidos de 2024, 2025, 2026) — ótimo para datas.
Por lista: por categorias definidas (estado, país, tipo de cliente).
Benefícios: menos dados para ler; exclusão rápida de dados antigos; backups mais fáceis.
Cuidado: escolha a chave certa; particionar tabelas pequenas só adiciona complexidade.

Sharding¶

Definição: Sharding

Divide os dados entre vários bancos independentes (shards, em servidores diferentes), permitindo crescer além da capacidade de um único servidor. Uma chave de shard decide onde cada registro fica (por cliente, região ou faixa de ID — ex.: clientes A–M em um servidor, N–Z em outro).

Vantagens: mais espaço, mais desempenho e escala horizontal. Desafios: consultas entre shards, reequilíbrio e consistência ficam mais complexos.

Pool de conexões¶

Abrir uma conexão nova a cada requisição consome tempo e recursos do banco. O pool mantém conexões prontas e reutilizáveis: a aplicação pega uma, executa a consulta e a devolve. Benefícios: menor latência, menor custo e mais estabilidade em picos. Limite o tamanho máximo para não sobrecarregar o banco, sempre devolva a conexão e configure timeout e monitoramento de conexões ociosas.

Cache¶

Camada rápida em memória com dados consultados com frequência: evita repetir consultas caras e reduz a carga no banco. Cache hit: o dado está lá (resposta rápida). Cache miss: busca no banco e salva para a próxima. Defina o TTL (por quanto tempo o dado vale) e invalide ou atualize o cache após mudanças — dados desatualizados causam erros. Detalhes em Spring — Cache.

Monitoramento e manutenção¶

Monitoramento e observabilidade¶

Acompanhe consultas lentas, conexões abertas, CPU, memória, disco e espaço disponível, com painéis de tendências e alertas para erros, lentidão e falta de espaço. Resolva a causa, não só o sintoma. A observabilidade combina métricas (CPU, memória, conexões, latência, erros), logs (falhas, consultas lentas, autenticações), traces (o caminho de uma requisição entre aplicação, serviços e banco), dashboards e alertas com contexto, limite e gravidade — para reduzir ruído e acelerar a resposta.

Health check¶

Verificação rápida da saúde do banco: a aplicação consegue conectar e executar uma consulta simples; recursos (CPU, memória, disco, conexões abertas, tamanho do pool); desempenho (tempo de resposta, consultas lentas, bloqueios); replicação (atraso das réplicas, status de sincronização); backup (último backup válido e resultado do teste de restauração). Transforme falhas em alertas claros com procedimentos de correção.

Manutenção contínua¶

Tarefa	Detalhe
Atualizações	Versão do banco, extensões e correções de segurança
Índices	Revise índices sem uso, duplicados e os que faltam nas consultas mais importantes
Estatísticas	Atualize as informações usadas pelo otimizador para escolher bons planos de execução
Espaço	Monitore disco, crescimento de tabelas, logs e arquivos temporários
Backup	Verifique execução, retenção, criptografia e restauração
Rotina	Defina calendário, responsáveis e evidências de cada tarefa executada

Planejamento de capacidade¶

Meça o uso atual (armazenamento, CPU, memória, conexões, tráfego), projete o crescimento (usuários, dados, picos, novas funcionalidades), defina limites e alertas antes de disco cheio ou conexões esgotadas, planeje quando escalar (aumentar recursos, usar réplicas, particionar ou distribuir), compare custo x desempenho e revise o plano regularmente com dados reais.

Arquivamento de dados¶

Dados antigos, pouco acessados e ainda necessários por regra ou histórico devem sair das tabelas ativas para reduzir volume e custo: use tabela histórica, banco separado ou armazenamento de longo prazo; documente como localizar e recuperar os dados arquivados; mantenha permissões, criptografia, retenção e auditoria; valide contagens e integridade antes de remover da base ativa.

Plano de manutenção do banco¶

Um plano de manutenção é o conjunto de tarefas agendadas que mantém o banco íntegro, rápido e disponível, construído sobre a estratégia de backup e restauração. Itens típicos:

Tarefa	Para quê	Frequência típica
Backup completo, diferencial e de logs	Permitir restauração até um ponto no tempo (veja RTO/RPO em Backup e recuperação)	Completo semanal/diário; diferencial e logs frequentes
Teste de restauração	Backup não testado não existe	Periódico
Verificação de integridade (`DBCC CHECKDB`, `ANALYZE`/`VACUUM`, `fsck`)	Detectar corrupção cedo	Semanal
Reorganizar/reconstruir índices	Combater fragmentação	Semanal/mensal
Atualizar estatísticas	O otimizador escolhe bons planos (Tuning de SQL)	Diária/semanal
Limpeza (histórico, logs antigos, dados expirados)	Controlar o espaço	Periódica
Monitorar espaço, desempenho e alertas	Agir antes do problema (Monitoramento)	Contínuo

Ferramentas: assistentes dos próprios SGBDs (por exemplo, o Maintenance Plan Wizard do SQL Server), jobs agendados (SQL Server Agent, cron, pg_cron, Oracle Scheduler) e scripts versionados. Dica: escolha janelas de baixo uso, registre os resultados e envie notificações de falha.

Evolução do banco: versionamento, migrações e testes¶

Controle de versão: scripts de estrutura, dados iniciais e migrações ficam registrados em histórico, junto com o código. Garante rastreabilidade (quem alterou, quando e por quê), revisão antes de produção, mesmas versões em desenvolvimento, teste e produção e resolução de conflitos entre alterações.
Migrações: arquivos/scripts que registram mudanças no banco de forma ordenada (criar tabela, adicionar coluna, criar índice, alterar restrição), cada uma com uma versão. Faça mudanças pequenas, claras e compatíveis; teste antes de produção e tenha plano de retorno. Ferramentas e exemplo em Spring — Flyway.
Testes do banco: estrutura (tabelas, colunas, tipos, chaves, índices, restrições), integridade (chaves estrangeiras e regras impedem dados inválidos), consultas (filtros, JOINs, cálculos), transações (operações relacionadas terminam juntas ou são desfeitas) e automação a cada mudança de código ou migração.
Dados de teste: crie cenários realistas com dados fictícios (nomes, pedidos, produtos, datas, valores inventados e variados), incluindo casos de borda (campos vazios, limites máximos, duplicidades, dados inválidos) e volume próximo ao de produção. Não copie dados reais sem proteção — principalmente dados pessoais.
Teste de carga: simula vários usuários, conexões ou requisições ao mesmo tempo para achar lentidão, limites de conexão, gargalos e falhas antes do uso real. Cenários: horários de pico, relatórios pesados, importações e muitas escritas; acompanhe tempo de resposta, CPU, memória, disco e consultas lentas e repita após mudanças importantes.
Documentação: catálogo (propósito de cada tabela, coluna, índice e relacionamento), dicionário de dados (tipo, formato, significado, exemplo e origem), regras (validações, cálculos, status permitidos), diagrama (DER) e atualização junto com cada mudança de estrutura.

Banco na nuvem¶

Tema	Resumo
Banco na nuvem	Hospedado na infraestrutura de um provedor e acessado pela internet; escala recursos rapidamente, sem comprar ou manter servidores físicos; flexível (aumenta armazenamento e capacidade conforme cresce); disponibilidade com zonas, réplicas e backups; segurança com controle de identidades, rede, chaves e criptografia
Banco gerenciado	O provedor administra tarefas comuns (atualizações, backups, monitoramento básico, infraestrutura); a sua equipe continua cuidando do modelo de dados, permissões, consultas, custos e qualidade; ganha tempo para o produto. Cuidado: entenda limites, preços, backup, recuperação e como exportar seus dados (lock-in)
Custos	Monitore armazenamento, CPU, memória, conexões e custo por ambiente; dimensione conforme a carga (evite pagar por capacidade ociosa); arquive dados antigos; use índices, consultas eficientes e cache; automatize alertas; revise planos, backups, réplicas e ambientes de teste

Modelos de contratação de nuvem em Nuvem.

Migração de banco¶

Planeje: mapeie tabelas, dados, dependências, volume e tempo de parada aceitável.
Backup: faça cópia testada antes de iniciar — backup sem restauração testada não basta.
Teste em ambiente de homologação e valide dados e desempenho.
Compatibilidade: verifique tipos de dados, SQL, funções, índices e permissões no novo banco.
Corte: defina a janela, sincronize as alterações finais e tenha plano de retorno.
Validação: compare contagens, amostras, relatórios e logs após a migração.

Resposta a incidentes¶

flowchart LR
    A["Detecção"] --> B["Triagem"]
    B --> C["Contenção"]
    C --> D["Comunicação"]
    D --> E["Recuperação"]
    E --> F["Aprendizado<br/>(pós-mortem)"]

Detecção: alertas, usuários ou logs indicam erro, lentidão, queda ou perda de dados.
Triagem: entenda impacto, sistemas afetados, urgência e causa inicial.
Contenção: reduza o dano — bloqueie a ação problemática, ative réplica ou limite o tráfego.
Comunicação: avise responsáveis e partes afetadas com informações claras e atualizações.
Recuperação: restaure o serviço com ações seguras, testadas e registradas.
Aprendizado: após o incidente, revise causa, impacto e melhorias necessárias.

Severidade e escalonamento: classifique pelo impacto no usuário, nos dados e na receita. Crítico: serviço indisponível, risco de perda de dados ou segurança comprometida. Alto: função importante degradada, mas há alternativa temporária. Moderado: erro limitado, sem impacto amplo e com correção planejável. Escalonamento: acione a pessoa ou equipe certa conforme o nível e o tempo de resposta — prioridades claras evitam caos.

Pós-mortem (post-mortem): análise feita após um incidente para entender o que aconteceu e evitar repetição: linha do tempo (detecção, ações, decisões, recuperação, comunicação), causa raiz (a origem, não só o sintoma visível), impacto (usuários afetados, tempo de parada, dados envolvidos, custo) e ações de melhoria com responsável, prazo e acompanhamento. Adote o formato sem culpa (blameless): foque no processo e no sistema; o objetivo é aprender e melhorar.

Runbook: guia prático com procedimentos para tarefas comuns e incidentes recorrentes — pré-requisitos, comandos, validações, riscos e plano de retorno; passos curtos, objetivos e seguros para quem está sob pressão. Exemplos: restaurar backup, aumentar capacidade, lidar com conexões cheias, promover réplica. Teste-o periodicamente e revise-o após mudanças no banco ou lições de incidentes.

Checklist de produção¶

Área	Itens
Backup	Backup recente, retenção correta e restauração testada
Migrações	Revisar scripts, testar em ambiente seguro e preparar plano de retorno
Segurança	Validar usuários, permissões, senhas, chaves e acessos de rede
Desempenho	Checar índices, consultas críticas, pool de conexões e capacidade
Monitoramento	Configurar alertas, logs, métricas e responsáveis por incidentes
Aprovação	Publicar com janela definida, comunicação e validação após o deploy

Boas práticas essenciais¶

Modele antes: defina entidades, regras e relacionamentos antes do SQL.
Nomeie bem: nomes claros e padronizados para tabelas e colunas.
Valide dados: tipos, NOT NULL, UNIQUE, CHECK e chaves estrangeiras.
Use índices para acelerar filtros e joins; monitore índices desnecessários.
Faça backup: automatize cópias e teste a restauração regularmente.
Documente: modelo, decisões, regras e mudanças do banco.

Projeto prático: sistema de vendas¶

Um exercício que reúne tudo: entidades (clientes, produtos, pedidos, itens, pagamentos), relacionamentos (cliente faz pedidos; pedido possui vários itens), regras (estoque não pode ficar negativo; preço deve ser maior que zero), tabelas (PKs, FKs, tipos corretos e restrições), consultas (vendas por período, produto mais vendido, ticket médio) e evolução (versione migrations, crie índices e mantenha backups).

A jornada¶

Entenda (dados, tabelas, linhas, colunas, chaves) → Modele (entidades, atributos, relacionamentos) → Consulte (SQL, filtros, joins, agregações, subconsultas) → Proteja (acessos, entradas, auditoria, backup) → Otimize (índices, monitoramento, capacidade) → Evolua (documente, teste, versione e aplique no próximo projeto).