La compression de géodatabase supprime les états et les lignes inutiles des tables système de géodatabase qui effectuent le suivi des versions (classique) et des modifications versionnées.
Qu'est-ce que la compression de géodatabase ?
La compression supprime les états qui ne sont plus référencés par une version classique et peut déplacer des lignes des tables delta vers la table métier. Seul l'administrateur de géodatabase peut compresser la géodatabase, mais la compression porte sur tous les états de la géodatabase, quel que soit le propriétaire de la version.
La compression est nécessaire car, au fur et à mesure qu'une géodatabase utilisant le versionnement classique 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 delta 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, l'administrateur de géodatabase doit effectuer des compressions régulières de la géodatabase afin de supprimer les données inutilisées.
Vous pouvez utiliser la commande Compresser ArcGIS Desktop ou l'outil de géotraitement Compresser ou un script Python.
Déroulement de la compression
La compression parcourt d'abord la mémoire et analyse la configuration de l'arborescence d'é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.
L'étape suivante 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, déplace des lignes de tables delta dans les tables de base (ou métier).
À 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.
La compression peut être arrêtée 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 la compression si vous la lancez alors que des utilisateurs sont connectés à la géodatabase, puis découvrez que la compression 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é à la géodatabase.
Assurez-vous de créer assez de journaux logiques pour gérer la transaction la plus longue. Typiquement, quand vous compressez une géodatabase, des transactions longues se produisent. Vous devez sauvegarder vos journaux logiques avant d'atteindre le pourcentage de la limite supérieure de la transaction longue défini par le paramètre LTXHWM dans le fichier onconfig Informix. Ne changez pas le paramètre LTXHWM ou LTXEHWM sans l'avis favorable d'un expert du support technique Informix qui connaît le comportement d'Informix Spatial DataBlade. Si une transaction ne parvient pas à se terminer et est annulée, car elle a atteint la limite supérieure de la transaction longue, cela signifie que vous n'avez pas suffisamment de journaux logiques.
Pendant la compression de géodatabases volumineuses, la base de données Informix peut manquer de verrous. Pour empêcher ce problème de survenir, les tables sont verrouillées en mode exclusif pendant la compression. Pour cela, le verrouillage exclusif doit être désactivé lors de la compression. Attribuez au paramètre de configuration USE_EXCLUSIVE_LOCKING la valeur False pour permettre la compression pendant que plusieurs utilisateurs sont connectés. Pour en savoir plus sur la modification de la valeur des paramètres de configuration, reportez-vous à la rubrique Modifier les mots-clés de configuration.
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 en ouvrant le sous-onglet Reconcile Order (Ordre de réconciliation) de l'onglet Versions dans la boîte de dialogue Geodatabase Administration (Administration de géodatabase) dans ArcMap. Reportez-vous à la rubrique Propriétés de la version pour plus d'informations sur le sous-onglet Reconcile Order (Ordre de réconciliation).
- Supprimez les versions descendantes après avoir réconcilié et réinjecté les mises à jour.
- Assurez-vous qu'aucun utilisateur n'est connecté à la géodatabase.
- Compresser la géodatabase.
Vous pouvez voir les résultats de chaque compression dans ArcGIS Desktop dans la table compress_log. Vous pouvez également consulter la table versions dans la base de données pour voir si l'ID 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 à la 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 de compression
La fréquence de compression de la géodatabase dépend 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.
Après avoir compressé une géodatabase
Mettez à jour les statistiques de la géodatabase après la compression. L'administrateur de géodatabase doit mettre à jour les statistiques sur les tables système de versionnement, et les utilisateurs individuels peuvent mettre à jour les statistiques sur leurs jeux de données modifiés.