Analise AWR

Envie seu AWR para uma análise gratuita.
Podem ser enviados em formato texto ou html.

Procure sempre emitir o AWR para o menor período possível de análise em que seu problema de desempenho ocorre.

Se desejado, edite o texto e troque o nome do seu servidor, outra outras informações que julgue que não devam ser dilvulgadas.

Analise AWR

Mensagempor gcomenale » Sex Fev 19, 2016 1:51 pm

Portilho, o que você acha desse AWR?
É um período pequeno, o cliente vive reclamando de lentidão nesse ambiente e a lentidão sempre "se resolve sozinha".
A amostragem é de 2 semanas apenas, mas da pra ter uma visão de como o ambiente está.

Ao meu ver esse ambiente tem 3 grandes gargalos, I/O, CPU e rede.
O posso ver a tentativa de melhora no I/O pelo o commit_write como BATCH, NOWAIT além de vários dbwrn e ASYNCH I/O.
Já a CPU da pra ver no sql execute elapsed time com 98.68% do DB Time e o evento PX Deq: Execution Msg também com uma porcentagem alta.
E a rede seria um wait class de 198,190,862 waits além de eventos como TCP Socket (KGAS), SQL*Net message to client e SQL*Net message from client altos.
Mas isso significa que o problema é na rede do banco ou na rede do usuário/aplicação?

Estou passando alguns parâmetros para você também ter uma ideia melhor:

##*******************************************************************
## Data atual : 19-02-2016 11:39:04
## DBID : 2614847641
## SCN Atual : 11930095079036
## Numero da Instancia : 1
## DB_UNIQUE_NAME : p3kdb
## Nome do database : P3KDB
## Versao : 10.2.0.4.0
## Compatibilidade : 10.2.0.4.0
## CBO trabalhando como : 10.2.0.4
## Cluster : FALSE
## Qtd de instancias : 1
## Data Guard : 0
## PHYSICAL : FALSE
## LOGICAL : FALSE
## SNAPSHOT : FALSE
## Apply by ARCHIVE : FALSE
## Apply by LGWR SYNC : FALSE
## Apply by LGWR ASYNC : FALSE
## PROTECTION MODE : MAXIMUM PERFORMANCE
## FAST START FAILOVER : FALSE
## REAL TIME APPLY : FALSE
## Instancias do Data Guard :
## Data Guard Broker : FALSE
## Standby files management : MANUAL
## Host Name : oesp0193.grpoesp.com.br
## Sistema Operacional : Linux x86 64-bit
## Status : OPEN
## Startup Time : 20/01/2016 15:58:57
## Conexoes : ALLOWED
## Local Listener : (address=(protocol=TCP)(host=oesp0193.grpoesp.com.br)(port=1521))
## Remote Listener :
## Service Name : p3kdb.grpoesp.com.br
## Open Mode : READ WRITE
## Criacao : 22-05-2009 09:22:55
## Archivelog : ARCHIVELOG
## Qtd de datafiles begin backup : 0
## Local da FRA :
## Local dos archives : location=/oracle/archive/p3kdb/
## Qtd min succeed dest : 1
## Tamanho da FRA : 0 GB
## Utilizacao da FRA : 0%
## Flashback : NO
## Consumo estimado do Flashback : GB
## Recyclebin : on
## Qtd de objetos na recycle : 13768
## Logging : NO
## Undo retention value : 25000
## Reset Logs : NOT ALLOWED
## Qtd de RSRC_PLANS ativos : 0
## Tamanho da SGA (MB) : 30720
## SGA_TARGET (MB) : 0
## SGA_MAX_SIZE (MB) : 30720
## PGA_AGGREGATE_TARGET (MB) : 6144
## WORKAREA_SIZE_POLICY : AUTO
## Numero maximo de sessoes : 0
## Qtd de sessoes p/ warning : 0
## HighWater de sessoes : 479
## Qtd de sessoes atualmente : 385
## Valor do jobqueue process : 5
## Valor do process : 2000
## Valor do sessions : 2205
## Numero max de named users : 0
## Block Size : 8192
## Level de coleta de stats : TYPICAL
## MultiBlock Read Count : 16
## Optimizer Mode : ALL_ROWS
## Quantidade de CPU : 8
## LOG_CHECKPOINT_INTERVAL : 0
## LOG_CHECKPOINT_TIMEOUT : 1800
## Fast Start MTTR Target : 0
## Nivel de Parallel no MTTR : LOW
## Nivel de Parallel no Recover : 0
## Parallel Server : FALSE
## Qtd de Inst no Parallel Server : 1
## Commit Write : BATCH,NOWAIT
## Cursor Sharing : EXACT
## Optimizer Index Cost Caching : 0
## Optimizer Index Cost Adj : 100
## Resumable Timeout : 0
## Start Transformation : FALSE
## Tipo de I/O : SETALL
## Qtde de DBWRITER : 8
## Qtde de Slaves DBWRITER : 0
## Asynch I/O Disk : TRUE
## Asynch I/O Tape : TRUE
## Slaves para Tape : FALSE
## Verificação de blocos : FALSE
## Qtd tables skip corrupted : 0
## Last Object Stats : 30-11-2015
## Last Dictionary Stats :
## Last System Stats Start : 03-16-2009 16:24
## Last System Stats End : 03-16-2009 16:24
## Status System Stats : COMPLETED
## Qtde de Tasks em andamento : 0
## Qtde de Jobs em andamento : 0
## Qtde de Chains em andamento : 0
## Retencao do controlfile : 45
## Acessibilidade do dictionary : FALSE
## Audit Mode : NONE
## SID desta Sessao : 2105
##*******************************************************************
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production


