La consignation de transactions individuelles par fichier s'apparente à la journalisation dans d'autres produits de bases de données. Les 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 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 crée un enregistrement des transactions dans un fichier journal avant d'appliquer celles-ci à la base de données. Par défaut, ce fichier journal est réutilisé continuellement (tout en occupant peu d'espace sur le disque) et l'historique des changement 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 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 que eDirectory est déjà en train de créer.
Vous devez activer la fonction de consignation de transactions individuelles par fichier pour les serveurs qui font partie d'un anneau de répliques. Si vous ne le faites pas, des erreurs se produisent lors de la restauration à partir des fichiers de sauvegarde et la base de données ne s'ouvre pas. Avec la restauration par défaut, une base de données qui partage des répliques avec d'autres serveurs n'est pas ouverte tant qu'elle n'a pas été restaurée dans l'état où elle se trouvait au moment de l'arrêt du système. (Si vous n'avez pas de journaux de transactions individuelles, vous devez suivre une procédure distincte pour tenter de récupérer ce qui a été perdu, comme expliqué dans Récupération de la base de données en cas d'échec de la vérification de la restauration.)
Par défaut, la consignation de transactions individuelles par fichier est désactivée. Vous devez l'activer si vous voulez 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. (Vous devez effectuer la 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 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 à 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 de iManager ou du client eMBox. Reportez-vous à Configuration des journaux de transactions individuelles avec iManager ou à Configuration des journaux de transactions individuelles à l'aide du client eMBox.
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 de eDirectory. Par mesure de sécurité, veillez également à restreindre les droits d'accès aux journaux octroyés aux utilisateurs. Pour plus d'informations, reportez-vous à Emplacement des journaux de transactions individuelles.
Notez l'emplacement des journaux de transactions individuelles. Pour plus d'informations, reportez-vous à Emplacement des journaux de transactions individuelles.
Contrôlez l'espace disponible là où sont stockés les journaux de transactions individuelles. Pour plus d'informations, reportez-vous à Sauvegarde et suppression des journaux de transactions individuelles.
Si les 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. Cela est nécessaire dans les cas suivants :
Si vous activez la consignation des fichiers de flux, les journaux de transactions individuelles consomment l'espace disque plus rapidement. Lorsque vous activez la consignation des fichiers de flux (les scripts de login, par exemple), le fichier de flux complet est copié dans le journal de transactions individuelles chaque fois qu'il subit une modification. Vous pouvez ralentir l'extension des fichiers journal en désactivant 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 journaux de transactions individuelles. L'extension de ces journaux est plus ou moins rapide selon le nombre de modifications apportées à l'arborescence et selon que les fichiers de flux (tels que les scripts de login) sont consignés ou non.
Si votre base de données change fréquemment, vous pouvez envisager d'effectuer des sauvegardes de eDirectory plus souvent pour avoir moins de changements à traiter à partir des journaux de transactions individuelles durant une restauration.
Ne changez pas le nom d'un journal de transaction individuelle. Si un 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 qu'en supprimant eDirectory vous supprimez également tous les journaux de transactions individuelles. Si vous souhaitez pouvoir utiliser les journaux ultérieurement pour une restauration, vous devez, avant de supprimer eDirectory, les copier à un autre emplacement.
Si une restauration est nécessaire, veillez à reconfigurer les journaux de transactions individuelles sur le serveur une fois la restauration terminée pour vous assurer que les journaux sont activés et qu'ils se trouvent à un emplacement qui autorise 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 configuration de la consignation de transactions individuelles reprend son état par défaut, c'est-à-dire qu'elle est désactivée et que l'emplacement correspondant reprend sa valeur par défaut. Vous devez effectuer la 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 de eDirectory.
Voici quelques points importants à prendre en compte lors du choix de l'emplacement :
Ne laissez pas les journaux à l'emplacement par défaut ; veillez à les enregistrer sur une unité de stockage différente de celle de eDirectory. Ainsi, si eDirectory est perdu suite à la défaillance d'une unité de stockage, vous pouvez tout de même accéder aux journaux de transactions individuelles pour le restaurer.
Par exemple, sous NetWare, l'emplacement par défaut correspond à sys:_netware\nds.rfl\. Si vous activez la consignation de transactions individuelles par fichier, vous ne devez pas utiliser l'emplacement par défaut. Les journaux ne doivent pas résider sur le volume sys: car il s'agit du volume sur lequel se trouve la base de données eDirectory.
Si votre serveur ne comprend qu'une seule unité de stockage, les journaux de transactions individuelles ne permettent pas d'assurer la tolérance aux pannes de eDirectory en cas de défaillance d'une telle unité. Dans ce cas, il est préférable de ne pas les utiliser.
Vous pouvez modifier l'emplacement des journaux de transactions individuelles à l'aide des options Configuration de la sauvegarde dans iManager ou setconfig dans le client eMBox. Le répertoire de ces journaux doit être un répertoire local du serveur.
Notez l'emplacement des journaux. Vous devez noter l'emplacement de stockage des journaux de transactions individuelles afin d'être en mesure de les retrouver si vous avez besoin de 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 localiser cet emplacement pendant que le serveur est en état de marche, vous pouvez consulter l'option Configuration de la sauvegarde dans iManager, ou l'option getconfig dans le client eMBox. Toutefois, si le serveur subit une défaillance affectant eDirectory (une panne matérielle, par exemple), vous ne pouvez pas rechercher l'emplacement des journaux de transactions individuelles.
Si le serveur a déjà subi une défaillance et si vous tentez de le restaurer, sachez que pour toute nouvelle installation de eDirectory, c'est l'emplacement par défaut des 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 journaux avant la défaillance du serveur. Vous devez vous reporter à vos notes pour savoir où ils se trouvent.
La configuration des journaux de transactions individuelles est également enregistrée dans le fichier _ndsdb.ini, mais celui-ci figure sur le même volume/la même partition de disque que eDirectory. Par conséquent, si vous perdez l'unité de stockage sur laquelle se trouve eDirectory, vous ne pouvez pas employer ce fichier pour rechercher cet emplacement.
Limitez les droits d'accès à l'emplacement où sont stockés les 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 journaux pour accéder à des données sensibles.
Contrôlez l'espace disque disponible pour vous assurer qu'il est suffisant. Pour plus de détails, reportez-vous à 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\DIBFiles\ et le nom de votre base de données eDirectory à NDS, l'emplacement des journaux de transactions individuelles correspond alors à d:\Novell\NDS\DIBFiles\nds.rfl\. Si vous renommez la base NDS en ND1, le répertoire des journaux de transactions individuelles devient d:\Novell\NDS/DIBFiles\nd1.rfl.
Le répertoire est créé immédiatement après le changement d'emplacement, mais aucun 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 à Préparation d'une restauration.
S'ils ne sont pas surveillés, les 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 journal et de supprimer du serveur ceux qui ne sont pas utilisés afin de faire de la place sur le disque.
Pour identifier, sauvegarder et éliminer les journaux de transactions individuelles dont la suppression ne pose pas de problème :
Notez le nom du dernier journal de transactions individuelles inutilisé.
Pour trouver le nom du dernier journal de transaction individuelle inutilisé, procédez comme suit :
Le dernier journal de transactions individuelles inutilisé correspond au journal le plus récent que la base de données a renseigné et qu'elle n'utilise plus pour enregistrer des transactions. C'est le dernier journal de transaction individuelle inutilisé parce que la base de données a fini d'y enregistrer des informations et a commencé un nouveau fichier journal, de sorte qu'elle n'a plus besoin de le maintenir ouvert. (Le journal dans lequel la base de données enregistre actuellement des transactions est utilisé et est encore nécessaire à la base de données.)
Effectuez une sauvegarde des journaux de transactions individuelles à partir du système de fichiers, afin de les enregistrer sur bande par mesure de sécurité.
Supprimez les journaux de transactions individuelles plus anciens que le dernier inutilisé.
AVERTISSEMENT :
sachez que lorsque vous supprimez des journaux de transactions individuelles du serveur, vous devez le faire avec précaution. Comparez attentivement les journaux avec ceux de votre sauvegarde sur bande, afin de vous assurer que celle-ci contient tous ceux que vous supprimez.
Le dernier journal de transactions individuelles inutilisé indique le nom du fichier que la base de données vient de compléter et de fermer. Il n'indique pas si vous pouvez supprimer ce fichier du serveur en toute sécurité. Veillez à ne supprimer que les fichiers dont vous possédez une sauvegarde sur bande.
Si vous devez récupérer certains journaux de transactions individuelles à partir d'une bande afin de les utiliser dans une restauration, tenez compte des points suivants :
Si vous supprimez eDirectory de votre serveur, le répertoire des 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.