Concepts de sauvegarde et de récupération

Présentation au sujet: "Concepts de sauvegarde et de récupération"— Transcription de la présentation:

1 Concepts de sauvegarde et de récupération
ORACLE Concepts de sauvegarde et de récupération Présenté PAR : Encadré Par: - NAJIHI SOUKAINA - abounasr meryem M. hanoune - Boujadi soukaina - danguir kamal

2 PLAN 1 1 2 3 4 5 Présentation et rappel Présentation et rappel
ORACLE PLAN ORACLE Présentation et rappel 1 Présentation et rappel 1 2 Catégories de pannes 3 Récupération d’une instance 4 Configuration pour récupération 5 Conclusion NAJIHI

3 Répondent à des contraintes : Obéissent à une stratégie
ORACLE ORACLE Principaux cas de figure : Corruption de fichier Perte de fichier Perte de disque Répondent à des contraintes : Disponibité des données Importance relative de certaines données Temps de reprise Volume maximum de perte supporté Économie Obéissent à une stratégie 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...) NAJIHI

4 2 2 3 3 1 1 4 4 Le rôle de DBA NAJIHI ORACLE
Augmenter la durée moyenne sans pannes 2 Augmenter la durée moyenne sans pannes 2 Réduire la durée moyenne de recuperation 3 Réduire la durée moyenne de recuperation 3 Protéger la base de données contre les défaillances dans toute la mesure du possible 1 Protéger la base de données contre les défaillances dans toute la mesure du possible 1 Limiter les pertes de données 4 Limiter les pertes de données 4 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) NAJIHI

5 Rappel sur la structure D’une base de données ORACLE
USER ARCn Mémoire Physique Logique Instance Contrôle file Redo log file Client Archives Datafiles UNDO Table SGA Shared Pool Buffer Cache Log Buffer PMON SMON DBWn CKPT LGWR Tablespaces SERVER ORACLE Image avant Update… user Update.. ORACLE Commit; ********* orcl PARSE Image après Execute Rappel sur la structure D’une base de données ORACLE Log plein 9 9 10 9 10 10 10 9 Update… OK 11 9 10 Commit; 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 SQL>Update… Image avant SQL>Commit; Switch Image écrasée Update… Commit; NAJIHI

6 1 2 3 4 5 Présentation et rappel Catégories de pannes
ORACLE ORACLE Présentation et rappel 1 Catégories de pannes 2 3 Recuperation d’une instance 4 Configuration pour recuperation 5 Conclusion NAJIHI

7 Catégories de pannes NAJIHI ORACLE Echec d’une instruction Echec d’un
Défaillance physique Echec d’un processus utilisateur Catégories de pannes Echec d’une instance Défaillance réseau Erreur utilisateur Les types de panne qui peuvent affecter une base de données NAJIHI

8 4. Erreur logique dans les applications
Echec d’une instruction ORACLE ORACLE 4. Erreur logique dans les applications 3. Echec d’une tentative d’allouer de l’espace 1. Tentative d’entrer des données non valide dans une table 2. Tentative d’effectuer des opérations avec des privilèges insuffisants 4. Aider les développeurs à corriger les erreurs du programmes 1. Aider les utilisateurs à valider et à corriger les données. 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 2. Accorder les privilèges objets ou les privilèges système appropriés 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. NAJIHI

9 processus utilisateur
Echec d’un processus utilisateur ORACLE 1. L’utilisateur a procédé à une déconnexion anormale ORACLE L’intervention du DBA n’est généralement pas nécessaire pour résoudre les échecs de processus utilisateur. 2. La session de l’utilisateur s’est terminée de façon anormale 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. 3. L’utilisateur a été confronté à une erreur du programme qui a mis fin à la session NAJIHI

10 3. Echec connexion réseau 1. Echec processus d’écoute
Défaillance réseau ORACLE 3. Echec connexion réseau 1. Echec processus d’écoute 2. Défaillance carte réseau ORACLE 3. Configurer une connexion réseau de secours 2. Configurer plusieurs cartes réseaux 1. Configurer un processus d’écoute de secours 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. NAJIHI

11 annuler l'opération La transaction validé Les interrogations flashback
Erreurs utilisateur ORACLE La transaction n’est pas encore validé annuler l'opération ORACLE PROBLEME suppression ou modification des données par inadvertance La transaction validé Les interrogations flashback 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). BOUJADI

12 niveau ligne niveau table 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 Configurer un processus d’écoute de secours niveau 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 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é BOUJADI

13 Exemple Supprimer la table EMPLIOYE DROP TABLE EMPLOYEE
ORACLE Exemple ORACLE 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

14 récupérer les informations d'origine via Oracle LogMiner
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 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. BOUJADI

15 ORACLE Oracle LogMiner ORACLE 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. 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. BOUJADI

16 défaillance matérielle
Echec d’une instance ORACLE 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 échec d’une instance 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. Un échec d’un processus en arrière-plan Des procédures d’arrêt d’urgence BOUJADI

17 1 2 3 4 5 Présentation et rappel Catégories de pannes
ORACLE ORACLE Présentation et rappel 1 2 Catégories de pannes Récupération d’une instance 3 4 Configuration pour récupération 5 Conclusion

18 Récupération d’une instance
ORACLE Récupération d’une instance ORACLE 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 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 La récupération utilise les informations stockées dans les groupes de fichiers de journalisation pour synchroniser les fichiers BOUJADI

19 Phases de la récupération d’instance
ORACLE ORACLE Un roll forward smon effectue deux opérations . 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. un rollback BOUJADI

