You can use the Migrate Storage geoprocessing tool to migrate existing binary spatial columns from one storage type to another. This is done by specifying a configuration keyword that contains a GEOMETRY_STORAGE parameter set to the new storage type to which you want to convert. You can also use the Migrate Storage geoprocessing tool to change the storage format of geometry attributes for parametric objects and surface patches in geodatabases in Microsoft SQL Server.
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. Provide this keyword to the dataset owners, as they are the ones who must run the Migrate Storage tool.
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 | |
SQL Server | GEOMETRY_STORAGE | SDEBINARY to Geometry |
SDEBINARY to Geography | ||
OGCWKB to Geometry | ||
OGCWKB to Geography | ||
Geometry attributes stored in a related system table to geometry attributes stored in a column in the base table |
Why migrate data?
The following are reasons to migrate your data:
- To access your spatial or raster data using structured query language (SQL)
- To move from a data type that may not be supported in the future to one that is supported
- To move geometry attribute information from a side table in SQL Server to a column in the base table to improve performance in parcel fabrics and to allow you to register the feature class for branch versioning
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.
Move from types that may not be supported in future releases
Feature classes created at ArcGIS 10.1 and later geodatabases in SQL Server use the Microsoft Geometry type by default. To move your existing feature classes to the Geometry storage type, use the Migrate Storage geoprocessing tool or a Python script.
Move geometry attributes to improve performance
Beginning with ArcGIS 10.5, storage of geometry attributes for parametric objects (such as true curves) and for surface patches (such as pointIDs and multipatches) has improved: they are stored directly in the business table. In earlier releases, this attribute data was stored in a related table that was joined with the business table. This join could cause poor performance and was often noticed while working with parcel fabrics.
If your existing feature classes participate in parcel fabrics or store true curves, multipatches, or pointIDs, and you find the display performance to be poor, consider migrating storage for these geometry attributes. Supported migration paths for existing feature classes are as follows:
- Storage type is Microsoft Geometry and you want to continue using the Geometry type.
To migrate the geometry attributes from the related table to a new column in the feature class's business table, specify a configuration keyword that has the GEOMETRY_STORAGE parameter set to Geometry, and run the Migrate Storage tool.
- Storage type is Microsoft Geography and you want to continue using the Geography type.
To migrate the geometry attributes from the related table to a new column in the feature class's business table, specify a configuration keyword that has the GEOMETRY_STORAGE parameter set to Geography, and run the Migrate Storage tool.
- Storage type is SDEBINARY and you want to migrate to the Microsoft Geometry type. In this case, specify a configuration keyword that has the GEOMETRY_STORAGE parameter set to Geometry, and run the Migrate Storage tool. This migrates both the spatial data type and geometry attributes to the new storage format.
In this case, specify a configuration keyword that has the GEOMETRY_STORAGE parameter set to Geography, and run the Migrate Storage tool. This migrates the geometry attributes to the new storage format.
- Storage type is SDEBINARY and you want to migrate to the Geography type.
In this case, specify a configuration keyword that has the GEOMETRY_STORAGE parameter set to Geography, and run the Migrate Storage tool. This migrates both the spatial data type and geometry attributes to the new storage format.
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 parameter. For example, if you want to migrate an sdebinary geometry column to Geometry, but you specify a keyword that has the GEOMETRY_STORAGE parameter set to OGCWKB, the migration will fail because that is not a supported migration path.
- You must be logged in as the owner of the table 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.