Costo della query rispetto alla velocità di esecuzione + parallelismo

Question

Il mio dipartimento è stato recentemente rimproverato (graziosamente) dal nostro reparto IT per l'esecuzione di query con costi molto elevati sulla base del fatto che le nostre query hanno una reale possibilità di destabilizzazione e/o arresto anomalo del database. Nessuno di noi è DBA; Erano solo ricercatori che scrivono ed eseguono query sul database, e io sono probabilmente l'unico che abbia mai esaminato un piano di spiegazioni prima del rimprovero.

Ci è stato detto che i costi di query superiori a 100 dovrebbero essere molto rari e le query con costi superiori a 1000 non dovrebbero mai essere eseguite. I problemi che sto incontrando sono che il costo sembra non avere alcuna correlazione con il tempo di esecuzione, e sto perdendo produttività mentre cerco di ottimizzare le mie query.

Come esempio, ho una query che viene eseguita in meno di 5 secondi con un costo di 10844. Ho riscritto la query per utilizzare una vista che contiene la maggior parte delle informazioni di cui ho bisogno e ho ottenuto un costo inferiore a 109, ma la nuova query, che recupera gli stessi risultati, impiega 40 secondi per essere eseguita. Ho trovato una domanda qui con una possibile spiegazione:

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

Tale questione mi ha portato a suggerimenti parallelismo. Ho provato a utilizzare /*+ no_parallel*/ nella query 10884, ma il costo non è cambiato, né il tempo di esecuzione, quindi non sono sicuro che il parallelismo sia la spiegazione del tempo di esecuzione più veloce ma dei costi più elevati. Quindi, ho provato a utilizzare l'hint /*+ parallel(n)*/ e ho riscontrato che maggiore è il valore di n, minore è il costo della query. Nel caso della query 10844 relativa al costo, ho riscontrato che lo /*+ parallel(140)*/ ha portato il costo a 97, con un aumento molto minore del tempo di esecuzione.

Questo sembrava un ideale "barare" per soddisfare le esigenze che il nostro reparto IT di cui, ma poi ho letto questo:

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

L'articolo contiene questa frase:

Parallel l'esecuzione può consentire a una singola operazione di utilizzare tutte le risorse di sistema.

Quindi, le mie domande sono:

Perchè sono effetti mette più a dura prova le risorse del server utilizzando il /*+ parallel(n)*/ suggerimento con un altissimo grado di parallelismo, anche se sto abbassando il costo?

Presumendo nessun parallelismo, la velocità di esecuzione è una misura migliore delle risorse utilizzate rispetto al costo?

Answer 1

La regola che il DBA ti ha dato non ha molto senso. Preoccuparsi del costo segnalato per una query è raramente produttivo. Innanzitutto, non è possibile confrontare direttamente il costo di due query diverse: una query che ha un costo in milioni può essere eseguita molto rapidamente e consumare pochissime risorse di sistema un'altra query che ha un costo in centinaia può essere eseguita per ore e portare il server in ginocchio. In secondo luogo, il costo è una stima. Se l'ottimizzatore ha effettuato una stima accurata del costo, ciò implica che ha generato il piano di query ottimale, il che significa che è improbabile che sia possibile modificare la query per restituire gli stessi risultati utilizzando meno risorse . Se l'ottimizzatore ha effettuato una stima imprecisa del costo, ciò implica che ha generato un piano di query scadente, nel qual caso il costo riportato non avrebbe alcun rapporto con qualsiasi metrica utile che si sarebbe presentata. Nella maggior parte dei casi, le query che stai cercando di ottimizzare sono le query in cui l'ottimizzatore ha generato un piano di query errato perché ha stimato in modo errato il costo di vari passaggi.

Tricking l'ottimizzatore utilizzando i suggerimenti che possono o non possono realmente cambiare il piano di query (a seconda di come il parallelismo è configurato, per esempio) è molto improbabile per risolvere un problem-- è molto più probabile che a causare stime del ottimizzatore per essere meno precisi e rendere più probabile la scelta di un piano di query che consuma molte più risorse del necessario. Un suggerimento parallel con un elevato grado di parallelismo, ad esempio, direbbe a Oracle di ridurre drasticamente il costo di una scansione completa della tabella, il che rende più probabile che l'ottimizzatore lo sceglierebbe su una scansione dell'indice. Questo è raramente qualcosa che i tuoi DBA vorrebbe vedere.

Se stai cercando una singola metrica che ti dica se un piano di query è ragionevole, utilizzerei la quantità di I/O logico. L'I/O logico è correlato piuttosto bene con le prestazioni effettive della query e con la quantità di risorse consumate dalla query. Guardare al tempo di esecuzione può essere problematico perché varia in modo significativo in base a quali dati vengono memorizzati nella cache (motivo per cui le query spesso vengono eseguite molto più rapidamente la seconda volta che vengono eseguite) mentre l'I/O logico non cambia in base a quali dati sono nella cache. Inoltre, consente di ridimensionare le aspettative in base al numero di righe necessarie per elaborare le modifiche. Se stai scrivendo una query che deve aggregare dati da 1 milione di righe, ad esempio, questo dovrebbe consumare molte più risorse di una query che deve restituire 100 righe di dati da una tabella senza aggregazione. Se si sta osservando l'I/O logico, è possibile ridimensionare facilmente le proprie aspettative in base alle dimensioni del problema per capire quanto siano efficienti le query in modo realistico.

Entra Christian Antognini di "Troubleshooting Oracle Performance" (pagina 450), per esempio, si dà una regola empirica che è abbastanza ragionevole

• 5 letture logiche per ogni riga che viene restituita/aggregato è probabilmente molto buona
• 10 letture logiche per ogni riga che viene restituita/aggregato è probabilmente adeguata
• 20+ letture logiche per riga che viene restituito/aggregato è probabilmente inefficiente e ha bisogno di essere sintonizzato

Diversi sistemi con modelli di dati diversi possono meritare di modificare leggermente i bucket, ma è probabile che questi siano dei buoni punti di partenza.

La mia ipotesi è che se sei un ricercatore che non è uno sviluppatore, probabilmente stai eseguendo query che devono aggregare o recuperare set di dati relativamente grandi, almeno in confronto a quelli che gli sviluppatori di applicazioni scrivono comunemente. Se stai eseguendo la scansione di un milione di righe di dati per generare risultati aggregati, le tue query consumeranno molte più risorse rispetto a uno sviluppatore di applicazioni le cui query stanno leggendo o scrivendo una manciata di righe. Potresti scrivere query che sono altrettanto efficienti da un punto di vista I/O logico per riga, potresti semplicemente guardare molte più righe.

Se si stanno eseguendo query sul database di produzione in tempo reale, è probabile che ci si trovi in ​​una situazione in cui è opportuno iniziare a separare il carico di lavoro. La maggior parte delle organizzazioni raggiunge un punto in cui l'esecuzione di query di report sul database attivo inizia a creare problemi per il sistema di produzione. Una soluzione comune a questo tipo di problema è la creazione di un database di report separato alimentato dal sistema di produzione (tramite uno snapshot notturno o da un processo di replica in corso) in cui le query di report possono essere eseguite senza disturbare l'applicazione di produzione. Un'altra soluzione comune è utilizzare qualcosa come Oracle Resource Manager per limitare la quantità di risorse disponibili a un gruppo di utenti (in questo caso, gli sviluppatori di report) al fine di minimizzare l'impatto sugli utenti con priorità più alta (in questo caso, gli utenti della produzione sistema).