Oracle zaznamenáva vykonané transakcie v tzv. redo (požadované zmeny v datafiles). Je to takto sekvenčne zapísané rýchlejšie a teda bezpečnejšie pre dáta.
Redo má organizované súbory v skupinách, ak sa zápisom jeden log (skupina viacerých mux. kópií logu) zaplní, prepne sa zápis do ďalšej skupiny. Po zaplnení poslednej skupiny sa prepne opäť na prvú (cykluje).
Redo má organizované súbory v skupinách, ak sa zápisom jeden log (skupina viacerých mux. kópií logu) zaplní, prepne sa zápis do ďalšej skupiny. Po zaplnení poslednej skupiny sa prepne opäť na prvú (cykluje).
select l.group#, lf.member, l.bytes/1024/1024 mb, l.status, l.archived
from v$logfile lf, v$log l
where l.group# = lf.group#
order by 1, 2;
-------
1 /r01/oracle/DB1/redo/redo_001.rlg 100 CURRENT NO
2 /r01/oracle/DB1/redo/redo_002.rlg 100 UNUSED YES
3 /r01/oracle/DB1/redo/redo_003.rlg 100 INACTIVE YES
V prípade zapnutého archívneho módu DB sa pri každom prepnutí zaplnený redo súbor zároveň uloží do cesty log_archive_dest ako archívny log. Prípadne do cesty v db_recovery_file_dest, tzv. fast recovery area (FRA).
Logy odtiaľto číta RMAN pri zálohovaní, označí ich ako obsolete ak je podľa jeho nastavení spravený dostatočný počet záloh. Súbory tak môžu byť zmazané, ide teda o akési dočasné úložisko.
Ak však RMAN vypadne (napr. kvôli výpadku zálohovacieho HW), databáza pobeží len po dobu, kým nezaplní toto úložisko pre archívne logy, následné transakcie zastaví (tzv. archive stuck, DB vypisuje archiver error).
Povedzme, že chceme rátať s maximálnym výpadkom 2 dni. Ako správne nadimenzovať tento diskový priestor?
Select, ktorý sa dá jednoducho nájsť na internete (napr Burleson) zobrazí tabuľku s prepnutiami v jednotlivé hodiny (vidieť tak špičky), avšak nás zaujíma stĺpček TOTAL, kde je suma za deň.
-- AKO CASTO PREPNE ZA HODINU
SELECT TO_CHAR(first_time, 'MM/DD') ||' '|| TO_CHAR(first_time, ' Dy') DAY
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'00',1,0)) H00
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'01',1,0)) H01
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'02',1,0)) H02
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'03',1,0)) H03
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'04',1,0)) H04
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'05',1,0)) H05
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'06',1,0)) H06
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'07',1,0)) H07
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'08',1,0)) H08
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'09',1,0)) H09
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'10',1,0)) H10
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'11',1,0)) H11
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'12',1,0)) H12
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'13',1,0)) H13
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'14',1,0)) H14
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'15',1,0)) H15
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'16',1,0)) H16
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'17',1,0)) H17
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'18',1,0)) H18
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'19',1,0)) H19
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'20',1,0)) H20
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'21',1,0)) H21
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'22',1,0)) H22
,SUM(DECODE(TO_CHAR(first_time, 'HH24'),'23',1,0)) H23
,COUNT(*) TOTAL
FROM v$log_history where trunc(first_time) >= trunc(sysdate)-15
GROUP BY TO_CHAR(first_time, 'MM/DD') ||' '|| TO_CHAR(first_time, ' Dy')
order BY TO_CHAR(first_time, 'MM/DD') ||' '|| TO_CHAR(first_time, ' Dy');
-------------
09/09 Ne 29 20 21 21 21 22 26 24 24 23 24 23 24 24 24 24 24 24 24 25 33 31 34 38 607
09/10 Po 36 37 38 38 37 37 38 25 22 21 21 21 23 22 23 23 24 24 24 26 26 24 30 28 668
09/11 Ut 25 25 25 23 23 23 26 24 22 22 23 23 23 24 23 23 23 13 0 0 0 0 0 0 413
Tento počet (najväčší z nich, ak nejde o veľkú odchýlku) vynásobíme 2 (2 dni) a veľkosťou jedného redo. Získame tak kapacitu potrebnú na diskoch pre archívne logy databázy.
V mojom prípade maximum bolo 668 logov za deň, pri 500MB redo súboroch (pozrieť z tabuľky v$log) to je 668 * 2 * 0,5 = 668GB archívnych logov na 2 dni.
Po kontrole veľkosti filesystému môžeme v prípade FRA pridať veľkosť takto:
SQL> alter system set db_recovery_file_dest_size=670G scope=both;
Žiadne komentáre:
Zverejnenie komentára