Gestión de la caché de consulta

Oracle Analytics Cloud mantiene una caché local de juegos de resultados de consulta en la caché de consulta.

Temas:

Acerca de la caché de consulta

La caché de consulta permite a Oracle Analytics Cloud satisfacer muchas solicitudes de consulta subsiguientes sin acceder a orígenes de datos de backend, lo cual incrementa el rendimiento de la consulta. Sin embargo, las entradas de la caché de consulta podrían quedarse desactualizadas ya que las actualizaciones se producen en los orígenes de datos de backend.

Ventajas del almacenamiento en caché

La manera más rápida de procesar una consulta es omitir el bloque del procesamiento y utilizar una respuesta calculada previamente.

Con la caché de consulta, Oracle Analytics Cloud almacena los resultados de las consultas calculados previamente en una caché local. Si otra consulta puede utilizar esos resultados, se elimina todo el procesamiento de base de datos para dicha consulta. Esto puede causar una mejora considerable en el tiempo medio de respuesta de consulta.

Además de mejorar el rendimiento, poder responder a una consulta desde una caché local permite ahorrar recursos de red y tiempo de procesamiento en el servidor de base de datos. Se ahorran recursos de red porque los resultados intermedios no se devuelven a Oracle Analytics Cloud. Al no ejecutar la consulta en la base de datos se libera el servidor de base de datos para que realice otros trabajos. Si la base de datos utiliza un sistema de contracargo, la ejecución de menos consultas también puede reducir costos en el presupuesto.

Otra ventaja de utilizar la caché para responder a una consulta es el ahorro en el tiempo de procesamiento en Oracle Analytics Cloud, especialmente si los resultados de la consulta se recuperan de varias bases de datos. Dependiendo de la consulta, puede haber un procesamiento de unión y ordenación considerable en el servidor. Si ya se ha calculado la consulta, se evita este procesamiento, de este modo se liberan recursos del servidor para otras tareas.

En resumen, la caché de consulta puede mejorar el rendimiento de consulta y reducir el tráfico de red, el procesamiento de base de datos y la sobrecarga de procesamiento sustancialmente.

Costos del almacenamiento en caché

El almacenamiento en caché tienes muchas ventajas evidentes, pero también determinados costos.

  • La posibilidad de que los resultados almacenados en caché estén desactualizados

  • Costos administrativos de gestión de la caché

Con las gestión de la caché, normalmente los beneficios superan con creces los costos.

Tareas administrativas asociadas al almacenamiento en caché

Algunas tareas administrativas están asociadas al almacenamiento en caché. Debe definir correctamente el tiempo de persistencia de caché de cada tabla física, sabiendo con qué frecuencia se actualizan los datos de esa tabla.

Cuando la frecuencia de la actualización varía, debe realizar un seguimiento de cuándo se producen los cambios y depurar la caché manualmente cuando sea necesario.

Cómo mantener la caché actualizada

Si no se depuran las entradas de caché cuando cambian los datos en las bases de datos subyacentes, es posible que las consultas devuelvan resultados que no están actualizados.

Debe evaluar si esto es aceptable. Puede ser aceptable permitir que la caché contenga algunos datos desactualizados. Debe decidir qué nivel de datos desactualizados es aceptable y, a continuación, configurar (y seguir) un juego de reglas que reflejen ese nivel.

Por ejemplo, suponga que una aplicación analiza datos corporativos de un gran conglomerado y que usted está realizando resúmenes anuales de las diferentes divisiones de la compañía. Los nuevos datos no afectan significativamente a las consultas porque solo afectan a los resúmenes del siguiente año. En este caso, las compensaciones para decidir si se debe purgar la caché pueden decantarse a favor de dejar las entradas en la caché.

Sin embargo, suponga que las bases de datos se actualizan tres veces al día y que está realizando consultas sobre las actividades del día actual. En este caso, debe depurar la caché con mucha mayor frecuencia o quizás considerar la posibilidad de no utilizar la caché en absoluto.

Otro escenario puede ser que vuelva a crear el juego de datos desde el principio a intervalos periódicos (por ejemplo, una vez a la semana). En este ejemplo, puede purgar la caché completa como parte del proceso de recreación del juego de datos, garantizando que nunca tiene datos desactualizados en la caché.

Independientemente de la situación, debe evaluar qué es aceptable para la información no actual que se devuelve a los usuarios.

