Oracle fournit différentes méthodes pour détecter et corriger la corruption de bloc de données. Une méthode consiste à déposer et à recréer un objet après la détection de la corruption; cependant, ce n’est pas toujours possible ou souhaitable. Si la corruption de bloc de données est limitée à un sous-ensemble de lignes, une autre option consiste à reconstruire la table en sélectionnant toutes les données à l’exception des lignes corrompues.
Une autre façon de gérer la corruption des blocs de données consiste à utiliser le package DBMS_REPAIR. Vous pouvez utiliser DBMS_REPAIR pour détecter et réparer les blocs corrompus dans les tables et les index. En utilisant cette approche, vous pouvez traiter les corruptions dans la mesure du possible et continuer à utiliser des objets pendant que vous tentez de les reconstruire ou de les réparer. DBMS_REPAIR utilise l’approche suivante pour traiter les corruptions:
- Étape 1: Détecter et signaler les Corruptions
- Étape 2: Évaluer les Coûts et les Avantages de l’Utilisation de DBMS_REPAIR
- Étape 3: Rendre les Objets Utilisables
- Étape 4: Réparer les Corruptions et Reconstruire les Données perdues
Remarque:
Toute corruption impliquant la perte de données nécessite une analyse et une compréhension de la manière dont ces données s’intègrent dans le système de base de données global. Par conséquent, DBMS_REPAIR n’est pas une baguette magiqueyou vous devez toujours déterminer si l’approche de réparation fournie par ce package est l’outil approprié pour chaque problème de corruption spécifique. Selon la nature de la réparation, vous risquez de perdre des données et des incohérences logiques peuvent être introduites ; vous devez donc peser les gains et les pertes associés à l’utilisation de DBMS_REPAIR.
Contenu du package DBMS_REPAIR
Le tableau 19-1 décrit les procédures qui composent le package DBMS_REPAIR.
Tableau 19-1 Procédures de réparation de DBMS_
| Nom de la procédure | Description |
|---|---|
|
|
Détecte et signale les corruptions dans une table ou un index. |
|
|
Marque les blocs (précédemment identifiés par la procédure |
|
|
Signale les entrées d’index qui pointent vers des lignes dans des blocs de données corrompus. |
|
|
Reconstruit les pigistes d’un objet. |
|
|
Lorsqu’il est utilisé, ignore les blocs marqués corrompus lors des analyses de table et d’index. S’il n’est pas utilisé, vous obtenez l’erreur ORA-1578 lorsque vous rencontrez des blocs marqués corrompus. |
|
|
Fournit des fonctions administratives (créer, supprimer, purger) pour les tables de réparation DBMS_REPAIR et les tables de clés orphelines. Remarque : Ces tables sont toujours créées dans le schéma SYS. |
Étape 1: Détecter et signaler les corruptions
Votre première tâche, avant d’utiliser DBMS_REPAIR, devrait être la détection et le signalement des corruptions. Les rapports indiquent non seulement ce qui ne va pas avec un bloc, mais identifient également la directive de réparation associée. Vous avez plusieurs options, en plus de DBMS_REPAIR, pour détecter les corruptions. Le tableau 19-2 décrit les différentes méthodologies de détection.
Tableau 19-2 Comparaison des Méthodes de Détection de la corruption
| Méthode de détection | Description |
|---|---|
|
DBMS_RÉPARER |
Effectue une vérification de bloc pour une table, une partition ou un index spécifié. Remplit une table de réparation avec les résultats. |
|
DB_VÉRIFIER |
Utilitaire de ligne de commande externe qui effectue une vérification de bloc sur une base de données hors ligne. |
|
ANALYSER |
Utilisé avec l’option VALIDER LA STRUCTURE, vérifie l’intégrité de la structure d’un index, d’une table ou d’un cluster ; vérifie ou vérifie que vos tables et index sont synchronisés. |
|
DB_BLOCK_VÉRIFIER |
Identifie les blocs corrompus avant qu’ils ne soient réellement marqués corrompus. Des vérifications sont effectuées lorsque des modifications sont apportées à un bloc. |
DBMS_REPAIR : À l’aide des procédures check_object et admin_tables
La procédure check_object vérifie et signale les corruptions pour un objet spécifié. Similaire à l’ANALYSE…VALIDER l’instruction STRUCTURE pour les index et les tables, la vérification des blocs est effectuée pour les blocs d’index et de données respectivement.
Non seulement check_object signale les corruptions, mais il identifie également les correctifs qui se produiraient si fix_corrupt_blocks est ensuite exécuté sur l’objet. Ces informations sont rendues disponibles en remplissant une table de réparation, qui doit d’abord être créée par la procédure admin_tables.
Après avoir exécuté la procédure check_object , une simple requête sur la table de réparation affiche les corruptions et les directives de réparation pour l’objet. Avec ces informations, vous pouvez évaluer la meilleure façon de résoudre les problèmes signalés.
DB_VERIFY : Effectuer une vérification de base de données hors ligne
En règle générale, vous utilisez DB_VERIFY comme utilitaire de diagnostic hors ligne lorsque vous rencontrez des problèmes de corruption de données.
Voir Aussi: Pour plus d’informations sur DB_VERIFY, consultez Utilitaires Oracle8i.
ANALYSER : Rapports de corruption
Le TABLEAU ANALYSER…L’instruction VALIDATE STRUCTURE valide la structure de l’objet analysé. Si Oracle valide avec succès la structure, un message confirmant sa validation vous est renvoyé. Si Oracle rencontre une corruption dans la structure de l’objet, un message d’erreur vous est renvoyé. Dans ce cas, vous déposez et recréez l’objet.
Voir Aussi : Pour plus d’informations sur l’instruction ANALYZE, consultez la référence SQL Oracle8i.
DB_BLOCK_CHECKING (Paramètre d’initialisation de la vérification de bloc)
Vous pouvez définir la vérification de bloc pour les instances via le paramètre DB_BLOCK_CHECKING (la valeur par défaut est TRUE) ; cela vérifie les données et les blocs d’index chaque fois qu’ils sont modifiés. DB_BLOCK_CHECKING est un paramètre dynamique, modifiable par l’instruction ALTER SYSTEM SET.
Étape 2: Évaluer les coûts et les avantages de l’utilisation de DBMS_REPAIR
Avant d’utiliser DBMS_REPAIR, vous devez peser les avantages de son utilisation par rapport aux passifs; vous devriez également examiner d’autres options disponibles pour traiter les objets corrompus.
Une première étape consiste à répondre aux questions suivantes:
- Quelle est l’ampleur de la corruption ?
Pour déterminer s’il y a des corruptions et des actions de réparation, exécutez la procédure
check_objectet interrogez la table de réparation. - Quelles autres options sont disponibles pour traiter les corruptions de blocs ?
En supposant que les données sont disponibles à partir d’une autre source, supprimez, recréez et remplissez à nouveau l’objet. Une autre option consiste à émettre la TABLE CREATE…COMME instruction SELECT de la table corrompue pour en créer une nouvelle.
Vous pouvez ignorer la corruption en excluant les lignes corrompues des instructions select.
Effectuez une récupération de support.
- Quelles corruptions logiques ou effets secondaires seront introduits lorsque vous utiliserez DBMS_REPAIR pour rendre un objet utilisable ? Peut-on y remédier? Quel est l’effort requis pour le faire?
Vous n’avez peut-être pas accès aux lignes des blocs marqués corrompus. Cependant, un bloc peut être marqué corrompu même s’il reste des lignes auxquelles vous pouvez accéder valablement.
Les contraintes d’intégrité référentielle peuvent être brisées lorsque les blocs sont marqués corrompus. Si cela se produit, désactivez et réactivez la contrainte ; toute incohérence sera signalée. Après avoir résolu tous les problèmes, vous devriez pouvoir réactiver la contrainte avec succès.
Une corruption logique peut se produire lorsqu’il y a des déclencheurs définis sur la table. Par exemple, si des lignes sont réinsérées, les déclencheurs d’insertion doivent-ils être déclenchés ou non ? Vous ne pouvez résoudre ces problèmes que si vous comprenez les déclencheurs et leur utilisation dans votre installation.
Les blocs Freelist peuvent être inaccessibles. Si un bloc corrompu est à la tête ou à la queue d’un pigiste, la gestion de l’espace réinitialise le pigiste. Il peut alors y avoir des blocs qui devraient être sur un pigiste, qui ne le sont pas. Vous pouvez résoudre ce problème en exécutant la procédure
rebuild_freelists.Les index et les tables peuvent être désynchronisés. Vous pouvez résoudre ce problème en exécutant d’abord la procédure
dump_orphan_keys(pour obtenir des informations à partir des clés qui pourraient être utiles pour reconstruire des données corrompues). Émettez ensuite l’instruction EN LIGNE ALTER INDEX REBUILD pour synchroniser la table et ses index. - Si la réparation implique une perte de données, ces données peuvent-elles être récupérées?
Vous pouvez récupérer des données de l’index lorsqu’un bloc de données est marqué corrompu. Les procédures
dump_orphan_keyspeuvent vous aider à récupérer ces informations. Bien entendu, la récupération de données de cette manière dépend de la redondance entre les index et la table.
Étape 3: Rendre les objets utilisables
Dans cette étape, DBMS_REPAIR rend l’objet utilisable en ignorant les corruptions lors des analyses de table et d’index.
Réparation de corruption: En utilisant les procédures fix_corrupt_blocks et skip_corrupt_blocks
, vous rendez un objet corrompu utilisable en établissant un environnement qui ignore les corruptions qui restent en dehors de la portée des capacités de réparation de DBMS_REPAIR.
Si les corruptions impliquent une perte de données, telle qu’une mauvaise ligne dans un bloc de données, tous ces blocs sont marqués corrompus par la procédure fix_corrupt_blocks. Ensuite, vous pouvez exécuter la procédure skip_corrupt_blocks, qui ignorera les blocs marqués corrompus pour l’objet. Lorsque skip est défini, les analyses de table et d’index ignorent tous les blocs marqués corrompus. Cela s’applique aux blocs corrompus de médias et de logiciels.
Implications lors du saut de blocs corrompus
Si un index et une table ne sont pas synchronisés, une transaction EN LECTURE SEULE de transaction DÉFINIE peut être incohérente dans les situations où une requête sonde uniquement l’index, puis une requête suivante sonde à la fois l’index et la table. Si le bloc de table est marqué corrompu, les deux requêtes renverront des résultats différents, enfreignant ainsi les règles d’une transaction en lecture seule. Une façon d’aborder cela est de ne pas ignorer les corruptions lors d’une transaction DÉFINIE EN LECTURE SEULE.
Un problème similaire se produit lors de la sélection de lignes enchaînées. Essentiellement, une requête de la même ligne peut ou non accéder à la corruption giving donnant ainsi des résultats différents.
Étape 4: Réparer les corruptions et Reconstruire les données perdues
Après avoir rendu un objet utilisable, vous pouvez effectuer les activités de réparation suivantes.
Récupérer des données À l’aide des procédures dump_orphan_keys
La procédure dump_orphan_keys signale les entrées d’index qui pointent vers des lignes dans des blocs de données corrompus. Toutes ces entrées d’index sont insérées dans une table de clés orphelines qui stocke la clé et l’identifiant de ligne de la corruption.
Une fois les informations d’entrée d’index récupérées, vous pouvez reconstruire l’index à l’aide de l’instruction EN ligne ALTER INDEX REBUILD.
Réparez les Freelists À l’aide de la procédure rebuild_freelists
Lorsqu’un bloc marqué « corrompu » est trouvé à la tête ou à la queue d’un freelist, le freelist est réinitialisé et une erreur est renvoyée. Bien que cela supprime le bloc incriminé du freelist, cela vous fait perdre l’accès du freelist à tous les blocs qui ont suivi le bloc corrompu.
Vous pouvez utiliser la procédure rebuild_freelists pour réinitialiser les pigistes. L’objet est scanné, et s’il est approprié qu’un bloc soit sur le freelist, il est ajouté au freelist maître. Les groupes de pigistes sont gérés en rencontrant les blocs de manière équitable – un bloc à la fois. Tous les blocs marqués « corrompus » dans l’objet sont ignorés lors de la reconstruction.
Limitations et restrictions
Les procédures DBMS_REPAIR ont les limitations suivantes:
- Les tables avec des LOBS, des tables imbriquées et des VARRAYS sont prises en charge, mais les colonnes hors ligne sont ignorées. Les clusters
- sont pris en charge dans les procédures
skip_corrupt_blocksetrebuild_freelist, mais pas dans la procédurecheck_object. - Les tables organisées par index et les index LOB ne sont pas pris en charge.
- La procédure
dump_orphan_keysne fonctionne pas sur des index bitmap ou des index basés sur des fonctions. - La procédure
dump_orphan_keystraite les clés d’une longueur maximale de 3 950 octets.
Procédures DBMS_REPAIR
Cette section contient des descriptions détaillées des procédures DBMS_REPAIR.
check_object
La procédure check_object vérifie les objets spécifiés et remplit la table de réparation avec des informations sur les corruptions et les directives de réparation. La validation consiste à vérifier par bloc tous les blocs de l’objet. Vous pouvez éventuellement spécifier une plage, un nom de partition ou un nom de sous-partition lorsque vous souhaitez vérifier une partie d’un objet.
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)
Tableau 19-3 La procédure check_object
| Argument | Description |
|---|---|
|
|
Nom du schéma de l’objet à vérifier. |
|
|
Nom de la table ou de l’index à vérifier. |
|
|
Nom de la partition ou de la sous-partition à vérifier. S’il s’agit d’un objet partitionné et que |
|
|
Type de l’objet à traiter. Doit être TABLE_OBJECT ou INDEX_OBJECT. La valeur par défaut est TABLE_OBJECT. |
|
|
Nom de la table de réparation à remplir. La table doit exister dans le schéma SYS. Utilisez la procédure |
|
|
Réservé pour une utilisation future. |
|
|
Numéro de dossier relatif. Utilisé lors de la spécification d’une plage de blocs. |
|
|
Le premier bloc à traiter si vous spécifiez une plage de blocs. Ne peut être spécifié que si l’objet est une seule table, partition ou sous-partition. |
|
|
Le dernier bloc à traiter si vous spécifiez une plage de blocs. Ne peut être spécifié que si l’objet est une seule table, partition ou sous-partition. Si un seul des block_start ou block_end est spécifié, l’autre par défaut est le premier ou le dernier bloc du fichier respectivement. |
|
|
Le nombre de corruptions signalées. |
fix_corrupt_blocks
Utilisez cette procédure pour corriger les blocs corrompus dans des objets spécifiés en fonction des informations de la table de réparation précédemment générées par la procédure check_object. Avant d’effectuer une modification à un bloc, le bloc est vérifié pour s’assurer qu’il est toujours corrompu. Les blocs corrompus sont réparés en marquant le logiciel de bloc corrompu. Lorsqu’une réparation est effectuée, la ligne associée dans la table de réparation est mise à jour avec un horodatage fixe.
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)
Tableau 19-4 La procédure fix_corrupt_blocks
| Argument | Description |
|---|---|
|
|
Nom du schéma. |
|
|
Nom de l’objet avec des blocs corrompus à corriger. |
|
|
Nom de la partition ou de la sous-partition à traiter. S’il s’agit d’un objet partitionné et que |
|
|
Type de l’objet à traiter. Doit être TABLE_OBJECT ou INDEX_OBJECT. La valeur par défaut est TABLE_OBJECT. |
|
|
Nom de la table de réparation avec les directives de réparation. Doit exister dans le schéma SYS. |
|
|
Réservé pour une utilisation future. |
|
|
Le nombre de blocs fixes. |
dump_orphan_keys
Signale les entrées d’index qui pointent vers des lignes dans des blocs de données corrompus. Pour chaque entrée d’index rencontrée, une ligne est insérée dans la table orpheline spécifiée.
Si la table de réparation est spécifiée, tous les blocs corrompus associés à la table de base sont gérés en plus de tous les blocs de données marqués corrompus par logiciel. Sinon, seuls les blocs marqués corrompus sont traités.
Ces informations peuvent être utiles pour reconstruire les lignes perdues dans le tableau et à des fins de diagnostic.
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)
Tableau 19-5 La procédure dump_orphan_keys
| Argument | Description |
|---|---|
|
|
Nom du schéma. |
|
|
Nom de l’objet. |
|
|
Nom de la partition ou de la sous-partition à traiter. S’il s’agit d’un objet partitionné et que |
|
|
Type de l’objet à traiter. La valeur par défaut est INDEX_OBJECT. |
|
|
Nom de la table de réparation contenant des informations sur les blocs corrompus dans la table de base. La table spécifiée doit exister dans le schéma SYS. La procédure |
|
|
Nom de la table de clés orphelines à remplir avec des informations concernant chaque entrée d’index faisant référence à une ligne d’un bloc de données corrompu. La table spécifiée doit exister dans le schéma SYS. La procédure |
|
|
Nombre d’entrées d’index traitées. |
rebuild_freelists
Reconstruit les freelists pour l’objet spécifié. Tous les blocs libres sont placés sur le maître freelist. Tous les autres pigistes sont mis à zéro. Si l’objet a plusieurs groupes de pigistes, les blocs libres sont répartis entre tous les pigistes, en les allouant aux différents groupes de manière 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);
Tableau 19-6 Procédure rebuild_freelists
| Argument | Description |
|---|---|
|
|
Nom du schéma. |
|
|
Nom de l’objet dont les pigistes doivent être reconstruits. |
|
|
Nom de partition ou de sous-partition dont les pigistes doivent être reconstruits. S’il s’agit d’un objet partitionné et que |
|
|
Type de l’objet à traiter. Doit être TABLE_OBJECT ou INDEX_OBJECT. La valeur par défaut est TABLE_OBJECT. |
skip_corrupt_blocks
Active ou désactive le saut de blocs corrompus lors des analyses d’index et de table de l’objet spécifié. Lorsque l’objet est une table, skip s’applique à la table et à ses index. Lorsque l’objet est un cluster, il s’applique à toutes les tables du cluster et à leurs index respectifs.
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);
Tableau 19-7 La procédure skip_corrupt_blocks
| Argument | Description |
|---|---|
|
|
Nom du schéma de l’objet à traiter. |
|
|
Nom de l’objet. |
|
|
Nom de la partition ou de la sous-partition à traiter. S’il s’agit d’un objet partitionné et que |
|
|
Type de l’objet à traiter. Doit être TABLE_OBJECT ou CLUSTER_OBJECT. La valeur par défaut est TABLE_OBJECT. |
|
|
Si SKIP_FLAG est spécifié, active le saut des blocs corrompus logiciels pour l’objet lors des analyses d’index et de table. Si NOSKIP_FLAG est spécifié, les analyses qui rencontrent des blocs corrompus par le logiciel renvoient un ORA-1578. |
admin_tables
Fournit des fonctions administratives pour la réparation et les tables de clés orphelines.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
Tableau 19-8 La procédure admin_tables
| Argument | Description |
|---|---|
|
|
Nom de la table à traiter. La valeur par défaut est ‘ORPHAN_KEY_TABLE’ ou ‘REPAIR_TABLE’ en fonction du type de table spécifié. Lorsqu’il est spécifié, le nom de la table doit avoir le préfixe approprié, ‘ORPHAN_’ ou ‘REPAIR_’. |
|
|
Type de table, doit être l’un des ORPHAN_TABLE ou REPAIR_TABLE. |
|
|
Indique quelle action administrative effectuer. Doit être CREATE_ACTION, PURGE_ACTION ou DROP_ACTION. Si la table existe déjà et que CREATE_ACTION est spécifiée, une erreur est renvoyée. PURGE_ACTION indique de supprimer toutes les lignes de la table associées à des objets inexistants. Si la table n’existe pas et que DROP_ACTION est spécifiée, une erreur est renvoyée. Lorsque CREATE_ACTION et DROP_ACTION sont spécifiées, une vue associée nommée DBA_<table_name > est créée et supprimée respectivement. La vue est définie de sorte que les lignes associées à des objets inexistants soient éliminées. Créé dans le schéma SYS. |
|
|
Indique l’espace de table à utiliser lors de la création d’une table. Par défaut, l’espace de table par défaut de SYS est utilisé. Une erreur est renvoyée si l’espace de table est spécifié et que l’action n’est pas CREATE_ACTION. |
Exceptions DBMS_REPAIR
| 942 | la table de réparation n’existe pas |
| 1418 | l’index spécifié n’existe pas |
| 24120 | paramètre non valide |
| 24121 | impossible de spécifier CASCADE_FLAG et une plage de blocs |
| 24122 | plage de blocs non valide |
| 24124 | paramètre d’action non valide spécifié |
| 24126 | CASCADE_FLAG spécifié et l’objet n’est pas une table |
| 24127 | espace de table spécifié et l’action n’est pas CREATE_ACTION |
| 24128 | partition spécifiée pour un objet non partitionné |
| 24129 | nom de table de clé orpheline non valide – doit avoir le préfixe ‘ORPHAN_’ |
| 24129 | la table de réparation spécifiée ne commence pas par le préfixe ‘REPAIR_’ |
| 24131 | la table de réparation a des colonnes incorrectes |
| 24132 | le nom de la table de réparation est trop long |