LGWR e ASYNC I/O

martedì 24 luglio 2007 alle 24:32 | Pubblicato su Diario | 3 commenti

Oggi voluto approfondire e capire meglio il contenuto di questo post di alcuni giorni fa di Kevin Closson. Egli, mi pare di poter dire in sintesi, afferma che è difficile che un sistema abbia bisogno di più processi DBWR (Data File Writer Process) o LGWR (Redo Log Writer Process), se mai fosse possibile avere più processi LGWR in un’istanza Oracle, per “scalare” ovvero sostenere un grande carico di lavoro. Questo post è stato ispirato a Kevin Closson da un’altro post, di Jonathan Lewis, che ha innescato una stimolante (per me) polemica.

Nel post Jonathan Lewis invalida in qualche modo le affermazioni di un articolo che si trova sul sito di Don Burleson (di cui non voglio riportare il link perchè effettivamente trovo tecnicamente poco interessante il sito). Effettivamente nell’articolo, forse nel maldestro tentativo di essere stringato, l’autore cerca di spiegare che la presenza in cima alla lista dei primi cinque eventi di un report di statspack degli eventi di wait “log file parallel write” e “log file sync” è un sintomo di un redo log buffer sottodimensionato. Giustamente (secondo me) Lewis obbietta che le scarne informazioni riportate fanno pensare più ad problema sul sistema di I/O che non riesce a scrivere abbastanza velocemente il contenuto del redo log buffer sugli online redo log. A me, leggendo il post e lo scarno articolo (definito da Don “quick tip”, per questo inevitabilmente breve) è venuto in mente una analogia con una situzione con cui mi sono trovato: un database con in cima agli eventi di wait l’ evento “db file sequential read” secondo la deduzione di Don avrei dovuto aumentare la Buffer Cache. Invece ovviamente il problema, oltre forse all’applicazione, era semplicemente il sistema di I/O (i dischi) non all’altezza.

La reazione di Donald Burleson al post di Jonathan Lewis è stata piuttosto scomposta, direi proprio sgradevole. Secondo me si è screditato più da solo con i suoi commenti più di quanto abbia fatto prima Lewis e poi Closson e poi ancora Howard Rogers. Infatti una contestazione che viene mossa da questi ultimi due è l’affermazione in un’altro articolo, sempre di Burleson, che da consigli su come dimensionare correttamente il redo log buffer e in cui maldestramente confonde LGWR I/O Slaves e LGWR processes. Sono d’accordo con Howard Rogers sul fatto che tali imprecisioni non possano essere giustificate come tentativo di rendere dei concetti compresibili anche a novizi. Secondo me si tratta di superficialità e approssimazione che non possono trovarsi in articoli che vengono presentati come consigli per DBA esperti (riporto cose che ha detto anche Howard Rogers come commento al post scatenante di Lewis)

Il concetto viene chiarito meglio da due commentatori più avanti, dopo gli sproloqui di Burleson. A me risulta che per definizione la scrittura del contenuto del redo log buffer sugli online redo log deve essere un’operazione “sincrona”, almeno nel caso questa scrittura sia scatenata da un commit (gli altri casi in cui questa scrittura scatta sono ogni 3 secondi o quando il redo log buffer è pieno per due terzi della sua capacità). Per “sincrona” intendo dire che quanto un utente del database fa un commit il processo LGWR provvede a svuotare il redo log buffer scrivendone il contenuto sugli online redo log, solo a conferma dell’avvenuta scrittura il commit restituisce il messaggio di successo dell’operazione. Per quello che è il ruolo dei REDO LOG è indispensabile che ci sia questa sincronia. Quindi come interlocutoriamente dice Alberto Dell’Era il funzionamento di LGWR in modalità Async I/O (che in mancanza di supporto da parte del sistema operativo può essere simulato con dei processi LGWR I/O Slaves) ha senso solo in cui ogni gruppo di REDO LOG consti di due o più copie di file uguali. Allora, come precisato anche nel link successivemente riportato da Alessandro Deledda, per parallelizzare la scrittura su tutti i membri dello stesso gruppo è utile avere il processo LGWR che lavora in modalità Async I/O o avere dei processi LGWR I/O Slaves.

A seguito di queste precisazioni anche un commentatore che inizialmente aveva difeso la posizione di Burleson si è ricreduto. A coronare il tutto sta il fatto che al posto di un articolo sul sito di Don in cui si approfondiva la discussione, articolo linkato anche da Kevin Closson nel suo posto oggi c’era una disgustosa pubblicità di una crocera-corso. Una cosa veramente disgustosa!

About these ads

3 commenti »

RSS feed dei commenti a questo articolo. TrackBack URI

  1. [...] Archivio ← LGWR e ASYNC I/O [...]

  2. è un pò datata ma l’informazione è senz’altro ben esposta e l’autore merita ;-)

    http://www.ixora.com.au/tips/tuning/redo_latches.htm

  3. Grazie Alessandro,
    l’articolo chiarisce almeno il meccanismo di base che dubbito sia cambiato molto da quando è stato scritto. Soprattutto mi ha chiarito il dubbio che ho esposto nel post succssivo su una frase di Kevin Closson


Rispondi

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...

Crea un sito o un blog gratuitamente presso WordPress.com. | The Pool Theme.
Entries e commenti feeds.

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.

Unisciti agli altri 70 follower

%d blogger cliccano Mi Piace per questo: