hoe te controleren Archiefloggrootte
in dit bericht zal ik het hebben over de volgende 3 onderwerpen.
- hoe de grootte van Archieflogboeken definiëren?
- hebben alle Archieflogs dezelfde grootte?
- Hoe controleer ik de grootte van Archieflogboeken?
A. Hoe de grootte van Archieflogboeken definiëren?
voordat u de grootte van gearchiveerde logboeken bepaalt, moet u weten dat gearchiveerde logboeken zijn afgeleid van het wisselen van online logboeken met opnieuw uitvoeren. Wat betekent, gearchiveerde logs zijn gepensioneerd en gekopieerd Online opnieuw logs. Met andere woorden, u bent niet het bepalen van gearchiveerde log grootte, in feite bent u het bepalen van online redo log grootte.
definieer Mean Time To Recover (MTTR)
maar nu is de vraag: hoe stel je een juiste en optimale grootte in voor online redo logs? Er is een simpel antwoord voor ons. Als uw database is Oracle 10g verder, dan kunt u een optimale waarde van de huidige instantie configuratie.
eerst moet u ervoor zorgen dat FAST_START_MTTR_TARGET is ingesteld op een andere waarde dan nul.
SQL> show parameter fast_start_mttr_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 1800
controleer de optimale Loggrootte opnieuw
Als u FAST_START_MTTR_TARGET hebt ingesteld, d.w.z. 1800 seconden in dit geval, dan kunt u een adviserende waarde voor het optimaliseren van logfile grootte door deze query te krijgen.
SQL> select target_mttr, estimated_mttr, optimal_logfile_size from v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE
----------- -------------- --------------------
146 21 1469
zoals u kunt zien, is de derde kolom OPTIMAL_LOGFILE_SIZE het antwoord. Oracle raadt u aan om de grootte van het logboek opnieuw in te stellen op 1469MB.
vervolgens moeten we mogelijk de grootte van redo logs wijzigen om te voldoen aan de aanbevolen grootte.
B. hebben alle Archieflogs dezelfde grootte?
meestal hebben gearchiveerde logs dezelfde grootte, maar ze kunnen worden beïnvloed door de volgende factoren.
zijn alle logboeken opnieuw gedefinieerd als dezelfde grootte?
hoewel we alle redo log groepen en leden moeten definiëren als dezelfde grootte, kunt u zien dat verschillende groottes tussen redo logs zijn gedefinieerd in enkele databases. Meestal worden de grotere redo logs toegevoegd na het aanmaken van de database. Daarom zagen we gearchiveerde logs van verschillende grootte.
hebt u ooit een log-schakelinterval ingesteld?
Log switching kan worden gedaan met een vast interval door het instellen van ARCHIVE_LAG_TARGET initialisatieparameter om u te helpen om de archieffrequentie te controleren.
als de parameter anders is ingesteld dan de standaardwaarde (0, uitgeschakeld), zal er enige verandering van log plaatsvinden voordat logboeken opnieuw worden ingevuld. Dergelijke voortijdige redo logs maken verschillende grootte gearchiveerde logs.
RMAN-back-up
naast het instellen van het log-schakelinterval, zal het nemen van een databaseback-up met gearchiveerde logs door RMAN log-switching activeren. Bijvoorbeeld, we zouden graag een op zichzelf staande volledige back-up als deze hebben:
RMAN> backup database plus archivelog;
Starting backup at 27-JUN-16
current log archived
...
Starting backup at 27-JUN-16
current log archived
...
zoals u kunt zien, 2 redo logs werden gearchiveerd door RMAN, voor en na de volledige back-up. Ze zijn kleiner dan gedefinieerd formaat.
C. Hoe Archieflogboekgrootte controleren?
nu gaan we terug naar ons hoofdonderwerp, Hoe controleer ik de archiefloggrootte in de database?
Grootte van elk gearchiveerd Logs
om de grootte van elk gearchiveerd logs te zien, vragen we 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
...
de grootte van elk archieflogboek kan worden berekend door blokken te vermenigvuldigen met block_size kolom. Bovendien hebben we alleen gearchiveerde logs berekend die in 24 uur zijn voltooid en beschikbaar zijn in de primaire database.
zoals u kunt zien, hebben niet alle archieflogboeken dezelfde grootte, de meeste archieflogboeken zijn in 1024MB (d.w.z. 1GB).
Grootte van alle gearchiveerde Logs
alle beschikbaarheden
om de totale grootte van de beschikbare gearchiveerde logs in de primaire databaseserver te zien, kunnen we dit doen:
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
zoals we kunnen zien, hebben we meer dan 400 GB aan gearchiveerde logs, we moeten ze vanaf nu agressiever verwijderen.
laatste 24 uur
om alle beschikbare archiefgrootte van de laatste 24 uur in de primaire databaseserver samen te vatten, kunnen we dit doen:
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
we hebben een filter toegevoegd om het tijdsbereik van gearchiveerde logs te beperken.