Hantera frågecachning

Oracles analysmoln upprätthåller en lokal cache med frågeresultatuppsättningar i frågecachen.

Avsnitt:

Om frågecachen

Frågecachen gör att Oracles analysmoln kan uppfylla många efterföljande frågebegäranden utan att behöva gå till datakällor på serversidan, vilket förbättrar frågeprestandan. Posterna i frågecachen kan dock bli inaktuella i och med att uppdateringar görs av datakällorna på serversidan.

Fördelar med cachning

Det snabbaste sättet att köra en fråga är att hoppa över större delen av bearbetningen och använda ett förberäknat svar.

Vid frågecachning lagrar Oracles analysmoln de förberäknade resultaten av frågor i en lokal cache. Om en annan fråga kan använda dessa resultat elimineras all databasbearbetning för den frågan. Detta kan drastiskt förbättra den genomsnittliga svarstiden för frågor.

Att kunna få svar på frågor från en lokal cache ger, förutom bättre prestanda, besparingar i nätverksresurser och bearbetningstid på databasservern. Besparingen av nätverksresurser beror på att inga mellanresultat returneras till Oracles analysmoln. Att frågan inte körs mot databasen frigör databasservern för andra uppgifter. Att köra färre frågor kan dessutom, om databasen använder ett återdebiteringssystem, kapa kostnader i budgeten.

En annan fördel med att använda cachen för att få resultat för en fråga är besparingar i bearbetningstid från Oracles analysmoln, särskilt om frågeresultaten hämtas från flera databaser. Beroende på hur frågan är utformad kan kopplingar och sortering kräva en hel del bearbetning i servern. Om det redan finns beräkningar för en fråga kan denna bearbetning undvikas, och serverresurser frigöras för andra uppgifter.

Sammanfattningsvis kan frågecachning ge avsevärda förbättringar av frågeprestanda och reducerad nätverkstrafik, databasbearbetning och bearbetningsbelastning.

Kostnader för cachning

Det finns många uppenbara fördelar med frågecachning, men det finns också vissa kostnader.

  • Risken att cachade resultat är inaktuella

  • Administrativa kostnader för hantering av cachen

Med hantering av cachen uppväger fördelarna oftast kostnaderna.

Administrationsuppgifter associerade med cachning

Det finns vissa administrationsuppgifter som är associerade med cachning. Du måste ställa in lämplig beständighetstid för cachen för varje fysisk tabell på, med kännedom om hur ofta data i respektive tabell uppdateras.

Om uppdateringar sker med oregelbundna intervall måste du hålla reda på när ändringar sker och vid behov rensa cachen manuellt.

Hålla cachen uppdaterad

Om cache-posterna inte rensas när data i de underliggande databaserna ändras kan det leda till att frågor returnerar svar som är inaktuella.

Du måste avgöra om detta är godtagbart. Det kan vara så att det är godtagbart att låta cachen innehålla en viss mängd inaktuella data. Du måste bestämma vilka nivåer med inaktuella data som kan godtas, och sedan konfigurera (och följa) en uppsättning regler baserade på dessa nivåer.

Säg till exempel att en applikationen analyserar företagsdata från ett stort konglomerat, och du ska skapa årssammanställningar för de olika divisionerna inom företaget. Frågorna berörs inte i någon i väsentlig grad av nya data eftersom nya data endast berör nästa års sammanställningar. I detta fall kan det vara så att de avvägningar som görs för att bestämma om cachen ska rensas kan ge vid handen att posterna kan lämnas kvar i cachen.

Anta å andra sidan att databaserna uppdateras tre gånger om dagen och du ska köra frågor som gäller aktiviteter under den aktuella dagen. I detta fall måste du rensa cachen mycket oftare, eller kanske överväga att inte använda cachen alls.

Ett annat scenario är att du återskapar en datamängd från början med regelbundna intervall (till exempel en gång i veckan). I detta exempel kan du rensa hela cachen som ett led i processen att återskapa datamängden och på så sätt se till att det aldrig finns inaktuella data i cachen.

Oavsett hur din situation ser ut måste du utvärdera i vilken mån det är godtagbart att inaktuell information returneras till användare.

Cachedelning mellan olika användare

Om delad inloggning är aktiverat för en viss anslutningspool kan cachen delas mellan användare och behöver inte fyllas på för varje användare.

Om delad inloggning inte är aktiverat och användarspecifik databasinloggning används genererar varje användare sin egen cache-post.

Aktivera eller avaktivera frågecachning

I Oracles analysmoln är frågecachen aktiverad som standard. Frågecachning kan aktiveras eller avaktiveras på sidan Systeminställningar.

  1. Klicka på Konsol.
  2. Klicka på Systeminställningar.
  3. Klicka på Performance Analyzer.
  4. Sätt Aktivera cache till på eller av.
    • På – cachelagring av datafrågor är aktiverat.
    • Av – cachelagring av datafrågor är avaktiverat.
  5. Klicka på Använd.
    Vänta en liten stund medan ändringarna förnyas i hela systemet.

Övervaka och hantera cachen

För att hantera ändringarna i de underliggande databaserna och övervaka cache-posterna måste du utveckla en strategi för cachehantering.

Du behöver en process som ogiltigförklarar cache-poster när data i de underliggande tabeller som utgör cache-posten ändras, och en process som övervakar, identifierar och tar bort oönskade cache-poster.

Det här avsnittet innehåller följande delavsnitt:

Välja strategi för cachehantering

Valet av strategi för cachehantering beror på flyktigheten hos data i de underliggande databaserna och förutsägbarheten för de ändringar som orsakar denna flyktighet.

Det beror också på antalet och typen av frågor som utgör cachen, och användningen av dessa frågor. I det här avsnittet ges en översikt över de olika metoderna för cachehantering.

Avaktivera cachelagring för systemet

Cachning kan avaktiveras för hela systemet, vilket stoppar tillägg av nya cache-poster och förhindrar att nya frågor använder den befintliga cachen. Om du avaktiverar cachning kan du aktivera den senare utan att några befintliga poster i cachen går förlorade.

Att tillfälligt avaktivera cachning är en användbar strategi i situationer där du misstänker att det finns inaktuella poster i cachen men vill verifiera att de är inaktuella innan du rensar dessa poster eller rensar hela cachen. Om du kan konstatera att data i cachen fortfarande är relevanta, eller om du har rensat problemposterna, är det säkert att aktivera cachen. Rensa vid behov hela cachen, eller den cache som är associerad med en specifik affärsmodell, innan du aktiverar cachen igen.

Cache och cachebeständighetstid för angivna fysiska tabeller

Du kan ställa in ett cachningsbart attribut för varje fysisk tabell, och ange om frågor mot denna tabell ska läggas till i cachen för att besvara kommande frågor.

Om du aktiverar cachning för en tabell läggs alla frågor som innefattar den tabellen till i cachen. Som standard är alla tabeller cachningsbara, men vissa tabeller kanske inte lämpar sig för att inkluderas i cachen om du inte ställer in lämpliga inställningar för beständighet för cache. Anta till exempel att du har en tabell med aktiekursdata som uppdateras en gång i minuten. Du kan ange att du vill rensa posterna för tabellen var 59 sekund.

Du kan även använda inställningarna för beständighet för cache till att ange hur länge posterna för tabellen ska lagras i frågecachen. Detta är användbart för datakällor som uppdateras ofta.

  1. I modelladministrationsverktyget dubbelklickar du på den fysiska tabellen i det fysiska skiktet.

    Om du använder semantikmodelleraren, se Vilka är de allmänna egenskaperna för en fysisk tabell?.

  2. I dialogrutan för egenskaper för Fysisk tabell, på fliken Allmänt, gör du ett av följande val:

    • Om du vill aktivera cachning markerar du Cachebar.

    • Om du vill förhindra att en tabell cashas avmarkerar du Cachebar.

  3. Om du vill ställa in en beständighetstid för cachen anger du Beständighetstid för cache och anger en måttenhet (dagar, timmar, minuter eller sekunder). Om du inte vill att poster i cachen ska utgå automatiskt markerar du Cache upphör aldrig att gälla.

  4. Klicka på OK.

Hur frågecachen påverkas av ändringar i semantiska modeller

Om du ändrar semantiska modeller med hjälp av semantikmodelleraren eller modelladministrationsverktyget kan ändringarna få konsekvenser för poster som finns lagrade i cachen. Om du till exempel ändrar definitionen av ett fysiskt objekt eller en dynamisk variabel för semantisk modell kan det hända att cacheposter som refererar till detta objekt eller denna variabel inte längre är giltiga. Dessa ändringar kan göra att cachen måste rensas. Det finns två scenarier att beakta: när du ändrar den befintliga semantiska modellen och när du skapar (eller laddar upp) en ny semantisk modell.

