Zoekvraagcaches beheren

In Oracle Analytics Cloud wordt een lokale cache met resultatensets voor zoekvragen onderhouden in de zoekvraagcache.

Onderwerpen:

Info over de zoekvraagcache

Dankzij de zoekvraagcache kan Oracle Analytics Cloud reageren op een groot aantal latere zoekvraagaanvragen zonder te zoeken in back-end-gegevensbronnen. Op deze wijze worden de prestaties verhoogd. Na verloop van tijd kunnen de querycachegegevens verouderd raken omdat updates alleen op de gegevensbronnen in de back-end worden uitgevoerd

Voordelen van cachen

De snelste manier om een zoekvraag uit te voeren is door het merendeel van de verwerking over te slaan en gebruik te maken van een eerder berekend antwoord.

Door gebruik te maken van een zoekvraagcache worden door Oracle Analytics Cloud vooraf berekende resultaten van zoekvragen opgeslagen in een lokale cache. Als een andere zoekvraag gebruik kan maken van die resultaten, hoeft er minder verwerking plaats te vinden voor die zoekvraag. Een enorme verbetering in de gemiddelde responstijd voor een zoekvraag kan hiervan het gevolg zijn.

Naast betere prestaties worden door het beantwoorden van een zoekvraag vanuit een lokale cache ook minder netwerkresources en verwerkingstijd op de databaseserver verbruikt. Netwerkresources worden bespaard omdat tussentijdse resultaten niet worden geretourneerd naar Oracle Analytics Cloud. Doordat de zoekvraag niet wordt uitgevoerd op de database, is de databaseserver vrij om andere werkzaamheden uit te voeren. Als de database gebruikmaakt van een terugboekingssysteem, dan kan het uitvoeren van minder zoekvragen ook leiden tot minder kosten.

Een ander voordeel van het gebruik van de cache om een zoekvraag te beantwoorden, is het besparen van verwerkingstijd in Oracle Analytics Cloud, vooral als de resultaten van de zoekvraag worden opgehaald uit meerdere databases. Afhankelijk van de zoekvraag, kunnen er behoorlijk wat join- en sort-processen plaatsvinden op de server. Als de query al is berekend, worden deze processen vermeden en zijn de server resources vrij voor andere taken.

Samengevat kan het gebruik van zoekvraagcaches de prestaties ingrijpend verbeteren en leiden tot minder netwerkverkeer, databaseverwerking en overhead.

Kosten van het gebruik van caches

Zoekvraagcaches hebben veel duidelijke voordelen, maar er zijn ook kosten aan verbonden.

De mogelijkheid bestaat dat de resultaten in de cache verouderd zijn.
Er zijn administratieve kosten verbonden aan het beheer van de cache.

Met betrekking tot het beheer van de cache wegen de voordelen meestal veel zwaarder dan de kosten.

Beheertaken die verband houden met de cache.

Enkele beheertaken houden verband met de cache. U moet de persistentietijd van de cache voor elke fysieke tabel op de juiste wijze instellen, gebaseerd op hoe vaak de gegevens in die tabel worden bijgewerkt.

Wanneer de frequentie van het bijwerken varieert, moet u bijhouden wanneer wijzigingen optreden en vervolgens de cache handmatig opschonen wanneer dit nodig is.

De cache up-to-date houden

Als de cache-ingangen niet worden opgeschoond wanneer de gegevens in de onderliggende databases veranderen, kunnen zoekvragen mogelijk verouderde resultaten opleveren.

U moet zelf bepalen of dit acceptabel is. Het is in bepaalde omstandigheden misschien acceptabel dat de cache verouderde gegevens bevat. U moet bepalen welk niveau aan verouderde gegevens acceptabel is en vervolgens een set regels configureren om aan deze niveaus te voldoen (en deze opvolgen).

Stel bijvoorbeeld dat u een applicatie gebruikt om de bedrijfsgegevens van een groot conglomeraat te analyseren en u jaarlijkse samenvattingen maakt van de verschillende divisies van het bedrijf. Nieuwe gegevens zijn niet wezenlijk van invloed op de zoekvragen omdat deze alleen van toepassing zijn op de samenvattingen voor het volgende jaar. In dit geval zijn er wellicht meer argumenten om de cache-ingangen ongemoeid te laten.

