In un geodatabase con versione, che impatto hanno le tabelle delta e l'albero di stato sulle prestazioni delle query?

Abbiamo un geodatabase arcsde con versione (arcgis 9.3.1 su Oracle 10g) con un modello di dati abbastanza complesso che include circa 100 featureclass e tabelle non spaziali, una rete geometrica e molte classi di relazione.

I dati vengono modificati quotidianamente da 5 o 6 utenti di arcmap utilizzando il controllo delle versioni sde. Inoltre, le versioni vengono create da servizi automatici che si interfacciano con altri sistemi aziendali per eseguire modifiche nel geodatabase. Le prestazioni delle query degenerano notevolmente nel corso della giornata, quindi abbiamo implementato uno script notturno per ottenere un impacco completo. In occasioni in cui viene eseguito un numero relativamente elevato di modifiche, il sistema può diventare inutilizzabile fino a dopo un impacco completo.

È stato suggerito che l'oracolo, come configurato, non può elaborare piani di esecuzione decenti di fronte a queste tabelle delta volatili. È una spiegazione ragionevole? Quale approccio dovrebbe essere adottato per risolverlo?

Aggiornamento in risposta ai commenti

• Alla fine della giornata, l'albero di stato è molto lineare, con solo una piccola ramificazione.
• Comprimiamo di notte (ottieni una compressione completa eliminando tutte le versioni).
• Le tabelle aziendali vengono analizzate regolarmente.
• Le tabelle Delta non vengono analizzate. Sono bloccati (tentativo di analizzare l'errore di restituzione "Le statistiche dell'oggetto ORA-20005 sono bloccate"). Né sono le tabelle volatili nello schema sde - STATES, STATE_LINEAGES.

Le tabelle delta e l'albero degli stati hanno un impatto diretto sulle prestazioni delle query.

Innanzitutto, è necessario comprendere il controllo delle versioni; Ho fatto una breve spiegazione della relazione dell'albero di stato e delle etichette di versione in una risposta diversa . Penso che ti aiuterebbe a superarlo.

Dopo aver letto quella risposta, è quindi possibile rendersi conto di come un ramo ID stato lungo (dalla radice all'id stato indicato da un'etichetta avrebbe un impatto sulle prestazioni. Perché? Perché si hanno join più complessi per ricreare la vista "corrente" della versione. Poiché l'impacco sta tagliando l'albero, i join interni diventano più facili da elaborare dal db sottostante e le sessioni ArcMap diventano più veloci.

Dai un'occhiata al documento Flussi di lavoro versioning di ESRI che ti insegnerà come mantenere l'albero dello stato della versione sotto controllo. Utilizzare GDBT per esaminare l'albero degli stati prima e dopo, in modo da poter vedere come un buon flusso di lavoro influisce sull'albero.

In secondo luogo, se riesci a cavartela senza dover utilizzare la rete geometrica per la maggior parte dei tuoi casi d'uso, allora fallo. Esso sarà rallentare i FeatureClasses che sono coinvolti perché utilizza messaggistica complessa per ogni chiamata Row :: deposito (al contrario solo memorizzare la riga nella tabella ed essere fatto con esso).

Per aggiornare le statistiche, utilizzare la funzione Analizza degli strumenti di gestione dei dati (contrassegnarli tutti). Saprà come gestire le tabelle delta (e qualsiasi altra tabella) necessarie.

[Il primo post si scusa: questo è pensato per essere un commento non una risposta definitiva.] Se hai versioni di modifica relativamente vecchie e che non sono state pubblicate, dovrebbero essere eliminate, postate o riconciliate. Una vecchia versione non riconciliata mantiene una vecchia visualizzazione predefinita, che impedisce la compressione nelle tabelle di base dei record delta appartenenti a versioni più recenti. Può esserci un numero enorme di questi record delta non compressi aggiunti a una versione precedente e le prestazioni ne risentono perché tutte le versioni sono viste sulle tabelle delta e di base. Le prestazioni del sistema sono correlate al numero di modifiche dall'ultima riconciliazione (o creazione) di ogni versione. Quindi in breve; se ci sono versioni che non è possibile pubblicare, riconciliarle regolarmente e comprimere.