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 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
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 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 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 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
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 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
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 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
