Spletna stran uporablja piškotke za boljšo uporabniško izkušnjo in spremljanje statistike obiskov (Google Analytics).
Z nadaljno uporabo spletne strani ali klikom na "Strinjam se", se strinjate z uporabo piškotkov.
Piškotki in njihova uporaba

Oracle in poln Fast Recovery Area

Objavil Blaž Kristan 10.2.2014 @ 13:20

Vse skupaj se je začelo z nedolžnim klicem ali lahko pogledam zakaj se ena od baz ne odziva.

Hiter pregled je pokazal, da servis (instanca) sicer dela, baza pa ni dvignjena. Sledil je skok v SQLplus in poskus startanja baze. Žal neuspešno.

Zlato pravilo Oracle diagnostike je pregled zadnjih zapisov v alert logu in tam me je čakalo zanimivo sporočilo:

************************************************************************
ARC0: Error 19809 Creating archive log file to 'N:\ORACLE\PRODUCT\11.2.0\FAST_RECOVERY_AREA\SID\ARCHIVELOG\2014_02_06\O1_MF_1_106_%U_.ARC'
ARCH: Archival stopped, error occurred. Will continue retrying
Errors in file L:\ORACLE\PRODUCT\11.2.0\diag\rdbms\SID\SID\trace\SID_ora_936.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 42949672960 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
ARCH: Error 19809 Creating archive log file to 'N:\ORACLE\PRODUCT\11.2.0\FAST_RECOVERY_AREA\SID\ARCHIVELOG\2014_02_06\O1_MF_1_106_%U_.ARC'
Errors in file L:\ORACLE\PRODUCT\11.2.0\diag\rdbms\SID\SID\trace\SID_ora_936.trc:
ORA-16038: log 1 sequence# 106 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: 'L:\ORACLE\PRODUCT\11.2.0\ORADATA\SID\REDO01.RDO'
ORA-00312: online log 1 thread 1: 'N:\ORACLE\PRODUCT\11.2.0\ORADATA\SID\REDO01N.RDO'
USER (ospid: 936): terminating the instance due to error 16038
System state dump requested by (instance=1, osid=936), summary=[abnormal instance termination].
System State dumped to trace file L:\ORACLE\PRODUCT\11.2.0\diag\rdbms\SID\SID\trace\SID_diag_4576.trc
Dumping diagnostic data in directory=[cdmp_20140206072521], requested by (instance=1, osid=936), summary=[abnormal instance termination].
Instance terminated by USER, pid = 936

Najprej sem poskusil z običajno metodo: backupom arhivskih logov.

backup device type disk archivelog all not backed up;

Žal zadeva ni delovala, ker je Fast Recovery Area polna.

Seveda sem takoj odprl raziskovalca in pobrisal stare arhivske loge, saj mi je bilo rečeno naj čimprej usposobim bazo. Začuda pa je baza še vedno vztrajala, da je Fast Recovery Area 100% polna in v njej ne more alocirati prostora za arhivski log. Čudno, saj sem zagotovo pobrisal odvečne arhivske loge.

Malo raziskovanja in skupaj sem spravil naslednje korake, da sem odpravil težavo:

C:\> rman target /
RMAN> STARTUP MOUNT
RMAN> CROSSCHECK ARCHIVELOG ALL;
RMAN> DELETE EXPIRED ARCHIVELOG ALL;
RMAN> ALTER DATABASE OPEN;

S prvim ukazom v RMANu startamo bazo do te mere, da prebere controlfile, saj se v njem nahajajo informacije glede arhivskih logov. Drugi ukaz pove bazi naj preveri ali so vsi arhivski logi še vedno na voljo in označi tiste, ki manjkajo (ja baza si zapomni katere arhivske loge ima). Tretji ukaz pa (logično) izbriše tiste arhivske loge, ki jih na disku ni več.

Šele, ko sem vse to naredil, se je baza normalno startala.

Kasneje sem sicer odkril, da bi lahko počistil arhivske loge tudi s pomočjo RMANa in to samo z enim ukazom:

delete noprompt archivelog until time 'sysdate - 1';

Nato sem začel z raziskovanjem, kako je do tega prišlo, in ugotovil, da baza še nikoli ni bila backupirana. Kaj takega se mi še ni zgodilo! Šel sem preverjati vso dokumentacijo in ugotovil, da je bazo postavil dobavitelj in očitno pozabil na backupe, a hkrati nastavil bazo v arhivski način. :S Če je niso nameravali redno backupirat bi bilo dovolj, da bi izklopili arhivski način in jo backupirali po potrebi.

Ker se nisem hotel poglabjati v delovanje aplikacije sem zgolj spacal RMAN skripto in nastavil schedule task, ki enkrat dnevno pobackupira vse skupaj in počisti arhivske loge.

 

configure retention policy to redundancy 1;
backup as compressed backupset database;
backup archivelog all delete all input;;
allocate channel for maintenance type disk;
delete noprompt obsolete device type disk;
release channel;
exit;

Samo na ta način je zagotovljeno, da se FRA ne zapolni in se arhivski logi redno brišejo.

Komentarji

* Komentarje mora odobriti admin.