Spatial Index Advisor

Hi all,
Do you know why I got the following error when I try to use add a layer?
Server object could not be created: server object could not be initialized: Non supported character set:oracle-character-set-560
Thanks

Well, I installed Oracle 8i and I used English as the default character set. The spatial index advisor is working now, but for sure I can display the data stored in the attributes because Arabic is the language we are using in our database with a character set (AR8MSWIN1256).
I do not know if there is another way we can run Spatial Index Advisor.
null

Similar Messages

Oracle Spatial Index Advisor

Have tried to use subject and got an error when adding the table to analyze.
Error: Server object could not be created: server object could not be initialized: Non supported character set: oracle-character-set-171.
What's issue of this error? Does anyone know?

Hi Igor,
Not sure what the problem is.
This could be an NLS issue.
You might want to log a bug against
the Spatial Index Advisor with a small dump
file of your layer.
Also, can you make sure your entries
in USER_SDO_GEOM_METADATA are correct?
Thanks.
Dan

Spatial Index Advisor : Error

I get a couple of error messages in Spatial Index Advisor when trying to draw indexed geometries. The errors are:
"Server object could not be created: server object could not be initialized: ORA-29902: error in executing ODCIIndexStart() routine", and then;
"Initialization error: server object could not be initialized: ORA-29902: error in executing ODCIIndexStart() routine"
Previously I uploaded a MapInfo table containing polygons using Easyloader, but without generating any indexes. Using DBA Studio, I created a spatial index with the assistance of the Tiling Wizard. I can only assume that the index itself was created OK, as I received no error messages from that process.
Am I missing somthing in my installation of Oracle? What is ODCI? I am using the 8.1.6 version downloaded from technet.
Thanks in advance,
Jon
null

Thanks Dan,
I'll try your suggestion as soon as I can. First I just need to clarify a few other issues as well.
1. Does this mean that ODCI Indexing for Spatial is not necessarily incorrectly installed in my case? Put another way, is this just a problem with the Spatial Advisor, or does it go beyond that to the actual implementation of ODCI indexing in Spatial?
2. In one of my messages I alluded to the fact that I'd confirmed the problem using the Java API (meaning the 'SDOAPI'). In short, I formed an SQL statement requesting geometries for a specified window (SDO_FILTER), but got pretty much the same error relating to the 'ODCIIndexStart()' function. I'm not at home at the moment, so can't give you the details at this time. I think SQLPLus also reported the same error, leading me to conclude that it's a problem with the cartridge installation itself. Does the workaround that you suggested fix the problem for just the Spatial Advisor, or the SDO_FILTER operator in general? In essence, are you saying that ODCIIndexStart() (in Spatial) does not understand coordinate systems, or just the Spatial Advisor?
3. Is there a patch to fix this in the interim?
Sorry to be such a pain. It's just that I've been banging my head against the proverbial brick wall with this for a while. I was starting to think it was me not understanding something basic.
Regards,
Jon
null

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.

Question about "Spatial Index Advisor"

I'm now using "Oracle8i Enterprise Edition 8.1.6" and "Oracle8i Enterprise Manager 2.1" for Windows NT/2000. I tried to use the extended administration tool of the Manager "Spatial Index Advisor" to access my spatial data. I can see the layers in the "Add layer" Dialog. But when I want to add a layer, it popup a failed message box said "Server object could not be created:Server object could not be initialized:Not be supported charaterset:oracle-characterset-852". Why? And how can I solve the problem?

Hi Dinghy,
The Oracle 8.1.6 sdo advisor is only implemented for the US7ASCII character set.
The Oracle 8.1.7 release of the advisor does have NLS support.
Hope this helps. Thanks.
Dan
null

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

Spatial Index Advisor

Similar Messages

Maybe you are looking for