Desempenho do Oracle Database: análise do ambiente

Estatísticas e métricas - Apresentação

Oi, tudo bem? Meu nome é Victorino Vila e eu serei o instrutor deste curso de Oracle, que começará a falar sobre performance. Antes de mais nada, vamos falar o que é performance. Quando um usuário está trabalhando no banco de dados, ele vai, de forma direta ou indiretamente, através de uma aplicação fazer coisas no banco, ele sempre deseja que haja um processamento rápido da resposta desse banco.

Essa ida e volta pode ser um comando que o usuário dá direto, no Oracle, via SQL, ou pode ser em um sistema, quando ele aperta um botão e a programação implementada na aplicação vai no Oracle fazer alguma coisa. Performance será o tempo que vai levar essa ida e volta. Esse tempo, dependendo da ação que o usuário está fazendo, pode ser longo ou não.

O grande problema é saber se esse usuário está disposto a esperar por esse tempo. Ou ele precisa de uma resposta rápida ou a resposta que ele espera está muito mais lenta do aquilo que ele pode suportar. Então cabe ao DBA analisar o ambiente e fazer uma série de análises do todo, para tentar determinar o que pode ser feito para melhorar esse tempo de retorno.

O tempo de retorno pode depender basicamente de duas coisas: ou depende de hardware, do ambiente, ou coisas que tem a ver com a lógica para resolver o comando SQL dentro do Oracle. Vamos melhorar um pouco o que eu falei. Recursos de ambiente eu acho que é muito fácil vocês entenderem: máquinas melhores vão resolver as coisas de maneira melhor.

Mas também será que todo aquele recurso bom da máquina é utilizado pelo Oracle para resolver o comando SQL de forma correta? Essas são coisas que o DBA tem que analisar. O assunto performance então estará dividido em dois cursos. Na primeira parte daremos ênfase em como o DBA pode analisar o ambiente. A segunda parte é a ênfase na forma com que o Oracle está resolvendo os comandos de SQL.

No que diz respeito à ênfase de ambiente, que corresponde a esse treinamento aqui, vamos falar de três grandes assuntos: coleta de estatísticas, administração de memórias do ambiente e alocação de recursos. Sobre a primeira, a coleta, vamos ver que o Oracle, ele fica vigiando o ambiente para medir que coisas serão feitas no banco de dados, e guarda essas estatísticas para futuras análises.

Sobre memória, vamos entender como funciona uma memória PGA e SGA no tratamento de ajuda na obtenção de respostas aos comandos vindos do usuário. Veremos que o Oracle possui uma série de instrumentos para automatizar, baseado nas estatísticas, esse uso de memória.

Finalmente, a terceira parte do treinamento irá consistir em como podemos alocar recursos, de forma direcionada, a determinado grupo de usuários. Veremos que eu posso alocar mais ou menos recursos de máquina em determinados horários, ou dias, para administrar processos que exigem, por exemplo, uma performance melhor em alguns períodos de tempo. Então é isso, espero que vocês gostem, um abraço e até o próximo vídeo.

Estatísticas e métricas - Antes de começar

Antes de começar, precisamos ter na máquina, que você vai usar para praticar os exercícios deste treinamento, o Oracle instalado. Serão até poucos exercícios, mas serão muito importantes. Caso você esteja na mesma máquina que já está usando para os outros cursos da formação Oracle, você já deve ter o ambiente instalado nela, perfeito, você nem precisa continuar assistindo esse vídeo.

Mas se você está em uma máquina nova, sem nada, que precisa ter um ambiente configurado, você precisa reinstalá-lo. Eu não vou aqui gravar de novo todos os passos da instalação, mas eu vou dar umas dicas de como você deve fazer. Primeiro aqui, no slide, em cima, eu mostro o que precisamos ter configurado na nossa máquina. Então primeiro precisamos desinstalar qualquer versão de Oracle que você tenha na sua máquina.

Depois vamos instalar a versão Oracle 19C enterprise. Atenção: não pode ser nem a standard e nem a express. Em seguida, nós instalaremos o Oracle Developer. Depois do Developer instalado, precisamos criar um banco de dados e uma instância. Finalmente fazer as conexões usando os usuários sys e system, que são os usuários administradores do banco, no Oracle Developer.

Se você voltar alguns cursos para trás aqui na formação Oracle, vocês vão achar todos os vídeos necessários para configurar esse ambiente. Mas eu vou especificar que vídeos, que cursos e que aulas são essas. Para as primeiras 3 tarefas listadas, você deve ir na aula 1 do curso “Administração do Oracle Database criação e gerenciamento do banco”. Se você for 2 cursos para trás, a partir desse, na lista dos cursos da formação Oracle, você vai achar ele.

