Administrere hurtigbufring av spørringer

Oracle Analytics Cloud vedlikeholder en lokal hurtigbuffer med spørringsresultatsett i spørringshurtigbufferen.

Emner:

Om spørringshurtigbufferen

Spørringshurtigbufferen gjør at Oracle Analytics Cloud oppfyller mange påfølgende spørringsforespørsler uten å ha tilgang til bakre datakilder, noe som øker spørringsytelsen. Oppføringene i spørringshurtigbufferen kan imidlertid bli gamle når de bakre datakildene oppdateres.

Fordeler med hurtigbufring

Den raskeste måten å behandle en spørring på, er å hoppe over det meste av behandlingen og bruke et forhåndsbehandlet svar.

Med en spørringshurtigbuffer lagrer Oracle Analytics Cloud forhåndsbehandlede resultater av spørringer i en lokal hurtigbuffer. Hvis en annen spørring kan bruke disse resultatene, elimineres all databasebehandling for denne spørringen. Det kan føre til dramatiske forbedringer i gjennomsnittlig svartid for spørringen.

I tillegg til å forbedre ytelsen, kan evnen til å besvare en spørring fra en lokal hurtigbuffer spare nettverksressurser og behandlingstid på databasetjeneren. Nettverksressurser spares fordi mellomliggende resultater ikke returneres til Oracle Analytics Cloud. Hvis spørringen ikke kjøres i databasen, frigis databasetjeneren til å gjøre annet arbeid. Hvis databasen bruker et tilbakebelastningssystem, kan kjøring av færre spørringer kutte kostnader i budsjettet.

En annen fordel med å bruke hurtigbufferen til å besvare en spørring, er kortere behandlingstid i Oracle Analytics Cloud, spesielt hvis spørringsresultatene ikke hentes fra flere databaser. Avhengig av spørringen kan det foregå betydelig sammenføynings- og sorteringsbehandling på tjeneren. Hvis spørringen allerede er beregnet, unngås denne behandlingen, og ressurser frigjøres til andre oppgaver.

Hurtigbufring av spørringer kan kort sagt gi en betydelig forbedring i spørringsytelsen og redusere nettverkstrafikken, databasebehandlingen og tilleggskostnadene ved behandling.

Kostnader ved hurtigbufring

Spørringshurtigbufring har mange klare fordeler, men også en del kostnader.

Hurtigbufrede resultater kan bli gamle
Administrative kostnader for administrasjon av hurtigbufferen

Fordelene med hurtigbufferstyring er vanligvis større enn kostnadene.

Administrative oppgaver knyttet til hurtigbufring

Enkelte administrative oppgaver er knyttet til hurtigbufring. Du må angi vedvarenhetstiden for hurtigbufferen for hver enkelt fysisk tabell i henhold til hvor ofte dataene i tabellen oppdateres.

Når hyppigheten for oppdateringen varierer, må du holde oversikt over når endringene skjer, og rydde hurtigbufferen manuelt når det er nødvendig.

Holde hurtigbufferen oppdatert

Hvis hurtigbufferoppføringene ikke ryddes når dataene i de underliggende databasene endres, kan spørringer returnere utdaterte resultater.

Du må evaluere om dette er akseptabelt. Det kan være akseptabelt å la hurtigbufferen inneholde noen gamle data. Du må bestemme hvilket nivå av gamle data som er akseptabelt, og deretter konfigurere (og følge) et sett med regler som gjenspeiler disse nivåene.

Tenk deg for eksempel at en applikasjon analyserer bedriftsdata fra et stort konglomerat, og du lager årlige sammendrag for de ulike avdelingene i selskapet. Nye data påvirker ikke spørringen materielt fordi de nye dataene bare påvirker neste års sammendrag. I dette tilfellet kan kompromissene for å bestemme om hurtigbufferen skal ryddes, være at oppføringene blir værende i hurtigbufferen.

Tenk deg imidlertid at databasene oppdateres tre ganger daglig, og du utfører spørringer på dagens aktiviteter. I dette tilfellet må du rydde hurtigbufferen mye oftere, eller kanskje vurdere om du ikke skal bruke hurtigbufferen i det hele tatt.

Et annet scenario er at du bygger datasettet på nytt fra begynnelsen med periodiske intervaller (for eksempel én gang per uke). I dette eksemplet kan du rydde hele hurtigbufferen som en del av prosessen med å bygge datasettet på nytt, og sikre at du aldri har gamle data i hurtigbufferen.

Uansett hvilken situasjon du er i, må du evaluere hva som er akseptabelt for ikke-gjeldende opplysninger som returneres til brukerne.

Hurtigbufferdeling på tvers av brukere

Hvis delt pålogging er aktivert for en bestemt tilkoblingsreserve, er det mulig å dele hurtigbufferen på tvers av brukere, og det er ikke nødvendig å seede for hver enkelt bruker.

Hvis delt pålogging ikke er aktivert og en brukerspesifikk databasepålogging brukes, genererer hver enkelt bruker sin egen hurtigbufferoppføring.