Uso compartido de la caché entre los usuarios

Si está activada la conexión compartida para un pool de conexiones concreto, se puede compartir la caché entre los usuarios y esta no se tiene que iniciar para cada usuario.

Si no está activada la conexión compartida y se utiliza una conexión a base de datos especifica del usuario, cada usuario genera su propia entrada de caché.

Activación o desactivación de la caché de consulta

En Oracle Analytics Cloud, la caché de consulta está activada por defecto. Puede activar o desactivar la caché de consulta en la página Configuración del sistema.

  1. Haga clic en Consola.
  2. Haga clic en Configuración del sistema.
  3. Haga clic en Rendimiento y compatibilidad.
  4. Defina Caché activada en activada o desactivada.
    • Activada: la caché de consulta de datos está activada.
    • Desactivada: el almacenamiento en caché está desactivado.
  5. Haga clic en Aplicar.
    Espere unos minutos para que los cambios se refresquen en el sistema.

Supervisión y gestión de la caché

Para gestionar los cambios en las bases de datos subyacentes y supervisar las entradas de caché, debe desarrollar una estrategia de gestión de caché.

Necesita un proceso para invalidar las entradas de caché cuando cambian los datos en las tablas subyacentes que componen la entrada de caché, así como un proceso para supervisar, identificar y eliminar todas las entradas de caché no deseadas.

Esta sección incluye los siguientes temas:

Selección de una estrategia de gestión de caché

La elección de una estrategia de gestión de caché depende de la volatilidad de los datos en las bases de datos subyacentes y de la previsibilidad de los cambios que causan esta volatilidad.

También depende del número y los tipos de consultas que componen la caché y del uso que se hace de dichas consultas. En esta sección se proporciona una visión general de los diferentes enfoques de la gestión de caché.

Desactivación del almacenamiento en caché para el sistema

Puede desactivar el almacenamiento en caché para todo el sistema a fin de impedir que todas las entradas de caché nuevas y todas las consultas nuevas utilicen la caché existente. La desactivación del almacenamiento en caché le permite activarla posteriormente sin perder ninguna de las entradas almacenadas en la caché.

La desactivación temporal del almacenamiento en cache es una estrategia útil en situaciones en las que pueda sospechar que tiene entradas de caché desactualizadas, pero desee verificar si están realmente desactualizadas antes de depurar dichas entradas o la caché completa. Una vez que haya comprobado que los datos almacenados en la caché siguen siendo relevantes, o que haya depurado las entradas problemáticas de forma segura, puede activar la caché de forma segura. Si es necesario, depure la caché completa o la caché asociada a un modelo de negocio concreto antes de volver a activar la caché.

Caché y tiempo de persistencia de caché para tablas físicas especificadas

Puede definir un atributo almacenable en caché para cada tabla física, lo cual le permite especificar si las consultas de esa tabla se agregan a la caché para responder a consultas futuras.

Si activa el almacenamiento en caché para una tabla, se agregarán a la caché todas las consultas referentes a la tabla. Todas las tablas se pueden almacenar en caché por defecto, pero es posible que algunas tablas no sean buenas candidatas para incluirlas en la caché a menos que configure el valor de persistencia de caché adecuado. Por ejemplo, suponga que tiene una tabla que almacene datos de cotizaciones bursátiles que se actualizan cada minuto Puede especificar que desea purgar las entradas de esa tabla cada 59 segundos.

También puede utilizar los valores de persistencia de caché para especificar cuánto tiempo se almacenan las entradas de esta tabla en la caché de consulta. Resulta útil para orígenes de datos que se actualizan con frecuencia.

  1. En la capa física de la herramienta de administración de modelos, haga doble clic en la tabla física.

    Si utiliza el modelador semántico, consulte ¿Cuáles son las propiedades generales de la tabla física?.

  2. En el cuadro de diálogo de propiedades Tabla física, en el separador General, realice una de las siguientes selecciones:

    • Para activar el almacenamiento en caché, seleccione Permite caché.

    • Para impedir que una tabla se almacene en caché, anule la selección de Permite caché.

  3. Para definir un tiempo de caducidad de caché, especifique un Tiempo de persistencia de caché y una unidad de medida (días, horas, minutos o segundos). Si no desea que caduquen automáticamente las entradas de caché, seleccione La caché nunca caduca.

  4. Haga clic en Aceptar.