Ändringar i den semantiska modellen

Om du ändrar en semantisk modell eller laddar upp en annan .rpd-fil leder alla ändringar du gör som berör cache-poster automatiskt till att alla cache-poster som refererar till de ändrade objekten rensas. Rensningen görs när du laddar upp ändringarna. Om du till exempel tar bort en fysisk tabell från en semantisk modell så rensas alla cache-poster som refererar till den tabellen vid incheckningen. Alla eventuella ändringar som görs i den semantiska modellen i det logiska skiktet rensar bort alla cache-poster från den semantiska modellen.

Ändringar av globala variabler för semantiska modeller

Värdena för globala variabler för semantiska modeller förnyas av data som returneras från frågor. När du definierar en global variabel för semantisk modell skapar du ett initieringsblock eller använder ett befintligt initieringsblock som innehåller en SQL-fråga. Du kan också konfigurera ett schema för att köra frågan och periodiskt förnya variabelns värde.

Om värdet för en global variabel för semantisk modell ändras blir alla cacheposter som använder denna variabel i en kolumn inaktuella, och en ny cachepost genereras nästa gång data i denna post behövs. Den gamla cache-posten tas inte bort omedelbart utan ligger kvar tills den rensas via den vanliga cachningsmetoden.

Strategier för att använda cachen

En av de största fördelarna med frågecachning är att det ger förbättrade upplevda frågeprestanda.

Frågecachning kan vara ett bra sätt att fylla på cachen utanför arbetstid, genom att köra frågor och cacha resultaten. En bra strategi för fördefiniering kräver att du vet när cache-träffar sker.

Om du vill fördefiniera cachen för alla användare kan du fördefiniera cachen med följande fråga:

SELECT User, SRs

Efter fördefiniering av cachen med SELECT User, SRs är följande frågor cache-träffar:

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

Det här avsnittet innehåller följande delavsnitt:

Om cacheträffar

Om cachning är aktiverat utvärderas varje fråga för att fastställa om den kvalificerar för en cache-träff.

En cache-träff innebär att Oracles analysmoln kunde använda cachen för att svara på frågan och inte behövde gå till databasen. Oracles analysmoln kan använda frågecachen för att besvara frågor på samma eller högre aggregeringsnivå.

Det är många faktorer som avgör om en fråga får träff i cachen. I tabellen nedan beskrivs dessa faktorer.

Faktor eller regel Beskrivning

En delmängd av kolumner i listan SELECT måste matcha

För att kvalificera för cache-träff måste alla kolumnerna i listan SELECT för en ny fråga finnas i den cachade frågan, eller kunna beräknas från kolumnerna i frågan.

Den här regeln beskriver minimikravet för att få träff i cachen, men att uppfylla dessa krav är ingen garanti för cache-träff. De andra reglerna i denna tabell gäller även de.

Kolumnerna i listan SELECT kan utgöras av uttryck på kolumnerna i de cachade frågorna

Oracles analysmoln kan beräkna uttryck på cachade resultat för att besvara den nya frågan, men alla kolumnerna måste finnas i det cachade resultatet. Den här frågan, till exempel:

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

får träff i cachen på frågan:

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

eftersom averageprice kan beräknas utifrån dollars och unitsales (averageprice = dollars/unitsales).

WHERE-satsen måste semantiskt vara likadan eller en logisk delmängd

För att frågan ska kvalificeras som en cache-träff måste WHERE-satsens begränsningar antingen vara ekvivalent med de i det cachade resultatet eller en delmängd av det cachade resultatet.

En WHERE-sats som är en logisk delmängd av en cachad fråga kvalificerar för en cache-träff om delmängden motsvarar ett av följande kriterier:

  • En delmängd av värden i listan IN. Frågor som frågar efter färre element än vad som finns i IN-listan för en cachad fråga kvalificerar för cache-träff. Följande fråga, till exempel:

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

    kvalificerar för träff på följande cachade fråga:

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

  • Den innehåller färre (men identiska) OR-begränsningar än det cachade resultatet.

  • Den innehåller en logisk delmängd av en exakt jämförelse. Följande predikat, till exempel:

    WHERE revenue < 1000

    kvalificerar för cache-träff på en jämförbar fråga med predikatet:

    WHERE revenue < 5000

  • Det finns ingen WHERE-sats. Om en fråga utan WHERE-sats cachas måste frågor som uppfyller alla andra regler för cache-träff kvalificeras som cache-träffar oavsett hur deras WHERE-sats ser ut.

