Discussion :

[Ikebukuro]

Salut,

J'avais lu qu'une base Oracle pouvait avoir plusieurs incarnations. Une incarnation c'est la base entre deux SCN qui valent 0.
Ces SCN sont remis à 0 quand on fait un ALTER DATABSE OPEN RESETLOG; quand, par exemple, on recrée le control file.

Dans un bouquin sur Oracle 11 j'avais lu que l'incarnation était un des concepts les plus difficiles d'Oracle.
Le pb est que dans plus aucun livre, sur la 12, on aborde ce concept.

J'avais compris aussi que, jusqu'à la 10 inclue, suite à cette remise à 0, il fallait refaire un backup RMAN complet de la base car les sauvegarde de la précédente incarnation n'étaient plus accessibles.
Depuis Oracle 11 ce ne serait plus le cas; est-ce que vous me confirmez que avec Oracle 11 ou 12, on n'a plus cette limitation RMAN sur les sauvegardes non accessibles et qu'on peut "oublier" cette notion?

[Pomalaix]

J'aime bien parler de réincarnation d'une base, c'est à dire d'une nouvelle vie.
La vie d'une base, c'est simplement la succession des transactions qui ont lieu.

Une nouvelle incarnation débute effectivement lorsque la base est ouverte avec l'option RESETLOGS. Celle-ci a notamment pour effet de vider les fichiers redo logs, et de faire redémarrer à zéro la numérotation des SCN.
Avant Oracle 10g, le RESETLOGS avait pour conséquence que l'on perdait de manière définitive les transactions figurant dans les fichiers redologs de statut courant ou actif. En cas de restauration, un RECOVER pouvait être bloqué à cause de l'absence de ces transactions.
A partir de la 10g, le RESETLOGS s'accompagne d'une précaution automatique : les fichiers redologs sont systématiquement archivés (il faut évidemment être en mode ARCHIVELOG), ce qui fait que dans la séquences des archivelogs avant et après le RESETLOGS, on n'a aucun manque. C'est ce qui permet de faire des restaurations relativement transparentes à la notion de RESETLOGS et donc d'incarnation.

Même si la gestion des incarnations est facilitée, on ne peut pas l'ignorer pour autant. Un SCN, par exemple 1234, n'est pas une notion assez précise. Il faut dire SCN 1234 vis à vis de l'incarnation 1, ou de l'incarnation 2, etc. C'est comme si on parlait de facture N°17 sans préciser l'année, alors qu'on a une facture N°17 en 2019 et en 2020.
Donc il y a encore des cas où il faut préciser à RMAN de quelle incarnation on parle avant de lui demander de revenir à tel ou tel SCN.

[Ikebukuro]

Encore un gros merci

[pachot]

Hello, Ce n'est pas le SCN qui est mis à zéro mais le numéro de séquence des threads de redo log. D'ailleurs, dans V$DATABASE on trouve le Resetlogs SCN.
Le SCN ne diminue jamais. il ne peut qu'augmenter. C'est un indicateur de temps. On peut avoir des nouvelles vies, mais pas remonter le temps

[Ikebukuro]

Ah oui, ce n'est pas le SCN qui est réinitialisé... pourtant sur le net l'erreur est courante.