Menu de navegação

[AdimariParticipante]

Boa tarde, alguém poderia esclarecer a seguinte dúvida?

Às vezes buscando melhorar a performance de uma instrução sql, são criados indices e tal, no plano de execução o cost aparece baixo, com relação ao plano anterior, pelo que observei, o único impacto relevante neste novo plano é a table acess full, em apenas uma ou duas tabelas em um cenário com 4 tabelas, por exemplo, porém mesmo o cost sendo bem inferior ao plano anterior, o tempo de execução desta instrução aumenta consideravelmente.
Porque isso ocorre, tecnicamente, estudando “o interiorzão” do modo de processamento do Oracle?
Qual a relação do cost com o modo de acesso às tabelas?

[brunopbParticipante]

atualizou as estatisticas?

vc deve estar fazendo tunning baseado em custos… e precisa atualizar as estatisticas para ser mais preciso na analise…

se falei besteira me corrijam por favor

[VitorLeandroParticipante]

Com certeza as estatísticas devem estar atualizadas… Mas, vamos por partes.

Um custo menor, não quer dizer que a query irá retornar os dados mais rápidos… É preciso analisar mais afundo a query que você está com problema.

Full scans, nem sempre sao ruins. Verifique se voce precisa de todas as linhas das tabelas que fazem Full Scan. Se através do join, a tabela de origem corresponder a 10% ou menos da outra tabela, talvez um index sobre o campo onde o join é realizado melhore muito o custo, e o tempo, pois menos linhas precisaram ser lidas para gerar o resultado. Se for necessário varrer mais de 50% dessa tabela, provavelmente o FULL Scan é mais rápido.

Seu banco é enterprise? Se for, pode ser inserido o hint de paralelismo nas tabelas de Full Scan. Isso diminuira o tempo de resposta. Mas lembre-se, paralelismo é bom de ser utilizado quando já foram esgotadas estratégias menos custosas, devido gasto maior de processamento.

[AdimariParticipante]

valeu, ja deu uma abertura maior

[fsitjaParticipante]

Complementando ainda a informação do VitorLeandro, o Cost serve apenas para comparar o diferentes planos de acesso para o mesmo SQL.

Se você alterar o SQL, a informação do custo do SQL novo não pode ser usada para comparar com a versão anterior da query, pois é como comparar laranjas com maçãs.

Há várias formas de fazer tuning, mas os parâmetros principais, além obviamente do tempo de retorno, são obtidos por meio de trace (TKprof) com dados de consistent gets (leituras a disco), hits de cache na SGA, result_cache, rollbacks implícitos, waits, etc.

A principal diretriz é minimizar o número de leituras no disco, sejam elas por meio de acesso a índices ou a tabelas.

[ramasineParticipante]

Segue um tópico bem legal sobre esse assunto!!

http://glufke.net/oracle/viewtopic.php?t=5519

Espero que seja útil!

Abs

[Autor]

Posts