Om fler kolumner används i WHERE-satsen måste de finnas i framskrivningslistan. Följande fråga, till exempel:

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

Leder inte till cache-träff för värdeifyllnadsfrågan i den föregående listan eftersom REGION inte finns med i framskrivningslistan.

Frågor med endast dimensioner måste vara exakta matchningar

Om en fråga med endast dimensioner, vilket innebär att inga fakta eller mått finns med i fråga, krävs exakt matchning av den cachade frågans framskrivningskolumner för träff mot cachen. Denna egenskap förhindrar falska positiva resultat om det finns flera logiska källor för en dimensionstabell.

Frågor med specialfunktioner måste vara exakta matchningar

Andra frågor som innehåller specialfunktioner, exempelvis tidsseriefunktioner(AGO, TODATE och PERIODROLLING), begränsnings- och offset-funktioner (OFFSET och FETCH), relationsfunktioner (ISANCESTOR, ISLEAF, ISROOT och ISSIBLING), externa aggregeringsfunktioner, och filtermått i allmänhet måste också vara exakta matchningar mot framskrivningskolumnerna i den cachade frågan. I dess fall måste även filtret matcha exakt. För filtermått kan delmängdscachen användas, om filtermåttet kan skrivas om som en WHERE-sats.

Uppsättningen med logiska tabeller måste matcha

För att kvalificeras som en cache-träff måste alla inkommande frågor ha samma uppsättning logiska tabeller som posten i cachen. Denna regel förhindrar falska cache-träffar. Till exempel är SELECT * FROM product inte en matchning med SELECT * FROM product, sales.

Värden för sessionsvariabler måst matcha, inklusive säkerhetssessionsvariabler

Om den logiska eller fysiska SQL-satsen innehåller en referens till någon sessionsvariabel måste sessionsvariabelns värden matcha. Annars fås ingen träff i cachen.

Dessutom måste värdet för sessionsvariabler som är säkerhetskänsliga matcha de säkerhetsvärden för sessionsvariabler som definierats i den semantiska modellen, även om den logiska SQL-satsen i sig inte refererar till sessionsvariabler. Se Säkerställa korrekta cacheresultat när databassäkerhet på radnivå används.

Ekvivalenta kopplingsvillkor

Den resulterande kopplade logiska tabellen för en ny frågebegäran måste vara densamma som (eller en delmängd av) de cachade resultaten för att kvalificeras som en cache-träff.

DISTINCT-attributet måste vara samma

Om en cachad fråga eliminerar dubbletter av poster genom användning av DISTINCT-uttryck (till exempel SELECT DISTINCT...) måste begäranden för de cachade kolumnerna också innehålla DISTINCT-uttryck. Om en begäran mot samma kolumn saknar DISTINCT-uttrycket fås inte träff mot cachen.

Frågor måste innehålla kompatibla aggregeringsnivåer

Frågor som frågar efter en aggregerad informationsnivå kan använda cachade resultat på en lägre aggregeringsnivå. Följande fråga, till exempel, frågar efter försäljningsvolym på nivåerna leverantör, region och ort:

SELECT supplier, region, city, qtysold
FROM suppliercity

Följande fråga frågar efter försäljningsvolym på nivån ort:

SELECT city, qtysold
FROM suppliercity

Den andra frågan resulterar i en cache-träff mot den första frågan.

Begränsad ytterligare aggregering

Om till exempel en fråga där kolumnen qtysold finns cachad resulterar en fråga om RANK(qtysold) inte i någon cache-träff. Dessutom kan en fråga som begär qtysold på nivån land få en cache-träff från en fråga som begär qtysold på nivån land, region.

Kolumnerna i ORDER BY-satsen måste finnas i select-listan

Frågor som sorterar per kolumner som inte finns i select-listan leder till cache-missar.

Diagnostisera beteendet för cache-träffar

För att kunna bedöma beteendet för cache-träffar bättre sätter du sessionsvariabeln ENABLE_CACHE_DIAGNOSTICS till 4, enligt följande exempel:

ENABLE_CACHE_DIAGNOSTICS=4

Säkerställa korrekta cacheresultat när databassäkerhet på radnivå används

