Gestire l'inserimento delle query nella cache

Oracle Analytics Cloud gestisce una cache locale di set di risultati delle query nella cache delle query.

Argomenti:

Informazioni sulla cache delle query

La cache delle query consente a Oracle Analytics Cloud di soddisfare molte richieste di query successive senza accedere alle origini dati backend, aumentando in questo modo le prestazioni delle query. Le voci della cache delle query possono tuttavia risultare non più valide se vengono eseguiti aggiornamenti nelle origini dati backend.

Vantaggi dell'inserimento nella cache

Il modo più veloce per elaborare una query consiste nel saltare l'elaborazione e nell'utilizzare una risposta precalcolata.

Con l'inserimento delle query nella cache, Oracle Analytics Cloud memorizza i risultati precalcolati delle query in una cache locale. Se un'altra query può utilizzare questi risultati, tutta l'elaborazione del database per tale query verrà eliminata. Il tempo di risposta medio per le query verrà così ridotto drasticamente.

Oltre a migliorare le prestazioni, la capacità di rispondere a una query da una cache locale preserva le risorse di rete e fa risparmiare tempo di elaborazione nel database server. Le risorse di rete vengono conservate perché i risultati intermedi non vengono restituiti a Oracle Analytics Cloud. Quando non si esegue la query nel database, il database server può dedicarsi ad altre operazioni. Se il database utilizza un sistema di riaddebito, l'esecuzione di un numero di query minore può anche ridurre i costi nel budget.

Un altro vantaggio dell'uso della cache per rispondere a una query è il risparmio in termini di tempo di elaborazione in Oracle Analytics Cloud, in particolar modo quando i risultati delle query vengono recuperati da più database. A seconda della query, l'elaborazione di join e ordinamento nel server può essere considerevole. Se la query è già stata calcolata, questa elaborazione verrà evitata e le risorse del server potranno essere utilizzate per altri task.

Riepilogando, è possibile affermare che l'inserimento delle query nella cache può migliorare in modo significativo le prestazioni delle query e ridurre il traffico di rete, l'elaborazione del database e il sovraccarico di elaborazione.

Costi dell'inserimento nella cache

L'inserimento delle query nella cache presenta molti vantaggi evidenti, ma comporta anche alcuni costi.

  • I risultati inseriti nella cache possono diventare non più validi

  • Costi amministrativi per la gestione della cache

Con la gestione della cache in genere in vantaggi superano di gran lunga i costi.

Task amministrativi associati all'inserimento nella cache

Alla funzione di inserimento nella cache sono associati alcuni task amministrativi. È necessario impostare in modo appropriato il tempo di persistenza della cache per ogni tabella fisica, conoscendo la frequenza di aggiornamento dei dati nelle tabelle.

Quando la frequenza di aggiornamento varia, è necessario tenere traccia del momento in cui si verificano le modifiche e rimuovere manualmente il contenuto della cache quando necessario.

Mantenere aggiornata la cache

Se le voci della cache non vengono rimosse quando si modificano i dati dei database di base, è possibile che le query restituiscano risultati non aggiornati.

È necessario valutare se tale eventualità può essere accettata o meno. Può essere considerato accettabile consentire che la cache contenga alcuni dati non più validi. È necessario stabilire il livello accettabile di dati non più validi e configurare, nonché applicare, un set di regole che rifletta il livello stabilito.

Si supponga, ad esempio, che un'applicazione analizzi i dati aziendali da un insieme di grandi dimensioni e di lavorare sui riepiloghi annuali delle varie divisioni della società. I nuovi dati non interessano materialmente le query, perché interessano solo i riepiloghi dell'anno successivo. In questo caso si potrebbe considerare più opportuna la decisione di lasciare le voci nella cache.

Si supponga, tuttavia, che i database vengano aggiornati tre volte al giorno e che si stiano eseguendo query sulle attività del giorno corrente. In questo caso è necessario eseguire più spesso le operazioni di rimozione delle voci della cache o addirittura decidere di non utilizzare affatto la cache.

Un altro scenario consiste nel ricreare daccapo il data set a intervalli periodici, ad esempio una volta alla settimana. In questo caso è possibile rimuovere l'intero contenuto della cache nell'ambito del processo di ricreazione del data set, garantendo in questo modo che la cache non contenga mai dati non più validi.

A prescindere dalla propria situazione personale, è necessario valutare cosa sia accettabile per le informazioni non correnti restituite agli utenti.

Condivisione della cache tra gli utenti

Se il collegamento condiviso è abilitato per un determinato connection pool, la cache può essere condivisa tra gli utenti e non è necessario popolarla per ogni utente.

Se invece il collegamento condiviso non è abilitato e si utilizza un login al database specifico per utente, ogni utente genera la propria voce di cache.

