Discussion :

[Léortien]

Bonjour,

J'ai lu à de nombreux endroits qu'il était nécessaire d'avoir sa base de données en mode ARCHIVELOG pour pouvoir faire une sauvegarde à chaud.
(par exemple dans cet excellent tutoriel http://oracle.developpez.com/guide/s...eneralites/#L3 où il est expliqué que "les changements qui ont lieu durant la phase de sauvegarde d'un tablespace donnent lieu à une consignation dans le flux de reprise...").

Cependant les changements pendant et après la sauvegarde ne seront pas appliqués lors de la restauration.
(la base de données pointe vers des fichiers hors base qui sont aussi modifiés par l'application et donc la sauvegarde pour être cohérente doit sauvegarder la base et les fichiers au même instant... et impensable d'arrêter l'application...).

Est ce que dans mon cas le mode ARCHIVELOG est obligatoire pour la sauvegarde à chaud?
(Etant donné que les fichiers absoluments nécessaires pour une restauration sont les datafiles et un fichier de contrôle (cf ce post-ci) je me pose la question).



Merci de m'avoir lu et désolé d'avoir été si long pour une seule question.

[orafrance]

d'abord ce n'est pas tout à fait exacte puisque RMAN n'a pas besoin d'archives et la base est dispo si je ne m'abuse.

En fait la sauvegarde à chaud consiste juste à copier les fichiers à une instant t. Ce qui va te permettre de redémarrer ta base en cas de restauration ce sont les archive log, en effet, la copie de tes fichiers ne suffit pas à avoir une base consitante (transaction en cours pendant la copie, heure de sauvegarde différente entre le 1° et dernier fichier sauvé, etc...). L'archive log est une copie du redolog réalisée à chaque checkpoint. Ainsi, si tu as les archives générées depuis le début de la sauvegarde, tu peux restaurer ce que tu veux (avant, pendant et après sauvegarde).

Ce qu'il faut retenir : la copie de fichier (datafile, tempfile et controlfile) ne sert à rien sans l'intelligence de la base qui est dans les redolog et archivelog.

[Léortien]

Oui tu as tout a fait raison pour RMAN (c'est d'ailleurs un des avantages indiqués dans le RMAN User's Guide pour le préférer à la méthode à laquelle je pensais cad le chapitre 3.2 du tutoriel que j'indiquais).

J'avoue que naïvement j'esperais que la commande
"PROMPT alter system switch logfile ;;" permettait de forcer l'écriture dans la base de ce qui était en mémoire et donc d'avoir une base consistante juste avant la mise en mode backup des tablespaces (en me relisant je me dis que je n'avais pas assez détaillé à mon message d'avant).


Je vais donc me tourner vers RMAN alors (je suis entouré de gens plutôt allergiques aux modifications).
Merci.

[orafrance]

ce qui n'est pas commité n'est pas dans les redos... donc un checkpoint ne te garanti pas la cohérence de données... CQFD

[Léortien]

Ok! Je viens de comprendre mon erreur de compréhension, cela force l'écriture sur disque de ce qui est en mémoire mais pas dans les fichiers que j'espérais.

Merci.
Bon je vais mettre en résolu, même si c'est agréable d'en comprendre un peu plus à chacun de tes passages

[orafrance]

à ton service

[pifor]

ce qui n'est pas commité n'est pas dans les redos...

Je crois qu'il y a des cas où des données peuvent être dans les redo logs avant le COMMIT: http://www.developpez.net/forums/sho...ht=redo+commit

[orafrance]

Et bien, bouyao a écrit : "Après un commit Oracle écrite dans les fichiers redo"

Je vais essayer de trouver la doc mais pour moi c'est pas dans les redos tant que c'est pas committé. D'ailleurs sans UNDO on ne peut pas restaurer une base qui aurait des transactions en cours

[pifor]

Voir aussi ce qu'il a écrit dans son message du 22/08/2006, 19h27:

J'ai dit en géneral :


Citation:
Les enregistrements redo peuvent aussi être écrits dans le fichier redo avant que la transaction correspondante soit validée. Si le buffer redo log est plein ou une autre transaction à été validée, LGWR vide toutes les entrées redo du buffer redo log dans le fichier redo, bien que certain enregistrements redo ne devrait pas être validés. Si nécessaire, oracle peut annuler ces changements.



Voir : http://mbouayoun.developpez.com/fichredo/#LI.1.

[orafrance]

en effet

[guigui_cwoco]

Selon ma source (Livre OCA Admin I de Sybex)

Je reformule en francais (je ne peux copier/coller cette source)

LGWR écrit les infos du RedoLog Buffer vers les fichiers Redo Log selon certaines circonstances :

* Quand un utilisateur 'commit' une transaction
* Quand le RedoLog Buffer est 1/3 plein
* Quand le RedoLog Buffer contient environ 1MB de données

[orafrance]

oui mais Oracle écrit dans le redo log buffer dés qu'une transaction est exécutée

Donc, le redo log buffer peut contenir des infos qui seront rollbackées

[remi4444]

pour moi c'est une simple question de bon sens... si toutes les données devaient rester stockées en mémoire avant le commit, ça voudrait dire que la mémoire devrait être au moins égale à l'espace UNDO, ce qui est quand meme un peut exigeant comme contrainte!

[orafrance]

le redolog buffer ne contient pas les mêmes infos que le UNDO et il est copier dans le redolog file si besoin. On utilise Shareplex qui est une sorte de standby database et on voit très bien des transactions rollbackées alors qu'il ne fait que jouer les redos... ce qui prouve bien que les redoslogs contiennent des transactions "invalides"