Om du använder en strategi med databassäkerhet på radnivå, exempelvis en virtuell privat databas (VPD), beror de dataresultat som returneras på användarens behörighet.

På grund av detta måste Oracles analysmoln veta om en datakälla använder databassäkerhet på radnivå och vilka variabler som är relevanta för säkerhet.

För att säkerställa att cache-träffar endast sker på cache-poster som inkluderar och matchar alla säkerhetskänsliga variabler måste databasobjekt och sessionsvariabelobjekt konfigureras korrekt i Modelladministrationsverktyget enligt följande:

  • Databasobjekt. I det fysiska skiktet, på fliken Allmänt dialogrutan Databas, väljer du Virtuell privat databas för att ange att datakällan använder databassäkerhet på radnivå.

    Om du använder databassäkerhet på radnivå med delad cachning måste du markera detta alternativ för att förhindra delning av cache-poster vars säkerhetskänsliga variabler inte matchar.

  • Sessionsvariabelobjekt. För säkerhetsrelaterade variabler markerar du Säkerhetskänslig i dialogrutan Sessionsvariabel för att ange att de är känsliga ur säkerhetssynpunkt om en strateg med databassäkerhet på radnivå används. Detta alternativ säkerställer att cache-poster markeras med de säkerhetskänsliga variablerna, och möjliggör matchning av säkerhetskänsliga variabler för alla inkommande frågor.

Köra en serie frågor för att fylla på cachen

En strategi för att maximera potentiella cache-träffar är att köra en serie frågor för att fylla på cachen.

Här följer några rekommendationer för vilka typer av frågor att använda om du ska skapa en serie frågor för att fördefiniera cachen.

  • Förbyggda standardfrågor. Frågor som körs vanligen, särskilt de so har höga bearbetningskostnader, är utmärkta frågor för at fördefiniera en cache. Frågor vilkas resultat är inbäddade i infopaneler är bra exempel på standardfrågor.

  • SELECT-listor utan uttryck. Att utesluta uttryck på SELECT-listkolumner ökar möjligheten till cache-träffar. En cachad kolumn med ett uttryck kan endast ge svar för frågor med samma uttryck; en cachad kolumn utan uttryck kan ge svar för frågor oavsett vad de har för uttryck. Till exempel en cachad begäran som:

    SELECT QUANTITY, REVENUE...

    kan ge svar för en ny fråga, till exempel:

    SELECT QUANTITY/REVENUE...

    men inte omvänt.

  • Ingen WHERE-sats. Om det inte finns någon WHERE-sats i ett cachat resultat kan det användas för att ge svar för frågor som motsvarar reglerna för cache-träffar för select-listan med alla WHERE-satser som inkluderar kolumner i framskrivningslistan.

De bästa frågorna för att fördefiniera en cache är i allmänhet frågor som drar mycket databasbearbetningsresurser och som sannolikt kommer att köras på nytt. Var noga med att inte fördefiniera cachen med enkla frågor som returnerar många rader. För dessa frågor (till exempel SELECT * FROM PRODUCTS där PRODUCTS är mappat direkt till en enda databastabell) krävs mycket lite databasbearbetning. Deras kostnader utgörs av belastning på nätverk och diskar, och för dessa faktorer har cachning ingen inverkan.

När Oracles analysmoln förnyar variabler för semantiska modeller undersöker det affärsmodeller för att fastställa om de refererar till dessa variabler för semantiska modeller. Om så r fallet rensar Oracles analysmoln allt cache-innehåll för dessa affärsmodeller. Se Hur frågecachen påverkas av ändringar i semantiska modeller.

Använda agenter för att fylla på frågecachen

Du kan konfigurera agenter för att fördefiniera frågecachen för Oracles analysmoln.

Att fördefiniera cachen kan förbättra svarstiderna för användare när de kör analyser eller visar analyser som finns inbäddade i deras infopaneler. Du kan uppnå detta genom att schemalägga agenter att köra begäranden som förnyar dessa data.

  1. I Oracles analysmoln öppnar du Klassisk hemsida och väljer Agent (avsnittet Skapa).
  2. På fliken Allmänt väljer du Mottagare för alternativet Kör som. Vid personanpassad fördefiniering av cache används varje mottagares datasynlighet för att anpassa agentens leveransinnehåll för varje mottagare.
  3. På fliken Schema anger du när du vill att cachen ska fördefinieras.
  4. Valfritt: Välj Villkor och skapa eller välj en villkorlig begäran. Du kan till exempel ha en affärsmodell som avgör när ETL-processen är klar. Du kan använda en rapport som baseras på den här affärsmodellen som villkorlig trigger för att fördefinieringen av cachen ska börja.
  5. På fliken Leveransinnehåll väljer du en enskild begäran eller en hel infopanelsida som du vill att cachen ska fördefinieras för. Ann välja en infopanelsida kan spara tid.
  6. På fliken Mottagareväljer du enskilda användare eller grupper för att vara mottagarna.
  7. På fliken Destinationer rensar du alla användardestinationer och väljer Servercache för Oracle Analytics.
  8. Spara agenten genom att välja knappen Spara i det övre höga hörnet.

