januar 25, 2022

Sådan kontrolleres Arkivlogstørrelse

i dette indlæg vil jeg tale om følgende 3 emner.

  1. Hvordan defineres Arkivlogstørrelse?
  2. er alle arkivlogfiler af samme størrelse?
  3. Sådan kontrolleres Arkivlogstørrelse?

A. Hvordan defineres Arkivlogstørrelse?

før du bestemmer arkiveret logstørrelse, skal du vide, at arkiverede logfiler stammer fra online redo logs skift. Hvilket betyder, arkiverede logfiler er pensioneret og kopieret online redo logs. Med andre ord, du bestemmer ikke arkiveret logstørrelse, faktisk bestemmer du online gentag logstørrelse.

Definer Middeltid til gendannelse (MTTR)

men nu er spørgsmålet: hvordan indstilles en korrekt og optimal størrelse til online redo-logfiler? Der er et simpelt svar til os. Hvis din database er Oracle 10g videre, kan du få en optimal værdi fra den aktuelle instanskonfiguration.

først skal du sørge for, at FAST_START_MTTR_TARGET er indstillet til en anden værdi end nul.

SQL> show parameter fast_start_mttr_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 1800

kontroller Optimal gentag Logstørrelse

hvis du har indstillet FAST_START_MTTR_TARGET, dvs. 1800 sekunder i dette tilfælde kan du få en rådgivende værdi til optimering af logfilstørrelse ved denne forespørgsel.

SQL> select target_mttr, estimated_mttr, optimal_logfile_size from v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE
----------- -------------- --------------------
146 21 1469

som du kan se, er den tredje kolonne OPTIMAL_LOGFILE_STØRRELSE svaret. Oracle anbefaler dig at indstille gentagelseslogstørrelsen til 1469 MB.

Dernæst skal vi muligvis ændre størrelsen på gentagelseslogfiler for at overholde den anbefalede størrelse.

B. er alle arkivlogfiler af samme størrelse?

for det meste er arkiverede logfiler af samme størrelse, men de kan blive påvirket af følgende faktorer.

gør alle redo logs defineret som samme størrelse?

selvom vi bør definere alle redo log grupper og medlemmer som samme størrelse, kan du se forskellige størrelser blandt redo logs er defineret i få databaser. Normalt tilføjes de større gentagelseslogfiler efter oprettelsen af databasen. Derfor så vi arkiverede logfiler i forskellige størrelser.

har du nogensinde indstillet logkontaktinterval?

Logskift kan udføres med et fast interval ved at indstille ARCHIVE_LAG_TARGET initialiseringsparameter for at hjælpe dig med at kontrollere arkivfrekvensen.

hvis parameteren er indstillet til en anden værdi end standardværdien (0, deaktiveret), vil der ske en vis logskift, før gentagelseslogfiler udfyldes. Sådanne for tidlige gentagelseslogfiler laver arkiverede logfiler i forskellige størrelser.

RMAN Backup

ved siden af indstilling log skift interval, tager en database backup med arkiverede logfiler af RMAN vil udløse log skift. For eksempel vil vi gerne have en selvstændig fuld backup som denne:

RMAN> backup database plus archivelog;
Starting backup at 27-JUN-16
current log archived
...
Starting backup at 27-JUN-16
current log archived
...

som du kan se, blev 2 redo logs arkiveret af RMAN, før og efter den fulde backup. De er mindre end defineret størrelse.

C. Sådan kontrolleres Arkivlogstørrelse?

lad os nu komme tilbage til vores hovedemne, hvordan man kontrollerer arkivlogstørrelsen i databasen?

størrelsen af hver arkiveret Log

for at se størrelsen af hver arkiveret log, spørger vi 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
...

størrelsen på hver enkelt arkivlog kan beregnes ved at multiplicere blokke med blokstørrelse kolonne. Desuden beregnede vi kun arkiverede logfiler, som er afsluttet i 24 timer og tilgængelige i den primære database.

som du kan se, er ikke alle arkivlogfiler i samme størrelse, de fleste arkiverede logfiler er i 1024MB (dvs.1GB).

størrelse på alle arkiverede logfiler

alle tilgængelige

for at se den samlede størrelse af tilgængelige arkiverede logfiler i den primære databaseserver kan vi gøre dette:

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

som vi kan se, har vi over 400 GB arkiverede logfiler, vi bør slette dem mere aggressivt fra nu af.

sidste 24 timer

for at opsummere alle tilgængelige arkiverede logstørrelser i de sidste 24 timer i den primære databaseserver, kan vi gøre dette:

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

vi tilføjede et filter for at begrænse tidsrummet for arkiverede logfiler.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.