[oracle_br] Re: Lentidao no Banco apos nova instalacao - ORACLE 9i
--- Em oracle_br@yahoogrupos.com.br, "Juliano" <[EMAIL PROTECTED]>
escreveu
>
> Será que meu problema nao pode ser devido antigamente esse Banco
> possuir as Tablespaces de Índices em um HD SCSI de 15000RPM e as de
> Dados em outro SCSI de 1RPM. E agora na nova instalacao, todas
> as tablespaces ficaram SOMENTE em um disco SCSI de 1RPM ???
> Até que ponto isso pode ser tão impactante na performance??
Bom, estamos aqui fazendo palpites & adivinhações, já q NÂO temos a
info precisa, mas o que pode "pegar" muitas vezes não é o fato de se
ter tablespaces de dados junto com índices, isso em si normalmente
não causa impacto tão grande , o que impacta mais é qtdade de discos
JUNTO com a vazão da controladora : em cima disso, o fato de vc ter
um disco pode tanto ser negativo quanto positivo. Caso 1, imagine que
a controladora NÃO tenha múltiplos canais simultâneos e/ou não tinha
vazão, não tinha capacidade suficiente pra atender dois discos
simultaneamente, num caso desses fatalmente os pedidos de I/O de um
disco se acumulariam enquanto o outro está sendo "rodado", está sendo
acessado pra se atender à pedidos de I/O anteriores, PORTANTO os RPMs
do outro disco basicamente NÃO estão sendo aproveitados ao
máximo Caso 2, imagine que a controladora TEM capacidade de rodar
os dois discos, de atender aos dois discos simultaneamente, aí
simultaneamente enquanto está fazendo I/O no disco 1 pode iniciar e
fazer outro I/O no outro disco, num caso desses se vc tirar um dos
discos, fatalmente haverá queda no throughput, I/Os que antes eram
simultâneos passam a precisar de enfileiramento
==>> Então é isso, DEPENDENDO do caso vc tirar discos PODE até ser
positivo ("baixando" a carga da controladora que não suportava o
nível anterior) embora logicamente aumentando a fila de processos em
wait, ou PODE (o que é mais comum) ser negativo, indisponibilizando
I/O simultâneo... Já que vc NÃO DIZ qual era o caso (provavelmente
por não saber), fica absolutamente IMPOSSÍVEL se dizer mais sobre o
que aconteceu... Justamente pra não sa ficar no escuro, se vc atende
a vários clientes vc TEM QUE ter (ou ao menos ensiná-los a ter) uma
listinha mais direitinha do hardware exato que eles têm, dos params
de SO e do banco... E seria bom se vc tivesse/mantesse também uma
breve HISTÓRICO do uso desse hardware pelo banco , seja com comandos
do SO (como iostat, netstat, top/glance/sar, etc), seja até mesmo (já
que vc está com banco 9i) coletando estatísticas de sistema via
dbms_stats.gather_system_stats num período significativo... Senão vc
tá num mato sem cachorro, não dá pra adivinhar o que aconteceu SE vc
não tiver um registro, breve e simples que seja...
> Quanto os parametros que informei da V$PARAMETER, para o seguinte
> hardware, o que o pessoal da lista acha??? Tem algo super ou sub
> estimado??
>
==> Já falamos algumas vezes, TORNO a repetir : params de banco NÃO
PODEM ser setados só em cima do hardware, outros fatores que só vc
pode obter, tal como o TIPO DE USO (se OLTP ou dw/batch), qtdade
máxima de usuários simultâneos, média de consumo de CPU, undo, redo e
RAM por sessão, tipo de conexão, etc, tem SIM um papel ** chave **
nesse config... Com isso em mente, sabendo portanto que estamos
comentando SEM essas infos, portanto usando bom-senso e idéias gerais
e genéricas apenas, a recomendação seria vc subir um pouco esses
params, de modo geral e genérico se recomenda que a SGA (memória
total alocada pelo bd, inclui pools e caches) seja inicialmente
setada em algo por volta de uns 30% da RAM existente e depois vc vai
subindo e monitorando, e pelo q vejo hoje vc está bem bem abaixo dos
30% do seu 1 Gb de RAM, acho q é seguro vc os subir um pouco... Da
mesma forma, SE vc tem conexões dedicadas/diretas apenas , e vc não
tem um montão enorme de sessões simultâneas, a PGA (ie, a RAM alocada
pra cada sessão) pode subir um pouco + a meta estipulada em
pga_aggregate_target.
[]s
Chiappa
--
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--__
OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE:
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
h
[oracle_br] Re: Lentidao no Banco apos nova instalacao - ORACLE 9i
Chiappa, mais uma vez muito obrigado por colaborar com o seu conhecimento. Minha dúvida é a seguinte: Será que meu problema nao pode ser devido antigamente esse Banco possuir as Tablespaces de Índices em um HD SCSI de 15000RPM e as de Dados em outro SCSI de 1RPM. E agora na nova instalacao, todas as tablespaces ficaram SOMENTE em um disco SCSI de 1RPM ??? Até que ponto isso pode ser tão impactante na performance?? Quanto os parametros que informei da V$PARAMETER, para o seguinte hardware, o que o pessoal da lista acha??? Tem algo super ou sub estimado?? Servidor IBM xSeries 232 - HD SCSI 1RPM - 1256Mb RAM - 2 Processadores PIII de 1.13Ghz db_cache_size: 50331648 large_pool_size: 16777216 log_buffer: 524288 pga_aggregate_target: 50331648 sga_max_size: 319886536 shared_pool_reserved_size: 7549747 shared_pool_size: 150994944 Agradeco a atencao e ajuda Juliano Martinez da Silva --- --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > --- Em oracle_br@yahoogrupos.com.br, "Juliano" <[EMAIL PROTECTED]> > escreveu > > > > Bom Dia Lista !! > > > > Realizei a instalacao do Oracle 9.2.0.4 em um cliente. > > Junto com essa instalacao, criei as tablespaces e importei os dados > > do export existente. > > Motivo: O HD existente havia queimado e nao havia um plano de > > contingência. > > > > Problema: Todos os usuarios informaram, que apos a nova instalacao, > > notavelmente havia um ganho de performance de aproximadamente 30% > em > > velocidade. > > Colega, absolutamente só com esse tipo de info não dá nem pra se > chutar direito o que pode ser, mas será que : > > a) antes estava com outra versão inferior de Oracle que por algum > bug não estava performando bem ? > b) será que ese tal hd que "queimou" já não tava dando problema > antes , tava com montes de setores ruins, e isso interferia na > performance ?? > c) será que o banco estava com algum parâmetro de inicialização > ultra-errado, e quando vc instalou novo banco, o parãmetro ficou com > um valor mais adequado ??? > d) será que antes o banco não estava com uma estrutura física > inadequada (por exemplo, usava tablespaces não-LMT) e quando vc re- > instalou ficou certa > e) será que as ESTATÍSTICAS das tabelas/índices estavam ultra- > erradas/defasadas, e quando vc recriou as stats foram recriadas, ou > ainda simplesmente as estats que vieram do .dmp estavam melhores > f) será que não havia algum prob no sistema > operacional/drivers/kernel ou coisa do tipo, e quando o técnico > substituiu o disco "queimado" não corrigiu isso também ??? > > QUALQUER uma dessas opções entre N+1 outras pode ter causado isso... > > > > > Acontece que ** SOMENTE ** em UMA transacao do Sistema > > Cliente/Servidor deles, os tempos simplesmente passaram a demorar > 3x > > mais do que antes. > > Então tá fácil, é nessa UMA transação que deve ser feita uma análise. > > >... pode-se > > verificar que a mesma possui muitos updates e inserts, e só commita > > no final !!! > > O que é TOTALMENTE o correto, via de regra COMMIT deve ser feito só > quando a transação lógica acaba, só quando necessário mesmo... > > O trabalho que vc vai ter que fazer aí VAI implicar alguma > necessidade de DBA (pra se verificar como estão criadas as > tablespaces de rollback/undo e temp, e os logs de banco), E alguma > necessidade de desenvolvimento (pra INSTRUMENTAR a rotina em questão > de modo que se possa acompanhar quanto tempo cada ação dentro dela > está demorando), e também para se extrair planos de execução e > eventuais traces, neste último caso com o dba. Assim, a recomendação > é que, se vc não tem algum conhecimento de DBA, trabalhe junto com > alguém que o tenha, é isso, facilitará em muito. > > []s > > Chiappa > -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: http://www.oraclebr.com.br/ __ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Lentidao no Banco apos nova instalacao - ORACLE 9i
Chiappa desculpe entrar no meio da conversa mas vc poderia me explicar melhor, ou me passar referências, sobre o uso de tablespaces limitadas ou não? Eu não entendi como este parâmetro interfere na performance. Obrigado Marco - Original Message - From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Friday, August 18, 2006 2:52 PM Subject: [oracle_br] Re: Lentidao no Banco apos nova instalacao - ORACLE 9i --- Em oracle_br@yahoogrupos.com.br, "Juliano" <[EMAIL PROTECTED]> escreveu > > Bom Dia Lista !! > > Realizei a instalacao do Oracle 9.2.0.4 em um cliente. > Junto com essa instalacao, criei as tablespaces e importei os dados > do export existente. > Motivo: O HD existente havia queimado e nao havia um plano de > contingência. > > Problema: Todos os usuarios informaram, que apos a nova instalacao, > notavelmente havia um ganho de performance de aproximadamente 30% em > velocidade. Colega, absolutamente só com esse tipo de info não dá nem pra se chutar direito o que pode ser, mas será que : a) antes estava com outra versão inferior de Oracle que por algum bug não estava performando bem ? b) será que ese tal hd que "queimou" já não tava dando problema antes , tava com montes de setores ruins, e isso interferia na performance ?? c) será que o banco estava com algum parâmetro de inicialização ultra-errado, e quando vc instalou novo banco, o parãmetro ficou com um valor mais adequado ??? d) será que antes o banco não estava com uma estrutura física inadequada (por exemplo, usava tablespaces não-LMT) e quando vc re- instalou ficou certa e) será que as ESTATÍSTICAS das tabelas/índices estavam ultra- erradas/defasadas, e quando vc recriou as stats foram recriadas, ou ainda simplesmente as estats que vieram do .dmp estavam melhores f) será que não havia algum prob no sistema operacional/drivers/kernel ou coisa do tipo, e quando o técnico substituiu o disco "queimado" não corrigiu isso também ??? QUALQUER uma dessas opções entre N+1 outras pode ter causado isso... > > Acontece que ** SOMENTE ** em UMA transacao do Sistema > Cliente/Servidor deles, os tempos simplesmente passaram a demorar 3x > mais do que antes. Então tá fácil, é nessa UMA transação que deve ser feita uma análise. >... pode-se > verificar que a mesma possui muitos updates e inserts, e só commita > no final !!! O que é TOTALMENTE o correto, via de regra COMMIT deve ser feito só quando a transação lógica acaba, só quando necessário mesmo... O trabalho que vc vai ter que fazer aí VAI implicar alguma necessidade de DBA (pra se verificar como estão criadas as tablespaces de rollback/undo e temp, e os logs de banco), E alguma necessidade de desenvolvimento (pra INSTRUMENTAR a rotina em questão de modo que se possa acompanhar quanto tempo cada ação dentro dela está demorando), e também para se extrair planos de execução e eventuais traces, neste último caso com o dba. Assim, a recomendação é que, se vc não tem algum conhecimento de DBA, trabalhe junto com alguém que o tenha, é isso, facilitará em muito. []s Chiappa [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: http://www.oraclebr.com.br/ __ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: Lentidao no Banco apos nova instalacao - ORACLE 9i
--- Em oracle_br@yahoogrupos.com.br, "Juliano" <[EMAIL PROTECTED]> escreveu > > Bom Dia Lista !! > > Realizei a instalacao do Oracle 9.2.0.4 em um cliente. > Junto com essa instalacao, criei as tablespaces e importei os dados > do export existente. > Motivo: O HD existente havia queimado e nao havia um plano de > contingência. > > Problema: Todos os usuarios informaram, que apos a nova instalacao, > notavelmente havia um ganho de performance de aproximadamente 30% em > velocidade. Colega, absolutamente só com esse tipo de info não dá nem pra se chutar direito o que pode ser, mas será que : a) antes estava com outra versão inferior de Oracle que por algum bug não estava performando bem ? b) será que ese tal hd que "queimou" já não tava dando problema antes , tava com montes de setores ruins, e isso interferia na performance ?? c) será que o banco estava com algum parâmetro de inicialização ultra-errado, e quando vc instalou novo banco, o parãmetro ficou com um valor mais adequado ??? d) será que antes o banco não estava com uma estrutura física inadequada (por exemplo, usava tablespaces não-LMT) e quando vc re- instalou ficou certa e) será que as ESTATÍSTICAS das tabelas/índices estavam ultra- erradas/defasadas, e quando vc recriou as stats foram recriadas, ou ainda simplesmente as estats que vieram do .dmp estavam melhores f) será que não havia algum prob no sistema operacional/drivers/kernel ou coisa do tipo, e quando o técnico substituiu o disco "queimado" não corrigiu isso também ??? QUALQUER uma dessas opções entre N+1 outras pode ter causado isso... > > Acontece que ** SOMENTE ** em UMA transacao do Sistema > Cliente/Servidor deles, os tempos simplesmente passaram a demorar 3x > mais do que antes. Então tá fácil, é nessa UMA transação que deve ser feita uma análise. >... pode-se > verificar que a mesma possui muitos updates e inserts, e só commita > no final !!! O que é TOTALMENTE o correto, via de regra COMMIT deve ser feito só quando a transação lógica acaba, só quando necessário mesmo... O trabalho que vc vai ter que fazer aí VAI implicar alguma necessidade de DBA (pra se verificar como estão criadas as tablespaces de rollback/undo e temp, e os logs de banco), E alguma necessidade de desenvolvimento (pra INSTRUMENTAR a rotina em questão de modo que se possa acompanhar quanto tempo cada ação dentro dela está demorando), e também para se extrair planos de execução e eventuais traces, neste último caso com o dba. Assim, a recomendação é que, se vc não tem algum conhecimento de DBA, trabalhe junto com alguém que o tenha, é isso, facilitará em muito. []s Chiappa -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --__ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: http://www.oraclebr.com.br/ __ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
