Hoje recebi um e-mail de alguém me perguntando porque os testes dele com o pgbench variam tanto, mesmo usando os mesmos parâmetros todas as veses. Para quem não sabe o pgbench é um pequeno aplicativo que lhe ajuda a fazer medições de perfomance no banco de dados simulando um teste TPC-B. Ele é muito simples de se utilizar e permite realizar testes com diferentes volumes de dados, conexões simultâneas e transações por conexão. O pgbench NÃO SERVE para fazer tuning em servidores de produção, mas serve para ajudar medir a diferença entre diferentes hardwares, SOs, sistemas de arquivo, etc. No mínimo, com o pgbench você vai começar a aprender muito sobre performance no PostgreSQL, comparando seus resultados em diferentes cenários.

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Veja, eu respeito o SGDB Oracle. Ele não apenas é um dos primeiros bancos de dados relacionais do mercado como também é robusto, confiável e possui uma miríade de recursos. Mas convenhamos, para um SGDB que está a tempos no mercado, algumas coisas são realmente incríveis. É claro que existem algumas explicações que dizem respeito a história de como o produto surgiu e muitas que tem mais haver com a estratégia de marketing da Oracle.

• A Oracle possui uma enorme documentação. Toda ela está disponível on-line para qualquer um baixar. O mesmo acontece com os softwares (não as atualizações, claro). Uma das coisas que eu aprecio na documentação da Oracle, são as suas recomendações quanto as melhores práticas. Algumas delas são específicas em relação ao seu produto, mas muito do que está lá se aplica a qualquer banco de dados. Dito isso, me explique: qual o motivo de tantos produtos da Oracle não seguirem as suas próprias recomendações. Você não acredita? Quem conhece as restrições das aplicações feitas em FORMS sabe do que eu estou falando. Agora imagine um ERP inteiro sem uma FK (chave estrangeira). Isso mesmo… o famoso ERP da Oracle não tem nenhuma. Alguém me explica isso?
• Eu falei bem da documentação da Oracle, não? Pois é, os caras fazem um bom trabalho nela. Mas tem um problema. Algumas coisas misteriosamente não estão lá. É quase inacreditável que eles esqueçam de documentar coisas tão importantes na documentação. Realmente não faz nenhum sentido. Vou lhes dizer que não é pouca coisa.
• Mais um detalhe bizarro sobre a documentação da Oracle. Você já olhou o manual de instalação deles? Bom, eles tem uma lista de dependências que devem ser instaladas para que você não falhe miseravelmente no meio do caminho. No entanto há algumas coisas bizarras lá. Eu nunca entendi o que o gnome-libs, o xscreensaver e o control-center fazem na lista de dependências. São completamente inúteis. Você definitivamente não precisa delas no seu servidor, mesmo que você queira usar o instalador gráfico. Ainda assim, se você cair na besteira de ler a documentação que acompanha os CDs do Oracle, ou a documentação que vem junto com os binários que você baixa no site, você pode encontrar sérios problemas no caminho. Algumas dependências simplesmente não estão descritas nesta versão da documentação, como você poderia esperar. Não esqueça, sempre olhas os “Release Notes” na documentação on-line. Particularmente, se você for fazer uma instalação em Linx com 64 bits, você me agradecerá muito por esta dica. Isto acontece porquê o instalador do Oracle de 64 bits roda em 32 bits. Surpresa, as dependências de 32 bits não estão na documentação original.
• Sim, o famoso processo de instalação do banco de dados está longe de ser um processo simples. Eu realmente não conheci o Oracle nas suas versões mais antigas. Só conheço ele a partir da versão 8. Não tenho nada contra as zilhões de recomendações de acertos no SO antes da instalação. Na verdade, isso é até bem bacana. Uso muito destas recomendações com outros SGDBs. Mas o instalador gráfico deles é simplesmente horrível. Porquê? É muito simples… ele força você a instalar a interface gráfica no seu servidor. Para os usuários do Windows, tudo bem, mas no mundo Unix isto é uma heresia. Para complicar ainda mais… o instalador é feito em Java e pesa uma tonelada. Fazer um instalador em modo texto não seria tão complexo assim. Não é que seja impossível fazer a instalação em modo texto. Claro que é possível. Mas você tem de criar um arquivo enorme de configurações que pode ser um inferno de editar, conforme forem as suas necessidades. Eu mesmo já criei alguns scripts para me ajudar a criar os arquivos de isntalação em modo texto. Daí para criar um instalador em modo texto seria realmente um pulo. Convenhamos que esta não seria uma tarefa árdua para a Oracle.
• O SQL*Plus número um dos DBAs Oracle. É claro que surgiram coisas mais amigáveis como o SQL Developer, mas o SQL*Plus é a única ferramenta em modo texto que você tem para utilizar. Eu realmente gosto muito das interfaces gráficas. Mas na hora do aperto elas não me servem muito. Quando preciso rodar uma rotina pesada ela também não me ajuda muito. E principalmente, quando quero fazer algum script rápido que acesse o SGDB, o SQL*Plus é uma mão na roda. Mas há um detalhe muito bizarro nele. Ele não tem suporte a biblioteca mais manjada das ferramentas em linha de comando: a ReadLine. Sem ela ou outra substituta a altura, voltamos para a idade do bit lascado. Até as setas do seu teclado perdem a utilidade. É realmente lastimável a perda de produtividade que este detalhe nos proporciona no dia a dia. Para quem está acostumado com o Bash, isto é simplesmente irritante.
• O metalink é a porta de entrada para um universo a parte da Oracle. Patches de segurança, zilhões de documentos sobre erros bizarros, uma maravilha. Só tem um problema. Parece que a Oracle usou seus próprios produtos para criar o seu site. E vou lhes dizer uma coisa… eles parecem que nunca utilizaram o gmail na vida. Definitivamente nunca ouviram falar em AJAX. Para completar, ainda usam FLASH para montar um site lento, feito e com uma péssima usabilidade. Depois que você se acostuma com o jeito tosco do site, até dá para se virar bem, a não ser é claro, que você esteja com um pepino enorme na mão e a sua conexão com a Internet esteja lenta. Se for esse o seu caso, vou lhe dizer qual é a forma de rezolver seus problemas de forma mais rápida, interativa e eficiente: entre no servidor de IRC da freenodes na sala #oracle. Você vai descobrir que o “suporte livre” realmente funciona.
• O padrão SQL já vai completar 20 anos em 2009. Ele surgiu em sua primeira versão oficial em 1989. Ficou famoso pela versão de 1992, e depois contou com mais duas grandes versões sendo a última em 2003. É verdade que a moral da ISO anda meio baixa nos últimos tempos. Mesmo assim, não há motivos para a Oracle ser tão lenta na adoção dos padrões. O tipo de dado TIMESTAMP surgiu apenas na versão 9i. O tratamento com os nulos, o nvarchar, a ausência do tipo inteiro e outras coisas estranhas do Oracle lhe garantem não conformidades significativas com o padrão SQL.
• A Oracle tem uma tara por arquivos binários que nenhum ser usuário possa ler. A coisa não se limita aos dispositivos crús (Raw Devices), vai dos backups com RMAN, ao rastreamento de erros com trace. Enfim, o negócio é confiar na Oracle…

