"DBA por acidente"
Começo o texto de hoje falando um pouco deste que é um termo muito comum em rodas de conversas de DBAs e profissionais que se dedicam a fazer bem feito e com excelência aquilo que se propõe a fazer, neste caso mais especificamente falando, ser um DBA cada vez melhor... Abro aqui um parêntese para indicação de leitura - "How to become an exceptional DBA"
O "DBA por acidente", as vezes nem mesmo sabe que é um DBA, a ele são atribuídas atividades de um DBA em paralelo às suas obrigações e quando menos se dá conta, já está atuando única e exclusivamente com a Administração do SGBD (Aqui, leia-se SQL Server).
Pelo fato de o SQL Server, diferente da maioria dos demais SGBDs, ter uma interface amigável e bastante intuitiva, muitos dos DBAs do tipo supracitado, ao executarem tarefas cotidianas e relativamente simples do dia-a-dia (tais como: backup, restore, criação de base nova, etc), simplesmente se acomodam e deixam de buscar conhecimento e entendimento a fundo do funcionamento da ferramenta, de possíveis problemas e soluções para poder atuar de forma mais rápida e efetiva.
Em outros SGBDs, como por exemplo: Oracle e DB2, a administração da ferramenta geralmente é de certa forma mais complexa e requer maior conhecimentos das particularidades destas, e talvez por este motivo, seja muito mais comum a existência de "DBAs por acidente" no mundo SQL Server.
Ainda que o Microsoft SQL Server ofereça uma interface super amigável e fácil de trabalhar, uma boa forma de se livrar das armadilhas do vício na interface gráfica que "facilita" muito a vida do DBA, é começar a olhar como as coisas funcionam em background. Por exemplo, ao executar um backup simples de uma base de dados via SSMS (SQL Server Management Studio), porque não gerar um script da execução deste backup e das próximas vezes que se for executar um backup simples, fazê-lo via T-SQL apenas alterando o script previamente gerado? Com o tempo, naturalmente este comando de backup será memorizado e não haverá mais a necessidade da dependência da interface para execução desta atividade...
Um dos pontos, é o conhecimento dos códigos gerados por tras de cada instrução submetida via interface gráfica, mas o estudo e conhecimento daquilo que se faz (neste caso, Administrar Banco de Dados (SQL Server)), vai muito além disto. Neste post, estou dando ênfase à utilização de códigos nas atividades do dia-a-dia de um DBA, pois acredito ser este um grande passo para se deixar o rótulo de "DBA por acidente" para se tornar um profissional cada vez melhor e saber exatamente aquilo que se está fazendo...
Posso citar inúmeras vantagens, na utilização de códigos de comando ao invés de interfaces gráficas, mas em minha opinião, destacam-se os seguintes fatores:
- Produtividade: Particularmente depois que se adquire prática, é muito mais rápido criar um usuário, executar um backup ou restore via T-SQL do que efetuar diversos cliques na tela, para realizar estas tarefas.
- Escalabilidade: Para fazer uma operação de backup/restore, pode ser pequena a diferença de tempo gasto usando tanto interface quanto T-SQL, porém tente fazer uma operação destas com dezenas ou até mesmo centenas de bases (e acredite, existem muitos cenários para isto).
- Flexibilidade: Se você é um DBA que usa única e exclusivamente a interface gráfica do SSMS e mal sabe como as coisas acontecem nos códigos executados por suas "telinhas", é bem possível que suas mãos ficarão literalmente atadas caso você se depare com um servidor onde o SQL Server esteja devidamente instalado, mas não haja o SSMS. Caso você não seja totalmente dependente da ferramenta gráfica, você poderá (em casos extremos) trabalhar normalmente conectando-se via SQLCMD