Index creation -- question

Hi,
I have a question about creating indexes for my environment here
i have a table that gets populated with about 200 million rows everyday.
my table structure is as follows
(tab_id,orig_add,orig_nw,dest_add,dest_nw,ts_arrive,ts_leave,status,fn_type,error_code)
tab_id number
orig_add varchar2
dest_add varchar2
orig_nw number
dest_nw number
ts_arrive date
ts_leave date
status number -- (0 /1)
fn_type number -- (0/1/2/3/4/5)
errorcode -- (about 20 distinct values)
this table has been partitioned on ts_leave (hourly)
if i know i am going to be using a lot of queries with the where clause like :
orig_nw=something and dest_nw=something
can i have a local index on (orig_nw,dest_nw) ?
what about fields like status and errorcode and fn_type?, is a bitmap index suited for this?
while indexes are being created, i will also have to be reminded of the fact that a great number of inserts are being done every second
Please advise..thanks

Bitmaps are most beneficial if the status holds something like Booleans
either False or True , Y or N , 0 or 1 . Not wholly true. Read this article by Jonathan Lewis and enlighten yourself.
"Forget the vague expressions like "low cardinality." In most cases there are only two points to bear in mind when considering bitmap indexes. First, it is the number of different blocks in the table that you have to visit for a typical index value that is the major cost of using an individual index; changing an index from B*tree to bitmap won't magically make it a better index. Secondly, it is Oracle's optimiser mechanism for combining multiple bitmap indexes that makes them useful."
Cheers, APC

Similar Messages

Fast index creation suggestions wanted

Hi:
I've loaded a table with a little over 100,000,000 records. The table has several indexes which I must now create. Need to do this as fast as possible.
I've read the excellent article by Don Burleson (http://www.dba-oracle.com/oracle_tips_index_speed.htm) but still have a few questions.
1) If the table is not partitioned, does it still make sense to use "parallel"?
2) The digit(s) following "compress" indicate the number of consective columns at the head of the index that have duplicates. True?
3) How will the compressed index effect query performance (vs not compressed) down the line?
4) In the future I will be doing lots and lots of updates on the indexed columns of the records as well as lots of record deletes and inserts into/out-of the table. Will these updates/inserts/deletes run faster or slower given that the indexes are compressed vs if they were not?
5) In order to speed up the sorting, is it better to add datafiles to the TEMP table or create more TEMP tables (remember, running "parallel")
Thanks in Advance

There are people who would argue that excellent and Mr. Burleson do not belong in the same sentence.
1) Yes, you can still use parallel (and nologging) to create the index, but don't expect 20 - 30 times faster index creation.
2) It is the number of columns to compress by, they may not neccesarily have duplicates. For a unique index the default is number of columns - 1, for a non-unique index the default is the number of columns.
3) If you do a lot of range scans or fast full index scans on that index, then you may see some performance benefit from reading fewer blocks. If the index is mostly used in equality predicates, then the performance benefit will likely be minimal.
4) It really depends on too many factors to predict. The performance of inserts, updates and deletes will be either
A) Slower
B) The same
C) Faster
5) If you are on 10G, then I would look at temporary tablespace groups which can be beneficial for parallel operations. If not, then allocate as much memory as possible to sort_area_size to minimize disk sorts, and add space to your temporary tablespace to avoid unable to extend. Adding additional temporary tablespaces will not help because a user can only use one temporary tablespace at a time, and parallel index creation is only one user.
You might want to do some searching at Tom Kyte's site http://asktom.oracle.com for some more responsible answers. Tom and Don have had their disagreements in the past, and in most of them, my money would be on Tom to be corerct.
HTH
John

Index creation online - performance impact on database

