A Installation, Migration, Compatibility, and Upgrade

This appendix provides information about installation, migration, compatibility, and upgrade relating to Oracle Spatial and Graph.

If you are upgrading to the current Oracle Database release, Oracle Spatial and Graph is automatically upgraded as part of the operation. For information about the upgrade procedure, see Oracle Database Upgrade Guide.

If you need to downgrade Spatial and Graph to the previous Oracle Database release, follow the instructions for downgrading a database back to the previous Oracle Database release in Oracle Database Upgrade Guide.

If you need to migrate spatial data from one database to another, see Migrating Spatial Data from One Database to Another.

If you use Oracle Spatial and Graph GeoRaster, see Ensuring That GeoRaster Works Properly After an Installation or Upgrade.

If you are using Spatial and Graph Web Feature Service (WFS) or Catalog Services for the Web (CSW) support, and if you have data from a previous release that was indexed using one or more SYS.XMLTABLEINDEX indexes, see Index Maintenance Before and After an Upgrade (WFS and CSW).

If you need to support geometries with more than 1,048,576 ordinates, see Increasing the Size of Ordinate Arrays to Support Very Large Geometries.

Topics:

A.1 Migrating Spatial Data from One Database to Another

Migrating spatial data refers to moving or copying Oracle Spatial and Graph geometry objects from one Oracle database to another. (The databases can have the same or different Oracle Database release numbers.)

If you are migrating spatial data using database links, export/import, Oracle Data Pump, or transportable tablespaces, the MDSYS schema must already exist in the destination database.

In limited situations you might also need to use the SDO_MIGRATE.TO_CURRENT subprogram (described in SDO_MIGRATE Package (Upgrading) ). See the Usage Notes for that subprogram.

A.2 Ensuring That GeoRaster Works Properly After an Installation or Upgrade

To use the GeoRaster feature of Oracle Spatial and Graph, you must enable it and ensure that Oracle XML DB Repository is properly installed.

Topics:

A.2.1 Enabling GeoRaster

By default the GeoRaster feature is disabled after the Oracle Spatial and Graph is initially installed. To enable GeoRaster, follow these steps:

  1. Connect to the database as SYS AS SYSDBA.
  2. Enter the following statement:
    EXECUTE MDSYS.enableGeoRaster;
    

After GeoRaster is enabled, if you later upgrade the database, you do not need to re-enable GeoRaster.

A.2.2 Ensuring Oracle XML DB Repository is Installed

For more information, see the installation and upgrade notes near the start of Chapter 1 in Oracle Spatial and Graph GeoRaster Developer's Guide.

To use the GeoRaster feature of Oracle Spatial and Graph, Oracle XML DB Repository must be installed properly. (In general, you should ensure that Oracle XML DB Repository is installed before you install Oracle Spatial and Graph.)

If Oracle Spatial and Graph has been installed (such as during an upgrade) but Oracle XML DB Repository is not installed, you need to install the Oracle XML DB Repository and reload related GeoRaster PL/SQL packages. In this case, follow these steps

  1. Install Oracle XML DB Repository.

    For information about installing Oracle XML DB Repository, see Oracle XML DB Developer's Guide.

  2. Go to the $ORACLE_HOME/md/admin directory.

  3. Connect to the database as SYS AS SYSDBA.

  4. Enter the following SQL statements:

    ALTER SESSION SET CURRENT_SCHEMA=MDSYS;
    @prvtgrs.plb
    @sdogrxml.sql

A.2.3 Checking if the SDO_GEORASTER Type Needs to be Altered After an Upgrade

If you upgrade Spatial and Graph to Release 12.2, you might need to alter the SDO_GEORASTER type if any user tablespaces containing SDO_GEORASTER objects were read-only during the upgrade.

During the upgrade, the SDO_GEORASTER type is automatically altered (to permit longer RDT names) as part of the upgrade unless any user tablespaces containing SDO_GEORASTER objects are read-only; and in that case, the type is not altered, and you must take steps to alter it.

You can check whether the SDO_GEORASTER type needs to be altered by entering the following SQL statement and checking the RASTERDATATABLE length is 128 or 32:

SQL> DESCRIBE sdo_georaster
 Name                            Null?    Type
 ------------------------------- -------- ----------------------------
 RASTERTYPE                               NUMBER
 SPATIALEXTENT                            MDSYS.SDO_GEOMETRY
 RASTERDATATABLE                          VARCHAR2(128)
 RASTERID                                 NUMBER
 METADATA                                 XMLTYPE
  • If the RASTERDATATABLE column type is VARCHAR2(128), then the SDO_GEORASTER type was successfully altered, and you do not need to alter it.

  • If the RASTERDATATABLE column type is VARCHAR2(32), then the SDO_GEORASTER type was not successfully altered, and you must alter it by following the instructions in the rest of this topic.