Maar stel in een ander geval dat de databases drie keer per dag worden bijgewerkt en u een zoekvraag uitvoert over de activiteiten op de huidige dag. In dat geval moet u de cache vaker opschonen of mogelijk zelfs overwegen om helemaal geen gebruik te maken van een cache.

Een ander scenario is dat u de gegevensset helemaal van begin af aan opbouwt na periodieke intervallen (bijvoorbeeld eenmaal per week). In dat geval kunt u de volledige cache opschonen als onderdeel van het opnieuw opbouwen van de gegevensset. Op deze manier zorgt u ervoor dat u nooit verouderde gegevens in de cache hebt.

Wat de situatie ook is, u moet zelf evalueren in welke gevallen het acceptabel is dat niet-actuele informatie wordt geretourneerd naar de gebruikers.

Het delen van de cache onder gebruikers

Als gedeeld inloggen is geactiveerd voor een bepaalde verbindingsgroep, kan de cache worden gedeeld onder gebruikers en hoeft deze niet te worden gevuld voor elke gebruiker.

Als gedeeld inloggen niet is geactiveerd en gebruikersspecifieke inlognamen voor de database worden gebruikt, moet elke gebruiker zijn of haar eigen cache-ingang genereren.

Zoekvraagcaches activeren of deactiveren

In Oracle Analytics Cloud is de zoekvraagcache standaard geactiveerd. U kunt querycaches activeren en deactiveren op de pagina Geavanceerde systeeminstellingen.

Klik op Console.
Klik op Geavanceerde systeeminstellingen.
Klik op Prestaties en compatibiliteit.
Schakel Cache activeren in of uit.
- Ingeschakeld: gegevens in zoekvraagcache plaatsen is geactiveerd.
- Uitgeschakeld: gegevens in cache plaatsen is gedeactiveerd.
Klik op Toepassen.
Het kan enkele minuten duren voordat de wijzigingen overal in het systeem zijn doorgevoerd.

De cache controleren en beheren

Als u de wijzigingen in de onderliggende databases wilt beheren en de cache-ingangen wilt controleren, moet u een strategie voor het cachebeheer ontwikkelen.

U hebt een proces nodig voor het ongeldig maken van cache-ingangen wanneer de gegevens zijn gewijzigd in de onderliggende tabellen waaruit de cache bestaat en een proces om ongewenste cache-ingangen te verwijderen.

Deze sectie bevat de volgende onderwerpen:

Een strategie voor het cachebeheer kiezen

De keuze voor een strategie voor cachebeheer is afhankelijke van de vluchtigheid van de gegevens in de onderliggende databases en de voorspelbaarheid van de wijzigingen die de oorzaak zijn van deze vluchtigheid.

Deze is ook afhankelijk van het aantal en type zoekvragen waaruit uw cache bestaat en het gebruik van deze zoekvragen. In deze sectie wordt een overzicht gegeven van de verschillende benaderingen van cachebeheer.

Caches voor het systeem deactiveren

U kunt caches deactiveren voor het volledige systeem om het gebruik van de bestaande cache door alle nieuwe cache-ingangen en alle nieuwe zoekvragen te stoppen. Wanneer u caches deactiveert, kunt u deze later weer activeren zonder ingangen te verliezen die zijn opgeslagen in de cache.

Het tijdelijk deactiveren van caches is een handige strategie in situaties waar u vermoedt dat de cache-ingangen verouderd zijn, maar dit eerst wilt controleren voordat u deze ingangen of de volledige cache gaat opschonen. Als u vindt dat de gegevens die zijn opgeslagen in de cache nog steeds relevant zijn of nadat u problematische ingangen hebt verwijderd, kunt u de cache weer veilig activeren. Als het nodig is schoont u de volledige cache of het gedeelte van de cache dat is gekoppeld aan een speciaal bedrijfsmodel, op voordat u de cache weer activeert.

Cache en persistentietijd cache voor de opgegeven fysieke tabellen

U kunt voor elke fysieke tabel een attribuut instellen dat in de cache kan worden geplaatst, zodat u kunt opgeven of zoekvragen voor die tabel worden toegevoegd aan de cache om toekomstige zoekvragen te beantwoorden.

