Concepts de sauvegarde et de récupération

1 217 vues

Publié le

Concepts de sauvegarde et de récupération oracle

Publié dans : Formation
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 217
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
130
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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...)
  • 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

  • Concepts de sauvegarde et de récupération

    1. 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. 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. 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
    4. 4. 1 4 Le rôle de DBA NAJIHI ORACLE 1 4
    5. 5. USE R ARCn MémoirePhysiqueLogique 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 SERVE R Rappel sur la structure D’une base de données ORACLE ORACLEuser ********* orcl SQL>Update… PARSE OK Update.. Update… Execute Image avant Image avant Image après SQL>Commit; Commit; Update… Commit; Image écrasée Log plein 9 9 9 99 10 Update… Commit; Switch 11 1010 10 10 NAJIHI ORACLE
    6. 6. ORACLE Recuperation d’une instance Configuration pour recuperation Conclusion Présentation et rappel Catégories de pannes NAJIHI ORACLE
    7. 7. ORACLE NAJIHI ORACLE Défaillance réseau Erreur utilisateur Echec d’une instance Echec d’un processus utilisateur Echec d’une instruction Défaillance physique Catégories de pannes
    8. 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. 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. 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
    11. 11. Erreurs utilisateur ORACLE PROBLEME suppression ou modification des données par inadvertance La transaction n’est pas encore validé annuler l'opération La transaction validé Les interrogations flashback BOUJADI ORACLE
    12. 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. 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. 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. 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. 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
    17. 17. ORACLE Configuration pour récupération Conclusion Récupération d’une instance Présentation et rappel Catégories de pannes ORACLE
    18. 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. 19. ORACLE Phases de la récupération d’instance smon effectue deux opérations un rollback Un roll forward BOUJADI ORACLE
    20. 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. 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. 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. 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
    24. 24. ORACLE Récupération d’une instance Conclusion Catégories de pannes Présentation et rappel Configuration pour récupération ORACLE
    25. 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. 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. 27. Comment multiplexer les fichiers journaux(1)  Avec Oracle Entreprise Manager ORACLE ORACLE ABOUNAS
    28. 28. ORACLE ORACLE ABOUNAS
    29. 29. ORACLE ORACLE ABOUNAS
    30. 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. 31. Exemple: Ajouter un nouveau membre au groupe numéro 4 Groupe 4 1membre : C:appmeryemoradataorcllog4.log ORACLE ORACLE ABOUNAS
    32. 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. 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. 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. 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. 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. 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. 38. Appellation et destination des fichiers de journalisation archivés(4)  Avec Oracle Entreprise Manager ORACLE ORACLE ABOUNAS
    39. 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. 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
    41. 41. ORACLE Récupération d’une instance Configuration pour récupération Présentation et rappel Catégories de pannes Présentation et rappel Conclusion ORACLE
    42. 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
    43. 43. Merci Pour Votre Attention ORACLE ORACLE

    ×