La compression de géodatabase supprime les états et les lignes inutiles des tables système qui effectuent le suivi des versions 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 et peut déplacer des lignes des tables de deltas 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 est modifiée, la taille des tables de deltas 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 effectuer des compressions régulières afin de supprimer les données inutilisées.
Vous pouvez utiliser la commande Compresser ArcGIS for Desktop, 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 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.
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é.
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 Reconcile Order de l'onglet Versions dans la boîte de dialogue Geodatabase Administration. Reportez-vous à la rubrique Propriétés de la version pour plus d'informations sur le sous-onglet Reconcile Order.
- 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 voir les résultats de chaque compression dans ArcGIS for Desktop dans la table sde_compress_log. Vous pouvez également consulter la table sde_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.