Oracle bietet verschiedene Methoden zum Erkennen und Korrigieren von Datenblockbeschädigungen. Eine Methode besteht darin, ein Objekt zu löschen und neu zu erstellen, nachdem die Beschädigung erkannt wurde. Wenn die Beschädigung von Datenblöcken auf eine Teilmenge von Zeilen beschränkt ist, können Sie die Tabelle auch neu erstellen, indem Sie alle Daten mit Ausnahme der beschädigten Zeilen auswählen.
Eine weitere Möglichkeit, Datenblockbeschädigungen zu verwalten, ist die Verwendung des Pakets DBMS_REPAIR. Mit DBMS_REPAIR können Sie beschädigte Blöcke in Tabellen und Indizes erkennen und reparieren. Mit diesem Ansatz können Sie nach Möglichkeit Beschädigungen beheben und Objekte weiterhin verwenden, während Sie versuchen, sie neu zu erstellen oder zu reparieren. DBMS_REPAIR verwendet den folgenden Ansatz, um Beschädigungen zu beheben:
- Schritt 1: Beschädigungen erkennen und melden
- Schritt 2: Kosten und Nutzen der Verwendung von DBMS_REPAIR bewerten
- Schritt 3: Objekte verwendbar machen
- Schritt 4: Beschädigungen reparieren und verlorene Daten wiederherstellen
Hinweis:
Jede Beschädigung, die den Verlust von Daten beinhaltet, erfordert eine Analyse und ein Verständnis dafür, wie diese Daten in das gesamte Datenbanksystem passen. Daher ist DBMS_REPAIR kein Zauberstab – Sie müssen immer noch feststellen, ob der von diesem Paket bereitgestellte Reparaturansatz das geeignete Werkzeug für jedes spezifische Korruptionsproblem ist. Abhängig von der Art der Reparatur können Daten verloren gehen und logische Inkonsistenzen können auftreten; Daher müssen Sie die mit der Verwendung von DBMS_REPAIR verbundenen Gewinne und Verluste abwägen.
DBMS_REPAIR-Paketinhalt
Tabelle 19-1 beschreibt die Prozeduren, aus denen das Paket DBMS_REPAIR besteht.
Tabelle 19-1 DBMS_REPAIR-Prozeduren
| Prozedurname | Beschreibung |
|---|---|
|
|
Erkennt und meldet Beschädigungen in einer Tabelle oder einem Index. |
|
|
Markiert Blöcke (die zuvor von der Prozedur |
|
|
Meldet Indexeinträge, die auf Zeilen in beschädigten Datenblöcken verweisen. |
|
|
Erstellt die Freelists eines Objekts neu. |
|
|
Bei Verwendung werden Blöcke ignoriert, die während Tabellen- und Indexscans als beschädigt markiert wurden. Wenn nicht verwendet, erhalten Sie den Fehler ORA-1578, wenn Sie auf Blöcke stoßen, die als beschädigt markiert sind. |
|
|
Bietet Verwaltungsfunktionen (Erstellen, Löschen, Bereinigen) für DBMS_REPAIR-Reparatur- und verwaiste Schlüsseltabellen. Hinweis: Diese Tabellen werden immer im SYS-Schema erstellt. |
Schritt 1: Erkennen und Melden von Beschädigungen
Ihre erste Aufgabe vor der Verwendung von DBMS_REPAIR sollte die Erkennung und Meldung von Beschädigungen sein. Die Meldung zeigt nicht nur an, was mit einem Block nicht stimmt, sondern identifiziert auch die zugehörige Reparaturanweisung. Sie haben neben DBMS_REPAIR mehrere Optionen, um Beschädigungen zu erkennen. Tabelle 19-2 beschreibt die verschiedenen Nachweismethoden.
Tabelle 19-2 Vergleich der Korruptionsnachweismethoden
| Nachweismethode | Beschreibung |
|---|---|
|
DBMS_REPAIR |
Führt eine Blockprüfung für eine angegebene Tabelle, Partition oder einen Index durch. Füllt eine Reparaturtabelle mit Ergebnissen. |
|
DB_VERIFY |
Externes Befehlszeilendienstprogramm, das die Blockprüfung in einer Offlinedatenbank durchführt. |
|
ANALYSIEREN |
Überprüft die Integrität der Struktur eines Index, einer Tabelle oder eines Clusters und überprüft, ob Ihre Tabellen und Indizes synchron sind. |
|
DB_BLOCK_CHECKING |
Identifiziert beschädigte Blöcke, bevor sie tatsächlich als beschädigt markiert werden. Überprüfungen werden durchgeführt, wenn Änderungen an einem Block vorgenommen werden. |
DBMS_REPAIR: Mit den Prozeduren check_object und admin_tables
Prüft und meldet die Prozedur check_object Blockfehler für ein angegebenes Objekt. Ähnlich wie bei der ANALYSE…VALIDATE STRUCTURE-Anweisung Für Indizes und Tabellen wird die Blockprüfung für Index- bzw.
Meldet nicht nur check_object Beschädigungen, sondern identifiziert auch alle Korrekturen, die auftreten würden, wenn fix_corrupt_blocks anschließend für das Objekt ausgeführt wird. Diese Informationen werden durch Auffüllen einer Reparaturtabelle bereitgestellt, die zuerst mit der Prozedur admin_tables erstellt werden muss.
Nachdem Sie die Prozedur check_object ausgeführt haben, zeigt eine einfache Abfrage in der Reparaturtabelle die Beschädigungen und Reparaturanweisungen für das Objekt an. Anhand dieser Informationen können Sie beurteilen, wie die gemeldeten Probleme am besten behoben werden können.
DB_VERIFY: Ausführen einer Offlinedatenbankprüfung
Normalerweise verwenden Sie DB_VERIFY als Offlinediagnosedienstprogramm, wenn Datenbeschädigungsprobleme auftreten.
Siehe auch: Weitere Informationen zu DB_VERIFY finden Sie unter Oracle8i-Dienstprogramme.
ANALYSIEREN: Korruptionsberichterstattung
Die ANALYSETABELLE…VALIDATE STRUCTURE-Anweisung validiert die Struktur des analysierten Objekts. Wenn Oracle die Struktur erfolgreich validiert, wird eine Nachricht zur Bestätigung der Validierung an Sie zurückgegeben. Wenn Oracle eine Beschädigung in der Struktur des Objekts feststellt, wird eine Fehlermeldung an Sie zurückgegeben. In diesem Fall würden Sie das Objekt löschen und neu erstellen.
Siehe auch: Weitere Informationen zur ANALYZE-Anweisung finden Sie in der Oracle8i-SQL-Referenz.
DB_BLOCK_CHECKING (Initialisierungsparameter für die Blockprüfung)
Sie können die Blockprüfung für Instanzen über den Parameter DB_BLOCK_CHECKING festlegen (der Standardwert ist TRUE). DB_BLOCK_CHECKING ist ein dynamischer Parameter, der durch die Anweisung ALTER SYSTEM SET geändert werden kann.
Schritt 2: Bewerten Sie die Kosten und den Nutzen der Verwendung von DBMS_REPAIR
Bevor Sie DBMS_REPAIR verwenden, müssen Sie die Vorteile seiner Verwendung in Bezug auf die Verbindlichkeiten abwägen; sie sollten auch andere verfügbare Optionen zum Adressieren beschädigter Objekte prüfen.
Ein erster Schritt besteht darin, die folgenden Fragen zu beantworten:
- Wie groß ist das Ausmaß der Korruption?
Um festzustellen, ob Beschädigungen und Reparaturaktionen vorliegen, führen Sie die Prozedur
check_objectaus und fragen Sie die Reparaturtabelle ab. - Welche anderen Optionen stehen zur Verfügung, um Blockfehler zu beheben?
Angenommen, die Daten sind aus einer anderen Quelle verfügbar, löschen Sie das Objekt, erstellen Sie es neu und füllen Sie es erneut aus. Eine andere Möglichkeit besteht darin, die TABELLE CREATE auszugeben…ALS SELECT-Anweisung aus der beschädigten Tabelle, um eine neue zu erstellen.
Sie können die Beschädigung ignorieren, indem Sie beschädigte Zeilen aus select-Anweisungen ausschließen.
Medienwiederherstellung durchführen.
- Welche logischen Beschädigungen oder Nebenwirkungen treten auf, wenn Sie DBMS_REPAIR verwenden, um ein Objekt verwendbar zu machen? Können diese angesprochen werden? Was ist der Aufwand, dies zu tun?
Möglicherweise haben Sie keinen Zugriff auf Zeilen in Blöcken, die als beschädigt markiert sind. Ein Block kann jedoch als beschädigt markiert werden, obwohl noch Zeilen vorhanden sind, auf die Sie gültig zugreifen können.
Referenzielle Integritätseinschränkungen können unterbrochen werden, wenn Blöcke als beschädigt markiert sind. In diesem Fall deaktivieren und aktivieren Sie die Einschränkung erneut. Nachdem Sie alle Probleme behoben haben, sollten Sie in der Lage sein, die Einschränkung erfolgreich wieder zu aktivieren.
Logische Beschädigung kann auftreten, wenn in der Tabelle Trigger definiert sind. Wenn beispielsweise Zeilen erneut eingefügt werden, sollten Einfügetrigger ausgelöst werden oder nicht? Sie können diese Probleme nur beheben, wenn Sie Trigger und deren Verwendung in Ihrer Installation verstehen.
Auf Freelist-Blöcke kann möglicherweise nicht zugegriffen werden. Wenn sich ein beschädigter Block an der Spitze oder am Ende einer Freelist befindet, wird die Freelist von Space Management neu initialisiert. Es kann dann Blöcke geben, die auf einer freelist stehen sollten, aber nicht. Sie können dies beheben, indem Sie die Prozedur
rebuild_freelistsausführen.Indizes und Tabellen sind möglicherweise nicht synchron. Sie können dies beheben, indem Sie zuerst die Prozedur
dump_orphan_keysausführen (um Informationen von den Schlüsseln zu erhalten, die beim Wiederherstellen beschädigter Daten nützlich sein können). Geben Sie dann die Anweisung ALTER INDEX REBUILD ONLINE aus, um die Tabelle und ihre Indizes wieder zu synchronisieren. - Wenn bei der Reparatur Daten verloren gehen, können diese Daten abgerufen werden?
Sie können Daten aus dem Index abrufen, wenn ein Datenblock als beschädigt markiert ist. Die
dump_orphan_keys-Prozeduren können Ihnen helfen, diese Informationen abzurufen. Natürlich hängt das Abrufen von Daten auf diese Weise von der Redundanz zwischen den Indizes und der Tabelle ab.
Schritt 3: Objekte verwendbar machen
In diesem Schritt macht DBMS_REPAIR das Objekt verwendbar, indem Beschädigungen während Tabellen- und Indexscans ignoriert werden.
Reparatur von Beschädigungen: Mit den Prozeduren fix_corrupt_blocks und skip_corrupt_blocks
machen Sie ein beschädigtes Objekt verwendbar, indem Sie eine Umgebung einrichten, in der Beschädigungen übersprungen werden, die außerhalb des Bereichs der Reparaturfunktionen von DBMS_REPAIR liegen.
Wenn Beschädigungen einen Datenverlust mit sich bringen, z. B. eine fehlerhafte Zeile in einem Datenblock, werden alle diese Blöcke durch die Prozedur fix_corrupt_blocks als beschädigt markiert. Dann können Sie die skip_corrupt_blocks -Prozedur ausführen, die Blöcke überspringt, die für das Objekt als korrupt markiert sind. Wenn skip gesetzt ist, überspringen Tabellen- und Index-Scans alle als beschädigt markierten Blöcke. Dies gilt sowohl für beschädigte Medien- als auch für Software-Blöcke.
Auswirkungen beim Überspringen beschädigter Blöcke
Wenn ein Index und eine Tabelle nicht synchron sind, kann eine schreibgeschützte SET-TRANSAKTION in Situationen inkonsistent sein, in denen eine Abfrage nur den Index und eine nachfolgende Abfrage sowohl den Index als auch die Tabelle überprüft. Wenn der Tabellenblock als beschädigt markiert ist, geben die beiden Abfragen unterschiedliche Ergebnisse zurück, wodurch die Regeln einer schreibgeschützten Transaktion verletzt werden. Eine Möglichkeit, dies zu erreichen, besteht darin, Beschädigungen nicht zu überspringen, wenn in einer FESTGELEGTEN TRANSAKTION NUR Lesetransaktion ausgeführt wird.
Ein ähnliches Problem tritt auf, wenn Zeilen ausgewählt werden, die verkettet sind. Im Wesentlichen kann eine Abfrage derselben Zeile auf dieselbe Zeile zugreifen oder nicht – wodurch unterschiedliche Ergebnisse erzielt werden.
Schritt 4: Reparieren von Beschädigungen und Wiederherstellen verlorener Daten
Nachdem Sie ein Objekt verwendbar gemacht haben, können Sie die folgenden Reparaturaktivitäten ausführen.
Wiederherstellen von Daten mithilfe der Prozeduren dump_orphan_keys
Die Prozedur dump_orphan_keys meldet Indexeinträge, die auf Zeilen in beschädigten Datenblöcken verweisen. Alle diese Indexeinträge werden in eine Tabelle mit verwaisten Schlüsseln eingefügt, in der der Schlüssel und die ROWID des Index gespeichert sind.
Nachdem die Indexeintragsinformationen abgerufen wurden, können Sie den Index mithilfe der Anweisung ALTER INDEX REBUILD ONLINE neu erstellen.
Freelists mit der Prozedur rebuild_freelists reparieren
Wenn ein Block mit der Bezeichnung „beschädigt“ am Anfang oder Ende einer Freelist gefunden wird, wird die Freelist neu initialisiert und ein Fehler zurückgegeben. Obwohl dadurch der fehlerhafte Block von der Freelist entfernt wird, verlieren Sie den Freelist-Zugriff auf alle Blöcke, die auf den beschädigten Block folgten.
Sie können die Prozedur rebuild_freelists verwenden, um die Freelists neu zu initialisieren. Das Objekt wird gescannt, und wenn ein Block in der Freelist enthalten sein soll, wird er zur Master-Freelist hinzugefügt. Freelist-Gruppen werden behandelt, indem die Blöcke gerecht verteilt werden – ein Block nach dem anderen. Alle Blöcke, die im Objekt als „beschädigt“ markiert sind, werden während der Neuerstellung ignoriert.
Einschränkungen und Einschränkungen
DBMS_REPAIR-Prozeduren haben die folgenden Einschränkungen:
- Tabellen mit LOBS, verschachtelten Tabellen und VARRAYS werden unterstützt, aber die Out-of-Line-Spalten werden ignoriert.
- Cluster werden in den Prozeduren
skip_corrupt_blocksundrebuild_freelistunterstützt, nicht jedoch in der Prozedurcheck_object. - Indexorganisierte Tabellen und LOB-Indizes werden nicht unterstützt.
- Die Prozedur
dump_orphan_keysarbeitet nicht mit Bitmap-Indizes oder funktionsbasierten Indizes. - Die Prozedur
dump_orphan_keysverarbeitet Schlüssel, die höchstens 3.950 Byte lang sind.
DBMS_REPAIR-Prozeduren
Dieser Abschnitt enthält detaillierte Beschreibungen der DBMS_REPAIR-Prozeduren.
check_object
Die Prozedur check_object überprüft die angegebenen Objekte und füllt die Reparaturtabelle mit Informationen zu Beschädigungen und Reparaturanweisungen. Die Validierung besteht aus der Blockprüfung aller Blöcke im Objekt. Sie können optional einen Bereich, Partitionsnamen oder Unterpartitionsnamen angeben, wenn Sie einen Teil eines Objekts überprüfen möchten.
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)
Tabelle 19-3 Die Prozedur check_object
| Argument | Beschreibung |
|---|---|
|
|
Schemaname des zu prüfenden Objekts. |
|
|
Name der zu prüfenden Tabelle oder des Index. |
|
|
Name der zu prüfenden Partition oder Unterpartition. Wenn dies ein partitioniertes Objekt ist und |
|
|
Typ des zu bearbeitenden Objekts. Muss entweder TABLE_OBJECT oder INDEX_OBJECT sein. Der Standardwert ist TABLE_OBJECT. |
|
|
Name der auszufüllenden Reparaturtabelle. Die Tabelle muss im SYS-Schema vorhanden sein. Verwenden Sie die Prozedur |
|
|
Reserviert für zukünftige Verwendung. |
|
|
Relative Dateinummer. Wird verwendet, wenn ein Blockbereich angegeben wird. |
|
|
Der erste zu verarbeitende Block, wenn ein Blockbereich angegeben wird. Kann nur angegeben werden, wenn das Objekt eine einzelne Tabelle, Partition oder Unterpartition ist. |
|
|
Der letzte zu verarbeitende Block, wenn ein Blockbereich angegeben wird. Kann nur angegeben werden, wenn das Objekt eine einzelne Tabelle, Partition oder Unterpartition ist. Wenn nur einer von block_start oder block_end angegeben ist, wird der andere standardmäßig auf den ersten bzw. letzten Block in der Datei gesetzt. |
|
|
Die Zahl der gemeldeten Korruption. |
fix_corrupt_blocks
Verwenden Sie diese Prozedur, um die beschädigten Blöcke in angegebenen Objekten basierend auf Informationen in der Reparaturtabelle zu beheben, die zuvor von der Prozedur check_object generiert wurden. Bevor Änderungen an einem Block vorgenommen werden, wird der Block überprüft, um sicherzustellen, dass der Block weiterhin beschädigt ist. Beschädigte Blöcke werden repariert, indem die Blocksoftware als beschädigt markiert wird. Wenn eine Reparatur durchgeführt wird, wird die zugehörige Zeile in der Reparaturtabelle mit einem Fix-Zeitstempel aktualisiert.
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)
Tabelle 19-4 Die Prozedur fix_corrupt_blocks
| Argument | Beschreibung |
|---|---|
|
|
Schemaname. |
|
|
Name des Objekts mit beschädigten Blöcken, die repariert werden sollen. |
|
|
Partitions- oder Unterpartitionsname, der verarbeitet werden soll. Wenn dies ein partitioniertes Objekt ist und |
|
|
Typ des zu bearbeitenden Objekts. Muss entweder TABLE_OBJECT oder INDEX_OBJECT sein. Der Standardwert ist TABLE_OBJECT. |
|
|
Name der Reparaturtabelle mit den Reparaturanweisungen. Muss im SYS-Schema vorhanden sein. |
|
|
Reserviert für zukünftige Verwendung. |
|
|
Die Anzahl der Blöcke festgelegt. |
dump_orphan_keys
Meldet Indexeinträge, die auf Zeilen in beschädigten Datenblöcken verweisen. Für jeden solchen Indexeintrag wird eine Zeile in die angegebene verwaiste Tabelle eingefügt.
Wenn die Reparaturtabelle angegeben ist, werden alle beschädigten Blöcke, die der Basistabelle zugeordnet sind, zusätzlich zu allen Datenblöcken behandelt, die als Software beschädigt markiert sind. Andernfalls werden nur Blöcke behandelt, die als beschädigt markiert sind.
Diese Informationen können für die Wiederherstellung verlorener Zeilen in der Tabelle und für Diagnosezwecke nützlich sein.
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)
Tabelle 19-5 Die Prozedur dump_orphan_keys
| Argument | Beschreibung |
|---|---|
|
|
Schemaname. |
|
|
Objektname. |
|
|
Partitions- oder Unterpartitionsname, der verarbeitet werden soll. Wenn dies ein partitioniertes Objekt ist und |
|
|
Typ des zu bearbeitenden Objekts. Der Standardwert ist INDEX_OBJECT. |
|
|
Name der Reparaturtabelle, die Informationen zu beschädigten Blöcken in der Basistabelle enthält. Die angegebene Tabelle muss im SYS-Schema vorhanden sein. Die Prozedur |
|
|
Name der Tabelle mit verwaisten Schlüsseln, die mit Informationen zu jedem Indexeintrag gefüllt werden soll, der auf eine Zeile in einem beschädigten Datenblock verweist. Die angegebene Tabelle muss im SYS-Schema vorhanden sein. Die Prozedur |
|
|
Anzahl der verarbeiteten Indexeinträge. |
rebuild_freelists
Erstellt die Freelists für das angegebene Objekt neu. Alle freien Blöcke werden auf der Master-Freelist platziert. Alle anderen Freelists werden auf Null gesetzt. Wenn das Objekt mehrere Freelist-Gruppen hat, werden die freien Blöcke auf alle Freelists verteilt und den verschiedenen Gruppen im Round-Robin-Modus zugewiesen.
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);
Tabelle 19-6 Die Prozedur rebuild_freelists
| Argument | Beschreibung |
|---|---|
|
|
Schemaname. |
|
|
Name des Objekts, dessen Freelists neu erstellt werden sollen. |
|
|
Partitions- oder Unterpartitionsname, dessen Listen neu erstellt werden sollen. Wenn dies ein partitioniertes Objekt ist und |
|
|
Typ des zu bearbeitenden Objekts. Muss entweder TABLE_OBJECT oder INDEX_OBJECT sein. Der Standardwert ist TABLE_OBJECT. |
skip_corrupt_blocks
Aktiviert oder deaktiviert das Überspringen beschädigter Blöcke während Index- und Tabellenscans des angegebenen Objekts. Wenn das Objekt eine Tabelle ist, gilt skip für die Tabelle und ihre Indizes. Wenn das Objekt ein Cluster ist, gilt es für alle Tabellen im Cluster und ihre jeweiligen Indizes.
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);
Tabelle 19-7 Die Prozedur skip_corrupt_blocks
| Argument | Beschreibung |
|---|---|
|
|
Schemaname des zu verarbeitenden Objekts. |
|
|
Name des Objekts. |
|
|
Partitions- oder Unterpartitionsname, der verarbeitet werden soll. Wenn dies ein partitioniertes Objekt ist und |
|
|
Typ des zu bearbeitenden Objekts. Muss entweder TABLE_OBJECT oder CLUSTER_OBJECT sein. Der Standardwert ist TABLE_OBJECT. |
|
|
Wenn SKIP_FLAG angegeben ist, wird das Überspringen von Softwarefehlblöcken für das Objekt während Index- und Tabellenscans aktiviert. Wenn NOSKIP_FLAG angegeben ist, geben Scans, die auf Software-beschädigte Blöcke stoßen, einen ORA-1578 zurück. |
admin_tables
Bietet Verwaltungsfunktionen für Reparatur- und verwaiste Schlüsseltabellen.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
Tabelle 19-8 Die Prozedur admin_tables
| Argument | Beschreibung |
|---|---|
|
|
Name der zu verarbeitenden Tabelle. Der Standardwert ist ‚ORPHAN_KEY_TABLE‘ oder ‚REPAIR_TABLE‘ basierend auf dem angegebenen table_type. Wenn angegeben, muss der Tabellenname das entsprechende Präfix ‚ORPHAN_‘ oder ‚REPAIR_‘ haben. |
|
|
Der Typ der Tabelle muss ORPHAN_TABLE oder REPAIR_TABLE sein. |
|
|
Gibt an, welche Verwaltungsaktion ausgeführt werden soll. Muss CREATE_ACTION, PURGE_ACTION oder DROP_ACTION sein. Wenn die Tabelle bereits vorhanden ist und CREATE_ACTION angegeben ist, wird ein Fehler zurückgegeben. PURGE_ACTION gibt an, dass alle Zeilen in der Tabelle gelöscht werden sollen, die nicht vorhandenen Objekten zugeordnet sind. Wenn die Tabelle nicht existiert und DROP_ACTION angegeben ist, wird ein Fehler zurückgegeben. Wenn CREATE_ACTION und DROP_ACTION angegeben sind, wird eine zugeordnete Ansicht mit dem Namen DBA_<table_name> erstellt bzw. gelöscht. Die Ansicht ist so definiert, dass Zeilen, die nicht vorhandenen Objekten zugeordnet sind, eliminiert werden. Im SYS-Schema erstellt. |
|
|
Gibt den Tablespace an, der beim Erstellen einer Tabelle verwendet werden soll. Standardmäßig wird der Standard-Tablespace von SYS verwendet. Ein Fehler wird zurückgegeben, wenn der Tablespace angegeben ist und die Aktion nicht CREATE_ACTION lautet. |
DBMS_REPAIR Ausnahmen
| 942 | reparaturtabelle existiert nicht |
| 1418 | der angegebene Index ist nicht vorhanden |
| 24120 | ungültiger Parameter |
| 24121 | CASCADE_FLAG und ein Blockbereich können nicht angegeben werden |
| 24122 | ungültiger Blockbereich |
| 24124 | ungültiger Aktionsparameter angegeben |
| 24126 | CASCADE_FLAG angegeben und Objekt ist keine Tabelle |
| 24127 | tablespace angegeben und action ist nicht CREATE_ACTION |
| 24128 | partition für nicht partitioniertes Objekt angegeben |
| 24129 | ungültiger Name der Orphan Key-Tabelle – muss das Präfix ‚ORPHAN_‘ haben |
| 24129 | die angegebene Reparaturtabelle beginnt nicht mit dem Präfix ‚REPAIR_‘ |
| 24131 | Reparaturtabelle hat falsche Spalten |
| 24132 | repair Tabellenname ist zu lang |