it-swarm.it

Con quale frequenza devono essere eseguite le statistiche del database Oracle?

Nella tua esperienza, quanto spesso dovrebbero essere eseguite le statistiche del database Oracle? Il nostro team di sviluppatori ha recentemente scoperto che le statistiche non erano state eseguite nella nostra scatola di produzione in oltre 2 mesi e mezzo. Mi sembra molto tempo, ma non sono un DBA.

21
user290

Al mio ultimo lavoro abbiamo fatto statistiche una volta alla settimana. Se ricordo bene, li abbiamo programmati il ​​giovedì sera, e venerdì gli amministratori del database sono stati molto attenti a monitorare le query più lunghe per qualsiasi cosa inaspettata. (Il venerdì è stato scelto perché spesso era solo dopo una release del codice, e tendeva a essere un giorno di traffico piuttosto basso.) Quando hanno visto una query errata, avrebbero trovato un piano di query migliore e lo avrebbero salvato in modo tale da non cambiare di nuovo in modo imprevisto . (Oracle ha gli strumenti per farlo automaticamente, gli dici la query per ottimizzare e lo fa).

Molte organizzazioni evitano di eseguire statistiche per paura di piani di query errati che spuntano inaspettatamente. Ma questo di solito significa che i loro piani di interrogazione peggiorano col passare del tempo. E quando eseguono le statistiche, incontrano una serie di problemi. Lo scramble risultante per risolvere questi problemi conferma i loro timori sui pericoli delle statistiche di corsa. Ma se eseguivano regolarmente le statistiche, utilizzavano gli strumenti di monitoraggio come previsto e risolvevano i problemi non appena si presentavano, avrebbero avuto meno mal di testa e non li avrebbero incontrati tutti contemporaneamente.

13
user11318

Ogni volta che i dati cambiano "significativamente".

Se un tavolo passa da 1 riga a 200 righe, si tratta di un cambiamento significativo. Quando un tavolo passa da 100.000 a 150.000 righe, questo non è un cambiamento terribilmente significativo. Quando una tabella passa da 1000 righe tutte con valori identici nella colonna X da 1000 a 1000 righe con valori quasi univoci nella colonna X, si tratta di una modifica significativa.

Le statistiche memorizzano le informazioni sul conteggio delle voci e sulle relative frequenze - cose che gli permetteranno di "indovinare" quante righe corrisponderanno a un determinato criterio. Quando indovina, l'ottimizzatore può scegliere un piano di query non ottimale very.

13
Jonathan Rupp

Poiché le statistiche di Oracle 11g vengono raccolte automaticamente per impostazione predefinita.

Due finestre di pianificazione sono predefinite all'installazione di Oracle Database:

  • WEEKNIGHT_WINDOW inizia alle 22:00 e termina alle 6:00 ogni lunedì fino a venerdì. 
  • WEEKEND_WINDOW copre giorni interi sabato e domenica.

Quando le statistiche sono state raccolte l'ultima volta?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

Stato della raccolta di statistiche automatizzate?

SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';

Gruppi di Windows?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

Orari della finestra?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

Raccogliere manualmente le statistiche del database in questo schema: 

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

Raccogliere manualmente le statistiche del database in tutti gli schemi!

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;
13
grokster

Quale versione Oracle stai usando? Controlla questa pagina che fa riferimento a Oracle 10:

http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

Dice:

L'approccio consigliato per la raccolta delle statistiche è consentire a Oracle di raccogliere automaticamente le statistiche. Oracle raccoglie automaticamente le statistiche su tutti gli oggetti del database e mantiene tali statistiche in un lavoro di manutenzione pianificato regolarmente.

5
David Medinets

