Em quais áreas do conhecimento de um DBA um desenvolvedor deve se aprofundar? [fechadas]

Devo admitir que a pergunta é bastante ampla, então vou tentar reduzi-la um pouco. Em nossa empresa, somos de 3 a 4 desenvolvedores e temos algumas instalações baseadas em SQL Server em execução nos sites de nossos clientes (tamanhos de banco de dados de até 100 GB, até 100 usuários simultâneos, aplicativos de intranet). Ninguém de nós tem uma boa experiência real na execução / manutenção / administração de bancos de dados (o que seja). Os clientes nem tanto. Está funcionando bem até agora, mas não posso dizer com certeza se é porque estamos fazendo tudo certo ou se simplesmente não atingimos áreas / situações em que não somos proficientes.

Então, estou procurando as coisas essenciais que você precisa saber ao executar um banco de dados do ponto de vista de um DBA . Você conhece os fatos concretos e sabe o que mais importa no seu dia-a-dia.

Em quais assuntos devo reunir um conhecimento mais profundo, sobre o que devo ter ouvido e com o que devo me preocupar até enfrentar pela primeira vez?

Estou ciente da questão Engenheiros de software e DBAs , mas não é exatamente o que eu estava procurando. Também existem muitos livros, mas eu gostaria de ouvi-lo daqueles com experiência prática.

Estou inclinado a concordar com o @Catcall, a recuperação do banco de dados deve estar no topo da lista. As implicações das opções de backup e recuperação são geralmente as mais mal compreendidas fora de uma equipe de DBA e as mais prováveis ​​de resultar em desastre.

• Verifique se você definiu e concordou (por gerenciamento técnico e não técnico) RPO (Recovery Point Objective) e RTO (Recovery Time Objective) para todos os bancos de dados e sistemas.
• Documente os procedimentos de backup e recuperação na medida em que possam ser seguidos por uma equipe não técnica.
• Assegure-se de que toda a documentação seja mantida em formato impresso e eletrônico, tanto dentro como fora do local. Um runbook de recuperação de desastre armazenado na rede local não será muito útil se os prédios pegarem fogo.
• Teste todos os aspectos dos procedimentos de recuperação, com frequência. Os backups são irrelevantes, é isso que restaura.

Em seguida, de uma perspectiva independente de banco de dados, é uma compreensão do que um servidor de banco de dados é criado para fazer; forneça Atomicidade, Consistência, Isolamento e Durabilidade às suas transações e dados. Geralmente incompreendido, freqüentemente a causa de problemas de desempenho e a principal fonte de inconsistência dos dados.

Para a sua plataforma escolhida, entre em detalhes sobre como a conformidade com o ACID é implementada. Procure tópicos como o que o log de transações faz, o que é o write-ahead-log , os níveis de isolamento e os internos de armazenamento . A compreensão dos principais aspectos internos do banco de dados facilita muito a compreensão de outros aspectos do trabalho do DBA, ajuste de desempenho e gerenciamento de recursos.

As duas coisas com as quais lido todos os dias.

1. Recuperação de desastres.

2. Ajuste de desempenho. (Tanto para consultas individuais quanto para os dbms em si.)

Seu plano de recuperação de desastre precisa ser

• com script,
• testado e
• praticado.

Estou usando scripts no sentido de algo que um ator seguiria, não algo escrito em Python. Deve dizer a todos que precisam se envolver exatamente o que fazer. (E muitas vezes, exatamente o que dizer também.)

O ajuste de desempenho para consultas inclui o entendimento de chaves, índices e normalização. (Geralmente, os problemas de "ajuste" são na verdade problemas estruturais.)