Spatial Index on list partition?

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

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

Similar Messages

Domain index on list-partitioned table?

Hi,
I have a list-partitioned table, and wanted to create a partitioned Oracle Text index on it. I keep getting an error, and am now wondering if it's possible to do. Here is my syntax:
CREATE INDEX SCHEMA1.IDX_ALL_TEXT_LOCAL ON SCHEMA1.TABLE1(ALL_TEXT)
INDEXTYPE IS CTXSYS.CONTEXT
LOCAL
(PARTITION PTN1 PARAMETERS('sync (on commit) storage ptn1'),
PARTITION PTN2 PARAMETERS('sync (on commit) storage ptn2'),
PARTITION PTN3 PARAMETERS('sync (on commit) storage ptn3'),
PARTITION PTN4 PARAMETERS('sync (on commit) storage ptn4'),
PARTITION PTN5 PARAMETERS('sync (on commit) storage ptn5'),
PARTITION PTN6 PARAMETERS('sync (on commit) storage ptn6'),
PARTITION PTN7 PARAMETERS('sync (on commit) storage ptn7'),
PARTITION PTN8 PARAMETERS('sync (on commit) storage ptn8')
PARAMETERS('section group my_group lexer new_lexer');
ERROR at line 1:
ORA-29850: invalid option for creation of domain indexes
Any advice would be much appreciated.
Thanks,
Nora

... will it spread the index across the tablespaces that are associated with each partition?No, as demonstrated below.
SCOTT@orcl_11gR2> CREATE TABLE table1
2      ( id         NUMBER(6),
3        all_text      VARCHAR2 (20)
4      )
5 PARTITION BY LIST (id)
6   (PARTITION ptn1 VALUES (2,4) TABLESPACE example,
7    PARTITION ptn2 VALUES (3,9) TABLESPACE example
8   )
9 /
Table created.
SCOTT@orcl_11gR2> INSERT ALL
2 INTO table1 VALUES (2, 'test2')
3 INTO table1 VALUES (3, 'test3')
4 INTO table1 VALUES (4, 'test4')
5 INTO table1 VALUES (9, 'test9')
6 SELECT * FROM DUAL
7 /
4 rows created.
SCOTT@orcl_11gR2> CREATE INDEX IDX_ALL_TEXT_LOCAL
2 ON TABLE1 (ALL_TEXT)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 /
Index created.
SCOTT@orcl_11gR2> SELECT table_name, tablespace_name
2 FROM   user_tab_partitions
3 WHERE table_name = 'TABLE1'
4 /
TABLE_NAME                     TABLESPACE_NAME
TABLE1                         EXAMPLE
TABLE1                         EXAMPLE
2 rows selected.
SCOTT@orcl_11gR2> SELECT table_name, tablespace_name
2 FROM   user_tables
3 WHERE table_name LIKE '%IDX_ALL_TEXT_LOCAL%'
4 /
TABLE_NAME                     TABLESPACE_NAME
DR$IDX_ALL_TEXT_LOCAL$I        USERS
DR$IDX_ALL_TEXT_LOCAL$R        USERS
DR$IDX_ALL_TEXT_LOCAL$N
DR$IDX_ALL_TEXT_LOCAL$K
4 rows selected.
SCOTT@orcl_11gR2>

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

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

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

Create local spatial index on range sub-partitions?

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

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

Partitioned Spatial Indexes

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

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

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';

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.

Creating DOMAIN INDEX on INTERVAL PARTITIONING

Hi !
I hava a problem, and I hope someone can help me!
Two questions are asked below:
1. Main question: HOW CAN I SOLVE THIS PROBLEM, ARE THERE OTHER WAYS DOING THE SAME JOB (MAYBE FASTER) ?
2. Additionally: Is there a way to accelerate the deletion process
Step 1: Creating the table* For Information how I create the table:
CREATE TABLE LOC_EXAMPLE
COLUMN1 NUMBER
COLUMN2 NUMBER
COLUMN3 NUMBER
COLUMN4 NUMBER
START_TIME TIMESTAMP
GEOLOC MDSYS.SDO_GEOMETRY,
TABLESPACE DB_DATA
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING
PARTITION BY RANGE (START_TIME)
INTERVAL (NUMTODSINTERVAL(1,'DAY'))
PARTITION PART_LOC_EXAMPLE VALUES LESS THAN (TO_DATE('01-01-2008','dd-MM-yyyy'))
ALTER TABLE LOC_EXAMPLE
ADD CONSTRAINT PK_LOC_EXAMPLE PRIMARY KEY (COLUMN2,COLUMN4)
DELETE FROM USER_SDO_GEOM_METADATA VALUE WHERE TABLE_NAME = 'LOC_EXAMPLE'
INSERT INTO USER_SDO_GEOM_METADATA VALUES ('LOC_EXAMPLE','GEOLOC', MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('X',-180,180,0.001111949), MDSYS.SDO_DIM_ELEMENT('Y',-90,90,0.001111949) ), 8307)
STEP 2: I TRY TO CREATE SPATIAL INDEX (ITS A DOMAIN INDEX IF I'M NOT WRONG) ON PARTITIONED TABLE*
(PARTITIONED TABLE is an extension of range partitioning)
CREATE INDEX LOC_EXAMPLE_idx ON LOC_EXAMPLE'(GEOLOC)
INDEXTYPE IS MDSYS.SPATIAL_INDEX LOCAL;
THE SECOND STEP IS NOT POSSIBLE AS THE ORACLE DOCUMENTATION SAYS:
When using interval partitioning, consider the following restrictions:
-You can only specify one partitioning key column, and it must be of NUMBER or DATE type.
-Interval partitioning is not supported for index-organized tables.
-You cannot create a domain index on an interval-partitioned table.
1) I THINK IT IS IMPOSSIBLE FOR ME TO PASS ON INTERVAL PARTITIONING (AMOUNT OF DATA IS REALY BIG).
This partitioning is also used to delete datas from database once a mounth (scheduled on the basis of the partitions).
Is there a way to accelerate the deletion process?
2) I NEED A SPATIAL INDEX! NO WAY TO PASS ON IT!
HOW CAN I SOLVE THIS PROBLEM, ARE THERE OTHER WAYS DOING THE SAME JOB (MAYBE FASTER) ?
Why is it not possible to create a domain index on interval partitioning, any reason?
Will this be possible anytime?
I would be grateful to read any advise ...!
Thanking you in anticipation,
Ali

