Banco de Dados Tuning Um amigo estava me contando que a empresa onde trabalha trocou um dos seus servidores por

r uma mquina mais potente, com vrios gigabytes de memria e muitos processadores. O objetivo era fazer com que um determinado programa, considerado crtico pela empresa, fosse executado com mais performance, podendo assim atender melhor a demanda dos vrios departamentos que o acessavam. Mas infelizmente, esta atualizao tecnolgica (e o investimento financeiro que no foi modesto), no atingiram os objetivos esperados. Houve sim uma melhora na performance do programa mas ainda estava muito abaixo do esperado. Interessei-me pelo assunto e comecei a fazer algumas perguntas sobre como funcionava este programa, quem eram os usurios, quais tarefas eles realizavam dentro deste programa e como era feita a manuteno no banco de dados utilizado por este sistema; e como era de se esperar no existiam rotinas de monitoramento e manuteno do banco de dados. Se consultarmos o dicionrio, veremos que a palavra de origem inglesa tuning significa realizar ajustes ou afinaes, com o objetivo de ganhar mais potncia (automobilismo) ou obter mais desempenho (informtica). Mas como podemos afinar um banco de dados? Deixe-me explicar atravs de um exemplo prtico: Vejamos um sistema que realiza uma tarefa relativamente simples, que se resume em ler uma tabela e retornar somente os registros que estejam dentro de determinados critrios, como um intervalo de tempo especfico e de um tipo especfico de operao, retornando o resultado exibido em ordem alfabtica. Aps escrevermos o script SQL para realizar esta consulta, se analisarmos as tarefas que sero executadas pelo servidor para este script (isto chama-se Plano de Execuo), obtemos o resultado abaixo:
StmtText Estimate Rows Estimate IO Estimate CPU Avg RowSize Total SubtreeCost

SELECT [NOME],[... |--Sort(ORDER BY: |--Table Scan(...

494 494 494

NULL 0,01126126 0,1897917

NULL 0,006996084 0,0124946

NULL 114 114

0,2337785 0,2337785 0,2022863

A tabela acima mostra que: O banco de dados realizou a consulta em trs etapas; A primeira etapa foi ler e validar os comandos utilizados; A segunda etapa foi fazer uma classificao das informaes; A terceira etapa foi ler a tabela toda, e considerar somente os registros que atendem os critrios de data e tipo.

Para cada tarefa, tivemos um custo de processador (CPU) e disco (EstimateIO), e tivemos como resultado 494 linhas que tiveram um custo total de recursos de banco de 0,23.

Agora vejamos o que acontece com a mesma consulta, depois de fazermos um pequeno ajuste ou tuning nesta tabela: StmtText SELECT [NOME,[ |--Index Seek( Estimate Rows 494 494 Estimate IO NULL 0,008310185 Estimate CPU NULL 0,0007004 Avg RowSize NULL 114 Total SubtreeCost 0,009010585 0,009010585

Desta vez para obter as mesmas 494 linhas de resultado, o banco realizou somente duas etapas, sendo que a primeira foi para ler e validar os comandos utilizados, e a segunda foi fazer uma pesquisa de ndice. Um ndice em tabela tem o mesmo objetivo que o ndice de um livro, ele nos ajuda a encontrar uma informao de forma mais rpida, sem que tenhamos que procurar pelo livro inteiro. Aps o ajuste da tabela, obtemos um plano de execuo que foi quase 23 vezes mais rpido! Fazer tuning em banco isto, se baseia em uma atividade de investigao e ajustes, onde o DBA dever: identificar a estrutura do banco para entender como as informaes esto relacionadas, entender como os usurios utilizam o banco de dados, realizar os ajustes necessrios, monitorar os resultados.

Este trabalho deve ser realizado periodicamente, j que o comportamento dos aplicativos, banco de dados e at a forma como os usurios utilizam estes recursos, podem mudar com o tempo, causando pontos de gargalo e baixa performance. Com isto, consegui convencer meu amigo a buscar ajuda de um bom DBA e que fazendo o tuning do banco, eles tero o retorno de performance esperado.

Apertar o parafuso fcil, o difcil saber qual o parafuso correto.