.png)
Fala pessoal, o post de hoje é para ajudar quem esta começando na área ou deseja ser um profissional de banco de dados SQL Server em breve.
Todo começo tem suas dificuldades, por mais que você se sinta preparado, a falta de experiência pode te fazer cair em algumas situações simples, mas que podem te fazer cometer um erro ou se enganar em algum assunto.
Eu confesso, algumas dessas experiências eu já passei no inicio da minha jornada como DBA, e por isso estou fazendo esse post, para que você não passe pelas mesmas coisas mesmo sem ainda ter experiência na área.
Vamos a lista!
1- Tentar subir um backup em uma versão anterior do SQL. O backup não regride versão, o que isso quer dizer, se eu faço um backup de um banco de dados que esta na versão 2016(por exemplo), ele não vai restaurar nas versões 2014 para trás. Isso parece óbvio (porque as versões antigas não conterão metadados e recursos que a 2016 tem e por isso ele não permite restaurar), mas é um pensamento muito comum. Já presenciei vários casos onde o suporte foi solicitado e ao verificar estavam tentando subir um backup de um SQL atual em um mais antigo. Existe uma forma de se fazer isso, mas não é um backup/restore, você precisaria gerar os scripts dos objetos, para criar o banco no do zero no SQL mais antigo e depois fazer o mesmo com os dados, copiar por inserts(com um linked server) ou gerar os dados em scripts mesmo, mas isso pode ficar muito inviável dependendo do tamanho do banco de dados.
2- Compartilhar o servidor entre banco e aplicação, é claro que existem varias situações, aplicações pequenas, mas por padrão o SQL Server deve ficar em um servidor dedicado a ele, isso traz muitos benefícios na parte da performance e segurança, isolando o banco de dados o DBA pode evitar uma serie de problemas. Se você tem um servidor com 16GB de memória e nele tem o banco com 8GB alocado pra ele e tem também a aplicação consumindo uns 3GB e + 20 conexões TS, em algum momento essas sessões de TS e a aplicação, podem consumir mais memória e com isso diminuir o consumo do banco, prejudicando a performance, sem contar que os acessos TS no mesmo ambiente onde esta o banco é um risco enorme para os dados, a porta do TS precisa ficar aberta para as conexões, o risco é realmente muito alto. Não é difícil encontrar um ambiente assim hoje em dia. O DBA deve sempre orientar para que o banco fique separado.
3- Instalar o que não é necessário, quando é solicitada uma instalação de uma instância, chega um momento em que você precisa escolher quais recursos você deseja instalar, em muitos casos por desconhecimento, todos os recursos são selecionados e instalados, além de demorar mais tempo na instalação deixa também recursos que não serão usados consumindo memória, por exemplo, no servidor. Sempre pegue a lista do que é necessário e instale apenas o que a aplicação vai usar: instância, reporting service, analysis services...
4- Esse é um dos piores possíveis e na medida em que você vai ganhando confiança vai se tornando cada vez mais perigoso, é o famoso delete ou update sem where. O principal motivo é a falta de atenção e ela vem com a confiança, aos poucos vai deixando de lado as boas praticas, deixando de validar, de conferir e quando menos se espera acaba acontecendo e causando um grande problema. Não relaxe, mantenha sempre as boas praticas, confira antes de executar, rode primeiro em homologação, confira a rotina de backup se esta em ordem, se possível gere um backup da tabela com o SELECT INTO, só então pense em executar em produção se for necessário.
5- Executar backup full e quebrar a sequencia da política de backup, quando for necessário executar um backup full fora do agendamento padrão, observe como é a política estruturada, se existem backups de log por exemplo, caso sim, se você gerar um backup full, irá iniciar uma nova sequencia e isso pode causar um serio risco de segurança dos dados, fazendo com que todos os logs posteriores ao seu backup passem a depender dele e não mais do que foi gerado de forma programada. Para evitar isso, você pode gerar um backup com a opção "copy only", é o mesmo que um full(apenas o tamanho em alguns casos será maior que o backup full tradicional) porém, não quebra a sequencia.
O ponto é que todas essas situações requerem atenção e podem impactar diretamente no ambiente onde esta atuando. Tenha atenção, na duvida pergunte, assim você poderá sempre fazer o melhor trabalho evitando esses erros e confusões.
Agora que você aprendeu, compartilhe com o seu amigo que esta começando também, assim poderemos mudar esse cenário.
Nos acompanhe em nossas redes sociais!
Grupo VIP Telegram: DBA On boarding
Youtube(vídeos novos todas as quartas): https://www.youtube.com/channel/UChFeqc-m7HZNdkoP0CshMGQ
Face & Instagram(conteúdo diário): dba on boarding
Até a próxima, tchau!