hi,
I have oracle 11.1.0.7 database running on Linux as 3 node RAC.
I have a huge table which has more than 255 columns and is about 400GB in size which is also highly fragmented because of constant DML activities.
Questions:
1. For now i am trying to create an index Online while the business applications are running.
Will there be any performance impact on the database to create index Online on a single column of a table 'TBL' while applications are active against the same table? So basically my question will index creation on a object during DML operations on the same object have performance impact on the database? is there a major performance impact difference in the database in creating index online and not online?
2. I tried to build an index on a column which has NULL value on this same table 'TBL' which has more than 255 columns and is about 400GB in size highly fragmented and has about 140 million rows.
I requested the applications to be shutdown, but the index creation with parallel of 4 a least took more than 6 hours to complete.
We have a Pre-Prod database which has the exported and imported copy of the Prod data. So the pre-Prod is a highly de-fragmented copy of the Prod.
When i created the same index on the same column with NULL, it only took 15 minutes to complete.
Not sure why on a highly fragmented copy of Prod it took more than 6 hours compared to highly defragmented copy of Pre-Prod where the index creation took only 15 minutes.
Any thoughts would be helpful.
Thanks.
Phil.

How are you measuring the "fragmentation" of the table ?
Is the pre-prod database running single instance or RAC ?
Did you collect any workload stats (AWR / Statspack) on the pre-prod and production systems while creating (or failing to create) the index ?
Did you check whether the index creation ended up in-memory, single pass or multi pass in in the two environments ?
The commonest explanation for this type of difference is two-fold:
a) the older data needs a lot of delayed block cleanout, which results in a lot of random I/O to the undo tablespace - slowing down I/O generally
b) the newer end of the table is subject to lots of change, so needs a lot of work relating to read-consistency - which also means I/O on the undo system
-- UPDATED: but you did say that you had stopped the application so this bit wouldn't have been relevant.
On top of this, an online (re)build has to lock the table briefly at the start and end of the build, and in a busy system you can wait a long time for the locks to be acquired - and if the system has been busy while the build has been going on it can take quite a long time to apply the journal file to finish the index build.
Regards
Jonathan Lewis

Systemcopy using R3load - Index creation VERY slow

We exported a BW 7.0 system using R3load (newest tools and SMIGR_CREATE_DDL) and now importing it into the target system.
Source database size is ~ 800 GB.
The export was running a bit more than 20 hours using 16 parallel processes. The import is still running with the last R3load process. Checking the logs I found out that it's creating indexes on various tables:
(DB) INFO: /BI0/F0TCT_C02~150 created#20100423052851
(DB) INFO: /BIC/B0000530000KE created#20100423071501
(DB) INFO: /BI0/F0COPC_C08~01 created#20100423072742
(DB) INFO: /BI0/F0COPC_C08~04 created#20100423073954
(DB) INFO: /BI0/F0COPC_C08~05 created#20100423075156
(DB) INFO: /BI0/F0COPC_C08~06 created#20100423080436
(DB) INFO: /BI0/F0COPC_C08~07 created#20100423081948
(DB) INFO: /BI0/F0COPC_C08~08 created#20100423083258
(DB) INFO: /BIC/B0000533000KE created#20100423101009
(DB) INFO: /BIC/AODS_FA00~010 created#20100423121754
As one can see on the timestamps the creation of one index can take an hour or more.
x_cons is showing constant CrIndex reading in parallel, however, the througput is not more than 1 - 2 MB/sec. Those index creation processes are running now since over two days (> 48 hours) and since the .TSK files don't mentioned those indexes any more I wonder how many of them are to be created and how long this will take.
The whole import was started at "2010-04-20 12:19:08" (according to import_monitor.log) so running now since more than three days with four parallel processes. Target machine has 4 CPUs and 16 GB RAM (CACHE_SIZE is 10 GB). The machine is idling though with 98 - 99 %.
I have three questions:
- why does index creation take such a long time? I'm aware of the fact, that the cache may not be big enough to take all the data but that speed is far from being acceptable. Doing a Unicode migration, even in parallel, will lead to a downtime that may not be acceptable by the business.
- why are the indexes not created first and then filled with the data? Each savepoint may take longer but I don't think that it will take that long.
- how to find out which indexes are still to be created and how to estimate the avg. runtime of that?
Markus

