12. 9. 2018

Oracle - kapacita pre archívne logy

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

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