Abilitare o disabilitare l'inserimento delle query nella cache

In Oracle Analytics Cloud la cache delle query è abilitata per impostazione predefinita. È possibile abilitare o disabilitare l'inserimento delle query nella cache nella pagina Impostazioni di sistema.

  1. Fare clic su Console.
  2. Fare clic su Impostazioni di sistema.
  3. Fare clic su Prestazioni e compatibilità.
  4. Impostare Abilitazione cache su Attivo o su Non attivo.
    • Attivo: l'inserimento delle query di dati nella cache è abilitato.
    • Non attivo: l'inserimento nella cache è disabilitato.
  5. Fare clic su Applica.
    Attendere alcuni secondi per consentire l'aggiornamento delle modifiche nel sistema.

Monitorare e gestire la cache

Per gestire le modifiche nei database di base e monitorare le voci della cache, è necessario sviluppare una strategia di gestione della cache.

È necessario un processo per invalidare le voci della cache quando i dati nelle tabelle di base che le compongono vengono modificati cambiano e un processo per monitorare, identificare e rimuovere eventuali voci della cache indesiderate.

Questa sezione contiene gli argomenti riportati di seguito.

Scegliere una strategia di gestione della cache

La scelta di una strategia di gestione della cache dipende dalla volatilità dei dati nei database di base e dalla prevedibilità delle modifiche che causano tale volatilità.

Dipende inoltre dal numero e dai tipi di query che costituiscono la cache e dalle modalità d'uso di tali query. In questa sezione viene fornita una panoramica dei vari approcci di gestione della cache.

Disabilitare l'inserimento nella cache per il sistema

È possibile disabilitare la funzione di inserimento nella cache per l'intero sistema per impedire la creazione di nuove voci e fare in modo che le nuove query non utilizzino la cache esistente. La disabilitazione dell'inserimento nella cache consente di abilitare di nuovo la funzione più tardi senza perdere le voci memorizzate ella cache.

La disabilitazione temporanea dell'inserimento nella cache è una strategia utile nelle situazioni in cui si sospetta l'esistenza di voci non più valide e si desidera verificare che siano effettivamente non più valide prima di procedere alla rimozione delle voci o dell'intera cache. Se si riscontra che i dati memorizzati nella cache sono ancora pertinenti o dopo aver rimosso le voci che costituivano un problema, è possibile abilitare in modo sicuro la cache. Se necessario, rimuovere l'intera cache o la cache associata a un modello aziendale particolare prima di abilitare di nuovo la cache.

Cache e tempo di persistenza della cache per le tabelle fisiche specificate

È possibile impostare un attributo inseribile nella cache per ogni tabella fisica, il che consente di specificare se le query per tale tabella vengono aggiunte alla cache per rispondere a query future.

Se si abilita l'inserimento nella cache per una tabella, qualsiasi query che interessa la tabella verrà aggiunta alla cache. Tutte le tabelle sono inseribili nella cache per impostazione predefinita, ma alcune potrebbero non essere adeguate per l'inclusione nella cache a meno che non si definiscano le impostazioni di persistenza cache appropriate. Si supponga, ad esempio, di disporre di una tabella in cui sono memorizzati i dati dei ticker azionari che vengono aggiornati ogni minuto. È possibile specificare che si desidera rimuovere le voci per la tabella ogni 59 secondi.

È inoltre possibile utilizzare le impostazioni di persistenza cache per specificare il periodo di tempo durante il quale le voci della tabella dovranno essere memorizzate nella cache delle query. Ciò è utile per le origini dati che vengono aggiornate spesso.

  1. In Model Administration Tool, nel layer fisico, fare doppio clic sulla tabella fisica.

    Se si utilizza Semantic Modeler, vedere Descrizione delle proprietà generali di una tabella fisica.

  2. Nella scheda Generale della finestra di dialogo delle proprietà Tabella fisica, effettuare una delle selezioni seguenti:

    • per abilitare l'inserimento nella cache, selezionare Inseribile nella cache;

    • per impedire l'inserimento di una tabella nella cache, deselezionare Inseribile nella cache;

  3. Per impostare il periodo di scadenza della cache, specificare un valore per Tempo persistenza cache e l'unità di misura (giorni, ore, minuti o secondi). Se non si desidera che le voci della cache scadano in modo automatico, selezionare La cache non scade mai.

  4. Fare clic su OK.

Effetto delle modifiche al modello semantico sulla cache delle query

