Générales
SQL Server utilise le concept de Consignation en écriture anticipée, où chaque opération de modification de données est d’abord écrite dans le journal des transactions (. LDF) à partir de la mémoire (pool de tampons) et vidés périodiquement du fichier de données du disque (. MDF) dans le cadre du processus CheckPoint (les opérations de modification de données sont des opérations d’insertion, de mise à jour, de suppression et d’autres opérations, telles que la reconstruction et la réorganisation d’index). L’utilisation d’un journal des transactions garantit que, en cas de sinistre, vous pouvez restaurer la base de données à un état antérieur avec une perte de données minimale. Des exemples de sinistres sont notamment des défaillances matérielles ou des erreurs humaines.

Mode de récupération complète :
Après avoir sauvegardé la transaction à l’aide du mode de récupération complète, SQL Server marque les enregistrements sauvegardés comme inactifs et tronque le journal. De cette manière, toutes les nouvelles opérations consignées dans le journal des transactions peuvent réutiliser cet espace en écrasant les entrées inactives. Cette conception permet d’éviter la croissance de la taille du journal.

Si aucune sauvegarde régulière du journal des transactions n’est effectuée, la taille du journal des transactions continue de croître jusqu’à ce qu’il consomme tout l’espace disque disponible. Par conséquent, si votre base de données ePO est configurée pour utiliser le mode de récupération complète, il est important d’effectuer des sauvegardes régulières du journal des transactions pour conserver sa taille dans la vérification.

Mode de récupération simple :
Dans le mode de récupération simple, lorsque le point de contrôle est atteint et que les enregistrements sont vidés sur le disque, SQL Server tronque le journal des transactions. Cette action permet de libérer de l’espace en interne dans le fichier journal des transactions. La taille du journal des transactions n’augmente pas tant qu’il y a suffisamment d’espace disponible pour les transactions actuellement ouvertes.

Dans le mode de récupération simple, le concept de sauvegarde du journal des transactions n’est pas utilisé, car vous effectuez une sauvegarde complète régulière de la base de données ePO. En cas de sinistre, vous pouvez uniquement récupérer la dernière sauvegarde complète. Toutes les modifications qui ont lieu après la dernière sauvegarde complète sont perdues.

Le mode de récupération simple est une solution acceptable pour la plupart des clients d’entreprise, car les données perdues en cas d’incident sont généralement des données d’événement depuis la dernière sauvegarde complète. Le mode de récupération complète inclut la surcharge administrative liée à la sauvegarde du journal des transactions de votre base de données ePO de façon périodique.

Pour cette raison, le Modèle de récupération simple pour la base de données ePO est recommandée. Toutefois, si vous choisissez d’utiliser le mode de récupération complète, assurez-vous que vous disposez d’un bon plan de sauvegarde pour la base de données ePO et le journal des transactions. La description du plan de sauvegarde des bases de données SQL Server dépasse le cadre de cet article. Pour plus d’informations, voir la documentation technique SQL Server.

REMARQUE : Si vous disposez de plusieurs bases de données avec différents modèles de récupération, vous pouvez créer des plans de maintenance de base de données distincts pour chaque mode de récupération. De cette façon, vous pouvez inclure une étape de sauvegarde des journaux des transactions uniquement sur les bases de données qui n’utilisent pas le mode de récupération simple.

Définition du mode de récupération de la base de données ePO sur simple
Pour vérifier que le mode de récupération est défini sur simple, apportez les modifications suivantes dans SQL Server Management Studio :

1. Cliquez sur Tous les programmes, Microsoft SQL Server <version>, SQL Server Management Studio.
2. Sélectionnez le fichier Authentification Saisissez (Windows ou SQL Server), puis cliquez sur Connecter permet de se connecter au SQL Server instance hébergeant la base de données ePO.
3. Dans la fenêtre Explorer d’objets, développez la section Bases de données sous.
4. Cliquez avec le bouton droit sur le ePO_<server name> mention.
5. Sélectionner Propriétés. La fenêtre Propriétés de la base de données s’ouvre.
6. Cliquez sur Options dans la Sélectionner une page zone du volet gauche.
7. Cliquez sur la flèche déroulante à droite de l’option Mode de récupération et sélectionnez Simple.
8. Cliquez sur OK.

Lorsque vous réduisez le fichier de données, les pages situées à la fin du fichier de données sont déplacées au début du fichier. Cette action ignore toute fragmentation potentielle introduite dans ce processus.

Si la taille de la base de données ePO augmente après la suppression des événements et la réduction de la base de données, un espace est nécessaire pour les événements envoyés par le agent. La réduction du fichier de données après la suppression des événements entraîne uniquement la croissance de la taille du fichier, en plus de provoquer la fragmentation. Si l’espace est important, pensez à filtrer les événements non essentiels à l’aide du filtrage des événements ePO.

REMARQUE : Vous pouvez envisager de réduire le fichier de données après avoir effectué de nombreuses opérations de suppression. Par exemple, purgez les anciens événements si vous savez que vous n’avez plus besoin de cet espace pour le stockage des nouveaux événements. Sinon, reconstruisez les index régulièrement et filtrez les événements inutiles à l’aide du filtrage des événements ePO pour éviter de capturer les données indésirables en premier lieu.

IMPORTANT : Le filtrage des événements a un impact direct sur les rapports qui peuvent être générés à l’aide de ces événements. Assurez-vous de filtrer uniquement les événements dont vous savez qu’ils ne sont pas nécessaires pour les rapports quotidiens. Sauvegardez la base de données ePO avant de purger les événements plus anciens. Pour vous y référer ultérieurement, vous pouvez toujours restaurer cette sauvegarde de la base de données ePO sous un nouveau nom afin de générer des rapports pour cette période.

