Prestazioni del database della vista rispetto alla nuova tabella

Question

Sto utilizzando un database Oracle che ha prestazioni lente a causa di join su alcune tabelle per ottenere risultati. Sto pensando di creare una nuova tabella che memorizzi alcuni di questi dati in modo che possano essere recuperati rapidamente senza dover eseguire i join. Un'altra alternativa è creare una vista per i join che sto eseguendo e quindi interrogare sempre la vista per i dati. Qual è il compromesso in termini di prestazioni tra l'utilizzo di una nuova tabella e la creazione di una vista? Ho immaginato che una vista avrebbe ancora bisogno di eseguire il join in modo che non offrisse le stesse prestazioni di un nuovo tavolo.

Informazioni su Oracle vista database è qui: - http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8004.htm - What is a View in Oracle?

Chiarimento in base alle risposte di seguito. Le query sono per lo più ottimizzate già, quindi non voglio fare l'ottimizzazione. Preferirei una nuova tabella o una vista materializzata, ma vorrei sapere quale potrebbe essere meglio. Sono interessato alle prestazioni. Scrivere più codice per mantenere la nuova tabella in sincronia con le vecchie tabelle non è un problema. Aggiungerò semplicemente le dichiarazioni di modifica ovunque siano state apportate modifiche alle vecchie tabelle. Non voglio usare una vista materializzata se è più lenta dell'aggiunta di una nuova tabella.

La differenza è se l'aggiornamento dei dati è più efficiente per la vista materializzata o per una nuova tabella. Per la nuova tabella, fondamentalmente aggiungerò le dichiarazioni di aggiornamento ovunque ci siano stati aggiornamenti alla vecchia tabella. Quindi, quando l'utente interroga la nuova tabella, i dati sono già lì (non è necessaria un'ulteriore elaborazione). Ma per una vista materializzata, se la vista si aggiorna automaticamente solo quando l'utente interroga la vista, allora potrebbe essere più lento.

Answer 1

Una vista è solo una query memorizzata quindi non ci dovrebbero essere differenze nelle prestazioni tra l'interrogazione di una vista e l'emissione di una query identica rispetto alle tabelle di base.

La creazione di una tabella separata può aumentare le prestazioni delle query ma viola la normalizzazione e quindi è necessario scrivere codice che mantenga la tabella in sincronia. Se è necessario che le query restituiscano il risultato corretto anziché un risultato approssimativo, ciò significa che le operazioni DML (inserimenti, aggiornamenti ed eliminazioni) saranno più lente per gestire la sincronizzazione dei dati. Questo potrebbe essere un compromesso appropriato se si tratta principalmente di un database di report, ma sarà molto meno appropriato in un ambiente OLTP in cui le prestazioni delle transazioni sono fondamentali.

Se si intende creare un tavolo, in genere suggerisco di creare un materialized view. Questo ha i vantaggi in termini di prestazioni di una tabella ma Oracle si occupa di mantenerlo sincronizzato in modo da non dover scrivere molto codice personalizzato per questo.

Ma non è affatto ovvio che materializzare i dati sia la soluzione adeguata in primo luogo. Sei sicuro di non aver semplicemente perso alcuni indici?

Answer 2

A materialized view potrebbe essere quello che stai cercando. Un normale view non esiste come tabella, fa semplicemente riferimento alle tabelle su cui è basato. Ma, come ha commentato Linutis, dovresti prima cercare di ottimizzare la tua query. Potresti aver bisogno di indici sulle colonne coinvolte nel join e statistiche raccolte sulle tabelle che stai utilizzando.

Answer 3

Le viste sono solo un wrapper per le query, le prestazioni dell'utilizzo di una vista sono uguali alle prestazioni dell'utilizzo di una query (se si ignora l'overhead di analisi delle query).

Quindi utilizzare una vista non aiuterà il problema, se si utilizzano molti join.Ma dopo tanta esperienza nell'ottimizzazione delle query in Oracle posso darti alcune note:

1. Utilizzare una sottoselezione (all'interno della clausola select) invece di unirsi quando è possibile; ci sono alcuni casi in cui questo non può essere fatto, o non è bene farlo, come ad esempio:
   • quando si utilizza inner join rimuovere alcuni record da set di risultati -
   • si desidera avere alcune condizioni su quelle colonne
   • si desidera ordinare su tali colonne.
2. Utilizzare union all invece di union dove può essere eseguito.
3. Usa coalesce quando è corretta, (anche usarlo su con il sub-select come parametri),
4. creare indici corretti (in base al piano di esecuzione)
5. Evitare di utilizzare memorizzati funzioni nelle clausole di unirsi e dove .

Queste sono le cose che mi sono venute in mente adesso. Spero che sarebbe di aiuto.