Ou então você procure esse curso pelo nome e você também poderá achar esse curso. Recapitulando, você deve seguir a aula 1 desse treinamento para fazer os 3 primeiros passos importantes para configurar a sua máquina. Vamos seguir em frente. Em seguida, precisamos fazer a criação de um banco e da instância. Sigam todos os vídeos da segunda aula do mesmo curso, “Administração do Oracle Database criação e gerenciamento do banco”.

Para o passo de criar as conexões com o SQL Developer, você vai em outro curso, vá no curso “Administração do Oracle Database segurança e otimização do banco”. É o curso anterior, se você olhar os cursos da formação Oracle, o anterior a este. Você deve ir nesse curso e ir no quarto vídeo da primeira aula do curso.

Você segue os passos que eu mostro para vocês como você cria as conexões do SQL Developer com o banco e com a instância. Então façam isso, se você não tem nada na sua máquina, volte alguns cursos para trás, faça a configuração e você pode seguir em frente neste treinamento.

Estatísticas e métricas - Problemas de negócio

O tema deste treinamento é performance. Quando falamos de ajuste de performance nós temos um único propósito: reduzir tempo de resposta dos sistemas para os usuários finais. Ou, em outras palavras, todo ajuste deve ser orientado para a correção do que nós chamamos de um problema de negócio.

O usuário final, ele nunca vai ligar para o help desk para reclamar que o pool de compartilhamento é muito pequeno. Ele também não vai ligar para o help desk para dizer que a estratégia de indexação não está correta. Ele vai ligar para o help desk para reclamar coisas do tipo “olha, a tela de entrada de dados de pedido não é atualizada rapidamente”.

Ou então vai ligar para reclamar que os processos que rodam à noite, em batch, eles nunca terminam. Mas quando falamos em corrigir os problemas de negócio, nós não estamos nos concentrando apenas em ter que, por exemplo, redesenhar as consultas SQL que são enviadas para o banco de dados.

Pode ser que, muitas vezes, as estruturas de memória ou os índices do ambiente não sejam ótimos para uma determinada carga de trabalho exigida pelo banco de dados. Logo, o que eu posso dizer, é que para trabalharmos com performance, precisamos verificar se os ajustes do ambiente, eles estão otimizados para aquela demanda de trabalho, e podemos então olhar as consultas SQL e nos concentrarmos em resolver os problemas de negócio.

Só que, como dizemos por aí, o buraco pode ser mais embaixo. Para entender isso, vamos rever quais seriam os passos principais para a implementação de qualquer sistema de TI, uma coisa bem superficial. Vamos lá, abrindo parênteses, a primeira fase é a análise de negócio. Precisamos entender o que o nosso sistema vai controlar.

Devemos definir os processos de negócio da organização que serão controlados pelo sistema que estamos desenhando ou implementando. Essa seria a fase de análise do negócio. A segunda parte seria a análise do sistema. Vamos transformar todas aquelas regras de negócio, que foram levantadas nas entrevistas com os usuários, em diagramas de entidade e relacionamento.

Precisamos, nessa fase, colocar em prática todas as boas regras, o que nós chamamos de modelagem relacional. O próximo passo é o projeto do sistema. É nessa fase que nós vamos transformar o nosso projeto relacional em banco de dados. É aqui que nós vamos desenhar as tabelas, os índices e os relacionamentos entre eles.

É aqui que aproveitamos para explorar tudo aquilo que o banco de dados Oracle nos proporciona de instrumentos para implementar no banco de dados. Depois vamos para a fase do designer do aplicativo. Nesse ponto é que vamos desenhar todas as nossas SQLs, os nossos programas de consulta, os nossos comandos de inclusão e alteração do banco, que estarão relacionados com as regras de negócio.

É nessa fase que o front-end vai desenhar as telas de acesso dos usuários e fazer o relacionamento com a parte back-end do sistema, que então vai executar os comandos de SQL para a manutenção e consulta dos dados no banco Oracle. Depois de desenharmos o aplicativo, vamos implementar ele.

Vamos treinar os usuários, colocar o sistema em produção e fazer o que nós chamamos de operação assistida: acompanhar o sistema, durante um tempo, bem de perto. Finalmente chegamos à parte da manutenção. Nós temos que monitorar o comportamento do sistema e ver se as respostas desses sistemas, para os usuários, estão corretas de acordo com a análise do negócio.