Tant que la maintenance appropriée de la base de données est effectuée, par exemple la reconstruction et la réorganisation des index, la taille de la base de données ePO n’a pas d’incidence négative sur les performances des requêtes. Si vous purgez régulièrement les anciens événements, par exemple tous les événements de plus de trois mois, en utilisant la ePO Purge Events Server Task , la taille de la base de données est stabilisée. La taille de la base de données est stabilisée en supposant que les taux de croissance de la base de données sont proportionnels aux entrées supprimées et aux anciens événements.

Un plan de maintenance de base de données doit être configuré pour que les performances de la base de données ePO soient correctes.

Créez un plan de maintenance pour la base de données ePO dans SQL Server :

1. Cliquez sur Tous les programmes, Microsoft SQL Server <version>, SQL Server Management Studio.
2. Sélectionnez le fichier Authentification Saisissez (Windows ou SQL Server), puis cliquez sur Connecter permet de se connecter au SQL Server instance hébergeant la base de données ePO.
3. Développer Gestion dans la fenêtre Explorer d’objets serveur.
4. Cliquez avec le bouton droit sur Plans de maintenance et sélectionnez Assistant Plan de maintenance.
5. Entrez un nom pour le plan de maintenance (par exemple, plans de maintenance des bases de données ePO).
6. Modifiez la planification. Cliquez sur Modifier puis cliquez sur Suivant.
   REMARQUE : Planifiez la tâche pour qu’elle s’exécute pendant les heures creuses (par exemple, une tâche récurrente tous les samedis à 11 h).
   
7. Sélectionnez les options suivantes sous Tâches de maintenance et cliquez sur Suivant:
   • Vérifier l’intégrité de la base de données
   • Reconstruire l’index
   • Enregistrerr la base de données (complète)
     
8. Définissez l’ordre d’exécution des tâches comme suit, puis cliquez sur Suivant:
   • Vérifier l’intégrité de la base de données
   • Enregistrerr la base de données (complète)
   • Reconstruire l’index
   REMARQUE : Ces tâches peuvent être interchangeables en fonction de l’ordre dans lequel elles s’exécutent. Créez une sauvegarde de la base de données avant le processus de reconstruction de l’index. Cette configuration vérifie qu’il existe une copie de sauvegarde correcte de la base de données en cas de problème au cours du processus de reconstruction.
   
9. Définir une Vérifier l’intégrité de la base de données tâche
   1. Sélectionner la base de données ePO ePO_<servername>.
   2. Sélectionner Inclure les index.
   3. Cliquez sur Suivant.
      
10. Définir une Enregistrerr la base de données (complète) tâche
    1. Sélectionner la base de données ePO ePO_<servername>.
    2. Entrez l’emplacement du chemin d’accès de sauvegarde.
    3. Dans le sous-dossier Définir la compression de la sauvegarde liste déroulante, sélectionnez Compresser la sauvegarde.
    4. Cliquez sur Suivant.
       
11. Définir une Reconstruire l’index tâche
    1. Sélectionner la base de données ePO ePO_<servername>.
    2. Cliquez sur Objet : tableaux et vues.
    3. Cliquez sur Modifiez l’espace libre par page en pourcentage de 10%..
    4. Sous Options avancées, sélectionnez Conserver l’index en ligne lors de la réindexation.
       REMARQUE : Toutes les éditions de SQL Server ne prennent pas en charge la reconstruction en ligne des index. Pour plus d’informations sur les éditions qui prennent en charge la reconstruction en ligne d’index, consultez la documentation en ligne de SQL Server.
       
    5. Pour les types d’index qui ne prennent pas en charge les reconstructions d’index en ligne, sélectionnez l’option Reconstruction des index hors ligne.
    6. Cliquez sur Suivant.
       
       REMARQUE : Une tâche de reconstruction d’index entraîne la mise à jour des statistiques dans le cadre de la reconstruction efficacement avec une analyse complète. Ainsi, un Mettre à jour les statistiques la tâche n’est pas nécessaire après un index de reconstruction.
       
12. Définit Sélectionner les options de rapport:
    1. Sélectionner Écrire un rapport dans un fichier texte et indiquez l’emplacement souhaité pour le dossier.
    2. Cliquez sur Suivant.
    3. Cliquez sur Terminer.

• ePO 5.10 comporte deux bases de données SQL uniques : la base de données principale et la nouvelle base de données d’événements ePO.
• Les bases de données des événements principal et ePO doivent être gérées à l’aide des étapes décrites dans cet article.
• L’exécution du script ci-dessous uniquement sur la base de données principale permet à la base de données des événements ePO d’être fragmentée au fil du temps. Cela entraîne des problèmes de performances potentiels. Pour plus d’informations sur la base de données des événements ePO, reportez-vous à la section KB91176-New ePO Events et au mode de récupération recommandé pour ePolicy Orchestrator 5.10.

• Si la fragmentation est comprise entre 20 et 30%, réorganisez l’index.
• Si la fragmentation est > 30%, reconstruisez l’index.

Vous pouvez personnaliser davantage la script afin d’inclure l’option permettant d’effectuer une reconstruction en ligne des index. La reconstruction en ligne permet d’obtenir davantage de simultanéité lors de la reconstruction de l’index et nécessite une utilisation intensive des ressources. Cette fonctionnalité n’est pas disponible dans toutes les éditions de SQL Server. Reportez-vous à la documentation en ligne sur les éditions qui prennent en charge la fonctionnalité de reconstruction en ligne des index.