Index creation time

Hi,
Could anyone point me in the right direction? How much time would it take to create new index on a column in a warehouse table containing 1.3 million records?
Does creating unique index take more time?

Hi,
Well, I think it depends of many "variables" ... Why don't you make a test and tell us?
LEGATTI@ORACLE10> create table test as select rownum id from dual connect by rownum < 1300000;
Table created.
LEGATTI@ORACLE10> commit;
Commit complete.
LEGATTI@ORACLE10> select count(*) from test;
COUNT(*)
1300000
LEGATTI@ORACLE10> set timing on
LEGATTI@ORACLE10> create unique index i_test on test (id);
Index created.
Elapsed: 00:00:07.51Cheers
Legatti

Similar Messages

CREATE TABLE/INDEX execution times

Hello,
what are my options to optimize table and/or index creation times?
I have a script that creates something around 60 000 objects (maybe half index, half table) and while each operation takes no more than a second, this will result in a 17 hour execution time. So I'm looking for ways to decrease table creation by a fraction of a second :-/
What I can think of is that all of these operations end up writing to the same datafile (e.g. SYSTEM01.DBF), could it do any good to divide the system tablespace into more data files? Adding a datafile would only increase the quota, so I would have to regroup the data?
Or can I increase the number of redologs? Or temporarily add larger redolog files?
Here is an extract to demonstrate:
14:20:10 SQL> DROP TABLE PS_DOTL_PDS2_T2
14:20:10   2 /
Table dropped.
14:20:11 SQL> CREATE TABLE PS_DOTL_PDS2_T2 (PROCESS_INSTANCE DECIMAL(10) NOT NULL,
14:20:11   2           BUSINESS_UNIT VARCHAR2(5) NOT NULL,
14:20:11   3           PO_ID VARCHAR2(10) NOT NULL,
14:20:11   4           LINE_NBR INTEGER NOT NULL,
14:20:11   5           SCHED_NBR SMALLINT NOT NULL,
14:20:11   6           DISTRIB_LINE_NUM INTEGER NOT NULL,
14:20:11   7           BUSINESS_UNIT_REQ VARCHAR2(5) NOT NULL,
14:20:11   8           REQ_ID VARCHAR2(10) NOT NULL,
14:20:11   9           REQ_LINE_NBR INTEGER NOT NULL,
14:20:11 10           REQ_SCHED_NBR SMALLINT NOT NULL,
14:20:11 11           REQ_DISTRIB_NBR INTEGER NOT NULL,
14:20:11 12           ACCOUNT VARCHAR2(10) NOT NULL,
14:20:11 13           OPERATING_UNIT VARCHAR2(8) NOT NULL,
14:20:11 14           PRODUCT VARCHAR2(6) NOT NULL,
14:20:11 15           FUND_CODE VARCHAR2(5) NOT NULL,
14:20:11 16           CLASS_FLD VARCHAR2(5) NOT NULL,
14:20:11 17           PROGRAM_CODE VARCHAR2(5) NOT NULL,
14:20:11 18           BUDGET_REF VARCHAR2(8) NOT NULL,
14:20:11 19           AFFILIATE VARCHAR2(5) NOT NULL,
14:20:11 20           AFFILIATE_INTRA1 VARCHAR2(10) NOT NULL,
14:20:11 21           AFFILIATE_INTRA2 VARCHAR2(10) NOT NULL,
14:20:11 22           CHARTFIELD1 VARCHAR2(10) NOT NULL,
14:20:11 23           CHARTFIELD2 VARCHAR2(10) NOT NULL,
14:20:11 24           CHARTFIELD3 VARCHAR2(10) NOT NULL,
14:20:11 25           PROJECT_ID VARCHAR2(15) NOT NULL,
14:20:11 26           ALTACCT VARCHAR2(10) NOT NULL,
14:20:11 27           DEPTID VARCHAR2(10) NOT NULL,
14:20:11 28           MONETARY_AMOUNT DECIMAL(26, 3) NOT NULL,
14:20:11 29           DISTRIB_AMT DECIMAL(26, 3) NOT NULL,
14:20:11 30           PO_DT DATE,
14:20:11 31           CURRENCY_CD VARCHAR2(3) NOT NULL,
14:20:11 32           KK_CLOSE_PRIOR VARCHAR2(1) NOT NULL,
14:20:11 33           PO_STATUS VARCHAR2(2) NOT NULL,
14:20:11 34           MID_ROLL_STATUS VARCHAR2(1) NOT NULL,
14:20:11 35           CURRENCY_CD_BASE VARCHAR2(3) NOT NULL,
14:20:11 36           RT_TYPE VARCHAR2(5) NOT NULL) TABLESPACE PSAPP STORAGE (INITIAL
14:20:11 37   40000 NEXT 100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10
14:20:11 38   PCTUSED 80
14:20:11 39 /
Table created.
14:20:11 SQL> CREATE UNIQUE iNDEX PS_DOTL_PDS2_T2 ON PS_DOTL_PDS2_T2
14:20:11   2   (PROCESS_INSTANCE,
14:20:11   3           BUSINESS_UNIT,
14:20:11   4           PO_ID,
14:20:11   5           LINE_NBR,
14:20:11   6           SCHED_NBR,
14:20:11   7           DISTRIB_LINE_NUM,
14:20:11   8           BUSINESS_UNIT_REQ,
14:20:11   9           REQ_ID,
14:20:11 10           REQ_LINE_NBR,
14:20:11 11           REQ_SCHED_NBR,
14:20:11 12           REQ_DISTRIB_NBR) TABLESPACE PSINDEX STORAGE (INITIAL 40000 NEXT
14:20:11 13   100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10 PARALLEL
14:20:11 14   NOLOGGING
14:20:11 15 /
Index created.
14:20:11 SQL> ALTER INDEX PS_DOTL_PDS2_T2 NOPARALLEL LOGGING
14:20:11   2 /
Index altered.
14:20:11 SQL> DROP TABLE PS_DOTL_PDS2_T3
14:20:11   2 /
Table dropped.
14:20:12 SQL> CREATE TABLE PS_DOTL_PDS2_T3 (PROCESS_INSTANCE DECIMAL(10) NOT NULL,
14:20:12   2           BUSINESS_UNIT VARCHAR2(5) NOT NULL,
14:20:12   3           PO_ID VARCHAR2(10) NOT NULL,
14:20:12   4           LINE_NBR INTEGER NOT NULL,
14:20:12   5           SCHED_NBR SMALLINT NOT NULL,
14:20:12   6           DISTRIB_LINE_NUM INTEGER NOT NULL,
14:20:12   7           BUSINESS_UNIT_REQ VARCHAR2(5) NOT NULL,
14:20:12   8           REQ_ID VARCHAR2(10) NOT NULL,
14:20:12   9           REQ_LINE_NBR INTEGER NOT NULL,
14:20:12 10           REQ_SCHED_NBR SMALLINT NOT NULL,
14:20:12 11           REQ_DISTRIB_NBR INTEGER NOT NULL,
14:20:12 12           ACCOUNT VARCHAR2(10) NOT NULL,
14:20:12 13           OPERATING_UNIT VARCHAR2(8) NOT NULL,
14:20:12 14           PRODUCT VARCHAR2(6) NOT NULL,
14:20:12 15           FUND_CODE VARCHAR2(5) NOT NULL,
14:20:12 16           CLASS_FLD VARCHAR2(5) NOT NULL,
14:20:12 17           PROGRAM_CODE VARCHAR2(5) NOT NULL,
14:20:12 18           BUDGET_REF VARCHAR2(8) NOT NULL,
14:20:12 19           AFFILIATE VARCHAR2(5) NOT NULL,
14:20:12 20           AFFILIATE_INTRA1 VARCHAR2(10) NOT NULL,
14:20:12 21           AFFILIATE_INTRA2 VARCHAR2(10) NOT NULL,
14:20:12 22           CHARTFIELD1 VARCHAR2(10) NOT NULL,
14:20:12 23           CHARTFIELD2 VARCHAR2(10) NOT NULL,
14:20:12 24           CHARTFIELD3 VARCHAR2(10) NOT NULL,
14:20:12 25           PROJECT_ID VARCHAR2(15) NOT NULL,
14:20:12 26           ALTACCT VARCHAR2(10) NOT NULL,
14:20:12 27           DEPTID VARCHAR2(10) NOT NULL,
14:20:12 28           MONETARY_AMOUNT DECIMAL(26, 3) NOT NULL,
14:20:12 29           DISTRIB_AMT DECIMAL(26, 3) NOT NULL,
14:20:12 30           PO_DT DATE,
14:20:12 31           CURRENCY_CD VARCHAR2(3) NOT NULL,
14:20:13 32           KK_CLOSE_PRIOR VARCHAR2(1) NOT NULL,
14:20:13 33           PO_STATUS VARCHAR2(2) NOT NULL,
14:20:13 34           MID_ROLL_STATUS VARCHAR2(1) NOT NULL,
14:20:13 35           CURRENCY_CD_BASE VARCHAR2(3) NOT NULL,
14:20:13 36           RT_TYPE VARCHAR2(5) NOT NULL) TABLESPACE PSAPP STORAGE (INITIAL
14:20:13 37   40000 NEXT 100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10
14:20:13 38   PCTUSED 80
14:20:13 39 /
Table created. It's a PeopleSoft database, during one of the upgrade steps, running on Oracle 11.2.0.3, Windows patchset #17 I believe. (Win2008R2_64)
As always any input or references are greatly appreciated.
Best regards.

Hi,
See bellow. You can create deferred segment creation option of Oracle. Oracle will not spend time on extent allocation and can save you enormous amount of time overall.
http://www.oracle-base.com/articles/11g/segment-creation-on-demand-11gr2.php
What I can think of is that all of these operations end up writing to the same datafile (e.g. SYSTEM01.DBF), could it do any good to divide the system tablespace into more data files? >Adding a datafile would only increase the quota, so I would have to regroup the data?Why giving example of SYSTEM01.DBF? You should not be using system tablespace. Having multiple datafiles will not be helping you.
What do you mean by regroup of data?
Salman
Edited by: Salman Qureshi on Apr 10, 2013 4:02 PM

Parallel Index creation takes more time...!!

OS - Windows 2008 Server R2
Oracle - 10.2.0.3.0
My table size is - 400gb
Number of records - 657,45,95,123
my column definition first_col varchar2(22) ; -> I am creating index on this column
first_col -> actual average size of column value is 10
I started to create index on this column by following command
CREATE INDEX CALL_GROUP1_ANO ON CALL_GROUP1(A_NO) LOCAL PARALLEL 8 NOLOGGING COMPRESS ;
-> In my first attempt after three hours I got an error :
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
So I increased the size of temp tablespace to 380GB ,Because i expect the size of first_col index this much.
-> In my second attempt Index creation is keep going even after 17 hours...!!
Now the usage of temp space is 162 GB ... still it is growing..
-> I checked EM Advisor Central ADDM :
it says - The PGA was inadequately sized, causing additional I/O to temporary tablespaces to consume significant database time.
1. why this takes this much of Temp space..?
2. It is required this much of time to CREATE INDEX in parallel processing...? more than 17 hrs
3. How to calculate and set the size of PGA..?

OraFighter wrote:
Oracle - 10.2.0.3.0
My table size is - 400gb
Number of records - 657,45,95,123
my column definition first_col varchar2(22) ; -> I am creating index on this column
first_col -> actual average size of column value is 10
I started to create index on this column by following command
CREATE INDEX CALL_GROUP1_ANO ON CALL_GROUP1(A_NO) LOCAL PARALLEL 8 NOLOGGING COMPRESS ;
Now the usage of temp space is 162 GB ... still it is growing..The entire data set has to be sorted - and the space needed doesn't really vary with degree of parallelism.
6,574,595,123 index entries with a key size of 10 bytes each (assuming that in your choice of character set one character = one byte) requires per row approximately
4 bytes row overhead 10 bytes data, 2 bytes column overhead for data, 6 bytes rowid, 2 bytes column overhead for rowid = 24 bytes.
For the sorting overheads, using the version 2 sort, you need approximately 1 pointer per row, which is 8 bytes (I assumed you're on 64 bit Oracle on this platform) - giving a total of 32 bytes per row.
32 * 6,574,595,123 / 1073741824 = 196 GB
You haven't said how many partitions you have, but you might want to consider creating the index unusable, then issuing a rebuild command on each partition in turn. From "Practical Oracle 8i":
<blockquote>
In the absence of partitioned tables, what would you do if you needed to create a new index on a massive data set to address a new user requirement? Can you imagine the time it would take to create an index on a 450M row table, not to mention the amount of space needed in the temporary segment. It's the sort of job that you schedule for Christmas or Easter and buy a couple of extra discs to add to the temporary tablespace.
With suitably partitioned tables, and perhaps a suitably friendly application, the scale of the problems isn't really that great, because you can build the index on each partition in turn. This trick depends on a little SQL feature that appears to be legal even though I haven't managed to find it in the SQL reference manual:
     create index big_new_index on partitioned_table (colX)
     local
     UNUSABLE
     tablespace scratchpad
The key word is UNUSABLE. Although the manual states that you can 'alter' an index to be unusable, it does not suggest that you can create it as initially unusable, nevertheless this statement works. The effect is to put the definition of the index into the data dictionary, and allocate all the necessary segments and partitions for the index - but it does not do any of the real work that would normally be involved in building an index on 450M rows.
</blockquote>
(The trick was eventually documented a couple of years after I wrote the book.)
Regards
Jonathan Lewis

Time, more taken in index creation

when i create an normal index on one column or an composite index on 3-4 columns on a table having say 9-10 million records, the time is too much, i did it in our test database & it too upto an hour to create the index. Please help in explaining, why it is taking so much time.
regards.

Well it depends what you consider the time should be. Indexing a table of 10m records is going to take time but to speed things up a bit you could specify NOLOGGING in the index creation script, you should take a backup afterwards though.
HTH
David

Index creation a long time..Please help to tune the creation time.

Hi all,
I am creating a index after using impdp to put the data in that table.
Below is my index creation command.The index creation takes ~30 minutes .
Can the forum memebers suggest me how to put this index creation with parallel clause or otherwise to reduce the time it takes to create the index?
+++++++++++++++++++++++++++++++++++++++++++++++
spool incre_HUNTER_PK_1.log
set lines 200 pages 0 echo on feedback on timing on time on
alter session enable parallel dml;
alter session enable parallel ddl;
CREATE UNIQUE INDEX "HUNTER_PK" ON "HUNTER" ("HUNTER_NUM", "BILL_SEQ", "BILL_VERSION")
PCTFREE 10 INITRANS 2 MAXTRANS 255 NOLOGGING COMPUTE STATISTICS
STORAGE(INITIAL 4294967296 NEXT 16777216 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "HUNTER_LARGE_02";
ALTER TABLE HUNTER ADD PRIMARY KEY ("HUNTER_NUM", "BILL_SEQ", "BILL_VERSION") USING INDEX HUNTER_PK;
ALTER INDEX "HUNTER_PK" NOLOGGING NOPARALLEL;
spool off
+++++++++++++++++++++++++++++++++++++++++++++++
Some other details:
1. My imdp command import nearly the below details
. . imported "HUSTY"."HUNTER" 42.48 GB 218185783 rows
2. It is a non-partitioned table.
3. I cant drop the table at the target.
Regds,
Kunwar

Kunwar wrote:
Can the forum memebers suggest me how to put this index creation with parallel clause or otherwise to reduce the time it takes to create the index?
What version of the database?
Creating indexes in parallel is described in the documentation. Search the on-line documentation for the syntax for create index; if there aren't any specific examples of creating indexes in parallel do a Google search for "create index parallel"

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

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

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

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

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

Why index creation is slower on the new server?

Hi there,
Here is a bit of background/env info:
Existing prod server (physical): Oracle 10gR2 10.2.0.5.8 on ASM
RAM: 96GB
CPUs: 8
RHEL 5.8 64bit
Database size around 2TB
New server:
VMWare VM with Oracle 10gR2 10.2.0.5.8 on ASM
RAM 128GB
vCPUs: 16
RHEL 5.8 64bit
Copy of prod DB (from above server) - all init param are the same
I noticed that Index creation is slower on this server. I ran following query:
SELECT name c1, cnt c2, DECODE (total, 0, 0, ROUND (cnt * 100 / total)) c3
FROM (SELECT name, VALUE cnt, (SUM (VALUE) OVER ()) total
FROM v$sysstat
WHERE name LIKE 'workarea exec%')
C1
C2
C3
workarea executions - optimal
100427285
100
workarea executions - onepass
2427
0
workarea executions - multipass
0
0
Following bitmap index takes around 40mins in prod server while it takes around 2Hrs on the VM.
CREATE BITMAP INDEX MY_IDX ON
MY_HIST(PROD_YN) TABLESPACE TS_IDX PCTFREE 10
STORAGE(INITIAL 12582912 NEXT 12582912 PCTINCREASE 0 ) NOLOGGING
This index is created during a batch-process and the dev team is complaining of slowness of the batch on new server. I have found this one statement responsible for some of the grief. There may be more and I am investigating.
I know that adding "parallel" option may speedup but I want find out why is it slow on the new server.
I tried creating a simple index on a large table and it took 2min in prod and 3.5min on this VM. So I guess index creation is slower on this VM in general. DMLs (select/insert/delete/update) seem to work with better elapsed time.
Any clues what might be causing this slowness in index creation?
Best regards

I have been told that the SAN in use by the VM has capacity of 10K IOPS. Not sure of this info helps. I don't know more than this about the storage.
What else do I need to find out? Please let me know - I'll check with my Sys Admin and update the thread.
Best regards

After index creation infocube is very slow! (don't produce result)

Hello all,
       I have the following problem, on a single cube ZWLPIANIF, after the index creation from manage of cube, the query on this cube is totally unusable because during a lot of time (it's necessary stop the execution) I whait over 30 minutes. When I delete the index the query work fine a little bit slow compared to another cube that have index.
ZWLPIANIF have 1,200,000 record loaded in FULL
from RSPC we made the following step:
deletion index
loading
creation index, the job of creation is completed successfully (in SM21 no log, in ST22 no dump, in SM37 is ok).
This is the details of our system SAP NetWeaver 2004s:
SAP_ABA     700     0016     SAPKA70016
SAP_BASIS     700     0016     SAPKB70016
ST-PI     2008_1_700     0000          -
PI_BASIS     2006_1_700     0006     SAPKIPYM06
SAP_BW     700     0018     SAPKW70018
FINBASIS     600     0013     SAPK-60013INFINBASIS
SEM-BW     600     0013     SAPKGS6013
BI_CONT     703     0011     SAPKIBIIQ1
ST-A/PI     01L_BCO700     0000          -
everyone have some ideas?
REGARDS
Gianvito

Hi,
You can analyse/debug the query through RSRT in execute+debug mode and please check wether the database optimiser chooses the right index that means wether statistics are updated or not.
You can do a reorganise of indexes as well.
Thank you,
Tilak

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

Index creation; What should the ideal process be?

DB Version:11g R1
I maintain a db related to retailing and wareshousing. Last week, i issued a CREATE INDEX statement at around 8:00 pm which is a 'not so busy time' for DB and applications. But the temp tablespace ran out of space during this exercise. It was a nightmare.
Now, we have decided to follow a standardized process followed by experienced Oracle DBA professionals in the Industry. So, we would like to know what process you guys would follow if you are asked to CREATE or REBUILD Indexes.

I maintain a db related to retailing and wareshousing. Last week, i issued a CREATE INDEX statement at around 8:00 pm which is a 'not so busy time' for DB and applications. But the temp tablespace ran out of space during this exercise. It was a nightmare. Here are some tips:
http://searchoracle.techtarget.com/tip/Speed-up-Oracle-index-creation
http://mehrajdba.wordpress.com/2009/01/30/how-to-make-an-index-creation-faster/
HTH
Z.K.

Index creation time

Similar Messages

Maybe you are looking for