Cómo afectan los cambios en el modelo semántico a la caché de consulta

Cuando modifica los modelos semánticos mediante el modelador semántico o la herramienta de administración de modelos, estos cambios pueden tener implicaciones para las entradas que se almacenan en la caché. Por ejemplo, si cambia la definición de un objeto físico o de una variable de modelo semántico dinámica, es posible que las entradas de caché que hacen referencia a dicho objeto o variable ya no sean válidas. Estos cambios pueden provocar la necesidad de depurar la caché. Hay dos escenarios que se deben tener en cuenta: cuando modifica el modelo semántico existente y cuando crea (o carga) un nuevo modelo semántico.

Cambios en el modelo semántico

Cuando modifica un modelo semántico o carga un archivo .rpd diferente, todos los cambios que realice que afecten a las entradas de caché provocan automáticamente la depuración de todas las entradas de caché que hacen referencia a los objetos modificados. La depuración se produce cuando carga los cambios. Por ejemplo, si suprime una tabla física de un modelo semántico, se depuran todas las entradas de caché que hacen referencia a esa tabla al desbloquear. Cualquier cambio que se realice en un modelo semántico en la capa lógica depurará todas las entradas de caché para dicho modelo semántico.

Cambios en las variables de modelo semántico globales

Los valores de las variables de modelo semántico globales se refrescan con los datos que se devuelven de las consultas. Al definir una variable de modelo semántico global, debe crear un bloque de inicialización o utilizar uno existente que contenga una consulta SQL. También configura un programa para ejecutar la consulta y refrescar periódicamente el valor de la variable.

Si cambia el valor de una variable de modelo semántico global, quedarán desactualizadas todas las entradas de caché que utilizan esta variable en una columna y se generará una nueva entrada de caché cuando los datos de esa entrada vuelvan a ser necesarios. La antigua entrada de caché no se elimina inmediatamente, sino que permanece hasta que se limpia mediante el mecanismo normal de almacenamiento en caché.

Estrategias de uso de la caché

Una de las principales ventajas de la caché de consulta es la mejora del rendimiento aparente de consulta.

La caché de consulta puede ser valiosa para iniciar la caché durante las horas libres mediante la ejecución de consultas y el almacenamiento en caché de sus resultados. Una buena estrategia de inicio requiere que conozca cuándo se producen los aciertos de caché.

Si desea iniciar la caché para todos los usuarios, puede iniciarla con la siguiente consulta:

SELECT User, SRs

Una vez iniciada la caché con SELECT User, SRs, las siguientes consultas son aciertos de caché:

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)

Esta sección incluye los siguientes temas:

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

Garantizar resultados de caché correctos al utilizar la seguridad de base de datos de nivel de fila

Al utilizar una estrategia de seguridad de base de datos de nivel de fila, como la base de datos privada virtual (VPD), los resultados de datos devueltos dependen de las credenciales de autorización del usuario.

Debido a esto, Oracle Analytics Cloud debe conocer si un origen de datos está utilizando la seguridad de base de datos de nivel de fila y qué variables son relevantes para la seguridad.

Para garantizar que los aciertos de caché solo se producen en las entradas de caché que incluyen y coinciden con todas las variables sensibles a la seguridad, debe configurar correctamente el objeto de base de datos y los objetos de variable de sesión en la herramienta de administración de modelos como se describe a continuación:

  • Objeto de base de datos. En la capa física, en el separador General del cuadro de diálogo Base de datos, seleccione Base de datos privada virtual para especificar que el origen de datos está utilizando la seguridad de base de datos de nivel de fila.

    Si está utilizando la seguridad de base de datos de nivel de fila con el almacenamiento en caché compartido, debe seleccionar esta opción para evitar que se compartan entradas de caché cuyas variables sensibles a la seguridad no coincidan.

  • Objeto de variable de sesión. Para las variables relacionadas con la seguridad, en el cuadro de diálogo Variable de sesión, seleccione Sensible a seguridad para identificarlas como sensibles a la seguridad al utilizar una estrategia de seguridad de base de datos de nivel de fila. Esta opción garantiza que las entradas de caché se marquen con las variables sensibles a la seguridad, lo que permite la coincidencia de variables sensibles a la seguridad en todas las consultas entrantes.

Ejecución de una serie de consultas para rellenar la caché

