Opération de compression de géodatabases
L'opération de compression de la géodatabase supprime les états et les lignes inutiles des tables système qui suivent les versions et les modifications versionnées.
Astuce:Pour comprendre la compression, vous devez d'abord comprendre comment le versionnement fonctionne. Si vous ne connaissez pas ce concept, reportez-vous à la rubrique Présentation rapide du versionnement.
Qu'est-ce qu'une opération de compression ?
L'opération de compression supprime les états qui ne sont plus référencés par une version et peut déplacer des lignes des tables delta vers la table métier. Une opération de compression ne peut être exécutée que par l'administrateur de géodatabase et porte sur tous les états de la géodatabase, quel que soit le propriétaire de la version.
Les opérations de compression sont nécessaires, car, au fur et à mesure qu'une géodatabase est modifiée, la taille des tables delta et le nombre d'états augmentent. Plus le nombre de tables et d'états est élevé, plus ArcGIS doit traiter de données à chaque fois que vous affichez ou interrogez une version. Par conséquent, le principal impact sur les performances n'est pas le nombre de versions mais le volume des modifications contenues dans les tables de deltas pour chaque version. En conséquence, les versions peuvent afficher des délais de réponse aux requêtes différents.
Pour maintenir les performances de la base de données, l'administrateur de géodatabase doit régulièrement exécuter une opération de compression afin de supprimer les données inutilisées.
Vous pouvez utiliser la commande Compresser ou l'outil de géotraitement Compresser d'ArcGIS for Desktop ou le script Python pour compresser une géodatabase. Reportez-vous à la rubrique Compression d'une géodatabase d'entreprise pour plus d'informations sur la compression d'une géodatabase dans l'arborescence du catalogue ou Compresser pour plus d'informations sur l'outil de géotraitement ou le script.
Que se passe-t-il lors d'une opération de compression ?
L'opération de compression parcourt d'abord la mémoire et analyse la configuration de l'arborescence de l'état de l'instance. En s'appuyant sur ces informations, la compression supprime tous les états qui ne participent pas à la généalogie d'une version. La suppression d'un état efface toutes les lignes des tables delta qui sont associées à cet état.
Au cours de l'étape suivante, l'opération de compression réduit les généalogies candidates d'états en un état. Une géologie candidate est une collection d'états pouvant être compressés en un état sans affecter la représentation logique d'une table dans une version donnée.
La dernière étape, le cas échéant, consiste à déplacer des lignes de tables de deltas dans les tables de base (ou métier).
Pour chaque étape de l'opération, les transactions de base de données sont démarrées et arrêtées pour chaque table en cours de compression. La transaction vérifie que chaque table est cohérente au cours de chaque étape du processus.
L'opération de compression peut être arrêtée avec la commande kill lorsqu'elle est en cours d'exécution, car l'opération est conçue pour être cohérente au niveau transactionnel. Par conséquent, si l'opération rencontre une erreur, échoue ou s'arrête brutalement, la cohérence des tables versionnées en cours de compression est préservée pour ce qui est de la représentation des versions. Vous pouvez arrêter l'opération de compression si vous la lancez alors que des utilisateurs sont connectés à la géodatabase, puis découvrez que cette opération consomme beaucoup de ressources système. Dans ce cas, il vous sera peut-être nécessaire d'arrêter l'opération et de la relancer lorsqu'un moins grand nombre d'utilisateurs, voire aucun, n'est connecté.
Comme une opération de compression peut être assez lourde, veillez à créer assez de journaux logiques et de disposer de suffisamment d'espace pour les fichiers journaux.
Compression complète d'une géodatabase
Dans une géodatabase entièrement compressée, les tables delta ne comportent aucune ligne et l'arborescence des états est tronquée au maximum, c'est-à-dire remise à zéro. L'amélioration des performances est optimale si la géodatabase est entièrement compressée. Pour ce faire, procédez comme suit :
- Réconciliez et réinjectez toutes les modifications en attente dans les versions enfants de la version DEFAULT. En tant qu'administrateur de géodatabase, vous pouvez voir dans quel ordre les versions doivent être réconciliées par défaut en ouvrant le sous-onglet Réconcilier l'ordre de l'onglet Versions dans la boîte de dialogue Administration de la géodatabase. Reportez-vous à la rubrique Propriétés de la version pour plus d'informations sur le sous-onglet Réconcilier l'ordre.
- Supprimez les versions après avoir réconcilié et réinjecté les mises à jour.
- Assurez-vous qu'aucun utilisateur n'est connecté.
- Lancez l'opération de compression.
Vous pouvez consulter les résultats de chaque opération de compression dans la table COMPRESS_LOG de la géodatabase (SDE_compress_log dans les géodatabases SQL Server et PostgreSQL). Vous pouvez aussi consulter la table VERSIONS (SDE_versions dans les géodatabases SQL Server et PostgreSQL) pour vérifier si l'identifiant d'état de la version DEFAULT est revenu à zéro. Si c'est le cas et s'il n'existe pas d'autres versions en attente, cela signifie qu'une compression complète a eu lieu.
Il n'est pas toujours possible de réconcilier, réinjecter et supprimer des versions, et de déconnecter tous les utilisateurs avant de procéder à une opération de compression. Par exemple, si vous effectuez le suivi de l'historique à l'aide de versions ou si vous devez gérer les versions successives d'un projet, l'état de l'historique et des versions successives reste tel quel dans l'arborescence des états. Par conséquent, ces états ne sont pas supprimés lors de la compression de la géodatabase. Vous pouvez effectuer une opération de compression sans ces étapes et tout de même constater des améliorations des performances.
Fréquence des opérations de compression
La fréquence des opérations de compression est fonction du nombre de mises à jour dont votre géodatabase fait l'objet. Si le nombre de mises à jour est important, effectuez une compression par jour. S'il est moyen ou faible, effectuez une compression au moins une fois par semaine.
Remarque :Il est important de ne pas attendre trop longtemps entre chaque opération. En effet, plus le nombre de mises à jour versionnées est important, plus la durée de compression est longue. Si vous ne procédez pas à au moins une compression par semaine, l'opération risque de durer plusieurs heures.
Après avoir compressé une géodatabase
Après avoir exécuté une opération de compression, vous devez actualiser les statistiques de votre géodatabase. L'administrateur de géodatabase doit mettre à jour les statistiques sur les tables système, et les utilisateurs individuels peuvent mettre à jour les statistiques sur leurs jeux de données modifiés. Pour plus d'informations sur la mise à jour des statistiques, reportez-vous à la rubrique Utiliser l'outil Analyser les jeux de données pour mettre à jour les statistiques sur les tables système de géodatabase ou Mise à jour des statistiques d'une géodatabase à l'aide de la commande Analyser.