Als u caches activeert voor een tabel, dan worden alle zoekvragen die betrekking hebben op de tabel toegevoegd aan de cache. Voor alle tabellen kunnen standaardcaches worden geactiveerd, maar sommige tabellen lenen zich er minder voor om te worden toegevoegd aan een cache, tenzij u geschikte instellingen voor cachepersistentie instelt. Stel dat u een tabel hebt waarin tickergegevens worden opgeslagen, die elke minuut worden bijgewerkt. U kunt aangeven dat u de ingangen voor die tabel elke 59 seconden wilt opschonen.

U kunt ook instellingen voor cachepersistentie gebruiken om op te geven hoe lang de ingangen voor deze tabel worden opgeslagen in de zoekvraagcache. Dit is handig voor gegevensbronnen die frequent worden bijgewerkt.

Dubbelklik in de fysieke laag in Model Administration Tool op de fysieke tabel.

Als u Semantic Modeler gebruikt, raadpleegt u voor meer informatie: Wat zijn de algemene eigenschappen van een fysieke tabel?.
Selecteer in het eigenschappendialoogvenster Fysieke tabel op het tabblad Algemeen een van de volgende mogelijkheden:
- Selecteer Cachebaar om caches te activeren.
- Deactiveer Cachebaar om te voorkomen dat een tabel in cache wordt geplaatst.
Als u een vervaltijd voor de cache wilt instellen, geeft u de Persistentietijd cache op en geeft u een maateenheid op (dagen, uren, minuten of seconden). Als u niet wilt dat cache-ingangen automatisch verlopen, selecteert u Cache verloopt nooit.
Klik op OK.

Welke gevolgen wijzigingen in het semantische model hebben op de zoekvraagcache

Wanneer u semantische modellen hebt gewijzigd met Semantic Modeler of Model Administration Tool, kunnen de wijzigingen gevolgen hebben voor onderdelen die in de cache zijn opgeslagen. Als u bijvoorbeeld de definitie van een fysiek object of een dynamische semantisch-model-variabele wijzigt, zijn de cache-ingangen die naar dat object of die variabele verwijzen mogelijk niet meer geldig. Vanwege deze wijzigingen is het wellicht nodig om de cache op te schonen. Er zijn twee scenario's die van belang zijn: wanneer u het bestaande semantische model wijzigt en wanneer u een nieuw semantisch model maakt (of uploadt).

Wijzigingen in het semantische model

Wanneer u een semantisch model wijzigt of een ander RPD-bestand uploadt, zullen alle wijzigingen die u maakt die gevolgen hebben voor cache-ingangen automatisch aanleiding zijn om alle cache-ingangen op te schonen die naar de gewijzigde objecten verwijzen. Het opschonen vindt plaats wanneer u de wijzigingen uploadt. Als u bijvoorbeeld een fysieke tabel uit een semantisch model verwijderd, worden alle cache-ingangen die verwijzen naar die tabel opgeschoond bij het inchecken. Alle wijzigingen die worden aangebracht in een semantisch model in de logische laag wissen alle vermeldingen in caches voor dat semantische model.

Wijzigingen aan algemene variabelen voor semantische modellen

De waarden van algemene variabelen voor semantische modellen worden vernieuwd door gegevens die het resultaat zijn van zoekvragen. Wanneer u een algemene variabele voor semantische modellen definieert, maakt u een initialisatieblok of gebruikt u een bestaand blok dat een SQL-zoekvraag bevat. U kunt ook een schema configureren om de zoekvraag uit te voeren en periodiek de waarde van de variabele te vernieuwen.

Als de waarde van een algemene variabele voor semantische modellen wordt gewijzigd, worden alle cache-ingangen die deze variabele gebruiken in een kolom verouderd en worden nieuwe cache-ingangen gegenereerd wanneer de gegevens in die ingang opnieuw nodig zijn. De oude cache-ingang wordt niet onmiddellijk verwijderd, maar blijft aanwezig totdat deze wordt opgeschoond door het gebruikelijke cachemechanisme.

Strategieën voor het gebruik van de cache

Een van de grootste voordelen van zoekvraagcaches is het verbeteren van de prestaties van de zoekvraag.

