--- Em oracle_br@yahoogrupos.com.br, "rei_do_delphi" <[EMAIL PROTECTED]> escreveu > > entendi, mas via de regra, utilizamos somente as views dinâmicas para > monitorar o desempenho do banco?
Somente elas não, há outras fontes, como traces e dumps,ou mesmo as tabelas internas do sistema que alimentam as views mas sim, as views dinâmicas tem papel IMPORTANTE pra isso. Lembro que há também ** utilitários ** do banco (como Statspack e OEM, entre outros) que consolidam a informação das views em relatórios, ajudam também. O conhecimento da arquitetura do banco é FUNDAMENTAL também - só pra manter no tópico, por exemplo, por não saber que algo por volta de 1 Mb é gatilho de flush do log buffer, é COMUM PRACAS vc ver por aí bancos com DEZENAS de Mbs de log buffer, puro desperdício... > > para definir tamanho de SGA é meio que no chute e depois reparando as > arestas? Sim basicamente, mas *** tem *** que ser um chute EDUCADO, muitíssimo na direção do gol adversário, vc chutar no sentido da torcida ou do seu próprio gol só PODE dar enrosco... Assim (por exemplo) em a pessoa sabendo o fato de que a SGA é uma área basicamente FIXA e que será usada para caches ** MAS ** não é a única ,já que por default a cada conexão alguma RAM extra é alocada para dados particulares da sessão (PGA) , isso leva a pessoa a NÃO EXAGERAR no tamanho da SGA, justamente para SOBRAR RAM pras PGAs e assim evitar swap.... A idéia é vc setar a SGA pra um tamanho nem tão grande ,no qual HAJA boa sobra para PGAs e demais alocações temporárias , nem tão pequeno em que os caches do Oracle se tornem inefetivos... Muitas vezes como chute inicial (SE não há outros softs na máquina consumindo/querendo consumir RAM, o que SÓ VOCÊ saberá) se dá algo entre 30% a 40% da RAM livre no sistema pro banco Oracle, a sobra tipicamente é algo que muitas vezes dá pra cobrir o resto do consumo, mas isso é um chute inicial, que terá SIM que ser validado.... INCLUSIVE, imho essa validação ao menos num estágio inicial ** NÃO PRECISA ** esperar pelo aplicativo ser desenvolvido, mesmo enquanto ainda está rolando modelagem e aprovação etc, facilmente os programadores podem (em se sabendo se é sistema OLTP ou batch, conhecendo mais ou menos alguns objetos importantes no sistema, dados como acessos simultâneos, linguagens/tools que serão usadas, etc) criar protótipos que façam açoes ao menos de modo geral parecidas com o que o sistema será, aí o DBA pode ir validando os seus chutes iniciais , ao menos um pouco. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "rei_do_delphi" <[EMAIL PROTECTED]> escreveu > > entendi, mas via de regra, utilizamos somente as views dinâmicas para > monitorar o desempenho do banco? > > para definir tamanho de SGA é meio que no chute e depois reparando as > arestas? > > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchiappa@> > escreveu > > > > Acho que é interessante acrescentar : logicamente, esse "ajuste > > dinâmico" ** não é ** "de graça" em termos de performance, > > tranquilamente race conditions , monitoração ficando pesada ou > > simplesmente ineficiência do algoritmo podem SIM ocorer em ambientes > > de grande porte e concorrência, como lembrado em > > http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/ . > > Assim sendo, automatismos do tipo num banco de grande porte (seja > por > > causa do grande número de usuários se OLTP, ou por causa da > > complexidade das queries se DW/batch) , pnesra duas vezes antes de > > sair ativando os automatismos de RAM (seja SGA automática, PGA > > automática)... > > Quanto à outra questão sim, concordo com vc, tamanho de log buffer > e > > pools de RAM não tem *** NADA VEZES NADA *** a ver com tamanho de > data > > files ou qtdade de registros presentes , mas sim com QUANTOS > > registros, QUANTOS % do datafile (em blocos) é tipicamente acessado, > > info essa que é PARTICULAR para cada aplicação/ambiente. O negócio > > então é mesmo iniciar com um valor mínimo/razovel e ir monitorando, > > sim, trabalho típico de DBA... > > > > []s > > > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "Carlos Alfredo Martins > Menezes" > > <carlos.menezes@> escreveu > > > > > > Colega, > > > A orientação da Oracle a partir da versão 10g é usar o modo > > automático de gerenciamento de memória, ou seja, a sua SGA fica com > > gerenciamento automático e ajustando dinamicamente os diversos pools > > de acordo com a necessidade (ver um pouco sobre Asmm EM: > > > http://www.oracle.com/technology/pub/articles/10gdba/week17_10gdba.htm > l), > > óbviamente os mecanismos manuais ainda estão disponíveis. Quanto ao > > pool de logfile, um tamanho muito grande em nada irá ajudar, pois o > > LGWR ativa a gravação quando supera 1MB, até onde sei, o > > dimensionamento destes pool´s não estão diretamente relacionados com > > os tamanhos dos datafiles, é mais confiável medir a necessidade em > > função das aplicações. > > > > > > Abraços, > > > > > > Carlos Alfredo M. de Menezes > > > Analista de Suporte Sr. > > > S/A Usina Coruripe Açúcar e Álcool > > > > > > > > > ________________________________ > > > > > > De: oracle_br@yahoogrupos.com.br > > [mailto:[EMAIL PROTECTED] Em nome de rei_do_delphi > > > Enviada em: segunda-feira, 16 de julho de 2007 15:31 > > > Para: oracle_br@yahoogrupos.com.br > > > Assunto: [oracle_br] Tamanho de Buffer Pool, Shared Pool, e Log > Buffer > > > > > > > > > > > > gostaria de saber também como dimensionar o tamanho de buffer > pool, > > > shared pool e log buffer, se existe alguma maneira de ver isso, > > > baseando-se no tamanho dos data-files ou na quantidade de inserts > ou > > > updates ou deletes que se tem no database. Obrigado pela ajuda e > > > paciência de todos. > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > >
