15
Migration Procedures

SDO_MIGRATE.FROM_815_TO_81X

Format

SDO_MIGRATE.FROM_815_TO_81X(

     tabname IN VARCHAR2

     [, commit_int IN NUMBER]);

Description

Migrates data from Spatial release 8.1.5 to the current release.

Parameters

tabname

Table with geometry objects.

commit_int

Number of geometries to migrate before Spatial performs an internal commit operation. If commit_int is not specified, no internal commit operations are performed during the migration.

If you specify a commit_int value, you can use a smaller rollback segment than would otherwise be needed.

Usage Notes

See Section A.3 for important information about migrating from Spatial release 8.1.5.

All geometry objects in tabname will be migrated so that their SDO_GTYPE and SDO_ETYPE values are in the format of the current release:

• SDO_GTYPE values of 4 digits are created, using the format (d00n) shown in Table 2-1 in Section 2.2.1.

• SDO_ETYPE values are as discussed in Section 2.2.4.

The procedure also orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counterclockwise for exterior rings, and clockwise for interior rings).

Examples

The following example changes the definitions of geometry objects in the ROADS table from the release 8.1.5 format to the format of the current release.

SQL> execute sdo_migrate.from_815_to_81x('ROADS');

SDO_MIGRATE.OGIS_METADATA_FROM

Format

SDO_MIGRATE.OGIS_METADATA_FROM

Description

Called at the source database when migrating from one 8.1.5 database to another 8.1.5 database. The procedure migrates OGIS (OpenGIS) metadata entries from schemas owned by MDSYS.

Parameters

None.

Usage Notes

Consider the following when using this procedure:

• The tables involved are strictly maintained by the user, and not by Spatial. Details are available in the sdocat.sql file and the OpenGIS specification.

• Call this procedure once before migrating the data, and it will generate a temporary table called SDO_GC_MIG. Export the temporary table to the new database and call SDO_MIGRATE.OGIS_METADATA_TO to restore the data.

SDO_MIGRATE.OGIS_METADATA_TO

Format

SDO_MIGRATE.OGIS_METADATA_TO

Description

Used at the destination database when migrating from one 8.1.5 database to another 8.1.5 database. The procedure migrates OGIS (OpenGIS) metadata entries from schemas owned by MDSYS.

Parameters

None.

Usage Notes

Consider the following when using this procedure:

• The tables involved are strictly maintained by the user, and not by Spatial. Details are available in the sdocat.sql file and the OpenGIS specification.

• Call this procedure once after migrating the data. See SDO_MIGRATE.OGIS_METADATA_FROM.

SDO_MIGRATE.TO_734

Format

SDO_MIGRATE.TO_734(

     sn IN VARCHAR2,

     layer IN VARCHAR2,

     tess_type IN VARCHAR2,

     param IN INTEGER);

Description

Migrates data from a previous release of Spatial Data Option to release 7.3.4.

Parameters

sn

Schema name of the owner of layer.

layer

Name of the layer to be migrated.

tess_type

Type of tessellation (indexing) to be used: FIXED or VARIABLE.

param

Parameter whose significance depends on tess_type:

• If tess_type is FIXED, param is the SDO_LEVEL value.

• If tess_type is VARIABLE, param is the SDO_NUMTILES value.

Usage Notes

None.

Examples

For fixed-size tessellation:

SQL> execute sdo_migrate.to_734('HERMAN', 'ROADS', 'FIXED', 10);

For variable-sized tessellation:

SQL> execute sdo_migrate_to_734('HERMAN', 'ROADS', 'VARIABLE',4);

SDO_MIGRATE.TO_81X

Format

SDO_MIGRATE.TO_81X(

     layer IN VARCHAR2,

     newtabname IN VARCHAR2,

     gidcolumn IN VARCHAR2,

     geocolname IN VARCHAR2,

     layer_gtype IN VARCHAR2,

     updateflag IN VARCHAR2);

Description

Migrates data from a previous release of Spatial Cartridge or Spatial Data Option to the current release of Oracle Spatial.

Parameters

layer

Name of the layer to be migrated.

newtabname

Name of the new table to which you are migrating the data.

gidcolumn

Name of the column in which to store the GID from the old table.

geocolname

Name of the column in the new table where the geometry objects will be inserted.

layer_gtype

One of the following values: POINT or NOTPOINT (default).

If the layer you are migrating is composed solely of point data, set this parameter to POINT for optimal performance; otherwise, set this parameter to NOTPOINT. If you set the value to POINT and the layer contains any nonpoint geometries, the migration might produce invalid data.

updateflag

One of the following values: UPDATE or INSERT (default).

If you are migrating the layer into an existing populated attribute table, set this parameter to UPDATE; otherwise, set this parameter to INSERT.

Usage Notes

Consider the following when using this procedure:

• The new table must be created before calling this procedure.

• The procedure converts geometries from the relational model to the object-relational model.

