Présentation

Les  Sauvegarde et restauration, permettent de se prémunir plus ou moins parfaitement de la perte accidentelle de données physique, fichier de données ou autre.
Principaux cas de figure : corruption de fichier, perte de fichier , perte de disque.

Elle assurent la fiabilité des données un domaine parmi d’autres de la sécurité des données.

remarque : de manière détournée, les sauvegardes logiques ou physiques peuvent être utilisées pour transférer / dupliquer des données pour un tout autre but que la fiabilité des données.
Par exemple :

• maintien de base de test à jour
• copie de BD pour infocentre ou Business Intelligence
• mise en production
• etc

Elles obéissent à une stratégie :

• Quoi sauvegarder : totalité, tablespace, uniquement les données sensibles, etc.
• Quand : fréquence pluri quotidienne, quotidienne, hebdomadaire, etc.
• Comment : à froid, à chaud, physiquement, logiquement

et répondent à des contraintes :

• disponibité des données : haute, moyenne, basse
• importance relative de certaines données
• temps de reprise
• volume maximum de perte supporté
• économie (par exemple la très haute disponibilité coute cher…)

Les grandes catégories de sauvegarde

• Sauvegardes physiques totale

Elle se fait ‘à froid’, c’est à dire base fermée. Elle est simple et rapide (dépend seulement de la taille des fichiers et de la vitesse des disques). Elle n’est pas ‘divisible’ par définition.

On sauvegarde les fichiers physiques (au niveau OS donc) de la base de données. TOUS les fichiers physiques : les fichiers de données bien sûr mais aussi les fichioers de paramétrage (SPFile et init.ora) , de controle, fichiers journaux (REDO Logs)…

• Sauvegarde physique partielle

On sauvegarde uniquement certains tablespaces (et donc tous les ficheirs physiques qu’il contient). SI un tablepace correspond à une application pariculière, on sauvegarde donc toutes les données de cette application. La liste des fichiers d’un tablespace est donnée dans le dictionnaire.
Peut se faire à chaud ou à froid.

• Sauvegarde logique totale ou partielle

On sauvegarde soit du SQL (CREATE TABLE + INSERT en général),
soit dans un format spécifique, grace à l’utilitaire EXPORT ou aux procédure DATAPUMP.
L’intérêt de cette méthode est sa granularité. On peut sauvegarder une table, qq tables, les données d’un schéma, ou une certaine catégorie d’objets connexes (vues, index, droits…)

remarques :

1) l’export et le datapump Oracle ne sont utilisables…que par l’IMPORT ou le datapump Oracle
2) les fichier SQL peut etre utilisé par un autre SGBD (MySQL, SQLServer) à la conformité au standard SQL près…
3) un utilisateur Lamda peut faire ses propres extractions

Voir le chapitre sur les transferts de données pour plus d’infos

Rappel sur la structure physique d’une base Oracle

Les principaux composants physques de la base (fichiers) sont résumés dans le schéma ci-après:

Il y a en gros au strict minimum :

• 1 control file
• des fichiers de  données système (pour TBS system, sysaux, undo, temp,…)
• des fichiers de données utilisateur ou applicatifs (users, compta, RH, clients,…)
• 1 fichier de paramètres d’initialisation (spfile)
• 2 fichiers journaux (redolog)

rem : les fichiers archive log sont optionnels.

Infos utiles du dictionnaire sur la base et ses fichiers

v$database
description générale de la base
DBA_TABLESPACES
description des tablespaces et fichiers
DBA_DATA_FILES
description des fichiers de données
v$logfile
description des redologsz
v$log_history
info sur l’historique de tous les redos issus du control file
v$log
infos sur les groupes et les membres
v$parameter
TOUS les parametres d’init de l’instance, y compris CONTROL_FILES…
v$controlfile
nom des control files

Les cas de récupération automatique

Certains problèmes ne relèvent pas de la perte de données physiques, mais plutôt de la perte d’information en mémoire centrale : interruption d’une transaction par exemple. Ces problèmes sont automatiquement résolus par Oracle :
- echec d’un ordre SQL : provoque une erreur d’execution documentée
- echec de process client (interruption du client, pb réseau, arrêt du shadow process) : provoque un Rollback de la transaction
- echec de l’instance (arrêt d’un process de fond du serveur, arrêt CPU serveur) : provoque un Rollback immédiat ou différé (au redémarrage de la base…)

remarque : certains dispositifs matériels : disques miroir, CPUs redondants, machines à très haute disponibilité, etc. peuvent prendre en charge de manière automatique et transparente les pertes de données physiques, sans passer par un processus de sauvegarde / restauration.

Principes d’organisation et de répartition :

multiplexages des fichiers de contrôle

séparation des fichiers de données et des fichiers redologs sur des disques différents -

CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’e:/data/oratest_log1a’) SIZE 500K,
GROUP 2 (’e:/data/oratest_log2a’) SIZE 500K;

create tablespace TB1 datafile ‘d:dataoradata1.dbf’ size 100M’;

ici on crée un nouveau Tablespace (et donc un fichier de données) sur le même disque que le fichier du tablespace ‘SYSTEM’ qui contient le dictionnaire. Ce n’est peut être pas une bonne idée en terme de performances…

multiplexage des fichiers de controle

