Rs Rs Grande Reginaldo, Tranquilo...as vezes os posts ficam meio..digamos...embaralhados..rs rs
Mas obrigadão pela ajuda ...estou tentand aprofundar os conhecimentos mesmo em tuning..acho muito 10. Ja estou vendo um bom material de configuração de CBO que um colega ai citou... abração --- Em oracle_br@yahoogrupos.com.br, rflribeiro <rflribe...@...> escreveu > > Esta mensagem foi enviada no dia da sua postagem (veja que ela segue > diretamente seu post). Deve ter sido a primeira resposta, inclusive. > Como a primeira mensagem que se envia ao grupo é moderada, só chegou hoje. > De qualquer forma, minha impressão ao ler seu post inicial não foi de > que já possuía alguma experiência e procurei não detalhar muito o > assunto. Acompanhei o restante da thread e vi o restante das respostas, > mas a mensagem já havia sido enviada, fazer o quê?. Quanto ao multiblock > veja bem, amigo, eu disse MULTIBLOCK e não DB_BLOCK), deixa pra lá... > Não vamos iniciar um flamewar... Estou disponível em pvt, qualquer coisa. > Novamente, boa sorte e um abraço. > P.S. Returning to the matrix. Abraços a todos. > > Ribeiro, Reginaldo > Administrador de Bancos de Dados > Oracle Certified Associate 10g > ---------------------------------------------------- > DBCom Brazil Consultoria em Tecnologia da Informação > skype: rflribeiro > mobile: 551178715729 > nextel id: 55*84*70035 > fone: 551135225172 > e-mail: rflribe...@... > site: http://www.dbcom.com.br > > > On 07/07/2009 02:46 PM, candiurudba wrote: > > > > > > Reginaldo, > > > > Nos posts anteriores (referentes a este topico) ja haviamos discutido > > isso e sabemos que em alguns casos, Full tables scans podm ser mais > > performaticos do que outros planos de acesso... > > > > Quanto a sair alterando parametros por alterar acredito que não seja a > > questão deste topico...a inteção é justamente o aprendizado pq, se vc > > ou qualquer outro DBA ate hj não configurou bem o CBO, não esta na > > verdade garantindo a maxima performance que pode ser obtida com a > > coleta de estatisticas e histogramas...esta é a intenção do tópico... > > > > Já vi muito DBA ( e ate mesmo experientes) coletando estatiscias, em > > um anbiente DATAWAREHOUSE e setado como optimizer_mode=FIRST_ROWS. > > quando na propria documentação da Oracle sugere ALL_ROWS para uma > > melhor performance... > > > > Um outro ponto importante, somente ler os Manuais sem praticar, por a > > prova, acredito que não seria d egrande utilizade. Seguindo o exemplo > > que vc passou, se eu aumentasse o db_block de 16 para 32, eu obteria > > ganhos de performance se todas as querys estivessem OK ?? provavelment > > esim, mas teria um custo alto de CPU ? Pq ? Estes são pontos que ficam > > na dúvida...tanto que aumentei de 16 para 25 e para mim, ficou bem > > traqnuilo... > > > > Quanto aos waits, ja descobri quais são (vide topicos anteriores) e > > por isso que não listei novamente aqui...pois a ideia era filtar os > > topicos atuais em CBO...um assunto que é pouco discutido.... > > > > --- Em oracle_br@yahoogrupos.com.br > > <mailto:oracle_br%40yahoogrupos.com.br>, rflribeiro <rflribeiro@> > > escreveu > > > > > > Amigo, fts (full table scan) não é o demônio... Há situações em que é > > > mais interessante varrer completamente a tabela ao invés de acessá-la > > > via index. Você está sofrendo problemas de performance? Se sim, já sabe > > > quais são os wait events relacionados? Conseguiu identificar as queries > > > ofensoras? Sair alterando parâmetros por alterar, visando seguir as > > > 'best practices (de quem?)' não é recomendável. Somente para > > > exemplificar, a alteração do multiblock para 40 ao invés de 16 vai te > > > dar o efeito exatamente contrário do que pretende se outros pontos não > > > forem objeto de análise e corretamente configurados. Tenha em mente que > > > a maior parte dos parâmetros relacionados à performance estão > > > relacionados. A mudança de qualquer um afeta diretamente a geração dos > > > planos de execução. > > > -> tahiti.oracle.com > > > No endereço acima, acesse o pt (performance e tuning) da sua versão > > (que > > > não informou, para variar) e dê uma bela fuçada lá. Também recomendo o > > > "Oracle Wait Interface: A Practical Guide to Performance Diagnostics & > > > Tuning by Richmond Shee, Kirtikumar Deshpande and K Gopalakrishnan > > > ISBN:007222729x". Boa sorte. > > > > > > Ribeiro, Reginaldo > > > Administrador de Bancos de Dados > > > Oracle Certified Associate 10g > > > ---------------------------------------------------- > > > DBCom Brazil Consultoria em Tecnologia da Informação > > > skype: rflribeiro > > > mobile: 551178715729 > > > nextel id: 55*84*70035 > > > fone: 551135225172 > > > e-mail: rflribeiro@ > > > site: http://www.dbcom.com.br <http://www.dbcom.com.br> > > > > > > > > > Am 02.07.2009 15:10, schrieb candiurudba: > > > > > > > > > > > > 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] >
