Res: Res: Res: [oracle_br] Re: Eventos de Espera.?
Blz, veja que não sou os em Perl mas ** também ** os em SQL vc acha nesse local, ok ? Eu tinha perguntado se era esse mesmo o livro justamente porque não veio nada em CD, fiquei na dúvida que scripts eram esses que vc não encontrava []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Welvis Douglas Silva Moreto <[EMAIL PROTECTED]> escreveu > > 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 > 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 > > 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" > > escreveu > > > > > > Seguem respostas : > > > > > > [EMAIL PROTECTED] com.br, Welvis Douglas Silva Moreto > > > escreveu > > > > > > > > ... é que aqui eu posso mexer nos Sql's pois temos os fontes dos > > > programas,.. .. > > > > > > OK, então a alter
Res: Res: Res: [oracle_br] Re: Eventos de Espera.?
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 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" > escreveu > > > > Seguem respostas : > > > > [EMAIL PROTECTED] com.br, Welvis Douglas Silva Moreto > > 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 SQ