Den enda skillnaden mellan cache-fördefinieringsagenter och andra agenter är att de rensar den tidigare cachen automatiskt och inte visas på infopanelerna som aviseringar.

Obs!:

Cache-fördefinieringsagenter rensar endast frågor med exakta matchningar, så inaktuella data kan finnas kvar. Se till att cachningsstrategin alltid innefattar rensning av cachen, då agentfrågor inte tar hand om ad hoc-frågor eller borrningar.

Använda modelladministrationsverktyget till att rensa cachen för specifika tabeller automatiskt

Att rensa cachen raderar poster från frågecachen och gör att innehållet hålls aktuellt. Du kan rensa cache-poster för specifika tabeller automatiskt genom att ställa in fältet Beständighetstid för cache för varje tabell i Modelladministrationsverktyg.

Obs!:

Om du använder semantikmodelleraren, se Vilka är de allmänna egenskaperna för en fysisk tabell?

Detta är användbart för datakällor som uppdateras ofta. Om du till exempel har en tabell med aktiekursdata som uppdatera en gång i minuten kan du använda inställningen Beständighetstid för cache för att rensa posterna i denna tabell var 59:e sekund. Se Cache och cachebeständighetstid för angivna fysiska tabeller.

Rensa cache programstyrt

Du kan använda en automatiserad metod för att rensa (eller tömma) cachen för din miljö i Oracles analysmoln efter behov.

Det här avsnittet innehåller följande delavsnitt:

Om verktyget för att rensa cache (purgeoaccache)

Oracle Analytics tillhandahåller ett verktyg som du kan köra för att rensa cache som kallas purgeoaccache.sh. Med det här verktyget kan du rensa cache på olika sätt. Du kan rensa hela cachen eller rensa cache kopplad till en viss fråga, tabell eller databas.

  • Rensa hela cachen (SAPurgeAllCache)

    I sapurgecache.txt anropar du funktionen SAPurgeAllCache för att rensa alla cacheposter. Detta är standardinställningen.

    Anropssatsen ser ut enligt följande: 
    Call SAPurgeAllCache();

  • Rensa cache för en fråga (SAPurgeCacheByQueryPurge)

    I sapurgecache.txt anropar du funktionen SAPurgeCacheByQueryPurge för att rensa cacheposter som matchar en viss fråga exakt.

    Anta till exempel att du har följande fråga där en eller flera frågecacheposter hämtar namnen på alla medarbetare som tjänar mer än SEK 1 000 000: 
    SELECT lastname, firstname FROM employee WHERE salary > 100000;
    Följande anropssats rensar de cacheposter som är associerade med den här frågan: 
    Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );

  • Rensa cache för en tabell (SAPurgeCacheByTable)

    I sapurgecache.txt anropar du funktionen SAPurgeCacheByTable för att rensa cacheposter som är associerade med en viss fysisk databastabell. Funktionen tar upp till fyra parametrar som var och en representerar komponenterna i ett fullt kvalificerat namn på en fysisk tabell (namn på databas, katalog, schema, tabell).

    Obs!:

    Du kan inte använda jokertecken i funktionsparametrarna. Både databasnamnet och tabellnamnet är dessutom obligatoriska parametrar, vilket innebär att de inte kan vara null.
    Anta till exempel att du har en tabell med det fullt kvalificerade namnet DBName.CatName.SchName.TabName. Följande anropssats rensar de cacheposter som är associerade med den här tabellen i det fysiska skiktet i den semantiska modellen: 
    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

  • Rensa cache för en databas (SAPurgeCacheByDatabase)

    I sapurgecache.txt anropar du funktionen SAPurgeCacheByDatabase för att rensa cacheposter som är associerade med en viss fysisk databas. Funktionen tar en parameter som representerar namnet på den fysiska databasen och parametern kan inte vara null.

    Anropssatsen ser ut enligt följande: 
    Call SAPurgeCacheByDatabase( 'DBName' );