pour ce faire il suffit de déclarer plusieurs fichiers de controle, sur des disques différents. Les mises à jour éventuelles par le noyau Oracle seront faites simultanément dans tous les fichiers. En cas de perte il suffira de recopier un des autres control file et de le renommer avec le nom du fichier perdu, puis de redémarrer la base.
la liste des fichiers de contrôle est spécifié dans le fichier de démarrage de la base : INIT.ORA
ex :
INIT_test.ora
DB_NAME = TEST
CONTROL_FILES = (/disk1/test_ctl1.ora, /disk2/test_ctl2.ora)

multiplexage des journaux (redo log files)

On a vu que l’écriture dans les redo logs files est circulaire.
Au minimum une base doit contenir 2 groupes de un fichier.
Pour permettre l’écriture simultanée de plusieurs redo logs et ainsi les sécuriser, on crée 2 fichiers ou plus par groupe.

exemple :

le minimum, 2 groupes contenant chacun un fichier (pas de multiplexage donc…)
CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’) SIZE 500K;

un peu mieux, LGWR va écrire simultanément dans les 2 fichiers du groupe courant
CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’, ‘e:dataoratest_log1b’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’, ‘e:dataoratest_log2b’) SIZE 500K;

protection max : ceinture ET bretelles (on écrit dans 3 fichiers en même temps)

CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’, ‘e:dataoratest_log1b’ , ‘f:dataoratest_log1b’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’, ‘e:dataoratest_log2b’ , ‘f:dataoratest_log1b’) SIZE 500K;

si on veut augmenter le temps de rebouclage du cycle d’écriture, ou en d’autres termes augmenter le délai avant écrasement éventuel du contenu du 1er journal, on peut rajouter des groupes supplémentaires…

Multiplexage des logs ARCHIVES

on utilise le paramètre LOG_ARCHIVE_DEST_n (où n est un entier de 1 à 5)
LOG_ARCHIVE_DEST_1 = ‘LOCATION=/disk1/arc/’
LOG_ARCHIVE_DEST_2 = ‘LOCATION=/disk2/arc/’
LOG_ARCHIVE_DEST_3 = ‘LOCATION=/disk3/arc/’
avec le format suivant
LOG_ARCHIVE_FORMAT = arch%t_%s.arc

on aura le résultat suivant (thread 1; log sequence de 100 à 102)

/disk1/arc/arch1_100.arc, /disk1/arc/arch1_101.arc, /disk1/arc/arch1_102.arc,
/disk2/arc/arch1_100.arc, /disk2/arc/arch1_101.arc, /disk2/arc/arch1_102.arc,
/disk3/arc/arch1_100.arc, /disk3/arc/arch1_101.arc, /disk3/arc/arch1_102.arc

l’archivage des redologs files

Ce processus (process ARCH ou “ARCHIVER”) est optionnel et permet de faire des restaurations les plus à jour possible.
En l’absence d’archivage, on ne pourra récupérer les données que de la dernière sauvegarde. Avec l’archivage on récupérera ces mêmes données + les modifications qui ont été faites entre la sauvegarde et le crash. (seules les transactions en cours au moment du crash sont perdues).L’archivage permet de garder tout l’historique des fichiers redologs, qui sont recopier sur le répertoire d’archivage dès qu’ils sont pleins (Switch).
Si on n’archive pas les redologs sont écrasés cycliquement, puisque rappelons le, ils sont utilisés de manière séquentielle et circulaire !

* mise en place de l’archivage
autorisation de l’archivage automatique dans INIT.ORA (reg : ORA_TEST_PFILE)
log_archive_start = true
log_archive_dest_1 = “location=C:OracleoradataTESTarchive”
log_archive_format = %%ORACLE_SID%%T%TS%S.ARC
puis arrêt / redémarrage de la base.
Il est possible d’autoriser l’archivage automatique de manière dynamique (sans arrêter la base) :
SQL> ALTER SYSTEM ARCHIVE LOG START;

* déclenchement du mode archivage
SQL> CONNECT INTERNAL
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG
SQL> ALTER DATABASE OPEN

* vérification de l’archivage (remplissage ou forcage des logs switchs)
SQL> ALTER SYSTEM SWITCH LOGFILE
voir log_archive_dest_1 et log_archive_format pour voir où les fichiers d’archive créés sur le disque

on peut également vérifier le statut de l’archivage avec la commande :
SQL> ARCHIVELOG LIST

Attention à la prolifération des LOGS archivés, notamment en cas de grosse procédure batch de mise à jour, il est conseillé de désactiver l’archivage !
Il est conseillé également de purger les archives après chaque nouvelle sauvegarde réussie !

Il est possible comme on l’a vu plus haut de multiplexer les logs archivés pour (encore et toujours) plus de sécurité

Principe général de restauration physique

Le principe est d’avoir sous la main une sauvegarde plus ou moins ancienne et de disposer d’un historique de toutes les modifications effectuées depuis cette sauvegarde. Ceci grace aux redolog en ligne et si nécessaire aux redologs archivés.

Une fois que les fichiers nécessaires sont restaurés, le DBA doit initier une restauration du support  (media recovery).
Pour que cette restauration assure des données cohérentes, Ceci implique notamment des mécanismes d’application d’image après et d’image avant ( rollforward and rollback ). Les modifications à appliquer sont choisies sélectivement à partir des redolog online et offline (archivés) et s’appuie sur les no SCN indiquant des points de cohérence dans le temps.

restauration du control file perdu

en cas de perte d’un control file il suffira
d’arreter la base,
de vérifier les spécifications des fichiers de controle dans l’ INIT.ORA,
de recopier le fichier manquant à partir d’un de ses jumeaux dans le répertoire de destination,
et de rouvrir la base