Ok, Ok, Ok amigo, acho q estes em PERL eu tenho, eu consegui baixar.. ehehehe, mas blz.. muito obrigado pela atenção.
qualquer coisa eu dou um grito.. ehehe Obrigado pela Atenção. Att, Welvis Douglas Msn : [EMAIL PROTECTED] ----- Mensagem original ---- De: jlchiappa <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Segunda-feira, 7 de Maio de 2007 18:50:32 Assunto: Res: Res: [oracle_br] Re: Eventos de Espera.? Colega, fui checar aqui em casa e o livro que eu tenho é o "Optimizing Oracle Performance" , do autor cary Millsap, editora O´Reilly, Primeira Edição, é esse mesmo que vc quer ? Pois fui checar e ele não veio com CD algum de scripts, os (poucos) scripts que ele usa - como por exemplo o script PERL de contagem de geytimeofday na pág. 153, ou os exemplos de v$ no cap. 08: Fixed view reference - todos estão listados no próprio livro, quais "scripts" que vc quer ??? E se vc não quiser digitar, no Prefácio ele já nos diz que as memas listagens estão online em http://www.oreilly. com/catalog/ optoraclep/ , é isso ? Ou é outro o livro a que vc se refere ? []s Chiappa --- Em [EMAIL PROTECTED] os.com.br, Welvis Douglas Silva Moreto <welvinho18@ ...> escreveu > > 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: [EMAIL PROTECTED] os.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" <jlchiappa@ ..> > 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] > __________________________________________________ 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]