Além de um especialista AIX, penso que vc CERTAMENTE precisará de um
especialista em RDBMS Oracle , que deverá verificar :
- se o tamanho dos redo log files está apropriado (na casa dos GBs,
provavelmente, se a geração de redo é intensa) para evitar log file switch ou
(ainda pior) espera por archive/limpeza se os redo log files todos já foram
usados ? Na mesma toada, EM ALGUNS CASOS um leve aumento do log buffer possa
ser viável, DEPENDENDO do tamanho atual
- se a configuração / distribuição de I/O está adequada : os /u05 e /u06
parecem indicar que vc está usando FILESYSTEM, e nem todos os tipos de
filesystem permitem I/o ASÍNCRONO e em DIRECT MODE, coisas muitas vezes Vitais
para a performance ... Em especial, via de regra é Inútil e Contra-produtivo se
ter CACHEs nos filesystem usados pelo Oracle, pois ele Já Mantém seus próprios
caches internos : cachear um cahe Não É recomendado na maioria dos cenários
- se a configuração do dataguard está ok , com a presença de STANDBY LOGFILES,
archives (já que deve ser dataguard físico) sendo enviados por uma rede
DEDICADA entre os servidores (não faz o menor sentido o envio de archives
concorrer com os usuários finais na rede Pública)
- ainda sobre o dataguard, vc diz que os redos são "recebidos de forma
síncrona" : o dg está operando em zero data-loss mode ?? Se sim, tranquilamente
PODE SER que o hardware (principalmente a infra de rede) não esteja suportando
a carga inerente a esse modo, aí OU se passa a trabalhar em maximum performance
OU se melhora a infra
- se a distribuição de RAM está OK : fiquei principalmente encafifado quando
vc diz que dos " 36gb de memória ram, 20gb para a instancia principal, 5gb para
uma outra instancia" - vc estava falando de que, SGA ?? Se sim, vc Sabe que
também é CRUCIAL se reservar memória para PGA e para os processos locais ?? A
regra de dedão de algo em torno de 20% a 40% (máximo) da RAM para a SGA visa
justamente ter uma segura margem de folga de RAM para os usos AFORA a SGA , a
SGA ** não é ** de forma nenhuma toda a RAM que o RDBMS precisa. O especialista
em RDBMS deveria SIM considerar muito seriamente a possibilidade de diminuir
severamente esses 20 GB se isso é o sizing da SGA
- o Planejamento para aplicação dos PATCHES : 11.2.0.3.0 indica que vc IGNOROU
TOTALMENTE PSUs/CPUs do 11.2.0.3, e também não aplicou o patchset 11.2.0.4
Com isso feito, aí sim especialista em RDBMS poderia usar as tools de análise
cabíveis (AWR/ASH/Statspack, Trace, Consulta Periódica com Histórico das V$ de
estatísticas de uso e execução de SQLs) para produzir um healthcheck desse
banco, tendo assim subsídios para demandar eventuais alterações na Aplicação
(principalmente por causa dos sintomas de grande número de commit wait e
concorrência que vc diz ter encontrado).
[]s
Chiappa
