O primeiro passo é uma análise de toda a carga à de consumo de seu banco de dados. Através de nossa exclusiva ferramenta de monitoramento, coletaremos estatísticas de uso para que possamos entender melhor como e quanto o banco de dados é consumido: transações por segundo, quantidade e tipos de travamento, concorrência, forma e quantidade de consumo, picos de consumo, planos de execução, comportamento do hardware e sistema operacional.

Sempre existiu a máxima de que banco de dados deveria rodar, unicamente, em máquinas físicas. Com as novas tecnologias de virtualização, isso não é, exatamente, uma verdade irretocável. Contudo, é preciso entender se o hardware e/ou máquina virtual está configurado adequadamente, e se, os recursos disponíveis são suficientes para atender às demandas impostas ao banco de dados. Capacidade e configuração incorreta de hardware e máquinas virtuais, podem representar boa parte de uma performance baixa. Mas, jamais acredite que "basta acrescentar mais hardware que tudo se resolve" - nós não acreditamos nisso. Nós preferimos resolver problemas de performance com inteligência e não fluxo de caixa.

O Sistema Operacional é uma parte pouco cuidada quando da instalação de um novo ambiente de banco de dados. Normalmente, existe um "establishment" (padrão de "deployment" de S/O) e este é seguido sem se ater às necessidades do RDBMS escolhido. Iremos atuar no contingenciamento e na equalização do "establishment" com o RDBMS. Passando por configurações do S/O, formas de "checkpoint", Cache, apresentação das mídias (discos), tipo de "file system" (sua configuração e "blocagem").

Dependendo do banco de dados (Oracle, MySQL, SQL Server, DB2, PostgreSQL, etc) a parametrização pode ser a parte mais importante de um trabalho com ênfase no ajuste fino de performance (performance tuning). Porém, é preciso aceitar que há um limite do que se pode, de fato, ganhar com este "apertar de parafusos". Não tem mais coelho nesta cartola. A parametrização é parte importante sim, mas, não é o Santo Graal da Performance. Não tem uma parâmetro mágico do tipo "ALTER PERFORMANCE = NITRO". Mas, fato é, que a perfeita orquestração de parâmetros podem contribuir para um excelente ganho de performance.

Quanto e o quê pode ou deve ser paralelizado? Cores, Threads, NUMA... As novas arquiteturas de hardware permitem-nos extrair todo o potencial das pastilhas (processadores) e do uso e mapeamento de grandes quantidades de memória (RAM). Todavia, é preciso um entendimento sistêmico do conjunto: hardware + sistema operacional + parametrização do banco de dados. Pouco paralelizar leva a subutilização do potencial do hardware, restringindo a performance. Inversamente, paralelizar em excesso ou de maneira pouco estratégica pode levar o hardware a exaustação, aumentando muito os conflitos, contenções, travamentos, MUTEX, e, também, diminuindo a performance, em alguns casos, de maneira drástica. Por isso, gostamos de usar o termo "estratégia". Os núcleos, cores e threads estão lá. Acertar a mão no quanto utilizar é tão importante quanto a correta parametrização do RDBMS e Sistema Operacional.

Os índices estão construídos da maneira mais eficiente de forma à atender suas queries? Existem índices pouco ou nunca utilizados que estão pesando nas escritas? Quem nunca ouviu: "É só criar um índice que diminuirá o tempo de consulta". Ou então, mais brilhante ainda: "Precisamos cortar alguns índices para conseguirmos melhores tempos de escrita". E o tempo gasto com a manutenção destes índices? Bancos de dados tem vida própria! Cardinalidade e Seletividade mudam, e, com isso índices bons se tornam ruins, e, talvez alguns ruins possam se tornar bons. Novamente, a palavra "estratégia". Analisaremos os índices, como foram pensados, e, se estão atendendo as principais e mais ofensivas queries.

Um breve estudo da modelagem de dados e como ela pode impactar na performance total do banco de dados. Academicamente, acreditamos que o sucesso ou o fracasso de uma aplicação inicia-se na modelagem da base de dados. Será que o banco de dados escolhido é o ideal para a aplicação pretendida? O formato normalizado seria melhor que o denormalizado? Guardar os dados em modelo bidimensional (colunas x linhas), documentos, familia de colunas, grafos? Tenho certeza de tudo que quero "perguntar" ao meu banco de dados? Mapeei as melhores formas de procurar por estas respostas? O fato é que cuidar, de verdade, da modelagem é uma parte do processo do software (aplicações). Depois que o avião está voando, fazer reparo nas turbinas é complicado. Um "refactoring" da base de dados pode significar horas de reescrita de código fonte das aplicações, o que envolveria muitos recursos: pessoas e financeiro. Portanto, não nos aprofundamos neste parte tão fundamental (temos uma serviço específico para isso). Mas, iremos nos pontos que podem contribuir negativamente na performance: excesso de normalização, "data types"(tipagem), tabelas de "staging" (auxiliares), tabelas temporárias, tabelas sumarizadas, entre outros fatores que podem ser, perfeitamente, ajustados em sintonia com a aplicação.

Identificação das queries mais ofensivas (alto consumo de recursos e/ou baixa performance), e, indicação das melhores práticas a serem adotas no seu "refactoring". Adicionalmente, poderá ser contratado um serviço especializado em refactoring de código SQL (queries, triggers, procedures, functions, jobs, events).