Formation échiquéenne jwhyCHESS, parallèle avec la planification de projet
Concepts de sauvegarde et de récupération
1. Concepts de sauvegarde et
de récupération
PRÉSENTÉ PAR : ENCADRÉ PAR:
- NAJIHI SOUKAINA - ABOUNASR MERYEM M. HANOUNE
- BOUJADI SOUKAINA - DANGUIR KAMAL
ORACLE
2. PLAN ORACLE
Récupération d’une instance
Configuration pour récupération
Conclusion
Présentation et rappel
Catégories de pannes
Présentation et rappel
NAJIHI
ORACLE
3. Principaux cas de figure :
Corruption de fichier
Perte de fichier
Perte de disque
ORACLE
Obéissent à une stratégieRépondent à des contraintes :
Disponibité des données
Importance relative de certaines données
Temps de reprise
Volume maximum de perte supporté
Économie
NAJIHI
ORACLE
8. ORACLEEchec d’une
instruction
1. Tentative d’entrer
des données non
valide dans une table
1. Aider les utilisateurs
à valider et à corriger
les données.
2. Tentative d’effectuer
des opérations avec
des privilèges
insuffisants
2. Accorder les
privilèges objets ou les
privilèges système
appropriés
3. Echec d’une
tentative d’allouer de
l’espace
3. Activer le mode de
reprise après un
problème d’allocation
d’espace
. Augmenter le quota de
l’utilisateur
. Ajouter de l’espace au
tablespace
4. Erreur logique dans
les applications
4. Aider les
développeurs à
corriger les erreurs du
programmes
NAJIHI
ORACLE
9. Echec d’un
processus utilisateur
ORACLE
1. L’utilisateur a
procédé à une
déconnexion
anormale
2. La session de
l’utilisateur s’est
terminée de façon
anormale
3. L’utilisateur a été
confronté à une
erreur du
programme qui a
mis fin à la session
L’intervention du DBA
n’est généralement pas
nécessaire pour
résoudre les échecs de
processus utilisateur.
NAJIHI
ORACLE
10. Défaillance réseau
ORACLE
1. Echec processus
d’écoute
1. Configurer un
processus d’écoute de
secours
2. Défaillance carte
réseau
2. Configurer plusieurs
cartes réseaux
3. Echec connexion
réseau
3. Configurer une
connexion réseau de
secours
NAJIHI
ORACLE
12. BOUJADI
• Configurer un processus d’écoute
de secoursniveau ligne
• Ramener la table à l'état où elle était
à un certain moment dans le passé
ou juste avant un drop.
niveau table
• Ramener la totalité de la base de
donnée à l'état où elle était à un
certain moment dans le passé
niveau base de
données
ORACLE
Flashback: voir l’état passé de données, ou de ramener une table ou
la totalité de la base de données dans le passé.
ORACLE
13. ORACLE
Exemple
Supprimer la table EMPLIOYE
DROP TABLE EMPLOYEE
Table supprimée
RÉCUPÉRER LA TABLE SUPPRIMÉE
FLASHBACK TABLE EMPLOYEE TO BEFORE DROP
Flashback terminé.
Afficher la structure de la table EMPLOYE
DESC EMPLOYE
Nom NULL ? Type
-------------------------------------------- ----------- ------------
ID NUMBER
NOM VARCHAR2(20)
SALAIRE NUMBER(7,2)
BOUJADI
ORACLE
14. ORACLE
Comme ce flashback va récupérer les données dans le
tablespace d’annulation, il faut que les données s’y
trouvent encore pour les récupérer (ce qui n’est pas garanti).
récupérer les informations d'origine via Oracle LogMiner
BOUJADI
ORACLE
15. ORACLE
Oracle LogMiner
Tous les changements
apportés à la base de
données sont
enregistrées dans les
fichiers Redo Log afin que
les opérations de
récupération de base
puissent être réalisées.
Le problème de ces
fichiers c'est que l'on ne
peut pas éditer le contenu
aussi facilement
Oracle LogMiner vous
permet d'interroger les
fichiers de journalisation
en ligne et les fichiers de
journalisation archivés via
une interface SQL.
BOUJADI
ORACLE
16. ORACLE
instance arrêtée avant la synchronisation des fichiers
de l'ensemble de la base de données.
Panne de courant défaillance matérielle
Des procédures
d’arrêt d’urgence
Un échec d’un
processus en arrière-
plan
échec d’une
instance
Echec d’une
instance
BOUJADI
ORACLE
18. ORACLE
Récupération d’une instance
La récupération utilise les informations stockées
dans les groupes de fichiers de journalisation pour
synchroniser les fichiers
Après une panne d’instance Il suffit au DBA de
la redémarrer l’aide de la commande startup
La base de données procède après à une
récupération automatique
BOUJADI
ORACLE
19. ORACLE
Phases de la récupération d’instance
smon effectue
deux opérations
un rollback
Un roll forward
BOUJADI
ORACLE
20. ORACLE
Règles de la récupération d’instance
Au cours de la récupération d’instance, les transactions
entre la position du point de reprise et la fin du fichier de
Journalisation doivent être appliquées aux fichiers de
données.
Il revient donc de contrôler la différence entre la position
du point de reprise et la fin du fichier de journalisation.
BOUJADI
ORACLE
21. Utiliser MTTR Advisor
Indiquer la durée souhaitée en secondes ou en minutes.
La valeur par default est de 0 (désactivé).
La valeur maximale est de 3600 secondes (une heure).
DANGUIR
ORACLE
22. DANGUIR
ORACLE
Défaillance physique
1. Echec d’un
disque
2. Echec d’un
contrôleur de disque
3. Suppression ou
corruption d’un
fichier de base de
données qui a mis
fin à la session
1. Restaurez le fichier affecté à
partir d’une sauvegarde .
2. Si nécessaire, informez la base
de données de l’emplacement
du nouveau fichier.
3. Si nécessaire, récupérez le
fichier en appliquant les
informations de journalisation.
23. Configurer la base de données afin
d’optimiser la possibilité de récupération
Programmez des sauvegardes régulières.
Multiplexez les fichiers de contrôles.
Multiplexez les groupes de fichiers de journalisation.
Conservez des copies archivées des fichiers de journalisation.
ORACLE
DANGUIR
25. Fichiers de contrôle
Protégez la base de données contre les défaillances
en multiplexant les fichiers de contrôles:
Au moins deux copies (Oracle en suggère trois).
Chaque copie sur un disque distinct
Au moins une copie sur un contrôleur de disque distinct.
ORACLE
DANGUIR
26. Fichiers de journalisation
Multiplexez les groupes de fichiers de journalisation afin de protéger
la base Contre toute défaillance physique ou perte de données.
Au moins de membres(fichiers) par groupe.
Chaque membre sur un disque distinct.
Chaque membre sur un contrôleur de disque distinct.
Impact important des fichiers de journalisation sur les performances.
ORACLE
DANGUIR
27. Comment multiplexer les fichiers
journaux(1)
Avec Oracle Entreprise Manager
ORACLE
ORACLE
ABOUNAS
30. Comment Multiplexer les fichiers
journaux(2)
Avec Les commande SQL
On doit avoir le privilège système ALTER DATABASE
la taille du nouveau membre n'est pas obligatoire. Elle est déterminé à
partir de la taille des membres existants du groupe
ALTER DATABASE [database]
ADD LOGFILE MEMBER 'filename'
TO GROUP n;
ORACLE
ORACLE
ABOUNAS
31. Exemple: Ajouter un nouveau membre au groupe numéro 4
Groupe 4
1membre :
C:appmeryemoradataorcllog4.log
ORACLE
ORACLE
ABOUNAS
32. La statut du nouveau membre est INVALID dans la vue v$logfile. C'est normal,
car aucun membre du groupe n'a encore fait l'objet d'une écriture.et le statut
changera lorsque le fichier est utilisé
Remarque
ORACLE
ORACLE
ABOUNAS
33. L’archivage des fichiers de
journalisation(1)
Rappel
Fichier de
données
1
Fichiers journaux
T1 T2
L’écrasement
des fichiers
Redol_logs
1 2
3
7 8
9
ORACLE
ORACLE
ABOUNAS
34. L’archivage des fichiers de
journalisation(2)
Pour préserver les informations de journalisation , créez des copies
archivées des fichiers de journalisation.
Pour faciliter la création de ces fichiers :
1. Indiquer une convention d'appellation pour les fichiers de journalisation
archivés
2. Indiquer une ou plusieurs destinations pour le stockage des
fichiers de journalisation archivés
3. Placer la base de données en mode ARCHIVELOG
ORACLE
ORACLE
ABOUNAS
35. Appellation et destination des fichiers
de journalisation archivés
Les paramétres du processus d’archivage (ARCn)
1. LOG_ARCHIVE_FORMAT
Ce paramétre définit le format souhaité pour le nom des archives .
Le format doit inclure les variables suivantes:
%s ou %S
• Numéro du
séquence de
fichier de
journalisation
%t ou %T
• Numéro
d’instance
(thread)
%r
• resetlogs ID
• garantir que
le nom du
redo_logs
archivé reste
unique
%d
• l'ID de la
base de
données
ORACLE
ORACLE
ABOUNAS
36. Remarques
Lorsque le nom de la variable est en majuscules , le nombre est complété
à gauche par des 0.
Pour savoir :
les numéros de séquences , et le numéro de thread (voir la vue v$log)
ID de la base de donnée (voir la vue v$database )
la valeur par défaut de paramétre (log_archive_format):
Exemple: arch_%T_%s.arc
Avec la valeur ci-dessus, les fichiers générés pour les numéros de
séquence de journal 300 à 302 dans le thread 1 seront les suivants :
arch_001_300.arc,
arch_001_301.arc,
arch_001_302.arc,
ORACLE
ORACLE
ORACLE
ABOUNAS
37. Appellation et destination des fichiers de
journalisation archivés(2)
Les paramétres du processus d’archivage
2. LOG_ARCHIVE_DEST_n
Ces paramétres définissent jusqu’à 10 distinations d’archivage. Les destinations
peuvent être locales (un répertoire) ou distantes (un alias Oracle Net pour une base
de données de secours
ORACLE
ORACLE
ABOUNAS
38. Appellation et destination des fichiers de
journalisation archivés(4)
Avec Oracle Entreprise Manager
ORACLE
ORACLE
ABOUNAS
39. Le mode ARCHIVELOG
Mode ARCHIVELOG : les groupes de redo remplis doivent être archivé.
Placer la BDD en Mode ARCHIVELOG
Avec entreprise Manager
ORACLE
ORACLE
ABOUNAS
40. Le mode Archivelog(2)
On peut archiver les fichiers de redo log (2):
Les commandes SQL (Connecter en tant que SYSDBA)
Arrêter La base
Démarrer la base en mode MOUNT (la base démarré mais non ouverte)
-
Positionner la base en mode ARCHIVELOG
Vérifier
Sql > SHUTDOWN IMMEDIATE
Base de donnée démontée
Instance oracle arrêtée
Sql > Startup MOUNT
Instance oracle lancée
Base de donnée montée
Sql > ALTER DATABASE ARCHIVELOG
Base de données modifié
Sql >alter database open
Sql >SELECT name,log_mode from v$database;
Name LOG_MODE
------------------------------------
ORCL ARCHIVELOG
ORACLE
ORACLE
ABOUNAS
Ouvrir la base
42. DBA
Protège la BDD
Contre les
pannes
Echec d'une instruction
Echec d'un processus utilisateur
Défaillance réseau
Echec d'une instance
Défaillance physique
Limite les pertes
de données
OPTIMISE
LA POSSIBLITE DE
RECUPERATION
Sauvegarde régulière
Multiplexer Fichier contrôle
Multiplexer Fichiers Redo_log
Archivage Fichiers Redo_log
régler la
récupération
d’instance
ORACLE
ORACLE
ABOUNAS
Mode
Archivelog
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, logiquementRé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...)
Le rôle du DBA est de garantir que la base de données est ouverte et disponible au moment où
les utilisateurs en ont besoin. Pour cela, le DBA (généralement en collaboration avec
l'administrateur système) :
• Anticipe et prévient les causes courantes de panne.
• Tente d'augmenter la durée moyenne sans pannes, en s'assurant que le matériel est le
plus fiable possible, que les composants essentiels sont protégés par redondance et que
la maintenance du système d'exploitation est effectuée à temps.
• Réduit la durée moyenne de récupération, en testant à l'avance les procédures de
récupération et en configurant les sauvegardes de sorte qu'elles soient disponibles en cas
de besoin.
• Limite les pertes de données. Les DBA qui appliquent les méthodes recommandées
peuvent configurer leurs bases de données de sorte qu'aucune transaction validée ne soit
jamais perdue.
Les outils permettant de garantir cela sont les suivants :
Les fichiers de journalisation archivés (archived redo logs)
- Les bases de données de secours et Oracle Data Guard (étudiés dans un
autre cours)
dans ce schéma on va voir les composantes et également le fonctionnement de la base de donnée ,
On a dans la section gauche la partie client ,dans la section de droite trois compartiment principaux : mémoire , structure physique , structure logique
et on peut voir aussi les processus qui sont en rouge
lorsque l'utilisateur démarre une session , il doit fournir :
-le nom de l'utilisateur
-mot de passe
- et une de connexion
ceci sera comparer par une alliance dans un fichier nommé tnsnames.ora
ce qui va permettre de rétablir la connexion avec le serveur et de démarrer localement un processus user
le user processus sera dirigé également vers le modelé d'écoute appelé listener celui ci permettra de démarrer un processus serveur appelé server la connexion donc établis entre le client et le serveur
Et l’utilisateur peut maintenant exécuter des requêtes sql et dans cet exemple on va utiliser la commande update
le server processus va permettre d'évaluer la syntaxe de la commande et également l'existence de l'objet et les privilèges sur l'objet
ceci sera confirmer par le user processus
la commande se retrouvera dans deux compartiments mémoire le shared pool et le log buffer
On trouve également dans le shared pool le plan de l'exécution
le server processus permettra d’ exécuter le plan et lire les bloc de la tables
afin de les charger dans un compartiment mémoire appelé
buffer cache, ce bloc appelé image avant,
On trouve également l'image avant à l'intérieur de segment appelé undo ,
une copie de ce bloc avec l'update appelé image après est stocker dans le shared pool ,
une confirmation sera envoyer au user processus
l'utilisateur pourra compléter la transaction en effectuant la commande commit,
server processus exécutera cette commande et la placer dans le log buffer ,
le commit va déclencher un processus appelé le log writer qui permettra
l'écriture officielle de la transaction dans le redo log file
l'image sera écraser à l'intérieur de undo segment
une confirmation sera retourné vers le user processus ,
lorsque le log est remplis il déclenche un processus appelé ARCn celui ci
permettra de générer un fichier appelé archive avec le contenu de log courant
un switch log sera déclencher écrasant le contenu du log précèdent
le switch déclenchera a son tour un processus CKPt (check point )
celui ci va générer une valeur séquentielle appelé check point number cette valeur sera inscrit à l'intérieur du contrôle file et aussi à l'entête
des datafiles
le check point déclenchera un autre processus appelé DBwn db writer
celui ci récupéra l'image après qui se trouve à l'intérieur de buffer cache
afin de l’enregistrer dans la table
Les types de panne qui peuvent affecter une base de données
Lorsqu'une opération de base de données unique échoue, l'intervention du DBA peut être
nécessaire pour corriger les erreurs concernant des privilèges utilisateur ou l'allocation
d'espace à la base de données.
Lorsque des utilisateurs sont déconnectés de façon anormale de l'instance, il se peut que des
transactions n'aient pas encore été validées (commit) et nécessitent d'être nettoyées. Le
processus en arrière-plan PMON interroge périodiquement les processus serveur afin de
vérifier que leurs sessions sont toujours connectées. Si le processus PMON découvre un
processus serveur dont l'utilisateur n'est plus connecté, il procède à une récupération des
transactions en cours, en annulant (rollback) les modifications non validées et en libérant les
éventuels verrous externes (locks) détenus par la session ayant échoué.
L'intervention du DBA ne doit pas être nécessaire suite à l'échec d'un processus utilisateur,
mais l'administrateur doit observer les tendances. Un ou deux utilisateurs qui sont
déconnectés de façon anormale ne doit pas éveiller de soupçons. Un faible pourcentage
d'échecs de processus utilisateur est normal. Les échecs fréquents et systémiques indiquent en
revanche d'autres problèmes. Un pourcentage élevé de déconnexions anormales peut indiquer
la nécessité d'une formation des utilisateurs (apprenez-leur à se déconnecter plutôt qu'à quitter
simplement les programmes). Ce problème peut également indiquer des problèmes
concernant le réseau ou les applications.
La meilleure solution pour les défaillances réseau consiste à fournir des chemins redondants
pour les connexions réseau. Les processus d'écoute, connexions réseau et cartes réseau de
secours permettent de limiter la probabilité qu'une défaillance réseau n'affecte la disponibilité
du système.
Les utilisateurs peuvent supprimer ou modifier des données par inadvertance. Dans ce cas, le
DBA peut être amené à aider l'utilisateur à corriger l'erreur. Si l'utilisateur n'a pas encore
validé la transaction ou quitté le programme, il suffit d'annuler l'opération. En revanche, s'il a
déjà validé les modifications, les interrogations flashback peuvent être utilisées pour
déterminer les valeurs antérieures (les données peuvent alors être mises à jour afin de
restaurer les informations d'origine).
Principe : La fonctionnalité FLASHBACK a pour objectif de récupérer vos données suite à une erreur d’utilisation et ainsi vous permettre de remonter dans le temps.
Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent de voir l’état passé de données, ou de ramener une table ou la totalité de la base de données dans le passé.
Il existe 3 niveaux de flashback
• niveau ligne
Le FLASHBACK niveau ligne possède trois variantes :Requête (FLASHBACK QUERY) : Nous permet de lire les données telles qu’elles étaient à un instant donné du passé.Version (FLASHBACK VERSION QUERY) : Nous permet de voir toutes les versions d’une ligne sur un certain intervalle de temps.Transaction (FLASHBACK TRANSACTION QUERY) : Permet de voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps.
• niveau table : permet de ramener la table à l'état où elle était à un certain moment dans le passé
ou juste avant un drop.
• niveau base de données : permet de ramener la totalité de la base de donnée à l'état où elle était
à un certain moment dans le passé
Comme ce flashback va récupérer les données dans le tablespace d’annulation, il faut que les données s’y trouvent encore pour les récupérer (ce qui n’est pas garanti).
Lorsque les interrogations flashback ne sont pas possibles parce que la période de
conservation des informations d'annulation a expiré, le DBA peut toujours récupérer les
informations d'origine via Oracle LogMiner.
Les REDO LOGs … Fichiers contenant toutes les informations sur toutes les transactions survenues dans notre base de données préférée. Le problème de ces fichiers c'est que l'on ne peut pas éditer le contenu aussi facilement. C'est pour cela que Oracle nous à fournit un outils très pratique permettant d'analyser et d'utiliser le contenu de ces fichiers REDO LOG.
Oracle LogMiner vous permet d'interroger les fichiers de journalisation en ligne et les fichiers de journalisation archivés via une interface SQL.
Les données des transactions peuvent persister plus longtemps dans les fichiers de journalisation en ligne que dans les informations d'annulation.
On dit qu'il y a ECHEC de l'instance lorsqu'elle est arrêtée avant la synchronisation des fichiers de l'ensemble de la base de données.
L'échec d'une Instance Oracle se produit suite à une défaillance matérielle, échec d'un processus d’arrière plan (BACKGROUND-PROCESS), panne de courant, ou suite à l'utilisation de commandes d'arrêt SHUTDOWN ABORT ou STARTUP FORCE.
La base de données Oracle Database 10g procède à une récupération automatique suite à
l'échec d'une instance. Il suffit au DBA de démarrer l'instance normalement. L'instance monte
les fichiers de contrôle, puis tente d'ouvrir les fichiers de données. Lorsqu'elle découvre les
fichiers de données qui n'ont pas été synchronisés au cours de l'arrêt, l'instance utilise les
informations des groupes de fichiers de journalisation pour réimplémenter les modifications
des fichiers de données jusqu'à l'instant de l'arrêt, puis pour annuler les éventuelles
transactions non validées
. Lorsqu'une instance a échoué, le processus d'arrière-plan SMON la récupère automatiquement lors de la réouverture de la base de données. La récupération d'une instance implique les étapes suivantes : Au cours de la récupération de l’instance , smon effectue deux opérations
U n roll forward Il lit les fichiers de journalisation et applique aux blocs de données les modifications qui y sont enregistrées. Etant donné que toutes les transactions validées ont été enregistrées dans les fichiers de journalisation, ce processus permet de récupérer ces transactions dans leur intégralité.
2. Puis un rollback pour enlever des fichiers de données les modifications enregistrées des transactions non validées
. Ces transactions sont annulées (rollback) par le processus SMON ou par les processus serveur lorsqu'ils accèdent aux données verrouillées.
Pour effectuer le suivi des informations déjà écrites dans les fichiers de données, la base de données utilise des points de reprise (checkpoints). Un point de reprise garantit qu'au moment où il se produit, toutes les données jusqu'à un certain numéro SCN sont enregistrées dans le fichier de données.
SCN est un nombre qui peut définir une version enregistrée (commit) de la base dans un temps bien précis. Quand il y a un commit sur une transaction, oracle lui assigne un nombre unique SCN qui identifiera cette transaction.
Les transactions qui ont lieu après la position du point de reprise peuvent ou non avoir déjà été écrites dans le fichier de données approprié. Dans le schéma les blocs hachurés n'ont pas encore été écrits sur le disque.
Le temps nécessaire à la récupération de l'instance correspond au temps nécessaire pour rétablir les fichiers de données de leur état au moment du dernier point de reprise jusqu'à l'état correspondant au dernier numéro SCN enregistré dans le fichier de contrôle.
Pour ouvrir cette page
Cliquez sur Serveur(stockage) groupe de fichiers de journalisation
Le statut invalid changera devient current
Les fichiers de journalisations constituent un journal des modifications apportées à la base Ils sont organisés en groupes écrits de manière circulaire :
(les informations sauvegardées sont donc par défault périodiquement écrasées)
Vous rappellez le mode circulaire d’écrire au fichier de journalisation.
Le process LGWR écrit dans les fichiers de redo log en mode circulaire : lorsque le fichier de redo log courant est rempli, LGWR commence à écrire dans le fichier de redo log suivant. Lorsque le dernier fichier de redo log est rempli, LGWR revient au premier fichier de redo log et écrit dans ce dernier, càd le 1er fichier est écrasé et remplacé par un autre ;
Remarque 2:
Les numéros de séquence incrémente
Pour sauvegarder les informations de journalisation , créez des copies archivées des fichiers de journalisation
Pour faciliter sa création :
1- tout simplement pour avoir un nom unique pour éviter l’écrasement de ces fichiers
2-où vont être stocké ces fichiers
3-en fin configurer la bdd en mode archivelog
Pour configurer la base de données pour une possibilité de récupération maximale, vous devez
Sauvegarder les fichiers de journalisation en ligne avant de leur écrasement dans des fichiers de journalisation archivés.
vous devez :
Arcn :Les processus d'archivage ARCn copient les fichiers de journalisation (sur le périphérique de stockage désigné. Par défaut, il n’est pas actif. Si le mode ARCHIVELOG est activé
Pour l’appelation et destination des fichiers de journalisation c’est les processus ARCn qui falit ce travail ………….
1- 1er paramétre qui utilise log_archive_format
%r : ID resetlogs ID ; permet de garantir que le nom du fichier de journalisation archivé
reste unique même suite à l'utilisation de certaines techniques de récupération avancées
qui réinitialisent les numéros de séquence des fichiers de journalisation.
• %d : inclut l'ID de la base de données dans le nom.
Le format doit inclure %s, %t et %r. L'utilisation de %d est facultative, mais elle est
obligatoire si plusieurs bases de données partagent la même destination des fichiers de
journalisation archivés.
Pour savoir les numéros de ²séquences , et le numéro de thread (interroger la vue du dictionnaire V$LOG)
Pour savoir la valeur par défaut pour ce paramétre (log_archive_format):
Le 2 eme paramétre est :
Remarque :
Les destinations locales doivent se terminer par une barre oblique (/), ou une barre oblique inverse (\) sous Windows
Pour ouvrir cette page
cliquez sur diponiblité Paramétres de récupération
---------------------------------------------------------------------------------
La destination numéro 10 utilise le paramétre USE_DB_RECOVERY_FILE_DEST qui prend par défault l’emplacement de la zone de récupération rapide (expliqué en détails en 2ème exposé)
-Le DBA peut utiliser la sauvegarde présente sur les fichiers de redo log archivés pour restaurer la base de données sans perdre aucune donnée comité.
-pour configurer la base de données en utilsant entreprise manager :
Vous devez d’abord se connecter en tant que sysdba puis cliquer sur
Diponiblité -> paramétres de récupération -> voir partie Récupération après défaillance matérielle , en suite cocher la case archivelog
-la base de données doit être montée mais non ouverte pour Activer et désactiver les options d'archivage des fichiers de journalisation en ligne autre donc vous devez démarrer la base en mode mount .
Le mode noarchivelog est le mode par défault pour la base de données , càd les fichiers de journalisation sont périodiquement écrasés ,.
Comme résumé on a vu commet le DBA protège la base de données contre les pannes (echec ………..)
Et comment régler la récupération d’instance
et tous ça pour limiter les pertes de données avec une sauvegarde régulière (on va le voir en détail en 2eme exposée) –multiplexer les fichiers de contrôle + multiplexer les fichiers de journalisation + archiver les fichiers de journalisation en activant le mode archivelog.
Ce Chapitre va vous permet de :
Savoir les types de défaillance pouvant survenir dans une base de donnée
Décrire comment régler le récupération d’instance
Pour limiter les pertes de données vous pouvez:
Faire une sauvegarde régulière
Savoir comment multiplexer le fichier de contrôle et les fichiers de journalisation
Décrire l’importance d’archiver les fichiers de journalisation
Configurer le mode ARCHIVELOG