ci sono differenze significative con oltre 500 milioni di tabelle di righe in Oracle?

Sono in un progettista di database in un ambiente di data warehouse. Sono abituato a gestire tabelle con un massimo di 1 milione di righe e ora sono di fronte a tabelle con oltre mezzo miliardo di righe. Ci sono differenze significative con gli strumenti nel "toolbox efficienza"? Posso fidarmi della mia precedente conoscenza di indici, partizioni e simili o alcuni di questi strumenti specifici sono più un ostacolo che un aiuto con dati così grandi? Qualche altro consiglio per gestire i tavoli?

(Ho già trovato un ottimo post su Aggiornamento di 700 milioni di righe sullo stesso valore )

I fondamenti dell'indicizzazione ecc. Funzionano tutti esattamente allo stesso modo, quindi a rigor di termini l'unica differenza è il costo di sbagliare!

Detto questo, ecco un elenco (non necessariamente completo) di cose da tenere a mente:

• È probabile che gli indici B-tree abbiano un livello aggiuntivo, quindi il costo per usarli è leggermente più alto. Tuttavia, in un DW dovresti usare gli indici bitmap (supponendo che tu abbia una versione enterprise)
• Ci vorrà molto più tempo per calcolare le statistiche per l'intera tabella, al punto che potrebbe non essere possibile nella normale finestra notturna. Questo può essere superato da
  • Usando un valore più piccolo estimate_percentquando si raccolgono le statistiche, viene campionato meno del tavolo.
  • Utilizzo della raccolta di statistiche incrementali (rilevante solo se si hanno indici globali su tabelle partizionate)
• Gli istogrammi per gli indici sono limitati a 254 bucket. Probabilmente più righe significano valori più distinti, il che significa che valori "quasi popolari" possono rappresentare un problema maggiore per i dati distorti.
• Le probabilità che l'intera tabella si adatti alla cache del buffer si avvicina a zero, il che significa che è più probabile che tu abbia più letture fisiche (disco). Il normale set di lavoro potrebbe anche essere troppo grande per essere memorizzato nella cache.
• Il partizionamento può essere tuo amico - se lo fai bene! Se di solito stai modificando e interrogando i dati su più partizioni, può costarti di più rispetto alle semplici tabelle.
• Le viste materializzate possono essere molto utili per ridurre il set di lavoro. ad es. se hai più di 10 anni di dati, ma la stragrande maggioranza delle query degli utenti sono solo in contrasto con gli ultimi 2 anni, la creazione di un MV limitato a questi dati può essere di grande aiuto.
• Maggiore è la base dati, minore è la probabilità che l'azienda (sia in grado di) finanziare un database di test che è un duplicato completo dell'ambiente live. Ciò rende più difficile riprodurre i problemi di prestazioni durante i test poiché le query lente potrebbero essere dovute alla scala e / o all'archiviazione fisica dei dati. Non puoi contare sull'essere in grado di estrapolare i risultati delle query da un DB di test molto più piccolo alle prestazioni corrispondenti in live.

Se non hai già familiarità con la lettura e la comprensione dei piani di esecuzione, passerei un po 'di tempo ad apprenderli: il tuo vincolo a un certo punto si imbatterà in problemi di prestazioni, quindi sapere come diagnosticare correttamente il problema diventerà più importante in quanto è più difficile aggiungere nuovi indicizza o apporta modifiche allo schema quando i conteggi delle righe sono maggiori.

La quantità ha una qualità tutta sua.

Quando si ha a che fare con tabelle di quella dimensione, aiuta a non pensare alla tabella dei fatti come a una tabella, ma a pensarla a livello di segmento o come una raccolta di tabelle discrete. (Essere abbastanza grandi da ricordare il partizionamento rolling-my-own con le viste delle partizioni aiuta.)

La carta di Scaling to Infinity di Tim Gorman è una risorsa inestimabile.