Nie można usunąć obszaru tabel Cofnij, ponieważ segment Cofnij znajduje się w trybie naprawy

  • Vovich Masterovich
  • 0
  • 3292
  • 866

Problem

Utworzono nowy obszar tabel cofania i podjęto próbę usunięcia starego obszaru tabel cofania. Porzucenie starej przestrzeni tabel Undo daje komunikat:

ORA-01548: aktywny segment wycofywania

Lub

Segment Cofnij pokazuje stan wymagający przywrócenia

Rozwiązanie

Ten problem może wystąpić, jeśli plik danych, w którym znajdują się cofnięte segmenty, jest w trybie offline, a transakcji nie można wycofać, ponieważ plik jest w trybie offline lub może się to również zdarzyć, jeśli wystąpi jakikolwiek problem w samym segmencie Cofnij.

Zaznacz opcję Cofnij segment

Najpierw sprawdź, czy stan segmentu Cofnij:

SQL> wybierz segment_name, status, tablespace_name z dba_rollback_segs, gdzie status nie jest w ('ONLINE', 'OFFLINE'); SEGMENT_NAME STATUS TABLESPACE_NAME ----------------- ----------- ---------------- _SYSSMU3 $ NEEDS ODZYSKANIE UNDO01

W powyższym przykładzie segment Cofnij _SYSSMU3 $ jest w stanie Wymaga odzyskania. Ten segment należy do obszaru tabel Undo UNDO01. Sprawdź stan pliku danych obecnego w obszarze tabel UNDO01.

SQL> wybierz status, nazwę, plik # z v $ datafile, gdzie ts # in (Wybierz ts # z v $ tablespace, gdzie name = "UNDO01"); NAZWA STATUSU NR PLIKU ------- --------------------------------------- ----------- ---------- ONLINE /[UNDO]/[FILE_NAME].dbf 56 RECOVER /[UNDO]/[FILE_NAME].dbf 77

Tak więc wyraźnie jeden plik ma status Odzyskaj. Jeśli baza danych jest w trybie dziennika archiwum i masz wszystkie wymagane tryby dziennika archiwalnego, możesz wykonać następujące czynności:

1. Sprawdź, czy masz wszystkie wymagane dzienniki archiwum na dysku lub jeśli używasz Rman, upewnij się, że istnieją one w kopii zapasowej:

SQL> Wybierz checkpoint_change # z v $ datafile_header gdzie plik # = [plik # (numer) w statusie ODZYSKIWANIA z poprzedniego zapytania];

2. Teraz znajdź te zmiany, w którym dziennik archiwum:

SQL> wybierz numer sekwencji, numer wątku, nazwę z v $ archived_log gdzie [checkpoint_change # z zapytania 1] między first_change # a next_change #;

Upewnij się, że masz wszystkie dzienniki archiwalne począwszy od tej sekwencji # do bieżącej sekwencji # w bazie danych. Na przykład:

SQL> wybierz checkpoint_change #, file #, status z v $ datafile_header, gdzie plik # = 77; CHECKPOINT_CHANGE # FILE # STATUS ------------------ ---------- ------- 2103113 4 OFFLINE 77
SQL> Wybierz numer sekwencji, numer wątku, nazwę z v $ archived_log, gdzie 2103113 między first_change # a next_change #; SEKWENCJA # NITKA # NAZWA --------------------------------------------- ----------------------------------- 96 1 /[DIRECTORY]/[FILE_NAME].Arc

Jeśli używasz rman - sprawdź, czy jest dostępny dziennik archiwalny z tej sekwencji do bieżącej sekwencji:

RMAN> kopia zapasowa listy archiwum z sekwencji [nie wymieniona w zapytaniu kroku 2 powyżej]; RMAN> odzyskaj plik danych [fileno]; RMAN> sql 'zmień plik danych bazy danych [fileno] online';

jeśli używasz sqlplus - upewnij się, że logi archiwalne są obecne na dysku:

SQL> odzyskaj plik danych [fileno];

Wpisz AUTO i naciśnij Enter. Po zakończeniu odzyskiwania wykonaj poniższe zapytanie:

SQL> zmień plik danych bazy danych [fileno] online;

Jeśli dzienniki archiwum zostały przywrócone do innej lokalizacji niż domyślne miejsce docelowe dziennika archiwum używane w bazie danych, określ to samo za pomocą polecenia set source w programie sqlplus:

SQL> set logsource "/ [DIR] / newlocation"; SQL> odzyskaj plik danych [fileno];

Wpisz AUTO i naciśnij Enter. Po zakończeniu odzyskiwania wykonaj poniższe zapytanie:

SQL> zmień plik danych bazy danych [fileno] online;
Jak usunąć cofniętą przestrzeń tabel w bazie danych Oracle




Jeszcze bez komentarzy

Zbiór przydatnych informacji o systemie operacyjnym Linux i nowych technologiach
Świeże artykuły, praktyczne wskazówki, szczegółowe recenzje i poradniki. Poczuj się jak w domu w świecie systemu operacyjnego Linux