Quando si modificano i modelli semantici con Semantic Modeler o Model Administration Tool, le modifiche possono avere conseguenze per le voci memorizzate nella cache. Ad esempio, se si modifica la definizione di un oggetto fisico o di una variabile di modello semantico dinamica, le voci della cache che fanno riferimento a tale oggetto o variabile potrebbero non essere più valide. Queste modifiche potrebbero comportare la necessità di rimuovere la cache. Esistono due scenari di cui tenere conto: quando si modifica il modello semantico esistente e quando si crea (o si carica) un nuovo modello semantico.

Modifiche al modello semantico

Quando si modifica un modello semantico o si carica un file .rpd diverso, le modifiche che hanno effetto sulle voci della cache comportano automaticamente la rimozione di tutte le voci della cache che fanno riferimento agli oggetti modificati. La rimozione si verifica quando si caricano le modifiche. Ad esempio, se si elimina una tabella fisica da un modello semantico, tutte le voci della cache che fanno riferimento alla tabella eliminata verranno rimosse all'esecuzione del check-in. Qualsiasi modifica apportata a un modello semantico nel livello Logico comporterà la rimozione di tutte le voci della cache relative a tale modello.

Modifiche alle variabili di modello semantico globali

I valori delle variabili di modello semantico globali vengono aggiornati in base ai dati restituiti dalle query. Quando si definisce una variabile di modello semantico globale, si crea un blocco di inizializzazione o se ne utilizza uno già esistente che contiene una query SQL. È inoltre possibile configurare una pianificazione per eseguire la query e aggiornare periodicamente il valore della variabile.

Se il valore di una variabile di modello semantico globale cambia, qualsiasi voce della cache che utilizza la variabile in una colonna diventa non più valida e quando i dati in tale voce sono nuovamente necessari viene generata una nuova voce della cache. La vecchia voce della cache non viene rimossa immediatamente, ma rimane fino a quando non ne viene eseguito il cleanup tramite il meccanismo di inserimento nella cache abituale.

Strategie per l'uso della cache

Uno dei principali vantaggi dell'inserimento delle query nella cache consiste nel miglioramento delle prestazioni apparenti delle query.

L'inserimento delle query nella cache può essere utile per popolare la cache durante le ore di inattività mediante l'esecuzione delle query e l'inserimento dei risultati nella cache. Una strategia di popolamento valida richiede che l'utente sappia quando si verificano gli accessi alla cache.

Se si desidera popolare la cache per tutti gli utenti, è possibile utilizzare la query seguente:

SELECT User, SRs

Dopo aver popolato la cache con SELECT User, SRs, le query seguenti costituiscono accessi alla cache:

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)

Questa sezione contiene gli argomenti riportati di seguito.

Informazioni sugli accessi alla cache

Quando l'inserimento nella cache è abilitato, ogni query viene valutata per determinare se è idonea per l'accesso alla cache.

Con l'espressione accesso alla cache si indica che Oracle Analytics Cloud è stato in grado di utilizzare la cache per rispondere alla query senza ricorrere affatto al database. Oracle Analytics Cloud può utilizzare la cache delle query per rispondere alle query allo stesso livello di aggregazione o a un livello di aggregazione più elevato.

L'accesso alla cache è determinato da vari fattori. Questi fattori sono descritti nella tabella riportata di seguito.

Fattore o regola Descrizione

Un subset di colonne nella lista SELECT deve corrispondere

Tutte le colonne nella lista SELECT di una nuova query devono esistere nella query inserita nella cache per essere idonee per un accesso alla cache oppure devono poter essere calcolate dalle colonne nella query.

Questa regola descrive il requisito minimo per accedere alla cache, ma soddisfarla non garantisce che l'accesso alla cache si verifichi. Vengono applicate anche le altre regole elencate in questa tabella.

Le colonne nella lista SELECT possono essere costituite da espressioni presenti nelle colonne delle query inserite nella cache

Oracle Analytics Cloud è in grado di calcolare le espressioni dei risultati inseriti nella cache per rispondere alla nuova query, ma tutte le colonne devono trovarsi nel risultato inserito nella cache. Ad esempio, la query:

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

accede alla cache nella query:

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

perché averageprice può essere calcolato da dollars e unitsales (averageprice = dollars/unitsales).

La clausola WHERE deve essere uguale dal punto di vista semantico o essere un subset logico

Affinché la query venga ritenuta idonea per l'accesso alla cache, i vincoli della clausola WHERE devono essere equivalenti ai risultati inseriti nella cache o a un subset dei risultati inseriti nella cache.

