Partizioni trasparenti

Gli utenti che lavorano sul cubo di destinazione non devono sapere dove vengono memorizzati i dati, perché vi accedono come se facessero parte del cubo locale.

Figura 9-5 Partizioni trasparenti

Questa immagine illustra il modo in cui un utente nella destinazione dati della partizione trasparente visualizza i dati provenienti da tre origini dati.

Poiché i dati vengono recuperati direttamente dall'origine dati, gli utenti accedono alla versione più recente. Quando aggiornano i dati, gli aggiornamenti vengono scritti di nuovo nell'origine dati. Questo processo significa che altri utenti dell'origine dati e della destinazione dati hanno accesso immediato a tali aggiornamenti.

Con una partizione trasparente, gli utenti all'origine dati e alla destinazione dati potrebbero notare prestazioni più lente man mano che un maggior numero di utenti accede ai dati di origine.

Ad esempio, il DBA in TBC può utilizzare una partizione trasparente per calcolare ogni membro della dimensione Scenario su un computer separato. Questo processo riduce il tempo trascorso per il calcolo e fornisce agli utenti la stessa vista dei dati.

Utilizzare una partizione trasparente per raggiungere i seguenti obiettivi:

Mostra agli utenti la versione più recente dei dati
Consenti agli utenti nella destinazione dati di aggiornare i dati
Riduzione dello spazio su disco

Quando si crea una partizione trasparente, la porzione di dati nel cubo di destinazione viene cancellata in #MISSING, poiché si prevede che i dati vengano memorizzati nel cubo di origine. Rimane cancellato anche se si elimina la partizione.

Regole per le partizioni trasparenti

Le partizioni trasparenti devono seguire le regole riportate di seguito.

I dati vengono memorizzati nel cubo di origine. Il cubo di destinazione non memorizza né gestisce dati, ma funge da punto di accesso. Se l'accesso in scrittura è abilitato, gli utenti che accedono al cubo di destinazione possono aggiornare i dati nel cubo di origine.
Se l'origine e la destinazione sono cubi di memorizzazione di aggregazione (ASO, Aggregate Storage), l'unione dei dati dal cubo di destinazione al cubo di origine non è supportata.
Le aree trasparenti condivise dell'origine dati e dei profili di destinazione dati non devono essere identiche, ma è necessario essere in grado di mappare le dimensioni in esse contenute. È necessario indicare a Essbase come ogni dimensione e membro nell'origine dati viene mappato a ogni dimensione e membro nella destinazione dati.
I profili di origine dati e destinazione dati per le aree non condivise non devono essere mappabili, ma le associazioni di attributi devono essere identiche. Altrimenti, gli utenti possono ottenere risultati errati per alcuni recuperi. Ad esempio, se il prodotto 100-10-1010 è associato all'attributo Aroma dell'uva nell'origine, ma il prodotto 100-10-1010 non è associato all'uva nel target, il totale delle vendite per tutti gli aromi dell'uva a New York non è corretto.
La definizione della partizione deve contenere solo membri memorizzati. Non è possibile utilizzare dimensioni o membri attributo per definire una partizione trasparente. Ad esempio, la dimensione attributo Tipo di mercato, associata alla dimensione Mercato, ha membri Urban, Suburban e Rural. Impossibile definire una partizione in Urban, Suburban o Rural.
Se una cella viene mappata dall'origine dati a un database di memorizzazione di aggregazione come destinazione, anche tutti gli elementi dipendenti della cella devono essere mappati alla stessa definizione di partizione.
È possibile creare una partizione trasparente sopra una partizione replicata. In altre parole, è possibile creare una destinazione di partizione trasparente utilizzando un'origine di partizione replicata, come illustrato nella seguente figura:

Figura 9-6 Partizione trasparente valida
Come illustrato di seguito, non è possibile creare una partizione trasparente su più altre partizioni. In altre parole, non è possibile creare una destinazione di partizione trasparente da più origini perché ogni cella di un database deve essere recuperata da una sola posizione, ovvero il disco locale o un disco remoto.

