Slik bruker du hybridmodus mest effektivt:
Unngå bruk av beregning i to trinn i hybridmodus. Bruk løsningsrekkefølge i stedet.
Konverter lagrede medlemmer som ikke er på nivå 0, til dynamisk beregning når det er mulig.
Hvis konverteringen til medlemmer av dynamisk beregning påvirker løsningsrekkefølgen for avhengige former, kan det hende at du må justere rekkefølgen på dimensjonene for disposisjonen for å tilpasse løsningsrekkefølgen til innstillingene for den tidligere bunkeberegningsrekkefølgen og totrinnsberegningen.
Standard løsningsrekkefølge for kuber i hybridmodus ligner på beregningsrekkefølgen for blokklagringskuber, med noen forbedringer. Hvis du vil bruke en løsningsrekkefølge som ikke er standard, kan du angi en egendefinert løsningsrekkefølge for dimensjoner og medlemmer.
En dynamisk beregnet formel som er behandlet i gal løsningsrekkefølge, kan gjøre at det blir utført for mange formler av en spørring, noe som reduserer ytelsen. Når det er mulig, bør en dynamisk beregnet spredt formel ha en høyere løsningsrekkefølge enn hierarkisk aggregerte spredte dimensjoner.
I enkelte applikasjoner er dette ikke mulig. Det kommer av at det er nødvendig med en annen løsningsrekkefølge for at det skal bli mulig å få de riktige formelresultatene. En applikasjon med enheter og priser må for eksempel ha en salgsverdi som er utført før de spredte aggregeringene, hvis det skal være mulig å få riktige salgsverdier på de øvre nivåene.
Det kan være at du må justere konfigurasjonene for spredning eller tetthet for dimensjonene (gjelder bare for utnyttelse av blokklagringsmotoren i tilfeller der hybridmotoren ikke kan brukes).
Minimer om mulig blokkstørrelsen.
Essbase-administratorer kan bruke følgende verktøy til å overvåke og optimalisere spørringsytelsen i hybridmodus:
Hvis du vil begrense hvor mye minne som kan forbrukes av en enkelt spørring, bruker du konfigurasjonsinnstillingen MAXFORMULACACHESIZE.
Hvis kuben har komplekse medlemsformler med kryssdimensjonale operatorer og flere IF/ELSE-setninger, kan ytelsesproblemer være relatert til formelutførelse. Hvis det er mistanke om dette, kan du aktivere spørringsbehandling nedenfra og opp for formelberegning. Dette optimaliserer spørringstider ved å identifisere de nødvendige skjæringspunktene for beregning, og det gjør spørringstiden proporsjonal med inndatastørrelsen.
Hvis du vil utføre slike spørringsoptimaliseringer for versjon 21c, bruker du konfigurasjonsinnstillingen QUERYBOTTOMUP, i tillegg til beregningsfunksjonen @QUERYBOTTOMUP. For versjon 19c bruker du konfigurasjonsinnstillingen IGNORECONSTANTS med BOTTOMUP-syntaks, i tillegg til beregningsfunksjonen @NONEMPTYTUPLE.
Bruk spørringssporing til å overvåke spørringsytelsen og lete etter feil. Konfigurasjonsinnstillinger på flere applikasjonsnivåer er tilgjengelige, avhengig av brukstilfellet. Bruk QUERYTRACE til kortsiktig feilleting i en enkelt spørring du tenker kan være problematisk. Bruk TRACE_REPORT til statistikkinnsamling for spørringer som kjører samtidig (ideelt for feilleting i et utviklingsmiljø). Bruk LONGQUERYTIMETHRESHOLD i produksjonsmiljøer til å skrive ut statistikk til applikasjonens loggfil om spørringer som kjører i lengre tid enn det som er definert.