Standardarbetsflöde för att rensa cache programstyrt

Här följer uppgifterna för att rensa cachen för din miljö i Oracles analysmoln.

Uppgift Beskrivning Mer information

Bestäm hur du vill skydda JDBC-anslutningen

Beroende på dina säkerhetskrav väljer du Resource Owner (resursägare) (rekommenderas) eller JSON Web Token (JWT) som verifieringstyp.

Mer information finns i Välja en verifieringstyp för JDBC-anslutningen i guiden Ansluta Oracles analysmoln till data.

Registrera BIJDBC-applikationen

Registrera BIJDBC-applikationen för att autentisera JDBC-anslutningen.

För verifieringstypen Resource Owner (resursägare) finns mer information i Registrera BIJDBC-applikationen med verifieringstypen Resource Owner (resursägare) i guiden Ansluta Oracles analysmoln till data.

För verifieringstypen JWT (JSON Web Token) finns mer information i guiden Ansluta Oracles analysmoln till data:

Ladda ned och ställ in verktyget för att rensa cache

Ladda ned BI-JDBC.zip och bi-jdbc-all.jar och ställ in verktyget.

Ladda ned och ställa in verktyget för att rensa cache

Ange OAuth-anslutningsinformation

Använd OCI-konsolen för att hämta de OAuth-anslutningsuppgifter som krävs för att ansluta till Oracles analysmoln och ange informationen i bijbdc.properties.

Lägga till anslutningsuppgifter i bijbdc.properties
Kör verktyget för att rensa cache Identifiera den cache du vill rensa och kör verktyget för att rensa cache för att rensa den angivna cachen. Kör verktyget för att rensa cache (purgeoaccache)
Skapa ett skript för att rensa cachen regelbundet (valfri) Använd ett Cron-jobb (eller liknande) för att rensa cachen efter ett regelbundet schema som passar din organisation. Skapa ett skript för att regelbundet rensa cachen efter ett schema

Ladda ned och ställa in verktyget för att rensa cache

Innan du kan använda verktyget för att rensa cache måste du ladda ned BI-JDBC.zip och utföra inställningsuppgifter. Du behöver till exempel hämta bijdbc-all.jar och ställa in variabeln JAVA_HOME.

  1. Ladda ned filen BI-JDBC.zip.
  2. Zippa upp filen BI-JDBC.zip.
  3. Bekanta dig med följande mappar och filer:
    • \certs: Mappen i vilken du kopierar certifikatet och privata nyckelfiler som krävs för OAuth 2.0-auktorisationen för JSON Web Token.
    • \lib: Mappen i vilken du kopierar bijdbc-all.jar. Det här javaarkivet innehåller drivrutiner för Java Database Connectivity som används för att ansluta till Oracles analysmoln.
    • \props: Den här mappen innehåller konfigurationsfiler för verktyget för att rensa cache.
    • bijdbc.properties: Verktyget för att rensa cache använder information i den här filen för att ansluta till Oracles analysmoln. Det finns två versioner av den här filen. Versionen i \rowner innehåller de anslutningsparametrar du behöver för att konfigurera för att ansluta som "resursägare". Versionen i \jwt innehåller de anslutningsparametrar du behöver för att konfigurera för att ansluta med JWT (JSON Web Token).
    • sapurgecache.txt: Verktyget för att rensa cache använder den här filen för att fastställa vilken cache som ska rensas, det vill säga hela eller cacheposter för en viss fråga, tabell eller databas.
    • \src: Mappen innehåller filen purgecache.jar.
    • purgeoaccache.bat och purgeoaccache.sh: Verktyget som du kör för att rensa cache.
  4. Kontrollera att JAVA_HOME har ställts in korrekt i purgeoaccache (.sh eller .bat).
    1. I mappen BI-JDBC öppnar du filen purgeoaccache som du tänker använda (.sh för Linux, .bat för Windows).
    2. Kontrollera att variabeln JAVA_HOME är rätt mapp för Java Development Kit i din miljö och uppdatera vid behov.
  5. Hämta drivrutinerna för Java Database Connectivity som behövs för att ansluta till Oracles analysmoln (bijdbc-all.jar ).
    1. Ladda ned drivrutinen för Java Database Connectivity om du inte redan har gjort det. Se Ladda ned JDBC-drivrutinen i guiden Ansluta Oracles analysmoln till data.
    2. Kopiera filen bijdbc-all.jar och klistra in den i BI-JDBC/lib.