Figura 9-7 Partizione trasparente non valida
Considerare attentamente le formule assegnate ai membri nell'origine dati e nella destinazione dati.

Vantaggi delle partizioni trasparenti

Le partizioni trasparenti possono risolvere molti problemi di database, ma le partizioni trasparenti non sono sempre il tipo di partizione ideale.

Hai bisogno di meno spazio su disco, perché stai memorizzando i dati in un database.

I dati a cui si accede dalla destinazione dati sono sempre la versione più recente.

Quando l'utente aggiorna i dati nell'origine dati, Essbase apporta tali modifiche nella destinazione dati.

I singoli database sono più piccoli, quindi possono essere calcolati più rapidamente.

La distribuzione dei dati è invisibile all'utente finale e agli strumenti dell'utente finale.

È possibile caricare i dati dall'origine dati o dalla destinazione dati.

Svantaggi delle partizioni trasparenti

Se i seguenti svantaggi sono troppo gravi, prendere in considerazione l'utilizzo di partizioni replicate o federate.

Le partizioni trasparenti aumentano l'attività di rete, con conseguente rallentamento dei tempi di recupero per gli utenti.

Poiché più utenti accedono ai dati di origine, il tempo di recupero potrebbe essere più lento.

Se il cubo di origine non riesce, gli utenti di origine e destinazione sono interessati. Pertanto, la rete e il cubo di origine devono essere disponibili ogni volta che gli utenti connessi all'origine o alla destinazione ne hanno bisogno.

È possibile eseguire alcune operazioni amministrative solo sui dati locali. Ad esempio, se si archivia il cubo di destinazione, Essbase archivia solo il cubo di destinazione e non quello di origine. Le operazioni amministrative riportate di seguito funzionano solo sui dati locali nei database di storage a blocchi.

comando calcolo CLEARDATA
Comando di calcolo DATACOPY
Comando EXPORT
comando VALIDATE
Comandi BEGINARCHIVE ed ENDARCHIVE

Quando si esegue un calcolo su una partizione trasparente, Essbase esegue il calcolo utilizzando i valori correnti dei dati locali e delle persone a carico trasparenti. Essbase non ricalcola le persone a carico trasparenti, poiché i contorni per l'origine e la destinazione possono essere talmente diversi che tale calcolo non è accurato. Per calcolare tutte le partizioni, eseguire un comando CALC ALL per ogni singola partizione, quindi eseguire un comando CALC ALL al livello superiore utilizzando i nuovi valori per ciascuna partizione.

Si consideri un esempio in cui:

Il profilo del cubo di destinazione contiene una dimensione Mercato con membri Est, Ovest, Sud e Centrale
Il profilo del cubo di origine contiene una dimensione orientale con membri di New York e New Jersey

Se si è tentato di calcolare il cubo di destinazione, si suppone che Est fosse un membro di livello 0. Nel cubo di origine, tuttavia, East è derivato dall'aggiunta di New York e New Jersey. Qualsiasi calcolo al target, tuttavia, non conoscerebbe queste informazioni e non potrebbe riflettere le modifiche apportate a New York e New Jersey nell'origine. Per eseguire un calcolo accurato, calcolare quindi Est nell'origine e quindi calcolare il target.

Le formule assegnate ai membri nel cubo di origine possono produrre risultati calcolati non coerenti con le formule o i consolidamenti definiti nel cubo di destinazione e viceversa.

Considerazioni sulle prestazioni per le partizioni trasparenti

Per migliorare le prestazioni delle partizioni trasparenti, prendere in considerazione le linee guida riportate di seguito durante la creazione della partizione.

Il partizionamento lungo dimensioni dense può rallentare notevolmente le prestazioni, perché le dimensioni dense vengono utilizzate per determinare la struttura e il contenuto dei blocchi di dati.