i Peter,
I would suggest creating an SAP ticket for this, because these kind of problems are quite difficult to analyze.
But let me describe the index creation within MaxDB. If only one index creation process is active, MaxDB can use multiple Server Tasks (one for each Data Volume) to possibly increase the I/O throughput. This means the more Data Volumes you have configured, the faster the parallel index creation process should be. However, this hugely depends on your I/O system being able to handle an increasing amount of read/write requests in parallel. If one index creation process is running using parallel Server tasks, all further indexes to be created at that time can only utilize one single User Task for the I/O.
The R3load import process assumes that the indexes can be created fast, if all necessary base table data is still present in the Data Cache. This mostly applies to small tables up to table sizes that take up a certain amount of the Data Cache. All indexes for these tables are created right after the table has been imported to make use of the fact, that all the needed data for index creation is still in the cache. Many idexes may be created simultaneously here, but only one index at a time can use parallel Server Tasks.
If a table is too large in relation to the total database size, then its indexes are being queued for serial index creation to be started when all tables were imported. The idea is that the needed base table data would likely have been flushed out of the Data Cache already and so there is additional I/O necessary rereading that table for index creation. And this additional I/O would greatly benefit from parallel Server Tasks accessing the Data Volumes. For this reason, the indexes that are to be created at the end are queued and serialized to ensure that only one index creation process is active at a time.
Now you mentioned that the index creation process takes a lot of time. I would suggest (besides opening an OSS ticket) to start the MaxDB tool 'Database Analyzer' with an interval of 60 seconds configured during the whole import. In addition, you should activate the 'time measurement' to get a reading on the I/O times. Plus, ensure that you have many Data Volumes configured and that your I/O system can handle that additional loag. E.g. it would make no sense to have 25 Server Tasks all writing to a single local disk, I would assume that the disk would become a bottle neck...
Hope my reply was not too confusing,
Thorsten

Faster Context index creation!!

Hi Experts,
I am new to the concept of CONTEXT in Oracle and I havent worked on it. My problem is that we have monthly process of rebuilding the context index on a table ( varchar column). This process takes about 8hrs. When I created it the last time I increased the sort_area_size parameter for the session to 500M,increased sort_multiblock_read_count and db_file_multiblock_read_count depending upon the OS limitations,and the index was created in 4 hrs. But this is just DBA trick to do things faster and i beleive it can be done more faster.
Can anyone suggest me what are the ways of speeding up the index creation process from the CONTEXT perspective
,like increasing default memory with Ctx_Adm.Set_Parameter ( 'DEFAULT_INDEX_MEMORY', '500M'); .
Also having default_index_memory and sort_area_size as 500, will this take 1000M of memory during the index creation?
Also i read somewhere that before creating index truncating the table DR$INDEX_ERROR will help speeding index creation. Is this right? I think it should not make a difference .
Any suggestion on speeding up the index creation would be helpful. i cannot create the index in parallel as I am running Oracle 8.1.6 and base table is not partitioned.
Thanks.
Ankur

Sorry for posting this question here. I have put in on TEXT forum.

ORA-1652: Index creation error

At the time of table re-organisation, Index creation got aborted for the secondary index creation. then we have continued our activity leaving the index creation due to short of System downtime.
Again we have run the sql statment when the sap system is up, then it has thrown an error:
ORA-1652 unable to extend temp segment by 128 in tablespace PSAPTEMP.
In the current system, we are not ready to increase the size of datafile or resizing.where it leads to the increase the size of database.
Here we have option to create a new temp tablespace, will delete after index creation, but while doing this how do we point the new tablespace which is created for this activity.
SAP 4.6c oracle 9 sun solaris.
Kindly advise what can be done. reply ASAP

