ArcGIS Server Java Help - 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.

Conseil :

Pour comprendre la compression, vous devez d'abord comprendre comment le versionnement fonctionne. Si vous ne connaissez pas ce concept, reportez-vous à la rubrique Maîtrise 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 ArcSDE 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 ArcSDE 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'ArcCatalog ou le script Python pour compresser une géodatabase. Reportez-vous à la rubrique Ajout de la commande Compresser dans ArcCatalog pour savoir comment rendre la commande Compresser disponible dans ArcCatalog 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 delta dans les tables 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, ou interrompue, 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é.

Il peut arriver que les opérations de compression soient de grande ampleur. Par conséquent, pour les bases de données Oracle configurées pour l'annulation automatique de la gestion de l'espace, assurez-vous que la valeur du paramètre UNDO_POOL de l'administrateur ArcSDE n'est pas trop basse et que le tablespace est assez grand pour terminer l'opération de compression.

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.
Supprimez les versions.
Assurez-vous qu'aucun utilisateur n'est connecté.*
Lancez l'opération de compression.

*Les services ArcIMS (à l'exception des services de carte ArcIMS) n'acquérant pas de verrous sur les états, leur impact est nul sur l'opération de compression. En revanche, les clients ArcGIS, y compris les services de carte ArcIMS, acquièrent des verrous et ont un impact sur 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 bases de données SQL Server et PostgreSQL). Vous pouvez aussi consulter la table VERSIONS (SDE_versions dans les bases de données 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.

Reportez-vous à la rubrique Compression d'une géodatabase ArcSDE sous licence ArcGIS Server Enterprise pour savoir comment effectuer une opération de compression.

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. Pour plus d'informations sur la mise à jour de statistiques, reportez-vous à la rubrique Mise à jour des statistiques d'une géodatabase à l'aide de la commande Analyser et à la rubrique consacrée à votre système de gestion de bases de données (SGBD).

3/6/2012