Una clausola WHERE che costituisce un subset logico di una query inserita nella cache viene ritenuta idonea per l'accesso alla cache se il subset soddisfa uno dei criteri riportati di seguito.

  • Subset di valori della lista IN. Le query che richiedono un numero di elementi minore di una query inserita nella cache della lista IN sono idonee per l'accesso alla cache. Ad esempio, la query seguente:

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

    è idonea per l'accesso alla query inserita nella cache seguente:

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

  • Contiene un numero di vincoli OR minore (ma vincoli identici) rispetto al risultato inserito nella cache.

  • Contiene un subset logico di un confronto di valori. Ad esempio, il predicato seguente:

    WHERE revenue < 1000

    è idonea per l'accesso alla cache per una query confrontabile con il predicato:

    WHERE revenue < 5000

  • Non vi è alcuna clausola WHERE. Se una query senza clausola WHERE viene inserita nella cache, le query che soddisfano tutte le altre regole di accesso alla cache vengono ritenute idonee a prescindere dalle relative clausole WHERE.

Inoltre, le colonne utilizzate nella clausola WHERE deve esistere nella lista di proiezione. Ad esempio, la query seguente:

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

non comporta un accesso alla cache per la query di popolamento nella lista precedente perché REGION non si trova nella lista di proiezione.

Le query solo dimensioni devono costituire una corrispondenza esatta

Se una query è del tipo solo dimensioni, ovvero è priva di fact o misure incluse, solo una corrispondenza esatta delle colonne di proiezione della query inserita nella cache comporta l'accesso alla cache. Questo funzionamento impedisce i falsi positivi in presenza di più origini logiche per una tabella dimensione.

Le query con funzioni speciali devono costituire una corrispondenza esatta

Anche le altre query che contengono funzioni speciali, quali ad esempio funzioni di serie temporali (AGO, TODATE e PERIODROLLING), funzioni LIMIT e di offset (OFFSET e FETCH), funzioni di relazione (ISANCESTOR, ISLEAF, ISROOT e ISSIBLING), funzioni di aggregazione esterne e in generale le metriche di filtro devono costituire una corrispondenza esatta con le colonne di proiezione nella query inserita nella cache. In questi casi anche il filtro deve costituire una corrispondenza esatta. Per le metriche di filtro, se possono essere riscritte come clausola WHERE, potrà essere utilizzata la cache del subset.

Il set di tabelle logiche deve corrispondere

Per essere considerate idonee per l'accesso alla cache, tutte le query in entrata devono avere lo stesso set di tabelle logiche come voce della cache. Questa regola evita che si verifichino falsi accessi alla cache. Ad esempio, SELECT * FROM product non corrisponde a SELECT * FROM product, sales.

I valori delle variabili di sessione, comprese le variabili di sessione inerenti alla sicurezza, devono corrispondere

Se l'istruzione SQL logico o SQL fisico fa riferimento a una variabile di sessione qualsiasi, i valori delle variabili di sessione devono corrispondere. In caso contrario, l'accesso alla cache non si verifica.

Inoltre, il valore delle variabili di sessione sensibili alla sicurezza deve corrispondere ai valori delle variabili della sessione di sicurezza definiti nel modello semantico, anche se l'istruzione SQL logica non fa riferimento alle variabili di sessione. Vedere Garantire risultati cache corretti quando si usa la sicurezza database a livello di riga.

Condizioni di join equivalenti

La tabella logica unita tramite join risultante di una nuova richiesta di query deve essere uguale ai risultati inseriti nella cache, o a un subset di tali risultati, per essere idonea per l'accesso alla cache.

L'attributo DISTINCT deve essere uguale

Se una query inserita nella cache elimina i record duplicati con l'elaborazione DISTINCT (ad esempio, SELECT DISTINCT...), anche le richieste per le colonne inserite nella cache devono includere l'elaborazione DISTINCT; una richiesta per la stessa colonna senza elaborazione DISTINCT è un accesso alla cache non riuscito.

Le query devono contenere livelli di aggregazione compatibili

Le query che richiedono un livello di informazioni aggregato possono utilizzare i risultati inseriti nella cache a un livello di aggregazione inferiore. La query seguente, ad esempio, richiede la quantità venduta a livello di fornitore, area e città:

SELECT supplier, region, city, qtysold
FROM suppliercity

La query seguente richiede la quantità venduta a livello di città:

SELECT city, qtysold
FROM suppliercity

La seconda query ha come risultato l'accesso alla cache sulla prima query.

Aggregazione aggiuntiva limitata

Ad esempio, se una query con la colonna qtysold è inserita nella cache, una richiesta per RANK(qtysold) ha come risultato un accesso alla cache non riuscito. Inoltre, una query che richiede qtysold a livello di paese può ottenere l'accesso alla cache da una query che richiede qtysold a livello di paese e area.

La clausola ORDER BY deve essere costituita da colonne nella lista SELECT

Le query ordinate in base a colonne non contenute nella lista SELECT hanno come risultato un accesso alla cache non riuscito.

Diagnosi del funzionamento degli accessi alla cache

