Pourquoi faire le backup à chaud d'une base tablespace par tablespace ?

Quand le tablespace est en BEGIN BACKUP, la première modification d’une ligne dans bloc déterminera l’écriture de tout son contenu dans le redo log (et non une information concernant les modifications uniquement). Les mises à jours ultérieures provoquent des écritures standard, et ceci jusqu'à l’écriture du bloc modifié sur disque (checkpoint, end backup, etc.). Dans cet état, il est souhaitable qu’il n’y ait pas une activité débordante du tablespace considéré. Ceci induit aussi la nécessité de ne pas démarrer un hot backup avec tous les tablespaces en mode BEGIN BACKUP, mais faire les copies une après l’autre en ayant un seul tablespace en BEGIN BACKUP à la fois.

Au début d’un hot backup, les SCN mis lors du checkpoint provoqué par BEGIN BACKUP est conservé et les entêtes des fichiers constituant le tablespace contient une information de hot backup.

Pourquoi écrire des blocs entiers dans les redo logs ? Pour calibrer une éventuelle image floue d’un bloc. Lors de la copie du fichier, l’OS lira les données en unités de blocs OS dont les blocs Oracle sont des multiples. Pendant la restauration, la manière dont les blocs sont lus risque de ne pas être celle qu’Oracle attend. Pour éviter ce genre de confusion, Oracle répertorie des blocs entiers. Le paramètre (non documenté) _LOG_BLOCKS_DURING_BACKUP = TRUE permet de ne pas répertorier des blocs entiers dans les redo dans le cas d’égalité entre la taille du bloc Oracle et le bloc OS.

Voir aussi ..\div\hotbackupstrategie.doc.html

Et aussi ..\brain\beginbackup.html