Per migliorare le prestazioni, includere una o più dimensioni sparse nella definizione dell'area in modo che il numero di blocchi richiesti sia limitato alle combinazioni con i membri sparsi.
Il basamento di partizioni trasparenti sui valori degli attributi di una dimensione può aumentare il tempo di recupero, poiché gli attributi sono associati a dimensioni sparse. In questi casi, il partizionamento a un livello superiore al livello associato agli attributi migliora il tempo di recupero. Ad esempio, nella dimensione Prodotto del database Sample.Basic, se gli attributi figlio 100-10, 200-10 e 300-10 (livello 0) sono associati agli attributi, partizionare i relativi elementi padre 100, 200 e 300 (livello 1) per migliorare le prestazioni di recupero.
Il caricamento dei dati nel cubo di origine dal cubo di destinazione può rallentare notevolmente le prestazioni. Se possibile, caricare i dati nell'origine dati localmente.
Il tempo di recupero è più lento perché gli utenti accedono ai dati tramite la rete.
Quando la destinazione è una partizione trasparente, considerare la possibilità di utilizzare le impostazioni di configurazione riportate di seguito.
- Per le richieste inviate da un cubo di origine a un cubo di destinazione della partizione trasparente, è possibile registrare i tempi di risposta delle transazioni utilizzando l'impostazione di configurazione ENABLE_DIAG_TRANSPARENT_PARTITION. La registrazione di questi messaggi è utile durante la risoluzione dei problemi relativi ai tempi di risposta troppo lenti.
- Quando la destinazione della partizione trasparente è un cubo di memorizzazione di aggregazione (ASO), è possibile specificare la dimensione massima della griglia richieste e della griglia risposte utilizzando le impostazioni di configurazione MAX_REQUEST_GRID_SIZE e MAX_RESPONSE_GRID_SIZE.
Il partizionamento delle dimensioni di base può rallentare notevolmente le prestazioni.

Calcolo delle partizioni trasparenti

Quando si calcolano dati locali che dipendono da dati remoti, Essbase deve utilizzare il calcolo bottom-up. Assicurarsi di utilizzare una cache della calcolatrice ottimizzata nel cubo di destinazione. Fare riferimento alla sezione Dimensioni della cache della calcolatrice.

Quando si esegue un calcolo su una partizione trasparente, Essbase esegue il calcolo utilizzando i valori correnti dei dati locali e delle persone a carico trasparenti. Quando si calcolano dati locali che dipendono da dati remoti, Essbase esegue un calcolo bottom-up. Il calcolo bottom-up può essere eseguito solo se la cache della calcolatrice nel database di destinazione viene utilizzata correttamente. Fare riferimento a Calcolo bottom-up e top-down.

L'aumento della memoria assegnata alla cache della calcolatrice migliora notevolmente le prestazioni di calcolo con partizioni trasparenti. Quando viene avviato un calcolo, un messaggio nel file di log dell'applicazione indica se la cache della calcolatrice è abilitata o disabilitata nel database di destinazione. L'utilizzo della cache della calcolatrice nel database di destinazione riduce il numero di blocchi richiesti dall'origine dati durante il calcolo. La riduzione dei blocchi richiesti, a sua volta, riduce il traffico di rete generato dal trasferimento dei blocchi attraverso la rete.

Prestazioni calcolo partizione trasparente

Il calcolo dei dati sulla destinazione di una partizione trasparente può rallentare le prestazioni quando Essbase deve recuperare i blocchi dipendenti dalla rete dall'origine prima di eseguire il calcolo. Per ottimizzare i calcoli trasparenti, utilizzare Calcolo dinamico, gestire la cache della calcolatrice, evitare le formule dall'alto verso il basso ed evitare formule complesse nei membri che definiscono le aree.

