Acerca dos Sucessos da Cache

Um subconjunto de colunas na lista SELECT deve corresponder

Todas as colunas da lista SELECT de uma nova consulta têm de existir na consulta em cache para se qualificarem para um sucesso da cache ou é necessário que possam ser calculadas a partir das colunas na consulta.

Esta regra descreve o requisito mínimo para o sucesso da cache, mas o cumprimento desta regra não garante um sucesso da cache. As outras regras listadas nesta tabela também se aplicam.

As colunas na lista SELECT podem ser compostas por expressões nas colunas das consultas em cache

O Oracle Analytics Cloud pode calcular expressões nos resultados em cache para responder à nova consulta, mas todas as colunas devem estar no resultado em cache. Por exemplo, a consulta:

SELECT product, month, averageprice FROM sales WHERE year = 2000

obtém um sucesso da cache na consulta:

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

porque averageprice pode ser calculado a partir de dollars e unitsales (averageprice = dollars/unitsales).

A cláusula WHERE deve ser semanticamente idêntica ou um subconjunto lógico

Para que a consulta se qualifique como um sucesso da cache, as restrições da cláusula WHERE devem ser equivalentes aos resultados em cache ou um subconjunto dos resultados em cache.

Uma cláusula WHERE que seja um subconjunto lógico de uma consulta em cache qualifica-se para um sucesso da cache se o subconjunto cumprir um dos seguintes critérios:

• Um subconjunto de valores da lista IN. As consultas que pedem menos elementos de uma consulta em cache da lista IN qualificam-se para um sucesso da cache. Por exemplo, a consulta seguinte:

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('EAST', 'WEST')

  qualifica-se como um sucesso na consulta em cache seguinte:

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')

• Contém menos restrições OR (mas idênticas) do que o resultado em cache.

• Contém um subconjunto lógico de uma comparação literal. Por exemplo, o predicado seguinte:

  WHERE revenue < 1000

  qualifica-se como um sucesso da cache numa consulta comparável com o predicado:

  WHERE revenue < 5000

• Não existe nenhuma cláusula WHERE. Se existir uma consulta sem uma cláusula WHERE colocada na cache, as consultas que satisfizerem todas as outras regras de sucesso da cache qualificam-se como sucessos da cache independentemente da respetiva cláusula WHERE.

Além disso, as colunas que são utilizadas na cláusula WHERE devem existir na lista de projeções. Por exemplo, a consulta seguinte:

SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')

Não resulta num sucesso da cache para a consulta de criação na lista anterior porque REGION não está na lista de projeções.

As consultas só de dimensão devem ser uma correspondência exata

Se uma consulta for só de dimensão, o que significa que nenhum facto ou medida está incluído na consulta, apenas uma correspondência exata das colunas de projeção da consulta em cache será um sucesso da cache. Este comportamento impede falsos positivos quando existem várias origens lógicas para uma tabela de dimensões.

As consultas com funções especiais devem ser uma correspondência exata

As outras consultas que contêm funções especiais, como funções de série de tempo (AGO, TODATE e PERIODROLLING), funções de limite e diferencial (OFFSET e FETCH), funções de relação (ISANCESTOR, ISLEAF, ISROOT e ISSIBLING), funções de agregação externa e, em geral, as métricas do filtro também devem ser uma correspondência exata com as colunas de projeção na consulta em cache. Nestes casos, o filtro também deve ser uma correspondência exata. Para as métricas do filtro, se for possível reescrever a métrica do filtro como uma cláusula WHERE, poderá tirar partido da cache do subconjunto.

O conjunto de tabelas lógicas deve corresponder

Para se qualificarem como um sucesso da cache, todas as consultas recebidas devem ter o mesmo conjunto de tabelas lógicas que a entrada da cache. Esta regra evita sucessos da cache falsos. Por exemplo, SELECT * FROM product não corresponde a SELECT * FROM product, sales.

Os valores das variáveis da sessão devem corresponder, incluindo as variáveis da sessão de segurança

Se a instrução de SQL lógico ou SQL físico fizer referência a qualquer variável da sessão, os valores das variáveis da sessão devem corresponder. Caso contrário, não ocorre um sucesso da cache.

Além disso, o valor das variáveis da sessão que são sensíveis à segurança deve corresponder aos valores das variáveis da sessão de segurança definidos no modelo semântico, mesmo que a própria instrução de SQL lógico não faça referência às variáveis da sessão. Consulte Assegurar Resultados da Cache Corretos ao Utilizar a Segurança da Base de Dados ao Nível da Linha.

Condições de junção equivalentes

A tabela lógica com junção resultante de um novo pedido de consulta tem de ser idêntica (ou um subconjunto de) aos resultados em cache para se qualificar para um sucesso da cache.

O atributo DISTINCT deve ser o mesmo

Se uma consulta em cache eliminar registos duplicados com o processamento DISTINCT (por exemplo, SELECT DISTINCT...), os pedidos para as colunas em cache também devem incluir o processamento DISTINCT; um pedido para a mesma coluna sem o processamento DISTINCT é uma falha da cache.

As consultas devem conter níveis de agregação compatíveis

As consultas que pedem um nível agregado de informações podem utilizar os resultados em cache a um nível de agregação inferior. Por exemplo, a consulta seguinte pede a quantidade vendida ao nível do fornecedor, da região e da localidade:

SELECT supplier, region, city, qtysold
FROM suppliercity

A consulta seguinte pede a quantidade vendida ao nível da localidade:

SELECT city, qtysold
FROM suppliercity

A segunda consulta resulta num sucesso da cache na primeira consulta.

Agregação adicional limitada

Por exemplo, se uma consulta com a coluna qtysold estiver em cache, um pedido de RANK(qtysold) resulta numa falha da cache. Adicionalmente, uma consulta que peça qtysold ao nível do país pode obter um sucesso da cache a partir de uma consulta que peça qtysold ao nível do país e da região.

A cláusula ORDER BY deve ser composta por colunas na lista Select

As consultas que ordenam por colunas que não estão contidas na lista Select resultam em falhas da cache.

Diagnosticar o comportamento de sucesso da cache

Para avaliar melhor o comportamento de sucesso da cache, defina a variável da sessão ENABLE_CACHE_DIAGNOSTICS como 4, como mostrado no exemplo seguinte:

ENABLE_CACHE_DIAGNOSTICS=4