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.

Similar Messages

Materialized view issue with spatial index and UNION all.

Hi guys,
I'm trying to build the following materialized view:
create materialized VIEW MV_ElectricalStuffs
refresh fast
AS
SELECT jb.ROWID,
    jb.FID,
    JB.NAME_NUMBER
FROM EL_BUS_BAR jb
UNION ALL
SELECT INC.ROWID,
    INC.FID,
    NULL,
    INC.NAME_NUMBER
FROM EL_INTERNAL_CELL INC;
I have this error showing up:
ORA-12015: cannot create a fast refresh materialized view from a complex query
This is because the table EL_INTERNAL_CELL has a SDO_GEOMETRY column that has a spatial index, whose ddl is
CREATE INDEX EL_INTERNAL_CELL_S ON EL_INTERNAL_CELL (GEOM) INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS('SDO_INDX_DIMS=2 TABLESPACE=USERS LAYER_GTYPE=COLLECTION');
When I remove the spatial index from EL_INTERNAL_CELL column GEOM, Oracle is very happy and creates the view.
Is there a mean however to keep the spatial index in the materialized view?

I've managed to drop the spatial index prior to create the materialized view and it is ok. After the materialized view creation, I've recreated the spatial index on the table and all ran smooth. Hope nothing will go bad in the future because of this trick on spatial index..

Trouble with creating Spatial Indexes and "user_sdo_geom_metadata"

G'day All,
I've encountered a weird issue while playing around with SDO_GEOMETRY objects under Oracle Apex v3.0.1 on Oracle XE running on Windows Vista.
The issue started when I attempted to create the spatial index :
create index geotag_sdx on geotag(location)
indextype is mdsys.spatial_index;
and I got the following error:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13203: failed to read USER_SDO_GEOM_METADATA view
ORA-13203: failed to read USER_SDO_GEOM_METADATA view
I scratched my head for a sec and thought WTF ? my metadata insert worked... well I was sure it did. However when I ran a select from "user_sdo_geom_metadata" there was no rows, so I tried again and I got an error "name is already used by an existing object", again I thought WTF ?
After getting the source for the "updatable" view "MDSYS.user_sdo_geom_metadata" I could see that the view was filter by CURRENT_SCHEMA:
SELECT SDO_TABLE_NAME TABLE_NAME, SDO_COLUMN_NAME COLUMN_NAME, SDO_DIMINFO DIMINFO, SDO_SRID SRID
FROM SDO_GEOM_METADATA_TABLE
WHERE sdo_owner = sys_context('userenv', 'CURRENT_SCHEMA')
I ran SELECT sys_context('userenv', 'CURRENT_SCHEMA') FROM DUAL and it correctly returned the SCHMEA name.
So from sqlplus and logged in a sys/sysdba I ran a select statement from MDSYS.SDO_GEOM_METADATA_TABLE and i saw the problem, the record was inserted with a SDO_OWNER value of "ANONYMOUS".
When I logged as the SCHEMA via sqlplus and ran the metadata insert statement it worked fine an d the index could be created.
Has anyone ran into this issue and how did you fix it as I'm concerned or know what I might be doing wrong ?
Any help would be most appreciated ?
Regards
Mark

Hi Marks,
Had a quick look at the stored procedure I'm using and there it is. We don't insert into user_sdo_geom_metadatas but in mdsys.sdo_geom_metadata_table and specify the owner ourselves. Of course, you need a direct grant on mdsys.sdo_geom_metadata_table to be able to do this from a stored procedure.
Seems we had the problem you are facing even without Apex. Our application has a special admin user that has execute privs on certain packages. But when running the spatial index creation procedure we ran into this "owner" problem.
Here they use all_sdo_geom_metadata:
Re: Metadata Error
Message was edited by:
renewestenberg

Spatial index - invalid geometry

Hello,
I have a table with buildings, on that a spatial index and everything was working fine.
Then, I added some more data (buildings) and the spatial queries (e.g., sdo_within_distance) didn't work anymore. I then dropped the spatial index and recreated it. That seemed to work fine (sqlplus told me "Index created"). When I go into the enterprise manager and check the spatial index it says this:
Failed to initialize Related Segments Space Info: ORA-00600: internal error code, arguments: [ktsircinfo_num1], [0], [0], [0], [], [], [], [] ORA-06512: at "SYS.DBMS_SPACE", line 429 ORA-06512: at line 1
Anyone knows what this might have to do with?
I also checked the geometries using VALIDATE_GEOMETRY_WITH_CONTEXT and found that there are some geometries with redundant points and self-intersecting boundaries.
Could this explain the above problem?
Markus