Lägga till anslutningsuppgifter i bijbdc.properties

Använd konsolen för Oracles molninfrastruktur (OCI) för att hämta den anslutningsinformation som krävs för filen bijdbc.properties.

För att slutföra den här uppgiften måste du ha behörighet för att få åtkomst till OCI-konsolen.
  1. Logga in på OCI-konsolen och gå till sidan Ytterligare uppgifter för din instans av Oracles analysmoln.
    1. I OCI-konsolen klickar du på Ikonen Navigeringsmeny högst upp till vänster.
    2. Klicka på Analys och AI. Under Analys klickar du på Analysmoln.
    3. Välj det delområde som innehåller den instans av Oracles analysmoln som du letar efter.
    4. Klicka på namnet på instansen.
    5. Klicka på Ytterligare uppgifter.
  2. Hämta den anslutningsinformation som krävs för filen bijdbc.properties.
    1. För att hämta oacHostname och idcsEndpointUrl, under Nätverksinformation kopierar du värdet Värdnamn och under Identitetsintygare kopierar du värdet Strimla.
    2. För att hämta idcsClientId, under Identitetsintygare klickar du på länken App för att få åtkomst till OAuth-konfigurationen för din instans. Gå till sektionen Allmän information och registrera klient-id:t.
    3. För att hämta idcsClientScope bläddrar du ned till de API:er för Konfigurera applikation som behöver vara en OAuth-skyddad sektion och registrera värdet Omfattning.
    4. Om du använder verifieringstypen Resource Owner (resursägare) för att skydda Java Database Connectivity-anslutningen till Oracles analysmoln hämtar du idcsClientSecret. Gå till sektionen Allmän information och registrera klienthemligheten.
    5. Om du använder verifieringstypen JWT (JSON Web Token) för att skydda Java Database Connectivity-anslutningen till Oracles analysmoln hämtar du certificateFile och privateKeyFile, det vill säga namnet och platsen för filen .cert och filen .pem som du använde för att skapa OAuth-konfigurationen för din instans och kopierade till mappen /certs.

      Obs!:

      Om du inte har kopierat filen .cert och filen .pem till mappen cert måste du göra det nu.
  3. Kopiera filen bijdbc.properties som du vill använda och klistra in den i mappen BI-JDBC/props/ så att du kan anpassa den.
    Mallen Resource Owner (resursägare) ligger i mappen props/rowner. Mallen JWT (JSON Web Token) ligger i mappen props/jwt.
  4. Lägg till de anslutningsuppgifter som du registrerade i steg 2, tillsammans med ditt användarnamn och lösenord som administratör till filen bijdbc.properties.
    Exempel på Resource Owner (resursägare): 
    ########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>
    Exempel på JWT (JSON Web Token): 
    ########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. Spara och stäng filen.

Kör verktyget för att rensa cache (purgeoaccache)

När du har slutfört inställningen och konfigurationen av filen bijdbc.properties kan du köra skriptet. Skriptet rensar hela cachen som standard. Om du vill rensa cacheposter för en viss fråga, tabell eller databas anger du den begärda funktionen och parametrarna i sapurgecache.txt.

  1. Valfri: I mappen BI-JDBC/props öppnar du filen sapurgecache.txt och uppdaterar anropssatsen för att ange vilka cacheposter du vill att skriptet ska rensa. Se Om verktyget för att rensa cache (purgeoaccache).
  2. Kör verktyget för att rensa cache (BI-JDBC\purgeoaccache). I Linux kör du purgeoaccache.sh. I Windows kör du purgeoaccache.bat.
Ett meddelande visas och anger att cache har rensats.

Skapa ett skript för att regelbundet rensa cachen efter ett schema

Du kan skapa ett anpassat skript, till exempel ett Cron-jobb (eller liknande), som rensar cache efter ett schema som passar din organisation.

Du kan till exempel köra ett anpassat skript kl. 23:00 varje dag för att tömma hela cachen. I det här fallet kan en Cron-post se ut så här: 
$crontab -e
0 23 * * * /bin/bash ~/BI-JDBC/purgeoaccache.sh >> ~/BI-JDBC/temp/purgeoaccache.log 2>&1