Zoekvraagcaches kunnen waardevol zijn omdat de zoekvraag in de cache kan worden geplaatst om tijdens minder drukke perioden te worden uitgevoerd, waarna de resultaten worden opgeslagen in de cache. Een goede strategie om zoekvragen in de cache te plaatsen vereist dat u weet wanneer cachetreffers plaatsvinden.

Als u voor alle gebruikers de cache wilt vullen, kunt u wellicht de volgende zoekvraag in de cache plaatsen:

SELECT User, SRs

Nadat de zoekvraag SELECT User, SRs in de cache is geplaatst, zijn de volgende zoekvragen cachetreffers:

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

Deze sectie bevat de volgende onderwerpen:

Info over cachetreffers

Wanneer caches zijn geactiveerd, wordt elke zoekvraag geëvalueerd om te bepalen of deze zich kwalificeert voor een cachetreffer.

Een cachetreffer betekent dat Oracle Analytics Cloud in staat was de cache te gebruiken om de zoekvraag te beantwoorden en helemaal geen gebruik hoefde te maken van de database. Oracle Analytics Cloud kan de zoekvraagcache gebruiken om zoekvragen op hetzelfde of een hoger aggregatieniveau te beantwoorden.

Vele factoren bepalen mede of een cachetreffer heeft plaatsgevonden. In de onderstaande tabel worden deze factoren beschreven.