• A commit operation is performed by this procedure.

• If any of the migration steps fails, nothing is migrated for the layer.

• layer is the underlying layer name, without the _SDOGEOM suffix.

• The old SDO_GID is stored in gidcolumn.

• SDO_GTYPE values of 4 digits are created, using the format (d00n) shown in Table 2-1 in Section 2.2.1.

• SDO_ETYPE values are created, using the values discussed in Section 2.2.4.

• The procedure orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counter clockwise for exterior rings, and clockwise for interior rings).

Examples

Insert point-only data into new rows:

execute sdo_migrate.to_81x('raptor', 'raptor', 'sdo_gid', 'feature', 'point'); 

Insert nonpoint data into new rows:

execute sdo_migrate.to_81x('BTU', 'BTU', 'sdo_gid', 'feature'); 

Update point-only data in existing rows:

execute sdo_migrate.to_81x('raptor', 'raptor', 'sdo_gid', 'feature',

  'point', 'update');

Update nonpoint data in existing rows:

execute sdo_migrate.to_81x('BTU', 'BTU', 'sdo_gid', 'feature',

  'notpoint', 'update');

SDO_MIGRATE.TO_CURRENT

Format (Any Object-Relational Model Implementation to Current)

SDO_MIGRATE.TO_CURRENT(

     tabname IN VARCHAR2

     [, column_name IN VARCHAR2]);

or

SDO_MIGRATE.TO_CURRENT(

     tabname IN VARCHAR2,

     column_name IN VARCHAR2

     [, commit_int IN NUMBER]);

Format (Any Relational Model Implementation to Current)

SDO_MIGRATE.TO_CURRENT(

     layer IN VARCHAR2,

     newtabname IN VARCHAR2,

     gidcolumn IN VARCHAR2,

     geocolname IN VARCHAR2,

     layer_gtype IN VARCHAR2,

     updateflag IN VARCHAR2);

Description

Migrates data from a previous Spatial release to the current release. The format depends on whether you are migrating from the Spatial relational model (release 8.1.5 or lower) or object-relational model (release 8.1.6 or higher). See the Usage Notes for the model that applies to you.

You are encouraged to use this procedure instead of the SDO_MIGRATE.FROM_815_TO_81X or SDO_MIGRATE.TO_81X procedure.

Parameters

tabname

Table with geometry objects.

column_name

Column in tabname that contains geometry objects. If column_name is not specified or is specified as null, the column containing geometry objects is migrated.

commit_int

Number of geometries to migrate before Spatial performs an internal commit operation. If commit_int is not specified, no internal commit operations are performed during the migration.

If you specify a commit_int value, you can use a smaller rollback segment than would otherwise be needed.

layer

Name of the layer to be migrated.

newtabname

Name of the new table to which you are migrating the data.

gidcolumn

Name of the column in which to store the GID from the old table.

geocolname

Name of the column in the new table where the geometry objects will be inserted.

layer_gtype

One of the following values: POINT or NOTPOINT (default).

If the layer you are migrating is composed solely of point data, set this parameter to POINT for optimal performance; otherwise, set this parameter to NOTPOINT. If you set the value to POINT and the layer contains any nonpoint geometries, the migration might produce invalid data.

updateflag

One of the following values: UPDATE or INSERT (default).

If you are migrating the layer into an existing populated attribute table, set this parameter to UPDATE; otherwise, set this parameter to INSERT.

Usage Notes for Object-Relational Model Migration

See Section A.3 for important information about upgrading from Spatial release 8.1.5.

All geometry objects in tabname will be migrated so that their SDO_GTYPE and SDO_ETYPE values are in the format of the current release:

• SDO_GTYPE values of 4 digits are created, using the format (d00n) shown in Table 2-1 in Section 2.2.1.

• SDO_ETYPE values are as discussed in Section 2.2.4.

The procedure also orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counter clockwise for exterior rings, and clockwise for interior rings).

Usage Notes for Relational Model Migration

Consider the following when using this procedure:

• The new table must be created before calling this procedure.

• The procedure converts geometries from the relational model to the object-relational model.

• A commit operation is performed by this procedure.

• If any of the migration steps fails, nothing is migrated for the layer.

• layer is the underlying layer name, without the _SDOGEOM suffix.

• The old SDO_GID is stored in gidcolumn.

• SDO_GTYPE values of 4 digits are created, using the format (d00n) shown in Table 2-1 in Section 2.2.1.

• SDO_ETYPE values are created, using the values discussed in Section 2.2.4.

• The procedure orders geometries so that exterior rings are followed by their interior rings, and saves them in the correct rotation (counter clockwise for exterior rings, and clockwise for interior rings).

Examples

The following example changes the definitions of geometry objects in the ROADS table from the release 8.1.5 or higher format to the format of the current release.

SQL> execute sdo_migrate.to_current('ROADS');