Você acha que a analise que fiz está correta?
gcomenale
 
Mensagens: 0
Registrado em: Qui Mar 26, 2015 1:19 am

Re: Analise AWR

Mensagempor portilho » Ter Fev 23, 2016 3:09 pm

Oi !
Acho que você esqueceu de colocar o AWR em anexo.
portilho
Site Admin
 
Mensagens: 435
Registrado em: Qua Mai 29, 2013 11:51 am

Re: Analise AWR

Mensagempor gcomenale » Qua Mar 02, 2016 1:21 pm

Desculpe, eu esqueci de anexar mesmo...
Acabei perdendo o AWR, gerei outro, Entretanto o DB CPU e sql execute elapsed time estão altos, além de Network e I/O.
Salvei como TXT pois o fórum não deixa enviar .html :(
gcomenale
 
Mensagens: 0
Registrado em: Qui Mar 26, 2015 1:19 am

Re: Analise AWR

Mensagempor portilho » Qui Mar 03, 2016 10:53 am

:-(
Acho que pode colocar como .zip.
portilho
Site Admin
 
Mensagens: 435
Registrado em: Qua Mai 29, 2013 11:51 am

Re: Analise AWR

Mensagempor gcomenale » Sex Mar 04, 2016 10:03 am

Segue, como .rar
Anexos
awrrpt_1_112517_113000.txt.rar
(62.73 KiB) Baixado 92 vezes
gcomenale
 
Mensagens: 0
Registrado em: Qui Mar 26, 2015 1:19 am

Re: Analise AWR

Mensagempor portilho » Sex Mar 04, 2016 10:51 am

Realmente está lento. A relação do DB Time x Elapsed parece péssima (105,634.06 x 14,490.07). Se a máquina tiver 10 Cores, já estaria a +- 100%.
O Time Model diz que 30% é CPU, ou seja, tem muita Wait.
Tem 8% de tempo em RMAN, era para rodar nesse horário?

Nas Waits, é praticamente User I/O, e as consequências dele (como "read by other session"). O "Buffer Pool Advisor" está pedindo mais memória: o "Size Factor" de 1.99 reduz o "Est Phys Read Factor" para .58.

Veja que no User I/O, tem "direct path write temp" e "direct path read temp". O "PGA Memory Advisory" tambem está pedindo mais 20% de PGA. E tem que verificar os SQLs que utilizam TEMP.

O "commit_write" está em "BATCH, NOWAIT"! Precisa deste NOWAIT mesmo?
Pra que tanto "streams_pool_size"? E "shared_pool_size", em manual e com 4GB? Essa memória poderia ser aproveitada para as áreas com necessidade.
portilho
Site Admin
 
Mensagens: 435
Registrado em: Qua Mai 29, 2013 11:51 am

Re: Analise AWR

Mensagempor gcomenale » Seg Mar 07, 2016 3:18 am

Infelizmente, não sou o responsável pela administração desse ambiente, mas sempre cai na minha mão pra atender quando está com lentidão :(
Dizem, "dizem", que existe um projeto para migrar esse banco para DB2, por isso o cliente não quer alocar recursos na máquina, apenas quer que funcione até migrar.

Essa máquina tem 8 cores:

top - 13:32:16 up 44 days, 22:36, 1 user, load average: 1.90, 1.63, 1.37
Tasks: 418 total, 4 running, 413 sleeping, 0 stopped, 1 zombie
Cpu0 : 32.8% us, 6.3% sy, 0.0% ni, 60.9% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 5.6% us, 5.3% sy, 0.0% ni, 89.1% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 19.6% us, 3.0% sy, 0.0% ni, 77.4% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 2.6% us, 1.0% sy, 0.0% ni, 96.4% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu4 : 2.3% us, 1.7% sy, 0.0% ni, 0.3% id, 95.7% wa, 0.0% hi, 0.0% si
Cpu5 : 1.3% us, 0.7% sy, 0.0% ni, 98.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu6 : 11.3% us, 0.3% sy, 0.0% ni, 88.4% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu7 : 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 65905260k total, 38642284k used, 27262976k free, 1871724k buffers
Swap: 50331640k total, 260k used, 50331380k free, 2143336k cached

Acha que se eu subir a memória do Oracle pra 45gb o Linux consegue se virar com os outros 20g? Tem algum calculo para ver quanto de memória o Linux precisa x quanto de memória posso usar pro Oracle? Por exemplo sv com 128gb deixo 80gb pro Oracle e o resto pro Linux, etc.

Acredito que a razão do RMAN estar alto é por conta que o incremental deles dura 10 horas...

O item Buffer Pool Advisory do AWR é o consumo de memória do Oracle todo? Seria SGA + PGA? Ele reclamando de memória.

Concordo, a shared_pool com 4gb está gritante, reduzindo 40% o impacto seria irrisório e poderia usar a memória para outros pools.
E sobre streams_pool_size não me pergunte o porque disso não estar em zero...

O commit_write em BATCH NOWAIT não seria para reduzir o I/O?! Esse ambiente tem vários DBWn (8). O Asynch I/O ajudaria nessa questão do I/O?
Tem recomendações de parâmetros para redução de I/O?
gcomenale
 
Mensagens: 0
Registrado em: Qui Mar 26, 2015 1:19 am

Re: Analise AWR

Mensagempor portilho » Seg Mar 07, 2016 10:47 am

"Dizem, "dizem", que existe um projeto para migrar esse banco para DB2, por isso o cliente não quer alocar recursos na máquina, apenas quer que funcione até migrar."
Aposto que em 2017 ainda estará em Oracle. :-D'

"Acha que se eu subir a memória do Oracle pra 45gb o Linux consegue se virar com os outros 20g? Tem algum calculo para ver quanto de memória o Linux precisa x quanto de memória posso usar pro Oracle? Por exemplo sv com 128gb deixo 80gb pro Oracle e o resto pro Linux, etc."
Eu acho que sim, 80GB para SGA + PGA parece adequado. Mas se aumentar e utilizar SWAP, reduza pelo SGA_TARGET até encontrar o ponto ideal. Este tamanho de SGA deveria estar (se já não está) em HugePages.

"Acredito que a razão do RMAN estar alto é por conta que o incremental deles dura 10 horas..."
É Enterprise? Se sim, utilize o BCT (Block Change Tracking), para reduzir o impacto de Leitura do Backup Incremental.

"O item Buffer Pool Advisory do AWR é o consumo de memória do Oracle todo? Seria SGA + PGA? Ele reclamando de memória."
Não, ele representa apenas o DB_CACHE_SIZE, que está dentro da SGA.

"O commit_write em BATCH NOWAIT não seria para reduzir o I/O?!"
Sim, mas a gravação assíncrona do LGWR / REDO (ao contrário do DBWR) pode causar perda de dados.
http://nervinformatica.com.br/blog/?p=4461

"Esse ambiente tem vários DBWn (8). O Asynch I/O ajudaria nessa questão do I/O?"
Já está em ASYNC I/O, pois o filesystemio_options está em SETALL.

"Tem recomendações de parâmetros para redução de I/O?"
Não vejo nenhum parâmetro simples que irá reduzir esta carga de I/O.
portilho
Site Admin
 
Mensagens: 435
Registrado em: Qua Mai 29, 2013 11:51 am

Re: Analise AWR

Mensagempor gcomenale » Seg Mar 07, 2016 1:24 pm

Mas existe alguma formula para calcular?

Não conheço muito de Huge Pages, seria isso a configuração?

[oesp0193.grpoesp.com.br@p3kdb: /home/oracle ]$ grep Huge /proc/meminfo
HugePages_Total: 15362
HugePages_Free: 1
Hugepagesize: 2048 kB

Fui tentar criar o Block Change Tracking, mas ele não deixou habilitar porque não tem espaço suficiente na shared pool... Estranho ele reclamar de falta de espaço.
gcomenale
 
Mensagens: 0
Registrado em: Qui Mar 26, 2015 1:19 am

Re: Analise AWR

Mensagempor portilho » Sáb Mar 12, 2016 11:35 am

Esta informação do meminfo mostra que já está sendo utilizado HugePages.
Essa informação de falta de memória é grave! Se não tem Shared Pool para o BCT, deve estar faltando para outros itens também (talvez com erros no Log).
portilho
Site Admin
 
Mensagens: 435
Registrado em: Qua Mai 29, 2013 11:51 am

Próximo

Voltar para Análise de AWR

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 2 visitantes