Spatial Index Fragmentation

Hello,
We are facing a problem with spatial query performance on 10.2.0.5.
Apologies for limited information, I am still gathering information, but thought of asking this upfront.
What we have noticed is that queries involving SDO_ANYINTERACT runs slower say at about 8 secs. On Export/Import of data, the same query
runs in 0.5 secs.
Has anyone had a similar issue ? From the spatial index table I am not able identify if there is any fragmentation.
Pls let me know.
Rgds,
Gokul

Gokul,
You'll have to provide a lot more information to get a meaningful answer.
I haven't found any issues with spatial queries on 10.2.0.5.
- Can you supply us your SQL query, preferably with an execution plan?
- How many rows in the table?
- How many rows does the query return?
- Is the data in a projected coordinate system or not?
- What do you mean by Export/Import and what is different about the query run at that stage?
John

Similar Messages

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!

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.

Error when creating spatial index in 10g

Hello.
I have a problen when I try to create a spatial index. The strange thing is that the same commands always works fine in some machines, but if always fails in others. I tryed in diferent versiones of Oracle, but I have the error in al of them. The versions I have tryed are:
- 10.2.0.1
- 10.2.0.4
The operating systems are:
Windows XP professional 32 bits
Windows 2003 Server 32 bits
These are the steps i make:
1) Create a Table with a SDO_GEOMETRY column (GEOMETRY)
2) Load data with SQLLDR (I hve tryed different SRID's, and all fail)
So far everything is ok
3) Create the INDEX
When I execute the CREATE INDEX command CREATE INDEX MADRID_SX ON MADRID (GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
I obtain the error:
ERROR en linea 1:+
ORA-29855: se ha producido un error en la ejecucion de la rutina+
ODCIINDEXCREATE+
ORA-13282: fallo al inicializar la transformacion de coordenadas+
ORA-06512: en "MDSYS.SDO_INDEX_METHOD_10I", line 10+
I too have noticed that if I execute the next command, I have an error:
SELECT MDSYS.sdo_cs.transform(sdo_geometry(2001,8192,sdo_point_type(13.6,52.4,null),null,null),25830) from dual;
ERROR en linea 1:+
ORA-13282: fallo al inicializar la transformacion de coordenadas+
ORA-06512: en "MDSYS.SDO_CS", linea 75+
ORA-06512: en "MDSYS.SDO_CS", linea 112+
ORA-06512: en "MDSYS.SDO_CS", linea 2678+
And if I execute the next command, I too have another error:
SELECT SDO_CS.VALIDATE_WKT(25830) FROM DUAL;
FALSE (169)*
Any ideas? Could it be related with something inside the machines, user privileges, etc.?
Thanks in advance.

I have found that the problem is to use a SRID of AUTH_NAME column in MDSYS.CS_SRS table without the value "Oracle." in it.
If I use an Oracle’s SRID, everything works fine. If I use an EPSG’s SRID, fails.
For example, this command uses an Oracle SRID (8192) and one from the EPSG (25830), and fails:
SELECT MDSYS.sdo_cs.transform(sdo_geometry(2001,8192,sdo_point_type(13.6,52.4,null),null,null),25830) from dual;
ERROR en linea 1:
ORA-13282: fallo al inicializar la transformacion de coordenadas
ORA-06512: en "MDSYS.SDO_CS", linea 79
ORA-06512: en "MDSYS.SDO_CS", linea 116
ORA-06512: en "MDSYS.SDO_CS", linea 2690
However, if I use two Oracle SRID (8192 and 83030), it works.
SELECT MDSYS.sdo_cs.transform(sdo_geometry(2001,8192,sdo_point_type(13.6,52.4,null),null,null),83030) from dual;
SDO_GEOMETRY(2001, 83030, SDO_POINT_TYPE(1625183.71, 5936269.06, NULL), NULL, NULL
Therefore, the problem seems to be to use a non Oracle SRID.

Rebuilding spatial indexing fail after patch 9.2.0.8.0

Hi!
I did apply patchset, and after i did try to
set NLS_LANG=American_America.CL8MSWIN1251
sqlplusw ......
SQL> alter index XXXX.YYYYYYYY_g_idx rebuild; -- <- Russian name
alter index XXXX.YYYYYYYY_g_idx rebuild
ERROR at line 1:
ORA-29858: error occurred in the execution of ODCIINDEXALTER routine
ORA-29400: data cartridge error
¡a¤
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13205: internal error while parsing spatial parameters
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
ORA-06512: at line 1
As you can see, rebuilding was failed.
Before upgrade all did work fine.
If i will create table WITH_ENGLISH_NAME as SELECT from my table all working fine ;(
I DID apply all *.sql from patchset.
Any idea, gurus ?
P.S.
I did use script from metalink
verify_spatial_installation.sql :
SQL>
SQL> prompt Verify version and status
Verify version and status
SQL> select COMP_NAME, SCHEMA, VERSION, STATUS
2 from dba_registry where comp_id='SDO';
COMP_NAME SCHEMA VERSION STATUS
Spatial MDSYS 9.2.0.8.0 VALID
SQL>
SQL> prompt Number of objects
Number of objects
SQL> select count(*)
2 from dba_objects where owner='MDSYS';
COUNT(*)
250
SQL>
SQL> prompt Summary count of objects
Summary count of objects
SQL> select object_type, count(*)
2 from dba_objects where owner='MDSYS'
3 group by object_type;
OBJECT_TYPE COUNT(*)
FUNCTION 47
INDEX 17
INDEXTYPE 2
LIBRARY 12
LOB 12
OPERATOR 14
PACKAGE 25
PACKAGE BODY 25
SEQUENCE 2
TABLE 18
TRIGGER 7
TYPE 34
TYPE BODY 10
VIEW 25
14 rows selected.
SQL>
SQL> prompt Any invalid objects ?
Any invalid objects ?
SQL> select object_name, object_type, status
2 from dba_objects
3 where owner='MDSYS'
4 and status <> 'VALID'
5 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
SDO_MIGRATE PACKAGE BODY INVALID
SQL>
SQL> prompt List of all spatial objects ordered by object_name
List of all spatial objects ordered by object_name
SQL> select object_name, object_type, status
2 from dba_objects where owner='MDSYS'
3 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
AGGRCENTROID TYPE VALID
AGGRCENTROID TYPE BODY VALID
AGGRCONVEXHULL TYPE VALID
AGGRCONVEXHULL TYPE BODY VALID
AGGRLRSCONCAT TYPE VALID
AGGRLRSCONCAT TYPE BODY VALID
AGGRLRSCONCAT3D TYPE VALID
AGGRLRSCONCAT3D TYPE BODY VALID
AGGRMBR TYPE VALID
AGGRMBR TYPE BODY VALID
AGGRUNION TYPE VALID
AGGRUNION TYPE BODY VALID
ALL_GEOMETRY_COLUMNS VIEW VALID
ALL_SDO_GEOM_METADATA VIEW VALID
ALL_SDO_INDEX_INFO VIEW VALID
ALL_SDO_INDEX_METADATA VIEW VALID
ALL_SDO_LRS_METADATA VIEW VALID
ALL_SDO_MAPS VIEW VALID
ALL_SDO_STYLES VIEW VALID
ALL_SDO_THEMES VIEW VALID
CS_SRS TABLE VALID
DBA_GEOMETRY_COLUMNS VIEW VALID
DBA_SDO_INDEX_INFO VIEW VALID
DBA_SDO_INDEX_METADATA VIEW VALID
DBA_SDO_LRS_METADATA VIEW VALID
DBA_SDO_MAPS VIEW VALID
DBA_SDO_STYLES VIEW VALID
DBA_SDO_THEMES VIEW VALID
F81_INDEX_OBJECT TYPE VALID
F81_INDEX_OBJ_ARRAY TYPE VALID
F81_NT_IND_TYPE TYPE VALID
GEOCODER_HTTP PACKAGE VALID
GEOCODER_HTTP PACKAGE BODY VALID
GEOCODE_RESULT TYPE VALID
GEODETIC_SRIDS VIEW VALID
H81_INDEX_OBJECT TYPE VALID
H81_INDEX_OBJ_ARRAY TYPE VALID
H81_NT_IND_TYPE TYPE VALID
HHAND FUNCTION VALID
HHBYTELEN FUNCTION VALID
HHCBIT FUNCTION VALID
HHCELLBNDRY FUNCTION VALID
HHCELLSIZE FUNCTION VALID
HHCLDATE FUNCTION VALID
HHCOLLAPSE FUNCTION VALID
HHCOMMONCODE FUNCTION VALID
HHCOMPARE FUNCTION VALID
HHCOMPOSE FUNCTION VALID
HHDECODE FUNCTION VALID
HHDISTANCE FUNCTION VALID
HHENCODE FUNCTION VALID
HHENCODE_BYLEVEL FUNCTION VALID
HHGBIT FUNCTION VALID
HHGETCID FUNCTION VALID
HHGROUP FUNCTION VALID
HHGTBIT FUNCTION VALID
HHGTYPE FUNCTION VALID
HHIDLPART FUNCTION VALID
HHIDPART FUNCTION VALID
HHINCRLEV FUNCTION VALID
HHJLDATE FUNCTION VALID
HHLENGTH FUNCTION VALID
HHLEVELS FUNCTION VALID
HHMATCH FUNCTION VALID
HHMAXCODE FUNCTION VALID
HHNCOMPARE FUNCTION VALID
HHNDIM FUNCTION VALID
HHOR FUNCTION VALID
HHORDER FUNCTION VALID
HHPRECISION FUNCTION VALID
HHSBIT FUNCTION VALID
HHSETCID FUNCTION VALID
HHSTBIT FUNCTION VALID
HHSTYPE FUNCTION VALID
HHSUBDIVIDE FUNCTION VALID
HHSUBSTR FUNCTION VALID
HHXOR FUNCTION VALID
LOCATOR_WITHIN_DISTANCE OPERATOR VALID
MD PACKAGE VALID
MD PACKAGE BODY VALID
MD$RELATE TABLE VALID
MD1 PACKAGE VALID
MD1 PACKAGE BODY VALID
MD2 PACKAGE VALID
MD2 PACKAGE BODY VALID
MDERR PACKAGE VALID
MDERR PACKAGE BODY VALID
MDPRVT_IDX PACKAGE VALID
MDPRVT_IDX PACKAGE BODY VALID
MD_LRS PACKAGE VALID
MD_LRS PACKAGE BODY VALID
OGIS_GEOMETRY_COLUMNS TABLE VALID
OGIS_SPATIAL_REFERENCE_SYSTEMS TABLE VALID
ORDMD_AG_LIBS LIBRARY VALID
ORDMD_CS_LIBS LIBRARY VALID
ORDMD_IDX_LIBS LIBRARY VALID
ORDMD_LRS_LIBS LIBRARY VALID
ORDMD_MBR_LIBS LIBRARY VALID
ORDMD_MIG_LIBS LIBRARY VALID
ORDMD_PRIDX_LIBS LIBRARY VALID
ORDMD_REL_LIBS LIBRARY VALID
ORDMD_RTREE_LIBS LIBRARY VALID
ORDMD_UDT_LIBS LIBRARY VALID
ORDMD_UTL_LIBS LIBRARY VALID
ORDMD_WD_LIBS LIBRARY VALID
PK_SDO_MASK INDEX VALID
PK_SRID INDEX VALID
PRVT_IDX PACKAGE VALID
PRVT_IDX PACKAGE BODY VALID
RTREE_FILTER OPERATOR VALID
RTREE_IDX PACKAGE VALID
RTREE_IDX PACKAGE BODY VALID
RTREE_INDEX INDEXTYPE VALID
RTREE_INDEX_METHOD TYPE VALID
RTREE_INDEX_METHOD TYPE BODY VALID
RTREE_NN OPERATOR VALID
SAMPLE_SEQ SEQUENCE VALID
SDO PACKAGE VALID
SDO PACKAGE BODY VALID
SDOAGGR TYPE VALID
SDOAGGR TYPE BODY VALID
SDOAGGRTYPE TYPE VALID
SDO_3GL PACKAGE VALID
SDO_3GL PACKAGE BODY VALID
SDO_ADMIN PACKAGE VALID
SDO_ADMIN PACKAGE BODY VALID
SDO_AGGR_CENTROID FUNCTION VALID
SDO_AGGR_CONVEXHULL FUNCTION VALID
SDO_AGGR_LRS_CONCAT FUNCTION VALID
SDO_AGGR_LRS_CONCAT_3D FUNCTION VALID
SDO_AGGR_MBR FUNCTION VALID
SDO_AGGR_UNION FUNCTION VALID
SDO_ANGLE_UNITS TABLE VALID
SDO_AREA_UNITS TABLE VALID
SDO_CATALOG PACKAGE VALID
SDO_CATALOG PACKAGE BODY VALID
SDO_CONSTRUCT_DIM_ARRAY FUNCTION VALID
SDO_CS PACKAGE VALID
SDO_CS PACKAGE BODY VALID
SDO_DATUMS TABLE VALID
SDO_DIM_ARRAY TYPE VALID
SDO_DIM_ELEMENT TYPE VALID
SDO_DIST_UNITS TABLE VALID
SDO_DROP_USER TRIGGER VALID
SDO_ELEM_INFO_ARRAY TYPE VALID
SDO_ELLIPSOIDS TABLE VALID
SDO_FILTER OPERATOR VALID
SDO_GEOM PACKAGE VALID
SDO_GEOM PACKAGE BODY VALID
SDO_GEOMETRY TYPE VALID
SDO_GEOMETRY TYPE BODY VALID
SDO_GEOM_IDX INDEX VALID
SDO_GEOM_METADATA_TABLE TABLE VALID
SDO_GEOM_TRIG_DEL1 TRIGGER VALID
SDO_GEOM_TRIG_INS1 TRIGGER VALID
SDO_GEOM_TRIG_UPD1 TRIGGER VALID
SDO_IDX PACKAGE VALID
SDO_IDX PACKAGE BODY VALID
SDO_IDX_MDATA_IDX INDEX VALID
SDO_IDX_TAB_SEQUENCE SEQUENCE VALID
SDO_INDEX_METADATA_TABLE TABLE VALID
SDO_INDEX_METHOD_9I TYPE VALID
SDO_INDEX_METHOD_9I TYPE BODY VALID
SDO_INT2_FILTER OPERATOR VALID
SDO_INT2_RELATE OPERATOR VALID
SDO_INT_FILTER OPERATOR VALID
SDO_INT_RELATE OPERATOR VALID
SDO_LRS PACKAGE VALID
SDO_LRS PACKAGE BODY VALID
SDO_LRS_METADATA_TABLE TABLE VALID
SDO_LRS_META_IDX INDEX VALID
SDO_LRS_TRIG_DEL TRIGGER VALID
SDO_LRS_TRIG_INS TRIGGER VALID
SDO_LRS_TRIG_UPD TRIGGER VALID
SDO_MAPS_TABLE TABLE VALID
SDO_MBR TYPE VALID
SDO_META PACKAGE VALID
SDO_META PACKAGE BODY VALID
SDO_MIGRATE PACKAGE VALID
SDO_MIGRATE PACKAGE BODY INVALID
SDO_NN OPERATOR VALID
SDO_NN_DISTANCE OPERATOR VALID
SDO_NUMTAB TYPE VALID
SDO_ORDINATE_ARRAY TYPE VALID
SDO_POINT_TYPE TYPE VALID
SDO_PRIDX PACKAGE VALID
SDO_PRIDX PACKAGE BODY VALID
SDO_PROJECTIONS TABLE VALID
SDO_RELATE OPERATOR VALID
SDO_RELATEMASK_TABLE VIEW VALID
SDO_RELATE_MASK PACKAGE VALID
SDO_RELATE_MASK PACKAGE BODY VALID
SDO_RID_ARRAY TYPE VALID
SDO_RTREE_ADMIN PACKAGE VALID
SDO_RTREE_ADMIN PACKAGE BODY VALID
SDO_RTREE_FILTER OPERATOR VALID
SDO_RTREE_RELATE OPERATOR VALID
SDO_STAT TYPE VALID
SDO_STATTAB TYPE VALID
SDO_STYLES_TABLE TABLE VALID
SDO_THEMES_IDX INDEX VALID
SDO_THEMES_TABLE TABLE VALID
SDO_TUNE PACKAGE VALID
SDO_TUNE PACKAGE BODY VALID
SDO_UTIL PACKAGE VALID
SDO_UTIL PACKAGE BODY VALID
SDO_VERSION FUNCTION VALID
SDO_VPOINT_TYPE TYPE VALID
SDO_WITHIN_DISTANCE OPERATOR VALID
SPATIAL_INDEX INDEXTYPE VALID
SYS_C001565 INDEX VALID
SYS_C001571 INDEX VALID
SYS_C001706 INDEX VALID
SYS_LOB0000027008C00040$$ LOB VALID
SYS_LOB0000027008C00041$$ LOB VALID
SYS_LOB0000027053C00012$$ LOB VALID
SYS_LOB0000027053C00013$$ LOB VALID
SYS_LOB0000027209C00004$$ LOB VALID
SYS_LOB0000027216C00005$$ LOB VALID
SYS_LOB0000027216C00006$$ LOB VALID
SYS_LOB0000027216C00013$$ LOB VALID
SYS_LOB0000027216C00014$$ LOB VALID
SYS_LOB0000027229C00006$$ LOB VALID
SYS_LOB0000028651C00012$$ LOB VALID
SYS_LOB0000028651C00013$$ LOB VALID
TRANSFORM_MAP PACKAGE VALID
TRANSFORM_MAP PACKAGE BODY VALID
UNIQUE_ANGLE_UNITS INDEX VALID
UNIQUE_AREA_UNITS INDEX VALID
UNIQUE_DIST_UNITS INDEX VALID
UNIQUE_LAYERS INDEX VALID
UNIQUE_MAPS INDEX VALID
UNIQUE_STYLES INDEX VALID
UNIQUE_TABLES INDEX VALID
UNIQUE_THEMES INDEX VALID
USER_CS_SRS TABLE VALID
USER_GEOMETRY_COLUMNS VIEW VALID
USER_SDO_GEOM_METADATA VIEW VALID
USER_SDO_INDEX_INFO VIEW VALID
USER_SDO_INDEX_METADATA VIEW VALID
USER_SDO_LRS_METADATA VIEW VALID
USER_SDO_MAPS VIEW VALID
USER_SDO_STYLES VIEW VALID
USER_SDO_THEMES VIEW VALID
USER_TRANSFORM_MAP TABLE VALID
V81_INDEX_OBJECT TYPE VALID
V81_INDEX_OBJ_ARRAY TYPE VALID
V81_NT_IND_TYPE TYPE VALID
VERTEX_SET_TYPE TYPE VALID
VERTEX_TYPE TYPE VALID
250 rows selected.
SQL>
SQL> spool off

Sir! No Sir! :)
I will try to explain.
If I do have table with russian letter, than creating index creation will fail, no matter name of index :(
But if I will prepare copy of my table with english name (including meta-data) - index creations is succesfull.

Oracle 9 spatial index export/import

Hi,
when exporting/importing a user via exp/imp I encounter a problem with the numeric characters encoding during creation of a spatial index.
Imp tool produces script like this:
"BEGIN "
"execute immediate 'INSERT INTO USER_SDO_GEOM_METADATA values (''POINTS'',''GEOMETRY'',mdsys.SDO_dim_array(MDSYS.SDO_DIM_ELEMENT(''X'',50000000,160000000,,005),MDSYS.SDO_DIM_ELEMENT(''Y'',450000000,600000000,,005)),,005) ' ; "
"COMMIT; END;"
Problem is with wrong representation of the numeric value '0.005' as ,005.
Originally, the index was created via
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'points',
'geometry',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X',-125000000,-115000000, '0.005'),
MDSYS.SDO_DIM_ELEMENT('Y', 30000000, 42100000, '0.005')
NULL
Any hints how to reimport the index correctly?
Thanks,
Bogart

You might need to set the NLS_LANG environment variable to get character set conversion done on import (I don't know this unfortunately - it has never been a problem for me).
There is a section on character set conversions in the utilities manual.

ERROR creating spatial index

Hi all.
I have a problem during the creation of a spatial index for a table column.
The metadata is in the USER_SDO_GEOM_METADATA VIEW, but Oracle throws the message:
ORA-29855: se ha producido un error en la ejecución de la rutina ODCIINDEXCREATE
ORA-13203: fallo al leer la vista USER_SDO_GEOM_METADATA
ORA-13203: fallo al leer la vista USER_SDO_GEOM_METADATA
ORA-06512: en "MDSYS.SDO_INDEX_METHOD_10I", línea 10
The code that i use to create the index is:
DELETE FROM USER_SDO_GEOM_METADATA;
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'E011_CIUDADES',
'F011_GEO',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('Longitud', -180, 180, 10), -- 10 meters tolerance
MDSYS.SDO_DIM_ELEMENT('Latitud', -90, 90, 10) -- 10 meters tolerance
8307 -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system
CREATE INDEX IX_SPATIAL_011_GEO
ON SYSTEM.E011_CIUDADES(F011_GEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('tablespace=ASOUSU');
I will apreciate any help. Thanks.

This is very bad:
CREATE INDEX IX_SPATIAL_011_GEO ON SYSTEM.E011_CIUDADES(F011_GEO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('tablespace=ASOUSU');It means you've stored spatial data in the SYSTEM user's schema, which, as noted, is mucho malo. Either that, or it is a typo and that is why you got: fallo al leer la vista USER_SDO_GEOM_METADATA

ORA-03113 WITH CREATION OF A SPATIAL INDEX

Hello,
the creation of a spatial index with 11G database interrupts with:
ORA-03113 end-of-file on communication channel.
The table contains only point data, but has over 3.000.000 data records.
Has anyone an idea what to do?
Anna

Anna,
A couple of questions.
1 Does this happen all the time?
2 Can you select from table consistently?
3 How long does it take from issuing the command to getting the error?
The error is indicating a network timeout or similar.
Regards.
Ivan

Create a spatial index on a large table

Hi all
I think that I might be starting to push XE beyond what it is capable of, but I thought I would ask here to see if anyone has some ideas how to get around my problem.
I have a table with around 8,000,000 record in it. It has position data in it (SDO_GEOMETRY) which I would like to index. The geometry is not complex, just a single point for each record. The SQL I use is
CREATE INDEX "ANNOTATION_TEXT_SX" ON "ANNOTATION_TEXT" ("GEOLOC") INDEXTYPE IS "MDSYS"."SPATIAL_INDEX"
The command fails, due to memory issues. The errors thrown are
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 7272216 (mdrtsalloc)]
ORA-04031: unable to allocate ORA-04031: unable to allocate 7272264 bytes of shared memory ("lar
I have done a bit of reading up, this type of error generally occurs when the tablespace runs out of memory. Since I am using the SYSTEM tablespace, I figure I am running it out to its capacity before the index is completed.
I have not created any other tablespaces. Is this an option to allow the creation of the index? Storage and Memory are at about 60% capacity (due to this one table) so is it just too big to create a spatial index on in XE? Am I barking up the wrong tree?
Cheers
James

Good to see you are not using the SYSTEM tablespace. (And no need to apologize too profusely for being new at this - we all were at one time.)
It normally doesn't matter how many rows are involved. The issue is how much actual space those rows require. 8,000,000 rows is actually not a lot in the GIS world, esp. if all you have is simple point data. Using the sdo_point field instead of the arrays should be a lot more compact as well.
Some steps I would take:
- Identify the actual amount of space used, in total as well as by tablespace. (One of the web-based admin screens can show you this.)
- Load it all up usnig the free 'developer license' Enterprise Edition insead of XE just to verify it'll work.
- Try indexing a smaller data set and see whether that works. (Export the table first) Delete about 1/2 rows and try indexing.
The ORA-04031 is really telling you something about the SGA is not big enough. One of the SGA pools is trying to extend by 7M. Post the info about your SGA, as well ass some details about your machine (disk/processor/total memory)
Message was edited by:
forbrich
The actual error causing the problem is the last line. It ends with "la and the rest is cut off. Could it have said 'large pool'???

Numeric character problems when creating spatial index

Hi,
We have run into a problem when trying to create spatial indexes. The problem seems to be that an mdsys-procedure tries to use a number with a comma as decimal symbol in an update statement
Error message:
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: Stmt-Execute Failure: begin mdsys.prvt_idx.execute_update(NULL,NULL,'set sdo_rtree_quality = 1,00000000 where UPPER(sdo_index_owner) = UPPER(''BK'') AND UPPER(sdo_index_name)=UPPER(''TEST_RTREE_IDX'') AND UPPER(sdo_index_table)=UPPER(''MDRT_8120$'')',NULL); end;
ORA-29400: data cartridge error
ORA-01747: invalid user.table.column, table.column, or column specification
ORA-06512: at "MDSYS.PRVT_IDX", line 17
ORA-06512: at line 1
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Our problem seems to be identical to the one discussed in this thread: create RTREE falied on 9.2.0.4
Regional settings, language versions etc:
Client:
OS: Windows 2000
Regional options (OS): Swedish, Sweden
Sqlplus (console and windows versions): v 9.2.0.1.0
Registry: NLS_LANG =SWEDISH_SWEDEN.WE8MSWIN1252
Server:
OS: Windows Server 2003
Regional options (OS): Swedish, Sweden
Oracle: v 9.2.0.3.0
Registry: NLS_LANG =SWEDISH_SWEDEN.WE8MSWIN1252
We have also tried building the indexes after overriding these settings by setting the environment variables NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 on both the client- and the server computer. This gives exactly the same error. We have tried setting NLS_NUMERIC_CHARACTERS to '.,' instead of ',.', but this does not help either.
We haven't tried changing the NLS_LANG registry entry on the server, because this is a production server at a customer's site that hosts several other databases, so we would prefer not to have to restart it if we can avoid it. However, as we understand it, the environment variable NLS_LANG should override the registry setting anyway, right?
We first experienced the problem when trying to build indexes on imported data. To verify that the problem was not with the data, we wrote a simple test script that:
1)Creates a table
2)Creates metadata
3)Inserts a simple geometry
4)Tries to create an index
The error message above is from running this script. We have verified that the script
works ok on another database server.
Below are the values of some of the language parameters right before running the script
(we have tried many other settings with the same result).
parameter...........................db................................instance...............session
NLS_CHARACTERSET.......WE8MSWIN1252..................................................
NLS_LANGUAGE...............AMERICAN...................AMERICAN...........AMERICAN
NLS_NCHAR_CH...............AL16UTF16 ..........................................................
NLS_NCHAR_CONV... ......FALSE..........................FALSE..................FALSE..
NLS_NUMERIC_CH...---------.,---------------------------------------------------------------.,
NLS_TERRITORY..............AMERICA......................AMERICA..............AMERICA
The guy who started the thread referenced above solved the problem, but we haven't been able to get it working by changing registry entries and session parameters.
The question is: Which setting will make the number in 'set sdo_rtree_quality = 1,00000000...' be generated with a . instead of a , as decimal symbol?

Ok, so here is my plan to solve this:
1) Change the default user locale (the language under "standards and formats") to English for the account under which the Oracle server runs.
2) Reboot (or is there an easier way to make Oracle reload the settings?)
This should make the index creation work. It may break something else however, so to avoid this I can set the user locale back to Swedish afterwards .
You can subsequently change the setting and update the sdo_rtree_quality in
the metadata and it should work fine. Do you mean I have to update the sdo_rtree_quality in some way to make it work after I have changed the default user locale back to Swedish? How do I do this?
Thanks a million both of you!

