Menu de navegação

[HitotuziParticipante]

Pessoal,

Continuo com o problema de lentidão ao conectar, bem após observações fui eliminando as possibilidades de problemas, verifiquei que o problema resolve quando eu reinicio o serviço do oracle juntamente com o listener, e durante o decorrer do dia o banco vai perdendo performance, ficando cada vez mais lento para conectar, como se algo tivesse enchendo e ultilizando os recursos. Aumentei a pga continuou a lentidão, aumentei o log_buffer (512kb * cpu_count) no meu caso ficou 4 MB e houve uma pequena melhora, porém continua com o decorrer das transações a lentidão, analisando o alert_log, não apresentou erros, porém verifiquei que no momento em a lentidão atinge o auge, o alert log informa que esta sendo preencido o REDOLOG. Meu banco é um Oracle 9i Release 2, este banco há um mês sofreu um aumento no volume de dados de 50% , aumentou o número de transações(SELECTS, INSERT, UPDATE, DELETE) daí esse problema de lentidão apareceu, ele possui 3 REDOLOG cada um com 100MB, esta em modo NO ARCHIVELOG ou seja, não gera arquivos, presumi que está havendo lendidão na hora do preenchimendo dos arquivos REDOLOGS… Então para resolver tenho algumas dúvidas:

1 aumentar o tamanho dos REDOLOG?
2 aumentar novamente o tamanho do parametro log_buffer ?
3 incluir mais um REDOLOG totalizando 4 REDOLOG de 100MB cada?
4 Essa lentidão no preenchimento do REDOLOG pode ser devido ao arquivo está corrompido?

Se alguem puder ajudar, ja estou há mais de 10 dias tentando resolver isso
Desde já agradeço!

[Christiano RiosParticipante]

Você pode informar o tempo de alternância de log? Geralmente aplicações mal projetadas geram alternâncias de logs muito frequentes, o que deteriora o desempenho. É preciso ver também o tamanho do buffer de log, pois as transações precisam aguardar o flush para os redo log online. Um buffer pequeno enche logo.
Outro fator importante é a quantidade de redo logs por grupo, e a distribuição destes em discos separados. Nem um extremo nem outro. Muitos redo logs geram mais trabalho para serem administrados pelo servidor. Você não mencionou, mas também seria bom analisar as disputas por bloqueio de objetos (Não me refiro a deadlocks). Já vi casos de lentidão e aumento do load no servidor ocasionados por bloqueios indevidos em várias partes do sistema. O enfileiramento de espera por locks aumenta, degradando o desempenho. Há um script do Oracle que ajuda bastante o DBA: utllockt.sql.

[Ricardo Portilho ProniParticipante]

É 9i?

Mostre para nós:
select * from v$database;
select * from v$instance;
show parameter log_archive
show parameter dest_1
show parameter dest_2

[HitotuziParticipante]

Bom dia,

    O tempo de alternância de log é em média 13 minutos, são 3 arquivos de REDOLOG de 100MB cada, o parâmetro log_buffer está setado para 4 MB Obedecendo a regra (512kb * cpu_count).

select * from v$database;

dbid: 43087394
name: sisgprd
created: 11/11/2011 10:40:34
resetlogs_change#: 190578
resetlogs_time: 11/11/2011 10:40:34
prior_resetlogs_change#: 1
prior_resetlogs_time: 12/5/2002 16:16:56
log_mode: noarchivelog
checkpoint_change#: 3107165926
archive_change#: 3107004571
controlfile_type: current
controlfile_created: 11/11/2011 10:40:34
controlfile_sequence#: 144540
controlfile_change#: 3107165926
controlfile_time: 11/9/2012 08:09:31
open_resetlogs: not allowed
version_time: 11/11/2011 10:40:34
open_mode: read write
protection_mode: maximum performance
protection_level: unprotected
remote_archive: enabled
activation#: 43091746
database_role: primary
archivelog_change#: 0
switchover_status: sessions active
dataguard_broker: disabled
guard_status: none
supplemental_log_data_min: no
supplemental_log_data_pk: no
supplemental_log_data_ui: no
force_logging: no

