Håndtere forespørgsels-caching

Oracle Analytics Cloud vedligeholder en lokal cache af forespørgselsresultatsæt i forespørgselscachen.

Emner:

Om forespørgselscachen

Med forespørgselscachen kan Oracle Analytics Cloud opfylde mange efterfølgende forespørgselsanmodninger uden at oprette adgang til backend-datakilder, hvilket forbedrer forespørgslers ydeevne. Men posterne i forespørgselscachen kan blive forældede, når der foretages opdateringer af backend-datakilderne.

Fordele ved caching

Det er hurtigst at behandle en forespørgsel ved at springe det meste af databehandlingen over og bruge et forudberegnet svar.

Med forespørgsels-caching gemmer Oracle Analytics Cloud de forudberegnede resultater af forespørgsler i en lokal cache. Hvis en anden forespørgsel kan bruge disse resultater, elimineres al databasebehandling for denne forespørgsel. Det kan medføre markante forbedringer i den gennemsnitlige responstid for forespørgsler.

Ud over en forbedring af ydeevnen betyder muligheden for at besvare en forespørgsel fra en lokal cache, at der bruges færre netværksressourcer og mindre behandlingstid på databaseserveren. Der spares netværksressourcer, fordi mellemliggende resultater ikke returneres til Oracle Analytics Cloud. Når du ikke kører forespørgslen på databasen, frigøres databaseserveren til andet arbejde. Hvis databasen bruger et debetoverførselssystem, betyder kørsel af færre forespørgsler også færre omkostninger.

En anden fordel ved at bruge cachen til at besvare en forespørgsel er kortere behandlingstid på Oracle Analytics Cloud, især hvis forespørgselsresultaterne hentes fra flere databaser. Afhængigt af forespørgslen kan der foregå en betragtelig sammenkædnings- og sorteringsbehandling på serveren. Hvis forespørgslen allerede er beregnet, undgås denne behandling, så serverressourcer frigøres til andre opgaver.

Sammenfattende kan man sige, at forespørgsels-caching forbedrer ydeevnen markant og reducerer netværkstrafik, databasebehandling og behandlingsspild.

Omkostninger ved caching

Forespørgsels-caching har mange indlysende fordele, men også visse omkostninger.

  • Risiko for, at cachede resultater bliver forældede

  • Administrative omkostninger ved styring af cachen

Med cachestyring er fordelene typisk større end omkostningerne.

Administrative opgaver, der er knyttet til caching

Der er knyttet nogle administrative opgaver til caching. Du skal angive persistenstiden for cache til hver enkelt fysisk tabel korrekt, så du ved, hvor ofte data i tabellen opdateres.

Når opdateringsfrekvensen varierer, skal du have styr på, hvornår ændringer forekommer, og manuelt fjerne cacheposterne permanent efter behov.

Holde cachen opdateret

Hvis cacheposterne ikke fjernes permanent, når dataene i de underliggende databaser ændres, kan forespørgsler potentielt returnere forældede resultater.

Du skal vurdere, om dette er acceptabelt. Det kan være acceptabelt at tillade cachen at indeholde nogle forældede data. Du skal bestemme, hvilket niveau af forældede data der er acceptabelt, og derefter konfigurere (og følge) et sæt regler, der afspejler disse niveauer.

Lad os for eksempel antage, at en applikation analyserer firmadata fra en større koncern, og du foretager årlige opsummeringer af de forskellige divisioner i firmaet. Nye data påvirker ikke forespørgslerne direkte, fordi de nye data kun påvirker næste års opsummeringer. I dette tilfælde vil overvejelser omkring permanent fjernelse af cacheposterne muligvis ende med, at posterne forbliver i cachen.

Men lad os antage, at databaserne opdateres tre gange dagligt, og du udfører forespørgsler på dagens aktiviteter. I så fald skal du fjerne cacheposterne permanent meget oftere eller måske overveje helt at undlade at bruge cachen.

I et andet scenarie genopbygger du datasættet i begyndelsen af de periodiske intervaller (for eksempel én gang om ugen). I dette eksempel kan du fjerne alle cacheposterne permanent som en del af processen til genopbygning af datasættet, så du er sikker på aldrig at have forældede data i cachen.

Uanset din situation skal du vurdere, hvad der er acceptabelt for uaktuelle oplysninger, der returneres til brugerne.

Cachedeling på tværs af brugere

Hvis delt logon er aktiveret for en bestemt forbindelsespulje, kan cachen deles på tværs af brugere og skal ikke udfyldes for hver bruger.

Hvis delt logon ikke er aktiveret, og der benyttes en brugerspecifik databaselogon, genererer hver bruger sin egen cachepost.

Aktivere eller deaktivere forespørgsels-caching

I Oracle Analytics Cloud er forespørgselscachen aktiveret som standard. Du kan aktivere eller deaktivere forespørgsels-caching på siden Systemindstillinger.

  1. Klik på Konsol.
  2. Klik på Systemindstillinger.
  3. Klik på Valg for ydeevne og kompatibilitet.
  4. Slå cacheaktivering til eller fra i Cacheaktivering.
    • Til – dataforespørgsels-caching er aktiveret.
    • Fra – caching er deaktiveret.
  5. Klik på Anvend.
    Vent et øjeblik, mens ændringerne opfriskes i hele systemet.

Overvåge og håndtere cachen

Hvis du vil håndtere ændringerne i de underliggende databaser og overvåge cacheposter, skal du udvikle en cachestyringsstrategi.

Du skal have en proces, der ugyldiggør cacheposter, når dataene i de underliggende tabeller, som opretter cacheposter, ændres, og en proces, der overvåger, identificerer og fjerner eventuelle uønskede cacheposter.

Afsnittet indeholder følgende emner:

Vælge en strategi for cachestyring

Valget af strategi for cachestyring afhænger af dataenes flygtighed i de underliggende databaser og forudsigeligheden af de ændringer, som skaber denne flygtighed.

Den afhænger også af det antal forespørgselstyper, der omfatter din cache, og den brug, som disse forespørgsler modtager. Dette afsnit viser en oversigt over de forskellige tilgange til cachestyring.

Deaktivere caching for systemet

Du kan deaktivere caching for hele systemet for at stoppe alle nye cacheposter og forhindre eventuelle nye forespørgsler i at bruge den eksisterende cache. Hvis du deaktiverer caching, kan du aktivere det senere uden at miste poster, der er gemt i cachen.

Midlertidig deaktivering af caching er en nyttig strategi i situationer, hvor der muligvis er forældede cacheposter, men du ønsker at verificere, at de rent faktisk er forældede, før du fjerner disse poster eller alle cacheposterne permanent. Hvis du mener, at de gemte data i cachen stadig er relevante, eller hvis du har fjernet problemposter permanent på en sikker måde, kan du trygt aktivere cachen. Fjern om nødvendigt alle cacheposterne permanent eller de cacheposter, der er tilknyttet en bestemt forretningsmodel, før du aktiverer cachen igen.

Cache og cachepersistenstid for angivne fysiske tabeller

Du kan angive en cacheattribut for hver fysiske tabel, så du kan angive, om forespørgsler for tabellen skal tilføjes i cachen for at kunne besvare fremtidige forespørgsler.

Hvis du aktiverer caching for en tabel, føjes enhver forespørgsel, som involverer tabellen, til cachen. Alle tabeller kan som standard caches, men nogle tabeller er måske ikke så egnede til at blive inkluderet i cachen, medmindre du konfigurerer egnede indstillinger for cachepersistens. Lad os for eksempel antage, at du har en tabel, som lagrer børsnoteringsdata, der opdateres hvert minut. Du kan angive, at du vil fjerne posterne for den pågældende tabel permanent hvert 59. sekund.

Du kan også bruge indstillinger for cachepersistens til at angive, hvor længe posterne til denne tabel skal gemmes i forespørgselscachen. Det er praktisk for datakilder, der opdateres ofte.

  1. Dobbeltklik på den fysiske tabel i det fysiske lag i Model Administration Tool.

    Hvis du bruger Semantic Modeler, skal du se Hvad er de generelle egenskaber for en fysisk tabel?.

  2. Foretag et af følgende valg på fanen Generelt i dialogboksen med egenskaber for Fysisk tabel:

    • Vælg Kan caches for at aktivere caching.

    • Fravælg Kan caches for at forhindre en tabel i at blive cachet.

  3. Angiv en persistenstid for cachen i Persistenstid for cache for at angive udløbstiden for cachen, og angiv en måleenhed (dage, timer, minutter eller sekunder). Hvis cacheposter ikke skal udløbe automatisk, skal du vælge Cache udløber aldrig.

  4. Klik på OK.

Sådan påvirker ændringer af semantiske modeller forespørgselscachen

Når du modificerer semantiske modeller ved hjælp af Semantic Modeler eller Model Administration Tool, kan ændringerne påvirke poster, der er lagret i cachen. Hvis du for eksempel ændrer definitionen af et fysisk objekt eller en dynamisk semantisk model, er cacheposter, der refererer til objektet eller variablen, måske ikke gyldige længere. Disse ændringer kan medføre et behov for at fjerne cacheposterne permanent. Du skal være opmærksom på to scenarier: Når du modificerer din eksisterende semantiske model, og når du opretter (eller uploader) en ny semantisk model.

