Menu de navegação

[MarcusParticipante]

Pessoal,

Estou com um problema de performance em uma query devido à volumetria.. alguém tem alguma sugestão de melhoria?

Segue dados:

Tabela / Quantidade de registros

[b]TIPO_LOCAL – 15
ESTADO_EQUIPAMENTO – 22
MODELO_EQUIPAMENTO – 228
OPERACAO – 242
ESTOQUE_LOCAL_OPERACAO – 147227
LOCAL – 20181021
EQUIPAMENTO – 33977402
[/b]

Segue query:

[b]select B.NM_TIPO_LOCAL AS “TIPO LOCAL”,
A.CD_LOCAL AS “COD. JDE”,
A.ID_LOCAL AS “COD. ATLAS”,
A.NM_LOCAL AS “DESCRIÇÃO”,
count(*) “qtd”,
G.NM_OPERACAO AS “OPERAÇÃO”,
E.NM_ESTADO_EQUIPAMENTO AS “ESTADO”

from LOCAL A,
TIPO_LOCAL B,
MODELO_EQUIPAMENTO C,
EQUIPAMENTO D,
ESTADO_EQUIPAMENTO E,
ESTOQUE_LOCAL_OPERACAO F,
OPERACAO G

where B.id_tipo_local = A.id_tipo_local
and A.id_local = D.id_local
and A.id_local = F.id_local
and C.id_modelo_equipamento = D.id_modelo_equipamento
and E.id_estado_equipamento = D.id_estado_equipamento
and F.id_estoque_local_operacao = D.id_estoque_local_operacao
and G.ID_OPERACAO = D.ID_OPERACAO
and G.ID_OPERACAO = F.ID_OPERACAO

group by B.NM_TIPO_LOCAL,
A.CD_LOCAL,
A.ID_LOCAL,
A.NM_LOCAL,
G.NM_OPERACAO,
E.NM_ESTADO_EQUIPAMENTO
[/b]

Plano de execução em anexo!

Agradeço desde já!

Attachments:

• Plano_exec.txt

[José Laurindo ChiappaModerador]

Blz ? Então, a primeira coisa que vc Não nos Dá então precisamos perguntar são os ** cruciais ** detalhes de versão e Edição do seu database, as configurações atuais não-default do banco bem como uma descrição do seu hardware (especialmente qtdade de memória total E livre, alocação da memória, banda de I/O, TIPO de I/O sendo usado, capacidade de CPU, consumo de recursos por outros SQLs, etc) E quais opções vc tem Licenciadas no seu RDBMS, para podermos Avaliar a aplicabilidade de PARTICIONAMENTO, PARALELLEL SQL, BITMAP INDEXES e VIEW MATERIALIZADAS : todas essas são features que podem ser VITAIS pra performance em grande volume de dados e julgando pelo seu EXPLAIN, vc não as tem habilitadas/não está usando em nenhuma dessas duas tabelas grandes, LOCAL e EQUIPAMENTO…..

A segunda coisa é sobre a Modelagem : EM ESPECIAL, me parece que essas tabelas são tabelas de FATO, ie, a cada vez que acontece uma ocorrência de geração de fator de negócio um registro é inserido, então o padrão de crescimento dela deve ser explosivo – numa situação assim, vc ter que percorrer a tabela grande TODINHA para filtrar os relativamente poucos registros que atendem à data de ocorrência, ao causador ou a que condição de filtro for é ASNICE COMPLETA : ainda que seja percorrendo um índice, percorrer milhões e milhões de registros NÃO É SIMPLES NEM BARATO!!! Particionamento e bitmap indexes podem ajudar MUITÍSSIMo nisso, bem como opções de ordenação física, como Cluster Tables e Index-organized Tables…

Até agora falei muito do físico, que é importante (e mesmo Crítico em alguns casos) mas vamos (SEM desmerecer o que disse antes!!) falar um pouco do lógico :

a. pelo jeito vc NÂO USOU as opções de captura de Execution Plan real, mas sim usou o comando EXPLAIN PLAN básico, que te dá um Plano baseado em Previsões apenas : plz use os recursos cfrme mostrados em https://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/ (ie, execução com HINT de GATHER) para obter o plano de execução EFETIVO e em formato EXTENDIDO, o que vai te dar (entre outras informações VITAIS!!) as colunas Starts, E-ROWS e A-ROWS, que servem (vide ) https://jonathanlewis.wordpress.com/2016/05/05/e-rows-a-rows/ e https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate para referências) para vc comparar a qtdade de linhas a acessar estimadas pelas Estatísticas Versus a quantidade realmente acessada no fim do plano de execução cumprido : com isso vc pode ter uma noção se as suas Coletas de Estatísticas estão sendo efetivas ou não….

b. se for real (e não uma simples suposição do EXPLAIN PLAN) esse passo onde mostra a operação “VIEW” usando um índice “index$_join$_006” me causa espécie : veja, julgando pelo nome esquisito, pra mim o RDBMS está criando na hora um índice apropriado por não existir (vide https://community.oracle.com/thread/924734), e necessariamente sair criando índice no meio da execução de uma query Não É o mais efetivo – plz CONSULTE as colunas indexadas versus as colunas sendo efetivamente usadas no WHERE da query pra avaliar se de repente vc criar o índice apropriado não te corta esse tempo todo dessa criação

c. para vc fazer um teste prático dos acessos e tentar identificar qual tabela está sendo mais acessada, fatie essa query : o que eu quero dizer com isso é tentar escrever uma versão mais simplificada dela, tipo :

elect
A.CD_LOCAL AS “COD. JDE”,
A.ID_LOCAL AS “COD. ATLAS”,
A.NM_LOCAL AS “DESCRIÇÃO”,
count(*) “qtd”,
from LOCAL A
where A.id_tipo_local = xxx
and eqipamnto = valorfixo
and …demais colunas-chave da tabela grande OPERACAO comparando com valores fixos …

==> se isso rodou aceitavelmente, tenta ir adicionando os JOINs com as tabelas pequenas um por vez… Depois a mesma coisa começando com a outra tabela grande EQUIPAMENTO ….
Meu objetivo com este último teste é identificar CARDINALIDADES e também possíveis chaves não-indexadas e/ou não referenciadas no SQL…

Blz ?

[]s

Chiappa

[Autor]

Posts