Aktivere eller deaktivere hurtigbufring av spørringer

Spørringshurtigbufferen aktiveres som standard i Oracle Analytics Cloud. Du kan aktivere og deaktivere spørringshurtigbufring på siden Systeminnstillinger.

Klikk på Konsoll.
Klikk på Systeminnstillinger.
Klikk på Ytelse og kompatibilitet.
Slå Aktiver hurtigbuffer på eller av.
- På - aktivering av dataspørring er aktivert.
- Av - hurtigbufring er deaktivert
Klikk på Bruk.
Vent litt til endringene oppfriskes gjennom hele systemet.

Overvåke og administrere hurtigbufferen

Når du skal administrere endringene i de underliggende databasene og overvåke hurtigbufferoppføringer, må du utvikle en strategi for administrasjon av hurtigbufferen.

Du trenger en prosess som gjør hurtigbufferoppføringer ugyldige ved endring av dataene i de underliggende tabellene som utgjør endringene i hurtigbufferoppføringene, og en prosess som overvåker, identifiserer og fjerner alle uønskede hurtigbufferoppføringer.

Denne delen inneholder emnene nedenfor.

Velge en strategi for hurtigbufferstyring

Valget av en strategi for hurtigbufferstyring avhenger av hvor ustabile dataene i de underliggende databasene er, og forutsigbarheten i endringene som forårsaker denne ustabiliteten.

Det avhenger også av hvor mange og hvilke typer spørringer som utgjør hurtigbufferen, og bruken disse spørringene mottar. Denne delen inneholder en oversikt over de ulike tilnærmingene til administrasjon av hurtigbufferen.

Deaktivere hurtigbufring for systemet

Du kan deaktivere hurtigbufring for hele systemet hvis du vil stoppe alle nye hurtigbufferoppføringer og hindre alle nye spørringer i å bruke den eksisterende hurtigbufferen. Hvis du deaktiverer hurtigbufring, kan du aktivere det senere uten å miste noen oppføringer som er lagret i hurtigbufferen.

Midlertidig deaktivering av hurtigbufring er en nyttig strategi i situasjoner der du kanskje mistenker at du har gamle oppføringer, men du vil bekrefte at de virkelig er gamle før du rydder disse oppføringene eller hele hurtigbufferen. Hvis du finner ut at dataene som er lagret i hurtigbufferen, fremdeles er relevante, eller når du har ryddet problemoppføringer på en sikker måte, kan du trygt aktivere hurtigbufferen. Hvis det er nødvendig, rydder du hele hurtigbufferen eller hurtigbufferen som er knyttet til en bestemt forretningsmodell, før du aktiverer hurtigbufferen på nytt.

Hurtigbuffer og vedvarenhetstid for hurtigbufre for angitte fysiske tabeller

Du kan definere et attributt som kan hurtigbufres, for hver enkelt fysiske tabell. Det gjør at du kan angi om spørringer for denne tabellen legges til i hurtigbufferen slik at de kan besvare fremtidige spørringer.

Hvis du aktiverer hurtigbufring for en tabell, legges alle spørringer som involverer tabellene, til i hurtigbufferen. Alle tabeller kan som standard hurtigbufres, men enkelte tabeller er kanskje ikke gode kandidater for inkludering i hurtigbufferen, med mindre du konfigurerer egnede vedvarenhetsinnstillinger for hurtigbuffer. Tenk deg for eksempel at du har en tabell som lagrer aksjemarkørdata som oppdateres hvert minutt. Du kan angi at du vil rydde oppføringer for denne tabellen hvert 59. sekund.

Du kan også bruke vedvarenhetsinnstillingene for hurtigbuffer til å angi hvor lenge oppføringene for denne tabellen lagres i spørringshurtigbufferen. Dette er nyttig for datakilder som oppdateres ofte.

Dobbeltklikk på den fysiske tabellen i Fysisk lag i modelladministrasjonsverktøyet.

Hvis du bruker semantisk modellerer, kan du se Hva er generelle egenskaper for en fysisk tabell?.
Velg ett av følgende i fanen Generelt i dialogboksen for egenskaper for Fysisk tabell:
- Hvis du vil aktivere hurtigbufring, merker du av for Kan hurtigbufres.
- Hvis du vil hindre at en tabell hurtigbufres, fjerner du merket for Kan hurtigbufres.
Hvis du vil definere en utløpstid for hurtigbufferen, angir du en verdi i Vedvarenhetstid for hurtigbuffer og angir en måleenhet (dager, timer, minutter eller sekunder). Hvis du ikke vil at hurtigbufferoppføringer skal utløpe automatisk, merker du av for Hurtigbuffer utløper aldri.
Klikk på OK.

Hvordan endringer i semantiske modeller påvirker spørringshurtigbufferen