There is a forum here at OTN for spatial. Please delete the contents of this post and ask your question there. Thanks.

Spatial Index problems - Newbie here

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

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

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

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

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

Performance of Creating Spatial Indexes

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

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

List partitioning multi-org tables

Hi
I am doing list partitioning on receivables multi-org tables on org_id column. Running into a performance problem with multi org views. The multi-org views for receivables tables are defined like below with a nvl condition on org_id (partitioned column) in their where clause
create or replace ra_customer_trx
select select * from ra_customer_trx_all
WHERE NVL(ORG_ID,NVL(TO_NUMBER(DECODE(SUBSTRB(USERENV ('CLIENT_INFO'),1,1), ' ', NULL, SUBSTRB(USERENV ('CLIENT_INFO'),1,10))),-99)) = NVL(TO_NUMBER(DECODE(SUBSTRB(USERENV ('CLIENT_INFO'),1,1), ' ', NULL, SUBSTRB(USERENV ('CLIENT_INFO'),1,10))),-99)
Queries against the view are doing all partition scan when I exptected partition pruning to kick in and the query goes only against the spefific partition.
select count(1) from ra_customer_trx ---- does all partition scan
select count(1) from ra_customer_trx_all where org_id = <> ---- does single partition scan, works well.
When I recreate the view with out any function calls on the org_id column partition pruning happens.
In a non partitioned environment which has an index on org_id column, both the above sqls use the index and yield same result.
So my questions are -
1. Is there a way to get around this problem without having to modify the oracle supplied multi-org views? Any options I can supply in the partition script?
2. In a non-partitioned env, with an index on org_id how is the optmizer able to go against the index and where as it is not able to in partitioned environment..? Both these envs has the same view definition with NVL(org.......) consition.
Does anyone have any suggestions?
Thank you.

