Présentation
Les Sauvegardes 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 (contient une description de tous les fichiers de la base )
- 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) qui contiennent une trace de toutes les modifications effectuées
rem : l’archivage des REDOLOGs est optionnel MAIS …OBLIGATOIRE !
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
Zoom sur 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
Vérification du mode courant :
SQL> SELECT log_mode FROM v$database; LOG_MODE -------- ARCHIVELOG -- Le cas échéant passer en mode ARCHIVELOG : SQL> SHUTDOWN IMMEDIATE ; (ou NORMAL mais pas ABORT !) SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;
On pourra éventuellement positionner des paramètres supplémentaires comme le répertoire destination, le multiplexage éventuel ou le format du nom de fichier
log_archive_dest_1 = “location=C:OracleoradataTESTarchive”
log_archive_format = %%ORACLE_SID%%T%TS%S.ARC
puis arrêt / redémarrage de la base.
* 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 ARCHIVE LOG LIST :
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 12
Next log sequence to archive 14
Current log sequence 14
en version 11 USE_DB_RECOVERY indique que c’est la flashback_area qui est utilisée pour stocker les archives. Si on veut + d’infos on peut voir les parametres DB_RECOVERY_FILE_DEST et DB_RECOVERY_FILE_SIZE :
SQL> SHOW PARAMETER DB_RECOVERY_FILE
NAME TYPE VALUE------------------------- ----------- ------------------------------ db_recovery_file_dest string /oracle/flash_recovery_area db_recovery_file_dest_size big integer 3000M
On voit donc ici l'emplacement de la flashback area et sa taille de 3GO.
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 le verra de multiplexer les logs archivés pour (encore et toujours) plus de sécurité
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
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