Hi, thanks, I decided to try an example word for word but I am still having the same problems.
I am thinking this might be an OEM error but I don't know. If it is I can live with it, but I need to know what the problem is before I can ignore an error in my production system.
This is what I am doing:
Following the directions provided in the following doc:
Doc ID: Note:146094.1
Subject: 9i New Feature: SDO_GEOMETRY Objects in Function-Based Indexes
Type: BULLETIN
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 17-MAY-2001
Last Revision Date: 21-APR-2004
PURPOSE ------- This article shows how to create and use a function-based index where the function returns an SDO_GEOMETRY object.
After I create the first index (LONG_LAT_TABLE_IDX) and then use OEM to find indexes for scott schema and click on LONG_LAT_TABLE_IDX entry I get the same exact error.
I am using 10g.
Are there "patches" for 10g that I need? If so, how do I figure out what I need?
Thank you for your time.
Les.

Spatial index creation error -ORA-13011: value is out of range

I am trying to create a spatial index and this is what I get.
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13200: internal error [ROWID:AAAFXYAADAAABxyAAD] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13011: value is out of range
ORA-00600: internal error code, arguments: [kope2upic014], [], [], [], [],
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 7
ORA-06512: at line 1
I can't find any documentation as to how to fix this. How do you determine which row of data is out of range? Any help would be greatly appreciated!

Hi Jeff,
The data at rowid AAAFXYAADAAABxyAAD has a problem.
Can see what the issue is by doing:
select sdo_geom.validate_geometry(geom_col_name,diminfo)
from your_table_name a, user_sdo_geom_metadata b
where b.table_name='YOUR_TABLE_NAME'
and a.rowid='AAAFXYAADAAABxyAAD';
If you are using Oracle9iR2 then this would be even better:
select sdo_geom.validate_geometry_with_context(geom_col_name,diminfo)
from your_table_name a, user_sdo_geom_metadata b
where b.table_name='YOUR_TABLE_NAME'
and a.rowid='AAAFXYAADAAABxyAAD';

Spatial Index Problem in View

