Partitioned Spatial Indexes

Anybody know if local partitioning for spatial indexes is planned for any release in the future?
Terry

This feature is planned for 9i. I've seen it work, but this can't be construed as a commitment by Oracle until 9i ships.
null

Similar Messages

Create local spatial index on range sub-partitions?

Is is possible to create a local spatial index on a table with range sub-partitions? We're trying to do this on a table that contains lots of x,y,z point data.
Trying to do so gives me the error: ORA-29846: cannot create a local domain index on a composite partitioned tableAccording to the spatial documentation:The following restrictions apply to spatial index partitioning:
- The partition key for spatial tables must be a scalar value, and must not be a spatial column.
- Only range partitioning is supported on the underlying table. All other kinds of partitioning are not currently
supported for partitioned spatial indexes.So there is nothing saying it can or can't be done. The examples I've seen in the documentation tend to partition based on a single value and don't use subpartitioning.
Example of what we're trying to do:SQL> SELECT * FROM V$VERSION;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for 64-bit Windows: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
SQL>
SQL> --- Create a table, partioned by X and subpartitioned by Y
SQL> CREATE TABLE sub_partition_test
2 (
3      x               NUMBER,
4      y               NUMBER,
5      z               NUMBER,
6      geometry        MDSYS.SDO_GEOMETRY
7 )
8 PARTITION BY RANGE (x)
9 SUBPARTITION BY RANGE (y)
10     (
11     PARTITION p_x100 VALUES LESS THAN (100)
12     (
13                     SUBPARTITION sp_x100_y100 VALUES LESS THAN (100),
14                     SUBPARTITION sp_x100_y200 VALUES LESS THAN (200),
15                     SUBPARTITION sp_x100_yMAXVALUE VALUES LESS THAN (MAXVALUE)
16     ),
17     PARTITION p_x200 VALUES LESS THAN (200)
18     (
19                     SUBPARTITION sp_x200_y100 VALUES LESS THAN (100),
20                     SUBPARTITION sp_x200_y200 VALUES LESS THAN (200),
21                     SUBPARTITION sp_x200_yMAXVALUE VALUES LESS THAN (MAXVALUE)
22     ),
23     PARTITION p_xMAXVALUE VALUES LESS THAN (MAXVALUE)
24     (
25                     SUBPARTITION sp_xMAXVALUE_y100 VALUES LESS THAN (100),
26                     SUBPARTITION sp_xMAXVALUE_y200 VALUES LESS THAN (200),
27                     SUBPARTITION sp_xMAXVALUE_yMAXVALUE VALUES LESS THAN (MAXVALUE)
28     )
29 );
Table created.
SQL>
SQL> -- Insert some sample data
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (1, 1, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(1, 1, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (50, 150, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(50, 150, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (150, 150, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(150, 150, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (150, 250, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(150, 250, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (150, 300, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(150, 300, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (220, 210, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(220, 210, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (220, 150, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(220, 150, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (220, 250, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(220, 250, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (220, 300, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(220, 300, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (320, 250, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(320, 250, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (320, 160, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(320, 160, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (320, 290, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(320, 290, 50), NULL, NULL));
1 row created.
SQL> INSERT INTO sub_partition_test (x, y, z, geometry)
2 VALUES (320, 320, 50, SDO_GEOMETRY(3001, 2157, SDO_POINT_TYPE(320, 320, 50), NULL, NULL));
1 row created.
SQL>
SQL> -- Create some metadata
SQL> DELETE FROM user_sdo_geom_metadata WHERE TABLE_NAME = 'SUB_PARTITION_TEST';
1 row deleted.
SQL> INSERT INTO user_sdo_geom_metadata VALUES ('SUB_PARTITION_TEST','GEOMETRY',
2 SDO_DIM_ARRAY(
3     SDO_DIM_ELEMENT('X', 0, 1000, 0.005),
4     SDO_DIM_ELEMENT('Y', 0, 1000, 0.005)
5 ), 262152);
1 row created.
SQL>
SQL> -- Create an Unusable Local Spatial Index
SQL> CREATE INDEX sub_partition_test_spidx ON sub_partition_test (geometry)
2    INDEXTYPE IS MDSYS.SPATIAL_INDEX
3 LOCAL
4 UNUSABLE;
CREATE INDEX sub_partition_test_spidx ON sub_partition_test (geometry)
ERROR at line 1:
ORA-29846: cannot create a local domain index on a composite partitioned tableThanks,
John

Ok, thanks. That's what we're planning on doing now.
SQL> CREATE TABLE partition_test
2 (
3      x               NUMBER,
4      y               NUMBER,
5      z               NUMBER,
6      geometry        MDSYS.SDO_GEOMETRY
7 )
8 PARTITION BY RANGE (x, y)
9     (
10     PARTITION p_x100y100 VALUES LESS THAN (100, 100),
11     PARTITION p_x100y200 VALUES LESS THAN (100, 200),
12     PARTITION p_x100yMAX VALUES LESS THAN (100, MAXVALUE),
13     PARTITION p_x200y100 VALUES LESS THAN (200, 100),
14     PARTITION p_x200y200 VALUES LESS THAN (200, 200),
15     PARTITION p_x200yMAX VALUES LESS THAN (200, MAXVALUE),
16     PARTITION p_x300y100 VALUES LESS THAN (300, 100),
17     PARTITION p_x300y200 VALUES LESS THAN (300, 200),
18     PARTITION p_x300yMAX VALUES LESS THAN (MAXVALUE, MAXVALUE)
19 );
Table created.
SQL>
SQL> INSERT INTO user_sdo_geom_metadata VALUES ('PARTITION_TEST','GEOMETRY',
2     SDO_DIM_ARRAY(
3        SDO_DIM_ELEMENT('X', 0, 1000, 0.005),
4        SDO_DIM_ELEMENT('Y', 0, 1000, 0.005)
5     ), 262152);
1 row created.
SQL> CREATE INDEX partition_test_spidx ON partition_test (geometry)
2     INDEXTYPE IS MDSYS.SPATIAL_INDEX
3 LOCAL
4 UNUSABLE;
Index created.

Spatial Index on list partition?

Wondering if anyone has created a spatial index on a table that has a list partition. Documentation says only a range partition is supported.
Also, when creating the partition, has anyone created the partitions in parallel? i.e. hohup a gang of jobs that work on each partition.

Hi Steven,
Oracle spatial partitioned indexing does not support list partitions.
Also, parallel spatial indexing is supported as of Oracle 9iR2, but the
parallelism implemented for partitioned indexing is partition-at-a-time
parallelism, i.e. partition 1 is indexed in parallel, then partition 2, etc.
Also implemented in 9iR2 is exchange partition, which allows you to
build the partitions for each index separately in parallel, then exchange
them in with very high index availability.
Hope this helps,
Dan

Is there any plan of allowing non-range partitioning of spatial indexes

our application is really lacking the ability of spatial index being partitioned by list. We are binning information in our data warehouse by spatial locations, and when we query it (actually, MapViewer is generating a tile), entire geometry set is searched because table is list-partitioned and we cannot have local spatial index.

Hi,
I'm not in a position to answer the question about list partitioning, but would a pseudo-list partition implemented as a range partition work? For example, something like this:
CREATE TABLE customers (
first_name    VARCHAR2(20),
last_name     VARCHAR2(20),
address_1     VARCHAR2(20),
address_2     VARCHAR2(20),
city          VARCHAR2(20),
state_abrv    VARCHAR2(3),
postal_code   VARCHAR2(10),
customer_id   NUMBER NOT NULL UNIQUE)
PARTITION BY RANGE (state_abrv)
   PARTITION ALASKA         VALUES LESS THAN ('AKz'),
   PARTITION ALABAMA        VALUES LESS THAN ('ALz'),
   PARTITION ARKANSAS       VALUES LESS THAN ('ARz'),
   PARTITION AMERICANSAMOA VALUES LESS THAN ('ASz'),
   PARTITION ARIZONA        VALUES LESS THAN ('AZz'),
   PARTITION CALIFORNIA     VALUES LESS THAN ('CAz'),
   PARTITION WYOMING        VALUES LESS THAN ('WYz')
   );I've used this method in the past, although I agree a list partitioning solution is much preferred.
Dan

Spatial Index problems - Newbie here

Hello,
I am pretty new to Oracle and have had an issue pop up. I was able to solve it but I am wondering what the issue really is so I can have a better understanding of how Oracle works.
I am trying to run a spatial index on a table which contains partitions, here is the code I was running.
CREATE INDEX "xxx_ADMIN"."CODED_PART_CODE_SIDX" ON "xxx_ADMIN"."CODED_PART_CODE" ("GEOMETRY")
INDEXTYPE IS "MDSYS"."SPATIAL_INDEX" LOCAL (
PARTITION "PART_v1234" PARAMETERS ('tablespace=xxx_coded_part_code sdo_rtr_pctfree=0 pctincrease=0 layer_gtype=POINT'),
PARTITION "PART_v2345" PARAMETERS ('tablespace=xxx_coded_part_code sdo_rtr_pctfree=0 pctincrease=0 layer_gtype=POINT'),
PARTITION "PART_v3456" PARAMETERS ('tablespace=xxx_coded_part_code sdo_rtr_pctfree=0 pctincrease=0 layer_gtype=POINT'),
PARTITION "PART_OTHER" PARAMETERS ('tablespace=xxx_coded_part_code sdo_rtr_pctfree=0 pctincrease=0 layer_gtype=POINT')) ;
commit;
This never seems to work but when I change the name of the partitions to start with a 'd' instead of a 'v' (PART_v1234 becomes PART_d1234) everthng works just fine.
Any idea why this happens?
Any help would be appreciated,
Tom

Well the first thing you need to learn about Oracle is basic concepts such as when asking a question about Spatial to post in the forum that discusses Spatial.
This group, Advanced Queuing is totally unrelated to Spatial.

Problems building a spatial index - this must be a bug please help!

Hi,
We have a rather large spatial data warehouse. The schema is a star schema and is partitioned. During a load recently we had an error with one particular dataset, when building the index we got:
ERROR at line 1:
ORA-29855: error occured in the execution of ODCIINDEXCREATE routine
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
We have seen this kind of thing before, but usually dropping the data and reloading works fine (or rebuild the index). I should not that this obviously occurs before the partition is exchanged in. We are running 10.2.0.2 on red hat ES3.
With this error we tried to reload the data, but get the same. We tried the data on another copy of the system, and the same. We have tried the data on a 10.2.0.3 and an 11.1.0.6 database and all fail at the same location. We have validated the geometries - all fine, I have tried changing the DIMINFO so that it spans the whole globe, it failes again (by the way we are on SRID 8307 and all data is point type). The data is approx 1.2M rows and I have tried subdividing it up into smaller tables and these all build fine. I have partitions with much higher row counts and these are fine. I have tried everything possible including changing index parameters e.g. parallel tablespace etc. I have tried it on a tablespace without ASSM and one with and both fail. I have an export of the data if anyone would be available to try it?
I would really appreciate any help at all on this one.
Thanks
Jonathan

There was a post a few months ago that addressed issues with 10.2.0.3 and Spatial index creation: Re: Fixed ...
-Justin

Performance of Creating Spatial Indexes

I have a spatial database with about 75GB of data in it. When I load this data initially it takes about 6 hours to load using 6 processes. To get this performance level I did not create any of the indexes or contsraints. So after the load I have to run the scripts to create the indexes and constraints.
To improve the performance of this I have written a script on UNIX which parses my SQL files and runs each create or alter statement in a separate process. The script makes sure that there are only a certain number of concurrent processes (10).
Creating the indexes is taking longer than the database load itself. There is one point layer in particular which has serveral hundred million rows which takes around 6 hours to complete. Are the any ways you can improve the performance of index creation. I did try the parallel option once but it did not reliably complete when I did my testing.
Does using Oracle Partitioning improve the performance of index creation? I do have a mapsheet attribute which could be used for the partitioning.
Paul

Hi Paul,
Parallelism should have reliably helped. I've heard a lot of good things about it more recently (i.e. if you tested on an earlier version you may want to upgrade/patch and check it out).
Partitioning should improve index creation speed as well. If you tend to query by an attribute, use that attribute as the partition key. If you tend to query by location (spatial query), try to use a partition key that reflects location (state, county, etc).
When you first create the index, create it local (partitioned) as unusable, then create each partition's index separately in parallel - you can use the script you've already written to do this.
Since it is point data, make sure to use layer_gtype=point
Here is a quick example:
CREATE INDEX partn_table_sidx ON partn_table(geom)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('LAYER_GTYPE=POINT')
LOCAL (
PARTITION P1 PARAMETERS (TABLESPACE=’P1_TBS’),
PARTITION P2 PARAMETERS (TABLESPACE=’P2_TBS’),
PARTITION P3 PARAMETERS (TABLESPACE=’P3_TBS’),
PARTITION P4 PARAMETERS (TABLESPACE=’P4_TBS’))
UNUSABLE;
ALTER INDEX partn_table_sidx REBUILD PARTITION P1;
ALTER INDEX partn_table_sidx REBUILD PARTITION P2;
ALTER INDEX partn_table_sidx REBUILD PARTITION P3;
ALTER INDEX partn_table_sidx REBUILD PARTITION P4;

Performance of insert with spatial index

I'm writing a test that inserts (using OCI) 10,000 2D point geometries (gtype=2001) into a table with a single SDO_GEOMETRY column. I wrote the code doing the insert before setting up the index on the spatial column, thus I was aware of the insert speed (almost instantaneous) without a spatial index (with layer_gtype=POINT), and noticed immediately the performance drop with the index (> 10 seconds).
Here's the raw timing data of 3 runs in each 3 configuration (the clock ticks every 14 or 15 or 16 ms, thus the zero when it completes before the next tick):
                                   truncate execute commit
no spatial index                     0.016   0.171   0.016
no spatial index                     0.031   0.172   0.000
no spatial index                     0.031   0.204   0.000
index (1000 default for batch size) 0.141 10.937   1.547
index (1000 default for batch size) 0.094 11.125   1.531
index (1000 default for batch size) 0.094 10.937   1.610
index SDO_DML_BATCH_SIZE=10000       0.203 11.234   0.359
index SDO_DML_BATCH_SIZE=10000       0.094 10.828   0.344
index SDO_DML_BATCH_SIZE=10000       0.078 10.844   0.359As you can see, I played with SDO_DML_BATCH_SIZE to change the default of 1,000 to 10,000, which does improve the commit speed a bit from 1.5s to 0.35s (pretty good when you only look at these numbers...), but the shocking part of the almost 11s the inserts are now taking, compared to 0.2s without an index: that's a 50x drop in peformance!!!
I've looked at my table in SQL Developer, and it has no triggers associated, although there has to be something to mark the index as dirty so that it updates itself on commit.
So where is coming the huge overhead during the insert???
(by insert I mean the time OCIStmtExecute takes to run the array-bind of 10,000 points. It's exactly the same code with or without an index).
Can anyone explain the 50x insert performance drop?
Any suggestion on how to improve the performance of this scenario?
To provide another data point, creating the index itself on a populated table (with the same 10,000 points) takes less than 1 second, which is consistent with the commit speeds I'm seeing, and thus puzzles me all the more regarding this 10s insert overhead...
SQL> set timing on
SQL> select count(*) from within_point_distance_tab;
COUNT(*)
     10000
Elapsed: 00:00:00.01
SQL> CREATE INDEX with6CDF1526$point$idx
2            ON within_point_distance_tab(point)
3    INDEXTYPE IS MDSYS.SPATIAL_INDEX
4    PARAMETERS ('layer_gtype=POINT');
Index created.
Elapsed: 00:00:00.96
SQL> drop index WITH6CDF1526$POINT$IDX force;
Index dropped.
Elapsed: 00:00:00.57
SQL> CREATE INDEX with6CDF1526$point$idx
2            ON within_point_distance_tab(point)
3    INDEXTYPE IS MDSYS.SPATIAL_INDEX
4    PARAMETERS ('layer_gtype=POINT SDO_DML_BATCH_SIZE=10000');
Index created.
Elapsed: 00:00:00.98
SQL>

Thanks for your input. We are likely to use partioning down the line, but what you are describing (partition exchange) is currently beyond my abilities in plain SQL, and how this could be accomplished from an OCI client application without affecting other users and keep the transaction boundaries sounds far from trivial. (i.e. can it made transparent to the client application, and does it require privileges the client does have???). I'll have to investigate this further though, and this technique sounds like one accessible to a DBA only, not from a plain client app with non-privileged credentials.
The thing that I fail to understand though, despite your explanation, is why the slow down is not entirely on the commit. After all, documentation for the SDO_DML_BATCH_SIZE parameter of the Spatial index implies that the index is updated on commit only, where new rows are fed 1,000 or 10,000 at a time to the indexing engine, and I do see time being spent during commit, but it's the geometry insert that slow down the most, and that to me looks quite strange.
It's so much slower that it's as if each geometry was indexed one at a time, when I'm doing a single insert with an array bind (i.e. equivalent to a bulk operation in PL/SQL), and if so much time is spend during the insert, then why is any time spent during the commit. In my opinion it's one or the other, but not both. What am I missing? --DD

Slow spatial index creation

Hi,
I am using v11.2.0.2 and it took 9.5 hours to create a spatial index for 88 million geodetic points. The table itself was created in 15 minutes (with a CTAS from another table with lat/lons) and only has two columns: ULL and GEOM. Does this seem excessive? What can I do to reduce the time to create the spatial index?
CREATE INDEX POINT_LL_SIDX ON POINT_LL (GEOM) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('TABLESPACE=ORDERS_IDX WORK_TABLESPACE=ORDERS_03 LAYER_GTYPE=POINT')Thanks,
David

Hi David,
If you have several CPU cores in your computer, you may try to create your spatial index in parallel,
especially, you can create a partitioned table and create a local spatial index on it in parallel.
BTW, on 11.2.0.2, bug 9588219 may affect index creation performance. Please get a patch for it,
or try your test case on 11.2.0.3.
Thanks,
Ying
Edited by: yhu on Jun 13, 2012 7:19 AM

Problem with function-based spatial index in 10g

hi,
the document's example doesn't work anymore.
http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10826/sdo_exten.htm#sthref721
when i try to create the index i get the following error message:
create index LONG_LAT_TABLE_IDX on LONG_LAT_TABLE(get_long_lat_pt(longitude,latitude)) indextype is mdsys.spatial_index
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-29400: data cartridge error
ORA-00904: "XXX"."GET_LONG_LAT_PT": invalid identifier
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
ORA-06512: at line 1
I'm not sure, but I think this problem occured in one special version of 9i...
thanks in advance,
michael
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

Hi Michael,
Do you have a user named XXX on your system? Are you creating the index as XXX?
I logged in as scott, followed the example, and had no problems.
SQL> create index LONG_LAT_TABLE_IDX on
LONG_LAT_TABLE(get_long_lat_pt(longitude,latitude))
indextype is mdsys.spatial_index;
Index created.
SQL> SQL> select name from LONG_LAT_TABLE a
where sdo_filter(get_long_lat_pt(a.longitude,a.latitude),
sdo_geometry(2001, 8307,
sdo_point_type(10,10,NULL), NULL, NULL)
)='TRUE';
NAME
Place1
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

Partioning spatially indexed tables

I am a complete novice when it comes to partitioning, so can someone tell me any advantages/disadvantages/problems in partitioning a large RTREE spatially indexed table (using an SDO_GEOMETRY column) containing several million rows?

Just to make sure you understand what is and isn't possible:
When partitioning a table with spatial data, you cannot partition based on the geometry column.
Spatial index partitioning is only available on a table that has been partitioned by range.
All of the manageability benefits associated with partitioning data applies to data with a spatial column as well. If the index has been built using partitioning, you can do things like store different index partitions in different tablespaces, index partition rebuilds, index partition archives, exchange, split, merge partitions, etc.
In terms of performance, there are several benefits that can be achieved:
If the partition key can be specified as a predicate on the query, then there can be a large performance improvement.
If you can't specify a partition key in the query, then if the index is stored across different tablespaces then concurrency can improve if multiple sessions are accessing the index.
Single stream performance can be improved through the use of parallelism as well.
Most of the above is available in 9iR1, although exchange partition and parallelism both were available as of 9iR2.
If there is no parallelism, and no partition key predicate can be specified in spatial queries, and there is only single session access to the database, and you don't need the manageability benefits, then partitioning probably isn't for you.

Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? Difference between Enterprise and SE?

We’re seeing the following issue: sql - Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? - Stack Overflow (posted by a colleague of mine) and are curious to know if this behaviour is due to a difference between standard and enterprise, or could we doing something else wrong in our DB config.?
We have also reproduced the issue on the following stacks:
Oracle SE One 11.2.0.3 (with Spatial enabled)
Redhat Linux 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
11.2.0.3.0 Standard Edition and 11.2.0.4.0 Standard Edition (both with Spatial enabled)
Microsoft Windows Server 2003R2 Standard x64 Edition
However, the SQL works fine if we try it on Oracle 11.2.0.3.0 *Enterprise* Edition.
Any help or advice would be much appreciated.
Kindest Regards,
Kevin

In my experience sdo_filter ALWAYS uses the spatial index, so that's not the problem. Since you did not provide the explain plans, we can't say for sure but I think yhu is right: Standard Edition can't use the bitmap operations, and thus it'll take longer to combine the results of the two queries (because the optimizer will surely split this OR up in two parts, then combine them).
BTW: when asking questions about queries here, it would be nice if you posted the queries here as well, so that we do not have to check another website in order to see what you are doing. Plus it will probably get you more answers, because not everyone can be bothered to click on that link. It would also have been nice if you had posted your own answer on the other post here as well, because my recommendation would have been to use union all - but since you already found that out for yourself my recommendation would have been a little late.

Spatial Index and XA transaction

Hi all,
I have problem with spatial index in XA transaction.
java.sql.SQLException: ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-29400: data cartridge error
ORA-14450: attempt to access a transactional temp table already in use
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 623
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 227
My configuration Java 5, Tomcat 5.5, UserTransaction manager Bitronix.
The problem disappears after dropping spatial index.
sql statement:
INSERT INTO ICING_SPATIAL.MAP_ISSUES ( FEATURE_ID, GEOMETRY, AUTHOR_ID, ISSUE_ID, ISSUE_STATUS, LANGUAGE, SOURCE, TEXT) VALUES ( ? ,SDO_MIGRATE.TO_CURRENT( ? , ( SELECT DIMINFO FROM ALL_SDO_GEOM_METADATA WHERE OWNER = ? AND TABLE_NAME = ? AND COLUMN_NAME = ? ) ), ? , ? , ? , ? , ? , ? )
Full stacktrace is:
java.sql.SQLException: ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-29400: data cartridge error
ORA-14450: attempt to access a transactional temp table already in use
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 623
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 227
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:212)
at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:951)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1160)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at oracle.jdbc.driver.OracleCallableStatement.executeUpdate(OracleCallableStatement.java:4245)
All user transactions are commited or rollbacked because the DBA_2PC_PENDING is empty: SQL> select * from SYS.DBA_2PC_PENDING;
no rows selected
SQL>
This problem occures regulary after any 2PC transaction has been rolledback. The next request causes this exception. Sometimes it appears after commit too, but I am able to reproduce it within ten or twenty requests.
Has anybody had simillar problem?
Thanks for any suggestions how to check what is going wrong.
Regards,
Zdenek Vrablik

The problem is in Oracle Spatial.
Oracle database don't support Temporary tables and XA transactions together. Oracle Spatial uses temporary tables.
Possible solution (I am using)
One database connection(nonXA) to read data and one connection(XA) to insedt/update/delete data including spatial data.

Creating a combined view of two spatially indexed tables

Hi All,
I'm using oracle 10g and C++ occi to store and retrieve data. I have two tables that are identical in structure, they have an SDO_GEOM column where I store lat/long/altitude info. When I store the data using a stored procedure, the data is put into the correct table. I now want to retrieve the data using a spatial operator - I use SDO_NN to retrive data within a given distance of a lat/long/altitude point. This works fine for a single or multiple tables as I use a stored function to give me the data back as an object. I now have a requirement to list all the data from both tables - I thought I could do this by creating a combined view but I understand this cannot be done with spatial data - I habe also tried using the join operator but I am having problems since the columns for each table are identical. Is there any workaround for this - the combined view will not have any spatial operators run on it, I just need to return each row (the spatial data can be returned as individual lat/long/alt instead of as a SDO_GEOM. A second idea I had would be to return all the data using a ref cursor - this works for a single table but I do not understand how I can open the cursor with a select from two tables with identical column names.
Unfortunately it is a requirement that the tables are seperate so combining the two tables into one is not an option.
Thanks in advance for any help anyone can offer,
Cheers,
Rob

You can create a UNION ALL view:
CREATE TABLE cola_markets_1 (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape SDO_GEOMETRY);
CREATE TABLE cola_markets_2 (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape SDO_GEOMETRY);
CREATE VIEW v1 AS
SELECT * FROM cola_markets_1 UNION ALL SELECT * FROM cola_markets_2;
If both tables have a spatial index on their shape column, a query plan will look
like:
explain plan for SELECT c.mkt_id, c.name FROM v1 c WHERE SDO_NN(c.shape, SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(4,6, 8,8)) , 'sdo_num_res=1') = 'TRUE';
0 SELECT STATEMENT     |           |
1 VIEW               | V1          |
2 UNION-ALL          |           |
3 TABLE ACCESS BY INDEX ROWID| COLA_MARKETS_1
4 DOMAIN INDEX     | COLA_SPATIAL_IDX_1
5 TABLE ACCESS BY INDEX ROWID| COLA_MARKETS_2
6 DOMAIN INDEX     | COLA_SPATIAL_IDX_2
However, the above SDO_NN query will return 2 rows (one from each table),
because it can only work on one table, it won't return the nearest neighbor
from the combined view without some tweaks. For example, to return the
top one, you may try:
select * from (SELECT c.mkt_id, c.name FROM v1 c WHERE SDO_NN(c.shape, SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(4,6, 8,8)) , 'sdo_num_res=1') = 'TRUE' order by sdo_geom.sdo_distance(c.shape, SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(4,6, 8,8)), 0.0001)) where rownum < 2;
Note that you can only pass literals or bind variables into the second input parameter
of spatial operators (including SDO_NN), when a UNION ALL view is used. i.e. the following
query won't work right now:
SELECT c.* FROM v1 c, another_table b WHERE b.id =1 and SDO_NN(c.shape, b.shape, 'sdo_num_res=1')= 'TRUE';

Spatial index creation for table with more than one geometry columns?

I have table with more than one geometry columns.
I'v added in user_sdo_geom_metadata table record for every column in the table.
When I try to create spatial indexes over geometry columns in the table - i get error message:
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13203: failed to read USER_SDO_GEOM_METADATA table
ORA-13203: failed to read USER_SDO_GEOM_METADATA table
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 8
ORA-06512: at line 1
What is the the solution?

I'v got errors in my user_sdo_geom_metadata.
The problem does not exists!

Partitioned Spatial Indexes

Similar Messages

Maybe you are looking for