Når du endrer semantiske modeller ved hjelp av semantisk modellerer eller modelladministrasjonsverktøyet, kan endringene ha innvirkning på oppføringer som er lagret i hurtigbufferen. Hvis du for eksempel endrer definisjonen av et fysisk objekt eller en dynamisk variabel for en semantisk modell, kan det hende at hurtigbufferoppføringer som refererer til dette objektet eller denne variabelen, ikke lenger er gyldige. Disse endringene kan føre til et behov for å rydde hurtigbufferen. Det finnes to scenarioer du må være oppmerksom på når du endrer den eksisterende semantiske modellen, og når du oppretter (eller laster opp) en ny semantisk modell.

Endringer i den semantiske modellen

Når du endrer en semantisk modell eller laster opp en annen RPD-fil, fører alle endringer som påvirker hurtigbufferoppføringer, automatisk til en rydding av alle hurtigbufferoppføringer som refererer til de endrede objektene. Ryddingen skjer når du laster opp endringene. Hvis du for eksempel sletter en fysisk tabell fra en semantisk modell, ryddes alle hurtigbufferoppføringer som henviser til denne tabellen, ved pålogging. Alle endringer som gjøres i en semantisk modell i det logiske laget, rydder alle hurtigbufferoppføringer for denne semantiske modellen.

Endringer i globale variabler for semantiske modeller

Verdiene for globale variabler for semantiske modeller oppfriskes av data som returneres fra spørringer. Når du definerer en global variabel for en semantisk modell, oppretter du en initialiseringsblokk eller bruker en som allerede finnes, og som inneholder en SQL-spørring. Du kan også konfigurere en tidsplan for kjøring av spørringen og periodisk oppfriske verdien for variabelen.

Hvis verdien for en global variabel for en semantisk modell blir endret, blir alle hurtigbufferoppføringer som bruker denne variabelen i en kolonne, foreldet. Det genereres en ny hurtigbufferoppføring når det blir behov for dataene i denne oppføringen på nytt. Den gamle hurtigbufferoppføringen fjernes ikke umiddelbart, men blir liggende til den fjernes via den vanlige hurtigbufringsmekanismen.

Strategier for bruk av hurtigbufferen

Én av de viktigste fordelene med spørringshurtigbufring er at det forbedrer spørringsytelsen.

Spørringshurtigbufring kan være verdifullt ved seeding av hurtigbufferen i rolige perioder ved å kjøre spørringer og hurtigbufre resultatene. En god seedingstrategi krever at du vet når hurtigbuffertreff forekommer.

Hvis du vil seede hurtigbufferen for alle brukerne, kan du seede hurtigbufferen med følgende spørring:

SELECT User, SRs

Når du har seedet hurtigbufferen ved hjelp av SELECT User, SRs, er følgende spørringer hurtigbuffertreff:

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

Denne delen inneholder emnene nedenfor.

Om hurtigbuffertreff

Når hurtigbufring er aktivert, evalueres hver enkelt spørring for å fastsette om den kvalifiserer for et hurtigbuffertreff.

Et hurtigbuffertreff betyr at Oracle Analytics Cloud kunne bruke hurtigbufferen til å besvare spørringen og ikke gikk til databasen i det hele tatt. Oracle Analytics Cloud kan bruke spørringshurtigbufferen til å besvare spørringer på samme eller et høyere aggregeringsnivå.

Mange faktorer bestemmer om det er treff i hurtigbufferen. Tabellen nedenfor beskriver disse faktorene.

