Oracle8i Spatial User's Guide and Reference Release 8.1.5 A67295-01 |
|
Spatial has undergone an architectural change, beginning with the 7.3.3 release. The emphasis on partitioned tables has been replaced by the improved spatial indexing features.
Spatial provides the essential functions, procedures, and scripts for using and managing both spatially indexed data and partitioned point data. The information in this appendix is relevant only to users who have not yet migrated to the new data model. For all other users, spatial indexing is preferred and recommended.
Partitioning is a technique where data is loaded into tables that automatically subdivide when a predefined maximum size is reached. During subdivision, data is moved from the parent partition to the child partitions and the parent partition is deleted. Storage parameters for child partitions are inherited from the root partition and can be changed at any time.
A partitioned table has a partition key that is an HHCODE column created by encoding multidimensional point data using the SDO_ENCODE() function. In the partitioning process, at each subdivision, data is subdivided into 2n partitions where n is the number of dimensions encoded in the HHCODE column. You can encode up to 32 dimensions using Spatial.
This guide does not attempt to provide the information necessary for fully utilizing table partitioning for point data. Existing users who need to use this method should continue to use their Spatial Data Option 7.3.2 documentation. The following is a high-level description of the partitioning process:
An HHCODE column is a new data type used to encode multiple dimensions into a unique orderable value. HHCODE is not a point, but rather a bounded cell representing an object space in as many dimensions as have been defined. An HHCODE data type is defined as RAW(255).
This section describes the following scripts:
Although the scripts described in this section are available, the recommended approach is to use Oracle8i partitioning and spatial indexing.
The altpart.sql script file shows how to use dynamic SQL in a PL/SQL procedure to modify all partitions of a Spatial partitioned table.
The Spatial data dictionary view used in this SQL script requires that a registered Spatial partitioned table is specified. If the table is not registered, you can use the USER_TABLES view to select all the partitioned tables from the user's schema. To use the USER_TABLES view, enter the following syntax:
SQL> SELECT TABLENAME FROM user_tables WHERE TABLENAME LIKE
2> '%tablename_P%';
The drppart.sql script file shows how to use dynamic SQL in a PL/SQL procedure to drop (remove) all partitions of a Spatial partitioned table. After running this procedure, you must run the SDO_ADMIN.DROP_PARTITION_INFO()
procedure.
The Spatial data dictionary view used in this SQL script requires that a registered Spatial partitioned table is specified. If the table is not registered, you can use the USER_TABLES view to select all the partitioned tables from the user's schema. To use the USER_TABLES view, use the following syntax:
SQL> SELECT TABLENAME FROM user_tables WHERE TABLENAME LIKE
2> '%tablename_P%';
The sdogrant.sql script file contains an administrative procedure, PROPAGATE_GRANTS(), which is used after calling the SDO_ADMIN.PARTITION() or SDO_ADMIN.REPARTITION() procedures.
This procedure must first be compiled by running the sdogrant.sql file. The PROPAGATE_GRANTS() procedure is callable only by the user who compiled it.
Table C-1 lists the procedures that can be used with partitioned point data. These procedures are neither required nor compatible with the geometry-based data format.
This procedure alters the high-water mark of a partitioned spatial table. The high-water mark defines how many records can be stored in a partition before it subdivides. The table must exist and be registered in the Spatial data dictionary.
This procedure is for use only with partitioned point data.
SDO_ADMIN.ALTER_HIGH_WATER_MARK (tablename, high_water_mark)
tablename |
Specifies the name of the partitioned table. |
high_water_mark |
Specifies the new high-water mark for the table. |
None.
The following example changes the high-water mark to 5000 records for the table1 partitioned spatial table:
SQL> EXECUTE SDO_ADMIN.ALTER_HIGH_WATER_MARK('table1', 5000);
This procedure removes a partitioned spatial table from the Spatial data dictionary. The table must exist and must be registered in the Spatial data dictionary.
This procedure is used only with partitioned point data.
SDO_ADMIN.DROP_PARTITION_INFO (tablename)
tablename |
Specifies the name of the partitioned table. |
This procedure does not remove the spatial table and its associated partition tables from the user's schema. For a description of how to remove a partitioned spatial table from the user's schema, see the drppart.sql sample SQL script file described in Section C.3.2.
The following example removes the table1 table from the Spatial data dictionary:
SQL> EXECUTE SDO_ADMIN.DROP_PARTITION_INFO('table1');
This procedure places data into partitioned tables based on the sorted order of encoded dimensional values.
This procedure is used only with partitioned point data.
SDO_ADMIN.PARTITION (owner.source_table, tablename, parallel, guess, plummet_flag [,tablespace] )
Consider the following when using this procedure:
The following example partitions the table1 partitioned spatial table with data contained in the source1 table:
SQL> EXECUTE SDO_ADMIN.PARTITION('source1','table1',1,10,FALSE);
This procedure is used to propagate the grants on the underlying table to the partitions.
This procedure is used only with partitioned point data.
SDO_ADMIN.PROPAGATE_GRANTS (tablename)
tablename |
Specifies the name of the partitioned table. |
This procedure is used after calls to SDO_ADMIN.PARTITION() or SDO_ADMIN.REPARTITION(). It must be called by the owner of the partition.
This procedure must be compiled prior to use. See Section C.3.3.
The following example propagates grants from the TABLE1 partitioned spatial table:
SQL> EXECUTE SDO_ADMIN.PROPAGATE_GRANTS('TABLE1');
This procedure creates a partitioned spatial table entry in the Spatial data dictionary, and defines the partition key column and the high-water mark for the table.
This procedure is used only with partitioned point data.
SDO_ADMIN.REGISTER_PARTITION_INFO (tablename, column, high_water_mark)
The SQL CREATE TABLE statement is used to create the partitioned spatial table, with the partition key column defined as RAW(255), prior to calling this procedure.
The following example registers the TABLE1 partitioned spatial table:
SQL> EXECUTE SDO_ADMIN.REGISTER_PARTITION_INFO('table1',
2> 'hhcolumn', 1000);
This procedure reorganizes a partitioned spatial table based on the sorted order of encoded dimensional values already contained in it. The table must exist and must be registered in the Spatial data dictionary.
This procedure is used only with partitioned point data.
SDO_ADMIN.REPARTITION (tablename, parallel, [tablespace])
Consider the following when using this procedure:
The following example repartitions the table1 partitioned spatial table:
SQL> EXECUTE SDO_ADMIN.REPARTITION('table1', 1);
This procedure checks if the partitioned spatial table exists, if it is registered in the Spatial data dictionary, and if the partition key column exists as defined in the Spatial data dictionary.
This procedure is used only with partitioned point data.
SDO_ADMIN.VERIFY_PARTITIONS (tablename)
tablename |
Specifies the name of the table. |
This procedure can generate the following errors depending on the results of the verification:
The following example verifies the table1 partitioned spatial table:
SQL> EXECUTE SDO_ADMIN.VERIFY_PARTITIONS('table1');
The functions described in this section are not required for creating or maintaining a spatial database, however, they are provided for convenience in working with legacy data in partitioned point data tables. They are used with SQL SELECT, INSERT, UPDATE, and DELETE statements to perform the following:
When using these functions in basic SQL statements, use the form:
SDO_<function>. When using the functions inside a PL/SQL block, use a period (.) instead of the underscore (_).
This section contains descriptions of the spatial functions listed in Table C-2.
This function creates a dimension from a bounded value, which is a value contained in a set of values expressed as a lower boundary and an upper boundary.
SDO_BVALUETODIM (value, lower_boundary, upper_boundary, decimal_scale)
This function returns a dimension. The data type is RAW.
The following example shows the SDO_BVALUETODIM() function:
SQL> INSERT INTO sourcetable1(SAMPLENAME,DATA_PT)
2> VALUES ('SAMPLE1',SDO_ENCODE(SDO_BVALUETODIM(10,-100,100,7),
3> SDO_BVALUETODIM(20,-100,100,7));
This function evaluates the relationship between an area or point described by an HHCODE and another HHCODE, or a range of HHCODEs expressed as an upper bound and lower bound.
SDO_COMPARE (hhcode_expression, {hhcode_expression | lower_bound_HHCODE,upper_bound_HHCODE})
This function returns one of the following keywords:
The data type is VARCHAR2.
The following example selects all points that fall within the given multidimensional range:
SQL> SELECT SDO_GID FROM layer1_SDOINDEX WHERE
2> SDO_COMPARE(SDO_MAXCODE,
3> SDO_ENCODE(5,5),
4> SDO_ENCODE(25,25))='INSIDE';
The following example selects GIDs based on interaction between their spatial index tiles:
SQL> SELECT SDO_GID FROM layer1_SDOINDEX A, layer2_SDOINDEX B
2> WHERE SDO_COMPARE(A.SDO_CODE,B.SDO_CODE) != 'OUTSIDE';
This function creates a dimension from an Oracle DATE data type. The component number determines the level of resolution of the date in the dimension.
SDO_DATETODIM (date [, component])
This function returns a dimension. The data type is RAW.
You must use a valid Oracle date format string.
The following example shows the SDO_DATETODIM() function:
SQL> INSERT INTO sourcetable1(SAMPLENAME,DATA_PT)
2> VAUES('SAMPLE1',SDO_ENCODE(SDO_DATETODIM(TO_DATE('19-Jul-96'),
3> SDO_BVALUETODIM(100,-1000,1000,7)));
This function extracts a single dimension from an HHCODE.
SDO_DECODE (hhcode_expression, dimension_number)
hhcode_expression |
Specifies an expression that evaluates to an HHCODE. |
dimension_number |
Specifies the dimension number to extract. |
This function returns a dimension. The data type is RAW.
The SDO_DECODE() function is called once for each dimension to be decoded.
The following example shows the SDO_DECODE() function:
SQL> SELECT
2> SDO_TO_BVALUE(SDO_DECODE(DATA_PT,1),1,6),
3> SDO_TO_BVALUE(SDO_DECODE(DATA_PT,2),-100,100),
4> SDO_TO_DATE(SDO_DECODE(DATA_PT,3))
5> FROM sourcetable1 WHERE SAMPLENAME='SAMPLE1';
This function combines dimensions to create the HHCODE that describes an area or point.
SDO_ENCODE (dimension1[,dimension2 ...])
dimension |
Specifies an expression created by the SDO_BVALUETODIM or SDO_DATETODIM functions. |
This function returns an HHCODE. The data type is RAW.
Consider the following when using this function:
The following example shows the SDO_ENCODE() function:
SQL> INSERT INTO sourcetable1(SAMPLENAME,DATA_PT)
2> VALUES ('SAMPLE1',SDO_ENCODE(SDO_BVALUETODIM(50,-100, 100, 10),
3> SDO_BVALUETODIM(30,-100,100,10),
4> SDO_DATETODIM(TO_DATE('05-Jul-96'),3)));
This function returns the original bounded data value of a dimension.
SDO_TO_BVALUE (dimension, lower_boundary, upper_boundary)
This function returns a bounded data value. The data type is NUMBER.
This function returns a number that is the value for a dimension within the specified range. This is not necessarily the range for which the dimension was originally created.
The following example shows the SDO_TO_BVALUE() function:
SQL> SELECT (SDO_TO_BVALUE(SDO_DECODE(DATA_PT,2),-100,100)
2> FROM sourcetable1 WHERE SAMPLENAME='SAMPLE1';
This function returns the original date value of a dimension.
SDO_TO_DATE (dimension)
dimension |
Specifies the dimension. |
This function returns an Oracle DATE data type.
The following example shows the SDO_TO_DATE() function:
SQL> SELECT SDO_TO_DATE(SDO_DECODE(DATA_PT,3))
2> FROM sourcetable1 WHERE SAMPLENAME='SAMPLE1';
The Spatial data dictionary is a set of tables owned by the database user mdsys. An extension to the Oracle8i data dictionary, it automatically maintains information about spatial tables, columns, and partitions. The Spatial data dictionary is created during the installation process. All nonspatial attribute information is maintained in the Oracle8i data dictionary.
The Spatial data dictionary has public views that provide extensive information about spatial tables. This section contains descriptions of the views that are available.
The following views are publicly available:
WARNING: Do not delete or modify any of the tables in the mdsys account. This corrupts the Spatial data dictionary. |
Returns a list of all columns that are part of spatial tables.
Returns a list of all dimensions that are part of HHCODE columns.
Contains information about spatial tables that should be removed (dropped) as a result of some failed operation, such as a failed load.
Column | Description |
---|---|
OWNER |
owner of the object |
NAME |
object name |
OPERATION |
operation during which the failure occurred |
CCHH |
common code HHCODE |
Contains the current status of a file that was loaded into a table using SD*Loader.
Column | Description |
---|---|
OWNER |
owner of the object |
MD_TABLE_NAME |
spatial table name |
FILENAME |
SLF file name |
ROWS_LOADED |
number of rows loaded before failure |
Returns a list of all the partitioned tables that are part of a user-accessible spatial table.
Returns a list of all the user-accessible spatial tables.
Returns a list of all tablespaces used by spatial tables.
Column | Description |
---|---|
OWNER |
owner of the object |
MD_TABLE_NAME |
name of the spatial table |
TABLESPACE_NAME |
name of tablespace |
SEQUENCE |
sequence number |
STATUS |
status of tablespace: ACTIVE or INACTIVE |
Returns a list of all columns that are part of Spatial tables.
Returns a list of all dimensions that are a part of spatial tables.
Contains information about spatial tables that should be removed (dropped) as a result of some failed operation, such as a failed load.
Column | Description |
---|---|
OWNER |
owner of the object |
NAME |
object name |
OPERATION |
operation during which the failure occurred |
CCHH |
common code HHCODE |
Contains the current status of a file that was loaded into a table using SD*Loader.
Column | Description |
---|---|
OWNER |
owner of the table where the error occurred |
MD_TABLE_NAME |
spatial table name |
FILENAME |
SLF file name |
ROWS_LOADED |
number of rows loaded before failure |
Returns a list of all the partitioned tables.
Returns a list of all the spatial tables.
Returns a list of all tablespaces used by spatial tables.
Column | Description |
---|---|
OWNER |
owner of the object |
MD_TABLE_NAME |
name of the spatial table |
TABLESPACE_NAME |
name of tablespace |
SEQUENCE |
sequence number |
STATUS |
status of tablespace: ACTIVE or INACTIVE |
Returns a list of all the HHCODE columns that are part of tables owned by the user.
Returns a list of all dimensions that are part of HHCODE columns owned by the user.
Contains information about spatial tables that should be removed (dropped) as a result of some failed operation, such as a failed load.
Column | Description |
---|---|
NAME |
object name |
OPERATION |
operation during which the failure occurred |
CCHH |
common code HHCODE |
Contains the current status of a file that was loaded into a table using SD*Loader.
Column | Description |
---|---|
MD_TABLE_NAME |
spatial table name |
FILENAME |
SLF file name |
ROWS_LOADED |
number of rows loaded before failure |
Returns a list of all the partitioned tables that are part of spatial tables owned by the user.
Returns a list of all the spatial tables owned by the user.
Returns a list of all tablespaces used by spatial tables.
Column | Description |
---|---|
MD_TABLE_NAME |
name of the spatial table |
TABLESPACE_NAME |
name of tablespace |
SEQUENCE |
sequence number |
STATUS |
status of the tablespace: ACTIVE or INACTIVE |
MDSQL-00001: partition is OFFLINE
Cause: An MDSQL operation was attempted on a partition that is OFFLINE.
Action: Restore the partition and try the operation again.
MDSQL-00002: PK is out of bounds
Cause: The partition key for the record being inserted belongs in another partition.
Action: Insert the record into the correct partition. The correct partition can be identified using the GET_PARTITION_NAME( ) function.
MDSQL-00003: updates that move the PK are not supported
Cause: The update of the partition key would result in the record belonging to another partition.
Action: Use the MD_DML.MOVE_RECORD( ) procedure to update the partition key and move the record to the correct partition.