Téléchargé 176 fois
![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](https://image.slidesharecdn.com/conceptsdesauvegardeetdercupration-141116151741-conversion-gate01/75/Concepts-de-sauvegarde-et-de-recuperation-30-2048.jpg)
Contenu connexe
Similaire à Concepts de sauvegarde et de récupération
![Cours_de_Base [Enregistrement automatique].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/coursdebaseenregistrementautomatique-251004134501-ee1a28b9-thumbnail.jpg?width=640&height=640&fit=bounds)
Concepts de sauvegarde et de récupération
- 1. Concepts de sauvegardeet 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’uneinstance Configuration pour récupération Conclusion Présentation et rappel Catégories de pannes Présentation et rappel NAJIHI ORACLE
- 3. Principaux cas defigure : 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. 1 4 Le rôle deDBA NAJIHI ORACLE 1 4
- 5. USE R ARCn MémoirePhysiqueLogique Instance Contrôle file Redolog 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. ORACLE Recuperation d’une instance Configurationpour recuperation Conclusion Présentation et rappel Catégories de pannes NAJIHI ORACLE
- 7. ORACLE NAJIHI ORACLE Défaillance réseau Erreur utilisateur Echecd’une instance Echec d’un processus utilisateur Echec d’une instruction Défaillance physique Catégories de pannes
- 8. ORACLEEchec d’une instruction 1. Tentatived’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. Echecprocessus 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. Erreurs utilisateur ORACLE PROBLEME suppression ou modification des donnéespar inadvertance La transaction n’est pas encore validé annuler l'opération La transaction validé Les interrogations flashback BOUJADI ORACLE
- 12. BOUJADI • Configurer unprocessus 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 tableEMPLIOYE 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 flashbackva 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 leschangements 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 avantla 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. ORACLE Configuration pour récupération Conclusion Récupérationd’une instance Présentation et rappel Catégories de pannes ORACLE
- 18. ORACLE Récupération d’une instance Laré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 larécupération d’instance smon effectue deux opérations un rollback Un roll forward BOUJADI ORACLE
- 20. ORACLE Règles de laré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 Indiquerla 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. Echecd’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 basede 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. ORACLE Récupération d’une instance Conclusion Catégoriesde pannes Présentation et rappel Configuration pour récupération ORACLE
- 25. Fichiers de contrôle Protégezla 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 Multiplexezles 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 lesfichiers journaux(1) Avec Oracle Entreprise Manager ORACLE ORACLE ABOUNAS
- 28.
- 29.
- 30. Comment Multiplexer lesfichiers 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 unnouveau membre au groupe numéro 4 Groupe 4 1membre : C:appmeryemoradataorcllog4.log ORACLE ORACLE ABOUNAS
- 32. La statutdu 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 fichiersde 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 fichiersde 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 destinationdes 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 lenom 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 destinationdes 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 destinationdes 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
- 41. ORACLE Récupération d’une instance Configurationpour récupération Présentation et rappel Catégories de pannes Présentation et rappel Conclusion ORACLE
- 42. DBA Protège la BDD Contreles 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.
Notes de l'éditeur
- #4 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...)
- #5 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)
- #6 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
- #8 Les types de panne qui peuvent affecter une base de données
- #9 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.
- #10 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.
- #11 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.
- #12 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).
- #13 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é
- #15 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.
- #16 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.
- #17 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.
- #19 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
- #20 . 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.
- #21 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.
- #28 Pour ouvrir cette page Cliquez sur Serveur(stockage) groupe de fichiers de journalisation
- #34 Le statut invalid changera devient current
- #35 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
- #36 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 :
- #37 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.
- #38 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):
- #39 Le 2 eme paramétre est : Remarque : Les destinations locales doivent se terminer par une barre oblique (/), ou une barre oblique inverse (\) sous Windows
- #41 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é)
- #42 -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
- #43 -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 .
- #44 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 ,.
- #46 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