Migration de données d'un type de stockage à un autre

Vous pouvez utiliser l'outil de géotraitement Migrer le stockage pour effectuer la migration des éléments binaires ou spatiaux ou des colonnes raster d'un type de stockage à un autre. Pour cela, vous devez indiquer un mot-clé de configuration qui contient un paramètre ATTRIBUTE_BINARY, GEOMETRY_STORAGE ou RASTER_STORAGE défini sur le nouveau type de stockage vers lequel vous souhaitez convertir les données.

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.

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. Esri recommande de créer un mot clé personnalisé spécifiquement pour la migration. Assurez-vous que le mot clé contienne le paramètre et la valeur vers lesquels vous migrez les données, ainsi que le paramètre UI_TEXT. Le paramètre UI_TEXT rend le mot clé disponible pour les clients ArcGIS.

Utilisez la commande sdedbtune pour ajouter un mot-clé ou pour modifier les paramètres de mot-clé et de paramètre existants. Les outils de commande d'administration ArcSDE et leur documentation peuvent être installés avec le serveur d'applications ArcSDE.

Voici les chemins de migration pris en charge pour chaque 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 ?

Deux raisons peuvent vous pousser à migrer vos données :

• Pour accéder à vos données spatiales ou raster à l'aide de SQL (Structured Query Language)
• Pour passer d'un type de données qui peut ne plus être pris en charge à l'avenir à un type pris en charge

Accès aux données à l'aide de 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.

Migrer de 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 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 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

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.

Depuis ArcGIS 10.1, les classes d'entités créées dans les géodatabases, sur SQL Server, utilisent le type de géométrie Microsoft par défaut. Pour déplacer vos classes d'entités existantes vers le type de stockage de géométries, utilisez l'outil de géotraitement Migrer le stockage ou un script Python.

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 données 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 ObjectID. L'opération d’enregistrement d'une couche avec la géodatabase ajoute automatiquement cette colonne.
• 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.
• 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.
  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.

• Si votre géodatabase est dans SQL Server 2008 ou 2008 R2, les classes d'entités migrées vers le type SQL Server GEOGRAPHY ne peuvent pas contenir de valeurs de coordonnées z ou m.