-
1. Le sens du rétablissement
Lorsque nous utilisons une base de données, nous espérons toujours que le contenu de la base de données est fiable et correct. Cependant, les pannes du système informatique (pannes matérielles, pannes de réseau, pannes de processus et pannes du système) affectent le fonctionnement du système de base de données et l'exactitude des données. les données de la base de données, voire détruire sexuellement la base de données, entraînant la perte de tout ou partie des données de la base de données. Par conséquent, lorsque l'échec ci-dessus se produit, on espère qu'une base de données complète pourra être rétablie. Ce processus est appelé récupération de base de données. Le sous-système de récupération est une partie importante du système de gestion de base de données. Le processus de récupération varie en fonction de la structure affectée par le type de panne survenue.
2. Méthode de récupération
Méthode IMPORTATION :
Utilisez IMPORT pour IMPORTER le dernier fichier de données exporté vers la nouvelle base de données. Cette méthode peut restaurer n'importe quel objet de base de données à l'état dans lequel il a été exporté, et les modifications ultérieures seront irréversibles. La commande IMPORT peut être exécutée de manière interactive. Pour la signification spécifique de chaque paramètre, voir l'explication détaillée des paramètres ORACLE EXP/IMP. Cette méthode convient aux environnements qui n'utilisent pas le mode archive.
Méthodes de récupération sécurisées :
Si la base de données s'exécute en mode archive, une fois la base de données endommagée, elle peut être restaurée à l'état de point d'arrêt via une sauvegarde à froid (sauvegarde à chaud) et une sauvegarde d'archive.
Récupération du fichier de contrôle de la base de données (en supposant que tous les fichiers de contrôle soient détruits) :
La base de données est basée sur le système de fichiers : utilisez simplement les commandes tar, cp et autres du système d'exploitation.
La base de données est basée sur les appareils bruts : dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1 seek=12
Récupération de fichiers de données de base de données
Récupération des espaces table de données et d'index et des espaces table système :
Copiez les fichiers de base de données pertinents et tous les fichiers journaux logiques générés depuis la sauvegarde du fichier de données et exécutez la commande suivante :
svrmgrl > montage de démarrage
svrmgrl > modifier la récupération automatique de la base de données
Si le fichier de contrôle est endommagé, alors : svrmgrl > modifier la récupération de la base de données à l'aide du fichier de contrôle de sauvegarde ; Entrez le nom du fichier journal et le nom du fichier redolog lorsque vous y êtes invité.
svrmgrl > modifier les journaux de réinitialisation ouverts de la base de données ;
Récupération des fichiers temporaires de la base de données et des espaces de table de restauration : il suffit de les mettre hors ligne et de les reconstruire.
Remarque : Si la base de données ne s'exécute pas en mode archive, la récupération peut uniquement restaurer l'état de la dernière sauvegarde. Pour plus d'informations sur les paramètres du mode d'archivage et les technologies liées à la sauvegarde, voir Technologie de sauvegarde de base de données ORACLE.
3. Solution de récupération d'espace table ORACLE
(1) Phénomène d’erreur d’espace table des ménages :
ORA-01157, ORA-01110 ou une erreur au niveau du système d'exploitation se produit lors du démarrage de la base de données
Des erreurs telles que ORA-07360, lors de l'arrêt de la base de données (en utilisant l'arrêt normal ou l'arrêt immédiat), entraîneront des erreurs ORA-01116, ORA-01110 et une erreur au niveau du système d'exploitation ORA-07368.
résoudre:
Il existe deux solutions ci-dessous :
Solution 1 : l'espace table de l'utilisateur peut être facilement reconstruit, c'est-à-dire que les objets récemment exportés sont disponibles ou que les objets de l'espace table peuvent être facilement reconstruits, etc. Dans ce cas, le moyen le plus simple consiste à se déconnecter et à supprimer les fichiers de données, à supprimer le tablespace et à reconstruire le tablespace et tous les objets.
svrmgrl> montage de démarrage
svrmgrl> modifier le nom du fichier de données du fichier de données de la base de données, dépôt hors ligne ;
svrmgrl> modifier la base de données ouverte ;
svrmgrl> supprime le tablespace nom_table, y compris le contenu ;
Reconstruisez le tablespace et tous les objets.
Solution 2 : l'espace table de l'utilisateur ne peut pas être facilement reconstruit. Dans la plupart des cas, la reconstruction de l'espace table est impossible et trop laborieuse. La méthode consiste à inverser la sauvegarde et à effectuer une récupération de support. Si votre système fonctionne en mode NOARCHIVELOG, alors uniquement. les données perdues peuvent être récupérées dans le journal de rétablissement en ligne.
Les étapes sont les suivantes :
1) Restaurer le fichier de données perdu à partir d'une sauvegarde
2)svrmgrl> montage de démarrage
3)svrmgrl> sélectionnez v1.group#,member,sequence#,first_change# dans v$log v1,v$logfile v2 où v1.group#=v2.group# ;
4) Si la base de données s'exécute en mode NOARCHIVELOG : svrmgrl> select file#,change# from v$recover_file ;
Si CHANGE# est supérieur au minimum FIRST_CHANGE#, le fichier de données peut être restauré.
Si CHANGE# est inférieur au minimum FIRST_CHANGE#, le fichier de données n'est pas récupérable. Restaurez la sauvegarde complète la plus récente ou utilisez la première option.
5)svrmgrl> récupérer le nom du fichier de données ;
6) Confirmez que la récupération est réussie
7)svrmgrl> modifier les journaux de réinitialisation ouverts de la base de données ;
Il n'est pas nécessaire d'effectuer une récupération de support pour les espaces table en lecture seule, il suffit de restaurer la sauvegarde. Les seules exceptions sont :
L'espace table a été modifié en mode lecture-écriture après la dernière sauvegarde. L'espace table a été modifié en mode lecture seule après la dernière sauvegarde. Dans ce cas, une récupération de support est requise.
(2) Espace table temporaire L'espace table temporaire ne contient pas de données réelles. La méthode de récupération consiste à supprimer l'espace table temporaire et à le reconstruire.
(3) Si la sauvegarde de l'espace table système n'est pas disponible, la seule méthode peut être de reconstruire la base de données.
(4) Il existe deux situations pour restaurer l'espace table :
1. La base de données a été complètement arrêtée (utilisez la commande shutdown immédiat ou shutdown)
1) Confirmez que la base de données est complètement fermée
2) Modifiez le fichier init.ora et commentez "rollback-segment"
3) svrmgrl> démarrage restreindre le montage
4) svrmgrl> modifier le nom du fichier de données de la base de données hors ligne ;
5) svrmgrl> modifier la base de données ouverte ;
Sur la base des résultats qui apparaissent : "instruction traitée" allez à (7) ; "ORA-00604,ORA-00376,ORA-01110" allez à (6)
6) svrmgrl> arrêt immédiat
Modifiez le fichier init.ora et ajoutez la ligne suivante : _corrupted_rollback_segments = (<roll1>,...<rolln>)
svrmgrl> restriction de démarrage
7) svrmgrl> supprimez le tablespace tablespace_name, y compris le contenu ;
8) Reconstruire l'espace table et le segment de restauration
9) svrmgrl> modifier le système pour désactiver la session restreinte ;
10) Modifier le fichier init.ora
2. La base de données n'est pas complètement fermée (la base de données plante ou la commande shutdown abort est utilisée pour fermer la base de données)
1) Restaurer la sauvegarde
2) svrmgrl> montage de démarrage
3) svrmgrl> sélectionnez le numéro de fichier, le nom et le statut dans v$datafile ;
svrmgrl> modifier le nom du fichier de données de la base de données en ligne ;
4) svrmgrl> sélectionnez v1.group#,member,sequence#,first_change# dans v$log v1,v$logfile v2 où v1.group#=v2.group# ;
5) svrmgrl> sélectionnez le fichier#,change# depuis v$recover_file #Voir la solution 2-4 ;
6) svrmgrl> récupérer le nom du fichier de données ;
7) svrmgrl> modifier la base de données ouverte ;
3. La base de données est ouverte
1) Supprimez le segment de restauration et l'espace table
2) Reconstruire l'espace table et le segment de restauration (5), contrôler la récupération des fichiers
1. Tous les fichiers de contrôle sont détruits. Copiez les fichiers de contrôle de sauvegarde dans le répertoire d'origine pour RAW DEVICE (périphérique nu), puis : dd if='con.bak' of='/dev/rdrd/drd1' seek=128.
2. Tous les fichiers de contrôle ne sont pas détruits. Utilisez d'autres fichiers de contrôle pour démarrer la base de données (6), enregistrez les blocs de données et les données qu'ils contiennent. Phénomène : une erreur ORA-01578 se produit lors de l'exécution de l'opération ORACLE. Analyse : une erreur ORA-1578 se produit lorsque ORACLE. considère qu'un bloc de données peut être corrompu et peut se produire pour les raisons suivantes :
Dommages au matériel ou au micrologiciel d'E/S Défaillance d'E/S ou de cache du système d'exploitation Erreur de mémoire ou d'échange de page Une partie du fichier de données est écrasée Tentative d'accès à un disque bloc non formaté Réparer Autres causes Étapes de solution :
Vérifiez les fichiers journaux et de trace pour voir s'il existe d'autres erreurs ou erreurs de positionnement :
sql>select * from v$datafile où file#=<F> ;
sql> sélectionnez propriétaire, nom_segment, type_segment dans dba_extents où file_id=<F> et <B> entre block_id et block_id+blocks-1 ;
Basé sur le segment_type renvoyé :
Le type de segment est temporaire ou cache ou n'a pas de valeur de retour. Vérifiez si l'instruction SQL est correcte.
Si le type de segment est un segment d'annulation, le bloc de données doit être restauré.
Le type de segment est index, vérifiez la table où il se trouve. Reconstruisez simplement l'index.
sql> sélectionnez le propriétaire, nom_table dans dba_tables où nom_cluster = nom_du_segment
L'erreur 1578 persiste et la base de données doit être restaurée.
Le type de segment est un tableau et enregistre les données dans le tableau.
Analyser si une entité présente une corruption permanente des données
sql> analyser la table table.name valider la cascade de structure ;
sql> analyser le nom du cluster de la table valider la cascade de la structure ;
Base de données de récupération d'erreur matérielle exécutée en mode ARCHIVE
Copie du fichier de données correspondant HORS LIGNE, fichier de données de sauvegarde
renommer le fichier de données vers un nouvel emplacement
récupérer le fichier de données à l'aide du journal d'archive
La base de données de fichiers de données en ligne s'exécute en mode non-ARCHIVE
HORS LIGNELe fichier de données correspondant copie le fichier de données sauvegardé, renomme le fichier de données et le met en ligne
Enregistrez les données dans le tableau, par exemple : sql>select * from bigemp;
ERREUR : ORA-01578 : bloc de données ORACLE corrompu (fichier n° 8, bloc n° 8147) ORA-00110 : fichier de données 8 : '/oracle/usr714.dbf' … … identifiant de fichier corrompu : 8 = 8 (hex) identifiant de bloc corrompu : 8147=1fd3(hex) premier rowid du bloc corrompu : 0000.1fd3.0000.0008 dernier rowid du bloc corrompu : 0000.1fd2.7fff.0008 premier rowid après ce bloc : 0000.1fd4.0000.0008
sql > créer une table temporaire en tant que select * from bigemp où 1=2 ;
sql > insérer dans temp select * from bigemp /*+rowid(bigemp) */ où rowid >='0000.1fd4.0000.0008';
sql > insérer dans temp select * from bigemp où rowid <='0000.1fd2.7fff.0008';
Dans les versions antérieures à ORACLE 7.1, lorsqu'il n'existe pas d'analyse de plage de rowid, le même objectif que ci-dessus peut être atteint grâce à l'indexation.
4. Post-scriptum
La technologie de sauvegarde et de récupération d'ORACLE peut être considérée comme étendue et approfondie. Je n'en connais qu'une petite partie, et elle n'est pas très complète. J'espère que ces articles pourront être utiles à tout le monde. Vous êtes également invités à partager votre expérience en matière de sauvegarde. et récupération. Dites-moi le problème, je vais l'organiser et le publier ici pour référence de tous les amis DBA et administrateurs de données qui souhaitent le faire. Peut-être que votre petit effort sauvera une entreprise !
En même temps, je voudrais rappeler à tous mes amis que la sauvegarde est très, très, très, très, très, très, très, très, très importante. . . Surtout, si possible, vous devez utiliser le mode ARCHIVE, sinon quelque chose risque de mal se passer et vous ne pourrez même pas pleurer.