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 ATTRIBUTE_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. 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 geodatabases in Oracle:
| Configuration parameter | Migrate from/to |
|---|---|
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 |
Tip:
If the table being migrated is registered to participate in traditional versioning, migrating it to a different storage type also updates the corresponding columns in the Adds table. If the feature class has archiving enabled, the archive table's columns are also updated.
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
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
Oracle recommends using the BLOB or BFILE data type instead of long raw data types in its databases. Although long raw columns are still supported, if you have long raw attribute, geometry, or raster fields in your current geodatabase in Oracle, you should migrate them to a different format in preparation for when they are not supported.
The storage for the attribute, geometry, and raster columns in a geodatabase is controlled by the configuration parameters ATTRIBUTE_BINARY, GEOMETRY_STORAGE, and RASTER_STORAGE, respectively. If you created your geodatabase in Oracle at ArcGIS 9.2 or earlier, these parameters may be set to use long raw data types, as they were the default types at the time.
If your geodatabase in Oracle was created at ArcGIS 9.3 or later (and not upgraded from ArcGIS 9.2 or earlier), the data you create will not use the long raw storage type. However, any existing data created with any or all of these parameters set to LONG RAW, or any data in upgraded geodatabases that have these parameters set to LONG RAW, will still contain long raw columns. To change the data types for these columns, you must alter your configuration keyword settings and migrate the data.
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.
- 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 being migrated.