Per valutare meglio il funzionamento degli accessi alla cache, impostare su 4 la variabile di sessione ENABLE_CACHE_DIAGNOSTICS, come mostrato nell'esempio seguente:

ENABLE_CACHE_DIAGNOSTICS=4

Garantire risultati cache corretti quando si usa la sicurezza database a livello di riga

Quando si usa la strategia di sicurezza del database a livello di riga, ad esempio per un database VPD (Virtual Private Database), i risultati dei dati restituiti dipendono dalle credenziali di autorizzazione dell'utente.

Per questo motivo Oracle Analytics Cloud deve sapere se un'origine dati utilizza la sicurezza database a livello di riga e conoscere le variabili pertinenti per la sicurezza.

Per garantire che gli accessi alla cache si verifichino solo per le voci che includono e corrispondono a tutte le variabili sensibili alla sicurezza, è necessario configurare in modo corretto l'oggetto di database e gli oggetti delle variabili di sessione in Model Administration Tool, come riportato di seguito.

  • Oggetto di database. Nel layer Fisico, nella scheda Generale della finestra di dialogo Database, selezionare Virtual Private Database per specificare che l'origine dati utilizza la sicurezza database a livello di riga.

    Se si utilizza la sicurezza database a livello di riga con la funzione di inserimento nella cache condiviso, è necessario selezionare questa opzione per impedire la condivisione delle voci della cache le cui variabili sensibili alla sicurezza non corrispondono.

  • Oggetto variabile di sessione. Per le variabili relative alla sicurezza, nella finestra di dialogo Variabile sessione selezionare Sensibile alla sicurezza per identificare le variabili come sensibili alla sicurezza quando si utilizza la strategia di sicurezza database a livello di riga. Questa opzione garantisce che le voci della cache vengano contrassegnate con le variabili sensibili alla sicurezza, consentendo la corrispondenza delle variabili sensibili alla sicurezza in tutte le query in entrata.

Eseguire una suite di query per popolare la cache

Una delle strategie per accrescere il numero di accesso potenziali alla cache consiste nell'eseguire una suite di query per popolare la cache.

Di seguito vengono forniti alcuni suggerimenti relativi ai tipi di query da utilizzare quando si crea una suite di query con cui popolare la cache.

  • Query precreate comuni. Le query eseguite comunemente, in particolare quelle che richiedono un'elaborazione complessa, sono query di popolamento della cache eccellenti. Un buon esempio di query comuni è costituito dalle query i cui risultati vengono incorporati nei dashboard.

  • Liste SELECT senza espressioni. L'eliminazione delle espressioni nelle colonne della lista SELECT offre maggiori possibilità di accesso alla cache. Una colonna inserita nella cache con un'espressione può rispondere solo a una nuova query che contiene la stessa espressione, mentre una colonna inserita nella cache senza espressioni può rispondere a una richiesta con qualsiasi espressione. Ad esempio, la richiesta inserita nella cache:

    SELECT QUANTITY, REVENUE...

    è in grado di rispondere a una nuova query quale:

    SELECT QUANTITY/REVENUE...

    ma non il contrario.

  • Nessuna clausola WHERE. Se non contiene una clausola WHERE, il risultato inserito nella cache può essere utilizzato per rispondere alle query che soddisfano le regole di accesso alla cache per la lista SELECT con qualsiasi clausola WHERE che include colonne nella lista di proiezione.

In generale, le migliori query di popolamento della cache sono le query che comportano un elevato consumo delle risorse di elaborazione del database e che probabilmente verranno eseguite di nuovo. Fare attenzione a non popolare la cache con query semplici che restituiscono molte righe. Queste query, ad esempio SELECT * FROM PRODUCTS, dove PRODUCTS è mappato direttamente a una singola tabella del database, richiedono un'elaborazione limitata del database. Le loro spese è il sovraccarico della rete e del disco, ovvero fattori che l'inserimento nella cache non è in grado di alleviare.

Quando aggiorna le variabili di modello semantico, Oracle Analytics Cloud esamina i modelli business per determinare se fanno riferimento alle variabili di modello semantico aggiornate. Se è così, Oracle Analytics Cloud rimuoverà tutta la cache per i modelli business esaminati. Vedere Effetto delle modifiche al modello semantico sulla cache delle query.

Utilizzare agenti per popolare la cache delle query

È possibile configurare gli agenti per popolare la cache delle query di Oracle Analytics Cloud.