Para maximizar los aciertos de caché potenciales, una estrategia consiste en ejecutar una serie de consultas para rellenar la caché.

A continuación se ofrecen algunas recomendaciones sobre los tipos de consultas que se deben usar al crear una serie de consultas con las que iniciar la caché.

  • Consultas predefinidas comunes. Las consultas que se ejecutan normalmente, concretamente las que son más costosas de procesar, son excelentes consultas de inicio de la caché. Las consultas cuyos resultados están embebidos en paneles de control son buenos ejemplos de consultas comunes.

  • Listas SELECT sin expresiones. La eliminación de expresiones en las columnas de listas SELECT aumentan la posibilidad de que se produzcan aciertos de caché. Una columna almacenada en caché con una expresión solo puede responder a una nueva consulta con la misma expresión; una columna almacenada en caché sin expresiones puede responder a una solicitud para esa columna con cualquier expresión. Por ejemplo, una solicitud almacenada en caché, como:

    SELECT QUANTITY, REVENUE...

    puede responder a una nueva consulta, como:

    SELECT QUANTITY/REVENUE...

    pero no al contrario.

  • Ninguna cláusula WHERE. Si no hay ninguna cláusula WHERE en un resultado almacenado en caché, este se puede utilizar para responder a consultas que cumplan las reglas de aciertos de caché para la lista seleccionada con cualquier cláusula WHERE que incluya columnas en la lista de proyecciones.

En general, las mejores consultas con las que iniciar la caché son aquellas que consumen muchos recursos de procesamiento de base de datos y que es probable que se vuelvan a emitir. Tenga cuidado de no iniciar la caché con consultas simples que devuelven muchas filas. Estas consultas (por ejemplo, SELECT * FROM PRODUCTS, donde PRODUCTS se asigna directamente a una única tabla de base de datos) requieren un procesamiento de base de datos muy reducido. Su costo es una sobrecarga de red y de disco, y estos factores no se reducen con el almacenamiento en caché.

Cuando Oracle Analytics Cloud refresca las variables del modelo semántico, examina los modelos de negocio para determinar si hacen referencia a esas variables de modelo semántico. En caso afirmativo, Oracle Analytics Cloud depura toda la caché para estos modelos de negocio. Consulte Cómo afectan los cambios en el modelo semántico a la caché de consulta.

Uso de agentes para iniciar la caché de consulta

Puede configurar agentes para iniciar la caché de consulta de Oracle Analytics Cloud.

El inicio de la caché puede mejorar los tiempos de respuesta para los usuarios cuando ejecutan o visualizan análisis embebidos en sus paneles de control. Puede realizarlo mediante la programación de agentes para que ejecuten solicitudes que refresquen estos datos.

  1. En Oracle Analytics Cloud, abra la página de inicio clásica y seleccione Agente (sección Crear).
  2. En el separador General, seleccione Destinatario para la opción Ejecutar como. El inicio personalizado de la caché utiliza la visibilidad de datos de cada destinatario para personalizar el contenido de entrega del agente para cada destinatario.
  3. Rn el separador Programar, especifique cuándo desea que se inicie la caché.
  4. Opcional: Seleccione Condición y cree o seleccione una solicitud condicional. Por ejemplo, podría tener un modelo de negocio que determine cuándo se completa el proceso de ETL. Podría utilizar un informe basado en este modelo de negocio para que sea al disparador condicional para que empiece el inicio de la caché.
  5. En el separador Contenido de entrega, seleccione una solicitud individual o una página de panel de control completa para la que desee iniciar la caché. La selección de una página de panel de control puede ahorrar tiempo.
  6. En el separador Destinatarios, seleccione los usuarios individuales o los grupos que serán los destinatarios.
  7. En el separador Destino, borre todos los destinos de usuario y seleccione Caché de Oracle Analytics Server.
  8. Guarde el agente seleccionando el botón Guardar en la esquina superior derecha.

La única diferencia entre los agentes de inicio de caché y otros agentes es que borran la caché anterior automáticamente y no aparecen en el panel de control como alertas.

Nota:

Los agentes de inicio de caché solo depuran las consultas de coincidencia exacta, por lo que los datos desactualizados podrían seguir existiendo. Asegúrese de que la estrategia de almacenamiento en caché siempre incluya la depuración de la caché, ya que las consultas de agente no abordan las consultas ad hoc ni los cambios de nivel.