Faktor eller regel	Beskrivelse
Et delsett av kolonner i `SELECT`-listen må samsvare	Alle kolonnene i `SELECT`-listen for en ny spørring må finnes i den hurtigbufrede spørringen hvis den skal være kvalifisert for et hurtigbuffertreff, eller det må være mulig å beregne dem fra kolonnene i spørringen. Denne regelen beskriver minstekravet for treff i hurtigbufferen, men et hurtigbuffertreff er ikke garantert selv om denne regelen følges. De andre reglene i denne tabellen gjelder også.
Kolonner i `SELECT`-listen kan bestå av uttrykk i kolonnene i de hurtigbufrede spørringene.	Oracle Analytics Cloud kan beregne uttrykk fra hurtigbufrede resultater og besvare den nye spørringen, men alle kolonnene må finnes i det hurtigbufrede resultatet. Spørringen vil for eksempel: SELECT product, month, averageprice FROM sales WHERE year = 2000 gi hurtigbuffertreff i spørringen: SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 fordi `averageprice` kan beregnes fra `dollars` og `unitsales` (`averageprice = dollars/unitsales`).
`WHERE`-leddet må være semantisk likt eller et logisk delsett	Hvis spørringen skal kvalifisere som et hurtigbuffertreff, må `WHERE`-leddskranker være lik de hurtigbufrede resultatene eller et delsett av de hurtigbufrede resultatene. Et `WHERE`-ledd som er et logisk delsett av en hurtigbufret spørring, kvalifiserer for et hurtigbuffertreff hvis delsettet oppfyller ett av følgende kriterier: Et delsett av verdier i en `IN`-liste. Spørringer som ber om færre elementer i en hurtigbufret spørring med en `IN`-liste, kvalifiserer for et hurtigbuffertreff. Følgende spørring vil for eksempel: SELECT employeename, region FROM employee, geography WHERE region in ('EAST', 'WEST') kvalifisere som et treff i følgende hurtigbufrede spørring: SELECT employeename, region FROM employee, geography WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST') Den inneholder færre (men identiske) `OR`-skranker enn det hurtigbufrede resultatet. Den inneholder et logisk delsett av en konstant sammenligning. Følgende predikat er for eksempel: WHERE revenue < 1000 kvalifisert som et hurtigbuffertreff i en sammenlignbar spørring med predikatet: WHERE revenue < 5000 Det finnes ikke noen `WHERE`-ledd. Hvis en spørring uten `WHERE`-ledd hurtigbufres, er spørringer som oppfyller alle andre regler for hurtigbuffertreff, kvalifisert som hurtigbuffertreff uansett om de inneholder noe `WHERE`-ledd. I tillegg må kolonner som brukes i `WHERE`-leddet, finnes i projiseringslisten. Følgende spørring vil for eksempel: SELECT employeename FROM employee, geography WHERE region in ('EAST', 'WEST') Fører ikke til et hurtigbuffertreff for seedingspørringen i forrige liste, fordi REGION ikke finnes i projiseringslisten.
Spørringer som bare er for dimensjoner, må være et nøyaktig samsvar	Hvis en spørring bare er for dimensjoner, noe som betyr at det ikke er inkludert noe faktum eller noen måling i spørringen, gir bare et nøyaktig samsvar i projiseringskolonnene i den hurtigbufrede spørringen et hurtigbuffertreff. Denne virkemåten hindrer falske positive svar når det finnes flere logiske kilder for en dimensjonstabell.
Spørringer med spesialfunksjoner må være et nøyaktig samsvar	Andre spørringer som inneholder spesialfunksjoner, for eksempel tidsseriefunksjoner (`AGO`, `TODATE` og `PERIODROLLING`), grense- og forskyvningsfunksjoner (`OFFSET` og `FETCH`), relasjonsfunksjoner (`ISANCESTOR`, `ISLEAF`, `ISROOT` og `ISSIBLING`), eksterne aggregeringsfunksjoner og generelle filtermålinger, må også være et nøyaktig samsvar med projiseringskolonnene i den hurtigbufrede spørringen. I disse tilfellene må filteret også være et nøyaktig samsvar. Hvis en filtermåling kan skrives om som et `WHERE`-ledd, kan delsettet av hurtigbufferen utnyttes.
Sett med logiske tabeller må samsvare	Hvis innkommende spørringer skal kvalifisere som et hurtigbuffertreff, må alle ha samme sett med logiske tabeller som hurtigbufferoppføringen. Denne regelen unngår falske hurtigbuffertreff. `SELECT * FROM product` samsvarer for eksempel ikke med `SELECT * FROM product, sales`.
Øktvariabelverdier må samsvare, inkludert sikkerhetsøktvariabler	Hvis logiske SQL-setninger eller fysiske SQL-setninger refererer til en hvilken som helst øktvariabel, må øktvariabelverdiene samsvare. Hvis ikke, oppstår det ikke noe hurtigbuffertreff. I tillegg må verdien for øktvariabler som er sikkerhetssensitive, samsvare med verdiene for sikkerhetsøktvariabler som er definert i den semantiske modellen, selv om logisk SQL-setningen ikke refererer til øktvariabler. Se Sikre riktige hurtigbufferresultater ved bruk av databasesikkerhet på radnivå.
Ekvivalente sammenføyningsbetingelser	Den resulterende sammenføyde logiske tabellen i en ny spørringsforespørsel må være den samme som (eller et delsett av) de hurtigbufrede resultatene hvis de skal kvalifisere for et hurtigbuffertreff.
Attributtet `DISTINCT` må være det samme	Hvis en hurtigbufret spørring eliminerer dupliserte oppføringer med `DISTINCT`-behandling (for eksempel `SELECT DISTINCT` ...), må forespørsler for de hurtigbufrede kolonnene også inkludere `DISTINCT`-behandling. En forespørsel om samme kolonne uten `DISTINCT`-behandling er en hurtigbufferbom.
Spørringer må inneholde kompatible aggregeringsnivåer	Spørringer som ber om et aggregert nivå av opplysninger, kan bruke hurtigbufrede resultater på et lavere aggregeringsnivå. Følgende spørring ber for eksempel om mengden som er solgt på leverandør-, region- og poststednivå: SELECT supplier, region, city, qtysold FROM suppliercity Følgende spørring ber om mengden som er solgt på poststedsnivå: SELECT city, qtysold FROM suppliercity Den andre spørringen fører til et hurtigbuffertreff i den første spørringen.
Begrenset tilleggsaggregering	Hvis en spørring med kolonnen `qtysold` for eksempel hurtigbufres, fører en forespørsel om `RANK(qtysold)` til en hurtigbufferbom. I tillegg kan en spørring som ber om `qtysold` på poststedsnivå, få et hurtigbuffertreff fra en spørring som ber om `qtysold` på land- eller regionsnivå.
`ORDER BY`-leddet må bestå av kolonner i SELECT-listen	Spørringer som er sortert etter kolonner som ikke finnes i SELECT-listen, fører til hurtigbufferbommer.
Diagnostisere virkemåte for hurtigbuffertreff	Hvis du vil vurdere virkemåten ved hurtigbuffertreff på en bedre måte, kan du sette øktvariabelen ENABLE_CACHE_DIAGNOSTICS til 4, som vist i følgende eksempel: ENABLE_CACHE_DIAGNOSTICS=4

