Oracle oferuje różne metody wykrywania i korygowania uszkodzeń bloków danych. Jedną z metod jest upuszczenie i odtworzenie obiektu po wykryciu uszkodzenia; jednak nie zawsze jest to możliwe lub pożądane. Jeśli uszkodzenie bloku danych jest ograniczone do podzbioru wierszy, inną opcją jest przebudowanie tabeli, wybierając wszystkie dane z wyjątkiem uszkodzonych wierszy.
kolejnym sposobem zarządzania uszkodzeniami bloków danych jest użycie pakietu DBMS_REPAIR. Możesz użyć DBMS_REPAIR do wykrywania i naprawy uszkodzonych bloków w tabelach i indeksach. Korzystając z tego podejścia, możesz usuwać uszkodzenia, jeśli to możliwe, a także nadal używać obiektów podczas próby ich odbudowy lub naprawy. DBMS_REPAIR używa następującego podejścia do usuwania uszkodzeń:
- Krok 1: Wykryj i zgłoś uszkodzenia
- Krok 2: Oceń koszty i korzyści wynikające z używania DBMS_REPAIR
- Krok 3: spraw, aby obiekty były użyteczne
- Krok 4: napraw uszkodzenia i odbuduj utracone dane
Uwaga:każda korupcja, która wiąże się z utratą danych, wymaga analizy i zrozumienia, w jaki sposób dane te pasują do ogólnego systemu bazodanowego. Dlatego DBMS_REPAIR nie jest magiczną różdżką – musisz nadal określić, czy podejście do naprawy zapewnione przez ten pakiet jest odpowiednim narzędziem dla każdego konkretnego problemu z uszkodzeniem. W zależności od charakteru naprawy, możesz utracić dane i wprowadzić logiczne niespójności; dlatego musisz rozważyć zyski i straty związane z użyciem DBMS_REPAIR.
Zawartość pakietu DBMS_REPAIR
tabela 19-1 opisuje procedury składające się na pakiet DBMS_REPAIR.
tabela 19-1 DBMS_PROCEDURA naprawy
| nazwa procedury | opis |
|---|---|
|
|
wykrywa i zgłasza uszkodzenia w tabeli lub indeksie. |
|
|
oznacza bloki (które wcześniej zostały zidentyfikowane przez procedurę |
|
|
zgłasza wpisy indeksu wskazujące na wiersze w uszkodzonych blokach danych. |
|
|
odbudowuje freelancerów obiektu. |
|
|
podczas skanowania tabeli i indeksu ignoruje bloki oznaczone jako uszkodzone. Jeśli nie zostanie użyty, pojawi się błąd ORA-1578 podczas napotkania bloków oznaczonych jako uszkodzone. |
|
|
udostępnia funkcje administracyjne (create, drop, purge) dla tabel kluczy dbms_repair repair i orphan. Uwaga: tabele te są zawsze tworzone w schemacie SYS. |
Krok 1: Wykryj i zgłoś uszkodzenia
Twoim pierwszym zadaniem, przed użyciem DBMS_REPAIR, powinno być wykrywanie i raportowanie uszkodzeń. Raportowanie nie tylko wskazuje, co jest nie tak z blokiem, ale także identyfikuje powiązaną dyrektywę naprawczą. Oprócz DBMS_REPAIR masz kilka opcji wykrywania uszkodzeń. Tabela 19-2 opisuje różne metody wykrywania.
tabela 19-2 porównanie metod wykrywania korupcji
| metoda wykrywania | opis |
|---|---|
|
DBMS_REPAIR |
wykonuje sprawdzanie bloków dla określonej tabeli, partycji lub indeksu. |
|
DB_VERIFY |
zewnętrzne narzędzie wiersza poleceń, które wykonuje sprawdzanie bloków w bazie danych offline. |
|
analizuj |
używany z opcją zweryfikuj strukturę, weryfikuje integralność struktury indeksu, tabeli lub klastra; sprawdza lub sprawdza, czy tabele i indeksy są zsynchronizowane. |
|
DB_BLOCK_CHECKING |
identyfikuje uszkodzone bloki, zanim faktycznie zostaną Oznaczone jako uszkodzone. Kontrole są wykonywane, gdy zmiany są wprowadzane do bloku. |
DBMS_REPAIR: Korzystanie z procedur check_object i admin_tables
procedura check_object sprawdza i raportuje uszkodzenia bloku dla określonego obiektu. Podobne do analizy…Instrukcja VALIDATE STRUCTURE dla indeksów i tabel, sprawdzanie bloków jest wykonywane odpowiednio dla indeksów i bloków danych.
nie tylko zgłasza uszkodzenia, ale także identyfikuje wszelkie poprawki, które mogłyby wystąpić, jeśli fix_corrupt_blocks zostanie następnie uruchomiony na obiekcie. Informacje te są udostępniane przez wypełnienie tabeli napraw, która musi być najpierw utworzona za pomocą procedury admin_tables.
po uruchomieniu procedury check_object proste zapytanie w tabeli napraw pokazuje dyrektywy uszkodzeń i naprawy dla obiektu. Dzięki tym informacjom możesz ocenić, jak najlepiej rozwiązać zgłoszone problemy.
DB_VERIFY: sprawdzanie bazy danych w trybie Offline
zazwyczaj używasz DB_VERIFY jako narzędzia diagnostycznego w trybie offline, gdy napotkasz problemy z uszkodzeniem danych.
Zobacz: Aby uzyskać więcej informacji o DB_VERIFY, zobacz Oracle8i Utilities.
ANALYZE: raportowanie korupcji
tabela analiz…Instrukcja VALIDATE STRUCTURE sprawdza strukturę analizowanego obiektu. Jeśli Oracle pomyślnie potwierdzi poprawność struktury, zostanie Ci zwrócony komunikat potwierdzający jej poprawność. Jeśli Oracle napotka korupcję w strukturze obiektu, zwracany jest komunikat o błędzie. W takim przypadku należy upuścić i ponownie utworzyć obiekt.
Zobacz także: aby uzyskać więcej informacji na temat instrukcji ANALYZE, zobacz referencję SQL ORACLE8I.
DB_BLOCK_CHECKING (parametr inicjalizacji sprawdzania bloków)
możesz ustawić sprawdzanie bloków dla instancji za pomocą parametru DB_BLOCK_CHECKING (wartość domyślna to TRUE); sprawdza to Dane i bloki indeksów za każdym razem, gdy są modyfikowane. DB_BLOCK_CHECKING jest dynamicznym parametrem, który można modyfikować za pomocą instrukcji ALTER system SET.
Krok 2: Oceń koszty i korzyści wynikające z używania DBMS_REPAIR
przed użyciem DBMS_REPAIR należy rozważyć korzyści wynikające z jego użycia w odniesieniu do zobowiązań; należy również sprawdzić inne dostępne opcje adresowania uszkodzonych obiektów.
pierwszym krokiem jest odpowiedź na następujące pytania:
- jaki jest zakres korupcji?
aby określić, czy występują uszkodzenia i działania naprawcze, wykonaj procedurę
check_objecti odpytaj tabelę napraw. - jakie inne opcje są dostępne do rozwiązywania uszkodzeń bloków?
zakładając, że dane są dostępne z innego źródła, upuść, ponownie utwórz i ponownie zapełnij obiekt. Inną opcją jest wydanie tabeli CREATE…Jako polecenie SELECT z uszkodzonej tabeli, aby utworzyć nową.
możesz zignorować korupcję, wykluczając uszkodzone wiersze z instrukcji select.
wykonaj odzyskiwanie multimediów.
- jakie logiczne uszkodzenia lub skutki uboczne zostaną wprowadzone, gdy używasz DBMS_REPAIR, aby obiekt był użyteczny? Czy można się tym zająć? Jaki jest wysiłek, aby to zrobić?
możesz nie mieć dostępu do wierszy w blokach oznaczonych jako uszkodzone. Blok może być jednak oznaczony jako uszkodzony, nawet jeśli nadal istnieją wiersze, do których możesz uzyskać prawidłowy dostęp.
ograniczenia integralności odniesienia mogą zostać złamane, gdy bloki są oznaczone jako uszkodzone. Jeśli tak się stanie, wyłącz i ponownie włącz ograniczenie; wszelkie niespójności zostaną zgłoszone. Po naprawieniu wszystkich problemów powinno być możliwe ponowne włączenie ograniczenia.
uszkodzenie logiczne może wystąpić, gdy w tabeli są zdefiniowane wyzwalacze. Na przykład, jeśli wiersze są ponownie wstawiane, czy należy uruchamiać wyzwalacze insert, czy nie? Możesz rozwiązać te problemy tylko wtedy, gdy rozumiesz wyzwalacze i ich użycie w instalacji.
bloki mogą być niedostępne. Jeśli uszkodzony blok znajduje się na czele lub ogonie freelisty, zarządzanie przestrzenią przywraca freelistę. Wtedy mogą być bloki, które powinny być na freeliście, które nie są. możesz to rozwiązać, uruchamiając procedurę
rebuild_freelists.Indeksy i tabele mogą być zsynchronizowane. Można to rozwiązać, wykonując najpierw procedurę
dump_orphan_keys(aby uzyskać informacje z kluczy, które mogą być przydatne w odbudowie uszkodzonych danych). Następnie wydaj polecenie Alter INDEX REBUILD online, aby zsynchronizować tabelę i jej indeksy. - jeśli naprawa wiąże się z utratą danych, czy można odzyskać te dane?
możesz pobrać dane z indeksu, gdy blok danych jest oznaczony jako uszkodzony. Procedury
dump_orphan_keysmogą pomóc w odzyskaniu tych informacji. Oczywiście pobieranie danych w ten sposób zależy od ilości redundancji między indeksami a tabelą.
Krok 3: czyń Obiekty użytecznymi
w tym kroku DBMS_REPAIR sprawia, że obiekt jest użyteczny, ignorując uszkodzenia podczas skanowania tabeli i indeksu.
Naprawa Uszkodzeń: Korzystanie z procedur fix_corrupt_blocks i skip_corrupt_blocks
powoduje, że uszkodzony obiekt staje się użyteczny poprzez utworzenie środowiska, które pomija uszkodzenia, które pozostają poza zakresem możliwości naprawy DBMS_REPAIR.
jeśli uszkodzenia wiążą się z utratą danych, takich jak zły wiersz w bloku danych, wszystkie takie bloki są oznaczone jako uszkodzone przez procedurę fix_corrupt_blocks. Następnie można uruchomić procedurę skip_corrupt_blocks, która pominie bloki oznaczone jako uszkodzone dla obiektu. Gdy opcja skip jest ustawiona, skanowanie tabeli i indeksu pomija wszystkie bloki oznaczone jako uszkodzone. Dotyczy to zarówno nośników, jak i uszkodzonych bloków oprogramowania.
implikacje podczas pomijania uszkodzonych bloków
jeśli indeks i tabela są zsynchronizowane, transakcja tylko do odczytu zestawu może być niespójna w sytuacjach, gdy jedno zapytanie sonduje tylko Indeks, a kolejne zapytanie sonduje zarówno indeks, jak i tabelę. Jeśli blok tabeli jest oznaczony jako uszkodzony, to dwa zapytania zwrócą różne wyniki, łamiąc w ten sposób zasady transakcji tylko do odczytu. Jednym ze sposobów podejścia do tego jest nie pomijanie uszkodzeń, gdy w określonej transakcji transakcja tylko do odczytu.
podobny problem występuje podczas wybierania wierszy, które są połączone łańcuchem. Zasadniczo zapytanie tego samego wiersza może, ale nie musi, uzyskać dostęp do korupcji-dając w ten sposób różne wyniki.
Krok 4: napraw uszkodzenia i odbuduj utracone dane
po utworzeniu obiektu można wykonać następujące czynności naprawcze.
Odzyskaj dane za pomocą procedur dump_orphan_keys
procedura dump_orphan_keys raportuje wpisy indeksu, które wskazują wiersze w uszkodzonych blokach danych. Wszystkie takie pozycje indeksu są wstawiane do tablicy kluczy osieroconych, która przechowuje klucz i rowid korupcji.
po pobraniu informacji o wpisie indeksu można odbudować indeks za pomocą instrukcji ALTER INDEX REBUILD ONLINE.
napraw Freelistów za pomocą procedury rebuild_freelists
gdy na głowie lub ogonie freelisty znajduje się blok oznaczony „uszkodzony”, freelista jest ponownie inicjowany i zwracany jest błąd. Chociaż usuwa to obrażający blok freelisty, powoduje utratę dostępu freelisty do wszystkich bloków, które następowały po uszkodzonym bloku.
możesz użyć procedury rebuild_freelists, aby ponownie zainicjować freelistów. Obiekt jest skanowany, a jeśli odpowiedni jest blok na freeliście, jest on dodawany do głównego freelisty. Grupy freelancerów są obsługiwane przez dzielenie się blokami w sprawiedliwy sposób-blok na raz. Wszelkie bloki oznaczone jako „uszkodzony” w obiekcie są ignorowane podczas odbudowy.
ograniczenia i ograniczenia
procedury DBMS_REPAIR mają następujące ograniczenia:
- obsługiwane są tabele z LOB, tabele zagnieżdżone i VARRAYS, ale kolumny poza wierszem są ignorowane.
- klastry są obsługiwane w procedurach
skip_corrupt_blocksirebuild_freelist, ale nie w procedurzecheck_object. - tabele zorganizowane indeksami i indeksy LOB nie są obsługiwane.
- procedura
dump_orphan_keysnie działa na indeksach bitmapowych ani indeksach opartych na funkcjach. - procedura
dump_orphan_keysprzetwarza klucze o długości co najwyżej 3950 bajtów.
procedury DBMS_REPAIR
Ta sekcja zawiera szczegółowe opisy procedur DBMS_REPAIR.
check_object
procedura check_object sprawdza określone obiekty i wypełnia tabelę napraw informacjami o uszkodzeniach i dyrektywach naprawy. Walidacja polega na sprawdzaniu wszystkich bloków w obiekcie. Opcjonalnie możesz określić zakres, nazwę partycji lub nazwę podczęści, gdy chcesz sprawdzić część obiektu.
procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)
tabela 19-3 procedura check_object
| Argument | opis |
|---|---|
|
|
nazwa schematu sprawdzanego obiektu. |
|
|
Nazwa tabeli lub indeksu do sprawdzenia. |
|
|
sprawdzana nazwa partycji lub podczęści. Jeśli jest to obiekt partycjonowany, a |
|
|
Typ przetwarzanego obiektu. Musi być TABLE_OBJECT lub INDEX_OBJECT. Domyślną wartością jest TABLE_OBJECT. |
|
|
Nazwa tabeli napraw, którą należy wypełnić. Tabela musi istnieć w schemacie SYS. Użyj procedury |
|
|
zarezerwowane do wykorzystania w przyszłości. |
|
|
względny numer pliku. Używane przy określaniu zakresu bloków. |
|
|
pierwszy blok do przetworzenia, jeśli podano zakres bloków. Może być określona tylko wtedy, gdy obiekt jest pojedynczą tabelą, partycją lub podczęścią. |
|
|
ostatni blok do przetworzenia, jeśli podano zakres bloków. Może być określona tylko wtedy, gdy obiekt jest pojedynczą tabelą, partycją lub podczęścią. jeśli podano tylko jeden z bloków block_start lub block_end, to drugi domyślnie jest odpowiednio pierwszym lub ostatnim blokiem w pliku. |
|
|
liczba zgłoszonych uszkodzeń. |
fix_corrupt_blocks
Użyj tej procedury, aby naprawić uszkodzone bloki w określonych obiektach na podstawie informacji z tabeli napraw, które zostały wcześniej wygenerowane przez procedurę check_object. Przed dokonaniem jakichkolwiek zmian w bloku Blok jest sprawdzany, aby upewnić się, że blok jest nadal uszkodzony. Uszkodzone bloki są naprawiane przez zaznaczenie uszkodzonego oprogramowania bloku. Po dokonaniu naprawy powiązany wiersz w tabeli napraw jest aktualizowany o znacznik czasu naprawy.
procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)
tabela 19-4 procedura fix_corrupt_blocks
| Argument | opis |
|---|---|
|
|
nazwa schematu. |
|
|
nazwa obiektu z uszkodzonymi blokami do naprawy. |
|
|
nazwa partycji lub podczęści do przetworzenia. Jeśli jest to obiekt partycjonowany, a |
|
|
Typ przetwarzanego obiektu. Musi być TABLE_OBJECT lub INDEX_OBJECT. Domyślną wartością jest TABLE_OBJECT. |
|
|
Nazwa tabeli napraw z dyrektywami napraw. Musi istnieć w schemacie SYS. |
|
|
zarezerwowane do wykorzystania w przyszłości. |
|
|
liczba bloków stała. |
dump_orphan_keys
raportuje wpisy indeksu, które wskazują wiersze w uszkodzonych blokach danych. Dla każdej napotkanej pozycji indeksu, wiersz jest wstawiany do określonej tabeli osieroconej.
jeśli podano tabelę napraw, wszystkie uszkodzone bloki powiązane z tabelą bazową są obsługiwane oprócz wszystkich bloków danych oznaczonych jako uszkodzone oprogramowanie. W przeciwnym razie obsługiwane są tylko bloki oznaczone jako uszkodzone.
informacje te mogą być przydatne do odbudowy utraconych wierszy w tabeli i do celów diagnostycznych.
procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)
tabela 19-5 procedura dump_orphan_keys
| Argument | opis |
|---|---|
|
|
nazwa schematu. |
|
|
nazwa obiektu. |
|
|
nazwa partycji lub podczęści do przetworzenia. Jeśli jest to obiekt partycjonowany, a |
|
|
Typ przetwarzanego obiektu. Domyślną wartością jest INDEX_OBJECT. |
|
|
Nazwa tabeli napraw, która zawiera informacje dotyczące uszkodzonych bloków w tabeli bazowej. Określona tabela musi istnieć w schemacie SYS. Do utworzenia tabeli używana jest procedura |
|
|
Nazwa tabeli kluczy osieroconych do wypełnienia informacjami dotyczącymi każdego wpisu indeksu, który odnosi się do wiersza w uszkodzonym bloku danych. Określona tabela musi istnieć w schemacie SYS. Do utworzenia tabeli używana jest procedura |
|
|
liczba przetworzonych wpisów indeksu. |
rebuild_freelists
odbudowuje freelistów dla określonego obiektu. Wszystkie darmowe bloki są umieszczane na głównym freeliście. Wszyscy inni freeliści są zerowani. Jeśli obiekt ma wiele grup freelistów, wolne bloki są rozdzielane między wszystkich freelistów, przydzielając różne grupy w sposób round-robin.
procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);
tabela 19-6 procedura rebuild_freelists
| Argument | opis |
|---|---|
|
|
nazwa schematu. |
|
|
nazwa obiektu, który ma zostać odbudowany. |
|
|
nazwa partycji lub podtytułu, którego freelancerzy mają zostać przebudowani. Jeśli jest to obiekt partycjonowany, a |
|
|
Typ przetwarzanego obiektu. Musi być TABLE_OBJECT lub INDEX_OBJECT. Domyślną wartością jest TABLE_OBJECT. |
skip_corrupt_blocks
Włącza lub wyłącza pomijanie uszkodzonych bloków podczas skanowania indeksów i tabel określonego obiektu. Gdy obiekt jest tabelą, pomiń odnosi się do tabeli i jej indeksów. Gdy obiekt jest klastrem, odnosi się do wszystkich tabel w klastrze i ich odpowiednich indeksów.
procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);
tabela 19-7 procedura skip_corrupt_blocks
| Argument | opis |
|---|---|
|
|
nazwa schematu obiektu, który ma być przetwarzany. |
|
|
nazwa obiektu. |
|
|
nazwa partycji lub podczęści do przetworzenia. Jeśli jest to obiekt partycjonowany, a |
|
|
Typ przetwarzanego obiektu. Musi być TABLE_OBJECT lub CLUSTER_OBJECT. Domyślną wartością jest TABLE_OBJECT. |
|
|
jeśli podano SKIP_FLAG, włącza pomijanie uszkodzonych bloków oprogramowania dla obiektu podczas skanowania indeksu i tabeli. Jeśli podano NOSKIP_FLAG, skanery, które napotkają uszkodzone bloki oprogramowania, zwracają Ora-1578. |
admin_tables
udostępnia funkcje administracyjne do naprawy i osieroconych tabel kluczy.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
tabela 19-8 procedura admin_tables
| Argument | opis |
|---|---|
|
|
Nazwa tabeli do przetworzenia. Domyślnie 'ORPHAN_KEY_TABLE ’ lub’ REPAIR_TABLE ’ na podstawie podanego table_type. Gdy zostanie podana, nazwa tabeli musi mieć odpowiedni prefiks, 'ORPHAN_’ lub 'REPAIR_’. |
|
|
typ tabeli, musi być jednym z ORPHAN_TABLE lub REPAIR_TABLE. |
|
|
wskazuje, jakie czynności administracyjne należy wykonać. Musi to być CREATE_ACTION, PURGE_ACTION lub DROP_ACTION. Jeśli tabela już istnieje i podano CREATE_ACTION, to zwracany jest błąd. PURGE_ACTION oznacza usunięcie wszystkich wierszy w tabeli, które są powiązane z nieistniejącymi obiektami. Jeśli tabela nie istnieje i jest określona DROP_ACTION, to zwracany jest błąd. gdy podano CREATE_ACTION i DROP_ACTION, skojarzony widok o nazwie DBA_<table_name> jest tworzony i usuwany odpowiednio. Widok jest zdefiniowany tak, że wiersze powiązane z nieistniejącymi obiektami są eliminowane. utworzone w schemacie SYS. |
|
|
wskazuje powierzchnię stołu, której należy użyć podczas tworzenia tabeli. Domyślnie używana jest domyślna przestrzeń tabeli SYS. Błąd jest zwracany, jeśli określona jest przestrzeń tabel, a akcja nie jest CREATE_ACTION. |
wyjątki DBMS_REPAIR
| 942 | tabela napraw nie istnieje |
| 1418 | podany indeks nie istnieje |
| 24120 | nieprawidłowy parametr |
| 24121 | nie można określić CASCADE_FLAG i zakresu bloków |
| 24122 | nieprawidłowy zakres bloków |
| 24124 | podano nieprawidłowy parametr akcji |
| 24126 | CASCADE_FLAG określony i Obiekt nie jest tabelą |
| 24127 | określona przestrzeń tablespace i akcja nie jest CREATE_ACTION |
| 24128 | partycja określona dla obiektu bez partycji |
| 24129 | Nieprawidłowa nazwa tablicy kluczy osieroconych – musi mieć prefiks 'ORPHAN_’ |
| 24129 | podana tabela napraw nie zaczyna się od prefiksu 'REPAIR_’ |
| 24131 | tabela napraw zawiera nieprawidłowe kolumny |
| 24132 | nazwa tabeli napraw jest zbyt długa |