Clique aqui para ler esse artigo em PDF.
Clique aqui para ler todos os artigos desta edição
Auto-sintonia em SGBDs: o fim do DBA?
Na era da informação, em que tecnologias, empresas e produtos surgem e desaparecem em poucos anos, as profissões relacionadas à computação também vêm sofrendo transformações. Vejamos o caso do Administrador de Bancos de Dados (DBA – DataBase Administrator): hoje, ele lida freqüentemente com bases distribuídas geograficamente, que atingem terabytes de dados e possibilitam a comunicação com milhares de usuários. Além disso, ele tem à sua disposição ferramentas cada vez mais sofisticadas para automatizar tarefas que antes só poderiam ser efetuadas manualmente.
Basicamente, o DBA tem duas incumbências: administrar o banco de dados e fazer ajustes de desempenho nele (sintonia ou ajuste fino). No primeiro caso, ele deve garantir que os dados se mantenham íntegros, consistentes e disponíveis. No segundo, ele deve realizar continuamente ajustes para agilizar ao máximo o acesso dos usuários.
Indubitavelmente, a segunda incumbência é responsável pelos piores (e também os melhores!) momentos na vida de um DBA. Não existe nada mais constrangedor do que uma ampulheta exibida indefinidamente após a requisição de alguns dados cujo retorno costumava ser célere. Por outro lado, não existe momento mais gratificante do que aquele em que se consegue realizar em apenas alguns instantes consultas outrora intermináveis.
Não faz muito tempo, esse tipo de descoberta dependia exclusivamente do DBA, que por sua vez só podia contar com a própria experiência e intuição. Entretanto, alguns SGBDs relacionais comerciais oferecem vários utilitários que ajudam o DBA a decidir sobre os ajustes a serem feitos, o que nos faz questionar até quando o DBA continuará a ser útil. Neste artigo, analisaremos algumas transformações ocorridas recentemente e seus impactos no dia-a-dia de um DBA.
Evolução dos SGBDs
Antes de apresentar as tendências para o novo campo de atuação de um DBA, veremos alguns avanços relacionados exclusivamente à evolução dos SGBDs (que provavelmente influenciarão essas tendências).
[ORACLE] Gerenciamento de Extents em Tablespaces:
• Antes: ao criar um segmento (tabelas, índices), o DBA deveria informar sua composição em áreas denominadas Extents. Era preciso definir as quantidades inicial e máxima, o tamanho do primeiro Extent e a taxa de crescimento.
Agora: não existe mais essa preocupação graças à facilidade denominada Gerência Local de Tablespaces, que automatiza essas decisões.
[ORACLE] Gerência de Segmentos de Rollback:
Antes: os segmentos de Rollback (áreas onde são armazenados os dados de transações que ainda não fizeram o commit) consistiam em constante fonte de preocupação para os DBAs e, não raras vezes, ocorriam erros causados pelo dimensionamento incorreto desses segmentos.
Agora: o Oracle 9i permite a completa automação da gerência de segmentos de Rollback por meio do SMU (System Managed Undo).
[ORACLE] Monitoramento:
Antes: o DBA realizava monitoramentos freqüentes e repetitivos, com pouco auxílio direto do SGBD.
Agora: a recém lançada versão 10g do Oracle oferece inúmeros advisories que enviam alertas ao DBA quando algo não vai bem. Variáveis monitoradas conferem o espaço em disco e detectam se a execução de consultas foi formulada corretamente. Isso permite que o DBA se concentre em tarefas mais nobres.
[SQL Server] Transferência de Login entre Servidores:
Antes: esse procedimento exigia bastante trabalho do DBA na versão 7, já que as senhas precisavam ser geradas manualmente se não fosse apropriado restaurar o Database Master (local onde são armazenadas as informações de segurança).
Agora: a funcionalidade do DTS (Data Transformation Services), ferramenta para integração de bases (heterogêneas ou não). Na versão 2000, há uma tarefa que transfere automaticamente Logins entre Servidores.
[SQL Server] Indexação:
Antes: a necessidade de criar índices era deduzida manualmente, observando-se os tempos de resposta longos ou analisando-se os planos de execução de comandos SQL.
Agora: a versão 7 introduziu o Index Tuning Wizard. A partir de um conjunto de acessos típicos a uma tabela ou conjunto de tabelas, são sugeridas criações de novos índices, ou a exclusão de índices pré-existentes.
Otimização de Consultas:
Antes: em vários SGBDs, para se realizar determinada consulta a uma base de dados volumosa era preciso fornecer algumas dicas de execução ao otimizador (denominadas
Table Hints).
Agora: na maioria dos casos, os otimizadores não precisam mais dessa ajuda. Além das melhorias introduzidas pelos fabricantes de SGBDRs, existem ainda algumas ferramentas de terceiros que também automatizam diversas tarefas cuja realização antes só era possível manualmente. Um exemplo é a família de produtos da Quest, mais especificamente o Quest Central, que faz a análise completa (plano de execução, recursos utilizados) da consulta e, caso identifique problemas em potencial, sugere mudanças.
Novo papel do DBA
Esses avanços são apenas alguns exemplos da sofisticação das ferramentas destinadas a apoiar as atividades do DBA. Pode-se então questionar: esses novos utilitários de auto-sintonia têm alguma limitação que justifique a presença de um DBA? Ou será que algum dia o DBA poderá ser totalmente substituído pela máquina?
Para responder a essas perguntas, basta observarmos algumas tarefas de administração e sintonia que dificilmente poderão ser totalmente automatizadas.
• Integração de fontes de dados heterogêneas.
• Realização de auditorias que avaliem a validade dos dados presentes na base;
• Construção de cenários que envolvam replicação de dados entre servidores;
• Nem todos os conselhos dados pelas ferramentas especialistas devem ser implementados, já que eles podem ter sido formulados com base em situações atípicas.
• Não há como automatizar a decisão de criar um índice para gerar um relatório imprescindível à reunião da diretoria que começará em poucas horas.
• Recuperações de dados após determinados tipos de falha, como disco corrompido, vírus ou sabotagem, entre outros;
• Elaboração, aplicação e acompanhamento de políticas para restringir o acesso aos dados, realizar cópias de segurança ou distribuir dados entre servidores geograficamente distantes, entre outras.
O surgimento de ferramentas que automatizam o trabalho outrora manual do DBA não se deve a uma sórdida campanha para transformá-lo em um profissional em extinção. Com o crescimento das bases de dados, o trabalho de administrá-las também se torna cada vez mais complexo, e o DBA atual não será capaz de cumprir sua missão se passar a maior parte do tempo realizando tarefas que poderiam ser (semi) automatizadas.
Um Caso Real
Para ilustrar a necessidade de adaptação do DBA à nova realidade, podemos citar a realização da sintonia fina em uma empresa que possui uma base de dados distribuída em dois SGBDs: Oracle (Contas a Pagar, Contas a Receber, Gestão etc.) e SQL Server (sistemas envolvidos com a atividade fim da empresa).
Existia um conjunto de tabelas armazenado na base Oracle que representava os títulos a serem cobrados e um processo encarregado de trazer os títulos desde o primeiro dia de 2002 e atualizar uma base semelhante no SQL Server. O trabalho era feito quatro vezes ao dia e cada execução consumia extensos recursos de máquina e de rede, já que durava cerca de uma hora no total e buscava quatrocentos mil registros. Infelizmente, desse montante apenas mil e quinhentos registros eram aproveitados em outras tarefas, tais como incluir novos títulos, alterar títulos existentes ou eliminar os que tinham sido excluídos na base de origem.
Após um estudo, descobriu-se a existência de tabelas de auditoria que registravam toda inclusão, alteração e exclusão de títulos na base Oracle. Esse fato permitiu reduzir a consulta que reunia os dados na origem de quatrocentos mil para cerca de dois mil registros! Com isso, o tempo de execução caiu consideravelmente, o que permitiu executar o processo com mais freqüência e manter os dados mais sincronizados.
No caso em questão, cabe ressaltar quão importante foi conhecer as regras de negócio da empresa. Foi importante também conhecer bem os dois SGBDs. Se fosse analisada apenas a rotina que alimentava a tabela de destino, jamais teria sido descoberto que, na verdade, a solução estava na origem! Trata-se de um caso típico de ajuste fino que dificilmente poderia ser automatizado.
Conclusão
Afinal, o cargo de DBA tem seus dias contados? Neste artigo argumentamos que não, pois muitas tarefas desempenhadas hoje pelo DBA (por exemplo: auditoria, integração de bases heterogêneas, tomadas de decisões) dificilmente poderão ser automatizadas. Entretanto, o DBA não pode acomodar-se em seus conhecimentos, ou correrá o risco de ficar desatualizado diante da crescente oferta de ferramentas de apoio e da complexidade cada vez maior das bases de dados sob sua responsabilidade. Se o profissional DBA for um profundo conhecedor dos dados e dos mecanismos que os regem, ele será um recurso ainda mais estratégico para as corporações.
