Melhorar a performance de um banco de dados é essencial (database server performance), pois aumenta a capacidade de processamento de informações por unidade de tempo, gera economia com menor uso de hardware (menos servidores ou menos tempo de nuvem) e cria um diferencial ao entregar informações, relatórios e dashboards mais rapidamente e mais completos, que se traduzem em ferramenta gerencial e estratégica para as unidades de negócios.
O Database Performance Server Tuning (Tuning banco de dados SQL server) é um serviço premium, de ajuste fino de performance. Enquanto nossos concorrentes tentam resolver problemas de performance baseando-se, somente, na parametrização (configuração) do servidor de banco de dados. Nós preferimos uma imersão (deep dive) no ambiente de banco de dados, analisando todos os fatores que possam contribuir para melhoria geral de performance, como inversamente, impactar negativamente nesta.
Diminuição do tempo de apresentação de notícias conteve a debandada de assinantes. Com escalabilidade foi possível aumentar a base de assinantes. Com mais performance e recursos disponíveis, foi possível criar banners mais adequados ao perfil do internauta, melhorando o índice de monetização com publicidade.
Por meio de consultoria com parametrização e escalabilidade horizontal, aumentamos em 5x o número de jogadores simultâneo, gerando ganhos em assinaturas e publicidade.
Redução do tempo de navegação entre categorias, produtos e carrinho (checkout) aumentou o número de visitantes e, consequentemente, de vendas.
A melhoria de performance possibilitou ondas de separação de mercadorias mais ágeis e menor tempo de composição da rota e carga, resolvendo os constantes problemas de backlog de pedidos.
Entregar aos seus clientes informações completas e seguras de forma rápida, a fim de agilizar decisões de crédito. Com o aumento da base de dados e quantidade de requisições, este sistema quase parou. Com nosso serviço de performance tuning e alto volume, ajudamos nosso cliente a atingir seus objetivos e os de seus clientes.
Em um ambiente SOA (Service-oriented Archicture) é imprescíndivel que os serviços de consumo de dados sejam ágeis. A partir de uma consultoria de performance com reescrita de procedures, queries e parametrização, conseguimos diminuir em até 75% os tempos de resposta de serviços cruciais para o negócio de crivo e propostas.
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 de banco de dados, 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 Database 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).
Tem perguntas sobre nossos serviços ou precisa de assistência técnica? Preencha o formulário abaixo e nossa equipe entrará em contato o mais breve possível.
Líderes em soluções de banco de dados, comprometidos com a inovação, segurança e desempenho para impulsionar o seu negócio.
Desenvolvido por