select * from v$instance;

instance_number: 1
instance_name: sisgprd
host_name: server03
version: 9.2.0.1.0
startup_time: 11/9/2012 08:09:23
status: open
parallel: no
thread#: 1
archiver: stopped
log_switch_wait:
logins allowed:
shutdown_pending: no
database_status: active
instance_role: primary_instance
active_state: normal

show parameter log_archive

log_archive_dest string
log_archive_dest_state_1 string enable
log_archive_dest_state_10 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_state_6 string enable
log_archive_dest_state_7 string enable
log_archive_dest_state_8 string enable
log_archive_dest_state_9 string enable
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_2 string
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string
log_archive_duplex_dest string
log_archive_format string ARC%S.%T
log_archive_max_processes integer 2
log_archive_min_succeed_dest integer 1
log_archive_start boolean FALSE
log_archive_trace integer 0

show parameter dest_1

db_create_online_log_dest_1 string
log_archive_dest_1 string
log_archive_dest_10 string

show parameter dest_2

db_create_online_log_dest_2 string
log_archive_dest_2 string

[Ricardo Portilho ProniParticipante]

Dobre a quantidade de Redo Logs e acompanhe.
Sua lentidão deve ocorrer quando atinge o último redo, tem que voltar a utilizar o primeiro, mas os dados que estão nele ainda não foram gravadas em datafiles.

Para provar, em um momento de lentidão, veja se na V$LOG tem um CURRENT e dois ACTIVE. E veja se no Alert Log tem “Checkpoing not complete”.

[HitotuziParticipante]

Olá Ricardo,

        Primeiramente obrigado pela resposta, bem no momento está começando a ficar lendo, pois reinicei a instância há + ou - uma hora e maia atrás, visualizando a v$log agora está INATIVO, ATIVO e CORRENTE no alert_log esta preenchendo o REDOLOG 3, sua sugestão seria criar mais 3 REDOLOG de 100Mb totalizando 6 arquivos REDOLOG? o parâmetro log_buffer continuaria 4MB ou deve ser amentado também?

[Ricardo Portilho ProniParticipante]

Olá.
Sim, crie mais 3 Redos de 100MB cada.

alter database create logfile ‘/CaminhoDosRedos/redo04.log’ size 100m;
alter database create logfile ‘/CaminhoDosRedos/redo05.log’ size 100m;
alter database create logfile ‘/CaminhoDosRedos/redo06.log’ size 100m;

[HitotuziParticipante]

Ok Ricardo, vou criar e monitorar, obrigado!

[Ricardo Portilho ProniParticipante]

Nos avise se resolver.
abraço !

[PetersonParticipante]

Bom dia Portilho,

Caso ele optasse por dobrar o tamanho dos Redo Logs ao invés de dobrar o número de arquivos, o efeito seria o mesmo?

[Ricardo Portilho ProniParticipante]

Sim, seria o mesmo.

[HitotuziParticipante]

Bom dia Ricardo,

     Aumentei dobrando o tamanho dos 3 REDOLOGS ao invés de criar mais 3 ajustei a SGA pois li sobre a disponibilização de memória para aplicativos no windows server 32-bi com 4g de RAM existe umas particularidades.  Durante esses 10 dias que monitorei, houve uma melhora de 70% o te tempo de troca de REDOLOS amenrou mara  30min e melhorou a performance, ainda não está como antes... fiquei monitorando no momento da lentidão e verifiquei que a tabanho alocado para Shared Pool rapidamente vai diminuido, pesquisei e achei o comando que limpa a Shared Pool.

ALTER SYSTEM FLUSH SHARED_POOL;

     Pegunto a vc em que implica ao banco a ultilização frequente desse comando?

[Ricardo Portilho ProniParticipante]

Não há relação da Shared Pool com os Redo Logs.
A Shared Pool geralemnte vai se enchendo de SQLs compilados, é assim mesmo. O Flush fará ela ter todo o trabalho de compilação novamente.
Tire um Statspack (é 9i né?) do período da lentidão e coloquei aqui (não sei se dá). Nele saberemos qual a exata causa da lentidão.

[Autor]

Posts