Factor of regel	Beschrijving
Een subset kolommen in de `SELECT`-lijst moet matchen.	Alle kolommen in de `SELECT`-lijst van een nieuwe zoekvraag moeten bestaan in de zoekvraag in de cache om te kwalificeren als een cachetreffer of ze moeten berekend kunnen worden aan de hand van de kolommen in de zoekvraag. Deze regel beschrijft de minimale vereiste om van een cachetreffer te spreken, maar aan deze regel voldoen is geen garantie voor een cachetreffer. De overige regels in deze tabel zijn ook van toepassing.
Kolommen in de `SELECT`-lijst kunnen worden samengesteld uit uitdrukkingen in kolommen van de zoekvragen in de cache.	Oracle Analytics Cloud kan uitdrukkingen op resultaten in de cache berekenen als antwoord op de nieuwe zoekvraag, maar alle kolommen moeten zich in het resultaat in de cache bevinden. Bijvoorbeeld, de zoekvraag: SELECT product, month, averageprice FROM sales WHERE year = 2000 treffers in cache op de zoekvraag: SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 omdat `averageprice` kan worden berekend aan de hand van `dollars` en `unitsales` (`averageprice = dollars/unitsales`).
`WHERE`-clausule moet semantisch hetzelfde zijn of een logische subset	Voordat de zoekvraag kan worden gekwalificeerd als een cachetreffer, moeten de beperkingen van de `WHERE`-clausule gelijk zijn aan de resultaten in de cache of een subset zijn van de resultaten in de cache. Een `WHERE`-clausule die een logische subset is van een zoekvraag in de cache, kan worden gekwalificeerd als een cachetreffer als de subset voldoet aan één van de volgende criteria: Een subset van waarden in de `IN`-lijst. Zoekvragen die minder elementen vereisen van een `IN`-lijst voor de zoekvraag in de cache, worden gekwalificeerd als cachetreffer. Bijvoorbeeld, de volgende zoekvraag: SELECT employeename, region FROM employee, geography WHERE region in ('EAST', 'WEST') wordt gekwalificeerd als een treffer op de volgende zoekvraag in de cache: SELECT employeename, region FROM employee, geography WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST') Deze bevat minder (maar identieke) `OR`-beperkingen dan het resultaat in de cache. Deze bevat een logische subset van een letterlijke vergelijking. Bijvoorbeeld, het volgende predicaat: WHERE revenue < 1000 wordt gekwalificeerd als een cachetreffer op een vergelijkbare zoekvraag met het predicaat: WHERE revenue < 5000 Er is geen `WHERE`-clausule. Als een zoekvraag zonder `WHERE`-clausule zich in de cache bevindt, dan worden andere zoekvragen die voldoen aan alle andere regels voor cachetreffers gekwalificeerd als cachetreffers, ongeacht de bijbehorende `WHERE`-clausule. Bovendien moet kolommen die worden gebruikt in de `WHERE`-clausule op de projectielijst staan. Bijvoorbeeld, de volgende zoekvraag: SELECT employeename FROM employee, geography WHERE region in ('EAST', 'WEST') Resulteert niet in een cachetreffer voor de vulzoekvraag in de vorige lijst omdat REGION niet op de projectielijst staat.
Zoekvragen met alleen dimensies moeten een exacte match opleveren.	Als een zoekvraag alleen een dimensie bevat, dit wil zeggen dat er geen feit of meting is opgenomen in de zoekvraag, dan zorgt alleen een exacte match van de projectiekolommen van de zoekvraag in de cache voor een treffer die de cache treft. Door dit gedrag wordt het optreden van 'valse positieven' vermeden wanneer er meerdere logische bronnen zijn voor een dimensietabel.
Zoekvragen met speciale functies moeten een exacte match zijn.	Andere zoekvragen die speciale functies bevatten, zoals tijdreeksfuncties, (`AGO`, `TODATE` en `PERIODROLLING`), limiet- en offsetfuncties (`OFFSET` en `FETCH`), relationele functies (`ISANCESTOR`, `ISLEAF`, `ISROOT` en `ISSIBLING`), externe aggregatiefuncties, en filtermetrieken in het algemeen moeten ook een exacte match opleveren met de projectiekolommen in de query in cache. In deze gevallen moet de filter ook een exacte match zijn. Voor filtermetrieken, als de filtermetriek kan worden herschreven als een `WHERE`-clausule, kan van de subsetcache gebruik worden gemaakt.
Een set logische tabellen moet matchen	Om te worden gekwalificeerd als een cachetreffer, moeten alle inkomende zoekvragen dezelfde set logische tabellen hebben als de cache-ingang. Door deze regel worden ongeldige cachetreffers vermeden. Bijvoorbeeld: `SELECT * FROM product` matcht niet met `SELECT * FROM product, sales`.
Waarden van sessievariabelen moeten matchen, inclusief veiligheidssessievariabelen.	Als het logische of fysieke SQL-statement verwijst naar een sessievariabele, moeten de waarden van de sessievariabelen matchen. Anders kunnen we niet spreken van een cachetreffer. Bovendien moeten de waarden van de sessievariabelen die veiligheidsgevoelig zijn, matchen met de waarden van de veiligheidssessievariabelen die zijn gedefinieerd in semntisch model, ook als het logische SQL-statement zelf niet verwijst naar sessievariabelen. Zie Zorgen voor correcte cacheresultaten bij het gebruik van databasebeveiliging op rijniveau.
Gelijkwaardige join-voorwaarden	De logische join-tabel die het resultaat is van een nieuwe zoekvraag moet hetzelfde zijn als (of een subset zijn van) de resultaten in cache om te worden gekwalificeerd als een cachetreffer.
Het `DISTINCT`-attribuut moet hetzelfde zijn.	Als een zoekvraag in cache dubbele records door een verwerking met `DISTINCT` (bijvoorbeeld: `SELECT DISTINCT`...), moeten aanvragen voor de kolommen in cache ook verwerking met `DISTINCT` gebruiken. Een aanvraag voor dezelfde kolom zonder de verwerking met `DISTINCT` is een cachemisser.
Zoekvragen moeten compatibele aggregatieniveaus bevatten.	Zoekvragen die een geaggregeerd informatieniveau aanvragen, kunnen resultaten in de cache gebruiken op een lager aggregatieniveau. In de volgende zoekvraag worden bijvoorbeeld de verkochte hoeveelheid bij de leverancier op regionaal en op plaatselijk niveau aangevraagd: SELECT supplier, region, city, qtysold FROM suppliercity In de volgende zoekvraag wordt de verkochte hoeveelheid op het plaatselijk niveau aangevraagd: SELECT city, qtysold FROM suppliercity De tweede zoekvraag resulteert in een cachetreffer op de eerste zoekvraag.
Beperkte extra aggregatie	Als bijvoorbeeld een zoekvraag met de kolom `qtysold` in de cache is geplaatst, resulteert een zoekvraag naar `RANK(qtysold)` in een cachemisser. Bovendien kan een zoekvraag die een aanvraag uitvoert op `qtysold` op landelijk niveau een cachetreffer krijgen van een zoekvraag die een aanvraag uitvoert op `qtysold` op het landelijk en regionaal niveau.
De `ORDER BY`-clausule moet bestaan uit kolommen in de SELECT-lijst.	Zoekvragen die zijn geordend op kolommen die niet zijn opgenomen in de SELECT-list, resulteren in cachemissers.
Diagnose stellen van het gedrag van cachetreffers	Om het gedrag van cachetreffers beter te kunnen beoordelen, stelt u de sessievariabele ENABLE_CACHE_DIAGNOSTICS in op '4', zoals in het volgende voorbeeld wordt getoond: ENABLE_CACHE_DIAGNOSTICS=4