Sikre riktige hurtigbufferresultater ved bruk av databasesikkerhet på radnivå

Når du bruker en databasesikkerhetsstrategi på radnivå, for eksempel en virtuell privat database (VPD), er de returnerte dataresultatene avhengige av brukerens påloggingsautorisasjon.

Oracle Analytics Cloud må derfor vite om en datakilde bruker databasesikkerhet på radnivå, og hvilke variabler som er relevante for sikkerheten.

For å sikre at hurtigbuffertreff bare forekommer i hurtigbufferoppføringer som inkluderer og samsvarer med alle sikkerhetssensitive variabler, må du konfigurere databaseobjektet og øktvariabelobjektene på riktig måte i modelladministrasjonsverktøyet, på følgende måte:

Databaseobjekt. I det fysiske laget velger du Virtuell privat database i fanen Generelt i dialogboksen Database hvis du vil angi at datakilden bruker databasesikkerhet på radnivå.

Hvis du bruker databasesikkerhet på radnivå med delt hurtigbufring, må du angi dette valget for å hindre deling av hurtigbufferoppføringer som har sikkerhetssensitive variabler som ikke samsvarer.
Objektet Øktvariabel. For sikkerhetsrelaterte variabler velger du Sikkerhetssensitiv i dialogboksen Øktvariabel hvis du vil identifisere dem som sensitive for sikkerhet når en databasesikkerhetsstrategi på radnivå brukes. Dette valget sikrer at hurtigbufferoppføringer merkes med de sikkerhetssensitive variablene, noe som aktiverer samsvarende sikkerhetssensitive variabler i alle innkommende spørringer.

Kjøre en samling av spørringer som fyller ut hurtigbufferen

Hvis du vil maksimere potensielle hurtigbuffertreff, er én strategi å fylle ut hurtigbufferen ved å kjøre en samling av spørringer.

Nedenfor finner du noen anbefalinger for typene spørringer du kan bruke når du oppretter en samling av spørringer som hurtigbufferen skal seedes med.

Vanlige forhåndbygde spørringer. Spørringer som kjøres ofte, spesielt spørringer som er dyre å behandle, passer utmerket til hurtigbufferseeding. Spørringer med resultater som er innebygd i instrumentpaneler, er gode eksempler på vanlige spørringer.
SELECT-lister uten uttrykk. Eliminering av uttrykk i kolonnene i SELECT-listen utvider muligheten for hurtigbuffertreff. En hurtigbufret kolonne med et uttrykk kan bare besvare en ny spørring med samme uttrykk. En hurtigbufret kolonne uten uttrykk kan besvare en forespørsel om denne kolonnen med et hvilket som helst uttrykk. En hurtigbufret forespørsel som:
```
SELECT QUANTITY, REVENUE...
```
kan for eksempel besvare en ny spørring som:
```
SELECT QUANTITY/REVENUE... 
```
men ikke motsatt.
Ingen WHERE-ledd. Hvis det ikke finnes noe WHERE-ledd i et hurtigbufret resultat, kan det brukes til å besvare spørringer som oppfyller reglene for hurtigbuffertreff for SELECT-listen med et hvilket som helst WHERE-ledd som omfatter kolonner i projiseringslisten.

De beste spørringene for seeding av hurtigbufferen er generelt spørringer som forbruker store mengder databasebehandlingsressurser, og som sannsynligvis utstedes på nytt. Vær forsiktig så du ikke seeder hurtigbufferen med enkle spørringer som returnerer mange rader. Disse spørringene (for eksempel SELECT * FROM PRODUCTS, der PRODUCTS tilordnes direkte til en enkelt databasetabell) krever svært lite databasebehandling. Disse kostnadene er tilleggskostnader for nettverk og disk, som er faktorer som ikke blir løst av hurtigbufring.

Når Oracle Analytics Cloud oppfrisker variabler for semantiske modeller, undersøkes forretningsmodeller for å finne ut om de refererer til disse variablene for semantiske modeller. Hvis de gjør det, rydder Oracle Analytics Cloud all hurtigbufring for disse forretningsmodellene. Se Hvordan endringer i semantiske modeller påvirker spørringshurtigbufferen.

Bruke agenter til å seede spørringshurtigbufferen

Du kan konfigurere agenter til å seede spørringshurtigbufferen for Oracle Analytics Cloud.

Seeding av hurtigbufferen kan forbedre svartiden for brukerne når de kjører analyser eller viser analyser som er innebygd i instrumentpanelet. Du kan gjøre dette ved å planlegge at agenter skal kjøre forespørsler som oppfrisker disse dataene.

