web-dev-qa-db-fra.com

RMAN-06054: Récupération des médias demandant un journal archivé inconnu, où est conservé le SCN?

J'ai la situation suivante:

  1. Les sauvegardes de DB1 (situées sur SRV1 serveur) La base de données est effectuée tous les jours à 1h00.

  2. J'ai pris des fichiers sauvegardés (Datafile, Archivelog, Controlfile, SPFILE) du 24/10/2011 et les restauré sur le serveur SRV2.

  3. Lors de la récupération du fichier journal Oracle requis:

    RMAN-06054: Récupération des médias demandant un journal archivé inconnu pour le fil 1 avec séquence 228 et démarrage du SCN de 26651733

  4. J'ai cherché ce logfile sur le serveur srv1 et la copié sur le serveur SRV2. L'enregistré avec la base de données et exécuter recover database commandez à nouveau. Toujours la même erreur, mais avec un autre numéro de séquence et SCN.

    RMAN-06054: Récupération des médias demandant un journal archivé inconnu pour le fil 1 avec la séquence 229 et le démarrage du SCN de 26654944

Ces archives sont générées après le 24/10/2011, la sauvegarde de cette date ne devrait pas savoir sur les archives plus récentes. Je peux définir la récupération jusqu'à cette séquence, mais je me demande simplement de savoir où est-ce que SCN stocké? Pourquoi mon oracle nécessite-t-il de nouveaux Archivelogs?

Serveur srv1 et srv2 ne sont pas en contact avec l'autre.

Merci beaucoup.

oraclebackuprecoveryrmanerror-handling
6
kupa

Chaque fichier journal de journal de redo (et fichier journal de redo archivé) contient le SCN de départ et la fin du SCN. Au cas où il s'agissait d'un dernier Redo, le SCN finissant est 0xFFFFFFFFFFFFFFF.

nap01:~/oradata/jt10g$ strings redo01.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000004, SCN 0x0000000b05b5-0x0000000bd34f

nap01:~/oradata/jt10g$ strings redo02.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000005, SCN 0x0000000bd34f-0x0000000bf612

nap01:~/oradata/jt10g$ strings redo03.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000006, SCN 0x0000000bf612-0xffffffffffff

Jusqu'à ce que la base de données voit 0xFFFFFFFFFFFFF, il continue de demander des journaux supplémentaires. Mais ce n'est pas un problème, vous pouvez spécifier jusqu'à SCN ou jusqu'à ce que vous puissiez annuler pour votre récupération (cela signifie que vous ne voulez pas une récupération complète, en d'autres termes, vous souhaitez perdre certaines données récentes).

6
kubanczyk

En complétant la réponse de @kubanczyk, qui est très bonne.

Lorsque vous publiez la commande Récupérer la base de données, le RDBMS essaiera une récupération complète, ce qui signifie qu'il recherchera les journaux archivés commençant par le SCN (fil et séquence) de la Sauvegarde restaurée et appliquez chaque journal archivé jusqu'à ce qu'il atteigne le journal de redo "actif" de la base de données d'origine. C'est pourquoi vous obtenez cette erreur.

Donc, votre meilleur choix que @kubanczyk posté est d'utiliser Récupérer la base de données jusqu'à annuler qui est une récupération incomplète jusqu'au journal archivé le plus récent (contigu).

Cela devrait faire l'affaire.

J'espère que cela clarifie un peu le processus de restauration/récupération.

Quant à l'autre partie de la question

Où est gardé le SCN?

Le SCN (numéro de changement de système) est conservé dans le fichier de contrôle et les en-têtes de chaque Datafile, uit permet à la base de données de savoir quels datafiles sont synchronisés et où le rédacteur de base de données DBWR doit effectuer les écrivies suivantes à partir du cache tampon de base de données.

Chaque sauvegarde est également "marquée" avec un SCN (et une séquence thread) pour permettre au processus RMAN connaître l'exact "temps" ceux qui ont été pris.

J'espère que cela t'aides.

2
Silvarion