Porém, pode ser que mesmo depois de tudo isso, um comportamento do sistema, ele acaba sendo muito aquém do esperado. É nesse ponto que eu fecho os parênteses que eu abri no início, e vamos voltar àquela parte inicial do nosso vídeo. Vamos voltar para o telefonema do cara do help desk para reclamar que a tela de entrada de dados do pedido não é atualizada ou, por exemplo, que o processo batch, ele nunca termina.

Resolver o problema do sistema depende de onde esse erro é cometido. Um erro cometido no início, na análise de negócio, pode ser muito difícil de conseguirmos corrigir posteriormente. Por exemplo, durante a análise de negócios, o nosso usuário nos disse que o cliente precisa ter uma chave de identificação única.

Só que o analista usou o nome do cliente como essa chave de identificação. Erro gravíssimo. Mas, vamos lá, isso foi feito e ninguém reclamou. Porém, na hora de implementar o sistema, se descobriu que podemos ter um monte de clientes com o mesmo nome. Resolver esse erro, que foi cometido no início da fase de implementação do sistema, pode ser muito difícil.

Cometer um erro lá em cima, na análise de negócio, e corrigi-lo, significa ter que rever todas as fases de implementação do projeto. Um outro exemplo de problema que pode acontecer no meio do projeto, é o desenho do banco de dados. Se você deixar para aqueles analistas clássicos, puros, modelarem as tabelas, eles vão sempre modelar o banco usando o que nós chamamos de melhor forma normal.

Geralmente usamos o que chamamos de terceira forma normal para a implementação de um banco de dados que será usado para gerenciar processos nas empresas. Mas, embora essa terceira forma normal possa ser teoricamente a ideal, ela raramente é boa para desempenho.

Pode ser que, no projeto, a terceira forma normal, nós tenhamos que fazer o que nós chamamos de uma desnormalização dessas tabelas para melhorar a performance. Esse processo de desnormalização, ele deve ser feito na fase de design do sistema. Mesmo que o projeto respeite a terceira forma normal, já tem que desnormalizar as tabelas quando for implementar o banco.

Se eu não fizer isso naquela fase, dificilmente conseguiremos corrigir os problemas de gerenciamento de dados, super normalizados, durante a fase de manutenção. Se esses sistemas que eu acabei de falar, as formas normais, soam um pouco desconhecidos a vocês, eu aconselho a procurar, aqui na Alura, a formação de Modelagem de dados, onde todos esses termos, que eu acabei de falar, serão definidos e apresentados de uma forma fácil e intuitiva.

Vamos voltar ao nosso problema. Logo quando pensamos em performance, ela deve ser parte fundamental da implementação do sistema. Ela deve trabalhar sempre na direção que nós chamamos de cima para baixo. O projeto de sistemas, ele já deve ser desenhado e pensado em performance. Em cada fase da implementação, nós devemos sempre questionar se a decisão tomada vai ou não prejudicar a performance.

Desde a modelagem do negócio, partindo para o desenho do banco, o desenho das sentenças SQLs e da facilidade do usuário em se relacionar com o front do sistema. Também devemos sempre nos concentrar nas necessidades de negócio do nosso cliente, na performance que aquele cliente quer que o sistema, que está sendo implementado, tenha.

O cliente tem que estar feliz com o desempenho do sistema em que ele vai trabalhar. Mas, às vezes, ou melhor, na grande maioria das vezes, aquele chamado do help desk, ele chega no colo de quem para resolver o problema de performance? Do DBA, do cara que administra o banco.

Ele tem que resolver esse problema de performance. Nem sempre os problemas de performance serão resolvidos pelo DBA, principalmente se o problema de performance for relacionado com o banco mal modelado ou com uma difícil interface front-end.

Só que é o seguinte, apesar do DBA, ele estar um pouco limitado para resolver esses problemas, ele tem alguns superpoderes que ele pode atuar, que diz respeito ao banco de dados Oracle, ao ambiente do Oracle. Vamos discutir mais a frente, nos próximos vídeos, um pouco mais sobre esse poder que o DBA tem.

Sobre o curso Desempenho do Oracle Database: análise do ambiente

O curso Desempenho do Oracle Database: análise do ambiente possui 214 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de SQL e Banco de Dados em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Estatísticas e métricas
• Eventos de espera
• Memória PGA
• SGA e gerenciamento automático
• Plano de recursos