La consignation de transactions individuelles par fichier s'apparente à la journalisation dans d'autres produits de bases de données. Les fichiers journaux de transactions individuelles enregistrent toutes les modifications opérées dans la base de données.
L'intérêt de la consignation de transactions individuelles par fichier est qu'elle fournit un historique des modifications depuis la dernière sauvegarde complète ou incrémentielle, de sorte que vous pouvez restaurer eDirectory dans l'état où il se trouvait avant une défaillance. Sans les fichiers journaux de transactions individuelles, vous ne pouvez restaurer eDirectory que dans l'état où il se trouvait au moment de la dernière sauvegarde complète ou incrémentielle.
eDirectory enregistre les transactions dans un fichier journal avant de les appliquer à la base de données. Par défaut, ce fichier journal est réutilisé continuellement (occupant ainsi peu d'espace disque) et l'historique des changements apportés à la base de données eDirectory n'est pas enregistré.
Lorsque vous activez la consignation continue de transactions individuelles par fichier, l'historique des modifications est enregistré dans un jeu de fichiers journaux de transactions individuelles consécutifs. La consignation de transactions individuelles par fichier ne réduit pas les performances du serveur ; elle enregistre simplement les entrées du fichier journal qu'eDirectory est déjà en train de créer.
Vous devez activer la fonction de consignation de transactions individuelles par fichier pour les serveurs faisant partie d'un anneau de répliques. Faute de quoi, des messages d'erreur s'afficheront lorsque vous tenterez de procéder à une restauration à partir des fichiers de sauvegarde et la base de données ne s'ouvrira pas. Dans le cadre de la restauration par défaut, une base de données qui partage des répliques avec d'autres serveurs ne s'ouvre pas tant que son état au moment de l'arrêt du système n'a pas été restauré. En l'absence de fichiers journaux de transaction individuelle, vous devez suivre une procédure distincte pour tenter de récupérer ce qui a été perdu, comme expliqué à la Section 15.7, Récupération de la base de données en cas d'échec de la vérification de la restauration.
La consignation de transactions individuelles par fichier est désactivée par défaut. Vous devez l'activer pour pouvoir l'utiliser sur un serveur. Elle est également désactivée lorsque vous restaurez un serveur, et les paramètres reprennent leur valeur par défaut. Après une restauration, vous devez donc la réactiver et recréer votre configuration.
REMARQUE :Vous devez effectuer une nouvelle sauvegarde complète afin de vous protéger contre toute défaillance susceptible de survenir avant la prochaine sauvegarde complète sans surveillance planifiée.
Dans un environnement monoserveur, la consignation de transactions individuelles par fichier n'est pas nécessaire. Vous pouvez néanmoins l'utiliser si vous souhaitez pouvoir restaurer eDirectory dans l'état où il se trouvait avant son arrêt, au lieu de bénéficier simplement de l'état enregistré dans la dernière sauvegarde.
Pensez à contrôler l'espace disque lorsque la consignation de transactions individuelles par fichier est activée. Pour plus d'informations, reportez-vous à la section Sauvegarde et suppression des journaux de transactions individuelles.
Dans cette section :
Vous pouvez activer et configurer la consignation de transactions individuelles par fichier à l'aide d'iManager ou de DSBK. Reportez-vous à la section Configuration des fichiers journaux de transactions individuelles avec iManager ou à la section Configuration des fichiers journaux de transaction individuelle avec DSBK.
Si vous décidez d'utiliser la fonction de consignation de transactions individuelles par fichier, vous devez tenir compte des considérations suivantes :
Activez la fonction avant d'effectuer une sauvegarde si vous souhaitez pouvoir l'utiliser pour restaurer la base de données.
Pour assurer une tolérance aux pannes, veillez à placer les journaux de transactions individuelles sur un ensemble de disques durs différent de celui d'eDirectory. Par mesure de sécurité, veillez également à restreindre les droits d'accès aux fichiers journaux des utilisateurs. Pour plus d'informations, reportez-vous à la section Emplacement des fichiers journaux de transactions individuelles.
Notez l'emplacement des fichiers journaux de transactions individuelles. Pour plus d'informations, reportez-vous à la section Emplacement des fichiers journaux de transactions individuelles.
Contrôlez l'espace disque disponible à l'emplacement de stockage des fichiers journaux. Pour plus d'informations, reportez-vous à la section Sauvegarde et suppression des journaux de transactions individuelles.
Si les fichiers journaux ont été désactivés ou perdus, réactivez-les, puis effectuez une nouvelle sauvegarde complète afin de pouvoir effectuer une récupération totale. Cette opération est nécessaire dans les cas suivants :
Après une restauration. La consignation de transactions individuelles par fichier est désactivée et les paramètres reprennent leur valeur par défaut dans le cadre du processus de restauration.
Si vous perdez le répertoire contenant les fichiers journaux de transactions individuelles en raison de la défaillance d'un périphérique de stockage ou d'une autre panne.
Si les fichiers journaux de transactions individuelles ont été désactivés par inadvertance.
Si vous activez la consignation des fichiers de flux, les fichiers journaux de transactions individuelles consomment l'espace disque plus rapidement. Lorsque vous activez la consignation des fichiers de flux (les scripts de connexion, par exemple), c'est tout le fichier de flux qui est copié dans le journal de transactions individuelles chaque fois qu'il subit une modification. La taille des fichiers journaux augmentera moins rapidement si vous désactivez la consignation des fichiers de flux et ne sauvegarder ces derniers que lors d'une sauvegarde complète ou incrémentielle.
La phase la plus lente de la restauration de la base de données est la lecture des fichiers journaux de transactions individuelles. L'augmentation de la taille de ces fichiers journaux dépend du nombre de modifications apportées à l'arborescence et de la consignation éventuelle des fichiers de flux (tels que les scripts de connexion).
Si votre base de données change fréquemment, vous pouvez envisager d'effectuer plus souvent des sauvegardes d'eDirectory pour traiter moins de changements à partir des journaux de transactions individuelles durant une restauration.
Ne modifiez pas le nom d'un fichier journal de transaction individuelle. Si un fichier journal porte un nom différent de celui qu'il avait lors de sa création, il ne peut pas être utilisé dans une restauration.
N'oubliez pas que la suppression d'eDirectory entraîne celle de tous les fichiers journaux de transactions individuelles. Si vous souhaitez pouvoir utiliser les fichiers journaux pour une restauration ultérieure, vous devez les copier à un autre emplacement avant de supprimer eDirectory.
Si une restauration est nécessaire, veillez à reconfigurer les fichiers journaux de transactions individuelles sur le serveur une fois la restauration terminée afin de vous assurer qu'ils sont activés et qu'ils se trouvent à un emplacement assurant la tolérance aux pannes. Après avoir activé les journaux de transactions individuelles, vous devez également effectuer une nouvelle sauvegarde complète.
Cette opération est nécessaire car, au cours d'une restauration, la consignation de transactions individuelles par fichier reprend sa configuration par défaut, autrement dit elle est désactivée et l'emplacement par défaut est rétabli. Vous devez effectuer une nouvelle sauvegarde complète afin de vous protéger contre toute défaillance susceptible de survenir avant la prochaine sauvegarde complète sans surveillance planifiée.
Si vous activez la consignation de transactions individuelles par fichier, veillez à changer l'emplacement du répertoire des journaux de transactions individuelles afin d'utiliser une unité de stockage différente de celle d'eDirectory.
Voici quelques points importants à prendre en compte lors du choix de l'emplacement :
Ne laissez pas les fichiers journaux à l'emplacement par défaut. Veillez à les enregistrer sur un autre périphérique de stockage qu'eDirectory. Ainsi, si eDirectory est perdu en raison de la défaillance d'un périphérique de stockage, vous pouvez quand même accéder aux fichiers journaux de transactions individuelles pour le restaurer.
Si votre serveur ne comprend qu'un seul périphérique de stockage, les fichiers journaux de transaction individuelle ne permettent pas d'assurer la tolérance aux pannes d'eDirectory en cas de défaillance de ce périphérique. Dans ce cas, il est préférable de ne pas les utiliser.
Vous pouvez modifier l'emplacement des fichiers journaux de transaction individuelle à l'aide des options Configuration de la sauvegarde dans iManager ou setconfig dans DSBK. Ces fichiers journaux doivent se trouver dans un répertoire local du serveur.
Notez l'emplacement des fichiers journaux. Vous devez noter l'emplacement de stockage des fichiers journaux de transactions individuelles de manière à pouvoir les retrouver si vous devez restaurer la base de données sur un serveur. Il est important de le faire lorsque le serveur est sain, avant qu'un incident ne survienne.
Pour trouver cet emplacement lorsque le serveur est fonctionnel, vous pouvez utiliser l'option Configuration de la sauvegarde dans iManager ou backup getconfig dans DSBK. Toutefois, si le serveur connaît une défaillance affectant eDirectory (une panne matérielle, par exemple), vous ne pouvez pas rechercher l'emplacement des fichiers journaux de transaction individuelle.
Si vous tentez de restaurer un serveur qui a déjà subi une défaillance, sachez qu'à chaque nouvelle installation d'eDirectory, c'est l'emplacement par défaut des fichiers journaux de transactions individuelles qui est indiqué. Par conséquent, si vous venez de réinstaller eDirectory lors de la première étape d'un processus de restauration, eDirectory n'indique pas l'emplacement où étaient stockés les fichiers journaux avant la défaillance du serveur. Vous devez vous reporter à vos notes pour savoir où ils se trouvent.
La configuration des fichiers journaux de transaction individuelle est également enregistrée dans le fichier _ndsdb.ini, mais celui-ci figure sur le même volume/la même partition de disque qu'eDirectory. Par conséquent, si vous perdez le périphérique de stockage sur lequel se trouve eDirectory, vous ne pouvez pas employer ce fichier pour rechercher cet emplacement.
Limitez les droits d'accès pour l'emplacement de stockage des fichiers journaux de transactions individuelles. C'est une question de sécurité. Les informations ne sont pas facilement lisibles, mais il est possible de décoder les fichiers journaux pour accéder à des données sensibles.
Contrôlez si l'espace disque disponible est suffisant. Reportez-vous à la section Sauvegarde et suppression des journaux de transactions individuelles.
Il est recommandé de réserver un volume/une partition de disque aux journaux de transactions individuelles. Il est ainsi plus facile de contrôler les privilèges de sécurité et l'espace disque.
Le dernier répertoire du chemin d'accès est créé par eDirectory. Il correspond au nom de la base de données eDirectory actuelle.
Ainsi, si l'emplacement spécifié correspond à d:\Novell\NDS\DIBFileset le nom de votre base de données eDirectory à NDS, l'emplacement des fichiers journaux de transaction individuelle est alors d:\Novell\NDS\DIBFiles\nds.rfl. Si vous renommez la base de données NDS en ND1, le répertoire des fichiers journaux devient d:\Novell\NDS\DIBFiles\nd1.rfl.
Le répertoire est créé immédiatement après le changement d'emplacement, mais aucun fichier journal de transaction individuelle n'est créé tant qu'aucune transaction n'a lieu dans la base de données.
Lors de la restauration, tous les journaux de transactions individuelles nécessaires doivent figurer dans le même répertoire. Pour plus d'informations, reportez-vous à la Section 15.4, Préparation d'une restauration.
S'ils ne sont pas surveillés, les fichiers journaux de transactions individuelles peuvent saturer le volume/la partition de disque qui les reçoit. Si ces journaux ne peuvent pas être créés par manque d'espace disque, eDirectory cesse de fonctionner sur le serveur concerné. Il est conseillé de sauvegarder périodiquement les fichiers journaux et de supprimer du serveur ceux qui ne sont pas utilisés afin de libérer de l'espace disque.
Pour identifier, sauvegarder et supprimer les fichiers journaux de transactions individuelles dont la suppression ne pose pas de problème, procédez comme suit :
Notez le nom du dernier fichier journal de transaction individuelle inutilisé.
Pour trouver le nom de ce fichier journal, vous avez plusieurs possibilités :
Dans iManager, cliquez sur Maintenance > Configuration de la sauvegarde et lisez le nom de fichier affiché.
Dans le client DSBK, entrez la commande getconfig backup. Reportez-vous à la section Configuration des fichiers journaux de transaction individuelle avec DSBK pour plus d'informations.
Le dernier fichier journal de transaction individuelle inutilisé correspond au fichier le plus récent que la base de données a renseigné et qu'elle n'utilise plus pour enregistrer des transactions. Il s'agit du dernier fichier journal de transaction individuelle inutilisé puisque la base de données a fini d'y enregistrer des informations et a créé un nouveau fichier journal, de sorte qu'elle n'a plus besoin de le maintenir ouvert. Le fichier journal actuellement utilisé pour l'enregistrement des transactions est toujours nécessaire à la base de données.
Sauvegardez les fichiers journaux de transactions individuelles à partir du système de fichiers, afin de les enregistrer sur bande par mesure de sécurité.
Supprimez les fichiers journaux de transactions individuelles plus anciens que le dernier inutilisé.
AVERTISSEMENT :faites preuve de précaution lorsque vous supprimez des fichiers journaux de transactions individuelles du serveur. Assurez-vous que vous avez bien sauvegardé sur bande tous les fichiers journaux que vous supprimez.
Le dernier fichier journal de transaction individuelle inutilisé indique le nom du fichier que la base de données vient de compléter et de fermer. Il ne précise pas si vous pouvez supprimer ce fichier du serveur en toute sécurité. Veillez à ne supprimer que les fichiers que vous avez sauvegardés sur bande.
Si vous devez récupérer certains fichiers journaux de transactions individuelles sauvegardés sur bande afin de les utiliser dans une restauration, tenez compte des points suivants :
Comme tous les fichiers journaux de transactions individuelles utilisés pour une restauration, ceux récupérés à partir d'une bande de sauvegarde du système de fichiers doivent être placés dans le même dossier que les autres fichiers journaux, sur le serveur en cours de restauration.
Comparez les tampons horaires des fichiers dupliqués sur la bande et sur le serveur. Si les tampons horaires diffèrent, utilisez le fichier le plus récent, c'est-à-dire celui du serveur. Par exemple, le fichier journal de transaction individuelle que la base de données utilisait au moment de la sauvegarde du système de fichiers est incomplet sur la bande. La version complète et la plus récente de ce fichier figure sur le serveur.
Si vous supprimez eDirectory de votre serveur, le répertoire des fichiers journaux de transactions individuelles et son contenu sont également supprimés. Si vous souhaitez pouvoir utiliser les journaux ultérieurement pour restaurer le serveur, vous devez, avant de supprimer eDirectory, les copier à un autre emplacement.