Opiekuje się pewną bazą danych w której są zdefiniowane dwa katalogi docelowe dla archivelog. W wyniku braku dostępu do dysku baza przełączyła katalog docelowy na alternatywny. I co teraz…Konfiguracja dla katalogów docelowych dla archive log jak poniżej:
SQL> show parameters archive
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
...
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_
DEST MANDATORY ALTERNATE=LOG_A
RCHIVE_DEST_2
log_archive_dest_2 string LOCATION=/home/backup/database
/alternate_log MANDATORY
log_archive_dest_state_1 string ENABLE
log_archive_dest_state_2 string ALTERNATE
Jak widac log_archive_dest_1 to katalog gdzie standardowo lądują archive log – dla nie wtajemniczonych jako LOCATION jest ustawiony USE_DB_RECOVERY_FILE_DEST ponieważ baza używa OMF/FRA. Drugi katalog docelowy log_archive_dest_2 jest typu ALTERNATE – oznacza to, iż baza będzie zapisywała archive log do tego katalogu tylko gdy nie może zapisać do log_archive_dest_1. I tak się stało, z powodu utraty dostępu do log_archive_dest_1 baza przeniosła się z zapisywanie do log_archive_dest_2.
Aby sprawdzić jaki jest aktualny status katalogów docelowych możemy użyć zapytania:
SQL> select dest_name, status from v$archive_dest; DEST_NAME STATUS ------------------ ----------- LOG_ARCHIVE_DEST_1 DISABLED LOG_ARCHIVE_DEST_2 VALID
STATUS może mieć kilka wartości: VALID – lokalizacja docelowa jest ok i działa, INACTIVE – lokalizacja docelowa jest nieaktywna/nieskonfigurowana, ERROR – problem z zapisem w lokalizacji docelowej, FULL – w lokalizacji docelowej skończyło się wolne miejsce, DEFERRED – lokalizacja docelowa została zatrzymana ręcznie, DISABLED – lokalizacja docelowa została zatrzymana w wyniku błędów (warto przeglądnąć logi bazy danych), BAD PARAM – coś źle zostało skonfigurowane i są podane nieprawidłowe parametry do lokalizacji.
W moim przypadku log_archive_dest_1 powinno miesc status VALID a log_archive_dest_2 status ALTERNATE. Jak widać z powyższego sql-a baza zapisywała archive log w drugiej, zapasowej lokalizacji docelowej. Po przywróceniu do życia dysku na którym zapisywały się archive log, przyszedł czas na przywrócenie normalnego działania ;) W pierwszej kolejności trze oznajmić oracle, że log_archive_dest_1 jest juz ok:
SQL> alter system set log_archive_dest_1=ENABLE; SQL> select dest_name, status from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_1';
DEST_NAME STATUS ------------------ ----------- LOG_ARCHIVE_DEST_1 VALID
Następnie warto stworzyć archive log i sprawdzić czy się zapisał tak jak oczekiwaliśmy – powinien zapisać się w obu lokalizacjach docelowych, gdyż log_archive_dest_2 nadal ma status VALID:
SQL> alter system switch logfile; SQL> select dest_name, status from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_1';
DEST_NAME STATUS ------------------ ----------- LOG_ARCHIVE_DEST_1 VALID
Jeśli status nie będzie VALID to znaczy, że baza znowu miała problem zapisać wlog_archive_dest_1 – w takim przypadku jedynie zostało ponownie w logach bazy sprawdzić co jest nie tak. Jeśli wszystko jest ok to na koniec wystarczy oznaczyć log_archive_dest_2 jako ALTERNATE i zweryfikować czy archive log zapisze się tylko w log_archive_dest_1:
SQL> alter system set log_archive_dest_2=ALTERNATE; SQL> select dest_name, status from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_2';
DEST_NAME STATUS ------------------ ----------- LOG_ARCHIVE_DEST_2 ALTERNATE SQL> alter system switch logfile;