Con la versione 10g e successiva di Oracle, le ottimizzazioni statistiche su tabelle e indici sono necessarie all'ottimizzatore per rendere "buona" la decisione del piano di esecuzione. La frequenza con la quale si raccolgono le statistiche è una chiamata complicata. Dipende dalla tua applicazione, dallo schema, dalla velocità dei dati e dalle pratiche commerciali. Alcune app di terze parti scritte per essere retrocompatibili con la versione precedente di Oracle non funzionano bene con il nuovo ottimizzatore. Quelle applicazioni richiedono che le tabelle non abbiano statistiche in modo che il db ricorra al piano di esecuzione della rule base. Ma in media, Oracle consiglia di raccogliere le statistiche su tabelle con statistiche obsolete. È possibile impostare le tabelle per il monitoraggio e controllare il loro stato e fare analizzare se/quando stantio. Spesso questo è sufficiente, a volte non lo è. Dipende davvero dal tuo database. Per il mio database abbiamo un insieme di OLTP tabelle che necessitano di raccolta di statistiche notturne per mantenere le prestazioni. Altre tabelle sono analizzate una volta alla settimana. Sul nostro grande database dw, analizziamo secondo necessità, poiché le tabelle sono troppo grandi per un'analisi regolare senza influire sul carico e sulle prestazioni complessive del db. Quindi la risposta corretta è, dipende dall'applicazione, dai cambiamenti di dati e dalle esigenze aziendali.

2
MichaelN

Quando gestivo un grande sistema di pianificazione multiutente supportato da Oracle, il nostro DBA aveva un lavoro settimanale che raccoglieva le statistiche. Inoltre, quando abbiamo apportato un cambiamento significativo che potrebbe influire o essere influenzato dalle statistiche, forzeremmo il lavoro a esaurire il ciclo per ottenere risultati.

2
Joe Skora

Assicurati di bilanciare il rischio che nuove statistiche causino modifiche indesiderate ai piani di query contro il rischio che le statistiche obsolete possano a loro volta causare la modifica dei piani di query. 

Immagina di avere un database di bug con una tabella ISSUE e una colonna CREATE_DATE dove i valori nella colonna aumentano più o meno monotonicamente. Ora, supponiamo che ci sia un istogramma in questa colonna che indica a Oracle che i valori per questa colonna sono distribuiti uniformemente tra il 1 ° gennaio 2008 e il 17 settembre 2008. Ciò consente all'ottimizzatore di stimare ragionevolmente il numero di righe che essere restituito se steste cercando tutti i problemi creati la settimana scorsa (cioè 7 - 13 settembre). Se l'applicazione continua a essere utilizzata e le statistiche non vengono mai aggiornate, tuttavia, questo istogramma sarà sempre meno preciso. Pertanto, l'ottimizzatore si aspetta che le query relative ai "problemi creati la scorsa settimana" siano sempre meno accurate nel tempo e potrebbero infine indurre Oracle a modificare negativamente il piano di query. 

1
Justin Cave

Generalmente non è consigliabile raccogliere statistiche così frequenti sull'intero database a meno che non si abbia una forte giustificazione per questo, come un inserimento di massa o un cambiamento di grandi quantità di dati che si verificano frequentemente sul database . La raccolta di statistiche sul database in questa frequenza può cambiare l'esecuzione delle query pianifica un nuovo piano di esecuzione scadente, la cosa può costarti molto tempo cercando di ottimizzare ogni query interessata dai nuovi piani poveri, ecco perché è necessario testare l'impatto della raccolta di nuove statistiche su un database di test o nel caso non hai il tempo o il potere dell'uomo per questo, almeno devi mantenere un piano di fallback eseguendo il backup delle statiche originali prima di crearne di nuove, quindi nel caso tu raccolga una nuova statistica e quindi le query non siano state eseguite come previsto, è possibile ripristinare facilmente le statistiche originali.

È disponibile uno script molto utile che consente di eseguire il backup delle statistiche originali e di acquisirne di nuove e di fornire il comando SQL che è possibile utilizzare per ripristinare le statiche originali nel caso in cui la cosa non andasse come previsto dopo la raccolta di nuove statistiche. Puoi trovare lo script in questo link: http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html

0
Chion

Nel caso di un sistema di tipo data warehouse, puoi considerare di non raccogliere statistiche e fare affidamento sul campionamento dinamico (impostazione optimizer_dynamic_sampling al livello 2 o superiore).

0
David Aldridge