Você não concorda com as minhas observações? Diria que tem outros itens para acrescentar a lista? Coloque nos comentários então!

É fato:

• O Linux historicamente escala melhor do que o FreeBSD;
• O PostgreSQL historicamente escala melhor que o MySQL;

Digam o que quiserem, todos os testes conduzidos por pessoas sérias parecem concordar com estas duas afirmações. Para quem não sabe, “escalar” significa aumentar de performance proporcionalmente ao número de CPUs existentes no equipamento.

Mas o tempo passa, e como prometido, a versão 7.0 do FreeBSD parece ter cumprido a promessa de melhorar o escalonador de processos. O resultado você observa aqui. Os testes podem não ser 100% fidedignos ao representar uma situação real com banco de dados, mas os números parecem ser bastante promissores.

Parabéns a equipe de desenvolvimento do FreeBSD… certamente vocês vão ganhar novos DBAs como usuários.

OBS: Os testes foram realizados com até 8 cores, não há informações para um número maior de processadores.

A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

ou “Zen e a arte do tuning em banco de dados”

Nada mais fácil do que reclamar do desempenho do banco de dados. Algumas aplicações que se comportavam bem por anos começam a se tornar lentas sem aviso prévio. Aplicações que tinham um excelente desempenho num banco de dados ficam exorbitantemente lento ao adotar outro fornecedor. É comum alguns desacreditarem completamente um fornecedor por não conseguir o desempenho esperado. Vejo pessoas pedindo ajuda, ficando perdidos no meio do caminho, desistindo e colocando a culpa no banco de dados. O fato é que muita gente acha que sabe como fazer ajustes de desempenho (também conhecido como tuning) em bancos de dados, mas poucos realmente o fazem. Eu aqui como aprendiz de feiticeiro resolvi deixar algumas dicas para quem pretende se enveredar nesta mistura de arte, ciência e bruxaria.

