La reprise de la base de données est l’une de ces tâches dont on espère ne jamais avoir besoin, mais qui, en cas de catastrophe, peut sauver votre entreprise. Dans des environnements à fort enjeu, tels que les systèmes financiers ou les bases de données ERP, même de petites erreurs peuvent entraîner de graves problèmes. Pour les administrateurs informatiques, maîtriser la reprise fondée sur le numéro de modification système (SCN) n’est pas seulement une question théorique : c’est souvent la dernière ligne de défense contre la corruption des données ou les erreurs commises par les utilisateurs.
Parfois, vous devez restaurer une base de données Oracle non seulement selon une date ou une heure précise, mais aussi à son état exact avant qu’un problème ne survienne. C’est dans ce cas que la récupération jusqu’à un SCN (System Change Number) s’avère particulièrement utile. Ce guide vous explique tout : ce qu’est un SCN, pourquoi il est important, comment effectuer une récupération à l’aide de RMAN ou de SQL*Plus pas à pas — et comment Vinchin contribue à assurer la sécurité de vos données.
Qu’est-ce que le SCN dans la reprise après sinistre d’une base de données ?
Le numéro de modification système (SCN) constitue le cœur du modèle de cohérence interne d’Oracle. À chaque validation d’une transaction dans Oracle Database, un SCN unique lui est attribué — on peut l’imaginer comme un repère croissant en permanence qui enregistre chaque modification effectuée dans tous les tablespaces.
Pourquoi cela est-il important ? La base de données utilise ces numéros comme des horodatages, mais sans dépendre des horloges système — ce qui élimine toute ambiguïté liée aux fuseaux horaires ou à la dérive des horloges. Lorsque vous effectuez une récupération jusqu’à un SCN, vous demandez à Oracle : « Restaurez ma base de données exactement à ce point précis. » Cette opération est précise au niveau de chaque transaction validée.
Pourquoi récupérer la base de données jusqu’à un SCN ?
Pourquoi choisir cette méthode plutôt qu’une récupération par date ou par numéro de séquence de journal ? Imaginez qu’une personne supprime accidentellement des données critiques de paie à 14 h 03, mais que plusieurs autres modifications interviennent au cours de cette même minute. Si vous ne connaissez que l’horodatage — ou si les horloges des serveurs ne sont pas parfaitement synchronisées —, vous risquez de manquer des transactions importantes ou d’effectuer un retour arrière trop loin.
La récupération jusqu’au SCN vous permet de déterminer avec précision l’endroit exact où l’erreur s’est produite et d’annuler uniquement les opérations nécessitant une correction. Cette méthode réduit au minimum la perte de données suite à des suppressions accidentelles ou à des échecs de traitements par lots, et contribue à respecter des règles strictes de conformité exigeant des pistes d’audit précises.
Pour les organisations soumises à une surveillance réglementaire – ou celles qui souhaitent simplement avoir l’esprit tranquille – la reprise fondée sur le SCN offre une précision inégalée par rapport aux méthodes basées sur le temps.
Check-list préalable à la récupération : garantir le succès
Avant de passer aux étapes de récupération, une bonne préparation fait toute la différence entre une opération fluide et des heures de dépannage ultérieures.
Tout d’abord : validez vos sauvegardes ! Utilisez régulièrement les commandes RMAN VALIDATE BACKUP afin d’éviter toute surprise lors des opérations de restauration. Ensuite : assurez-vous que tous les journaux archivés jusqu’à votre SCN cible sont disponibles ; l’absence de journaux entraîne une restauration incomplète.
Vérifiez l’espace disque sur les serveurs source et de destination : la restauration de bases de données volumineuses nécessite suffisamment d’espace pour les fichiers de sauvegarde ainsi que pour le stockage temporaire pendant le traitement. Enfin, documentez l’incarnation sous laquelle votre base de données est actuellement exécutée ; si un événement OPEN RESETLOGS s’est déjà produit auparavant, connaître cette information permet d’éviter toute confusion ultérieure lors de la restauration des fichiers de contrôle ou des journaux archivés.
Prendre ces mesures dès le départ évite bien des maux de tête par la suite et garantit que tous les éléments nécessaires à une reprise efficace sont prêts au moment où la catastrophe survient.
Comment récupérer une base de données jusqu’à un SCN spécifique à l’aide de RMAN ?
RMAN (Recovery Manager) est l’outil intégré d’Oracle pour la sauvegarde et la reprise après sinistre ; la plupart des administrateurs s’y appuient, car il automatise de nombreuses tâches complexes derrière des commandes simples.
Commencez par identifier votre SCN cible — le numéro juste avant l’apparition des modifications non souhaitées. Vous pouvez interroger directement les vues V$DATABASE ou V$ARCHIVED_LOG :
SÉLECTIONNER CURRENT_SCN DE V$DATABASE;
Ou, si vous souhaitez des points historiques :
SÉLECTIONNEZ SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# DE V$ARCHIVED_LOG ORDONNÉ PAR SEQUENCE#;
Une fois que vous avez identifié votre SCN souhaité :
1. Arrêtez la base de données si elle est en cours d’exécution à l’aide de SHUTDOWN IMMEDIATE (ou de SHUTDOWN ABORT si nécessaire).
2. Démarrer en mode montage avec STARTUP MOUNT — cela maintient les fichiers de données fermés, mais accessibles pour la restauration.
3. Connectez-vous en tant qu’utilisateur cible dans RMAN.
4. Aperçu des fichiers requis avec :
SET UNTIL SCN <your_scn>;
RESTORE DATABASE PREVIEW;
Cela indique les sauvegardes et journaux nécessaires avant le lancement effectif de la restauration — une excellente méthode pour détecter rapidement d’éventuelles pièces manquantes !
5. Commencer la restauration effective :
EXÉCUTER {
DÉFINIR JUSQU’À SCN <your_scn>; # Remplacer <your_scn> par la valeur réelle
RESTAURER LA BASE DE DONNÉES;
RÉCUPÉRER LA BASE DE DONNÉES;
}6. Une fois l’opération terminée, ouvrez-la avec l’option resetlogs :
ALTER DATABASE OPEN RESETLOGS;
Quelques conseils : Si vous travaillez après des incarnations précédentes (RESETLOGS), utilisez RESET DATABASE TO INCARNATION <incarnation_key> avant de commencer les restaurations. Vérifiez systématiquement que tous les journaux d’archives nécessaires sont présents jusqu’au SCN choisi ; sinon, RMAN interrompra la reprise en cours en demandant les fichiers manquants !
Pour les sauvegardes compressées ou les stratégies à plusieurs sections, courantes dans les déploiements plus importants, assurez-vous d’utiliser des paramètres compatibles tant lors de la création que de la restauration de la sauvegarde ; sinon, les performances peuvent se dégrader ou des erreurs peuvent survenir lors des étapes de décompression ou de réassemblage.
Comment récupérer une base de données jusqu’à un SCN spécifique à l’aide de SQL*Plus ?
SQL*Plus offre aux administrateurs de bases de données expérimentés un contrôle précis des reprises manuelles, mais exige une grande vigilance, car ses fonctionnalités d’automatisation sont limitées par rapport à celles de RMAN.
La première étape consiste toujours à identifier votre SCN cible à l’aide des requêtes mentionnées ci-dessus (V$DATABASE, V$ARCHIVED_LOG, etc.).
Voici comment se déroule la récupération manuelle :
1. Arrêtez le système à l’aide de la commande SHUTDOWN IMMEDIATE
2. Monter l’instance via DÉMARRAGE EN MODE MONTAGE
3. Restaurez les fichiers de données physiques à partir de l’emplacement de sauvegarde — cette opération s’effectue généralement en dehors de SQL*Plus, à l’aide d’outils de copie au niveau du système d’exploitation (par exemple cp sous Linux). Assurez-vous que les fichiers restaurés correspondent à leurs chemins d’origine ; sinon, mettez à jour les pointeurs du fichier de contrôle en conséquence à l’aide de la commande ALTER DATABASE RENAME FILE.
4. Démarrer la récupération des supports :
RÉCUPÉRER LA BASE DE DONNÉES JUSQU’AU CHANGEMENT <your_scn>;
5. Lors de la phase d’application des journaux de restauration (redo), SQL*Plus vous demandera de spécifier le chemin complet de chaque fichier journal archivé requis, jusqu’à atteindre le numéro de changement choisi.
6. Terminer le processus en ouvrant la base de données :
ALTER DATABASE OPEN RESETLOGS;
Les méthodes manuelles exigent une grande vigilance : si un seul journal d’archivage fait défaut, tout le processus s’arrête jusqu’à ce que le problème soit résolu ! Attention également aux sauvegardes à chaud effectuées pendant que les tablespaces étaient en ligne ; des instantanés inconsistants peuvent nécessiter des vérifications supplémentaires, telles que RECOVER DATABASE USING BACKUP CONTROLFILE.
SQL*Plus montre toute sa puissance lorsqu’il s’agit d’automatiser des flux de travail personnalisés sur plusieurs hôtes, mais veillez toujours à tester minutieusement les procédures au préalable, car la gestion des erreurs incombe entièrement à l’opérateur !
Meilleures pratiques pour la reprise basée sur SCN
Vous souhaitez une reprise plus fluide la prochaine fois ? Voici quelques habitudes à intégrer dans vos routines quotidiennes :
Exécutez régulièrement des requêtes de script sur CURRENT_SCN à partir des bases de données de production, puis stockez les résultats conjointement avec les métriques de surveillance ; disposer d’une chronologie permet d’accélérer considérablement l’analyse de la cause première après un incident (« Quelle modification s’est produite entre 10 h et 11 h ? »).
Automatisation des tâches de validation permettant de vérifier la présence et l’intégrité des journaux d’archivage récents, ainsi que des restaurations test périodiques sur des clones non productifs — rien ne remplace la pratique concrète dans des conditions maîtrisées !
Après chaque modification importante du schéma — ou, en particulier, après tout événement RESETLOGS — effectuez immédiatement de nouvelles sauvegardes complètes afin que les chaînes incrémentales futures restent intactes, quelle que soit l’évolution à venir la semaine prochaine, le mois prochain ou l’année prochaine !
Et enfin : conservez des procédures détaillées décrivant chaque étape spécifique à l’environnement local, y compris les partages réseau utilisés pour les copies hors site, ainsi que les contacts à solliciter en cas d’escalade si quelque chose ne se passe pas comme prévu au cours du processus… car même les plans les mieux conçus peuvent parfois rencontrer des obstacles imprévus !
Présentation de Vinchin Backup & Recovery
Au-delà des procédures manuelles et des outils natifs, la protection de niveau entreprise exige des solutions robustes spécifiquement conçues pour des environnements critiques tels que les bases de données Oracle — qui nécessitent une précision et une fiabilité à grande échelle. Vinchin Backup & Recovery se distingue comme une solution professionnelle de niveau entreprise prenant en charge les principales plateformes actuelles, notamment les bases de données Oracle, MySQL, SQL Server, MariaDB, PostgreSQL/Postgres Pro et MongoDB.
Avec des fonctionnalités telles que la compression avancée côté source (pour Oracle), les options de sauvegarde incrémentale (pour Oracle), les capacités de sauvegarde par lots de bases de données, des politiques de rétention flexibles incluant la prise en charge de la politique de rétention GFS, ainsi que la protection contre les ransomwares intégrée sur toutes les plates-formes prises en charge — y compris la sauvegarde dans le cloud et l’archivage sur bande — vous bénéficiez d’une couverture complète contre des menaces allant de la suppression accidentelle aux cyberattaques sophistiquées, tout en optimisant l’efficacité du stockage et l’agilité opérationnelle.
La console web intuitive simplifie les flux de travail de protection en quatre étapes claires :
Sélectionnez les bases de données à protéger.
Choisissez le stockage cible (local, NAS, SAN, cloud).
Définir les plannings, la rétention et les politiques.
Envoyer la tâche.
Reconnu mondialement avec les meilleures notes parmi les utilisateurs professionnels dans le monde entier, Vinchin Backup & Recovery propose un essai gratuit complet de 60 jours — cliquez ci-dessous pour découvrir par vous-même une protection des données de pointe.
FAQ sur la récupération de la base de données jusqu’à un SCN
Q1 : Puis-je automatiser la capture régulière des SCN de ma base de données actuelle ?
A1 : Oui ; planifier des scripts qui interrogent CURRENT_SCN depuis V$DATABASE, puis exporter les résultats quotidiennement via des tâches planifiées cron ou le Planificateur de tâches Windows, selon la préférence de la plateforme.
Q2 : Que dois-je faire si mes journaux d’archivage sont répartis sur plusieurs emplacements de stockage ?
A2 : Cataloguer tous les répertoires contenant des journaux de restauration archivés dans RMAN à l’aide de la commande CATALOG START WITH avant de commencer toute opération de restauration impliquant ces fichiers.
Q3 : Existe-t-il un risque supplémentaire lors de l’exécution d’une récupération à un instant donné sur des bases de données très volumineuses ?
A3 : Des jeux de données plus volumineux augmentent le risque de restaurations partielles en raison d’interruptions matérielles ou réseau ; il est donc indispensable de vérifier systématiquement l’intégrité après la reprise à l’aide de l’utilitaire DBVERIFY, ainsi que de procéder à des contrôles au niveau applicatif chaque fois que cela est possible.
Conclusion
La restauration d’une base de données jusqu’à un numéro spécifique de changement système (SCN) offre aux équipes opérationnelles un contrôle précis pour récupérer les données perdues, qu’il s’agisse d’accidents majeurs ou mineurs — avec des outils automatisés tels que RMAN ainsi que des options manuelles via SQL*Plus, selon la complexité de la situation ! Pour une protection optimisée, envisagez les solutions Vinchin, conçues spécifiquement pour répondre aux exigences de fiabilité de niveau entreprise que les entreprises actuelles réclament partout dans le monde.