Ændringer af den semantiske model

Når du modificerer en semantisk model eller uploader en anden .rpd-fil, vil eventuelle ændringer, som påvirker cacheposter, automatisk medføre en permanent fjernelse af alle cacheposter, der refererer til de ændrede objekter. Den permanente fjernelse udføres, når du uploader ændringerne. Hvis du for eksempel sletter en fysisk tabel i en semantisk model, fjernes alle cacheposter, der refererer til tabellen, permanent ved indtjekning. Alle ændringer, der foretages i en semantisk model i det logiske lag, fjerner alle cacheindgange for den pågældende semantiske model permanent.

Ændringer af globale variabler for semantiske modeller

Værdierne for globale variabler for semantiske modeller opfriskes af data, der returneres fra forespørgsler. Når du definerer en global variabel for en semantisk model, opretter du en initialiseringsblok eller bruger en eksisterende, som indeholder en SQL-forespørgsel. Du konfigurerer også en tidsplan for at køre forespørgslen og jævnligt opfriske variablens værdi.

Hvis værdien for en global variabel for en semantisk model ændres, bliver enhver cachepost, der bruger denne variabel i en kolonne, forældet, og der genereres en ny cachepost, når data i posten skal bruges igen. Den gamle cachepost fjernes ikke straks, men bevares, indtil den fjernes gennem den sædvanlige caching-mekanisme.

Strategier for brug af cachen

En af hovedfordelene ved forespørgsels-caching er en forbedring af forespørgslers umiddelbare ydeevne.

Forespørgsels-caching kan være nyttig til at udfylde cachen uden for normal kontortid ved at køre forespørgsler og caching af deres resultater. En god udfyldningsstrategi kræver, at du ved, hvornår cachehits forekommer.

Hvis du vil udfylde cachen for alle brugere, kan du udfylde cachen med følgende forespørgsel:

SELECT User, SRs