If you need to alter the SDO_GEORASTER type, follow these steps.

  1. Enter the following statements to find a list of read-only tablespaces that contain SDO_GEORASTER objects:

    SQL> connect / as sysdba
    Connected.
    SQL> select distinct TABLESPACE_NAME from dba_tables a, mdsys.sdo_geor_sysdata_table b where a.owner=b.SDO_OWNER and a.TABLE_NAME=b.GEORASTER_TABLE_NAME;
    
    TABLESPACE_NAME
    ------------------------------
    TBS_3
    
  2. For each read-only tablespace found in the preceding step, manually change it to read/write. For example (and do similarly for each tablespace):

    SQL> alter tablespace tbs_3 read write;
    
  3. Alter the SDO_GEORASTER type by entering the following statements::

    SQL> connect / as sysdba
    
    Connected.
    
    SQL> alter session set current_schema=MDSYS;
    
    Session altered.
    
    SQL> alter type SDO_GEORASTER modify attribute ( rasterDataTable VARCHAR2(128) ) cascade including table data;
    
    Type altered.
  4. For each tablespace that you changed to read/write in step 2, change it back to read-only. For example (and do similarly for each tablespace):

    SQL> alter tablespace tbs_3 read only;
    

A.3 Index Maintenance Before and After an Upgrade (WFS and CSW)

Effective with Release 11.2, the SYS.XMLTABLEINDEX index type is deprecated, and therefore the Spatial WFS and CSW createXMLTableIndex methods create indexes of type XDB.XMLINDEX instead of type SYS.XMLTABLEINDEX as in previous releases. However, if you have data from a previous release that was indexed using one or more SYS.XMLTABLEINDEX indexes, you must drop the associated indexes before the upgrade and re-create the indexes after the upgrade, as follows:

  1. Using Oracle Database Release 11.1, call the dropXMLTableIndex method (in oracle.spatial.csw.CSWAdmin or oracle.spatial.wfs.WFSAdmin, as appropriate depending on the application) to drop associated indexes.

  2. Upgrade the database from Release 11.1 to Release 11.2.

  3. Using Oracle Database Release 11.2, call the createXMLTableIndex (in oracle.spatial.csw.CSWAdmin or oracle.spatial.wfs.WFSAdmin, as appropriate depending on the application) to create indexes that were dropped in step 1.

For information about Spatial and Graph Web Feature Service (WFS) support, see Web Feature Service (WFS) Support.

For information about Spatial and Graph Catalog Services for the Web (CSW) support, see Catalog Services for the Web (CSW) Support.

A.4 Increasing the Size of Ordinate Arrays to Support Very Large Geometries

If you need to support geometries with more than 1,048,576 ordinates, you must follow the instructions in this section. However, doing so involves significant extra work (running a script, migrating existing spatial data), some database downtime , and some considerations and restrictions. Therefore, you should not perform the actions in this section unless you need to.

To increase the size of ordinate arrays to support geometries with up to 10M ordinates, follow these steps:

  1. Ensure that no users are using any spatial tables or Oracle Spatial and Graph or Locator features.
  2. Connect to the database as the SYS user with SYSDBA privileges (SYS AS SYSDBA, and enter the SYS account password when prompted).
  3. Enter the following statement:
    • Linux: @$ORACLE_HOME/md/admin/sdoupggeom.sql

    • Windows: @%ORACLE_HOME%\md\admin\sdoupggeom.sql

    One of the actions of the sdoupggeom.sql script is to automatically migrate all spatial data to accommodate the new SDO_ORDINATE_ARRAY definition. This script may take a long time to complete, and the amount of time will depend on the amount of spatial data that exists in the database.

After you perform these steps, the following considerations and restrictions apply:

  • Any existing transportable tablespaces that were created with the old SDO_ORDINATE_ARRAY definition will not work.

  • If an export file was created using the Original Export utility on a database with the old SDO_ORDINATE_ARRAY definition, and if that file needs to be imported into a database that is using the new SDO_ORDINATE_ARRAY definition, you must specify the TOID_NOVALIDATE flag with the Original Import utility, as in the following example:

    imp scott/<password> file=states.dmp tables=states TOID_NOVALIDATE=MDSYS.SDO_GEOMETRY,MDSYS.SDO_ORDINATE_ARRAY,MDSYS.SDO_ELEM_INFO_ARRAY
    
  • If you plan to use Oracle Data Pump to import data after sdoupggeom.sql has been executed on a source database, you must also run sdoupggeom.sql on the target (destination) database after the import operation.