Quando apportare modifiche?

Question

Utilizzando Oracle 10g, a cui si accede tramite Perl DBI, ho una tabella con alcune decine di milioni di righe che vengono aggiornate alcune volte al secondo mentre vengono lette molto più frequentemente da un altro processo.

Presto la frequenza degli aggiornamenti aumenterà di un ordine di grandezza (forse due).Qualcuno ha suggerito che eseguire il commit di ogni N aggiornamenti anziché dopo ogni aggiornamento aiuterà le prestazioni.

Ho alcune domande:

• Sarà più veloce o più lento o dipende (si prevede di eseguire il benchmark in entrambe le direzioni non appena sarà possibile ottenere una simulazione decente del nuovo carico)
• Perché aiuterà/ostacolerà le prestazioni.
• Se "dipende...", da cosa?
• Se aiuta, qual è il miglior valore di N?
• Perché il mio DBA locale non può avere una risposta diretta e utile quando ne ho bisogno?
  (In realtà conosco la risposta a questa domanda) :-)

MODIFICARE:

@codeslave:Grazie, btw perdere modifiche non emesse non è un problema, non elimino i dati originali utilizzati per l'aggiornamento fino a quando non sono sicuro che va tutto bene, BTW Cleaning Lady ha scollegato il server, due volte :-)

Alcuni googling hanno dimostrato che potrebbe essere d'aiuto a causa di problemi relativi ai segmenti di rollback, ma non conosco ancora una regola empirica per ogni poche decine?centinaia?mille ?

@diciu:Grandi informazioni, lo esaminerò sicuramente.

Answer 1

Un commit fa sì che Oracle scriva materiale sul disco, ad es.nel file di registro di ripristino in modo che qualunque cosa abbia fatto la transazione in fase di commit possa essere recuperabile in caso di interruzione di corrente, ecc.La scrittura nel file è più lenta della scrittura in memoria, quindi un commit sarà più lento se eseguito per molte operazioni di seguito anziché per una serie di aggiornamenti uniti.

In Oracle 10g c'è un commit asincrono che lo rende molto più veloce ma meno affidabile: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS So per certo che, in uno scenario che ho visto in una determinata applicazione, la modifica del numero di aggiornamenti coalizzati da 5K a 50K lo rende più veloce di un ordine di grandezza (10 volte più veloce).

Answer 2

Ridurre la frequenza dei commit accelererà sicuramente le cose, tuttavia poiché leggi e scrivi frequentemente su questa tabella c'è il rischio che si verifichino blocchi.Solo tu puoi determinare la probabilità che gli stessi dati vengano aggiornati contemporaneamente.Se la possibilità che ciò accada è bassa, esegui il commit ogni 50 righe e monitora la situazione.Prova ed errore, temo :-)

Answer 3

Oltre a ridurre la frequenza di commit, dovresti anche considerare di eseguire aggiornamenti in blocco anziché singoli.

Answer 4

Se "non elimini i dati originali utilizzati per l'aggiornamento finché [sei] sicuro che tutto vada bene", allora perché non rimuovi tutti quei commit incrementali nel mezzo e non esegui il rollback se c'è un problema?Sembra che tu abbia effettivamente costruito un sistema di transazione sopra le transazioni.

Answer 5

@CodeSlave alle tue domande risponde @stevechol, se rimuovo TUTTI i commit incrementali ci saranno dei blocchi.Immagino che se non arriva niente di meglio seguirò il suo consiglio, sceglierò un numero casuale, monitorerò il carico e adeguerò di conseguenza.Durante l'applicazione di @diciu twaks.

PS:la transazione oltre alla transazione è semplicemente accidentale, ricevo i file utilizzati per gli aggiornamenti tramite FTP e invece di eliminarli immediatamente ho impostato un processo cron per eliminarli una settimana dopo (se nessuno che utilizza l'applicazione si è lamentato) ciò significa che se qualcosa va storto Ho una settimana per individuare gli errori.

Answer 6

Più veloce/più lento?

Probabilmente sarà un po' più veloce.Tuttavia, corri un rischio maggiore di imbatterti in situazioni di stallo, di perdere le modifiche non salvate nel caso in cui dovesse accadere qualcosa di catastrofico (la donna delle pulizie scollega il server), FUD, Fire, Brimstone, ecc.

Perché aiuterebbe?

Ovviamente meno operazioni di commit, il che a sua volta significa meno scritture su disco, ecc.

DBA e risposte dirette?

Se fosse facile, non ne avresti bisogno.