Martin,
We have discussed with the team like,
1. Create new temporary tablespace with desired Size which should be minimum 25GB
            CREATE temporary tablespace PSAPTEMP1......
    2. If the original tablespace is a default temporary tablespace, set the new tablespace as default temporary tablespace in the database.
             SQL> alter database default temporary tablespace PSAPTEMP1;
    3. Perform the index creation
    4. Make the old tablespace PSAPTEMP as the default temporary tablespace.
             SQL> alter database default temporary tablespace PSAPTEMP
   5. Drop the new tablespace.
             SQL> drop tablespace temp including contents.
Here I have a question, while switching the default temporary tablespace from PSAPTEMP to the much bigger new PSAPTEMP1Tablespace whether this will affect the running transaction.
Any impact on switching the tablespace online..?
We are performing this activity in the online system(running sap system)
Thanks,

Delete cube request - before or after index creation?

Hi Folks,
a quick question. I plan to delete for one cube requests that are older than 3 days (cube only hosts short term reporting). Now I wonder if this should be done aftter the new load but before the index is created or after the index is created.
I guess it is after the index is created otherwise it would take longer to find the requests that should be deleted. The index will be slighly degenerated due to the deletion but should be only marginal.
I am right or wrong?
Thanks for all replies in advance,
Axel

hi,
a quick question. I plan to delete for one cube requests that are older than 3 days (cube only hosts short term reporting). Now I wonder if this should be done aftter the new load but before the index is created or after the index is created.
The delete should be done before index creation, as once the index are created then even though the data corresponding to those index is deleted the index still remains. This unnecessarily increases the index table size
regards,
Arvind.

Help needed in index creation and its impact on insertion of records

Hi All,
I have a situation like this, and the process involves 4 tables.
Among the 4 tables, 2 tables have around 30 columns each, and the other 2 has 15 columns each.
This process contains validation and insert procedure.
I have already created some 8 index for one table, and an average of around 3 index on other tables.
Now the situation is like, i have a select statement in validation procedure, which involves select statement based on all the 4 tables.
When i try to run that select statement, it takes around 30 secs, and when checked for plan, it takes around 21k memory.
Now, i am in a situation to create new index for all the table for the purpose of this select statement.
The no.of times this select statement executes, is like, for around 1000 times of insert into table, 200 times this select statement gets executed, and the record count of these tables would be around one crore.
Will the no.of index created in a table impacts insert statement performace, or can we create as many index as we want in a table ? Which is the best practise ?
Please guide me in this !!!
Regards,
Shivakumar A

Hi,
index creation will most definitely impact your DML performance because when inserting into the table you'll have to update index entries as well. Typically it's a small overhead that is acceptable in most situations, but the only way to say definitively whether or not it is acceptable to you is by testing. Set up some tests, measure performance of some typical selects, updates and inserts with and without an index, and you will have some data to base your decision on.
Best regards,
Nikolay

Error while running index creation

