Acerca de los aciertos de caché

Cuando el almacenamiento en caché está activado, se evalúa cada consulta para determinar si está cualificada para un acierto de caché.

Un acierto de caché significa que Oracle Analytics Cloud ha podido utilizar la caché para responder a una consulta sin ir a la base de datos. Oracle Analytics Cloud puede utilizar la caché de consulta para responder a consultas en el mismo nivel de agregación o uno superior.

Hay varios factores que determinan si se produce un acierto de caché. En la siguiente tabla se describen estos factores.

Factor o regla Descripción

Un subjuego de columnas de la lista SELECT debe coincidir

Para que esté cualificada para un acierto de caché, todas las columnas de la lista SELECT de una nueva consulta tienen que existir en la consulta en caché, o deberán poder calcularse a partir de las columnas en la consulta.

Esta regla describe el requisito mínimo para un acierto de caché, pero el cumplimiento de esta regla no garantiza un acierto de caché. También se aplican las reglas restantes de esta tabla.

Las columnas de la lista SELECT pueden estar compuestas de expresiones de las columnas de las consultas en caché

Oracle Analytics Cloud puede calcular expresiones en los resultados en caché para responder a la nueva consulta, pero todas las columnas deben estar en el resultado en caché. Por ejemplo, la consulta:

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

coincide con la caché en la consulta:

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

porque averageprice puede calcularse a partir de dollars y unitsales (averageprice = dollars/unitsales).

La cláusula WHERE debe ser semánticamente la misma o un subjuego lógico

Para que la consulta esté cualificada como un acierto de caché, las restricciones de la cláusula WHERE deben ser equivalentes a los resultados en caché, o bien un subjuego de los resultados en caché.

Una cláusula WHERE que es un subjuego lógico de una consulta en caché está cualificada para un acierto en caché si el subjuego cumple uno de los siguientes criterios:

  • Un subjuego de los valores de lista IN. Las consultas que solicitan menos elementos de una consulta en caché de lista IN están cualificadas para un acierto de caché. Por ejemplo, la siguiente consulta:

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

    está cualificada como un acierto en la siguiente consulta en caché:

    SELECT employeename, region
    FROM employee, geography
    WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')
  • Contiene menos restricciones OR (pero idénticas) que el resultado en caché.

  • Contiene un subjuego lógico de una comparación literal. Por ejemplo, el siguiente predicado:

    WHERE revenue < 1000

    está cualificado como un acierto de caché en una consultas comparable con el predicado:

    WHERE revenue < 5000
  • No hay ninguna cláusula WHERE. Si hay una consulta sin ninguna cláusula WHERE almacenada en caché, las consultas que cumplen todas las reglas restantes de acierto de caché están cualificadas como aciertos de caché independientemente de su cláusula WHERE.

Además, todas las columnas que se utilizan en la cláusula WHERE deben estar en la lista de proyecciones. Por ejemplo, la siguiente consulta:

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

No da como resultado un acierto de caché para la consulta inicial en la lista anterior porque REGION no está en la lista de proyecciones.

Las consultas solo de dimensión deben ser una coincidencia exacta

Si una consulta es solo de dimensión, lo que significa que no está incluido ningún hecho o medida en la consulta, solo una coincidencia exacta de las columnas de proyección de la consulta en caché coincide con la caché. Este comportamiento evita falsos positivos cuando hay varios orígenes lógicos para una tabla de dimensiones.

Las consultas con funciones especiales deben ser una coincidencia exacta

Otras consultas que contienen funciones especiales, como las funciones de serie temporal (AGO, TODATE y PERIODROLLING), las funciones de límite y desplazamiento (OFFSET y FETCH), las funciones de relación (ISANCESTOR, ISLEAF, ISROOT y ISSIBLING), las funciones de agregación externa y, en general, las métricas de filtro también deben ser una coincidencia exacta con las columnas de proyección en la consulta en caché. En estos casos, el filtro también debe ser una coincidencia exacta. En el caso de las métricas de filtro, si la métrica de filtro puede reescribirse como una cláusula WHERE, se puede aprovechar la caché de subjuego.

El juego de tablas lógicas debe coincidir

Para estar cualificadas como un acierto de caché, todas las consultas entrantes deben tener el mismo juego de tablas lógicas que la entrada de caché. Esta regla evita aciertos de caché falsos. Por ejemplo, SELECT * FROM product no coincide con SELECT * FROM product, sales.

Los valores de las variables de sesión deben coincidir, incluidas las variables de la sesión de seguridad

Si la sentencia SQL lógica o física hace referencia a cualquier variable de sesión, los valores de la variable de sesión deben coincidir. De lo contrario, no hay una coincidencia con la caché.

Además, el valor de las variables de sesión que son sensibles a la seguridad debe coincidir con los valores de las variables de sesión de seguridad definidos en el modelo semántico, incluso aunque la propia sentencia SQL lógica no haga referencia a las variables de sesión. Consulte Garantizar resultados de caché correctos al utilizar la seguridad de base de datos de nivel de fila.

Condiciones de unión equivalentes

La tabla lógica unida resultante de una nueva solicitud de consulta tiene que ser la misma que (o un subjuego de) los resultados en caché para estar cualificada para un acierto de caché.

El atributo DISTINCT debe ser el mismo

Si una consulta en caché elimina registros duplicados con el procesamiento DISTINCT (por ejemplo, SELECT DISTINCT...), las solicitudes para las columnas en caché también deben incluir el procesamiento DISTINCT; una solicitud para la misma columna sin el procesamiento DISTINCT es una falta de caché.

Las consultas deben contener niveles de agregación compatibles

Las consultas que solicitan un nivel de información agregado pueden utilizar resultados en caché en un nivel de agregación inferior. Por ejemplo, la siguiente consulta solicita la cantidad vendida en el nivel de proveedor y región y ciudad:

SELECT supplier, region, city, qtysold
FROM suppliercity

La siguiente consulta solicita la cantidad vendida en el nivel de ciudad:

SELECT city, qtysold
FROM suppliercity

La segunda consulta tiene como resultado un acierto de caché en la primera consulta.

Agregación adicional limitada

Por ejemplo, si una consulta con la columna qtysold está almacenada en caché, una solicitud de RANK(qtysold) tiene como resultado una falta de caché. Además, una consulta que solicite qtysold en el nivel de país puede obtener un acierto de caché de una consulta que solicite qtysold en el nivel de país, región.

La cláusula ORDER BY debe estar compuesta por columnas de la lista de selección

Las consultas que ordenan por columnas que no están contenidas en la lista de selección tienen como resultado faltas de caché.

Diagnóstico del comportamiento del acierto de caché

Para una mejor evaluación del comportamiento del acierto de caché, defina la variable de sesión ENABLE_CACHE_DIAGNOSTICS en 4, como se muestra en el siguiente ejemplo:

ENABLE_CACHE_DIAGNOSTICS=4