Åpne den klassiske hjemmesiden i Oracle Analytics Cloud, og velg Agent (delen Opprett).
Velg Mottaker for valget Kjør som i fanen Generelt. Personlig tilpasset hurtigbufferseeding bruker datasynligheten for hver enkelt mottaker til å tilpasse agentleveringsinnhold for hver mottaker.
Angi når du vil at hurtigbufferen skal seedes, i fanen Planlegg.
Valgfritt: Velg Betingelse, og opprett eller velg en betinget forespørsel. Du kan for eksempel ha en forretningsmodell som fastsetter når ETL-prosessen er fullført. Du kan bruke en rapport som er basert på denne forretningsmodellen, som den betingede utløseren for start av hurtigbufferseeding.
Velg en individuell forespørsel eller en hel instrumentpanelside du vil seede hurtigbufferen for, i fanen Leveringsinnhold. Hvis du velger en instrumentpanelside, kan det spare tid.
Velg individuelle brukere eller grupper som skal være mottakerne, i fanen Mottakere.
Fjern alle brukermål i fanen Mål, og velg Hurtigbuffer for Oracle Analytics Server.
Lagre agenten ved å klikke på Lagre øverst til høyre.

Den eneste forskjellen mellom agenter for hurtigbufferseeding og andre agenter er at de fjerner den forrige hurtigbufferen automatisk, og de vises ikke som varsler i instrumentpanelet.

Merknad:

Agenter for hurtigbufferseeding rydder bare spørringer med nøyaktig samsvar, så det kan fremdeles finnes foreldede data. Kontroller at hurtigbufferstrategien alltid inkluderer hurtigbufferrydding, ettersom agentspørringer ikke adresserer ad-hoc-spørringer eller drillinger.

Bruke Model Administration Tool til å rydde hurtigbufferen automatisk for bestemte tabeller

Rydding av hurtigbufferen sletter oppføringer fra spørringshurtigbufferen og holder innholdet ferskt. Du kan rydde hurtigbufferoppføringer automatisk for bestemte tabeller ved å angi en verdi i feltet Vedvarenhetstid for hurtigbuffer for hver enkelt tabell i modelladministrasjonsverktøyet.

Merknad:

Hvis du bruker semantisk modellerer, kan du se Hva er generelle egenskaper for en fysisk tabell?

Dette er nyttig for datakilder som oppdateres ofte. Hvis du for eksempel har en tabell som lagrer lagertelegrafdata som oppdateres hvert minutt, kan du bruke innstillingen Vedvarenhetstid for hurtigbuffer til å rydde oppføringene for denne tabellen hvert 59. sekund. Se Hurtigbuffer og vedvarenhetstid for hurtigbufre for angitte fysiske tabeller.

Nullstille hurtigbufferen programmatisk

Du kan automatisere nullstillingen (eller ryddingen) av hurtigbufferen for Oracle Analytics Cloud-miljøet etter behov.

Denne delen inneholder emnene nedenfor.

Om verktøyet for nullstilling av hurtigbuffer (purgeoaccache)

Oracle Analytics har et verktøy du kan kjøre for å nullstille hurtigbufferen: purgeoaccache.sh. Med dette verktøyet kan du nullstille hurtigbufferen på ulike måter. Du kan nullstille hele hurtigbufferen eller nullstille hurtigbufferen som er knyttet til en bestemt spørring, tabell eller database.

Nullstille hele hurtigbufferen (SAPurgeAllCache)

Hvis du vil nullstille alle hurtigbufferoppføringer, bruker du funksjonen SAPurgeAllCache i sapurgecache.txt. Dette er standardinnstillingen.
CALL-setningen ser slik ut:
```
Call SAPurgeAllCache();
```
Nullstille hurtigbufferen for en spørring (SAPurgeCacheByQueryPurge)

Hvis du vil nullstille hurtigbufferoppføringer som samsvarer nøyaktig med en bestemt spørring, bruker du funksjonen SAPurgeCacheByQueryPurge i sapurgecache.txt.
Tenk deg for eksempel at du har følgende spørring, der én eller flere spørringshurtigbufferoppføringer henter navnene på alle ansatte som tjener mer enn $ 100 000:
```
SELECT lastname, firstname FROM employee WHERE salary > 100000;
```
Følgende CALL-setning nullstiller hurtigbufferoppføringene som er knyttet til denne spørringen:
```
Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );
```
Nullstille hurtigbufferen for en tabell (SAPurgeCacheByTable)

Hvis du vil nullstille hurtigbufferoppføringer som er knyttet til en bestemt tabell i en fysisk database, bruker du funksjonen SAPurgeCacheByTable i sapurgecache.txt. Funksjonen tar opptil fire parametre som hver representerer komponentene i et fullt kvalifisert navn på en fysisk tabell (database-, katalog-, skjema-, tabellnavn).

Merknad:
Du kan ikke bruke jokertegn i funksjonsparametrene. I tillegg er både databasenavnet og tabellnavnet obligatoriske parametre, dvs. de kan ikke være null.
Du kan for eksempel ha en tabell med det fullt kvalifiserte navnet DBName.CatName.SchName.TabName. Følgende CALL-setning nullstiller hurtigbufferoppføringene som er knyttet til denne tabellen i det fysiske laget i den semantiske modellen:
```
Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );
```
Nullstille hurtigbufferen for en database (SAPurgeCacheByDatabase)