Il popolamento della cache può migliorare i tempi di risposta per gli utenti che eseguono analisi o visualizzano analisi incorporate nei rispettivi dashboard. È possibile eseguire questa operazione pianificando gli agenti per eseguire richieste che aggiornano questi dati.

  1. In Oracle Analytics Cloud aprire la Home page classica e selezionare Agente (sezione Crea).
  2. Nella scheda Generale selezionare Destinatario per l'opzione Esegui come. Il popolamento personalizzato della cache utilizza la visibilità dei dati di ogni destinatario per personalizzare il contenuto di consegna degli agenti per ogni destinatario.
  3. Nella scheda Pianificazione specificare quando si desidera popolare la cache.
  4. Opzionale: Selezionare Condizione e creare o selezionare una richiesta condizionale. Si supponga ad esempio di disporre di un modello aziendale che determini quando viene completato il processo ETL. In questo caso si potrebbe utilizzare un report basato sul modello aziendale come trigger condizionale per l'avvio del popolamento della cache.
  5. Nella scheda Contenuto di distribuzione selezionare una singola richiesta oppure l'intera pagina dashboard per la quale si desidera popolare la cache. La selezione di una pagina di dashboard può far risparmiare tempo.
  6. Nella scheda Destinatari selezionare i singoli utenti o gruppi destinatari.
  7. Nella scheda Destinazioni cancellare tutte le destinazioni utente e selezionare Oracle Analytics Server Cache.
  8. Salvare l'agente facendo clic sul pulsante Salva nell'angolo superiore destro.

L'unica differenza tra gli agenti di popolamento della cache e gli altri agenti consiste nel fatto che cancellano automaticamente la cache precedente e non vengono visualizzati nel dashboard come avvisi.

Nota:

Gli agenti di popolamento della cache rimuovono solo le query di corrispondenza esatte, pertanto potrebbero ancora esistere dati non più validi. Fare quindi in modo che la strategia di inserimento nella cache includa sempre la rimozione della cache, perché le query agente non gestiscono le query o le espansioni ad hoc.

Usare Model Administration Tool per rimuovere automaticamente la cache per tabelle specifiche

La funzione di rimozione elimina le voci dalla cache delle query e mantiene aggiornato il contenuto. È possibile rimuovere automaticamente le voci della cache per tabelle specifiche impostando il campo Tempo persistenza cache per ogni tabella in Model Administrator Tool.

Nota:

Se si utilizza Semantic Modeler, vedere Descrizione delle proprietà generali di una tabella fisica

Ciò è utile per le origini dati che vengono aggiornate spesso. Se ad esempio si dispone di una tabella in cui sono memorizzati i dati dei ticker azionari che vengono aggiornati ogni minuto, è possibile utilizzare l'impostazione Tempo persistenza cache per rimuovere le voci della tabella a intervalli di 59 secondi. Vedere Cache e tempo di persistenza della cache per le tabelle fisiche specificate.

Cancellare la cache a livello di programmazione

È possibile utilizzare un approccio automatizzato per cancellare (o eliminare) la cache per l'ambiente Oracle Analytics Cloud in base alle esigenze.

Questa sezione contiene gli argomenti riportati di seguito.

Informazioni sulla utility di cancellazione della cache (purgeoaccache)

Oracle Analytics fornisce una utility denominata purgeoaccache.sh che è possibile eseguire per cancellare la cache. Con questa utility, è possibile cancellare la cache in diversi modi. È possibile cancellare l'intera cache oppure cancellare la cache associata a una query, una tabella o un database specifico.

  • Cancellare l'intera cache (SAPurgeAllCache)

    In sapurgecache.txt, chiamare la funzione SAPurgeAllCache per cancellare tutte le voci della cache. Si tratta dello stato predefinito.

    L'istruzione call ha il formato seguente: 
    Call SAPurgeAllCache();

  • Cancellare la cache per una query (SAPurgeCacheByQueryPurge)

    In sapurgecache.txt chiamare la funzione SAPurgeCacheByQueryPurge per cancellare le voci della cache che corrispondono esattamente a una query specifica.

    Si supponga, ad esempio, di disporre della query riportata di seguito in cui una o più voci della cache relative alla query recuperano i nomi di tutti i dipendenti che guadagnano più di $100.000. 
    SELECT lastname, firstname FROM employee WHERE salary > 100000;
    L'istruzione call riportata di seguito cancella le voci della cache associate a questa query. 
    Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );

  • Cancellare la cache per una tabella (SAPurgeCacheByTable)

    In sapurgecache.txt chiamare la funzione SAPurgeCacheByTable per cancellare le voci della cache associate a una specifica tabella fisica di database. La funzione accetta fino a quattro parametri, ognuno dei quali rappresenta i componenti di un nome di tabella fisica completamente qualificato (nome di database, catalogo, schema, tabella).

    Nota:

    Non è possibile utilizzare caratteri jolly nei parametri della funzione. Inoltre, sia il nome del database che il nome della tabella sono parametri obbligatori, pertanto non possono essere nulli.
    Si supponga, ad esempio, di disporre di una tabella con il nome completamente qualificato DBName.CatName.SchName.TabName. L'istruzione call riportata di seguito cancella le voci della cache associate a questa tabella nel livello fisico del modello semantico. 
    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

  • Cancellare la cache per un database (SAPurgeCacheByDatabase)

    In sapurgecache.txt chiamare la funzione SAPurgeCacheByDatabase per cancellare le voci della cache associate a un database fisico specifico. La funzione accetta un parametro che rappresenta il nome del database fisico; il parametro non può essere nullo.

    L'istruzione call ha il formato seguente: 
    Call SAPurgeCacheByDatabase( 'DBName' );