Zorgen voor correcte cacheresultaten bij het gebruik van databasebeveiliging op rijniveau

Bij gebruik van een databasebeveiligingsstrategie op rijniveau, zoals een Virtual Private Database (VPD), zijn de geretourneerde gegevensresultaten afhankelijk van de autorisatiereferenties van de gebruiker.

Daarom moet Oracle Analytics Cloud weten of een gegevensbron gebruikmaakt van databasebeveiliging op rijniveau en welke variabelen relevant zijn voor de beveiliging.

Om ervoor te zorgen dat cachetreffers alleen plaatsvinden voor cache-ingangen die alle veiligheidsgevoelige variabelen bevatten en ermee matchen, moet u het database-object en de sessievariabele objecten correct configureren in Model Administration Tool, op de volgende wijze:

Database-object. Selecteer in de fysieke laag, op het tabblad 'Algemeen' van het dialoogvenster 'Database' Virtual Private Database om aan te geven dat de gegevensbron databasebeveiliging op rijniveau gebruikt.

Als u databasebeveiliging op rijniveau gebruikt met een gedeelde cache, dan moet u deze optie selecteren om het delen van cache-invoeren te vermijden waarvan de veiligheidsgevoelige variabelen niet overeenkomen.
Sessievariabel object. Selecteer voor veiligheidsgerelateerde variabelen in het dialoogvenster 'Sessievariabele' Veiligheidsgevoelig om deze te identificeren als veiligheidsgevoelig wanneer een databasebeveiligingsstrategie op rijniveau wordt gebruikt. Deze optie zorgt ervoor dat de cache-ingangen worden gemarkeerd met veiligheidsgevoelige variabelen en activeert het matchen van veiligheidsgevoelige variabelen voor alle inkomende zoekvragen.

Voer een groep zoekvragen uit om de cache te vullen

Als u het aantal potentiële cachetreffers wilt maximaliseren, is een strategie het uitvoeren van een groep zoekvragen om de cache te vullen.

Hier volgen een aantal aanbevelingen voor het type zoekvragen dat u kunt gebruiken om een groep zoekvragen samen te stellen waarmee u de cache kunt vullen.

Algemene zoekvragen die vooraf zijn opgebouwd. Zoekvragen die over het algemeen worden uitgevoerd, vooral zoekvragen die duur zijn in de verwerking, zijn vaak uitstekende zoekvragen om de cache te vullen. Zoekvragen waarvan de resultaten worden ingesloten in dashboards zijn goede voorbeelden van algemene zoekvragen.
SELECT-lijsten zonder uitdrukkingen. Door uitdrukkingen te verwijderen uit kolommen met SELECT-lijsten, wordt de kans op cachetreffers vergroot. Een kolom met een uitdrukking die in cache is opgeslagen, kan alleen een antwoord zijn op een nieuwe zoekvraag met dezelfde uitdrukking. Een kolom in cache zonder uitdrukkingen kan een antwoord zijn op een aanvraag voor die kolom met elke uitdrukking. Bijvoorbeeld: een aanvraag in cache, zoals:
```
SELECT QUANTITY, REVENUE...
```
kan een antwoord zijn op een nieuwe zoekvraag, zoals:
```
SELECT QUANTITY/REVENUE... 
```
maar het omgekeerde geldt niet.
Geen WHERE-clausule. Als er geen WHERE-clausule staat in een resultaat in cache, kan deze worden gebruikt om zoekvragen te beantwoorden die voldoen aan de regels voor cachetreffers voor de selectielijst met een willekeurige WHERE-clausule waar kolommen zijn opgenomen in de projectielijst.