How to view Index fragmentation in sap ecc6 ?

how to view Index fragmentation in sap ecc6 ?

Hi Haimiao,
You can use brtools to get required information. For relevant steps use the link below
https://help.sap.com/saphelp_nw04/helpdata/en/08/5742154ae611d1894f0000e829fbbd/content.htm
Regards,
Deepak Kori

Error in spatial index

Hi, everyone
I created a spatial index on a table, but i get the error message:
ORA-13033: the data in sdo_elem_info_array of sdo_geometry is unavailable
How can i write a SQL command to delete those unavailable records?

Hi,
here you find an example with a similar error. You simply can validate the spatial data, to find invalid records:
DROP   TABLE sdo_test;
CREATE TABLE sdo_test (
nr      NUMBER,
GEOM     MDSYS.SDO_GEOMETRY);
COMMIT;
--correct
INSERT INTO sdo_test VALUES (1,
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1),
    SDO_ORDINATE_ARRAY(-87.899771, 42.000853, 0, -87.899109, 42.000847, 54.8504622)));
--correct
INSERT INTO sdo_test VALUES (2,
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1),
    SDO_ORDINATE_ARRAY(-87.917489, 41.992077, 0, -87.917063, 41.99174, 51.4503307)));
--empty SDO_ELEM_INFO_ARRAY
INSERT INTO sdo_test VALUES (3,
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(),
    SDO_ORDINATE_ARRAY(-87.925704, 41.965994, 0, -87.925705, 41.965445, 60.9789892)));
