Início / dba / Perguntas / 318418
Accepted
Mark Barinstein
Asked: 2022-10-20 08:05:49 +0800 CST

Db2: EXP0059W no plano de acesso para consultas usando visualização estatística com predicado IN ou EXISTS

  • 772

O problema está listado como resolvido em 9.7.1, mas o mesmo existe em todas as versões 11.5 e 11.1 recentes.
IC62904: PROBLEMA EXP0059W PARA STATVIEWS COM SELECT DISTINCT .
Ainda o mesmo EXP0059W no plano de acesso.
Os passos para reproduzir:

connect to mydb;
create table ta (a1 int);
create table tb (b1 int);
create view sv as (select * from ta where a1 in (select b1 from tb));                                                           
alter view sv enable query optimization;

explain all with snapshot for
select * from ta where a1 in (select b1 from  tb);              

!db2exfmt -d mydb -1 -o sv.plan;

O plano de acesso contém a seguinte mensagem semelhante à descrita no link:

Diagnostic Details:     EXP0059W  The following MQT or statistical view was
            not eligible because of one or more of the
            following reasons: (1) the MQT had extra table
            joins or GROUP BY columns that were not present in
            the query, or (2) the query had an SQL construct
            such as ORDER BY, FETCH FIRST n ROWS, DISTINCT, or
            had a subquery that could not be matched:
            "DB2ADMIN"."SV".

Não consigo abrir um Caso com suporte IBM.
A questão é: alguém sabe como resolver o problema com, digamos, alguma configuração de variável de registro ou com outras facilidades?

db2

1 respostas

  1. Best Answer

    Você pode reformular sua consulta na exibição?

    create or replace view sv as (select ta.* from ta join tb on a1 = b1);
alter view sv enable query optimization;

explain all with snapshot for
select * from ta where a1 in (select b1 from  tb);

    [...]

    Extended Diagnostic Information:
--------------------------------

[...]
Diagnostic Identifier:  3
Diagnostic Details:     EXP0147W  The following statistical view was used
                        by the optimizer to estimate cardinalities:
                        "DB2INST1"."SV".
Diagnostic Identifier:  4
Diagnostic Details:     EXP0148W  The following MQT or statistical view was
                        considered in query matching: "DB2INST1"."SV".

    Eu tentei com:

    db2set DB2_INLIST_TO_NLJN=YES

    mas não parece melhorar as coisas

    Algumas observações adicionais, não sei se ajuda. Uma visão como:

    create or replace view sv1 as (
    select DISTINCT ta.* from ta where a1 in (select b1 from tb)
);

    não pode ser usado para otimizar consultas (SQL20278W), mas:

    create or replace view sv1 as (
    select ta.* from ta where a1 in (select b1 from tb)
);

    posso. Se olharmos para a consulta:

    select 
  * 
from 
  ta 
where 
  a1 in 
  (select 
     b1 
   from 
     tb
  )

    é otimizado como:

    SELECT 
  DISTINCT Q2.A1 AS "A1" 
FROM 
  DB2INST1.TB AS Q1,
  DB2INST1.TA AS Q2 
WHERE 
  (Q2.A1 = Q1.B1)

    Se adicionarmos restrições adicionais:

    create table tb (b1 int not null unique);

    a consulta é otimizada como:

    SELECT 
  Q2.A1 AS "A1"     -- DISTINCT not necessary
FROM 
  DB2INST1.TB AS Q1,
  DB2INST1.TA AS Q2 
WHERE 
  (Q2.A1 = Q1.B1)

    Portanto, o Db2 pode usar a visualização para a instrução otimizada:

    Diagnostic Identifier:  3
Diagnostic Details:     EXP0147W  The following statistical view was used
                        by the optimizer to estimate cardinalities:
                        "DB2INST1"."SV1".
Diagnostic Identifier:  4
Diagnostic Details:     EXP0148W  The following MQT or statistical view was
                        considered in query matching: "DB2INST1"."SV1".

    Você pode adicionar algumas restrições que eliminam a necessidade de DISTINCT na consulta otimizada?

    Uma maneira perigosa é adicionar uma restrição informativa:

    create table tb (b1 int not null);

alter table tb add constraint abc
        unique (b1)
not enforced
enable query optimization;
    • 1

relate perguntas