Over het algemeen zijn de beste zoekvragen om de cache te vullen, zoekvragen die intensief gebruikmaken van databaseverwerkingsresources en die waarschijnlijk opnieuw worden uitgevoerd. Pas ervoor op dat u de cache niet vult met eenvoudige zoekvragen die veel rijen retourneren. Deze zoekvragen (bijvoorbeeld: SELECT * FROM PRODUCTS, waar PRODUCTS rechtstreeks verwijst naar één databasetabel) vereisen zeer weinig databaseverwerking. Hun kosten liggen op het gebied van netwerk- en schijfoverhead, iets waarvoor het gebruik van caches geen oplossing biedt.

Wanneer in Oracle Analytics Cloud variabelen voor semantische modellen worden vernieuwd, worden bedrijfsmodellen onderzocht om te bepalen of deze verwijzen naar die betreffende variabelen. Als dat het geval is, schoont Oracle Analytics Cloud alle caches op voor deze bedrijfsmodellen. Zie Welke gevolgen wijzigingen in het semantische model hebben op de zoekvraagcache.

Gebruik agenten om zoekvragen in de cache te plaatsen

U kunt agenten configureren om de zoekvraagcache in Oracle Analytics Cloud te vullen.

Door de cache te vullen kunnen de responstijden worden verbeterd voor gebruikers wanneer ze analyses uitvoeren of weergeven die zijn ingesloten in hun dashboards. U kunt dit bereiken door agenten in te plannen om aanvragen uit te voeren waarmee deze gegevens worden vernieuwd.

Open in Oracle Analytics Cloud de klassieke beginpagina en selecteer Agent (in de sectie Maken).
Selecteer op het tabblad Algemeen de optie Ontvanger voor de optie Uitvoeren als. Bij gepersonaliseerd vullen van de cache wordt de zichtbaarheid van de gegevens van elke ontvanger gebruikt om de agent aan te passen met betrekking tot de geleverde inhoud voor elke ontvanger.
Geef op het tabblad Planning op wanneer u wilt dat de cache wordt gevuld.
Optioneel: Selecteer Voorwaarde een maak of selecteer een voorwaardelijke aanvraag. U beschikt bijvoorbeeld over een bedrijfsmodel waarin wordt bepaald wanneer het ETL-proces is voltooid. U kunt een rapport op basis van dit bedrijfsmodel gebruiken als voorwaardelijke trigger voor het vullen van de cache.
Selecteer op het tabblad Bezorgingsinhoud een afzonderlijke aanvraag of een volledige dashboardpagina waarvoor u de cache wilt vullen. Door een dashboardpagina te selecteren kunt u tijd besparen.
Selecteer op het tabblad Ontvangers afzonderlijke gebruikers of groepen als ontvangers.
Wis op het tabblad Bestemmingen alle bestemmingen van gebruikers en selecteer Oracle Analytics Server Cache.
Sla de agent op door op de knop Opslaan te klikken in de rechterbovenhoek.

Het enige verschil tussen agenten die de cache vullen en andere agenten is dat de laatstgenoemden de vorige cache automatisch wissen en dat ze niet op het dashboard worden weergegeven als waarschuwingen.

Opmerking:

Agenten die de cache vullen schonen alleen exact matchende zoekvragen op, dus mogelijk zijn er nog steeds verouderde gegevens aanwezig. Controleer of de cachestrategie altijd zorgt voor het opschonen van de cache, omdat zoekvragen met agenten geen rekening houden met ad-hoczoekvragen of drills.

Model Administration Tool gebruiken om automatisch de cache op te schonen voor specifieke tabellen

Door de cache op te schonen worden ingangen verwijderd uit de zoekvraagcache en blijft de inhoud vers. U kunt automatisch cache-ingangen opschonen voor specifieke tabellen, door het veld Persistentietijd cache in te stellen voor elke tabel in Model Administration Tool.

Opmerking:

Als u Semantic Modeler gebruikt, raadpleegt u voor meer informatie: Wat zijn de algemene eigenschappen van een fysieke tabel?.

Dit is handig voor gegevensbronnen die frequent worden bijgewerkt. Als er bijvoorbeeld een tabel is waarin tickergegevens worden opgeslagen die elke minuut worden bijgewerkt, kunt u de instelling Persistentietijd cache gebruiken om de ingangen voor die tabel elke 59 seconden op te schonen. Zie voor meer informatie: Cache en persistentietijd cache voor de opgegeven fysieke tabellen.