LGWR e ASYNC I/O, precisazione

martedì 24 luglio 2007 alle 24:41 | Pubblicato su Diario | 2 commenti

Nel mio post precedente, fra le altre cose ho anche parlato di ciò che ho indicato nel titolo, del processo LGWR (Redo Log Writer Process) e del suo funzionamento in modalità Async I/O. Nel spiegarmi non sono stato dettagliato, però Kevin Closson, in un suo post , di qualche giorno fa, ma che ho letto attentamente solo poco fa, spiega molto bene alcune cose. Egli in effetti conferma parzialmente quello che ho affermato, cioè che il funzionamento in modalità Async I/O di LGWR ha senso nel caso di più copie di redo log file per gruppo; ma c’è anche un’altro caso in cui viene utilizzata questa modalità: nel caso la dimensione del redo log buffer da salvare su disco sia superiore alla dimensione massima (dipendente dalla piattaforma) di un singolo blocco di scrittura, allora LGWR fa due o più richieste (asincrone) di scrittura, per poi mettersi in attesa delle conferme di avvenuta scrittura.

Kevin Closson sottolinea come tutto sommato le attività da compiere da LGWR siano poche e semplici, soprattutto paragonate a quelle di DBWR. Nel seguito del post Closson descrive cosa può accadare mentre un processo è in attesa dell’evento “Log File Sync” (LFS). C’è un punto della descrizione che non ho capito bene, ma che non ho il coraggio di chiedere a Kevin, si tratta della fase iniziale del paragrafo intitolato proprio “Log File Sync”:

When a foreground process commits changes to the database, it allocates space in the redo buffer and copies the redo information into the buffer-protected either by the redo allocation latch itself or a redo copy latch. ”

Non ho ben capito cosa significa che al momento del commit il processo alloca spazio nel redo buffer ne dove lo copia. Si tratta di un dettaglio molto tecnico, ma io sapevo (o meglio credevo) che per ogni statement che modifica dati, e quindi genera redo, le informazioni di redo vengono scritte come record sul redo buffer, al commit viene scritto un record di commit e viene innescato il riversamento del redo log buffer sugli online redo log.

In ogni caso Kevin Closson spiega, e dimostra, come il tempo di attesa sull’evento “Log File Sync” in certe condizioni possa essere perlopiù tempo di “starvation” piuttosto che il tempo di I/O. Cioè quando LGWR fa le chiamate di sistema (in modalità kernel) necessarie a svolgere le sue funzioni, come ad esempio la richiesta di scrittura asincrona, lo schedulatore dei processi del sistema operativo può mettere in attesa LGWR e passare in esecuzione un’altro processo.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao Cristian

    Un piccolo commento riguardante il tuo problema di comprensione…

    Devi pensare che più processi possono scrivere contemporaneamente nel redo buffer. Quando un processo deve scriverci qualcosa riserva (allocca) una parte di memoria nel redo buffer. Da notare che il processo sa esattamente quanta memoria gli occorre perché i change vector della modifica, o del commit, so già stati preparati. L’allocazione e la copia sono poi protetti dai due latch citati. Quindi non vedo problemi con la descrizione che tu hai fatto dell’utilizzo del redo buffer.

    Ho fatto un po’ di luce o è peggio di prima?

    Chris

  2. Wow! quando stamattina ho visto la mail non ci potevo credere, allora sono andato a rovistare fra i miei libri e quando ho visto sul libro di Jonathan Lewis che non ricordavo male mi è quasi venuto un colpo! Tu sei il Christian Antognini che insieme a Wolfgang Breitling è stato “Technical Rewiever” del libro “Cost Based Oracle Fundamentals” di Jonathan Lewis, nonché membro della OakTable!!!
    Mi ci è voluto un po’ per riprendermi e rileggere attentamente quanto mi hai scritto. Si aiuta a far chiarezza, devo dire che al riguardo ho letto anche quanto scritto al link (http://www.ixora.com.au/tips/tuning/redo_latches.htm) suggerito da Alessandro al mio post precedente. In effetti Kevin si è riferito alla fase di Commit, che innesca anche LGWR, ma la fase di scrittura sul redo log buffer in sostanza, nella modalità che tu hai spiegato, avviene ad ogni singolo statement. Grazie, ora mi è tutto molto più chiaro.


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: