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.
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
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...)
| Nom de la vue | infos |
| 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 |
Certains problèmes ne relèvent pas de la perte de données
physique, 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) : provoqhe un Rollback immédiat ou différé
(au redémarrage de la base...)remarque : certains dispositifs matériel
: disques mirroir, 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.
+ un fichier d'initialisation ou de paramétrage (init file) et
optionnellement un fichier de mot de passe (password file) et des fichiers
d'archivage des journaux
>>
pour + de détails, voir les fichiers
physiques d'Oracle du chapitre DBA / Architecture
CREATE DATABASE test DATAFILE 'd:\dataora\test_system'
SIZE 10M
LOGFILE GROUP 1 ('e:\dataora\test_log1a') SIZE 500K,
GROUP 2 ('e:\dataora\test_log2a') SIZE 500K;
create tablespace TB1 datafile 'd:\dataora\data1.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...
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) |
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:\dataora\test_system' SIZE
10M
LOGFILE GROUP 1 ('d:\dataora\test_log1a') SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a') SIZE 500K;
un peu mieux, LGWR va ecrire simultanément dans les 2 fichiers du groupe courant
CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE
10M
LOGFILE GROUP 1 ('d:\dataora\test_log1a', 'e:\dataora\test_log1b') SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a', 'e:\dataora\test_log2b') SIZE 500K;
protection max : ceinture ET bretelles (on écrit dans 3 fichiers en même temps)
CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE
10M
LOGFILE GROUP 1 ('d:\dataora\test_log1a', 'e:\dataora\test_log1b' , 'f:\dataora\test_log1b')
SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a', 'e:\dataora\test_log2b' , 'f:\dataora\test_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...
on utilise le pramè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
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 !
autorisation de l'archivage automatique dans INIT.ORA (reg : ORA_TEST_PFILE)
log_archive_start = true
log_archive_dest_1 = "location=C:\Oracle\oradata\TEST\archive"
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;
SQL> CONNECT INTERNAL
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG
SQL> ALTER DATABASE OPEN
verification 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é
en cas de perte d'un control file il suffira
|
|
