Segmentation des tables de base de données

Si vous avez reçu un message d'avertissement de segmentation des tables lors de la mise à niveau du Data Aggregator, segmentez les tables de base de données au niveau du Data Repository. La segmentation des tables est une tâche unique requise pour les systèmes où l'installation d'origine est une version antérieure à la version 2.3.3. La segmentation des tables réduit la quantité d'espace disque requis pour la base de données. Elle permet également d'améliorer les performances d'interrogation en général.
capm280
Si vous avez reçu un message d'avertissement de segmentation des tables lors de la mise à niveau du Data Aggregator, segmentez les tables de base de données au niveau du Data Repository. La segmentation des tables est une tâche unique requise pour les systèmes où l'installation d'origine est une version antérieure à la version 2.3.3. La segmentation des tables réduit la quantité d'espace disque requis pour la base de données. Elle permet également d'améliorer les performances d'interrogation en général.
Si vous ne savez pas si votre base de données requiert une segmentation, téléchargez le script et identifiez les tables nécessitant une segmentation. Si la segmentation est déjà complète ou si elle n'est pas requise, le script ne renvoie aucune table.
Vous pouvez segmenter les tables de base de données, que les composants Data Aggregator et Data Collector soient actifs ou arrêtés.
La segmentation est un processus qui consomme beaucoup de ressources. Nous vous recommandons
vivement
d'arrêter le Data Aggregator et les Data Collectors pour segmenter les tables de base de données.
La segmentation peut prendre plusieurs heures lorsque les tables incluses dans la base de données sont volumineuses. Lors des tests, la migration des tables de plus de 100 Go a duré plus de 10 heures. Le temps nécessaire à l'opération de segmentation n'est pas proportionnel à la taille de la table. La durée dépend de nombreux facteurs et notamment du nombre de lignes, de colonnes, de la compression des données et des spécifications système.
Aucune surveillance active de votre environnement d'infrastructure n'a lieu lorsque le Data Aggregator et les Data Collectors sont arrêtés.
Les limitations suivantes s'appliquent si vous segmentez les tables de base de données alors que le Data Aggregator est en service :
  • N'effectuez aucune tâche d'administration du Data Aggregator :
    • Modification des profils de surveillance
    • Association des collections à des profils de surveillance
    • Augmentation des fréquences d'interrogation
    • Exécution de nouvelles détections
  • Réduisez le plus possible la charge des rapports.