Workflow standard per la cancellazione della cache a livello di programmazione

Di seguito sono riportati i task necessari per cancellare la cache per l'ambiente Oracle Analytics Cloud.

Task Descrizione Ulteriori informazioni

Decidere come si desidera proteggere la connessione JDBC

A seconda dei requisiti di sicurezza, scegliere il tipo di asserzione Proprietario risorsa (scelta consigliata) o Token Web JSON (JWT).

Vedere Scelta di un tipo di asserzione per la connessione JDBC nella Guida Connessione di Oracle Analytics Cloud ai dati.

Registrare l'applicazione BIJDBC

Registrare l'applicazione BIJDBC per autenticare la connessione JDBC.

Per l'asserzione Proprietario risorsa, vedere Registrare l'applicazione BIJDBC utilizzando l'asserzione Proprietario risorsa nella Guida Connessione di Oracle Analytics Cloud ai dati.

Per l'asserzione JWT, nella Guida Connessione di Oracle Analytics Cloud ai dati:

Scaricare e impostare la utility di cancellazione della cache

Scaricare i file BI-JDBC.zip e bi-jdbc-all.jar e impostare la utility.

Scaricare e impostare la utility di cancellazione della cache

Fornire informazioni sulla connessione OAuth

Utilizzare la console OCI per recuperare i dettagli della connessione OAuth necessari per connettersi a Oracle Analytics Cloud e immettere le informazioni in bijbdc.properties.

Aggiungere i dettagli della connessione a bijbdc.properties
Eseguire la utility di cancellazione della cache. Identificare la cache che si desidera cancellare ed eseguire la utility di cancellazione della cache per cancellare la cache specificata. Eseguire la utility di cancellazione della cache (purgeoaccache)
Creare uno script per cancellare periodicamente la cache (facoltativo) Utilizzare un job Cron (o simile) per cancellare la cache in base a una pianificazione con cadenza periodica adatta alla propria organizzazione. Creare uno script per cancellare periodicamente la cache in base a una pianificazione

Scaricare e impostare la utility di cancellazione della cache

Prima di poter utilizzare la utility di cancellazione della cache, è necessario scaricare BI-JDBC.zip ed eseguire alcuni task di impostazione. Ad esempio, sarà necessario recuperare bijdbc-all.jar e impostare la variabile JAVA_HOME.

  1. Scaricare il file BI-JDBC.zip.
  2. Estrarre il file BI-JDBC.zip.
  3. Acquisire familiarità con le cartelle e i file riportati di seguito.
    • \certs: la cartella in cui copiare i file del certificato e della chiave privata necessari per l'autorizzazione JWT OAuth 2.0.
    • \lib: la cartella in cui copiare bijdbc-all.jar. Questo file jar contiene i driver JDBC utilizzati per connettersi a Oracle Analytics Cloud.
    • \props: questa cartella contiene i file di configurazione per la utility di cancellazione della cache.
    • bijbdc.properties: la utility di cancellazione della cache utilizza le informazioni contenute in questo file per connettersi a Oracle Analytics Cloud. Sono disponibili due versioni di questo file. La versione in \rowner contiene i parametri di connessione che è necessario configurare per connettersi come "proprietario risorsa". La versione in \jwt contiene i parametri di connessione che è necessario configurare per connettersi con JWT (JSON Web Token).
    • sapurgecache.txt: la utility di cancellazione della cache utilizza questo file per determinare la cache da cancellare, ovvero tutto il contenuto oppure le voci della cache per una query, una tabella o un database specifico.
    • \src: la cartella che contiene il file purgecache.jar.
    • purgeoaccache.bat e purgeoaccache.sh: la utility da eseguire per cancellare la cache.
  4. Controllare che JAVA_HOME sia impostato correttamente in purgeoaccache (.sh o .bat).
    1. Nella cartella BI-JDBC aprire il file purgeoaccache che si intende utilizzare (.sh per Linux, .bat per Windows).
    2. Controllare che la variabile JAVA_HOME corrisponda alla cartella JDK appropriata nell'ambiente e aggiornarla, se necessario.
  5. Recuperare i driver JDBC necessari per connettersi a Oracle Analytics Cloud (bijdbc-all.jar).
    1. Se non lo si è già fatto, scaricare il driver JDBC. Vedere Scaricare il driver JDBC nella Guida Connessione di Oracle Analytics Cloud ai dati.
    2. Copiare il file bijdbc-all.jar e incollarlo in BI-JDBC/lib.

