Per utilizzare la modalità ibrida nel modo più efficace, effettuare le operazioni riportate di seguito.
Evitare di utilizzare il calcolo a due passaggi in modalità ibrida. Utilizzare invece l'ordine di soluzione.
Convertire i membri memorizzati non di livello 0 in membri di calcolo dinamico, laddove fattibile.
Se la conversione in membri di calcolo dinamico influisce sull'ordine di soluzione per le formule dipendenti, potrebbe essere necessario modificare l'ordine delle dimensioni del profilo in modo da allineare l'ordine di soluzione con l'ordine di calcolo batch precedente e le impostazioni di calcolo a due passaggi.
L'ordine di soluzione per i cubi in modalità ibrida è simile all'ordine di calcolo dei cubi di memorizzazione a blocchi, con alcuni miglioramenti. Se si desidera utilizzare un ordine di soluzione non predefinito, è possibile impostarne uno personalizzato per le dimensioni e i membri.
Una formula calcolata in modo dinamico ed elaborata nell'ordine di soluzione errato può causare l'esecuzione di un numero eccessivo di formule da parte di una query, con il conseguente deterioramento delle prestazioni. Quando possibile, una formula sparsa calcolata in modo dinamico deve avere un ordine di soluzione superiore rispetto a quello delle dimensioni sparse aggregate in modo gerarchico.
In alcune applicazioni ciò non è possibile poiché è necessario un ordine di soluzione diverso per ottenere risultati della formula corretti. Ad esempio, per ottenere il valore di vendita corretto ai livelli superiori, è necessario che un'applicazione con unità e prezzi includa un valore di vendita eseguito prima delle aggregazioni sparse.
Potrebbe essere necessario modificare le configurazioni dense o sparse delle dimensioni (si applica solo all'utilizzo del motore di memorizzazione a blocchi nei casi in cui non è possibile utilizzare il motore ibrido).
Se possibile, ridurre la dimensione dei blocchi.
Per monitorare e ottimizzare le prestazioni delle query in modalità ibrida, gli amministratori di Essbase possono utilizzare gli strumenti riportati di seguito.
Per limitare la quantità di memoria che può essere utilizzata da una singola query, utilizzare l'impostazione di configurazione MAXFORMULACACHESIZE.
Se il cubo contiene formule membro complesse con operatori a dimensioni incrociate e più istruzioni IF/ELSE, è possibile che i problemi di prestazioni sia correlati all'esecuzione delle formule. In tal caso, è possibile attivare l'elaborazione della query bottom-up per il calcolo della formula. Ciò consente di ottimizzare i tempi della query identificando le intersezioni necessarie per il calcolo in modo che il tempo di esecuzione della query sia proporzionale alla dimensione dei dati di input.
Per effettuare queste ottimizzazioni della query per la release 21c, usare l'impostazione di configurazione QUERYBOTTOMUP e la funzione di calcolo @QUERYBOTTOMUP. Per la release 19c, usare l'impostazione di configurazione IGNORECONSTANTS con la sintassi BOTTOMUP e la funzione di calcolo @NONEMPTYTUPLE.
Utilizzare il trace delle query per monitorare ed eseguire il debug delle prestazioni delle query. Sono disponibili più impostazioni di configurazione a livello di applicazione, a seconda del caso d'uso. Utilizzare QUERYTRACE per il debug a breve termine di una singola query che si ritiene possa presentare dei problemi. Utilizzare TRACE_REPORT per la raccolta di statistiche sulle query eseguite contemporaneamente (ideale per l'esecuzione del debug in un ambiente di sviluppo) Utilizzare LONGQUERYTIMETHRESHOLD negli ambienti di produzione per visualizzare nel file di log dell'applicazione le statistiche relative a tutte le query con tempi di esecuzione più lunghi rispetto a quelli impostati.