Utilisez la procédure suivante pour segmenter les tables de base de données :
Identification des tables qui requièrent une segmentation
Avant de lancer la segmentation des tables, identifiez les tables nécessitant une segmentation.
Procédez comme suit :
  1. Téléchargez le script segment.py à sur le site du support de CA :Dans cette procédure, le script segment.py se trouve dans le répertoire de base de l'administrateur de la base de données Vertica Linux.
  2. Connectez-vous à un hôte du cluster Data Repository en tant qu'administrateur de la base de données Vertica Linux.
  3. Exécutez le script suivant :
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    • mot_passe_administrateur_BdD
      Mot de passe d'administrateur de la base de données Vertica Linux
    • nom_BdD
      Nom de la base de données
      Valeur par défaut
      : drdata
      Ce paramètre est sensible à la casse.
    • port_BdD
      Port Vertica
      Valeur par défaut
      : 5433
    Par exemple :
    ./segment.py --task tables --pass password
    -
    -name
    mydatabase
    Toutes les prévisions de table actuellement non segmentées (triées dans l'ordre décroissant) sont renvoyées. Si une table nécessite une segmentation, continuez ce processus.
Sauvegarde du Data Repository
Avant de segmenter les tables, sauvegardez le Data Repository.
Une fois la segmentation terminée, l'espace disque pour la sauvegarde augmente en fonction de la quantité de données dans les nouvelles prévisions de tables segmentées. Vérifiez que le système de sauvegarde dispose de l'espace disque suffisant à l'issue de la segmentation et avant l'exécution de sauvegardes.
Les données des anciennes prévisions de table non segmentée sont supprimées des données de sauvegarde un jour après l'heure indiquée pour la valeur restorePointLimit. Pour supprimer ces données immédiatement, modifiez le nom de cliché dans le fichier de configuration de la sauvegarde et effectuez une sauvegarde complète. Vous pouvez ensuite archiver l'ancienne sauvegarde, puis la supprimer du disque. Utilisez la sauvegarde de présegmentation uniquement si vous ne pouvez pas utiliser celle créée une fois la segmentation terminée. Si vous utilisez la sauvegarde de présegmentation, une nouvelle opération de segmentation sera requise au niveau des tables.
Pour plus d'informations, reportez-vous à la section Sauvegarde du Data Repository.
Segmentation des tables ne contenant aucune donnée
Les tables sans date sont segmentées rapidement et la segmentation n'a pas d'impact négatif sur les performances. Il n'est pas nécessaire d'arrêter le Data Aggregator pour pouvoir segmenter ces tables.
Procédez comme suit :
  1. Connectez-vous à un hôte du cluster Data Repository en tant qu'administrateur de la base de données Vertica Linux.
  2. Exécutez le script suivant :
    ./segment.py --task segment --zerotables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    • mot_passe_administrateur_BdD
      Mot de passe d'administrateur de la base de données Vertica Linux
    • nom_BdD
      Nom de la base de données
      Valeur par défaut :
      drdata
      Ce paramètre est sensible à la casse.
    • port_BdD
      Port Vertica
      Valeur par défaut
      : 5433
    Le script segmente les tables de base de données ne contenant aucune donnée.
Détermination de l'heure de segmentation des tables
Pour déterminer si une segmentation des tables est nécessaire lorsque le Data Aggregator est activé ou désactivé, calculez le temps nécessaire pour cette opération.
Procédez comme suit :
  1. Obtenez la liste des tables nécessitant une segmentation :
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    Le paramètre
    database_name
    est sensible à la casse.
    La liste trie les tables selon leur taille, par ordre décroissant.
  2. Désactivez les sauvegardes Data Repository planifiées jusqu'à la finalisation de la segmentation. Les sauvegardes peuvent interférer avec le processus de segmentation.
  3. Sélectionnez une table à l'étape 1 d'environ 5 Go et segmentez-la :
    ./segment.py --task segment --table
    rate_table_name
    --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    Le paramètre
    database_name
    est sensible à la casse.
    Vous pouvez exécuter cette commande lorsque Data Aggregator est en cours d'exécution, mais nous vous recommandons de l'exécuter dans une fenêtre de maintenance de 2 à 3 heures.
  4. Réactivez les sauvegardes Data Repository planifiées.
  5. Utilisez la durée de segmentation de la table de 5 Go pour déterminer la durée nécessaire pour segmenter toutes les tables de moins de 100 Go.
    La durée réelle nécessaire pour segmenter les tables de la base de données peut varier en fonction du type et de la compression des données dans les tables. Les valeurs calculées ici sont de simples estimations. Lorsque vous planifiez une fenêtre de maintenance, ajoutez une heure supplémentaire pour chaque portion de 10 à 15 Go des tables de base de données. Pour les bases de données volumineuses, vous ne serez peut-être pas en mesure de planifier une fenêtre de maintenance unique pour la segmentation de l'ensemble de la base de données. Dans ce cas, vous pouvez segmenter les tables de base de données sur plusieurs fenêtres de maintenance.
Segmentation des autres tables de base de données
Segmentez les tables restantes.
Lors de la segmentation des tables dans la base de données, si le Data Aggregator est en cours d'exécution, au moins 40 % de l'espace disque disponible doit rester libre pour le traitement des requêtes et pour les autres activités de la base de données. Lorsque le Data Aggregator n'est pas en cours d'exécution, l'utilisation totale du disque pendant la segmentation ne doit pas dépasser 90 % de l'espace disponible sur le disque. Les tables qui entraîneraient un dépassement de l'utilisation du disque au-delà de la limite de 90 % pendant la segmentation ne sont pas segmentées.
Procédez comme suit :
  1. En tant qu'administrateur de la base de données Vertica Linux, connectez-vous à un des ordinateurs du cluster sur lequel Data Repository est installé.
  2. Lors de la validation de la segmentation de prévisions relatives à la table dans la procédure précédente, si plus de dix prévisions de table dont la longueur est de zéro ont été observées au cours de cette vérification, entrez la commande suivante pour les segmenter :
    ./segment.py --task segment --pass database_admin_user_password --zerotables [--name database_name] [--port database_port]
    • mot_passe_administrateur_BdD
      Mot de passe d'administrateur de la base de données Vertica Linux
    • nom_BdD
      Nom de la base de données
      Valeur par défaut :
      drdata
      Ce paramètre est sensible à la casse.
    • port_BdD
      Port Vertica
      Valeur par défaut
      : 5433
    Par exemple :
    ./segment.py --task segment --pass password --zerotables --name mydatabase --port 1122
  3. Si la taille de certaines prévisions de table dépasse 100 Go, entrez la commande suivante pour créer un script afin de commencer par segmenter les prévisions de table dont la taille est
    inférieure à
    100 Go :
    ./segment.py --task script --pass database_admin_user_password --lt100G [--name database_name] [--port database_port]
    • mot_passe_administrateur_BdD
      Mot de passe d'administrateur de la base de données Vertica Linux
    • nom_BdD
      Nom de la base de données
      Valeur par défaut :
      drdata
      Ce paramètre est sensible à la casse.
    • port_BdD
      Port Vertica
      Valeur par défaut
      : 5433
    Par exemple :
    ./segment.py --task script --pass password --lt100G --name mydatabase --port 1122
  4. Désactivez les sauvegardes planifiées tant que la segmentation n'est pas terminée. Les sauvegardes peuvent interférer avec le processus de segmentation.
  5. Pour exécuter le script segment-script.sh, saisissez la commande suivante :
    nohup ./segment-script.sh
    Le script segmente toutes les prévisions de table non segmentées dont la taille est inférieure à 100 Go et les trie dans l'ordre croissant (de la moins volumineuse à la plus volumineuse). Le résultat est envoyé au fichier nohup.out. Si le shell est fermé par inadvertance, le script continue de s'exécuter.
    Selon la taille de votre fenêtre de maintenance et de la taille combinée de toutes les tables inférieures à 100 Go, déterminez quelles tables peuvent être segmentées au cours de la fenêtre de maintenance. Modifiez le script généré en supprimant les tables qui ne tiennent pas dans la fenêtre de maintenance. Exécutez le fichier segment-script.sh généré au cours de la fenêtre de maintenance. Si certaines tables de moins de 100 Go n'ont pas pu être segmentées au cours de la fenêtre de maintenance, générez de nouveau le script et exécutez le script segment-script.sh lors de la prochaine fenêtre de maintenance planifiée autant de fois que nécessaire pour que toutes les tables soient segmentées.
    Lorsque vous exécutez le script, les tables qui entraînent une utilisation du disque au-delà de la limite de 90 % affichent un message d'erreur et ne sont pas segmentées. Pour pouvoir segmenter ces tables, vous avez besoin de davantage d'espace disque.
    Un message apparaîtra pour chaque table entraînant un dépassement de l'utilisation de disque au-delà de 60 %. Il est vivement recommandé d'arrêter Data Aggregator avant de segmenter ces tables.
    L'exécution de ce script peut prendre plusieurs heures. N'interrompez pas l'exécution du script une fois lancée pour éviter d'endommager la base de données.
  6. Réactivez les sauvegardes planifiées uniquement si d'autres opérations de segmentation sont nécessaires et seront effectuées au cours d'une fenêtre de maintenance ultérieure.
  7. Générez un script (segment-script.sh), qui segmente les autres prévisions de table de plus de 100 Go :
    ./segment.py --task script --pass database_admin_user_password [--name database_name] [--port database_port]
    • mot_passe_administrateur_BdD
      Mot de passe d'administrateur de la base de données Vertica Linux
    • nom_BdD
      Nom de la base de données
      Valeur par défaut :
      drdata
      Ce paramètre est sensible à la casse.
    • port_BdD
      Port Vertica
      Valeur par défaut
      : 5433
    Par exemple :
    ./segment.py --task script --pass password --name mydatabase --port 1122
    Lorsque le script est généré, les tables qui peuvent entraîner un dépassement de l'utilisation du disque au-delà de 60 % et 90 % sont indiquées.
  8. Si ce n'est déjà fait, désactivez les sauvegardes planifiées.
  9. Pour exécuter le script segment-script.sh, saisissez la commande suivante :
    nohup ./segment-script.sh
    Le script segmente toutes les tables non segmentées et les trie dans l'ordre croissant.
  10. Vérifiez que toutes les tables sont segmentées :
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    Le paramètre
    database_name
    est sensible à la casse.
    Le message suivant s'affiche :
    No tables found with unsegmented projections.
  11. Réactivez les sauvegardes planifiées.
  12. Si vous avez segmenté les tables de base de données alors que le Data Aggregator et le Data Collector étaient hors service, démarrez ces composants.