You can use the Migrate Storage geoprocessing tool to migrate existing binary, spatial, or raster columns from one storage type to another. This is done by specifying a configuration keyword that contains an ATTRBUTE_BINARY, GEOMETRY_STORAGE, or RASTER_STORAGE parameter set to the new storage type to which you want to convert.
It is important to create the configuration keyword to include the correct parameter and value. If you specify a keyword with incorrect or missing information, the information is read from the DEFAULTS keyword. Esri recommends that you create a custom keyword specifically for the migration. Be sure the keyword contains the parameter and value to which you are migrating the data, as well as a UI_TEXT parameter. The UI_TEXT parameter makes the keyword available to ArcGIS clients.
The following are the supported migration paths for each database management system:
| Database management system | Configuration parameter | Migrate from/to |
|---|---|---|
Oracle | ATTRIBUTE_BINARY | Long raw to BLOB |
GEOMETRY_STORAGE | Long raw (SDEBINARY) to BLOB (SDELOB) | |
Long raw (SDEBINARY) to ST_Geometry | ||
BLOB (SDELOB) to ST_Geometry | ||
SDO_Geometry to ST_Geometry | ||
RASTER_STORAGE | Long raw to BLOB | |
Long raw to ST_Raster* | ||
BLOB to ST_Raster* | ||
PostgreSQL | RASTER_STORAGE | Bytea to ST_Raster* |
SQL Server | RASTER_STORAGE | Image to ST_Raster* |
GEOMETRY_STORAGE | SDEBINARY to Geometry | |
SDEBINARY to Geography | ||
OGCWKB to Geometry | ||
OGCWKB to Geography | ||
Geometry attributes stored in a related table to geometry attributes stored in a column in the base table |
*ST_Raster must be installed in the geodatabase. See Install ST_Raster in Oracle, Install ST_Raster in PostgreSQL, or Install ST_Raster in SQL Server for instructions.
Why migrate data?
Migrating raster data allows you to access it using structured query language (SQL).
Access data using SQL
Accessing the information in a geodatabase via SQL allows external applications (those not developed in an ArcObjects environment) to work with the tabular data managed by the geodatabase. If these applications need to access spatial or raster data in the geodatabase, you must store your spatial or raster data in data types that allow SQL access. For example, using the ST_Geometry storage type allows you to access your feature data with SQL, something that you cannot do easily if your data is stored in a BLOB or long raw field.
Migration prerequisites
The following conditions must be met before you can convert your data:
- You must make a backup of the data before you migrate it.
- If you are converting the spatial column data type, the data must be stored in high precision. If your data is currently stored with basic precision, you must first migrate it to high precision before you migrate the storage type. Use the Upgrade Spatial Reference geoprocessing tool to upgrade to high precision.
- The table or feature class must be registered with the geodatabase.
- The configuration keyword you specify when migrating the data type must contain the correct value for the GEOMETRY_STORAGE, ATTRIBUTE_BINARY, or RASTER_STORAGE parameter. For example, if you want to migrate a long raw geometry column to ST_Geometry, but you specify a keyword that has the GEOMETRY_STORAGE parameter set to SDO_GEOMETRY, the migration will fail because that is not a supported migration path.
- You must be logged in as the owner of the table that contains the column being migrated.
- Migration of a feature class to the SQL Server Geography type requires that the data be in one of the geographic coordinate systems supported by the Geography type.