Uso de la herramienta de administración de modelos para depurar automáticamente la caché de tablas específicas

La depuración de la caché suprime las entradas de la caché de consulta y mantiene el contenido refrescado. Puede depurar automáticamente las entradas de caché de tablas específicas definiendo el campo Tiempo de persistencia de caché para cada tabla en la herramienta de administración de modelos.

Nota:

Si utiliza el modelador semántico, consulte ¿Cuáles son las propiedades generales de la tabla física?

Resulta útil para orígenes de datos que se actualizan con frecuencia. Por ejemplo, si tiene una tabla que almacena datos de cotizaciones bursátiles que se actualizan cada minuto, puede utilizar el valor Tiempo de persistencia de caché para depurar las entradas de esa tabla cada 59 segundos. Consulte Caché y tiempo de persistencia de caché para tablas físicas especificadas.

Borrado de la caché de forma programada

Puede utilizar una estrategia automatizada para borrar (o depurar) la caché del entorno de Oracle Analytics Cloud según sea necesario.

Esta sección incluye los siguientes temas:

Acerca de la utilidad para borrar la caché (purgeoaccache)

Oracle Analytics proporciona una utilidad que se puede ejecutar para borrar la caché: purgeoaccache.sh. Esta utilidad ofrece distintas opciones para borrar la caché. Puede borrar la caché completa o borrar la caché asociada a una consulta, tabla o base de datos específica.

  • Borrar la caché completa (SAPurgeAllCache)

    En sapurgecache.txt, llame a la función SAPurgeAllCache para borrar todas las entradas de la caché. Éste es el estado por defecto.

    La sentencia CALL tiene este aspecto: 
    Call SAPurgeAllCache();

  • Borrar la caché de una consulta (SAPurgeCacheByQueryPurge)

    En sapurgecache.txt, llame a la función SAPurgeCacheByQueryPurge para borrar las entradas de la caché que coincidan exactamente con una consulta específica.

    Por ejemplo, imagine que tiene la siguiente consulta, en la que una o varias entradas de la caché de consulta recuperan los nombres de todos los empleados que ganan más de 100.000 dólares: 
    SELECT lastname, firstname FROM employee WHERE salary > 100000;
    La siguiente sentencia CALL borra las entradas de la caché asociadas a esta consulta: 
    Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );

  • Borrar la caché de una tabla (SAPurgeCacheByTable)

    En sapurgecache.txt, llame a la función SAPurgeCacheByTable para borrar las entradas de la caché asociadas a una tabla de base de datos física específica. La función toma hasta cuatro parámetros, cada uno de los cuales representa los componentes del nombre totalmente cualificado de una tabla física (nombre de base de datos, catálogo, esquema y tabla).

    Nota:

    No se pueden utilizar comodines en los parámetros de función. Además, tanto el nombre de la base de datos como el nombre de la tabla son parámetros obligatorios, por lo que no pueden ser nulos.
    Por ejemplo, imagine que tiene una tabla con el nombre totalmente cualificado DBName.CatName.SchName.TabName. La siguiente sentencia CALL borra las entradas de la caché asociadas a esta tabla en la capa física del modelo semántico: 
    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

  • Borrar la caché de una base de datos (SAPurgeCacheByDatabase)

    En sapurgecache.txt, llame a la función SAPurgeCacheByDatabase para borrar las entradas de la caché asociadas a una base de datos física específica. La función toma un parámetro que representa el nombre de la base de datos física y que no puede ser nulo.

    La sentencia CALL tiene este aspecto: 
    Call SAPurgeCacheByDatabase( 'DBName' );

Flujo de trabajo típico para borrar la caché de forma programada

A continuación se indican las tareas para borrar la caché del entorno de Oracle Analytics Cloud.

Tarea Descripción Más información

Decida cómo desea proteger su conexión JDBC

En función de sus requisitos de seguridad, elija el tipo de afirmación entre Propietario de recurso (recomendado) o Tokens web JSON (JWT).

Consulte Elección del tipo de afirmación para la conexión JDBC en la guía Conexión de Oracle Analytics Cloud a sus datos.

Registro de la aplicación BIJDBC

Registre la aplicación BIJDBC para autenticar la conexión de JDBC.

Para la afirmación de propietario de recursos, consulte Registro de la aplicación BIJDBC mediante una afirmación de propietario de recursos en la guía Conexión de Oracle Analytics Cloud a sus datos.

