Pimp My Database – Parte 2
Leitores, nesta segunda parte do artigo, continuarei a relatar a os detalhes de uma consultoria de banco de dados que prestei. Na primeira parte descrevi rapidamente alguns detalhes do ambiente, procurando mostrar como era lastimável a situação, do ponto de vista técnico.
Logo que eu e o Zé terminamos de levantar todos os principais problemas, procurei deixar uma coisa bem clara: da mesma maneira que no programa ‘Pimp My Ride’, eu sempre presto consultoria não apenas para resolver o problema imediato do cliente, mais também para mostrar, passo a passo, o que foi feito, aproveitando a oportunidade para treinar e capacitar os profissionais envolvidos. Acredito que, desta maneira, não apenas resolvo o problema imediato, que muitas vezes pode ser descrito como ‘apagar incêndios’, mas também agrego conhecimento à equipe técnica responsável.
Voltando para o ambiente, o primeiro passo foi planejar como implementar todas as mudanças necessárias com o menor downtime possível, isto é, alterar as configurações do servidor sem deixar o site fora do ar. Utilizamos temporariamente um servidor, com menor poder de processamento, memória e disco, com uma cópia do banco de dados para possibilitar as alterações do servidor. A aplicação também foi modificada, por Zé, alertando aos usuários que alguma instabilidade poderia ocorrer durante o período de manutenção. Feito isso, nos propusemos a modificar o servidor de banco de dados.
O primeiro passo foi desabilitar uma série de serviços desnecessários. Suporte à multimídia, impressão e serviços de acesso remotos não essenciais foram apenas alguns dos serviços desabilitados. Só com esta ação o servidor já apresentou uma diminuição na memória utilizada. O próximo passo foi retirar todos os vírus, spywares e outras pragas virtuais. Após esta retirada, foi a vez de remover uma série de softwares desnecessários, como leitores de e-mail, plug-ins para o navegador e muitos outros. Para garantir que nenhum outro tipo de software desnecessário fosse instalado, foram configuradas políticas de domínio para bloquear a execução de uma série de aplicações, incluindo os navegadores.
O próximo passo foi passar todas as atualizações: service packs do windows, service packs do SQL Server e demais patchs e hotfixes. Em seguida, combinei com Zé que deveríamos instituir uma política se usuários e senhas, reforçadas por regras como:
-
Troca de senha a cada três meses;
-
Desabilitar as contas padrão;
-
Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;
-
Outras políticas gerais de senha, como o cancelamento após um algumas tentativas e horários definidos para certos usuários.
Um detalhe importante a ser considerado, quando se fala de política de senhas, é a parte humana. Deixei bem claro para Zé que apenas reforçar a segurança com soluções tecnológicas não adiantava muito: é importante reforçar a segurança com políticas que envolvam as pessoas como, por exemplo, políticas que deixam claro que os administradores não devem anotar senhas em um papel. Infelizmente é necessário também definir certas punições para evitar o risco de quebra na segurança e também para coibir os usuários a vazar informações. No final das contas, um documento contendo a política de segurança foi escrito.
Mais alguns acertos no servidor e partimos para o banco de dados. O primeiro passo foi identificar o que estava sendo utilizado ativamente pela aplicação e o que era historio. Com a posse desta informação, ‘quebrei’ o banco de dados em dois, com o objetivo de separar as informações mais utilizadas daquelas que foram consideradas histórico.
Além disso, modifiquei parâmetros específicos no servidor para garantir que o acesso a memória seja mais ‘econômico’ e que o banco de dados não cresça tanto. Alias o problema de espaço em disco esta ligado ao banco de dados: como não havia backup periódico do banco de dados, e este estava com o recovery Model Full e com todas as opções de auto-crescimento habilitadas (o que, infelizmente, é a realidade em muitas empresas que adotam o SQL Server como servidor de banco de dados) o arquivo de Transaction Log cresceu absurdamente. Modifiquei as configurações da base de dados, separei os arquivos de dados e de Transaction log e elaborei uma rotina de backup periódica e automática para resolver estes problemas. Sempre lembrando que, a cada modificação no servidor ou ação tomada, eu explicava para Zé o que estava acontecendo, que se encarregava de documentar o procedimento.
Com a questão da memória e do disco resolvidas, fui verificar o uso do processador. Apesar de possuir um alto pode de processamento, não raramente a CPU acusava o uso de 100% de processamento. Comecei a identificar os pontos onde isso acontecia e, aplicando técnicas para distribuir a carga, utilizar índices e otimizar stored procedures, consegui evitar o uso excessivo de processamento, por parte do servidor de banco de dados. Memória, CPU e disco já estavam ajustados, só faltava agora a rede.
Para entender o porquê da lentidão na rede, tive que analisar como a aplicação interagia com o servidor de banco de dados. Para isso, utilizar o Profiler e captei as principais consultas enviadas para o servidor de banco de dados. E não eram poucas. Resolvei, então, que deveríamos fazer pequenas modificações pontuais na aplicação: evitar solicitar muitas consultas diretamente para o servidor, trocando-as por chamadas à stored procedures, limitar a quantidade de linhas retornadas a partir do banco de dados, com a paginação de resultados, e utilização maciça do cachê. Com o uso destas técnicas, conseguimos diminuir em cerca de 60% o consumo de rede, com base na troca de informações entre o servidor de banco de dados e o servidor de aplicações.
Mais ainda faltava muita coisa para ser feita. Mais especificamente, faltava acertar problemas de desempenho e também a questão da disponibilidade. E, talvez o mais importante, tomar medidas pró-ativas, para evitar que Zé fosse chamado de madrugada para apagar um ‘incêndio‘ decorrente de um defeito no ambiente.
Neste ponto, já revertemos o servidor de banco de dados temporário para o servidor oficial. A partir desta reversão, pude verificar quais são as verdadeiras consultas enviadas pela aplicação em horários de extremo uso (picos de usuários) e nos horários mais folgados. Com base nisso, e também em uma análise do que os usuários mais fazem na aplicação, comecei a esquadrinhar a próximas modificações. Como na maioria das aplicações WEB, os usuários fazem mais visualização de dados do que gravação, isto é, a maioria dos usuários somente joga os produtos no ‘carrinho’ ou apenas os vê, sendo que, em contrapartida, apenas uma pequena parcela dos usuários finaliza as compras e grava dados na base.
Existem muitas técnicas para otimizar o desempenho. Neste caso específico, o que mais gerou resultados positivos foi a utilização de índices e a re-escrita das consultas da aplicação. Obviamente, antes de começar a fazer os testes verifiquei qual o tempo médio que os usuários gastavam nas operações mais comuns e qual seria o tempo ideal, de acordo com o conhecimento do Zé e de outros especialistas no negócio. Além disso, deixei claro que, para manter o tempo de resposta, verificaria apenas o banco de dados, que na maioria das vezes NÃO é o principal responsável. Esta última frase pode até gerar polêmica, mas eu me reservo no direito de fazer esta afirmação com base na minha experiência em consultoria de banco de dados. Mais uma vez, a idéia aqui não é apontar dedos e procurar culpados, mais sim alertar para os problemas.
Na próxima parte do artigo descreverei quais foram as principais atitudes para garantir a disponibilidade e também as ações indicadas para se agir de forma pró-ativa.
