Oracle DBA

A redo logok valtasa igencsak draga operacio. Miert? Tobbek kozott ilyenkor checkpoint (is) tortenik.

(DBWR, LGWR, valszeg az ARCH processek kemenyen dolgoznak)

Az egyik legaltalanosabb problema a redo logok tul kis merete, amely nagy dml terheles alatt a rendszert durvan lassithatja, mivel ha pl.: egy percen belul 1-2 logvaltas tortenik az minimum ugyanennyi checkpointot is jelent. A checkpoint pedig mindig eroforras igenyes muvelet.

ket szkriptet mutatok most be amivel a multbeli logvaltasokat (log switch -eket) elemezhetjuk:

az elso szkriptet ugy irtam meg es parametereztem, hogy csak hetkoznapokat monitorozzon ejfel es reggel 8 kozott (termeszetesen megvaltoztathatod :) ):

SELECT TRUNC (a.first_time), COUNT (*)
FROM
(SELECT b.first_time
FROM v$log_history b
WHERE TO_CHAR (b.first_time, 'Dy') IN ('Mon', 'Tue', 'Wed', 'Thu', 'Fri')) a
WHERE TO_NUMBER (TO_CHAR (a.first_time, 'HH24')) BETWEEN 0 AND 8 GROUP BY TRUNC (a.first_time)
ORDER BY 1 DESC

A masodik szkript hasonlo, viszont ez napon beluli eloszlast mutat, perces bontasban (intraday distribution): SELECT to_char(a.first_time,'YYYY/Mon/DD-HH24-MI') HOUR_OF_DAY,
COUNT (*)
FROM (SELECT b.first_time FROM v$log_history b) a where
trunc(a.first_time)=to_date('290109','DDMMYY')
GROUP BY to_char(a.first_time,'YYYY/Mon/DD-HH24-MI')
ORDER BY 2 desc Mindez szep es jo, mostmar tudjuk hogy orankent mikor van csucs redo log "gyartasban", akkor allitsuk be a meretet rendesen.

Az tapasztalatom az, hogy 5-15 perces logvaltas optimalis, persze minden a kornyezettol fugg.
Ha surun valtunk logot, belassul a rendszer, ha ritkan akkor instance crash eseten hosszabb a recovery (vagy tobb adatot vesztunk...). Mindenki dontse el mi a fontos(abb).

Nezzunk egy peldat, intraday distribution-ra (a 2. szkript kimenete): 2009/Jan/29-07-03 3
2009/Jan/29-07-09 3
2009/Jan/29-07-02 3
2009/Jan/29-07-04 2
2009/Jan/29-08-59 2
2009/Jan/29-20-10 2
2009/Jan/29-07-14 2
.
.
.

A fenti lista azt mutatja, hogy Jan 29-en reggel 7 ora utan volt a "peak period" logvaltas szempontjabol, 3 logvaltas/perc!! ... az sok.

Akkor most szamoljunk:

select distinct(bytes/1024/1024) REDO_MB from v$log;Ha itt nem 1 sort kaptal vissza eredmenykent, akkor ejnye-bejnye es javaslom gondolkozz el rajta miert nincsenek a redo logjaid egyforma meretre allitva :) Szoval a lenyeg, hogy igy megkaptuk a redo logok meretet MB-ban.

Ha a fenti peldat veszem alapul (csucsidoben 3 logvaltas) es az 5 perces logvaltasi intervallumot szeretnem elerni a csucsidoszakban akkor:

3 * 5 * [aktualis redo log meret MB] = uj redo log merete MB-ban

Pl.: az aktualis redo logok merete 50 MB akkor a kepletbe valo behelyettesites utan 3*5*50 = 750MB

Ez a gyalogos modszer. Ha lustak vagyunk vagy nem bizunk magunkban vegyuk igenybe a super-dooper Oracle advisory segitseget, lasd alabb ...

A fenti technika hatranya, hogy ha a DB DML terhelese nem egyenletes (az esetek nagy tobbsegeben ez igy van) akkor sajnos mivel a csucsra mereteztunk, lesznek idoszakok amikor a redo logok merete nem optimalis (peldany crash eseten sok adatot veszithetunk, vagy az instance recovery sokaing tart).

Hasznaljuk a fast_start_mttr_target parametert, amennyiben az instance osszeomlas utani ujraidulas kivant idotartamat szeretnenk meghatarozni.

... amennyibe a fast_start_mttr_target parametert nem 0 ertekre allitjuk, akkor igenybe vehetjuk az Oracle advisort is az optimalis redo log meret meghatarozasara:

 select optimal_logfile_size from v$instance_recovery; Ezzel azert csinjan banjunk, mert jobb felni mint ... szoval mindig ellenorizzuk terheles alatt hogyan muzsikal a DBnk.

Kellemes meretezes!