Para la afirmación de JWT, en la guía Conexión de Oracle Analytics Cloud a sus datos:

Descargue y configure la utilidad para borrar la caché

Descargue los archivos BI-JDBC.zip y bi-jdbc-all.jar y configure la utilidad.

Descarga y configuración de la utilidad para borrar la caché

Proporcione la información de conexión de OAuth

Utilice la consola de OCI para obtener los detalles de conexión de OAuth necesarios para conectarse a Oracle Analytics Cloud e introduzca la información en bijbdc.properties.

Adición de los detalles de conexión a bijbdc.properties
Ejecute la utilidad para borrar la caché Identifique la caché que desea borrar y ejecute la utilidad para borrar la caché especificada. Ejecución de la utilidad para borrar la caché (purgeoaccache)
Cree un script para borrar la caché periódicamente (opcional) Utilice un trabajo Cron (o similar) para borrar la caché según una programación periódica adecuada para su organización. Creación de un script para borrar la caché según una programación periódica

Descarga y configuración de la utilidad para borrar la caché

Antes de usar la utilidad para borrar la caché, debe descargar el archivo BI-JDBC.zip y realizar una serie de tareas de configuración. Por ejemplo, tendrá que obtener el archivo bijdbc-all.jar y definir la variable JAVA_HOME.

  1. Descargue el archivo BI-JDBC.zip.
  2. Descomprima el archivo BI-JDBC.zip.
  3. Familiarícese con los siguientes archivos y carpetas:
    • \certs: carpeta en la que copiará los archivos de certificado y clave privada necesarios para la autorización OAuth 2.0 de JWT.
    • \lib: carpeta en la que copiará el archivo bijdbc-all.jar. Este archivo jar contiene los controladores JDBC que se utilizan para conectarse a Oracle Analytics Cloud.
    • \props: esta carpeta contiene los archivos de configuración de la utilidad para borrar la caché.
    • bijdbc.properties: la utilidad para borrar la caché usa la información de este archivo para conectarse a Oracle Analytics Cloud. Existen dos versiones de este archivo. La versión que se encuentra en \rowner contiene los parámetros de conexión necesarios para conectarse como "propietario de recursos". La versión que se encuentra en \jwt contiene los parámetros de conexión necesarios para conectarse mediante JWT (token web JSON).
    • sapurgecache.txt: la utilidad para borrar la caché usa este archivo para determinar qué caché borrar; es decir, si hay que borrarlo todo o solo las entradas de caché de una consulta, tabla o base de datos específica.
    • \src: carpeta que contiene el archivo purgecache.jar.
    • purgeoaccache.bat y purgeoaccache.sh: utilidad que se ejecuta para borrar la caché.
  4. Compruebe que JAVA_HOME se haya definido correctamente en purgeoaccache (.sh o .bat).
    1. En la carpeta BI-JDBC, abra el archivo purgeoaccache que vaya a utilizar (.sh para Linux, .bat para Windows).
    2. Compruebe que la variable JAVA_HOME sea la carpeta de JDK adecuada de su entorno y, si es necesario, actualícela.
  5. Obtenga los controladores JDBC necesarios para conectarse a Oracle Analytics Cloud (bijdbc-all.jar ).
    1. Si todavía no lo ha hecho, descargue el controlador JDBC. Consulte Descargar el controlador de JDBC en la guía Conexión de Oracle Analytics Cloud a sus datos.
    2. Copie el archivo bijdbc-all.jar y péguelo en BI-JDBC/lib.

Adición de los detalles de conexión a bijbdc.properties

Utilice la consola de Oracle Cloud Infrastructure (OCI) para obtener la información de conexión necesaria para el archivo bijdbc.properties.

Para completar esta tarea, debe tener permiso para acceder a la consola de OCI.
  1. Conéctese a la consola de OCI y vaya a la página Detalles adicionales de la instancia de Oracle Analytics Cloud.
    1. En la consola de OCI, haga clic en Icono del menú de navegación, en la esquina superior izquierda.
    2. Haga clic en Análisis e IA. En Análisis, haga clic en Analytics Cloud.
    3. Seleccione el compartimento que contiene la instancia de Oracle Analytics Cloud que está buscando.
    4. Haga clic en el nombre de la instancia.
    5. Haga clic en Detalles adicionales.
  2. Recupere la información de conexión necesaria para el archivo bijdbc.properties.
    1. Para obtener oacHostname y idcsEndpointUrl, en Información de red, copie el valor de Nombre de host y, en Proveedor de identidad, copie el valor de Segmento.
    2. Para obtener idcsClientId, en Proveedor de identidad, haga clic en el enlace de aplicación para acceder a la configuración de OAuth para la instancia. Vaya a la sección Información general y registre el ID de cliente.
    3. Para obtener idcsClientScope, desplácese hasta la sección de configuración de las API de aplicación que se deben proteger mediante OAuth y registre el valor de Ámbito.
    4. Si está utilizando el tipo de afirmación de propietario de recursos para proteger la conexión de JDBC con Oracle Analytics Cloud, obtenga idcsClientSecret. Vaya a la sección Información general y registre el secreto de cliente.
    5. Si está utilizando el tipo de afirmación de JWT para proteger la conexión de JDBC con Oracle Analytics Cloud, obtenga certificateFile y privateKeyFile; es decir, el nombre y la ubicación de los archivos .cert y .pem que ha utilizado para crear la configuración de OAuth para la instancia y que ha copiado en la carpeta /certs.

      Nota:

      Si no ha copiado los archivos .cert y .pem en la carpeta de certificados, hágalo ahora.
  3. Copie el archivo bijdbc.properties que desee utilizar y péguelo en la carpeta BI-JDBC/props/ para poder personalizarlo.
    La plantilla de propietario de recursos se encuentra en la carpeta props/rowner. La plantilla de JWT se encuentra en la carpeta props/jwt.
  4. Agregue los detalles de conexión registrados en el paso 2, junto con su nombre de usuario y contraseña de administrador, al archivo bijdbc.properties.
    Ejemplo de propietario de recursos: 
    ########OAC Hostname Value############
oacHostname=<Hostname value>

######Below Values Collected From IDCS Confidential App#########
idcsEndpointUrl=<Stripe value>
idcsClientId=<Client ID value>
idcsClientScope=<concatenation of the Primary audience and Scope values>
idcsClientSecret=<Client Secret value>

######Service Administrator UserId & Password#########
user=<OAC admin username>
password=<OAC admin password>
    Ejemplo de JWT: 
    ########OAC Hostname Value############
oacHostname=<Hostname value>

######Below Values Collected From IDCS Confidential App#########
idcsEndpointUrl=<Stripe value>
idcsClientId=<Client ID value>
idcsClientScope=<Scope value>

######Public Key and Private Key File Paths########
certificateFile=./certs/bijdbcclient.cert
privateKeyFile=./certs/bijdbcclient.pem <private key file bijdbcclient.pem location that exist inside BI-JDBC/certs>

######Service Administrator UserId#########
user=<OAC admin username>

######Optional Properties########
LOGFILEPATH=./temp
LOGLEVEL=SEVERE
  5. Guarde y cierre el archivo.

Ejecución de la utilidad para borrar la caché (purgeoaccache)

Una vez completada la configuración y definido el archivo bijdbc.properties, ya puede ejecutar el script. El script borrará toda la caché por defecto. Si desea borrar las entradas de la caché de una consulta, tabla o base de datos en concreto, indique la función y los parámetros que sean necesarios en sapurgecache.txt.

  1. Opcional: En la carpeta BI-JDBC/props, abra el archivo sapurgecache.txt y actualice la sentencia CALL para especificar qué entradas de la caché desea que borre el script. Consulte Acerca de la utilidad para borrar la caché (purgeoaccache).
  2. Ejecute la utilidad para borrar la caché (BI-JDBC\purgeoaccache). En Linux, ejecute purgeoaccache.sh. En Windows, ejecute purgeoaccache.bat.
Se muestra un mensaje que indica que la caché se ha borrado correctamente.

Creación de un script para borrar la caché según una programación periódica

Puede crear un script personalizado, como un trabajo Cron (o similar), que borre la caché según una programación adecuada para su organización.

Por ejemplo, puede ejecutar un script personalizado cada día a las 11:00 PM para depurar toda la caché. En este caso, la entrada de Cron podría tener este aspecto: 
$crontab -e
0 23 * * * /bin/bash ~/BI-JDBC/purgeoaccache.sh >> ~/BI-JDBC/temp/purgeoaccache.log 2>&1