1 - Entre no espírito do tuning

A primeira lição para os os jovens padawans do tuning é ter paciência, humildade e persistência. Você não desvendará tudo de uma hora para outra. Os seus segredos serão revelados aos poucos. Mesmo que você disponha da melhor bibliografia sobre o assunto, você só aprenderá de fato com o tempo. Seja humilde, ouça os desenvolvedores, os administradores de sistemas e redes, escute DBAs mais experientes e menos experientes também. Nunca cometa o erro de achar que você já domina bem o assunto. Sempre há mais para se aprender e o conhecimento pode vir das fontes menos esperadas. Seja persistente, não desista facilmente. Achar o ajuste ideal pode levar meses até mesmo para um DBA experiente. Você deve realmente se concentrar no assunto e se dispor a gastar muito tempo nele. Nunca espere ou prometa resultados rápidos. Alguns ajustes podem levar alguns minutos e terem resultados fantásticos enquanto outros podem levar meses para atingir uma melhoria de 10%. Lembre-se que em alguns casos, 10% pode significar a economia de milhões de dólares.

2 - Seja um aprendiz que realmente aprende

Se você tem a intenção de aprender, esteja disposto a estudar e experimentar. Estudar não significa ler alguns tutoriais e sair realizando baterias de testes. Estudar não significa pegar o Date, Tanenbaun ou qualquer outro clássico e achar que irá absorver tudo e depois estará craque no assunto. Tuning é um daqueles assuntos que exigem conhecimento genuíno que só pode ser obtido através da fusão entre teoria e prática. Portanto, estamos falando um processo de vários ciclos de ação, reflexão e revolução. Outra forma de encarar a mesma coisa seria dizer que não importa se você fez doutorado em banco de dados ou se você trabalha a 20 anos como DBA. Importam as oportunidades que você teve de dissecar casos reais e descobrir causas concretas dos problemas de performance.

3 - Concentre-se na Lei do 80/20 dos bancos de dados

Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às especificidades de cada fornecedor e cada versão.
Na verdade, se formos levar a questão de forma mais ponderada, a lei não seria 80/20, seria 99,9/0,01 . Isto ocorre por um motivo simples, ajustes de SQL e modelagem podem resultar em ganhos de performance da ordem de 10, 100 ou até 1000 vezes. Enquanto isso, ajustes no SO e SGDB tem ganhos da ordem de até 10 vezes. Portanto, antes de mais nada aprenda a modelar bem e conheça as minúcias do SQL do seu SGDB. Depois aprenda a analisar com profundidade os planos de execução e reescreva consultas complexas a partir deste tipo de análise.

4 - Concentre-se na Lei do 80/20 da informática

20% dos parâmetros de configuração do seu SGDB são utilizados em 80% do tempo. Aprenda a manejar bem estes parâmetros antes de mais nada. A maioria dos outros parâmetros são utilizados em ocasiões específicas e não tem um impacto tão forte no desempenho. Normalmente o tuning do SGDB começa por estes parâmentros mais importantes, os demais só são utilizados se você conhece especificidades da sua aplicação que sugerem o seu uso, caso contrário são deixados em seus valores padrão.

5 - Conheça o perfil das suas aplicações

A forma como a sua aplicação utiliza o seu SGDB é de suma importante para o DBA. Existem alguns padrões que lhe indicam caminhos já trilhados por outros. Sendo assim identificar o tipo de carga que a aplicação projeta sobre o banco de dados é muito importante. Aqui alguns tipos clássicos:

• OLTP ou On Line Trasactional Processing consiste na maior parte da carga das aplicações corporativas atuais. É caracterizado por um grande volume de pequenas transações conconrretes e alto volume de gravações. As cargas OLTP são as que tem o desempenho de disco mais crítico.
• BI ou Business Inteligence consistem num universo paralelo com diversas tecnologias como Data Mining, OLAP, Data Warehouse, Data Mart, Balanced Scored Card, etc. A questão é que quando falamos em BI, o banco de dados sempre acaba de um jeito ou de outro, tendo que suportar consultas enormes, com grande quantidade de dados e cálculos complexos. As cargas de BI exigem muita velocidade em leitura de disco, memória para ordenações e uso intenso do processador.
• Sites Web Dinâmicos: os sites dinâmicos são aqueles que armazenam o seu conteúdo num banco de dados. Desta forma um único acesso numa página web pode representar uma dúzia de pequenas leituras no banco de dados. As cargas de sites web são caracterizadas por um enorme número de conexões simultâneas realizando pequenas leituras.
• Operações em lote ou bath são cargas de trabalho intensas no banco de dados que podem durar várias horas para se completar e tem um grande impacto na performance. São comuns tanto em aplicações OLTP (cálculo de uma folha de pagamento, fechamento de ano fiscal, etc), como em BI (carga de grandes tabelas vindas de fontes externas). As cargas em lote sempre são alvos de estudos cuidadosos tem o potencial de crescer rapidamente em tempo de execução até inviabilizar os negócios da empresa.

É claro que uma única aplicação pode ter todas estas características ao mesmo tempo. É óbvio também que tem-se o hábito de abrigar várias aplicações no mesmo banco de dados, tornando tudo muito mais divertido…

6 - Monitore hoje, monitore sempre

Estar sempre atento a fatos notáveis no seu banco de dados são atitudes de valor inestimável para quem se preocupa com desempenho. Quem participa da equipe de desenvolvimento tem sempre a oportunidade de ser mais proativo e detectar possíveis problemas antes deles ocorrerem. Mas quem cuida de um banco de dados já em produção acaba sendo mais reativo. É claro que se você conhece bem o seu banco de dados, você sabe em que momentos o desempenho se torna crítico e quando não. Ter isso bem documentado é fundamental. Você pode saber que uma determinada rotina demora normalmente 2 horas para ser executada. Um dia esta rotina começa a demorar 3 ou 4 horas e você quer saber o porquê. Se você tiver documentado o perfil da carga quando tudo funcionava bem, você poderá comparar isso com a nova situação e detectar rapidamente o que realmente mudou. Se você não tiver isto documentado, será muito mais difícil de saber porque o tempo de execução aumentou.

7 - Crie suas próprias métricas e guarde-as com cuidado

É muito fácil coletar zilhões de estatísticas através do SO, SGDB ou até mesmo através dea aplicação. No entanto elas não tem muito valor se você não souber o que elas realmente significam e se não puder inferir uma estatística a um dado evento. De nada adianta saber o volume de leituras do seu disco num dado momento. No entanto saber quantas leituras em disco uma determinada transação provoca, é muito mais útil. Conheça as estatísticas disponíveis. Saiba como extraí-las através das ferramentas disponíveis, saiba como extrair estas informações do forma a torna-las relevantes e saiba o que elas realmente significam. Para isto é preciso criar pequenos programas que gerem cargas padronizadas no seu banco de dados.

Quanto mais próxima a carga gerada se assemelhar da sua aplicação, maior será o valor da sua métrica. Há programas sofisticados que são capazes de gerar cargas idênticas a de um ambiente de produção. Estes sistemas simulam cargas concorrentes e até mesmo criam robôs que utilizam as suas aplicações como se fossem usuários normais. Como é possível imaginar, testes que simulam uma carga de stress muito próxima da realidade tem um custo exorbitante. Há ferramentas intermediárias que geram cargas como o TPC-H ou TPC-C que podem ser muito interessantes para medir a capacidade do servidor para gargas genéricas.

8 - Saia do geral e vá para o específico

A maioria dos SGDBs permite que você realize uma configuração geral do banco de dados para o uso cotidiano e uma configuração específica para situações especiais. É comum você ter uma carga específica que possui um perfil diferenciado das demais. Este tipo de operação pode receber uma configuração específica. Você pode fazer com que todo o banco de dados assuma uma determinada configuração em um determinado momento, pode isolar isso para um usuário específico, para uma sessão específica ou até para uma transação específica. Apesar de ser trabalhoso, operações em lote, grandes relatórios e outras cargas mais pesadas se beneficiam muito deste tipo de atenção do DBA. Outra questão a se analisar sempre é a de evitar ao máximo a concorrência junto a este tipo de operação agendando sempre que possível para um horário de menor demanda.

9 - Tenha rigor científico

Apesar de todo o ar de mistério e magia em torno do tuning, a melhor forma de você saber o que está fazendo é utilizar do rigor científico. Uma das premissas da ciência é a de que você só tem um experimento válido se puder reproduzi-lo. Isto significa que não adianta rodar uma determinada carga num banco de dados em produção para ver como ele se comporta. No ambiente em produção, há outras pessoas agindo sobre ele de forma que você nunca conseguirá reproduzir exatamente as mesmas condições de teste. O tamanho das tabelas, índices, estatísticas tem de ser todos idênticos. Não preciso dizer que o servidor tem que ter o mesmo hardware, o mesmo software e exatamente a mesma configuração, para que o teste seja válido.