Le prestazioni con calcoli trasparenti possono anche rallentare se Essbase deve eseguire un calcolo dall'alto verso il basso su qualsiasi parte della destinazione dati contenente formule membro dall'alto verso il basso. Quando la destinazione dati non contiene formule membro top-down, Essbase può eseguire un calcolo bottom-up sulla destinazione dati, che risulta molto più veloce.

Quando Essbase esegue il calcolo sul cubo di origine, può sempre eseguire un calcolo bottom-up.

Prendere in considerazione l'utilizzo di queste alternative di calcolo:

Se si è assolutamente certi che uno script di calcolo della partizione di destinazione non implichi l'accesso ai dati remoti, è possibile utilizzare il comando di calcolo SET REMOTECALC OFF nello script di calcolo per interrompere gli sforzi di recupero dalla partizione di origine.
Implementare i membri di Calcolo dinamico come padri dei dati trasparenti in modo che i dati vengano calcolati in tempo reale quando vengono recuperati. Questo processo riduce i tempi di elaborazione batch. Essbase esegue il calcolo solo quando gli utenti lo richiedono.
Implementa un livello replicato tra i dati trasparenti di basso livello e i dati locali di alto livello.

Considera queste strategie di performance:

Mantenere la partizione completamente all'interno dell'area cache della calcolatrice, il che significa che qualsiasi membro sparso nella definizione della partizione deve essere contenuto nella cache della calcolatrice. Ad esempio, nel cubo Sample Basic, se una definizione di partizione include @IDESC(East), tutti i discendenti di East devono trovarsi nella cache della calcolatrice.
Abilitare la cache della calcolatrice e assegnarvi una quantità di memoria sufficiente.
Non utilizzare formule complesse su membri che definiscono la partizione. Ad esempio, in Sample Basic, l'assegnazione di una formula complessa a New York o New Jersey (entrambi figli di East) obbliga Essbase a utilizzare il metodo di calcolo dall'alto verso il basso.

Partizioni trasparenti e formule membro

Se i profili della destinazione dati e dell'origine dati sono identici, ad eccezione di formule membro diverse, assicurarsi che la definizione della partizione produca i risultati del calcolo desiderati.

Si supponga, ad esempio, che i profili di origine dati e destinazione dati contengano una dimensione Mercato con membri Nord e Sud e figli di Nord e Sud. Nell'obiettivo dati, Market viene calcolato in base ai dati per i membri del Nord e del Sud (e i loro figli) nell'origine dati. Se uno qualsiasi di questi membri nell'origine dati contiene formule membro, queste vengono calcolate influendo sul valore calcolato di Market nella destinazione dati. Questi risultati possono essere diversi dal modo in cui il membro Market viene calcolato dai membri North e South sul target di dati, dove queste formule potrebbero non esistere.

Assicurarsi che tutte le formule assegnate ai membri nell'origine dati e nella destinazione dati producano i risultati desiderati.

Partizioni trasparenti e utilizzo della porta

Una porta viene utilizzata per ogni combinazione utente e macchina univoca. Se un utente definisce diverse partizioni trasparenti su un server, utilizzando lo stesso nome utente, viene occupata una sola porta.

In una partizione trasparente, quando un utente (user1) esegue il drilling in un'area della destinazione che accede ai dati di origine, user1 utilizza il nome utente dichiarato nella definizione della partizione (utente della partizione) per accedere ai dati dal database di origine. Questo accesso causa l'uso di una porta aggiuntiva poiché diversi utenti (utente utente1 e utente della partizione) si connettono all'applicazione.

Se un secondo utente (user2) si connette al database di destinazione ed esegue il drilling verso il basso per accedere ai dati di origine, user2 utilizza anche il nome utente dichiarato nella definizione della partizione (utente della partizione). Poiché l'utente della partizione è già connesso al database di origine, non è necessaria una porta aggiuntiva per l'utente della partizione, purché user2 acceda allo stesso database di origine.