user2317378 wrote:
1. Is there a way to get around this problem without having to modify the oracle supplied multi-org views? Any options I can supply in the partition script?You mean to say that the expression used in the view belongs to some Oracle supplied schema, like APPS? Or is this a view you've created yourself?
Can you show us the output of EXPLAIN PLAN using DBMS_XPLAN.DISPLAY when querying the view? Use the \ tag before and after to use proper formatting in fixed font.
Please make sure that the "Predicate Information" section below the plan is also included in your post. If it is missing your plan table is old and needs to be upgraded using $ORACLE_HOME/rdbms/admin/utlxplan.sql or dropped if you're in 10g which provides a system wide PLAN_TABLE.
2. In a non-partitioned env, with an index on org_id how is the optmizer able to go against the index and where as it is not able to in partitioned environment..? Both these envs has the same view definition with NVL(org.......) consition.
These are two different questions. One is about partition pruning not taking place, the other one about an index not being used.
Can you show us the output of EXPLAIN PLAN using DBMS_XPLAN.DISPLAY when querying the unpartitioned example? Use the \ tag before and after to use proper formatting in fixed font.
Please make sure that the "Predicate Information" section below the plan is also included in your post. If it is missing your plan table is old and needs to be upgraded using $ORACLE_HOME/rdbms/admin/utlxplan.sql or dropped if you're in 10g which provides a system wide PLAN_TABLE.
It would be interesting to know how Oracle can use the index given the complex expression in the WHERE clause.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Insert using Spatial Index fails when called from PHP

I have a stored procedure that inserts into a table with a spatial index on one of its fields.
When I run the procedure from SQL Server Management Studio it runs just fine.
When I run it from PHP, it returns the error: "INSERT failed because the following SET options have incorrect settings: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes
on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations"
From within Management Studio, I have tried many different combinations of settings, until I wound up with the list I have in the procedure below.
Within Managment Studio the error changes based on the options I have set, but PHP always replies with: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'
I have configured PHP to use the same SQL user as management studio, and I have tried both mssql_query and mssql_execute with bound parameters.
The spatial index is on the field post.location If I remove the spatial index it works, but I need the spatial index.
CREATE PROCEDURE insert_post ( @subject AS VARCHAR(250), @body AS VARCHAR(2000), @latitude AS FLOAT, @longitude AS FLOAT ) AS BEGIN
SET NOCOUNT ON
SET ANSI_WARNINGS ON
SET ANSI_PADDING ON
SET CONCAT_NULL_YIELDS_NULL ON
SET NUMERIC_ROUNDABORT OFF
DECLARE @location AS geography = geography::Point(@latitude, @longitude, 4326)
INSERT INTO post
    subject,
    body,
    location
) VALUES (
    @subject,
    @body,
    @location
END

Hi Charles
Your issue looks like it have two basic sources: (1) The connection string properties, (2) The table structure and the data which you try to insert.
(1) The connection string properties can be specified in various ways.
You can set most of them during the connection, depending on the provider which you are using. We did not get from you any information about the PHP code, so we have no information regarding this part.
The connection properties can be changed after the connection was made, which is basically what you have try to do. But we don't know what properties
are differents (since you .. the PHP code..) but you can check those properties dynamically, insert them to a table and then compare. To check all the properties you can use this post:
http://ariely.info/Blog/tabid/83/EntryId/153/SQL-Server-Get-Connection-Properties.aspx
(2) We need to understand your
table structure and compare it to yours query. Please post your DDL+DML (queries to create the table and to insert some sample data), and the full SP code
as it is now.
[Personal Site] [Blog] [Facebook]

Performance of insert with spatial index

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

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

Slow spatial index creation

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

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

Spatial Index on list partition?

Similar Messages

Maybe you are looking for