Outra coisa importante e que dá trabalho é a entediante tarefa de lidar com apenas uma variável por vez. É comum alguém querer alterar diversas coisas de uma vez só para depois testar o seu impacto sobre a performance. Você nunca vai saber qual das suas alterações ajudou e qual atrapalhou na performance final se fizer assim. Há vezes em que se chega numa configuração muito boa assim. No entanto você nunca tem o conhecimento claro sobre a influência de cada variável. Assim, o êxito pode se transformar em fracasso miserável quando aplicado em outra situação.

10 - Saiba gerar e analisar métricas manualmente

Os bancos de dados proprietários como o Oracle e o DB2 levam uma enorme vantagem (talvez a mais importante delas) sobre os livres no que diz respeito a ferramentas de monitoramento, gerenciamento e autotuning. São recursos poderosos que coletam métricas pré-determinadas, fazem análises e recomendações. Estas ferramentas são excelentes para resolver problemas comuns do dia-a-dia. Em empresas de pequeno e médio porte, estas ferramentas podem diminuir bastante a dependência do DBA para as tarefas mais cotidianas. Mas existem 2 problemas intrínsecos a este tipo de ajuda:

• Você aprende menos, uma vez que se acomoda com os resultados já enlatados pela sua ferramenta. O uso constante dos conselheiros (ou ‘advisors’), assistentes (ou ‘wizards’) e outras tecnologias no estilo nnf (next, next, finish) embrutecem muito o profissional de informática que deixa de entender completamente o que se passa de fato nos bastidores do SGDB. Veja, não é porque existe calculadora que as pessoas deixaram de aprender a fazer as contas na mão.
• A ferramenta pode errar. Nem sempre as recomendações da sua ferramenta serão as melhores. É impossível para quem desenvolve uma ferramenta deste tipo prever todas as situações possíveis. Além disso, a ferramenta nunca tem todas as informações relevantes ao negócio para poder fazer uma avaliação realmente segura. O ser humano ainda não pode ser substituído na sua capacidade de julgamento. Existem muitas ações que podem ser conveniente automatizadas, outras não. É por isso que a figura do “conselheiro” apenas aconselha, não decide. Um DBA experiente saberá quando o conselho é útil e quando não. Mas para isso você não pode ter se acomodado com o uso apenas da sua ferramenta automatizada.

11 - Torne-se um ninja em discos

10 entre 10 DBAs se preocupam com discos mais do que qualquer outro componente do hardware. Não se trata apenas de ter espaço de armazenamento para seus dados. Trata-se de desempenho. Os custos de uma boa solução de storage podem ser estratosféricos, com um custo de mais de R$ 30 mil num único disco. E não se surpreenda se ouvir falar em bancos de dados com milhares de discos. Então este é um universo que o DBA precisa dominar. SATA, SCSI, SAS, Fibre Channel, iSCSI, RAID e outras tecnologias devem ser bem conhecidas. Não basta saber quais tipos de RAID existem, é preciso testa-los, saber quais as diferenças quando implementados via software, por uma controladora local ou em um storage externo. Os sistemas de arquivo também são motivos de intermináveis discussões. Conhecer as suas diferenças, seus parâmetros e seu desempenho e estabilidade são obrigações do DBA. Um detalhe capcioso aqui é que ferramentas de benchmarks para discos e sistemas de arquivo costumam ser de pouca utilidade para o DBA. A carga que estas ferramentas criam nos discos dificilmente equivale a carga que um banco de dados cria na prática. Assim, a melhor forma de testa-los, continua sendo através de programas que gerem carga diretamente no banco de dados. Baseie as suas métricas de disco neste tipo de teste.

12 - Não troque segurança por desempenho

É muito fácil conseguir aumentar o desempenho de um banco de dados abrindo mão da segurança. Lembre-se que as pessoas utilizam bancos de dados mais pela sua confiabilidade e versatilidade do que pelo seu desempenho. Rotinas de backup, tolerância a falhas, garantia de ACID e outras questões não podem ser jogadas pela janela de uma hora para outra, a não ser que você se permita ser jogado pela janela quando as coisas derem errado. Existem parâmetros no SO, no SGDB e configurações de hardware que fazem o seu SGDB decolar, mas o tornam muito vulnerável ao menor problema que acontecer.

É fundamental conhecer bem os mecanismos de logs de transação e rollback. Ajustes nestes mecanismos tem grande impacto nas operações de gravação. Ao mesmo tempo, qualquer falha nesta área compromete definitivamente a integridade do banco de dados.