20 Règles de la récupération d’instance
ORACLE ORACLE 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. 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. BOUJADI

21 Utiliser MTTR Advisor ORACLE 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

22 Restaurez le fichier affecté à partir d’une sauvegarde .
Défaillance physique ORACLE 1. Echec d’un disque Restaurez le fichier affecté à partir d’une sauvegarde . Si nécessaire, informez la base de données de l’emplacement du nouveau fichier. Si nécessaire, récupérez le fichier en appliquant les informations de journalisation. 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 DANGUIR

23 ORACLE 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. DANGUIR

24 1 2 3 4 5 Présentation et rappel Catégories de pannes
ORACLE ORACLE Présentation et rappel 1 Catégories de pannes 2 3 Récupération d’une instance Configuration pour récupération 4 5 Conclusion

25 ORACLE 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. DANGUIR

26 Fichiers de journalisation
ORACLE 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. DANGUIR

27 Comment multiplexer les fichiers journaux(1)
ORACLE Comment multiplexer les fichiers journaux(1) ORACLE Avec Oracle Entreprise Manager Pour ouvrir cette page Cliquez sur Serveur(stockage) groupe de fichiers de journalisation ABOUNASR

28 ORACLE ORACLE ABOUNASR

29 ORACLE ORACLE ABOUNASR

30 Comment multiplexer les fichiers journaux(1)
ORACLE Comment multiplexer les fichiers journaux(1) ORACLE Lors de la création d’une nouvelle BDD ((Avec Assistant DBCA)) ABOUNASR

31 Comment Multiplexer les fichiers journaux(2)
ORACLE Comment Multiplexer les fichiers journaux(2) ORACLE Avec Les commande SQL On doit avoir le privilège système ALTER DATABASE NB 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; ABOUNASR

32 Exemple: Ajouter un nouveau membre au groupe numéro 4
ORACLE Exemple: Ajouter un nouveau membre au groupe numéro 4 ORACLE Groupe 4 1membre : C:\app\meryem\oradata\orcl\log4.log ABOUNASR

33 ORACLE Remarque ORACLE 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é Le statut invalid changera devient current ABOUNASR

34 L’archivage des fichiers de journalisation(1)
ORACLE L’archivage des fichiers de journalisation(1) L’écrasement des fichiers Redol_logs ORACLE Rappel Fichier de données Fichiers journaux 1 2 1 8 7 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 3 9 T1 T2 ABOUNASR

35 L’archivage des fichiers de journalisation(2)
ORACLE L’archivage des fichiers de journalisation(2) ORACLE 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 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 : ABOUNASR

36 Appellation et destination des fichiers de journalisation archivés
ORACLE ORACLE 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 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. ABOUNASR

37 Exemple: arch_%T_%s.arc
Remarques ORACLE ORACLE 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 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): ABOUNASR

38 Appellation et destination des fichiers de journalisation archivés(2)
ORACLE Appellation et destination des fichiers de journalisation archivés(2) ORACLE 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 Le 2 eme paramétre est : Remarque : Les destinations locales doivent se terminer par une barre oblique (/), ou une barre oblique inverse (\) sous Windows ABOUNASR

39 Appellation et destination des fichiers de journalisation archivés(3)
ORACLE Appellation et destination des fichiers de journalisation archivés(3) ORACLE Lors de la création d’une nouvelle BDD (Avec Assistant DBCA) ABOUNASR

40 Appellation et destination des fichiers de journalisation archivés(4)
ORACLE ORACLE Avec Oracle Entreprise Manager 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é) ABOUNASR

41 ORACLE Le mode ARCHIVELOG ORACLE Mode ARCHIVELOG : les groupes de redo remplis doivent être archivé. Placer la BDD en Mode ARCHIVELOG Avec entreprise Manager -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 ABOUNASR

42 Le mode Archivelog(2) ! On peut archiver les fichiers de redo log (2):
ORACLE 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 ORACLE 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 ! Ouvrir la base Sql > ALTER DATABASE ARCHIVELOG Base de données modifié Sql >alter database open -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 . Sql >SELECT name,log_mode from v$database; Name LOG_MODE ORCL ARCHIVELOG ABOUNASR

43 ORACLE Le mode NOARCHIVELOG ORACLE En mode, NOARCHIVELOG, les fichiers de redo log online sont réécrits à chaque fois qu’un fichier de redo log online est rempli . Basculer la base en mode NOARCHIVELOG La démarche est similaire à la configuration de mode ARCHIVELOG , seulement au lieu de mode Archivelog , tapez Noarchievelog 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 ,. Sql > ALTER DATABASE NOARCHIVELOG; Base de données modifié ABOUNASR

44 1 1 2 3 4 5 Présentation et rappel Présentation et rappel
ORACLE ORACLE Présentation et rappel 1 Présentation et rappel 1 2 Catégories de pannes 3 Récupération d’une instance 4 Configuration pour récupération Conclusion 5

45 LA POSSIBLITE DE RECUPERATION
Protège la BDD Contre les pannes ORACLE Echec d'une instruction Echec d'un processus utilisateur ORACLE Défaillance réseau Echec d'une instance régler la récupération d’instance Défaillance physique DBA Limite les pertes de données OPTIMISE LA POSSIBLITE DE RECUPERATION Sauvegarde régulière 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 Multiplexer Fichier contrôle Multiplexer Fichiers Redo_log Mode Archivelog Archivage Fichiers Redo_log ABOUNASR

46 Merci Pour Votre Attention
ORACLE Merci Pour Votre Attention ORACLE