Aggiungere i dettagli della connessione a bijbdc.properties

Utilizzare la console Oracle Cloud Infrastructure (OCI) per recuperare le informazioni di connessione necessarie per il file bijbdc.properties.

Per completare questo task è necessario disporre dell'autorizzazione per accedere alla console OCI.
  1. Connettersi alla console OCI e passare alla pagina Dettagli aggiuntivi per l'istanza Oracle Analytics Cloud.
    1. Nella console OCI fare clic su Icona del menu di navigazione nell'angolo superiore sinistro.
    2. Fare clic su Analytics & AI. In Analytics fare clic su Analytics Cloud.
    3. Selezionare il compartimento che contiene l'istanza Oracle Analytics Cloud che si sta cercando.
    4. Fare clic sul nome dell'istanza.
    5. Fare clic su Dettagli aggiuntivi.
  2. Recuperare le informazioni di connessione necessarie per il file bijbdc.properties.
    1. Per recuperare oacHostname e idcsEndpointUrl, in Informazioni di rete copiare il valore Nome host e in Provider di identità copiare il valore Striping.
    2. Per recuperare idcsClientId, in Provider di identità fare clic sul collegamento Applicazione per accedere alla configurazione OAuth per l'istanza. Andare alla sezione Informazioni generali e prendere nota dell'ID client.
    3. Per recuperare idcsClientScope, scorrere verso il basso fino alla sezione Configurare le API dell'applicazione che devono essere protette da OAuth e prendere nota del valore Ambito.
    4. Se si utilizza il tipo di asserzione Proprietario risorsa per proteggere la connessione JDBC a Oracle Analytics Cloud, recuperare idcsClientSecret. Andare alla sezione Informazioni generali e prendere nota del valore Segreto client.
    5. Se si utilizza il tipo di asserzione JWT per proteggere la connessione JDBC a Oracle Analytics Cloud, recuperare certificateFile e privateKeyFile, ovvero il nome e la posizione del file .cert e del file .pem utilizzati per creare la configurazione OAuth per l'istanza e copiati nella cartella /certs.

      Nota:

      Se il file .cert e il file .pem non sono stati copiati nella cartella cert, è necessario farlo ora.
  3. Copiare il file bijbdc.properties che si desidera utilizzare e incollarlo nella cartella BI-JDBC/props/ in modo da poterlo personalizzare.
    Il modello Proprietario risorsa si trova nella cartella props/rowner. Il modello JWT si trova nella cartella props/jwt.
  4. Nel file bijbdc.properties aggiungere i dettagli delle connessioni di cui si è preso nota nel passo 2, insieme al nome utente e alla password dell'amministratore.
    Esempio di Proprietario risorsa: 
    ########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>
    Esempio di 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. Salvare e chiudere il file.

Eseguire la utility di cancellazione della cache (purgeoaccache)

Dopo aver completato l'impostazione e configurato il file bijbdc.properties, è possibile eseguire lo script. Per impostazione predefinita, lo script cancellerà l'intera cache. Se si desidera cancellare le voci della cache per una query, una tabella o un database specifico, specificare la funzione e i parametri necessari in sapurgecache.txt.

  1. Facoltativo: nella cartella BI-JDBC/props aprire il file sapurgecache.txt e aggiornare l'istruzione call per specificare le voci della cache che si desidera siano cancellate dallo script. Vedere Informazioni sulla utility di cancellazione della cache (purgeoaccache).
  2. Eseguire la utility di cancellazione della cache (BI-JDBC\purgeoaccache). In Linux, eseguire purgeoaccache.sh. In Windows, eseguire purgeoaccache.bat.
Viene visualizzato un messaggio per indicare che la cancellazione della cache è riuscita.

Creare uno script per cancellare periodicamente la cache in base a una pianificazione

È possibile creare uno script personalizzato, ad esempio un job Cron (o simile), che esegua la cancellazione della cache in base a una pianificazione adatta alla propria organizzazione.

Ad esempio, è possibile eseguire uno script personalizzato ogni giorno alle 23:00 per rimuovere l'intera cache. In questo caso, una voce Cron può essere simile alla seguente: 
$crontab -e
0 23 * * * /bin/bash ~/BI-JDBC/purgeoaccache.sh >> ~/BI-JDBC/temp/purgeoaccache.log 2>&1