Hvis du vil nullstille hurtigbufferoppføringer som er knyttet til en bestemt fysisk database, bruker du funksjonen SAPurgeCacheByDatabase i sapurgecache.txt. Funksjonen tar én parameter som representerer navnet på den fysiske databasen, og parameteren kan ikke være null.
CALL-setningen ser slik ut:
```
Call SAPurgeCacheByDatabase( 'DBName' );
```

Typisk arbeidsflyt for programmatisk nullstilling av hurtigbufferen

Her er oppgavene for nullstilling av hurtigbufferen for Oracle Analytics Cloud-miljøet.

Oppgave	Beskrivelse	Flere opplysninger
Finne ut hvordan du vil sikre JDBC-tilkoblingen	Velg Ressurseier (anbefalt) eller JSON Web Tokens (JWT) som påstandstype, avhengig av sikkerhetskravene.	Se Velge en påstandstype for JDBC-tilkoblingen i håndboken Koble Oracle Analytics Cloud til dataene.
Registrere BIJDBC-applikasjonen	Registrer BIJDBC-applikasjonen for å autentisere JDBC-tilkoblingen.	Se Registrere BIJDBC-applikasjonen ved hjelp av påstanden Ressurseier i håndboken Koble Oracle Analytics Cloud til dataene hvis du vil ha informasjon om påstanden Ressurseier. Ved JWT-påstand kan du se informasjonen i håndboken Koble Oracle Analytics Cloud til dataene: Generer først en privat nøkkel og et sertifikat som kreves i JWT, se Generere klientens private nøkkel og klientsertifikatfilen. Bruk deretter påstanden JWT, se Registrere BIJDBC-applikasjonen ved hjelp av påstanden JWT.
Laste ned og sette opp verktøyet for nullstilling av hurtigbuffer	Last ned `BI-JDBC.zip` og `bi-jdbc-all.jar`, og sett opp verktøyet.	Laste ned og sette opp verktøyet for nullstilling av hurtigbuffer
Angi OAuth-tilkoblingsopplysninger	Bruk OCI-konsollen for å hente OAuth-tilkoblingsdetaljene som er nødvendige for å koble til Oracle Analytics Cloud, og angi opplysningene i `bijdbc.properties`.	Legge til tilkoblingsdetaljer i bijdbc.properties
Kjøre verktøyet for nullstilling av hurtigbuffer	Identifiser hurtigbufferen du vil nullstille, og kjør verktøyet for nullstilling av hurtigbuffer for å nullstille den angitte hurtigbufferen.	Kjøre verktøyet for nullstilling av hurtigbuffer (purgeoaccache)
Opprette et skript for å nullstille hurtigbufferen regelmessig (valgfritt)	Bruk en Cron-jobb (eller lignende) for å nullstille hurtigbufferen etter en tidsplan som passer for organisasjonen din.	Opprette et skript for å nullstille hurtigbufferen regelmessig etter en tidsplan

Laste ned og sette opp verktøyet for nullstilling av hurtigbuffer

Før du kan bruke verktøyet for nullstilling av hurtigbuffer, må du laste ned BI-JDBC.zip og utføre noen oppsettoppgaver. Du må for eksempel hente bijdbc-all.jar og angi variabelen JAVA_HOME.

Last ned filen BI-JDBC.zip.
Pakk ut filen BI-JDBC.zip.
Gjør deg kjent med følgende mapper og filer:
- \certs: Mappen der du kopierer sertifikatfilen og filen for privat nøkkel som er nødvendig for OAuth 2.0-autorisasjon med JWT.
- \lib: Mappen der du kopierer bijdbc-all.jar. Denne JAR-filen inneholder JDBC-driverne som brukes for å koble til Oracle Analytics Cloud.
- \props: Denne mappen inneholder konfigurasjonsfiler for verktøyet for nullstilling av hurtigbuffer.
- bijdbc.properties: Verktøyet for nullstilling av hurtigbuffer bruker opplysninger i denne filen for å koble til Oracle Analytics Cloud. Det finnes to versjoner av denne filen. Versjonen i \rowner inneholder tilkoblingsparametrene du må konfigurere for å koble til som "ressurseier". Versjonen i \jwt inneholder tilkoblingsparametrene du må konfigurere for å koble til med JWT (JSON Web Token).
- sapurgecache.txt: Verktøyet for nullstilling av hurtigbuffer bruker denne filen for å bestemme hvilken hurtigbuffer som skal nullstilles, dvs. alt eller hurtigbufferoppføringer for en bestemt spørring, tabell eller database.
- \src: Mappen som inneholder filen purgecache.jar.
- purgeoaccache.bat og purgeoaccache.sh: Verktøyet du kjører for å nullstille hurtigbufferen.
Kontroller at JAVA_HOME er riktig angitt i purgeoaccache (.sh eller .bat).
1. Åpne purgeoaccache-filen du planlegger å bruke (.sh for Linux, .bat for Windows) i mappen BI-JDBC.
2. Kontroller at variabelen JAVA_HOME er riktig JDK-mappe i det aktuelle miljøet, og oppdater hvis nødvendig.
Hent JDBC-driverne som er nødvendige for å koble til Oracle Analytics Cloud (bijdbc-all.jar ).
1. Last ned JDBC-driveren hvis du ikke allerede har gjort det. Se Laste ned JDBC-driveren i håndboken Koble Oracle Analytics Cloud til dataene.
2. Kopier filen bijdbc-all.jar og lim den inn i BI-JDBC/lib.