Hi All ,
I am running index creation step like below .
alter session enable parallel DDL;
alter session set workarea_size_policy=manual;
alter session set sort_area_size=250000000;
alter session set db_file_multiblock_read_count=128;
CREATE INDEX "CUST_ROUTE_IDX" ON "CUST_2_K2K" ("PP2S", "KK2S")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING
STORAGE( INITIAL 5M
NEXT 16777216
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT)
TABLESPACE "INDX" PARALLEL 2;
when i am running like above i am getting following error..
CREATE INDEX "CUST_ROUTE_IDX" ON "CUST_ROUTE_IDX" ("PP2S", "KK2S")
**ERROR at line 1:**
**ORA-00604: error occurred at recursive SQL level 1**
**ORA-04031: unable to allocate 38410272 bytes of shared memory ("large**
**pool","SEQ$","QERHJ hash-joi","kllcqc:kllcqslt")**
DB is ORA 10gR2 installed on 8 cpu machine with 32 GB of RAM . From Unix Top command i can understand that 18GB of RAM is free.
When i remove "alter session set sort_area_size=250000000;" and run above script no error is coming .
But enough memory is availabe to the machine as per UNIX . Can any one help me out why this err is coming .
Also when I do " show parameter sort_area_size " in any new sqlplus session it displays 65536
This value is in bytes/KB/MB ...pls advice
Thanks in Advance

Please read any error message carefully, prior to posting.
**ORA-04031: unable to allocate 38410272 bytes of shared memory (*"large**
**pool"*,"SEQ$","QERHJ hash-joi","kllcqc:kllcqslt")**
Oracle is trying to allocate memory in the large pool, and the large pool is too small.
The sort_area_size has nothing to do with it.
Also there is no gain in setting the work_policy to manual, as Oracle will allocate memory beyond pga_aggregate_target automagically.
There is also no gain in setting db_file_multiblock_read_count, as Oracle will adjust that automagically.
Sort_area_size is in bytes, as documented, and it is your value in the spfile/init.ora which is the default or which you have set.
You can read about this in the documentation which is online at http://tahiti.oracle.com
Sybrand Bakker
Senior Oracle DBA

Index creation failed in Business Objects Explorer

Hi,
I installed the Business Objects Explorer ...
But I can not index anything.
When I try to index the following message appears:
"Server, DRWBI001.PolestarIndexing, generated messages The Following:
Index creation failed. File system Polestar exceptions occurred on the server. Search for Polestar ERROR Within the servers log file for more details. (Can not create directory C: \ Program Files \ Business Objects \ BusinessObjects Enterprise 12.0 \ win32_x86 \ \ Index \ DRWBI001.PolestarIndexing \ InProgress \ ExplorationIndexes \ 35e98114-4831-A254-8dad-497fd3d4bb26 \-30_10.09.41 2010-06. 564) "
What should I do? help me please

I do not have UNIVERSE.
I'm trying to index files like Microsoft excel.
I have to do some configuration in the CMC to be able to crawl in Business Objects Explorer?
What should I do to crawl in Business Objects Explorer?

CONTEXT index creation - performance!

Hi,
I have a table with about 5Million rows. The content that needs to be indexed is of RAW datatype. The average size (length) of this field is about 50 characters (it could be more).
I am trying to index this column to perform a keyword search. DEtails are furnished below.
table:
SQL> desc kwtai
Name Null? Type
TSD_HH24 DATE
COUNTRY_CODE_ALPHA_2 VARCHAR2(2)
ONETWORK NUMBER(6)
OADDRESS VARCHAR2(25)
DNETWORK NUMBER(6)
DADDRESS VARCHAR2(25)
MESSAGE_LENGTH NUMBER
MESSAGE_CONTENT RAW(2000)
Preferences:-
begin
Ctx_Ddl.Create_Preference('mc_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('mc_storage','I_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'K_TABLE_CLAUSE',
'tablespace large_index storage (initial 10M next 10M)');
ctx_ddl.set_attribute('mc_storage', 'R_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('mc_storage', 'N_TABLE_CLAUSE',
'tablespace large_index storage (initial 1M)');
ctx_ddl.set_attribute('mc_storage', 'I_INDEX_CLAUSE',
'tablespace large_index storage (initial 1M) compress 2');
ctx_ddl.create_preference('mc_lex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mc_lex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/.,');
ctx_ddl.set_attribute('mc_lex', 'INDEX_STEMS','NONE');
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters (' lexer mc_lex storage mc_storage memory 500M ')
parallel 16;
This create index takes about 4 hours to complete on a 8CPU dual core machine.
This is on Oracle 10g (10.2.0.4)
The reason i am creating the index as opposed to syncing it is because the data gets loaded into this table only once a day and it gets cleared once my keyword analysis is done.
Any pointers to speed up the index creation will be really appreciated! Thanks in advance!

My base table has the text that needs to be indexed stored in the "MESSAGE_CONTENT" column which for now is RAW data type. The data stored in this table are in hex representation.
Some examples -
MESSAGE_CONTENT
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69F16F
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461
616C70686120626574612067616D6D612064656C746120657073696C6F6E207A657461206E69C3B16F
6865792E2C2C77686174277320676F696E67206F6E2E2E2E7066206368616E67277320697320736F6D652072657374617572616E742E2074686579206172652070736564756F2D636F6F6C
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E
54686520477265656B20616C7068616265742069732074686520736372697074207468617420686173206265656E20706F73742D64617461
Now with your suggestion i tried to bypass this. So what i did was added a format column to my base table and updated it to "TEXT". My database is in UTF8.
Now when i create the index with the following preferences it takes less than a minute.
begin
Ctx_Ddl.Create_Preference('kwta_storage', 'BASIC_STORAGE');
ctx_ddl.set_attribute('kwta_storage','I_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'K_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 10M next 10M)');
ctx_ddl.set_attribute('kwta_storage', 'R_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) lob (data) store as (cache)');
ctx_ddl.set_attribute('kwta_storage', 'N_TABLE_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M)');
ctx_ddl.set_attribute('kwta_storage', 'I_INDEX_CLAUSE',
'tablespace TEXT_INDEX storage (initial 1M) compress 2');
ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
ctx_ddl.set_attribute('mylex', 'skipjoins', '_-"''`~!@#$%^&*()+=|}{[]\:;<>?/,');
ctx_ddl.set_attribute('mylex','punctuations','.?!');
ctx_ddl.set_attribute('mylex', 'INDEX_STEMS','NONE');
ctx_ddl.set_attribute('mylex', 'continuation','\-');
Ctx_Ddl.Create_Stoplist ( 'mystop' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'is' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'has' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'the' );
Ctx_Ddl.Add_Stopword ( 'mystop', 'that' );
end;
create index kwtaidx on kwtai (message_content) indextype is ctxsys.context
parameters ('filter ctxsys.auto_filter format column fmt stoplist mystop lexer mylex storage kwta_storage memory 500M')
parallel 16;
When i select distinct tokens from the $I table i get the following
TOKEN_TEXT
RESTAURANT
GREEK
WHATS
ARE
DELTA
ZETA
ALPHA
ALPHABET
EPSILON
PF
PSEDUOCOOL
SOME
CHANGS
NIÃO
ON
POSTDATA
SCRIPT
BEEN
GAMMA
GOING
HEY
NI
O
THEY
BETA
Now what i am also wondering is if the text (message_content column) is being converted to UTF8 (database characterset) by using AUTO_FILTER. Is my assumption correct? Not sure how to validate this?
And, would you kindly share of why RAW must not be used in this case?
Thanks for all your pointers!

Index creation of 0figl_o02 taking too long.

Hi,
we load data to a ODS 0FIGL_O02 approx .5 million records daily. and recreate the index using the function module - RSSM_PROCESS_ODS_CREA_INDEXES.
The index creation job used to last for 3 -4 hours six months ago. but now the job runs for 6 hours, is there a way to decrese the job time.
the no of records in the active table of ODS is 424 million.

hi,
this DSO is based on DS 0FI_GL_4 which is delta enabled.
Do you mean to say that you are receiving .5 million data daily?
if yes then there is not much that you can do, as the program will try to create the incremental index and will have to find the current index of 240 million records. One thing you can do is that as a regular Monthly activity you can completely delete the index of the cube and recreate it(this may take huge time but it would correct some of the corrupt indexes).
this below sap note might help you.
Note 1413496 - DB2-z/OS: BW: Building indexes on active DSO data
If you are not using to report or lookup on this DSO then please do not create secondary indexes.
regards,
Arvind.
Edited by: Arvind Tekra on Aug 25, 2011 5:18 PM

Spatial query index creation fails with ORA-13282: failure on initializatio

Hi,
I have an Oracle 10g 10.2.0.5.0 database newly installed. Spatial index creation fails:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13282: failure on initialization of coordinate transformation
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
The script I am trying to run is:
Insert into USER_SDO_GEOM_METADATA
(TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
Values
('SOME_TABLE', 'geo',
"SDO_DIM_ARRAY"(
"SDO_DIM_ELEMENT"('X',600000,900000,0.001),
"SDO_DIM_ELEMENT"('Y',150000,400000,0.001)), 23700);
CREATE INDEX IX_GEO_SOME_TABLE ON SOME_TABLE (GEO) INDEXTYPE IS MDSYS.SPATIAL_INDEX ;
Earlier I had some issues with NLS settings in relation to Spatial, but in this particular case setting the NLS_LANG for AMERICAN_AMERICA does not help. I found this comment http://www.orafaq.com/forum/t/127312/2/ but would not like to hack around with MDSYS table content. Any help is highly appreciated.
Regards, Tamas

Tamas,
1 . . .Are you indexing a table that already has geometries or an empty table?
. . . .If the former, do all the geometries in that table have the same (not NULL) SRID (23700)?
2 . .The link you posted suggests a parsing problem since in Hungarian (23700), the decimal seperator is a comma (not a period). Accordingly, I believe the edit to mdsys.sdo_cs_srs.WKTEXT would be:
PROJCS["HD72 / EOV", GEOGCS [ "HD72", DATUM ["Hungarian Datum 1972 (EPSG ID 6237)", SPHEROID ["GRS 1967 (EPSG ID 7036)", 6378160, 298,247167427]], PRIMEM [ "Greenwich", 0,000000 ], UNIT ["Decimal Degree", 0,01745329251994328]], PROJECTION ["Egyseges Orszagos Vetuleti (EPSG OP 19931)"], UNIT ["Meter", 1]]
^ ^ ^ Regards,
Noel

Strange: Conditional Error in Intermedia Text Index Creation

Hi All,
I am facing a strange error while creating the Intermedia Text index on 8.1.6 release for NT 4.0.
I have one database instance installed on the server. When i connect to Oracle through SQL plus as: connect username/password;
The index creation works fine!
But, if i connect using: username/password@servicename;
The index creation does not work!
The following error occurs.
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000:intermedia Text error:
ORA-50704:Net8 listener is not running or cannot start external procedures
ORA-28575:unable to open RPC connection to external procedure agent
ORA-12154:TNS:could not resolve service name
ORA-06512:at "CTXSYS.DRUE", line 126
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 54
ORA-06512:at line 1
Could anyone please help as to why it works without when connected without the service name but not otherwise?
Thanking you in advance!
Thanks and Regards
Anurag Agarwal

Hi All,
I am facing a strange error while creating the Intermedia Text index on 8.1.6 release for NT 4.0.
I have one database instance installed on the server. When i connect to Oracle through SQL plus as: connect username/password;
The index creation works fine!
But, if i connect using: username/password@servicename;
The index creation does not work!
The following error occurs.
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000:intermedia Text error:
ORA-50704:Net8 listener is not running or cannot start external procedures
ORA-28575:unable to open RPC connection to external procedure agent
ORA-12154:TNS:could not resolve service name
ORA-06512:at "CTXSYS.DRUE", line 126
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 54
ORA-06512:at line 1
Could anyone please help as to why it works without when connected without the service name but not otherwise?
Thanking you in advance!
Thanks and Regards
Anurag Agarwal

Index creation in BKPF table

Hello Gurus,
I have a bad performance in IDCP transaction, i read the sap note 511819 and this recommend create an index in BKPF table with fields:
'MANDT'
'BUKRS'
'XBLNR'
But i see in the system the table have an index with fields:
MANDT
BUKRS
BSTAT
XBLNR
Is necessary the index creation if already exists one index with this fields?
The table have 150 million rows and 9 indexes.
What is your suggestion?
Best regards,
Ernesto Castro.

HI,
If you have already index 001 with MANDT BUKRS BSTAT XBLNR
fields than it's not necessary to create another index with MANDT BUKRS XBLNR fields.
you need to create index 001 on following table only as described in note.
table : VBRK fields : MANDT XBLNR
table : LIKP fields: MANDT XBLNR
also activate this index only during the least critical time ( when maximum free resources available )
regards,
kaushal

Index creation -- question

Similar Messages

Maybe you are looking for