Banco de dados

AULA 08
Tuning de Banco de Dados
ANALISANDO EVENTOS NO TEMPO
Na aula anterior...
Estudamos os eventos de espera ligados ao processo de gravação do controlfile, analisamos
como a geração de redolog influencia nos gargalos e como podemos fazer para melhorar...
Novidade...
Na aula de hoje conforme comentei, iremos parar um pouco de falar de OWI e vamos falar de
algo um pouco diferente porém também importante.
Quando conversamos sobre OWI vimos que ele não traz dados históricos, somente retrata o que
está a acontecer no exato momento em que é analisado, certo?
Pois bem...
Porém algumas vezes pode ser que nos seja solicitado, ou até que nós mesmos percebamos que
se faz necessário olhar para um momento no passado para traçar uma linha de base, para
analisar um determinado período do banco de dados.
AWR
Eu estou falando de um "cara" muito importante, uma ferramenta sensacional da Oracle, que
infelizmente faz parte da versão Enterprise Manager. Digo infelizmente pois acaba se tornando
difícil para quem tem versões mais simples do banco de dados.
Sua utilização é bem simples e pode ser feita através do Enterprise Manager ou via script direto
no sistema operacional.
Como não gosto de condicionar meus DBAs a trabalharem como DBAs de "telinha" vamos
trabalhar a famosa utilização em linha de comando.
Porém antes disso vamos comentar quem é o AWR, como funciona...
AWR
Sobre
AWR ou Automatic Workload Repository é um local dentro do banco de dados que coleta,
armazena e analisa dados a respeito do funcionamento do banco de dados.
Os dados do AWR tem uma vantagem interessante que é permanecerem mesmo após queda da
instância, podem ser utilizados para criação de uma linha de base do ambiente, a famosa
baseline. Também podem servir como comparativo entre dois períodos, entre nós em ambiente
RAC.
Para que os dados do banco de dados sejam armazenado em disco, entra em ação um processo
de background novo, o MMON(Manageability Monitor).
O AWR capta os dados de forma automática sem a necessidade de intervenção de um DBA.
AWR
Como funciona??
O Processo do AWR com a configuração default que atende muito bem a praticamente todos os
tipos de ambiente, funciona da seguinte forma.
Estatísticas em
memória
A cada 1 hora
SYSAUX
MMON
Os dados são armazenados no
tablespace SYSAUX (questão de prova)
na forma de SNAPSHOTS que serão
mantidos de acordo com a política de
retenção que é de 07 dias (default).
AWR
Funcionamento
Todas as configurações default podem ser alteradas, porém nem sempre devem ou são
necessárias, podendo mesmo vir a ocasionar certo overhead no ambiente como um todo.
Afinal de contas é um processo razoávelmente grande rodando a mais.
O espaço que ocupa no tablespace SYSAUX também é algo que se deve levar em consideração
quando for alterar configurações default ou modificar processo de espurgo dos snapshots.
Para termos uma idéia mais ou menos correta, o AWR em um sistema com 100 sessões ativas
requer em média 2,5GB de espaço no tablespace em condições default, isto é: uma coleta por
hora mantido por 07 dias.
O consumo médio depende diretamente do número de sessões ativas no sistema.
Existem dois scripts do Oracle que nos ajudam a entender sobre os espaços e a geração do AWR.
utlsyxsz.sql e awrinfo.sql ambos estão no $ORACLE_HOME/rdbms/admin
AWR
Funcionamento
utlsyxsz.sql:
Traz informações importantes como: tamanho que está ocupando no tablespace, quantidade de
sessões ativas, a frequência dos snapshots e a política de retenção
awrinfo.sql:
Traz relatório estimando o crescimento médio da ocupação no tablespace e pode ser útil para
ajudar a dimensionar o ambiente ou para prever modificações nos padrões default.
AWR
Alterando as configurações default
Conforme já conversamos as configurações default podem ser alteradas, ou pelo OEM (Oracle
Enterprise Manager) ou através de linha de comando com a package:
DBMS_WORKLOAD_REPOSITORY
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention IN NUMBER DEFAULT NULL,
interval IN NUMBER DEFAULT NULL,
topnsql IN NUMBER DEFAULT NULL);
Onde: retention define a política de retenção ou seja altera o 07 dias que é default;
Interval define o tempo entre uma coleta e outra que é 60 minutos default, podendo ir de 10
minutos a 100 anos;
topnsql define quantas TOPSQL serão capturadas, especificando DEFAULT será 30 para
STATISTCS_LEVEL TYPICAL e 100 para ALL. Especificando MAXIMUM irá capturar todos os SQL do
período.
AWR
Configurações
Por falar no parâmetro STATISTCS_LEVEL, para que o AWR funcione ele deverá estar setado para
TYPICAL ou ALL, caso contrário será desabilitado.
Aqui cabe uma lembrança importante:
O parâmetro setado para ALL aumentará banstante a carga de "trabalho" do banco de dados.
Portanto, aconselho a utilizá-lo somente se realmente necessário, lembrando de habilitá-lo
por um tempo desabilitando depois.
AWR
Gerando e apagando SNAPSHOT manualmente
Conforme eu já comentei, a geração dos snapshots ocorrem automaticamente sem a
necessidade de intervenção do DBA. Porém pode ser que por algum motivo específico você
queira ou precise criar manualmente um.
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT (};
Com o comando acima ele irá criar automaticamente um SNAPSHOT, dando para ele um
SNAP_ID já com a numeração devida.
Agora se quiser apagar do snap_id 10 ao 15:
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(
LOW_SNAP_ID => 10,
HIGH_SNAP_ID => 15);
AWR
Gerando AWR por script
Já aprendemos a configurar a geração dos snapshots agora vamos aprender a gerar o relatório
do AWR manualmente, isto é, via linha de comando e não pelo OEM.
Todos os scripts de geração desde a versão inicial do AWR (10g) estão em:
$ORACLE_HOME/rdbms/admin
Gerando AWR de um determinado periodo:
$ORACLE_HOME/rdbms/admin/awrrpt.sql
Gerando AWR comparativo entre duas faixas de periodos determinados:
$ORACLE_HOME/rdbms/admin/awrddrpt.sql
Rodando logado como SYS ou SYSTEM no SQLPLUS ele irá nos perguntar qual tipo de relatório e
dados referentes ao período para análise.
AWR
O que olhar primeiro
Esta é uma pergunta bem interessante: Estando com o relatório na tela, que olhar primeiro??
Bem, aqui antes de mais nada cabe fazer uma reflexão interessante: Qual situação me faria
escolher a análise do sistema pelo AWR? Porque escolhi gerar este relatório que traz dados do
"passado"?
Ora! Porque eu quero analisar dados do passado!!! Ok, ok! Obvio demais né? Vamos lá...
Imagine que algum usuário relatou que hoje pela manhã quando ele gerou o relatório contábil o
sistema demorou muito mais do que o habitual.
Quando ele disse " hoje pela manhã " ele matou a charada. Estamos tratando de uma situação
passada, logo, quem poderá nos ajudar a entender o que aconteceu (não o que está
acontecendo) é alguma ferramenta que nos mostre o passado.
Sendo assim, o relatório do AWR é perfeito para levantarmos tais informações.
AWR
O que olhar primeiro
Agora se aprofundarmos mais ainda na situação e descobrirmos que ontem pela manhã, ele
também rodou o mesmo relatório, porém com performance muito superior a de hoje.
BINGO! Temos aqui mais um ponto que pode nos ajudar e muito.
Quando ele disse "ontem melhor que hoje" ele nos remeteu a situação de podermos trabalhar
comparando os dois períodos. Exemplo:
Ontem entre 08:00 e 10:00 e hoje o mesmo horário.
Sei que talvez esteja pensando:
O que isso poderá demonstrar?
Poderemos encontrar qual a atividade que ocorreu no banco de dados em um período que não
ocorreu no outro e por isso pode ter impactado o ambiente.
AWR
O que olhar primeiro
Pois é... Falamos, falamos mais ainda não respondi a pergunta não é mesmo??
O que olhar primeiro quando eu estiver com o AWR em mãos?
Bem vamos lá então ver alguns itens interessantes que temos aqui:
Este é o primeiro "setor" do AWR. Serve para
identificarmos a qual banco pertence, qual S.O.,
qual o período analisado, e o DB Time do banco de
dados.
AWR
O que olhar primeiro
Após conferir o cabeçalho eu sempre vou em busca de uma sessão importante os TOP EVENTS. E
aqui novamente teremos a importância do conhecimento dos eventos de espera. Exatamente
isso! Aqueles mesmos que começamos a trabalhar no estudo do OWI.
Percebeu?
Temos
aqui
eventos tratados no estudo
do OWI
AWR
O que olhar primeiro
Também são coletadas informações importantes sobre o sistema operacional da instância. Como
o Load e atividade do CPU.
Perceba, que no período o
CPU ficou bem "tranquilo"
com 95% Idle.
AWR
O que olhar primeiro
Muitas vezes o TOP FIVE dos eventos não me traz uma indicação forte de onde estará o meu
problema, e pode ser que eu deva verificar na sessão TIME MODEL STATISTICS em busca de
informações relevantes.
AWR
O que olhar primeiro
Veja que esta sessão dentro do AWR é bem interessante.
Lembra que em um outro slide atrás vimos que o nosso DB
TIME era 210,56 minutos?
Aqui os tempos são em segundos, por isso ele fala 12633,8(s)
210,56 * 60.
Analisando o desenho ao lado vemos que 47,85% do tempo
foi executando queries. Este valor eu não considero
alarmante, mas caso fosse poderíamos olhar a sessão
referente aos SQLs.
AWR
O que olhar primeiro
Veja que esta sessão dentro do AWR é bem interessante.
Lembra que em um outro slide atrás vimos que o nosso DB
TIME era 210,56 minutos?
Aqui os tempos são em segundos, por isso ele fala 12633,8(s)
210,56 * 60.
Analisando o desenho ao lado vemos que 47,85% do tempo
foi executando queries. Este valor eu não considero
alarmante, mas caso fosse poderíamos olhar a sessão
referente aos SQLs.
AWR
O que olhar primeiro
As queries demonstradas no AWR são divididas conforme abaixo:
AWR
O que olhar primeiro
Eu constumo olhar primeiro o ordenado pelo tempo de execução.
AWR
O que olhar primeiro
Outra parte legal é a que fala dos segmentos com maiores leituras físicas ou lógicas
AWR
O que olhar primeiro
Também temos para escrita física, segmentos mais locados com lock de linha nas operações
DML.
Enfim, olhando para o AWR temos um enorme histórico do que aconteceu dentro daquele
período escolhido para análise.
A grande jogada do AWR é coletar informações, transformá-las em dados estatísticos que
possam ser trabalhados para montar uma linha de base (baseline), para trazer em relatórios,
como acabamo de ver.
Porém temos algo muito interessante que ocorre a cada AWR que é o evento de ADDM –
Automatic Database Diagnostic Monitor, que irá fazer análise encima de cada AWR gerado e vai
sugerir alterações no banco de dados, melhorias, etc.
Mas isto é assunto para nossos próximos encontros.
Tuning banco de dados
Próxima aula...
Na próxima aula vamos botar a mão na massa e gerar AWR e analisar ele
conforme vimos hoje.
AULA 08
Tuning de Banco de Dados
FIM