Revisado por Marcelo Pivovar - Solution Architect

Introdução

Porque meu banco dedados está lento? Aposto que essa seja a pergunta mais comum que qualquer DBA Oracle enfrenta ao longo de sua carreira e a decisão final tomada no final do dia é sempre aumentar a capacidade de infraestrutura do banco de dados. É um mito que o aumento da capacidade do servidor em termos de CPU e RAM seja a solução para todos os problemas de performance, mas caso seja realmente problema de CPU e IO precisamos provar isso através de números. Nessa tentativa eu gostaria de quebrar o mito e compartilhar minha experiência e conhecimento na análise das mais inexplorada área da capacidade de planejamento de métodos estatísticos, que pode ser usado de forma proativa para evitar potenciais problemas imediatos ou até mesmo problemas futuros.

Servidor de banco de dados, você está sendo servido corretamente? O servidor de banco de dados foi provisionado em fase de implementação do projeto. Com o passar do tempo, a carga de trabalho da aplicação aumenta e permanece despercebida e é aí que o desempenho real começa devido à falta de conhecimento da carga de trabalho da própria aplicação.

Ilustração. 1: Um servidor totalmente carregado, rejeita os novos pedidos dos clientes Legenda: "Hey ! Eu não faço mais pedidos de ninguém!"

Você está certo de que o banco de dados é sempre o centro dos problemas? Em casos onde não existe nenhum aumento significativo na carga de trabalho, há grandes chances do problemaser com a aplicação por seremvulneráveis a estouros de memória devido a falhas de arquitetura, nesses casos o problema permanece indetectável, ou o aumento de carga pode ser um SQL fazendo um péssimo plano de execução. Mas, em qualquer um dos casos, o dedo é apontando diretamente para a infraestrutura, como processamento (CPU) e memória (RAM)

Você entende totalmente a sua carga de trabalho? Na maioria dos casos onde a aplicação conecta ao banco de dados são complexas em termos de carga de trabalho e nesses casos, existem pessoas que acreditam que performance tuning é melhor executada iniciando a nível de "sistema" e ir movendo-se abaixo através das camada para encontrar o gargalo(s). Para fazer isso, precisamos estar plenamente conscientes da carga de trabalho do nosso sistema e sua tendência.

Quais são os diferentes métodos estatísticos de análise da capacidade do sistema de um banco de dados? Simple Maths (Matemática simples) - Este modelo pode levar a uma única entrada de componente, aplicativo ou até mesmo uma métrica. Este método é geralmente envolvidos com projetos de curta duração. A precisão é geralmente baixo, mas suficiente, quando utilizado de forma adequada

Ilustração 2: Um resultado da consolidação de servidores usando método Simple Maths.

Essential Forecasting Mathematics (Matemática Essencial De Previsão) – Este método pode produzir previsões relativamente precisas. Este é novamenteum outro método de entrada de componentes por meio de métricas técnicas. Este método é usado com projetos de curta duração.

Linear Regression Analysis (Análise de Regressão Linear) – Este método é geralmente usado para determinar o quanto que uma atividade empresarial pode ocorrer antes que o sistema fique sem combustível. Linear Regression Analysisé um método para investigar relações entre as variáveis​​. Exemplo: Logical Reads vs. CPU utilization

Fórmula de correlação utilizado em modelo de regressão linear:

CPU utilizada = usercalls * m + c

O coeficiente de correlaçãor = ∑(Yi-Y)(Xi-X)/SQRT(∑(Xi-Y)2(Xi-X)2

Nota: - MS Excel fornece a função predefinida CORREL() para a complexa equação matemática (Ótima novidade!)

Ilustração 3: Um template Excel para o método Linear Regression Modelling.  

Queuing Theory – Este é basicamente um upgrade para a Essential Forecasting Mathematics, este método é utilizado para predição de alta precisão.

Agner Krarup Erlang(1878 -1929) é o homem por trás dessa teoria. Ele estudou o desempenho das linhas telefónicas. Quando a função Erlang C é usada, nós não aplicamos as fórmulas de tempo de resposta essenciais de previsão (essential forecasting response time), em vez disso, temos uma única e nova fórmula, que pode ser aplicado tanto para CPU como para I/O subsystem.

Para subsistemas de CPU, só há uma fila para o arrival rate de todo o sistema (λsys), mas para subsistemas I/O a arrival rate em cada fila (λq) é a arrival rate do sistema (λsys) dividido pelo número de dispositivos I/O.

Fórmula de correlação utilizado em modelo de filas:

Q = λqQt

Ec = Erlang (m,St,λq)

Ilustração 4: System response time Vs. System arrival rate.

Ilustração 5: Um template de Excel para Queuing modelling.

Conclusão

Esta é uma introdução a alguns métodos estatísticos e modelos que podem ser usados para replicar no sistema de carga de trabalho nos nossos bancos de dados. Este planejamento de capacidade ou medida de carga de trabalho, quando feito de forma proativa em uma base regular pode prever uma interrupção não programada devido à falta de recursos do sistema, como CPU ou RAM.

Joel é um DBA Especialista (Oracle ACE Director, OCM Cloud Admin. & OCM11g ). Com mais de 14 anos de experiência do mundo Oracle Technology, especializado em arquitetura e implementação de soluções como: Cloud, Alta disponibilidade, Disaster/Recovery, Upgrades, replicação e todos as áreas relacionadas com bancos de dados Oracle. Consultor internacional com deveres, conferências e atividades em mais de 50 países e inúmeros clientes em todo o mundo. Palestrante regular nos eventos Oracle em todo o mundo como: OTN LAD, OTN MENA, OTN APAC e muito mais. Joel sempre foi conhecido por ser pioneiro em tecnologia Oracle desde os primeiros dias de sua carreira sendo o primeiro latino-americano premiado como "OTN Expert" no ano de 2003 pela Oracle Corporation, um dos primeiros "ACE Oracle" no Oracle ACE Program no ano de 2004, um dos primeiros OCP Database Cloud Administrator em todo o mundo no ano de 2013 e como um das maiores realizações profissionais em sua carreira, recentemente ele foi homenageado como o primeiro "OCM Database Cloud Administrator" do mundo.

Ajith Narayanan possui 9 anos de experiência de trabalho, principalmente na administração de banco de dados Oracle e Oracle Apps administração, planejamento de capacidade e ajuste de desempenho em vários ambientes Oracle.

Flávio Soares é um Oracle DBA Sênior, Exadata DMA, Troubleshooter e Consultor Oracle, certificado em OCP/OCE RAC. Especialista em Exadata, alta disponibilidade e replicação de dados com soluções Oracle. Flávio disponibiliza frequentes informações para a comunidade Oracle através do seu blog.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.