“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
Além dos três fatores supracitados, existem outros diversos, porém não é a intenção ficar enumerando o que considero melhor ou pior em cada um dos meios de administração do SQL Server.
Na minha visão a relação existente entre um DBA por acidente e Linhas de código, é que normalmente DBAs por acidente não se preocupam em entender como a coisa funciona, e por isto, geralmente continuam a sempre fazer a mesma tarefa, da mesma maneira, enquanto aqueles que se propõe a ser excelentes profissionais, sempre estão correndo atras de entendimento e fugindo das limitações impostas (neste caso, falando sobre utilizar única e exclusivamente, Interface Gráfica).
Sinceramente, não tenho nada contra quem utiliza interface gráfica, desde que o faça por preferência, e não por limitação de não saber fazer de outra maneira. É fato que ninguém nasce sabendo, ou com Master degree em nada, mas nunca é tarde para começar a correr atras do prejuízo…
A intenção do texto realmente não foi em ser técnico, apenas externar algo que penso com relação ao assunto que se faz presente nos meios profissionais…
Grande Agraço…
View Comments (8)
Boa Garoto! Eu comecei como um DBA por acidente, era um desenvolvedor que precisava fazer umas querys mais elaboradas, umas SPs e etc e depois de um tempo fazendo isso resolvi ser DBA. Durante um bom tempo a interface amigável resolveu minha vida. Um dia mudei de emprego (já como DBA, e vc sabe aonde foi... hehehehehe) e descobri que não sabia nada. O SQL server tem muito mais a oferecer do que só click and go!
Aprender comandos, sintaxes e principalmente o porquê e para que usá-los é fundamental para um DBA. Costumo dizer que, agora, sou um DBA à moda antiga, porque prefiro mil vezes fazer via scripts do que na telinha, inclusive na minha primeira prova de certificação isso foi complicado. Havia uma questão que me mandava fazer algo que no script era uma linha, mas devia ser feito via tela... vixi... a cobra fumou. Finalmente entendi que é preciso balancear as coisas.
Agora que me "embrenhei" no mundo de Storage então?!?! Aí que descobri que o equilíbrio é fundamental.
Conhecer o que a ferramenta que você resolveu cuidar pode fazer é fundamental em qualquer área, e amplia bastante seus limites.
Apenas discordo um pouquinho do manow Logan no quesito mercado. No nosso último encontro inclusive falamos disso... o mercado é uma mãe! Tem vaga pra todo mundo, inclusive para o cara que acha que ser DBA é aplicar script e fazer backup via maintenance plans.
E aí Edvaldo!
Antes de qualquer coisa, parabéns pelo post! É um assunto que eu já ouvi várias vezes e acho que tenho uma visão um pouco diferente...
Da forma como você falou no segundo parágrafo, me enquadrei nessa questão do "DBA por acidente"... Afinal, comecei trabalhando com suporte técnico, estudava para MCSE (na época do Windows NT 4.0 ainda), me envolvi com o mundo Linux / Unix / Oracle / MySQL / etc e voltei pro ambiente MS, mas como analista de sistemas em uma empresa de desenvolvimento (ASP.NET, Delphi em Banco SQL Server).
Como sempre tive essa veia de infra-estrutura correndo, logo me grudei no SQL Server. Em pouco tempo, além das tarefas diárias como analista, assumi a infra da empresa como um todo e passei a me dedicar cada vez mais na organização e estruturação do banco (modelagem, backup, Mirroring, performance, etc).
Pode ser que seja exigência demais da minha parte (o que faz parte do meu perfil, felizmente), mas hoje, apesar do que tenho feito, de estar estudando (muito) e querendo "subir o nível do desafio", ainda não me vejo como um DBA 'as is', pois como o meu trabalho não é exclusivo com banco, sinto que tenho muito o que aprender e fazer para poder colocar essas 3 letras no meu currículo. Costumo brincar que eu as vezes ESTOU um DBA, mas não SOU um DBA ainda.
Como você falou, muitas pessoas começam como DBA por um acaso do destino mas, ao meu ver, isso não é de modo algum ruim. Ruim é quando alguém se acomoda e acha que por saber o básico (o feijão com arroz), já está bom. E acredito isso seja válido para todas as profissões, sem excessão. A evolução profissional passa obrigatoriamente pelo conhecimento, que quanto maior, melhor.
Particularmente, nao gosto de criar um estereótipo, como falar que um DBA por acidente é alguém que não se preocupa em saber como as coisas funcionam. Isso é apenas um mau profissional, que o próprio mercado dará um jeito de fazer com que ele se ajuste às necessidades ou com que ele procure outra área.
O importante, no final das contas, é não se acomodar nunca. Estudar sempre... Seja um "DBA por acidente" ou um "DBA desde o início".
Desculpa o tamanho do texto, mas não vi como falar de outra forma. :)
Grande abraço!
Olá Logan,
Primeiramente, muito obrigado pelo feedback e leitura do post...
Eu também, como a grande maioria, fui jogado no mundo de Banco de Dados... e rotulei-me como "DBA por acidente"...
A essência do texto (pelo menos a intenção), é relacionada aos profissionais que tem uma única e exclusiva função (neste caso, citei "DBAs por acidente"), aprendem a fazer o básico e se acomodam com essa situação... não buscando aprofundamento naquilo que fazem...
Existem diversos cenários e empresas, que não precisam que necessariamente tenha um ou mais profissionais exclusivamente dedicados à Administração do SGBD, nestes casos, concordo plenamente que ninguém precisa estudar e dedicar-se única e exclusivamente a uma das diversas funções às quais é atribuído...
Mas minha visão, é que alguém que tem uma função específica (DBA no caso), não deve acomodar-se em saber fazer o básico, é preciso sempre estudar, correr atras e sempre conseguir melhorar naquilo que faz...
Mas como citei logo acima no parágrafo anterior, este é apenas meu ponto de vista...
Mais uma vez muito obrigado pela leitura e comentário o post...
Abraços
Verdade!
So tenho uma coisa a dizer meu amigo :
Get-Edvaldo | Start-LoveHim
Parabens..otimo post
Valeu Laerte,
Vindo de você, isso é um super hyper mega feedback...
Abração
Concordo, e digo mais:
Acredito que ainda exista um certo preconceito com o SQL Server. Muita gente acha que é um banco que não precisa de manutenção. "Eu gosto de SQL Server! É um ótimo banco pra sisteminha de pequeno." (Já ouvi tais palavras!)
Oracle e DB2, por outro lado, são levados à sério desde o princípio. "São bancos de dados profissionais. Enterprise."
Aos poucos a visão vai mudando e tenho visto o SQL Server ganhando cada vez mais espaço. Torço (e trabalho) pra que continue assim. :)
Material é o que não falta pra quem tem interesse, e a comunidade de SQL Server é uma das mais ativas que conheço e das quais já participei.
Valeu pelo feedback e acréscimos Ivan...
Abraços