Migration de données d'un type de stockage à un autre
Vous pouvez utiliser l'outil de géotraitement Migrer le stockage, les commandes d'administration ArcSDE, les objets ArcObjects ou l'API ArcSDE pour migrer des colonnes binaires, spatiales ou raster existantes d'un type de stockage à un autre. Pour cela, vous devez indiquer un mot-clé de configuration qui contient un paramètre ATTRBUTE_BINARY, GEOMETRY_STORAGE ou RASTER_STORAGE défini sur le nouveau type de stockage vers lequel vous souhaitez convertir les données.
Il est important que le mot clé soit créé correctement pour inclure le paramètre et la valeur corrects. Si vous indiquez un mot clé avec des informations inexactes ou manquantes, les informations sont lues à partir du mot-clé DEFAULTS. Pour cette raison, Esri recommande de créer un mot-clé personnalisé spécifiquement pour la migration et de s'assurer que le mot clé contient le paramètre et la valeur vers lesquelles vous effectuez la migration des données, ainsi qu'un paramètre UI_TEXT. Le paramètre UI_TEXT rend le mot clé disponible pour utilisation par les clients ArcGIS.
Astuce :Pour en savoir plus sur les mots-clés et les paramètres de configuration, consultez la rubrique Que sont les mots-clés et les paramètres de configuration DBTUNE ? et les rubriques associées.
Voici les chemins de migration pris en charge par le système de gestion de bases de données (SGBD) :
|
SGBD |
Paramètre de configuration |
Migrer depuis/vers |
|---|---|---|
|
Oracle |
ATTRIBUTE_BINARY |
LONG RAW vers BLOB |
|
GEOMETRY_STORAGE |
LONG RAW (SDEBINARY) vers BLOB (SDELOB) |
|
|
LONG RAW (SDEBINARY) vers ST_GEOMETRY |
||
|
BLOB (SDELOB) vers ST_GEOMETRY |
||
|
SDO_GEOMETRY vers ST_GEOMETRY |
||
|
RASTER_STORAGE |
LONG RAW vers BLOB |
|
|
LONG RAW vers ST_RASTER * |
||
|
BLOB vers ST_RASTER * |
||
|
PostgreSQL |
RASTER_STORAGE |
BYTEA vers ST_RASTER * |
|
SQL Server |
RASTER_STORAGE |
IMAGE vers ST_RASTER * |
GEOMETRY_STORAGE | SDEBINARY vers GEOMETRY | |
SDEBINARY vers GEOGRAPHY | ||
OGCWKB vers GEOMETRY | ||
OGCWKB vers GEOGRAPHY |
*ST_Raster doit être installé dans la géodatabase. Reportez-vous aux rubriques Installation du type ST_Raster dans Oracle, Installation du type ST_Raster dans PostgreSQL ou Installation du type ST_Raster dans SQL Server pour les instructions.
Astuce :Si la table qui fait l'objet d'une migration est inscrite comme versionnée, sa migration vers un type de stockage différent implique également la mise à jour des colonnes correspondantes de la table des ajouts. Si l'archivage est activé pour la classe d'entités, les colonnes de la table d'archive sont également mises à jour.
Pourquoi effectuer une migration de mes données ?
Vous pouvez effectuer une migration de données pour deux raisons : 1) être en mesure d'accéder à vos données spatiales ou raster à l'aide du langage SQL (Structured Query Language) ; 2) de passer d'un type de données qui ne sera peut-être pas pris en charge dans le futur à un type de données qui le sera.
Accès SQL
L'accès aux informations dans une géodatabase via SQL permet aux applications externes (celles qui ne sont pas développées dans un environnement ArcObjects) d'utiliser les données tabulaires gérées par la géodatabase. Si ces applications doivent accéder aux données spatiales ou raster dans la géodatabase, vous devez stocker vos données spatiales ou raster dans des types de données qui permettent un accès SQL. Par exemple, le type de stockage ST_Raster permet d'accéder aux données raster par SQL, ce qui n'est pas facile si les données raster sont stockées dans un champ BLOB, LONG RAW, IMAGE, BINARY ou BYTEA.
Abandonner des types qui peuvent ne plus être pris en charge dans les versions futures
Oracle recommande l'utilisation des types de données BLOB ou BFILE au lieu des types de données LONG RAW dans ses bases de données. Même si les colonnes LONG RAW sont encore prises en charge, si vous avez des champs attribut, géométrie ou raster LONG RAW dans votre géodatabase ArcSDE actuelle dans Oracle, il est conseillé de migrer ces champs vers un format différent en préparation du moment où ils ne seront plus pris en charge.
Le stockage des colonnes attribut, géométrie et raster dans une géodatabase est contrôlé par les paramètres DBTUNE ATTRIBUTE_BINARY, GEOMETRY_STORAGE et RASTER_STORAGE. Les valeurs par défaut de ces paramètres sous le mot-clé de configuration DBTUNE DEFAULTS sont différentes selon la version d'ArcGIS que vous avez utilisée lors de la création de la géodatabase. Le tableau suivant présente le paramètre par défaut du mot-clé DEFAULTS de la table DBTUNE pour les géodatabases ArcSDE dans Oracle.
|
Paramètre |
Valeur par défaut pour la version 9.3 d'ArcGIS et les versions ultérieures |
Valeur par défaut pour la version 9.2 d'ArcGIS |
Valeur par défaut avant la version 9.2 d'ArcGIS |
|---|---|---|---|
|
ATTRIBUTE_BINARY |
BLOB |
BLOB |
LONG RAW |
|
GEOMETRY_STORAGE |
ST_GEOMETRY |
LONG RAW (SDEBINARY) |
LONG RAW (SDEBINARY) |
|
RASTER_STORAGE |
BLOB |
LONG RAW |
LONG RAW |
Remarque :Les données créées dans les nouvelles géodatabases (non mises à niveau) version 9.3 ou ultérieures avec les paramètres par défaut n'utilisent pas le type de stockage LONG RAW. Toutefois, toutes les données existantes créées avec un ou plusieurs paramètres définis sur LONG RAW, ou toutes nouvelles données dans les géodatabases mises à niveau ayant ces paramètres définis sur LONG RAW contiennent encore des colonnes de type LONG RAW. Pour changer les types de données de ces colonnes, modifiez vos paramètres DBTUNE et migrez les données.
Pour modifier les paramètres DBTUNE, utilisez la commande sdedbtune pour ajouter un paramètre à un mot clé existant ou pour exporter, modifier, puis importer le contenu de la table DBTUNE. Consultez le manuel ArcSDE Administration Command Reference pour plus d'informations sur l'utilisation de la commande sdedbtune.
Avant d'effectuer une migration...
Les conditions suivantes doivent être vérifiées avant la conversion de vos données :
- Vous devez effectuer une sauvegarde des données avant d'effectuer leur migration.
- Si vous effectuez une conversion du type de colonne spatiale, les données doivent être stockées en haute précision. Si vos données sont actuellement stockées en précision de base, vous devez tout d'abord effectuer une migration vers la haute précision avant de migrer le type de stockage. Pour cela, vous pouvez utiliser soit l'outil de géotraitement Mettre à jour la référence spatiale, soit la commande sdelayer avec l'opération alter. Reportez-vous à la rubrique Migration vers la haute précision pour plus d'informations sur la migration de la précision d'un jeu de données.
- Si vous effectuez une conversion de la colonne spatiale, elle doit contenir une colonne d'identifiant d'objet. L'enregistrement d'une couche avec la géodatabase ajoute automatiquement cette colonne, ou vous pouvez utiliser la commande sdetable avec l'opération alter_reg pour l'ajouter.
- Le mot-clé de configuration spécifié lors de la migration du type de données doit contenir la valeur correcte pour les paramètres GEOMETRY_STORAGE, ATTRIBUTE_BINARY et RASTER_STORAGE. Par exemple, si vous voulez effectuer la migration d'une colonne de géométrie depuis le type LONG RAW vers le type ST_GEOMETRY, mais vous spécifiez un mot-clé ayant le paramètre GEOMETRY_STORAGE défini sur SDO_GEOMETRY, la migration échoue parce qu'il ne s'agit pas d'un chemin de migration pris en charge.
- Lorsque des données sont migrées d'un type de données vers un autre, un nouveau segment est créé dans la base de données de destination des données copiées. Une fois que la migration est terminée, les métadonnées sont redirigées vers le nouveau segment et l'ancien est supprimé. De ce fait, il existe deux copies des données pendant la migration ; par conséquent, assurez-vous que vous disposez de suffisamment d'espace dans la base de données pour ces deux copies des données.
- Comme le stockage d'attributs, de rasters et de géométries peut faire l'objet d'une migration vers un type de données BLOB dans Oracle, il est recommandé de lire la rubrique Stockage de données BLOB dans les géodatabases Oracle avant d'effectuer la migration.
- Vous devez être connecté en tant que propriétaire de la table contenant la colonne à migrer.
- Pour effectuer la migration d'une classe d'entités vers le type SQL Server GEOGRAPHY, les données doivent être dans l'un des systèmes de coordonnées géographiques pris en charge par le type GEOGRAPHY et la classe d'entités ne doit pas contenir de valeurs de coordonnées z ou m.Astuce :
La liste de systèmes de coordonnées pris en charge qui peuvent être utilisés avec le type SQL Server GEOGRAPHY se trouve dans la vue système SQL Server sys.spatial_reference_systems.
Outils pour la migration
Consultez les rubriques suivantes pour plus d'informations sur la migration de données :