Ederson, se vc não se importar, vou usar a sua msg para extender um pouco as recomendações para o Élcio : 1. Éderson, primeira coisa : SE, como mostrado em msgs anteriores da thread, vc fez uma consulta na USER_TABLES e na USER_INDEXES e não retornou nada, isso IMPLICA que o usuário com o qual vc está conectado NÂO É O DONO das tabelas, apenas recebeu privs de SELECT nas tabelas de outrem, okdoc ?? ORA, SE esse seu usuário não é o dono, quase COM CERTEZA ele ** NÂO VAI TER ** privilégios para recoletar estatísticas, sim ??? Da mesma forma, é PROVÁVEL que esse usuário desprivilegiado NÂO tenha acesso às DBMSs/recursos necessários para se analisar um plano de execução, comparar/analizar estatísticas , etc... Da mesma forma, a gente NÂO SABE se é esse SQL que está com problemas OU se na verdade é o banco em geral que está sendo 'castigado'/consumido em excesso por outra(s) sess/ão/ões e a má performance desse SQL é RESULTADO de falta de recursos nesse ambiente e/ou má-utilização.... Então vc ** VAI TER QUE ** ser ajudado pelo DBA aí, é ELE que tem os privs para ver o banco em geral E e ele que pode te dar os acessos necessários : sem isso, vc está de mãos atadas, NEM adianta continuar a leitura.... 2. o plano apenas e tão somente ABSOLUTAMENTE não é tudo que nos interessa : o que nós queremos é, Além do plano, saber a CARDINALIDADE que foi estimada pelo CBO versus a Cardinalidade efetivamente encontrada na execução... Sendo 10g, SE tudo estiver default o 10g Automaticamente já coleta essas coisas e as mantém em cache : assim, SE vc executou completamente já essa query lenta, vc pode passar o SQL_ID desse SQL para o DBMS_XPLAN.... Caso não, para Evitar a execução completa do SQL, cfrme for vc pode usar um hint de GATHER_PLAN_STATISTICS.... E não esquecer NUNCA de passar o param de format como ALL, pois senão vc Não Vai obter a Cardinalidade estimada/encontrada (E-ROWS e A-ROWS)... veja https://blogs.oracle.com/optimizer/entry/how_do_i_know_if para uma refs a respeito... 3. quem vai analisar a performance de um SQL *** TEM *** que saber EXATAMENTE quais os índices disponíveis , de que tipo são, quais as regras de negócio possíveis/aceitáveis para se joinear as tabelas, a Cardinalidade e o Domínio dos dados..... É ESSE CONHECIMENTO que vai te habilitar a, digamos, criar um índice de função que só indexa os valores desejados, usar uma condição de join que implique em menos I/O no total, OU até mesmo (como Último Recurso, e NÂO como o primeiro!!) tentar um HINT... okdoc ? Isso só VOCÊ pode obter aí no SEU database, sim ??? A questão aqui é ELIMINAR a chance de SQL com má-performance devido à um plano ruim, por causa de algum método de acesso que o CBO não consegui enxergar/usar, seja por falta de estatísticas apropriadas, seja por ordenação interna dos dados (cluster_factor) ruim, histogramas de tamanho / qtdade insuficiente, o que for .... 4. a dica final : DE FORMA ALGUMA o teu objetivo é simplesmente "fazer o CBO usar um índice" , Absolutamente isso não é o fim do tuning, é MUITO POSSÌVEL que ao vc forçar o uso do índice vc obtenha performance PIOR, não é verdade que 'índice em uso = boa performance, índice não em uso/table scan = coisa ruim' sempre, em todos os casos, okdoc ?? De forma geral, acesso via índice é bom SE há uma qtdade relativamente pequena de linhas a recuperar, mas quanto mais linhas são necessárias, mais atraente fica o table scan ao invés do index access, o hash join ao invés do nested loop, yep ?? []s Chiappa
--- Em [email protected], "ederson2001br" <ederson2001br@...> escreveu > > Bom dia Elcio, > > O script abaixo, vc pode rodar conectado como o usuário dono da tabela que vc > está em dúvida, ou até mesmo conectado como outro usuário. > > Ele mostra os indices disponíveis para aquela tabela. > > Informe para o grupo: > -o sql da query e > -o resultado do script abaixo, > -o plano de execução mostrado com o script que o colega já te passou: > EXPLAIN PLAN FOR > -- seu SQL > SELECT * FROM TABLE(dbms_xplan.display); > > Para começar. Sem isto não tem advinhação. > > > break on NOMEINDEX > set linesize 170 > set pagesize 100 > set verify off; > column NOMECOLUNA format a30; > select UI.index_name NOMEINDEX, > UI.uniqueness UNICIDADE, > AIC.column_position POSICAO , > SUBSTR(AIC.column_name,1,30) NOMECOLUNA > from ALL_indexes UI, all_ind_columns AIC > where UI.table_name = LTRIM(RTRIM(upper('&tabela'))) > and AIC.table_name = UI.table_name > and AIC.index_owner = UI.table_owner > and AIC.index_name = UI.index_name > order by UI.index_name, AIC.column_position; > set linesize 90; > set pagesize 20; > set verify on; > > > Ederson Elias > DBA Oracle > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 > ------------ > Labor improbus omnia vincit > > --- Em [email protected], Elcio Francisco <elciofrancisco@> > escreveu > > > > não > > > > Elcio Francisco > > Analista de Sistemas > > Multicrédito > > Belo Horizonte - MG > > > > P Antes de imprimir pense em sua responsabilidade com o MEIO AMBIENTE > > Adote os 3Rs na sua vida: Reduza, Reutilize, Recicle! > > > > > > ________________________________ > > De: christiancedrid <christiancedrid@> > > Para: [email protected] > > Enviadas: Quinta-feira, 9 de Maio de 2013 17:06 > > Assunto: [oracle_br] Re: Query Lenta > > > > > > > > > > > > Você tem acesso a DBA_TABLES e DBA_INDEXES? > > > > --- Em [email protected], Elcio Francisco <elciofrancisco@> > > escreveu > > > > > > Christian, muito obrigado verifiquei nas tabelas > > > > > > Select * from user_tables; > > > > > > Select * from user_indexes; > > > > > > Nenhuma delas traz dado nenhum isso mostra que os indices estão todos > > > desatualizados não atualizam indices??? > > > > > > Obrigado > > > > > > Elcio Francisco > > > Analista de Sistemas > > > Multicrédito > > > Belo Horizonte - MG >
