La sauvegarde à chaud signifie que le système est opérationnel et que les mises à jour se déroulent comme d'habitude
J'expliquerais ici le mécanisme de suivi par Oracle lors de la sauvegarde à chaud
Sauvegarde à chaud manuelle
Démarrage manuel de la sauvegarde à chaud avec la commande ci-dessous pour un tablespace
alter tablespace USERS commencer la sauvegarde ;
Peu de choses se produisent à ce moment-là
1) DBWn contrôle l'espace de table (écrit tous les blocs modifiés à partir d'un SCN donné)
2) CKPT arrête de mettre à jour le champ Checkpoint SCN dans les en-têtes de fichier de données et commence à mettre à jour le champ Hot Backup Checkpoint SCN à la place
Les en-têtes de fichier de données qui contiennent le SCN du dernier point de contrôle terminé ne sont pas mis à jour lorsqu'un fichier est en mode de sauvegarde à chaud . Cela permet au processus de récupération de comprendre quels fichiers de journalisation d'archives pourraient être nécessaires pour récupérer complètement ce fichier.
3)LGWR commence à enregistrer des images complètes des blocs modifiés la première fois qu'un bloc est modifié après avoir été écrit par DBWn
La première fois qu'un bloc est modifié dans un fichier de données en mode de sauvegarde à chaud, le bloc entier est écrit dans le redo log files, pas seulement les octets modifiés. Normalement, seuls les octets modifiés (un vecteur de rétablissement) sont écrits. En mode de sauvegarde à chaud, le bloc entier est enregistré la première fois. En effet, vous pouvez vous retrouver dans une situation où le processus copiant le fichier de données et DBWR travaillent simultanément sur le même bloc.
Disons qu'ils le sont et que le facteur de lecture bloquant le système d'exploitation est de 2K . Le programme de sauvegarde va lire un bloc Oracle 8k. Le système d'exploitation lui donne 4k. Pendant ce temps — DBWR a demandé de réécrire ce bloc. le système d'exploitation planifie l'écriture DBWR pour qu'elle se produise immédiatement. Le bloc 8k entier est réécrit. Le programme de sauvegarde redémarre (OS multitâche ici) et lit les derniers 4k du bloc. Le programme de sauvegarde a maintenant un bloc fracturé - la tête et la queue proviennent de deux points dans le temps.
Oracle ne peut pas gérer cela pendant la récupération. Par conséquent, nous enregistrons l'intégralité de l'image du bloc afin que lors de la récupération, ce bloc soit totalement réécrit à partir de redo et soit au moins cohérent avec lui-même. Nous pouvons le récupérer à partir de là.
Point important dans la sauvegarde à chaud
1)Pour limiter l'effet de cette journalisation supplémentaire, vous devez vous assurer de ne placer qu'un tablepspace à la fois en mode de sauvegarde et de sortir le tablespace du mode de sauvegarde dès que vous l'avez sauvegardé. Cela réduira au minimum possible le nombre de blocs devant être enregistrés.
2) Si l'espace de table est en mode hotbackup et que la base de données est abandonnée. Et puis vous essayez de démarrer, il se plaindra de la récupération car le fichier de données SCN de cet espace de table sera plus ancien, puis pour démarrer la base de données, nous devons d'abord terminer la sauvegarde de cet espace de table. Il met simplement à jour le SCN du point de contrôle avec le SCN du point de contrôle de sauvegarde à chaud
Sauvegarde du gestionnaire de récupération
Nous n'avons pas besoin de mettre l'espace de table en mode hotbackup pour effectuer la sauvegarde à l'aide du mode hotback
Étant donné que RMAN est un outil Oracle, ils savent comment gérer le cas de bloc fracturé, donc il n'écrit pas de fragments de bloc ou blocs partiels à la sauvegarde, il écrit l'image complète du bloc cohérent sur le support de sauvegarde. Ainsi, le gestionnaire de récupération n'a pas besoin d'enregistrer le bloc complet dans le fichier de journalisation. Cela signifie donc une énorme économie de journalisation à partir d'un cas de sauvegarde manuelle
De plus, rman ne gèle pas l'en-tête du fichier de données, il continue à effectuer un point de contrôle tout aussi régulièrement, mais il effectue un point de contrôle sur l'espace de table.
La sauvegarde RMAN note le SCN de départ, Absolute Fuzzy SCN (qui est le même que le SCN de départ au début) lorsque la sauvegarde commence et que les blocs sont sauvegardés dans le fichier de données, le bloc est vérifié pour le SCN, s'il est plus élevé que le démarrage SCN, Absolute Fuzzy SCN est mis à jour avec ce numéro. Il en va de même pour tous les blocs, lorsque l'ensemble du fichier de données est sauvegardé, ces deux numéros sont stockés dans l'en-tête de sauvegarde.
Ainsi, chaque fois que RMAN a restauré ces sauvegardes, ils savent qu'il sait de quel SCN du début à la fin du SCN, il doit récupérer le fichier de données à coup sûr
Donc, fondamentalement, il n'y a pas de surcharge comme l'augmentation de la journalisation dans la sauvegarde à chaud RMAN.
Il en va de même pour la sauvegarde d'image avec RMAN