Hello everyone.
I have a table (A) that stores point locations (X,Y) and contains the following fields:
ID NUMBER(10,0) No 1
CD_CODIGO_EMA VARCHAR2(10 BYTE) Yes 2
TX_NOMBRE_EMA VARCHAR2(50 BYTE) Yes 3
CD_PROVINCIA_EMA NUMBER(5,0) Yes 4
CD_MUNICIPIO_EMA NUMBER(5,0) Yes 5
NU_UTMX_EMA NUMBER(10,2) Yes 6
NU_UTMY_EMA NUMBER(10,2) Yes 7
NU_HUSO_EMA NUMBER(5,0) Yes 8
NU_TIPO_EMA NUMBER(3,0) Yes 9
TX_URL_EMA VARCHAR2(255 BYTE) Yes 10
I have created a view (V) with a field of type SDO_GEOMETRY values based on longitude (NU_UTMX_EMA) and latitude columns (NU_UTMY_EMA) in Table A, as follows:
CREATE VIEW A_VIEW (ID, SHAPE)
AS SELECT
ID, MDSYS.SDO_GEOMETRY(2001, 83030, MDSYS.SDO_POINT_TYPE(NU_UTMX_EMA, NU_UTMY_EMA, NULL), NULL, NULL)
FROM A
I have updated the view USER_SDO_GEOM_METADATA:
insert into user_sdo_geom_metadata values (
'A_VIEW',
'SHAPE',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('Longitude',90000,630000,0.005),
MDSYS.SDO_DIM_ELEMENT('Latitude',3980000,4300000,0.005)
83030
I can see the spatial view in differentes clientes (for example, Geoserver and ArcMap). The problem is when I try to Zoom into the View I receive the message: Interface not supported without a spatial index+
If I try to make an spatial index on the view, I receive the message:
create index V_idx on A_VIEW(SHAPE) indextype is MDSYS.SPATIAL_INDEX;
ORA-01702 A view is nos appropiate here.
How can I fix it? The original table (A) has a spatial index and it works fine.
Thanks in advance

This should be answered in your other post:
View with SDO_GEOMETRY column

ODCIIndexStart error in Spatial Index Advisor

Folks,
I am getting the following error when attempting to zoom in on a layer in the spatial index advisor:
Initialization error: server object could not be initialized
ORA-29902: error in executing ODCIIndexStart() routine
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at "MDSYS.SDO_CS", line 236
I have seen similar sorts of complaints from a number of people in the forums but no clear explanation of what is causing the problem or how to resolve it.
I did a bunch of experiments and I have come to the conclusion that the problem only occurs with layers that have 3 dimensions and are geodetic. If I force a projected SRID to be used for the layer (and all component geometries) then the problem goes away. Or if I force the layer to be only 2D then it works fine.
I have also tried using "geodetic=false" and "sdo_indx_dims=2" when creating the spatial index, and these did not seem to help at all.
The problem is occuring for me in the spatial index advisor, but my understanding from my client is that it also occurs in other contexts, so I don't think this is specifically a spatial index advisor problem.
I would add that I believe I am running 9.2.0.1.0 on Windows XP.
I found I was able to reproduce the problem creating an indexing a layer as follows then opening it in the spatial index advisor and trying to zoom in:
-- Cleanup
drop index idx_test1 force;
drop table test1;
delete from user_sdo_geom_metadata where table_name = 'TEST1';
--Here's my table:
CREATE TABLE test1
PNT_ID NUMBER(17) NOT NULL,
ORA_GEOMETRY MDSYS.SDO_GEOMETRY
--Here's my insert:
INSERT INTO test1
VALUES ( 1, MDSYS.SDO_GEOMETRY(
3001, 8192, MDSYS.SDO_POINT_TYPE(60.8996766, -32.606364, 0), NULL, NULL
COMMIT;
-- of course I did the insert into the metadata table...
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'TEST1',
'ora_geometry',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 50, 70, 0.0005),
MDSYS.SDO_DIM_ELEMENT('Y', -40, -30, 0.0005),
MDSYS.SDO_DIM_ELEMENT('Z', -10, 10, 0.0005)),
8192
COMMIT;
CREATE INDEX idx_test1
ON test1(ora_geometry)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
I would appreciate any feedback on why this doesn't work and if there is a more elegant way of resolving the problem beside discarding my elevation values.

This is reproducable in 9.2.0.4. I couldn't find a bug entered for it.
I entered bug 3149274.
There is a similar bug (2409529) that breaks projected layers.

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.

I can't not use spatial operator and index .

Dear all,
I create following spatial tales and spatial index.
create table LHelix(
PDB_IDcode varchar(8) not null,
chainID varchar(2),
Hnum number not null,
anum varchar(6),
Hgeo MDSYS.SDO_GEOMETRY,
primary key(PDB_IDcode,chainId,hnum,anum))
insert into user_sdo_geom_metadata values(
'LHELIX','HGEO',
mdsys.sdo_dim_array(
mdsys.sdo_dim_element('X',-400,400,0.05),
mdsys.sdo_dim_element('Y',-400,400,0.05),
mdsys.sdo_dim_element('Z',-400,400,0.05)),0);
create index LhI on Lhelix(hgeo) indextype is MDSYS.spatial_index
PARAMETERS ('SDO_level=12 sdo_numtiles=100 sdo_maxlevel= 32')
After that, I perfomed following query.
select distinct l1.pdb_idcode, l2.pdb_idcode,l1.hnum, l2.hnum
from lhelix l1, lhelix l2
where mdsys.sdo_relate(l1.hgeo, l2.hgeo, 'mask=ANYINTERACT querytype=Window')='TRUE' and
l1.pdb_idcode != l2.pdb_idcode and l2.pdb_idcode='1wja';
When I did this query, I got the results.
But Now when I try query, I have following errors.
ORA-29902: ODCIIndexStart() ·çÆ¾À» ¼öÇà½Ã ¿À·ù°¡ »ý°å½À´Ï´Ù
ORA-13208: ³»ºÎ ¿À·ù°¡ [window SRID does not match layer SRID] ¿¬»êÀÚ¸¦
Æò°¡ÇÏ´Âµ¥ »ý°å½À´Ï´Ù
ORA-06512: "MDSYS.SDO_INDEX_METHOD", ÁÙ 84¿¡¼
ORA-06512: ÁÙ 1¿¡¼
Dose anybody know how can I handle this problems?
I am so in hurry!!!
Please help me!!!
Thanks!!
sung

I would suggest two things:
1) Do not use 0 for the SRID in the user_sdo_geom_metadata entry. There is no 0 SRID value. Look at the sdo_srid value in your geometries, and if it is NULL, specify NULL. If there is a value, match it in the user_sdo_geom_metadata entry.

