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,
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, deixa
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 oracle_br@yahoogrupos.com.br, Welvis Douglas Silva Moreto <[EMAIL PROTECTED]> 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: 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" > 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 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 >
Res: Res: [oracle_br] Re: Eventos de Espera.?
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 > 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 > adequad