DELETE FROM USER_SDO_GEOM_METADATA
WHERE TABLE_NAME = 'SDO_TEST' AND COLUMN_NAME = 'GEOM' ;
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('SDO_TEST', 'GEOM',
    MDSYS.SDO_DIM_ARRAY
      (MDSYS.SDO_DIM_ELEMENT('X', -87.925705, -87.8991090, 0.001),
       MDSYS.SDO_DIM_ELEMENT('Y', 41.965445, 41.9654450, 0.001),
       MDSYS.SDO_DIM_ELEMENT('M',    0.00000, 60.9789892, 0.001)
     ),8307);
--DROP   INDEX sdo_test_geom_spix;
--ORA ERROR 13033
CREATE INDEX sdo_test_geom_spix
          ON sdo_test(geom)
   INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS('sdo_indx_dims=2');
--find the invalid record
SELECT nr, SDO_GEOM.VALIDATE_GEOMETRY(geom,0.001) val
FROM sdo_test;
nr     val
1    TRUE
2    TRUE
3    13033
oops - where is the PREVIEW button in the new design ?!
In the meantime found the Syntax Highlighting (->Switch to the advanced editor, paste your code, mark it, click the >> (insert) button, select Syntax Highlighting, choose the style...>

Spatial Index Fragmentation

Similar Messages

Maybe you are looking for