Olá Chiappa, tudo bem ? você conseguiu ver os scripts lá no seu livro? pois eu tenho o livri em pdf, ai não preciso estar comprando... ai mando imprimir.. fica mais facíl.
att, Welvis Douglas ----- Mensagem original ---- De: jlchiappa <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 4 de Maio de 2007 14:07:32 Assunto: Res: [oracle_br] Re: Eventos de Espera.? Ah, pra complementar ficou faltando eu dizer mais algumas coisas :primeiro, de forma alguma vc deveria estar preocupado com o fato de "aparecerem muitos full scans", NEM SEMPRE um full scan é "mau", nem sempre é "bom"... O que vc tem que estar preocupado é com a EFICIÊNCIA, com quantos logical I/Os vc teve que fazer.... Assim, se um dado plano está fazendo um full scan MAS vc testou e sabe que a query vai recuperar poucas linhas E que se usar um índice y, ou se fazer um hash join ao invés de nested loop, ou o que for, vc obtém a mesma resposta com qtdade de LIOs menor, ENTÃO SIM esse full scan é "mau", já se vc quer ler uma larga proção da tabela, quer aplicar paralelismo, não há como se acessar via índice porque alguma das colunas indexadas não está no WHERE ou não está sendo restringida por valor algum, AÍ um suculento full scan é ** exatamente ** o que o dr. recomendou, esse full scan é "bom"... Quanto à eficiência, é se assegurar que o scan acessa a MENOR quantidade de blocos possíveis no MENOR TEMPO : por exemplo se vc tiver uma high-water mark desnecessariamente alta vc vai ter lotes de blocos inúteis sendo lidos, se o seu db_file_multiblock_ read não estiver no máximo aceitável pelo SO + hardware, E/OU se o extent size não for adequado, vc não está lendo o máximo possível no menor tempo.... Da mesma forma, quando eu falei em "alteração física" em msg anterior, quero dizer algo do tipo : SE vc deixar a storage como default quando cria uma tabela, o bd VAI deixar um monte de espaços "vazios" à espera de futuros UPDATEs, então a mesma quantidade de linhas com o default ocupa via de regra MUITO MAIS blocos do que se vc tivesse não reservado esse espaço, menos blocos implica em menos I/O... Outras alterações físicas podem ser ** extremamente ** úteis, por exemplo : se vc frequentemente precisa recuperar apenas os relativamente poucos registros dos clientes do estado SP, vc ter um índice que indexa apenas essa porção dos dados 9via FUCNTION INDEX) talvez aceleraria ENORMEMENTE , pois ainda que seja necesário um scan seria feito scan no índice, que seria menor que a tabela por conter menos dados... da mesma forma, Particionamento, Views Materializadas, Clusters, tabela ordenadas na hora da criação, GTTs, IOTs, etc, podem levar a reduções ASSOMBROSAS de I/O, vc TEM que as conhecer todas E ver em que pontos da sua aplicação essas feats te ajudam... []s Chiappa --- Em [EMAIL PROTECTED] os.com.br, "jlchiappa" <[EMAIL PROTECTED] ..> escreveu > > Seguem respostas : > > [EMAIL PROTECTED] com.br, Welvis Douglas Silva Moreto <welvinho18@ > > escreveu > > > > ... é que aqui eu posso mexer nos Sql's pois temos os fontes dos > programas,.. .. > > OK, então a alteração e tunning de SQLs deve ser facilitada aí.... > mais à frente porém, quando vc diz "full scan, aqui se tem muito. e > outros eventos", o que eu quero frisar, deixar CLARO, é que SE O > BANCO está fazendo full scan é PORQUE a aplicação está assim o > exigindo, simples assim, o ponto é que NÂO TEM O QUE MEXER no banco > em si se o ajuste mais "grosso" do banco está feito, então a pergunta > que vc tinha feito "o que devo mexer no banco para eliminar waits" > não tem um sentido, ok ??? O wait é SINTOMA, e e´sintoma CAUSADO > pelos SQLs da aplicação, é neles que vc vai mexer... > O que vc pode fazer se já não o fez a nível de banco é o tunning > mais "grosseiro" de banco, ie : se assegurar que os parâmetros de CBO > (ao menos os que cito no meu paper da ENPO) estão ok, que os jobs que > estão coletando as estatísticas pro CBO estão coletando o necessário, > com um frequência aceitável e com histogramas se adequado, que a RAM > alocada pro banco e pros processos criados por ele (tanto SGA quanto > PGA, se conexão dedicada) nem está muito pequena nem está grande a > ponto de não deixar espaço pras outras coisas ou mesmo paginar, que > os log files estão numa quantidade e tamanho aceitáveis, esse tipo de > coisa. Antes também de ajustar os SQLs, que pelo jeito vai ser SIM o > seu próximo passo, já que é linux o SO, vc TEM QUE TER também > ajustado bem o SO, ie, se ASSEGURADO que o kernel não está limitando > pra baixo qtdade de RAM alocada prum processo do Oracle e itens > semelhantes, SE o servidor só atende banco Oracle , ver que a > quantidade de RAM que o linux aloca pros seus caches é pequena, que > os filesystems aonde os datafiles Oracle residem não estão cacheando > info (já que o próprio bd Oracle tem os seus caches muito mais > eficientes, dedicados) - usando até raw devices onde se julgar > adequado -,, que vc TENHA Direct I/O e Asynchronous I/O presentes, > que não há bugs em firmware/drivers de nada referente à I/O.... Essas > tarefas todas são atribuição do sysadmin, MAS no metalink vc encontra > algumas notas listando ações necessárias e valores-sugestã o pra > maioria delas. > > ==> Esse tunning "grosso" inicial de banco e SO feito (se está em > produção imagino que já foi feito), aí não tem conversa, é tunning e > alteração de SQLs e estruturas físicas. > > "... tomo alguns cuidados da hora de escrever, usando Hints" > > hmmm, algo não parece bem, HINTs deveria ser o ÚLTIMO dos ÙLTIMOs > recursos, só sendo usados mesmo quando não teve como o CBO montar um > plano adequado, SE vc os está usando rotineiramente já na hora de > escrever, algo vai MUITO mal aí... > > "Trabalhando com Sql's com a base carregada, q é totalmente diferente > de uma vazia. " > > ==>> EXATAMENTE POR ISSO que vc nunca, jamais, de modo algum, pode > querer fazer análise de performance numa máquina com carga totalmente > diferente da real!!! Mais que isso, o hardware da máquina de > análises/homologaçã o deveria ser o mais possível IDÊNTICO à > produção , o SO deveria ser RIGOROSAMENTE O MESMO, os volumes de > dados deveria ser os mesmos... Se não der pros volumes serem > exatamente os mesmos, e pro hardware ser exatamente o mesmo (os dois > únicos pontos onde eu cederia se fosse vc, e mesmo asim após muito > choro), que ao menos seja proporcional (ie, se a máquina tem digamos > 1/4 da capacidade da máquina de Produção, tente-se colocar 1/4 de > dados, 1/4 dos usuários simultâneos, algo do tipo)... O que NÃO DÀ, > repito, é querer testar num laboratório dust-free, ie, numa máquina > VAZIA, com míseros dados, sem outras sessões concorrentes, isso > simplesmente NÃO É real, ululantemente ÓBVIO que vc só pode ter > surpresas desagradáveis quando for pra Produção o código... > > > > > Uma das coisas também que estou vendo a a questão do balanceamento > de carga. e estou tendo sobrecarga em um dos meus discos, mas não > quero apenas usar o oracle para fazer essa analise, quero ver pelo > linux. > > ok, Sei que além das nativas como iostat há tools linux disponíveis > pra isso instaláveis, como a IOzone em > http://www.acnc. com/benchmarks. html , mas fatalmente o seu sysadmin > será capaz de indicar outras. > > > > > Voçe tem os Scripts do Livro Optimizing Oracle Performance, tenho > apenas o pdf os scripts não achei na net. se voce puder me mandar > ficarei muito grato > > tenho o livro em casa, posso olhar e depois te digo. > > []s > > Chiappa > > --- Em [EMAIL PROTECTED] os.com.br, Welvis Douglas Silva Moreto > <welvinho18@ > escreveu > > > > Chiappa, aqui é um banco Oracle9i Release 9.2.0.4.0, é que aqui eu > posso mexer nos Sql's pois temos os fontes dos programas, e conheco > grande parte dos relatórios e procedimentos grandes, na realidade os > que eu desenvolvi, eu tomo alguns cuidados da hora de escrever, > usando Hints, tkprof, trace. Trabalhando com Sql's com a base > carregada, q é totalmente diferente de uma vazia. Só que agora estou > vendo a necessidade de estar melhorando isso. pois full scan, aqui se > tem muito. e outros eventos. então estou montando um script para > estar trabalhando com os sqls mais criticos. > > > > Uma das coisas também que estou vendo a a questão do balanceamento > de carga. e estou tendo sobrecarga em um dos meus discos, mas não > quero apenas usar o oracle para fazer essa analise, quero ver pelo > linux. > > > > Voçe tem os Scripts do Livro Optimizing Oracle Performance, tenho > apenas o pdf os scripts não achei na net. se voce puder me mandar > ficarei muito grato welvis_douglas@ > > > > e muito obrigado pela ajuda. > > > > t+ e um boa tarde. > > > > att, > > > > Welvis Douglas > > > > > > > > ----- Mensagem original ---- > > De: jlchiappa <jlchiappa@> > > Para: [EMAIL PROTECTED] os.com.br > > Enviadas: Quarta-feira, 2 de Maio de 2007 14:06:46 > > Assunto: [oracle_br] Re: Eventos de Espera.? > > > > Bom, pra variar vc não cita versão, mas no manual 9i em diante os > > eventos todos estão TODOS documentados no manual "Oracle9i Database > > Reference" no apêndice A - > > Oracle Wait Events . Evidentemente, além da documentação, que > existe > > e é grátis, vc certamente VAI desejar/necessitar de mais exemplos, > > refs a mais, discussão de casos, dicas.... Pra isso eu recomendo os > > livros "Oracle Wait Interface: A Practical Guide to Performance > > Diagnostics & Tuning", de Richmond Shee, Kirtikumar Deshpande e K > > Gopalakrishnan e o "Optimizing Oracle Performance" , de Cary > Millsap > > (este último foca em análise de waitings via trace/TKPROF mas eu o > > recomendo, também). > > > > ==> OBS : na esmagadora absoluta ** maioria ** dos casos, NÃO É > VOCÊ > > (que imagino ser um dba, ou similar) que "faz alguma coisa" pra > > diminuir waits - veja, um wait necessariamente NÂO OCORRE do nada, > > ele está presente PORQUE a aplicação assim o exige, quase sempre só > > mesmo ALTERANDO a aplicação e/ou as estruts do banco pra > corrigir... > > Por exemplo, se vc está fazendo um montão de I/Os digamos porque a > > aplicação tem SQLs horrorosos, lendo & relendo tabelas grandes sem > > critério algum, não usando as features Oracle, etc, , vc pode > tentar > > ** o que quiser ** que NÃO TEM O QUE, esse banco vai ter montes e > > montes de waits de I/O, faça vc o que quiser.... Já se o monte de > > I/Os é por estrutura inadequada (exemplo, não usa Particionamento > > quando deveria, não usa índice de função, não tem cláusula de > STORAGE > > adequadas, etc) a alteração TEM QUE ser feita é nos objetos em si, > a > > nível de banco VOLTO A AFIRMAR vc pode mexer o que quiser que NÂO > > OBTERÀ RESULTADO ALGUM, muito certamente.. . > > Os poucos casos onde vc pode ter algum retorno mexendo no banco > > decorrem OU de CBO mal-aplicado (exemplo, com estatísticas não- > > frescas, ou sem se ter ajustado os params de CBO), ou de banco > > fisicamente mal-instalado/ configurado (exemplo, com muito poucos > log > > files e/ou de tamanho inadequado, com I/O mal-distribuí do/com > > conflitos de I/O), por aí.... > > > > []s > > > > Chiappa > > > > --- Em [EMAIL PROTECTED] os.com.br, Welvis Douglas Silva Moreto > > <welvinho18@ ...> escreveu > > > > > > Onde eu Consigo um lugar q me diz o que cara evento do oracle faz > e > > onde eu consigo ver o q posso fazer para diminuir os mesmos? > > > > > > toda vez tem q ficar vasculhando na net, alguem sabe de algum > site > > q eu possa ver essa inf. > > > > > > att, > > > > > > Welvis Douglas > > > Msn: welvis_douglas@ ... > > > > > > ____________ _________ _________ _________ _________ __ > > > Fale com seus amigos de graça com o novo Yahoo! Messenger > > > http://br.messenger .yahoo.com/ > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > ____________ _________ _________ _________ _________ __ > > Fale com seus amigos de graça com o novo Yahoo! Messenger > > http://br.messenger .yahoo.com/ > > > > [As partes desta mensagem que não continham texto foram removidas] > > > __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
