Carandiru, Um bom material para leitura sobre tunning e CBO é o livro Cost Based Oracle Fundamentals - Jonathan Lewis Leitura em ingles mas vale a pena dar uma olhada apesar do nível de detalhamento...
[ ]'s Matheus 2009/7/3 candiurudba <candiuru...@yahoo.com.br> > > > Grande Andre, > > sim !! sim !! As vezes um FULL TABLE SCAN tem um custo muito menor do que > uma consulta contendo um indice ou prumary key.. > > Citei a questão dos FULL TABLES ou dos RANGE SCAN com relação aos > parametros do CBO...Existem algumas opções bem específicas nas configuração > que mexem diretamente com os FULL TABLE SCAN...por isso a dúvida :) > > Estou começando um trabalho de tuning onde o chiappa ja me deu alguns > toques, devidos ha alguns latchs que tenho na mnha library cache...e sei que > grande parte disso, é culpa de querys mal elaboradas mas, podendo cercar > tudo que eu puder quanto ao banco, seria bom ... > > Já li muitas coisas sobre o CBO...sempre coletei as estatisticas de banco e > etc..mas nunca configurei o bendito..ou seja...talvez pudesse etsar ganhando > mais alguma coisa, com relação a performance no plano de execução das querys > se tivesse dando uma olhadinha nele antes....mas antes tarde do que nunca ne > !! Rs > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > Andre Santos <andre.psantos...@...> escreveu > > > > > Candiuru > > > > Aqui no fórum há excelentes DBA's que poderão ajudar nas questões sobre > > parâmetros. > > > > Sobre os "full table scans" ou "index range scans", não devemos > associá-los > > necessariamente a coisas ruins. > > Dependendo do conteúdo das tabelas e do tipo de consulta, podem ser os > > melhores métodos (com menor custo). > > > > Além dos parâmetros, que você está pesquisando, o modo de coletar as > > estatísticas é muito importante (por exemplo, quais tabelas/colunas terão > > histogramas, etc...). > > > > [ ] > > > > André > > > > 2009/7/2 candiurudba <candiuru...@...> > > > > > > > > > > > > Boa tarde colegas, > > > > > > Estava lendo algumas mensagens antigas aqui no forum, sobre o erro de > > > basear tuning nos famosos Hit Ratios (buffer chache e etc...) e que > algumas > > > melhorias podem ser implementadas, com relação a performance de querys, > > > alterando alguns parametros do CBO. > > > > > > Comecei a fazer algumas pesquisas sobre algumas opções e tenho algumas > > > pequenas dúvidas... > > > > > > Nas aplicações que trabalho, temos algumas tabelas que sofrem FULL > TABLE > > > SCAN e INDEX RANGE...meu banco de dados esta configurado como > > > optimizer_mode=ALL_ROWS que, segundo pesquisa, favorece os FULL TABLE > > > SCANS...seria isso mesmo ? > > > > > > Segundo pesquisei no metalink, para banco um OLTP o ideial seria > > > FIRST_ROWS..mas, e com relação aos FULL TABLE SCANS ? Perderia muita > > > performance ? > > > > > > Opções que pensei em mudar, relativas a pesquisa: > > > > > > optimizer_mode=ALL_ROWS ==> FIRST_ROWS > > > > > > optimizer_index_caching=0 ==> 50 > > > > > > db_file_multiblock_read_count=16 ==>40 > > > > > > parallel_automatic_tuning=FALSE ==>ON (pelo que entendi, com esta opção > em > > > ON ele pode paralelizar os FULL TABLES SCAN...isso funciona mesmo ? ) > > > > > > hash_area_size e sort_area_size não irei mexes pois utilizo > > > pga_aggregate_target. Segundo documentação, só poderia alterar estas > opções > > > se nao estivesse trabalhando com pga_aggregate. > > > > > > Tudo certinho ? > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas]
