Menu de navegação

[LourivalParticipante]

Estamos enfrentando um problema aqui, segue abaixo descrição:
> Banco de Dados: Oracle 10g Release 1 – Sistema operacional:
Linux Red Hat Enterprise.
> Servidor HP Proliant ML539 com 4GB de RAM,Xeon Intel e 4 HD SATA de 250GB montadas em RAID 1+0
> O Banco fica muito lento em períodos aleatórios durante o dia e
nos últimos dias o mesmo tem travado de madrugada. Só sendo recuperado
derrubando e subindo ele novamente.
> Observamos (com o comando top) que sempre que ele está lento o
oracle ocupa a CPU por volta de 56% e quando o mesmo
volta a ficar baixo a velocidade normaliza.
> Testamos várias possibilidades e não achamos nenhum processo em
particular causando isso.
Alguém pode ajudar? ❓

[vieriParticipante]

stastapck, awr , addm , E.M , querys , wait’s events ….

[Marcio68AlmeidaParticipante]

Além das opções fornecidas pelo nosso amigo Vieri.
Você também pode olhar o I/O em disco e a rede.

Mas é sempre necessária a visita de um DBA qualificado para analisar o problema pessoalmente…

Qual é o Load Average nos momentos de lentidão ?

[ramasineParticipante]

Qual a característica do banco…OLTP ou DW ??

Uma análise mais minuciosa as ferramentas de report da própria Oracle, deve te ajudar bastante a achar os processos ofensores..!!

[LourivalParticipante]

Valew, galera.

O load average tá em 79% no momento de pico.
a lentidão ocorre quando as máquinas via gigabit,
mandam gravar informações no banco, através de 1 aplicativo Java.

O Banco recebe dados de 6 outras bases,mas esse processo não causa nenhum problema.
Os usuários usam o aplicativo Java (+Genexus) para corrigir alguns campos da tabela, e fazem o update.
Nas máquinas deles é notado a lentidão geral.

Já foram feitos testes físicos na rede e hardware, e nada foi encontrado.
Vamos começar a examinar melhor as SQLs q estão no aplicativo.

Obrigado pela atenção.

[Marcio68AlmeidaParticipante]

Bom…
79 de Load Average é um número que nem eu consegui chegar, e olha que as apicações que rodam aqui são ruins…

Ao que tudo indica, o seu problema é bem semelhante ao que eu tenho aqui, na hora de ler/grtavar grandes quantidades de informação, os discos pedem pinico…
Você está trabalhando com storage ?
Qual a velocidade de gravação dos teus discos ?
No momento que as gravações são executadas, você sabe se também são executadas consultas pesadas ?

[LourivalParticipante]

o máximo do load average agora é de 3.4
ainda assim continua lento.
são 3 users: SVP,ETR e P4
o ETR é quem manda os dados de outras 6 bases,
em pacotes pequenos, nada de erros.
o P4 somente as vezes manda alguma coisa,e bem pouco.
já o SVP,trabalha muito, são 6 terminais com aplicativos,
e + 3 máquinas que alteram e gravam na base.

Será q há alguma instrução SQL q causa o problema,isso é possível?

Continuamos na luta! 🙂

[Marcio68AlmeidaParticipante]

[quote=”Lourival”:ynqnxmiz]Será q há alguma instrução SQL q causa o problema,isso é possível?

Continuamos na luta! 🙂 [/quote]

Não tenha dúvida que alguma consutla ou processo de atualização está gerando essa demora…
Você percebeu se há processos em LOCK nesse horário ?

[IshiiParticipante]

Olá,

Pergunta: quando trava de madrugada o que aparece no Alert.log?

Há algum processo agendado para esses horários?

[]s Ishii

[LourivalParticipante]

A saga continua!

Estamos fazendo um upgrade no servidor, mais espaço em HD, mais memória.
Esperamos aumentar a performance da máquina e assim ter condições para avaliar melhor o Banco.

Obrigado a todos q responderam.

[fsitjaParticipante]

Minha bola de cristal sempre aponta para duas coisas:

1 – update sem uso de bind variables;
2 – update em loops (ou loops aninhados) que poderiam ser feitos num comando só ou em lote (bulk binding).

Não tem hardware que conserte isso… apenas é paliativo pois não há escalabilidade nessas soluções acima.

Meus 2 cents.

[IshiiParticipante]

Olá,

Já vi um caso de uma aplicação que chamava uma procedure que chamava outra procedure e assim ia por volta de umas 30 ou 40 procedures. O problema era quando uns 50 usuários chamavam a primeira simultaneamente ou não…aparentemente não fica nenhuma muito lenta mas o “conjunto da obra” ficava…. o Load Average era por volta de 50% no horário de uso chegando a incríveis 95% e fora dele caia para 2 ou 1%.

Cada caso é um caso… vale pela experiência e pelas dicas conseguidas com todos…

Abraços

Ishii

[LourivalParticipante]

o resumo da obra ficou assim:

1 – Servidor feito upgrade.

2 – Otimizado o BD Oracle

3 – Politica de Backup reformulada

Estamos desde as 09:00hs migrando o BD completo
para um Storage e logo vamos colocar o HP Proliant 5G
no ar.

Só ficou o aplicativo para ser periciado.
no mais, a experiência sempre é válida.

valew, pessoal.

[rovilsoParticipante]

Olá Lourival e demais amigos

Mesmo que o problema está se encaminhando para a solução, gostaria de deixar o registro para que nunca seja utilizado discos SATA para tarefas nobres e que exigem bastante acesso à disco, como é o caso.

A tecnologia SATA foi desenvolvida para ser um substituto ao HD IDE, ou seja, para desktops. Os storages ou servidores que aceitam o que se chama de “SATA Corporativo” servem para uma coisa apenas: backup em disco, onde existem grandes volumes de dados e a gravação predominante é sequencial. Pode até ser RAID 1 + 0, se o acesso for randômico e em altas taxas, é certo como 2 + 2 são 4 que os discos SATA não irão aguentar.

Nestes casos sempre utilize discos SAS ou FC. Estes são realmente para uso corporativo, com características de acesso full-duplex, desenvolvidos para obter alta performance com tempo de resposta em ms bem menor do que os SATA, velocidade de rotação maior e também suportando uma quantidade de I/O por segundo quase 3x maior que os primos mais singelos.

Abraços,
Rovilso

[PetersonParticipante]

Rovilso,

Muito boa sua colocação! Muito útil e pertinente!

[Autor]

Posts