Legge til tilkoblingsdetaljer i bijdbc.properties

Bruk Oracle Cloud Infrastructure-konsollen (OCI) for å hente tilkoblingsopplysningene som er nødvendige for filen bijdbc.properties.

For å kunne gjøre dette må du ha tillatelse til å få tilgang til OCI-konsollen.

Logg på OCI-konsollen, og naviger til siden Flere detaljer for Oracle Analytics Cloud-forekomsten din.
1. Klikk på øverst til venstre i OCI-konsollen.
2. Klikk på Analyse og KI. Klikk på Analytics Cloud under Analyse.
3. Velg seksjonen som inneholder Oracle Analytics Cloud-forekomsten du ser etter.
4. Klikk på navnet på forekomsten.
5. Klikk på Flere detaljer.
Hent tilkoblingsopplysningene som er nødvendige for filen bijdbc.properties.
1. For å hente oacHostname og idcsEndpointUrl kopierer du verdien for Vertsnavn under Nettverksopplysninger og verdien for Stripe under Identitetsleverandør.
2. For å hente idcsClientId klikker du på koblingen App under Identitetsleverandør for å få tilgang til OAuth-konfigurasjonen for forekomsten din. Gå til delen Generelle opplysninger og noter deg klient-ID-en.
3. For å hente idcsClientScope ruller du ned til delen Konfigurer applikasjons-API-er som må OAuth-beskyttes og noterer deg verdien for Omfang.
4. Hvis du bruker påstandstypen Ressurseier for å sikre JDBC-tilkoblingen til Oracle Analytics Cloud, henter du idcsClientSecret. Gå til delen Generelle opplysninger og noter deg klienthemmeligheten.
5. Hvis du bruker påstandstypen JWT for å sikre JDBC-tilkoblingen til Oracle Analytics Cloud, henter du certificateFile og privateKeyFile, dvs. navnet og plasseringen til CERT-filen og PEM-filen du brukte for å opprette OAuth-konfigurasjonen for forekomsten din, og kopierte til mappen /certs.
  
  Merknad:
  Hvis du ikke har kopiert CERT-filen og PEM-filen til mappen /certs, må du gjøre det nå.
Kopier bijdbc.properties-filen du vil bruke, og lim den inn i mappen BI-JDBC/props/, slik at du kan tilpasse den.
Ressurseier-malen ligger i mappen props/rowner. JWT-malen ligger i mappen props/jwt.

Legg til tilkoblingsdetaljene du noterte deg i trinn 2, sammen med administratorbrukernavnet og -passordet ditt, i filen bijdbc.properties.

Eksempel med Ressurseier:

########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>

Eksempel med 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

Lagre og lukk filen.

Kjøre verktøyet for nullstilling av hurtigbuffer (purgeoaccache)

Når du har fullført oppsettet og konfigurert filen bijdbc.properties, er du klar til å kjøre skriptet. Skriptet nullstiller hele hurtigbufferen som standard. Hvis du vil nullstille hurtigbufferoppføringer for en bestemt spørring, tabell eller database, angir du den nødvendige funksjonen og tilhørende parametre i sapurgecache.txt.

Valgfritt: Åpne filen sapurgecache.txt i mappen BI-JDBC/props, og oppdater CALL-setningen for å angi hvilke hurtigbufferoppføringer du vil at skriptet skal nullstille. Se Om verktøyet for nullstilling av hurtigbuffer (purgeoaccache).
Kjøre verktøyet for nullstilling av hurtigbuffer (BI-JDBC\purgeoaccache). Hvis du bruker Linux, kjører du purgeoaccache.sh. Hvis du bruker Windows, kjører du purgeoaccache.bat.

Det vises en melding om at hurtigbufferen er nullstilt.

Opprette et skript for å nullstille hurtigbufferen regelmessig etter en tidsplan

Du kan opprette et egendefinert skript, for eksempel en Cron-jobb (eller lignende), som nullstiller hurtigbufferen etter en tidsplan som passer for organisasjonen din.

Du kan for eksempel velge å kjøre et egendefinert skript kl. 23:00 hver dag for å rydde hele hurtigbufferen. I dette tilfellet kan en Cron-oppføring se slik ut:

$crontab -e
0 23 * * * /bin/bash ~/BI-JDBC/purgeoaccache.sh >> ~/BI-JDBC/temp/purgeoaccache.log 2>&1