Cannot INSERT records into Partitioned Spatial Table and Index

I am trying to tune our Spatial Storage by creating partitioning our spatial_entity table and index. I used the World Geographic Reference System (GEOREF) creating a partition for each 15 x 15 degree grid square assigning a partition key of decimal longitude, decimal_latitude. The build went OK, however when trying to insert a data record I receive an ORA-14400: Inserted partition key does not map to any partition.
I validated the CREATE(s), and all appears correct, but obviously something is not correct, which is prompting for expert help in this forum.
I would be very grateful for your help.
Below are the code snippets for the table and index, and an insert statement.
CREATE TABLE spatial_entity
     geoloc_type VARCHAR2 (60 BYTE) NOT NULL
,entity_id NUMBER NOT NULL
,metadata_xml_uuid VARCHAR2 (40 BYTE) NOT NULL
,geoloc MDSYS.sdo_geometry NOT NULL
,nee_method CHAR (1 BYTE) NOT NULL
,nee_status CHAR (1 BYTE) NOT NULL
,decimal_latitude NUMBER (15, 6) NOT NULL
,decimal_longitude NUMBER (15, 6) NOT NULL
PARTITION BY RANGE (decimal_longitude, decimal_latitude)
     PARTITION p_lt_0_90s
          VALUES LESS THAN (1, -90)
     ,PARTITION p_lt_0_75s
          VALUES LESS THAN (1, -75)
     ,PARTITION p_lt_0_60s
          VALUES LESS THAN (1, -60)
     ,PARTITION p_lt_0_45s
          VALUES LESS THAN (1, -45)
     ,PARTITION p_lt_0_30s
          VALUES LESS THAN (1, -30)
     ,PARTITION p_lt_0_15s
          VALUES LESS THAN (1, -15)
     ,PARTITION p_lt_0_0
          VALUES LESS THAN (1, 0)
     ,PARTITION p_lt_0_15n
          VALUES LESS THAN (1, 15)
     ,PARTITION p_lt_0_30n
          VALUES LESS THAN (1, 30)
     ,PARTITION p_lt_0_45n
          VALUES LESS THAN (1, 45)
     ,PARTITION p_lt_0_60n
          VALUES LESS THAN (1, 60)
     ,PARTITION p_lt_0_75n
          VALUES LESS THAN (1, 75)
     ,PARTITION p_lt_0_90n
          VALUES LESS THAN (1, maxvalue)
CREATE INDEX geo_spatial_ind ON spatial_entity (geoloc)
INDEXTYPE IS mdsys.spatial_index
PARAMETERS ('layer_gtype=MULTIPOINT TABLESPACE=GEO_SPATIAL_IND') LOCAL
(PARTITION p_lt_0_90s,
PARTITION p_lt_0_75s,
PARTITION p_lt_0_60s,
PARTITION p_lt_0_45s,
PARTITION p_lt_0_30s,
PARTITION p_lt_0_15s,
PARTITION p_lt_0_0,
PARTITION p_lt_0_15n,
PARTITION p_lt_0_30n,
PARTITION p_lt_0_45n,
PARTITION p_lt_0_60n,
PARTITION p_lt_0_75n,
PARTITION p_lt_0_90n,
INSERT INTO spatial_entity
     geoloc_type
     ,entity_id
     ,metadata_xml_uuid
     ,geoloc
     ,nee_method
     ,nee_status
     ,decimal_latitude
     ,decimal_longitude
VALUES
               'BATCH'
               ,0
               ,'6EC25B76-8482-4F95-E0440003BAD57EDF'
               ,"MDSYS"."SDO_GEOMETRY"
                    2001
                    ,8307
                    ,"MDSYS"."SDO_POINT_TYPE" (32.915286, 44.337902, NULL)
                    ,NULL
                    ,NULL
               ,'M'
               ,'U'
               ,32.915286
               ,44.337902
Thank you for you help.
Dave

Thank you for your quick reply. I did not post the entire CREATE script as it is quite long. The portion of the script that is applicable to the INSERT is:
,PARTITION p_lt_45e_90s
          VALUES LESS THAN (23, -90)
     ,PARTITION p_lt_45e_75s
          VALUES LESS THAN (23, -75)
     ,PARTITION p_lt_45e_60s
          VALUES LESS THAN (23, -60)
     ,PARTITION p_lt_45e_45s
          VALUES LESS THAN (23, -45)
     ,PARTITION p_lt_45e_30s
          VALUES LESS THAN (23, -30)
     ,PARTITION p_lt_45e_15s
          VALUES LESS THAN (23, -15)
     ,PARTITION p_lt_45e_0
          VALUES LESS THAN (23, 0)
     ,PARTITION p_lt_45e_15n
          VALUES LESS THAN (23, 15)
     ,PARTITION p_lt_45e_30n
          VALUES LESS THAN (23, 30)
     ,PARTITION p_lt_45e_45n
          VALUES LESS THAN (23, 45)
     ,PARTITION p_lt_45e_60n
          VALUES LESS THAN (23, 60)
     ,PARTITION p_lt_45e_75n
          VALUES LESS THAN (23, 75)
     ,PARTITION p_lt_45e_90n
          VALUES LESS THAN (23, maxvalue)
Or, I do not fully understand. Are you indicating that I must explcitly state the longitude in each clause,
e.g ,PARTITION p_lt_45e_45n
          VALUES LESS THAN (45, 45)
,PARTITION p_lt_45w_45n
          VALUES LESS THAN (-45, 45)
If so, that answers the question of why it cannot find a partition, however an Oracle White Paper "Oracle Spatial Partitioning Best Practices" Sept 2004, discusses multi column partitioning such as represented by this problem, and gives an INSERT statement example of :
CREATE TABLE multi_partn_table (in_date DATE,
geom SDO_GEOMETRY, x_value NUMBER, y_value NUMBER)
PARTITION BY RANGE (X_VALUE,Y_VALUE)
PARTITION P_LT_90W_45S VALUES LESS THAN (1,-45),
PARTITION P_LT_90W_0 VALUES LESS THAN (1,0),
PARTITION P_LT_90W_45N VALUES LESS THAN (1,45),
PARTITION P_LT_90W_90N VALUES LESS THAN (1,MAXVALUE
and as I am writing this I am seeing that I failed to include the longitude and latitude in the SDO_GEOMETRY clause, so it does appear tht I need to explicitly state the longitude valuues.
What is your judgement sir?
Dave

How to add spatial information and property information in one transaction

Hi All:
I have a oracle spatial table and property table,they are joined by equal key fields.
I don't know how to realize to commit the spatial information and property information in one transaction.
How to realize it?
Thanks in advance.
zhimin

through triggers

Spatial index on table with object-column (and inheritance)

Hi!
Is it possible to create a spatial index on a table with an object-column (and inheritance) like this:
CREATE OR REPLACE TYPE feature_type AS OBJECT (
shape MDSYS.SDO_GEOMETRY
) NOT FINAL;
CREATE OR REPLACE TYPE building_type UNDER feature_type (
name VARCHAR2(50)
CREATE TABLE features ( no NUMBER PRIMARY KEY, feature feature_type);
[...] user_sdo_geom_metadata [...]
Then
CREATE INDEX features_idx ON features(feature.shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
throws:
ORA-01418: specified index does not exist
Curious! :)
If I define feature_type with "NOT FINAL" option but without subtypes, I get (create index):
ORA-00604: error occurred at recursive SQL level 1
ORA-01460: unimplemented or unreasonable conversion requested
So I think besides object tables also inheritance isn't supported whith oracle spatial!?
Thanks,
Michael
ps:
We use Oracle9i Enterprise Edition Release 9.0.1.4.0 / Linux.
Solves Oracle9i 9.2 this problems?

Hi
You'll need to be on 9.2 to do this....
Dom

CBO and spatial index

For a table with 2 million rows, with just ID=123 in the where clause it takes some msecs to return one row, but with a sdo_relate in the where clause, CBO checks both indexes, and if the spatial filter window is big, then can take 30 minutes to return.
This is the query:
SELECT g1.geometry
FROM STAGE1.PARCEL_GEOMETRIES g1
WHERE g1.id=123 and
(mdsys.sdo_relate (g1.geometry,:FilterGeometry, 'mask=ANYINTERACT querytype=window') = 'TRUE');
This is the plan:
SELECT STATEMENT ALL_ROWSCost: 2 Bytes: 32 Cardinality: 1
     8 TABLE ACCESS BY INDEX ROWID TABLE STAGE1.PARCEL_GEOMETRIES Cost: 2 Bytes: 32 Cardinality: 1
          7 BITMAP CONVERSION TO ROWIDS
               6 BITMAP AND
                    2 BITMAP CONVERSION FROM ROWIDS
                         1 INDEX RANGE SCAN INDEX STAGE1.PGM_PK Cost: 1 Cardinality: 1
                    5 BITMAP CONVERSION FROM ROWIDS
                         4 SORT ORDER BY
                              3 DOMAIN INDEX INDEX (DOMAIN) STAGE1.PGM_GMIDX Cost: 1 Cardinality: 1
When I put in a no_index hint to ignore spatial index, it returns right away:
SELECT /*+ NO_INDEX(g1 pgm_gmidx)*/ g1.geometry
FROM STAGE1.PARCEL_GEOMETRIES g1
WHERE g1.id=123 and
(mdsys.sdo_relate (g1.geometry,:FilterGeometry, 'mask=ANYINTERACT querytype=window') = 'TRUE');
Plan
SELECT STATEMENT ALL_ROWSCost: 1 Bytes: 32 Cardinality: 1
     2 TABLE ACCESS BY INDEX ROWID TABLE STAGE1.PARCEL_GEOMETRIES Cost: 1 Bytes: 32 Cardinality: 1
          1 INDEX RANGE SCAN INDEX STAGE1.PGM_PK Cost: 1 Cardinality: 1
My question is, why CBO chose to use spatial index while it knows only one row returned from id=123? With spatial index it can return 500,000 rows from sdo_relate. I do need the spatial index because for other cases it's being used. Is there anything I can do? Is this "work as design"?
Thanks!!

Thanks Bryan.
My database is 10.2.0.4. Although the problem is not the query is doing full table scan here. It's using spatial index. But problem is the attribute query, which in this case is "id=123", has cardinality 1, or 0, if the spatial query can use the 1 geometry return from "id=123", then it works very fast. But because spatial index is being used, so it takes a long time to run if the filter window is big.
In my test case I disabled the spatial index then it worked very fast. What I meant was, I couldn't use hint to disable spatial index to allow this scenario work fast because in other cases I do need the spatial index.
Thanks again!
Sharon

Error creating spatial indexes

I'm using oracle 10g2.
I retrieve the following error message during spatial index creation:
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-13236: internal error in R-tree processing: [failed to cluster in memory]
ORA-13232: failed to allocate memory during R-tree creation
ORA-13236: internal error in R-tree processing: [failed to allocate memory
4387752 (mdrtsalloc)]
ORA-04031: unable to allocate ORA-04031: unable to allocate 4387800 bytes of
shared memory ("large pool","unknown object","koh-kghu sessi","kpmalloc")
bytes of shared memory ("","","","")
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
I've already tried to increase memory, shared and large pool, actually I have the following settings:
Shared pool 500
Buffer cache 200
Large pool 200
Pool Java 20
I've already installed data and created spatial indexes on other machine correctly with the same data with less memory use, and I can't find any difference.
Could anybody help me?

Andre,
I didn't think the , and ; in the sdo_geom_metadata would be causing the problem because he indicated that he could build indexes on other data - I assume he uses the same diminfo values for these as well. But, one can never be too sure!
But certainly, follow what the error messages indicate.
The Oracle Error message manual says:
"ORA-13232: failed to allocate memory during R-tree creation
Cause: This feature assumes a minimum of 64K memory for bulk creation.
Action: Create the index for a small subset of the data. Then, use transactional insert operations for the rest of the data."
The spatial manual says:
"Before you create a spatial index, be sure that the rollback segment size and the SORT_AREA_SIZE parameter value are adequate, as described in Section 4.1.1."
One way to change the sort area size is to alter your existing session before
executing the create index statement. So, from 4.1.1. this can be done via:
ALTER SESSION SET SORT_AREA_SIZE = 20000000;
Also, do what Andre suggests. On my laptop with 1G of memory as a matter of course I change the SGA from the default to being much larger.
regards
S

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

Spatial Index and XA transaction

Similar Messages

Maybe you are looking for