Efter udfyldning af cachen med SELECT User, SRs er følgende forespørgsler cachehits:

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (og brugeren var USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (og brugeren var USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (og brugeren var USER3)

Afsnittet indeholder følgende emner:

Om cachehits

Når caching er aktiveret, evalueres hver forespørgsel for at bestemme, om den er kvalificeret som cachehit.

Et cachehit betyder, at Oracle Analytics Cloud kunne bruge cachen til at besvare forespørgslen uden på noget tidspunkt at gå til databasen. Oracle Analytics Cloud kan bruge forespørgselscachen til at besvare forespørgsler på det samme eller et højere niveau af aggregering.

Mange faktorer bestemmer, om der er cachehit. Disse faktorer er beskrevet i tabellen nedenfor.

Faktor eller regel Beskrivelse

Et undersæt af kolonner på listen SELECT skal matche

Alle kolonnerne på SELECT-listen for en ny forespørgsel skal findes i den cachede forespørgsel for at være kvalificeret som cachehit, eller de skal kunne beregnes ud fra kolonnerne i forespørgslen.

Denne regel beskriver minimumkravet til et cachehit, men opfyldelsen af denne regel er ikke garanti for et cachehit. De andre regler i denne tabel gælder også.

Kolonnerne på SELECT-listen kan sammensættes af udtryk i kolonnerne for de cachede forespørgsler

Oracle Analytics Cloud kan beregne udtryk på cachede resultater for at besvare den nye forespørgsel, men alle kolonnerne skal være i det cachede resultat. For eksempel har forespørgslen:

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

cachehit på forespørgslen:

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

fordi averageprice kan beregnes ud fra dollars og unitsales (averageprice = dollars/unitsales).

WHERE-klausulen skal være semantisk den samme eller et logisk undersæt

Hvis forespørgslen skal være kvalificeret som cachehit, skal WHERE-klausulens begrænsninger enten svare til de cachede resultater eller være et undersæt af de cachede resultater.

En WHERE-klausul, der er et logisk undersæt af en cachet forespørgsel, er kvalificeret som cachehit, hvis undersættet opfylder et af følgende kriterier:

  • Et undersæt af IN-listeværdier. Forespørgsler, der anmoder om færre elementer af en IN-listes cachede forespørgsel, er kvalificeret som cachehit. For eksempel er forespørgslen:

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

    kvalificeret som et hit på følgende cachede forespørgsel:

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

  • Den indeholder færre (men identiske) OR-begrænsninger end det cachede resultat.

  • Den indeholder et logisk undersæt af en litteral sammenligning. For eksempel er prædikatet:

    WHERE revenue < 1000

    kvalificeret som et cachehit på en sammenligningsforespørgsel med prædikatet:

    WHERE revenue < 5000

  • Der er ingen WHERE-klausul. Hvis en forespørgsel uden WHERE-klausul caches, er forespørgsler, som opfylder alle andre regler for cachehit, kvalificeret som cachehits uanset deres WHERE-klausul.

Desuden skal kolonner, der bruges på WHERE-klausulen, være på projektionslisten. Følgende forespørgsel:

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

resulterer for eksempel ikke i et cachehit for udfyldningsforespørgslen på den foregående liste, fordi REGION ikke findes på projektionslisten.

Rene dimensionsforespørgsler skal være et nøjagtigt match

Hvis en forespørgsel kun er til en dimension, så ingen fakta eller målinger er inkluderet i forespørgslen, vil kun et nøjagtigt match i projektionskolonnerne på den cachede forespørgsel være et cachehit. Denne funktionsmåde forhindrer falske positivresultater, når der er flere logiske kilder til en dimensionstabel.

Forespørgsler med specialfunktioner skal være et nøjagtigt match

Andre forespørgsler, der indeholder specialfunktioner, for eksempel tidsseriefunktioner (AGO, TODATE og PERIODROLLING), grænse- og forskydningsfunktioner (OFFSET og FETCH), relationsfunktioner (ISANCESTOR, ISLEAF, ISROOT og ISSIBLING), eksterne aggregeringsfunktioner og generelle filtermetrikker, skal også være et nøjagtigt match med projektionskolonnerne i den cachede forespørgsel. I disse tilfælde skal filteret også være et nøjagtigt match. For filtermetrikker, der kan omskrives som en WHERE-klausul, kan undersætcachen udnyttes.

Sæt af logiske tabeller skal matche

For være kvalificeret som cachehit skal alle indgående forespørgsler have det samme sæt logiske tabeller som cacheposten. Denne regel forhindrer falske cachehits. For eksempel matcher SELECT * FROM product ikke SELECT * FROM product, sales.

Sessionsvariabelværdier skal matche, herunder sikkerhedssessionsvariabler

Hvis den logiske SQL-sætning eller fysiske SQL-sætning refererer til en sessionsvariabel, skal sessionsvariabelværdierne matche. I modsat fald er der ikke tale om et cachehit.

Desuden skal værdien for sikkerhedsfølsomme sessionsvariabler matche de værdier for sikkerhedssessionsvariabler, som er defineret i den semantiske model, selvom selve den logiske SQL-sætning ikke refererer til sessionsvariabler. Se Sikre korrekte cacheresultater ved brug af databasesikkerhed på rækkeniveau.

Tilsvarende sammenkædningsbetingelser

Den resulterende sammenkædede logiske tabel for en ny forespørgselsanmodning skal være den samme som (eller et undersæt af) de cachede resultater for at være kvalificeret som cachehit.

DISTINCT-attributten skal være den samme

Hvis en cachet forespørgsel eliminerer dublerede records med DISTINCT-behandling (for eksempel SELECT DISTINCT...), skal anmodninger om de cachede kolonner også inkludere DISTINCT-behandling. En anmodning om den samme kolonne uden DISTINCT-behandling er ikke et cachehit.

Forespørgsler skal indeholde kompatible aggregeringsniveauer

Forespørgsler, der anmoder om et aggregeret niveau af oplysninger, kan bruge cachede resultater på et lavere aggregeringsniveau. For eksempel anmoder følgende forespørgsel om salgstallet på leverandør-, regions- og byniveau:

SELECT supplier, region, city, qtysold
FROM suppliercity

Følgende forespørgsel anmoder om salgstallet på byniveau:

SELECT city, qtysold
FROM suppliercity

Den anden forespørgsel resulterer i et cachehit på den første forespørgsel.

Begrænset yderligere aggregering

Hvis for eksempel en forespørgsel med kolonnen qtysold caches, resulterer en anmodning om RANK(qtysold) ikke i et cachehit. Desuden kan en forespørgsel, der anmoder om qtysold på landeniveau, få et cachehit fra en forespørgsel, der anmoder om qtysold på lande- og regionsniveau.

ORDER BY-klausulen skal bestå af kolonner på valglisten

Forespørgsler, der sorterer efter kolonner, som ikke findes på valglisten, resulterer ikke i cachehit.

Diagnosticere funktionsmåde for cachehit

Du kan bedre vurdere funktionsmåden for cachehits ved at angive sessionsvariablen ENABLE_CACHE_DIAGNOSTICS til 4, som vist i følgende eksempel:

ENABLE_CACHE_DIAGNOSTICS=4

Sikre korrekte cacheresultater ved brug af databasesikkerhed på rækkeniveau

Hvis du bruger en strategi for databasesikkerhed på rækkeniveau, for eksempel Virtuel privat database (VPD), afhænger de returnerede dataresultater af brugerens autorisationsoplysninger.

Derfor skal Oracle Analytics Cloud vide, om en datakilde bruger databasesikkerhed på rækkeniveau, og hvilke variabler der er relevante for sikkerheden.

Hvis du vil sikre, at cachehits kun forekommer på cacheposter, som indeholder og matcher alle sikkerhedsfølsomme variabler, skal du konfigurere databaseobjektet og sessionsvariablernes objekter korrekt i Model Administration Tool på følgende måde:

  • Databaseobjekt. Vælg Virtuel privat database på fanen Generelt i dialogboksen Database i det fysiske lag for at angive, at datakilden bruger databasesikkerhed på rækkeniveau.

    Hvis du bruger databasesikkerhed på rækkeniveau sammen med delt caching, skal du angive dette valg for at forhindre deling af cacheposter, hvis sikkerhedsfølsomme variabler ikke matcher.

  • Sessionsvariabelobjekt. I forbindelse med sikkerhedsrelaterede variabler skal du vælge Sikkerhedsfølsom i dialogboksen Sessionsvariabel for at identificere dem som sikkerhedsfølsomme, når der bruges en strategi for databasesikkerhed på rækkeniveau. Dette valg sikrer, at cacheposter mærkes med sikkerhedsfølsomme variabler, så der foretages matchning af sikkerhedsfølsomme variabler på alle indgående forespørgsler.

Køre en suite af forespørgsler for at udfylde cachen

Hvis du vil maksimere potentielle cachehits, er én strategi at køre en suite af forespørgsler for at udfylde cachen.

Følgende er nogle anbefalinger af forespørgselstyper, der kan bruges til at oprette en suite af forespørgsler, som cachen skal udfyldes med.

  • Almindelige foruddefinerede forespørgsler. Forespørgsler, der typisk køres, især dem, som er dyre at behandle, er fremragende forespørgsler til cacheudfyldning. Forespørgsler, hvis resultater er integreret i instrumentbrætter, er gode eksempler på almindelige forespørgsler.

  • SELECT-lister uden udtryk. Eliminering af udtryk i SELECT-listekolonner øger muligheden for cachehits. En cachet kolonne med et udtryk kan kun besvare en ny forespørgsel med det samme udtryk, mens en cachet kolonne uden udtryk kan besvare en anmodning for den pågældende kolonne med ethvert udtryk. For eksempel kan en cachet anmodning som denne:

    SELECT QUANTITY, REVENUE...

    besvare en ny forespørgsel som denne:

    SELECT QUANTITY/REVENUE...

    men ikke omvendt.

  • Ingen WHERE-klausul. Hvis der ikke er nogen WHERE-klausul i et cachet resultat, kan det bruges til at besvare forespørgsler, der opfylder reglerne for cachehit på valglisten med enhver WHERE-klausul, der indeholder kolonner på projektionslisten.

Generelt er de bedste forespørgsler til udfyldning af cache de forespørgsler, som forbruger store mængder ressourcer til databasebehandling, og som formentlig bliver udstedt igen. Undgå at udfylde cachen med simple forespørgsler, der returnerer mange rækker. Disse forespørgsler (for eksempel SELECT * FROM PRODUCTS, hvor PRODUCTS mapper direkte til en enkelt databasetabel) kræver meget lidt databasebehandling. Omkostningen er netværks- og diskspild, hvilket er faktorer, som caching ikke afhjælper.

Når Oracle Analytics Cloud opfrisker variabler for semantiske modeller, undersøges forretningsmodeller for at bestemme, om de refererer til disse variabler for semantiske modeller. Hvis det er tilfældet, fjerner Oracle Analytics Cloud alle cacheposterne permanent for disse forretningsmodeller. Se Sådan påvirker ændringer af semantiske modeller forespørgselscachen.

Bruge agenter til at udfylde forespørgselscachen

Du kan konfigurere agenter til at udfylde Oracle Analytics Cloud-forespørgselscachen.

Udfyldning af cachen kan forbedre responstider for brugere, når de kører analyser eller ser på analyser, som er integreret i deres instrumentbrætter. Du kan opnå dette ved at planlægge agenter til kørsel af anmodninger, som opfrisker disse data.

  1. Åbn den klassiske startside i Oracle Analytics Cloud, og vælg Agent (afsnittet Opret).
  2. Vælg Modtager for valget Kør som på fanen Generelt. Personligt tilpasset cacheudfyldning bruger datasynligheden for hver modtager til at tilpasse agentleveringsindhold for hver enkelt modtager.
  3. Angiv, hvornår cachen skal udfyldes, på fanen Planlæg.
  4. Valgfrit: Vælg Betingelse, og opret eller vælg en betinget anmodning. Du kan for eksempel have en forretningsmodel, der bestemmer, hvornår ETL-processen er fuldført. Du kan bruge en rapport, der er baseret på denne forretningsmodel, som den betingede trigger for, at cacheudfyldningen begynder.
  5. Brug fanen Leveringsindhold til at vælge en individuel anmodning eller en hel instrumentbrætside, som du vil udfylde cachen for. Du kan spare tid, hvis du vælger en instrumentbrætside.
  6. Brug fanen Modtagere til at vælge individuelle brugere eller grupper, som skal være modtagere.
  7. Ryd alle brugerdestinationer på fanen Destinationer, og vælg Oracle Analytics Server-cache.
  8. Gem agenten ved at vælge knappen Gem i øverste højre hjørne.

Den eneste forskel mellem cacheudfyldningsagenter og andre agenter er, at de automatisk rydder den tidligere cache og ikke vises på instrumentbrættet som varslinger.

Bemærk:

Cacheudfyldningsagenter fjerner kun forespørgsler med nøjagtigt match permanent, så der kan stadig være forældede data. Sørg for, at caching-strategien altid inkluderer permanent fjernelse af cacheposterne, da agentforespørgsler ikke er rettet mod ad-hoc-forespørgsler eller boringer.

Bruge Model Administration Tool til automatisk at fjerne cacheposter permanent for specifikke tabeller

Permanent fjernelse af cacheposterne sletter poster i forespørgselscachen, så indholdet opfriskes. Du kan automatisk fjerne cacheposter permanent for specifikke tabeller ved at udfylde feltet Persistenstid for cache for hver tabel i Model Administration Tool.

Bemærk:

Hvis du bruger Semantic Modeler, skal du se Hvad er de generelle egenskaber for en fysisk tabel?

Det er praktisk for datakilder, der opdateres ofte. Hvis du for eksempel har en tabel, der indeholder børsnoteringsdata, som opdateres hvert minut, kan du bruge indstillingen Persistenstid for cache til at fjerne posterne for tabellen permanent hvert 59. sekund. Se Cache og cachepersistenstid for angivne fysiske tabeller.

Rydde cachen via programmering

Du kan bruge en automatiseret tilgang til rydning (eller permanent fjernelse) af cachen for dit Oracle Analytics Cloud-miljø efter behov.

Afsnittet indeholder følgende emner:

Om hjælpeprogrammet til rydning af cache (purgeoaccache)

Oracle Analytics indeholder et hjælpeprogram, som du kan køre for at rydde cachen, purgeoaccache.sh. Med dette hjælpeprogram kan du rydde cachen på forskellige måder. Du kan rydde hele cachen eller rydde den cache, der er knyttet til en specifik forespørgsel, tabel eller database.

  • Ryd hele cachen (SAPurgeAllCache)

    Kald funktionen SAPurgeAllCache i sapurgecache.txt for at rydde alle cacheposter. Dette er standard.

    Call-sætningen ser ud på følgende måde: 
    Call SAPurgeAllCache();

  • Ryd cache for en forespørgsel (SAPurgeCacheByQueryPurge)

    Kald funktionen SAPurgeCacheByQueryPurge i sapurgecache.txt for at rydde cacheposter, der matcher en specifik forespørgsel nøjagtigt.

    Lad os for eksempel antage, at du har følgende forespørgsel, hvor en eller flere poster i forespørgselscachen henter navnene på alle medarbejdere, der tjener mere end $100.000: 
    SELECT lastname, firstname FROM employee WHERE salary > 100000;
    Følgende call-sætning rydder de cacheposter, der er knyttet til denne forespørgsel: 
    Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );

  • Ryd cache for en tabel (SAPurgeCacheByTable)

    Kald funktionen SAPurgeCacheByTable i sapurgecache.txt for at rydde cacheposter, der er knyttet til en specifik fysisk databasetabel. Funktionen tager op til fire parametre, der hver repræsenterer komponenterne i et fuldt kvalificeret navn på en fysisk tabel (database-, katalog-, skema-, tabelnavn).

    Bemærk:

    Du kan ikke bruge jokertegn i funktionsparametrene. Derudover er både databasenavnet og tabelnavnet obligatoriske parametre, hvilket vil sige, at de ikke kan være NULL.
    Lad os for eksempel antage, at du har en tabel med det fuldt kvalificerede navn DBName.CatName.SchName.TabName. Følgende call-sætning rydder de cacheposter, der er knyttet til denne tabel i den semantiske models fysiske lag: 
    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

  • Ryd cache for en database (SAPurgeCacheByDatabase)

    Kald funktionen SAPurgeCacheByDatabase i sapurgecache.txt for at rydde cacheposter, der er knyttet til en specifik fysisk database. Funktionen tager én parameter, der repræsenterer navnet på den fysiske database, og parameteren kan ikke være NULL.

    Call-sætningen ser ud på følgende måde: 
    Call SAPurgeCacheByDatabase( 'DBName' );

Typisk workflow for rydning af cachen via programmering

Her er opgaverne til rydning af cachen for dit Oracle Analytics Cloud-miljø.

Opgave Beskrivelse Flere oplysninger

Bestemme, hvordan du vil sikre din JDBC-forbindelse

Afhængigt af dine sikkerhedskrav skal du vælge Ressourceejer (anbefalet) eller JSON Web Tokens (JWT) som assertionstype.

Se Vælge en assertionstype til din JDBC-forbindelse i vejledningen Oprettelse af forbindelse mellem Oracle Analytics Cloud og dine data.

Registrere BIJDBC-applikationen

Registrer BIJDBC-applikationen for at autentificere din JDBC-forbindelse.

Se Registrere BIJDBC-applikationen ved hjælp af Ressourceejer-assertion i vejledningen Oprettelse af forbindelse mellem Oracle Analytics Cloud og dine data for at få oplysninger om Ressourceejer-assertion.

Se vejledningen Oprettelse af forbindelse mellem Oracle Analytics Cloud og dine data for at få oplysninger om JWT-assertion:

Downloade og konfigurere hjælpeprogrammet til rydning af cache

Download BI-JDBC.zip og bi-jdbc-all.jar, og konfigurer hjælpeprogrammet.

Downloade og konfigurere hjælpeprogrammet til rydning af cache

Angive oplysninger om OAuth-forbindelse

Brug OCI-konsollen til at hente de OAuth-forbindelsesdetaljer, der kræves for at oprette forbindelse til Oracle Analytics Cloud, og indtast oplysningerne i bijdbc.properties.

Føje forbindelsesdetaljer til bijdbc.properties
Køre hjælpeprogrammet til rydning af cache Identificer den cache, som du vil rydde, og kør hjælpeprogrammet til rydning af cache for at rydde den angivne cache. Køre hjælpeprogrammet til rydning af cache (purgeoaccache)
Oprette et script til regelmæssig rydning af cachen (valgfrit) Brug et cron-job (eller lignende) til at rydde cachen efter en regelmæssig tidsplan, der passer til din organisation. Oprette et script til regelmæssig rydning af cachen efter en tidsplan

Downloade og konfigurere hjælpeprogrammet til rydning af cache

Før du kan bruge hjælpeprogrammet til rydning af cache, skal du downloade BI-JDBC.zip og udføre nogle opsætningsopgaver. Du skal for eksempel hente bijdbc-all.jar og angive variablen JAVA_HOME.

  1. Download filen BI-JDBC.zip.
  2. Pak filen BI-JDBC.zip ud.
  3. Gør dig fortrolig med følgende mapper og filer:
    • \certs: Den mappe, som du skal kopiere det certifikat og de privatnøglefiler til, der kræves til JWT OAuth 2.0-autorisering.
    • \lib: Den mappe, som du skal kopiere bijdbc-all.jar til. Denne jar-fil indeholder de JDBC-drivere, der bruges til at oprette forbindelse til Oracle Analytics Cloud.
    • \props: Denne mappe indeholder konfigurationsfiler til hjælpeprogrammet til rydning af cache.
    • bijdbc.properties: Hjælpeprogrammet til rydning af cache bruger oplysninger i denne fil til at oprette forbindelse til Oracle Analytics Cloud. Der er to versioner af denne fil. Versionen i \rowner indeholder de forbindelsesparametre, som du skal bruge til at konfigurere for at oprette forbindelse som "ressourceejer". Versionen i \jwt indeholder de forbindelsesparametre, som du skal bruge til at konfigurere for at oprette forbindelse som JWR (JSON Web Token).
    • sapurgecache.txt: Hjælpeprogrammet til rydning af cache bruger denne fil til at bestemme, hvilken cache der skal ryddes. Det vil sige alting eller cacheposter for en specifik forespørgsel, tabel eller database.
    • \src: Den mappe, der indeholder filen purgecache.jar.
    • purgeoaccache.bat og purgeoaccache.sh: Det hjælpeprogram, som du bruger til rydning af cachen.
  4. Tjek, at JAVA_HOME er sat korrekt i purgeoaccache (.sh eller .bat).
    1. Åbn, den purgeoaccache-fil, som du planlægger at bruge (.sh til Linux, .bat til Windows), i mappen BI-JDBC.
    2. Tjek, at variablen JAVA_HOME er den relevante JDK-mappe i dit miljø, og opdater om nødvendigt.
  5. Hent de JDBC-drivere, der er påkrævet for at oprette forbindelse til Oracle Analytics Cloud (bijdbc-all.jar ).
    1. Download JDBC-driveren, hvis du ikke allerede har gjort det. Se Downloade JDBC-driveren i vejledningen Oprettelse af forbindelse mellem Oracle Analytics Cloud og dine data.
    2. Kopier filen bijdbc-all.jar, og indsæt den i BI-JDBC/lib.

Føje forbindelsesdetaljer til bijdbc.properties

Brug Oracle Cloud Infrastructure (OCI) Console til at hente de forbindelsesoplysninger, der kræves til filen bijdbc.properties.

Du skal have adgang til OCI-konsollen for at fuldføre denne opgave.
  1. Log på OCI-konsollen, og naviger til siden Yderligere detaljer for din Oracle Analytics Cloud-instans.
    1. Klik på Ikonet Navigationsmenu øverst til venstre i OCI-konsollen.
    2. Klik på Analytics & AI. Klik på Analytics Cloud under Analytics.
    3. Vælg de rum, der indeholder den Oracle Analytics Cloud-instans, som du søger efter.
    4. Klik på instansens navn.
    5. Klik på Yderligere detaljer.
  2. Hent de forbindelsesoplysninger, der kræves til filen bijdbc.properties.
    1. Hent oacHostname og idcsEndpointUrl ved at kopiere værdien for værtsnavn under Netværksoplysninger og kopiere stripe-værdien under Identitetsudbyder.
    2. Hent idcsClientId ved at klikke på applinket under Identitetsudbyder for at få adgang til OAuth-konfigurationen for din instans. Gå til sektionen Generelle oplysninger, og registrer klient-id'en.
    3. Hent idcsClientScope ved at rulle ned til sektionen Konfigurer applikations-API'er, der skal beskyttes af OAuth, og registrere værdien for Omfang.
    4. Hent idcsClientSecret, hvis du bruger typen Ressourceejer-assertion til at sikre JDBC-forbindelsen til Oracle Analytics Cloud. Gå til sektionen Generelle oplysninger, og registrer klienthemmeligheden.
    5. Hvis du bruger typen JWT-assertion til at sikre JDBC-forbindelsen til Oracle Analytics Cloud, skal du hente certificateFile og privateKeyFile, hvilket vil sige navnet på og lokationen for .cert-filen og .pem-filen, som du brugte til at oprette OAuth-konfigurationen for din instans og kopierede til mappen /certs.

      Bemærk:

      Hvis du ikke har kopieret .cert-filen og .pem-filen til mappen certs, skal du gøre det nu.
  3. Kopier den bijdbc.properties-fil, som du vil bruge, og indsæt den i mappen BI-JDBC/props/, så du kan tilpasse den.
    Ressourceejerskabelonen findes i mappen props/rowner. JWT-skabelonen findes i mappen props/jwt.
  4. Føj de forbindelsesdetaljer, som du registrerede i trin 2, samt dit administratorbrugernavn og din adgangskode, til filen bijdbc.properties file.
    Ressourceejereksempel: 
    ########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>
    JWT-eksempel: 
    ########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. Gem og luk filen.

Køre hjælpeprogrammet til rydning af cache (purgeoaccache)

Når du har fuldført opsætningen og konfigureret filen bijdbc.properties, er du klar til at køre scriptet. Scriptet vil som standard rydde hele cachen. Hvis du vil rydde cacheposter for en bestemt forespørgsel, tabel eller database, skal du angive den påkrævede funktion og de påkrævede parametre i sapurgecache.txt.

  1. Valgfrit: Åbn filen sapurgecache.txt i mappen BI-JDBC/props, og opdater call-sætningen for at angive, hvilke cacheposter scriptet skal rydde. Se Om hjælpeprogrammet til rydning af cache (purgeoaccache).
  2. Kør hjælpeprogrammet til rydning af cache (BI-JDBC\purgeoaccache). Kør purgeoaccache.sh på Linux. Kør purgeoaccache.bat på Windows.
Der vises en meddelelse om, at cachen er ryddet.

Oprette et script til regelmæssig rydning af cachen efter en tidsplan

Du kan oprette et tilpasset script såsom et cron-job (eller lignende), der rydder cachen efter en tidsplan, der passer til din organisation.

Du kan for eksempel køre et tilpasset script kl. 23:00 hver dag for at fjerne hele cachen permanent. I dette tilfælde kan en cron-indtastning se ud på følgende måde: 
$crontab -e
0 23 * * * /bin/bash ~/BI-JDBC/purgeoaccache.sh >> ~/BI-JDBC/temp/purgeoaccache.log 2>&1