cum să verificați dimensiunea jurnalului de arhivă
în acest post, voi vorbi despre următoarele 3 subiecte.
- cum se definește dimensiunea jurnalului de arhivă?
- toate jurnalele de arhivă au aceeași dimensiune?
- cum să verificați dimensiunea jurnalului de arhivă?
A. Cum se definește dimensiunea jurnalului de arhivă?
înainte de a determina dimensiunea jurnalului arhivat, trebuie să știți că jurnalele arhivate sunt derivate din comutarea jurnalelor de refacere online. Ceea ce înseamnă că jurnalele arhivate sunt retrase și copiate jurnalele de refacere online. Cu alte cuvinte, Nu determinați dimensiunea jurnalului arhivat, de fapt determinați dimensiunea jurnalului de refacere online.
Define Mean Time To Recover (MTTR)
dar acum întrebarea este: cum să setați o dimensiune adecvată și optimă pentru jurnalele de refacere online? Există un răspuns simplu pentru noi. Dacă baza dvs. de date este Oracle 10g mai departe, atunci puteți obține o valoare optimă din configurația curentă a instanței.
în primul rând, trebuie să vă asigurați că FAST_START_MTTR_TARGET a fost setat la o altă valoare decât zero.
SQL> show parameter fast_start_mttr_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 1800
verificați dimensiunea optimă a Jurnalului de refacere
dacă ați setat FAST_START_MTTR_TARGET, adică. 1800 secunde în acest caz, atunci puteți obține o valoare consultativă pentru optimizarea dimensiunii fișierului jurnal prin această interogare.
SQL> select target_mttr, estimated_mttr, optimal_logfile_size from v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE
----------- -------------- --------------------
146 21 1469
după cum puteți vedea, a treia coloană OPTIMAL_LOGFILE_SIZE este răspunsul. Oracle vă recomandă să setați dimensiunea jurnalului de refacere la 1469 MB.
apoi, s-ar putea să fie nevoie să redimensionăm jurnalele de refacere pentru a ne conforma dimensiunii recomandate.
B. Toate jurnalele de arhivă au aceeași dimensiune?
în mare parte, jurnalele arhivate au aceeași dimensiune, dar ar putea fi afectate de următorii factori.
toate jurnalele refac definite ca fiind de aceeași dimensiune?
deși ar trebui să definim toate grupurile de jurnale redo și membrii ca fiind de aceeași dimensiune, este posibil să vedeți dimensiuni diferite între jurnalele redo sunt definite în câteva baze de date. De obicei, jurnalele de refacere mai mari sunt adăugate după crearea bazei de date. De aceea am văzut jurnale arhivate de dimensiuni diferite.
ați setat vreodată intervalul de comutare a jurnalului?
Comutarea jurnalului se poate face la un interval fix prin setarea parametrului de inițializare ARCHIVE_LAG_TARGET pentru a vă ajuta să controlați frecvența de arhivare.
dacă parametrul este setat altul decât valoarea implicită (0, dezactivat), unele comutări de jurnal vor avea loc înainte de completarea jurnalelor de refacere. Astfel de jurnale de refacere prematură fac jurnale arhivate de dimensiuni diferite.
RMAN Backup
pe lângă setarea intervalului de comutare a jurnalului, realizarea unei copii de rezervă a bazei de date cu jurnalele arhivate de RMAN va declanșa comutarea jurnalului. De exemplu, am dori să avem o copie de rezervă completă autonomă ca aceasta:
RMAN> backup database plus archivelog;
Starting backup at 27-JUN-16
current log archived
...
Starting backup at 27-JUN-16
current log archived
...
după cum puteți vedea, 2 jurnale de refacere au fost arhivate de RMAN, înainte și după copia de rezervă completă. Ele sunt mai mici decât dimensiunea definită.
C. Cum se verifică dimensiunea jurnalului de arhivă?
acum, să revenim la subiectul nostru principal, cum să verificăm dimensiunea jurnalului de arhivă în baza de date?
dimensiunea fiecărui jurnal arhivat
pentru a vedea dimensiunea fiecărui jurnal arhivat, interogăm V$ARCHIVED_LOG:
SQL> column name format a50;
SQL> column "Size (MB)" format 9999.999;
SQL> select sequence#, name, blocks*block_size/1024/1024 "Size (MB)" from v$archived_log where status = 'A' and standby_dest = 'NO' and completion_time > sysdate-1;
SEQUENCE# NAME Size (MB)
---------- -------------------------------------------------- ---------
175398 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175398.arc 1023.999
175399 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175399.arc 1023.999
175400 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175400.arc 749.232
175401 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175401.arc 43.875
175402 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175402.arc 727.369
175403 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175403.arc 6.957
175404 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175404.arc 1023.993
175405 /oradata/FRA/ORCL/ARCH/ERPAPP1_1_175405.arc 1023.999
...
dimensiunea fiecărui jurnal de arhivă poate fi calculată din înmulțirea blocurilor cu coloana BLOCK_SIZE. În plus, am calculat doar jurnalele arhivate care sunt finalizate în 24 de ore și disponibile în baza de date primară.
după cum puteți vedea, nu toate jurnalele de arhivă au aceeași dimensiune, majoritatea jurnalelor arhivate sunt în 1024 MB (adică 1 GB).
dimensiunea tuturor jurnalelor arhivate
toate disponibilitățile
pentru a vedea dimensiunea totală a jurnalelor arhivate disponibile în serverul de baze de date primare, putem face acest lucru:
SQL> sselect sum(blocks*block_size)/1024/1024/1024 "Total Size (GB)" from v$archived_log where status = 'A' and standby_dest = 'NO';
Total Size (GB)
---------------
436.632
după cum putem vedea, avem peste 400 GB de jurnale arhivate, ar trebui să le ștergem mai agresiv de acum înainte.
Ultimele 24 de ore
pentru a rezuma toate dimensiunile jurnalului arhivat disponibile în ultimele 24 de ore în serverul bazei de date primare, putem face acest lucru:
SQL> column "Total Size (GB)" format 9999.999;
SQL> select sum(blocks*block_size)/1024/1024/1024 "Total Size (GB)" from v$archived_log where status = 'A' and standby_dest = 'NO' and completion_time > sysdate-1;
Total Size (GB)
---------------
101.828
am adăugat un filtru pentru a limita intervalul de timp al jurnalelor arhivate.