Capture the Index Rebuild process time in a table

Dear Experts,

I have a stored procedure to rebuild the indexes. I would like to capture reconstruction of start and end time for a table. I created the table with structure below: I am writing an insert statement in the procedure that captures rebuild timings, might well want to suggest how to implement this?


MAINT DESC

Name Null? Type
------------------------------------------- ------------------------------------
OWNER VARCHAR2 (30)
TABLE-NAME VARCHAR2 (30)
START_TIME DATE
END_TIME DATE
VARCHAR2 (200) COMMENTS


CODE PLEASE
=======

CREATE OR REPLACE PROCEDURE "USER1". "" ONLINE_REORG ".
(v_owner IN varchar2, v_tablename IN varchar2) AS
v_rebuild_statement VARCHAR2 (1000);
v_rebuild_statement1 VARCHAR2 (1000);
err_msg VARCHAR2 (100);
v_cdc number (6);
cursor c1 is select master index_name table_name, nom_tablespace
of dba_indexes
where table_owner = upper (v_owner) and
nom_tablespace is not null and
index_type = 'NORMAL' and
table_name = Upper (v_tablename);

BEGIN
DBMS_OUTPUT. Put_line ('Rebuild Index procedure begins execution At' | to_char (sysdate, ' DD-MM-YYYY HH24:MI:SS'));))

FOR c1_rec IN c1 LOOP
Start
v_rebuild_statement: = 'edit index' | c1_rec. Owner: '.' | c1_rec.index_name |' REBUILD PARALLEL 6 LOGGING COMPRESS TABLESPACE ' | c1_rec.tablespace_name;
DBMS_OUTPUT. Put_line(v_rebuild_statement||';');
EXECUTE IMMEDIATE v_rebuild_statement;
exception when others then
null;
end;
Start
v_rebuild_statement: = 'edit index' | c1_rec. Owner: '.' | c1_rec.index_name |' NOPARALLEL ';
DBMS_OUTPUT. Put_line(v_rebuild_statement||';');
EXECUTE IMMEDIATE v_rebuild_statement;
exception when others then
null;
end;
END LOOP;
DBMS_OUTPUT. Put_line ("Rebuild Index procedure completes execution to ' |") TO_CHAR
(sysdate, ' DD-MM-YYYY HH24:MI:SS'))) ;
EXCEPTION
WHILE OTHERS THEN
DBMS_OUTPUT. Put_line ("Rebuild Index ended execution without success to")
' || TO_CHAR (sysdate, ' DD-MM-YYYY HH24:MI:SS'));)
err_msg: = SUBSTR (SQLERRM, 1, 100);
raise_application_error(-20001,err_msg);
END;

Tags: Database

Similar Questions

  • the index rebuild process

    Hi master,

    It is 'NO' yet another thread on the rebuilding of the index.

    I have read all the threads on index rebuild on oracle forums. each thread is full load with arguments and significantly useful discussion.

    but hardly a thread to discuss the process of rebuilding the index!

    I would like to know what exactly the do oracle, to rebuild the index? It uses the existing as a source index and therefore require more space?

    or it generates repeat therefore requires more space?

    What oracle will do with the old index? It frees the space occupied by the old index?

    If someone has a link or a suggestion, I will be grateful. and the deep knowledge sharing is more appreciated.


    Thanks and greetings
    VD

    Published by: vikrant dixit on January 21, 2009 03:40

    Vikrant dixit says:
    Thanks Charles

    for your kind support. and yet I doubt how much performance gain should be expected by rebuilding the index. I think I have to read all this thread once more and find the cream of the subject.

    and all that said by experts is it not true that the performance gain is dependent on scenario?

    in any case thank you

    Thanks and greetings
    VD

    Vikrant,

    From what I've seen and read, what said you above is correct.

    I like your the thread topic to try to understand what is happening during an index rebuild and after an index rebuild. The subject of rebuild indexes or not has been discussed many, many times on this forum, in messages Usenet dating back to 1999, various threads on asktom.oracle.com, various Web sites and in various books. But, your topic of what happens during an index rebuild, and after an index rebuild is not discussed as often, then I hope the links I provided will help you.

    Charles Hooper
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • schedule the index rebuild online

    Hello

    I need to schedule a task at the level of the database to rebuild the index online each month. all script exist? as the procedure to call on every month to rebuild indexes for the 5 tables identified in our project?

    It is in production

    We run in oracle 10g in the solaris platform.

    Dear Raman,

    I have no why yon need this.

    Try this, you can change next_date and interval you condition

    declare
  VJOBNUMBER BINARY_INTEGER;
begin
  DBMS_JOB.SUBMIT( job => VJOBNUMBER, NEXT_DATE => sysdate, interval => 'SYSDATE + 30', WHAT => 'BEGIN
FOR S IN (SELECT ''alter index'' || INDEX_NAME || '' rebuild;'' A FROM ALL_INDEXES)
LOOP
EXECUTE IMMEDIATE S.A;
END LOOP;
END;');
  DBMS_OUTPUT.PUT_LINE('Job number assigned: ' || TO_CHAR(VJOBNUMBER));
end;

  • I followed these steps several times, but he still has to work to rebuild the index.  Is there something else in the way of this work?

    Have you tried to rebuild the index spotlight several times, but it didn't work. I followed the steps through the system preferences, but there is no result for the rebuilding of the index.  Is there another way to do it, or is there another problem preventing it from working?

    Do you mean the following steps:

    Rebuild the index on your Mac - Apple Support Spotlight

  • At the same time index rebuild...

    OK, so I have a question that has puzzled me a bit. I think I understand the theory, but I am not convinced, so looking for 3xp3rt thoughts.

    I have the following table with the indexes following:

    Departments of instance name table Name Index
    AWESOME_DETAIL 20 1 AWESOME_DETAIL_B8

    The table itself has a DEGREE of 2 BODIES 1 value.

    What is happening is when the following is executed:

    ALTER INDEX REBUILD AWESOME_DETAIL_B8.

    the table is read in series, despite the index with a DOP of 20. However, when we do the following:

    ALTER INDEX REBUILD PARALLEL OF 20 AWESOME_DETAIL_B8

    The table is read with the parallelism and the treatment is faster (no surprise on the second part).

    When the index is rebuilt with the first statement, the degree of parallel remained unchanged at 20. If we run the second statement, and the index have had a degree of parallelism of the 2, then I expect the degree of parallelism of the index itself will be replaced by 20 (because I've seen this before).

    Is this expected behavior? Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.

    Essentially, the first statement is a pure DDL operation and the second statement is a DDL operation with storage options, where the change? And DDL operations ignore the declaration of principles on the subject, unlike, for example, a SELECT statement.

    I tried with a DISPLACEMENT of ALTER TABLE and saw the same behavior: without specifying PARALLEL in my statement, it read the table in series. When I specified PARALLEL, it read the table in parallel.

    Mark

    When you specify PARALLEL creating / REBUILD / MOVE, the degree is used for the C/R/M. it is always "in place" for all the readings (and will be used in DML If ALTER SESSION ACTIVATE PARALLEL_DML has been paid).
    However, the degree of PARALLEL set of the GET on the table / index is not automatically reused for the next RECONSTRUCTION/MOVE (although the degree that has been set remains!)

    Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.

    Yes, precisely.

    See http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/clauses006.htm#g1058315

    NOPARALLEL
    Specify NOPARALLEL for serial execution. It is the default value.

    Hemant K Collette

  • Index rebuild required after truncate the table and load data

    Hello


    I have a situation that we truncate tables bit and then we loaded data [only content] on these tables. What you need to rebuild the index online is necessary or not?


    And another question is if we drop a few clues is the total amount of space is released or not. And re-create indexes will use the same amount of space. As I don't have disk space more? In this situation, rebuild the index online will be a better idea...

    Can you please on this...


    truncate the table some the few loading tables + reconstruction markings online is the best (or) droping little tables, a few tables loading + re-create the index is better

    Can you suggest the best way... We have a time that it currently we don't have enough space on the disk... [Option should not effect the space]

    user13095767 wrote:
    Ok. I have it...

    u want to say if we disbale the index while loading... Next, we need to spend the time to build.

    If the indexes are enabled, then rebuild again is not necessary after loading tables...

    Please answer if my understanding is correct...

    above is correct

    >

    If so, how abt the differences in the space occupied by the spaces of storage during the index rebuild and re-create... T he acquires more space if recreate us [deletion and creation] or rebuild online is preferable to an index...?

    space used is the same for all options.

  • Reduced index rebuild the size of

    Hi all

    I think that this topic was raised by several times up to now... But I would like to know as I'm very curious.

    An array of size 6 GB with index btree of 300 MB, the size very high CPU load in that server (I think because of I/O), after the reconstruction of this size of the index came up to 250 MB.

    Now all my seniors ordered me to rebuild all indexes in the database that are huge in size, so that the i/o and CPU will be back to normal.

    I had the argument with my elder for the reason why we need to rebuild the index?
    Answer: As Oracle has access to this index it a lot of scan crashes a lot because of fragmentation. Oracle also has to scan all the blocks below the high water mark, where some blocks have fewer lines.

    My doubt is: when index is fragmented (candidate means that after reconstruction, reduced its size) made Oracle scans unwanted blocks below let high water is wrong, because the INDEX and TABLE are two different concepts, INDEX maintains information on which all blocks, it would seek the required values. So Oracle will not scan the blocks unwanted in the INDEX.

    Do may doubt is good or bad?

    A few details:
    The indicator is in DMT tablespace.
    Oracle 8i version.
    Sun solaris with 5.8 version, with 8 CPUS and 6 GB of RAM
    None of the indices have a height more than two.

    Plz HELP me in this concept... I want to prove my elders.

    -Yasser

    Yasserracdba,

    People learn their theory IT more. The normal index is implemented as a B *-tree structure.
    This means

                                                                      1 

                                             2        3                              5            6

                                      7       8    9   10                    11     12    13     14

    This means: block 1 contains information on block 2, 3, 5, 6 (I forgot 4, does not renumber)
    Block 2 about 7 and 8
    Block 7, etc are the leaves blocks and contain the actual keys.
    The key consists of key values and a rowid.

    The index is balanced. For a single scan will always tell you the same number of blocks, in this case 4
    (3 blocks + block index 1 data).

    IF YOU DON'T HAVE A CLUE, YOU WILL BE FORCED TO READ THE ENTIRE TABLE, THE TABLE SCAN COMPLETE THIS CALLED (YOU CAN SHOUT, I CAN SHOUT TOO)

    TO ACCESS THE INDEX MEANS SELF-CONTAINED BED, FULL TABLE SCAN MEANS SCATTERED MULTI BLOCK READING (BLOCKS END UP NOT CONTIGUOUS CACHE)

    FOR RANGE SCANS IO CAN BE REDUCED. TO LOOK UP A KEY INDIVIDUAL IO WILL NOT, I REPEAT N O T, REDUCE.

    -----------------
    Sybrand Bakker
    Senior Oracle DBA

    Experts: those who don't read the documentation

    Published by: sybrand_b on May 28, 2009 11:04

  • Shrink the table, rebuild the index?

    I need to reduce some very large tables after the removal of lines and I want to validate the script to run. I was thinking something like this:
    run_deleting_process;
    change the movement line of table my_tableI enable;
    ALTER table my_table retractable space WATERFALL;
    change the movement line of table my_tableI disable;
    I need to rebuild the index after that?, or if I rebuild the markings, can I delete clause CASCADE of the command? It is recommended to run utltrp.sql after shrink the table?, maybe some dependent object needs to be recompiled after the reduction of a table?
    The database version is 11.1.0.7 and documentation does not specify that the index rebuild is required, but I realized it is a desition normall when the narrowing of the tables.
    Thank you

    No there is no rebuild the index after shrinkage. And if you use "cascade", your index will be supported. You do very well.

    Visit this link as well.

    http://www.orafaq.com/Forum/t/137522/2/

  • Internal components of the online index rebuild.

    Hi all

    What happens in the index rebuild online compared to the simple index rebuild?

    Why this task consumes temporary space in the tablespace where index?

    How to get access index is accepted when online index rebuilding... What happens internally?

    -Yasser

  • Strange - Inserts first slowly, then quickly after the index drop and recreate

    Hello

    I have a chart with lines more 1,250,000,000 on Oracle 11.1.0.7, Linux. He had 4 global index, not partitioned. Insertions in this table have been very slow - lots of db file sequential reads, each taking an average of 0,009 second (from tkprof) - not bad, but the overall performance was wrong - so I fell & re-create the primary key index (3 columns in this index) and permanently other 3 index. As a result, total number of db file sequential reads decreased about 4 times (I was expecting that - now, there is only 1, not 4 index) but not only that - the avarage db file sequential read time fell just 0.0014 second!

    In further investigation, I found in the form of traces, that BEFORE the fall & recreate, each sequential reading of the db file has been reading completely different blocks ("random") and AFTER the fall & recreate, blocks accessed by db file sequential reads are almost successively ordered (which allows to obtain cached storage Bay, and I think it's why I get 0.0014 instead of 0.009)! My question is - HOW it HAPPENED? Why the index rebuild has helped so much? The index is fragmented? And perhaps helped PCTFREE 10%, which I've recreated the index with, and there is no index block is divided now (but will appear in the future)?

    Important notes - the result set that I insert is and has always ordered columns of table KP index. FILESYSTEMIO_OPTIONS parameter is set to SETALL is not OS cache (I presume), which makes my reading faster (because I have Direct IO).

    Here is an excerpt of the trace file (expected a single insert operation):

    -> > FRONT:
    WAITING #12: nam = 'db file sequential read' ela = 35089 file #= 15 block #= blocks 20534014 = 1 obj #= tim 64560 = 1294827907110090
    WAITING #12: nam = 'db file sequential read' ela = 6434 file #= 15 block #= blocks 61512424 = 1 obj #= tim 64560 = 1294827907116799
    WAITING #12: nam = 'db file sequential read' ela = 7961 file #= 15 block #= blocks 33775666 = 1 obj #= tim 64560 = 1294827907124874
    WAITING #12: nam = 'db file sequential read' ela = 16681 file #= 15 block #= blocks 60785827 = 1 obj #= tim 64560 = 1294827907143821
    WAITING #12: nam = 'db file sequential read' ela = 2380 file #= 15 block #= blocks 60785891 = 1 obj #= tim 64560 = 1294827907147000
    WAITING #12: nam = 'db file sequential read' ela = 4219 file #= 15 block #= blocks 33775730 = 1 obj #= tim 64560 = 1294827907151553
    WAITING #12: nam = 'db file sequential read' ela = 7218 file #= 15 block #= blocks 58351090 = 1 obj #= tim 64560 = 1294827907158922
    WAITING #12: nam = 'db file sequential read' ela = 6140 file #= 15 block #= blocks 20919908 = 1 obj #= tim 64560 = 1294827907165194
    WAITING #12: nam = ela 'db file sequential read' = 542 file #= 15 block #= blocks 60637720 = 1 obj #= tim 64560 = 1294827907165975
    WAITING #12: nam = 'db file sequential read' ela = 13736 file #= 15 block #= blocks 33350753 = 1 obj #= tim 64560 = 1294827907179807
    WAITING #12: nam = 'db file sequential read' ela = 57465 file #= 15 block #= blocks 59840995 = 1 obj #= tim 64560 = 1294827907237569
    WAITING #12: nam = 'db file sequential read' ela = file No. 20077 = 15 block #= blocks 11266833 = 1 obj #= tim 64560 = 1294827907257879
    WAITING #12: nam = 'db file sequential read' ela = 10642 file #= 15 block #= blocks 34506477 = 1 obj #= tim 64560 = 1294827907268867
    WAITING #12: nam = 'db file sequential read' ela = 5393 file #= 15 block #= blocks 20919972 = 1 obj #= tim 64560 = 1294827907275227
    WAITING #12: nam = 'db file sequential read' ela = 15308 file #= 15 block #= blocks 61602921 = 1 obj #= tim 64560 = 1294827907291203
    WAITING #12: nam = 'db file sequential read' ela = 11228 file #= 15 block #= blocks 34032720 = 1 obj #= tim 64560 = 1294827907303261
    WAITING #12: nam = 'db file sequential read' ela = 7885 file #= 15 block #= blocks 60785955 = 1 obj #= tim 64560 = 1294827907311867
    WAITING #12: nam = 'db file sequential read' ela = 6652 file #= 15 block #= blocks 19778448 = 1 obj #= tim 64560 = 1294827907319158
    WAITING #12: nam = 'db file sequential read' ela = 8735 file #= 15 block #= blocks 34634855 = 1 obj #= tim 64560 = 1294827907328770
    WAITING #12: nam = 'db file sequential read' ela = 14235 file #= 15 block #= blocks 61411940 = 1 obj #= tim 64560 = 1294827907343804
    WAITING #12: nam = 'db file sequential read' ela = 7173 file #= 15 block #= blocks 33350808 = 1 obj #= tim 64560 = 1294827907351214
    WAITING #12: nam = 'db file sequential read' ela = 8033 file #= 15 block #= blocks 60493866 = 1 obj #= tim 64560 = 1294827907359424
    WAITING #12: nam = 'db file sequential read' ela = 14654 file #= 15 block #= blocks 19004731 = 1 obj #= tim 64560 = 1294827907374257
    WAITING #12: nam = 'db file sequential read' ela = 6116 file #= 15 block #= blocks 34565376 = 1 obj #= tim 64560 = 1294827907380647
    WAITING #12: nam = 'db file sequential read' ela = 6203 file #= 15 block #= blocks 20920100 = 1 obj #= tim 64560 = 1294827907387054
    WAITING #12: nam = 'db file sequential read' ela = 50627 file #= 15 block #= blocks 61602985 = 1 obj #= tim 64560 = 1294827907437838
    WAITING #12: nam = 'db file sequential read' ela = 13752 file #= 15 block #= blocks 33351193 = 1 obj #= tim 64560 = 1294827907451875
    WAITING #12: nam = 'db file sequential read' ela = 6883 file #= 15 block #= blocks 58686059 = 1 obj #= tim 64560 = 1294827907459551
    WAITING #12: nam = 'db file sequential read' ela = file No. 13284 = 15 block #= blocks 19778511 = 1 obj #= tim 64560 = 1294827907473558
    WAITING #12: nam = 'db file sequential read' ela = 16678 file #= 15 block #= blocks 34226211 = 1 obj #= tim 64560 = 1294827907493010
    WAITING #12: nam = 'db file sequential read' ela = 9565 file #= 15 block #= blocks 61123267 = 1 obj #= tim 64560 = 1294827907507419
    WAITING #12: nam = 'db file sequential read' ela = 6893 file #= 15 block #= blocks 20920164 = 1 obj #= tim 64560 = 1294827907515073
    WAITING #12: nam = 'db file sequential read' ela = 9817 file #= 15 block #= blocks 61603049 = 1 obj #= tim 64560 = 1294827907525598
    WAITING #12: nam = 'db file sequential read' ela = 4691 file #= 15 block #= blocks 33351248 = 1 obj #= tim 64560 = 1294827907530960
    WAITING #12: nam = 'db file sequential read' ela = file No. 25983 = 15 block #= blocks 58351154 = 1 obj #= tim 64560 = 1294827907557661
    WAITING #12: nam = 'db file sequential read' ela = 7402 file #= 15 block #= blocks 5096358 = 1 obj #= tim 64560 = 1294827907565927
    WAITING #12: nam = 'db file sequential read' ela = 7964 file #= 15 block #= blocks 61603113 = 1 obj #= tim 64560 = 1294827907574570
    WAITING #12: nam = 'db file sequential read' ela = 32776 file #= 15 block #= blocks 33549538 = 1 obj #= tim 64560 = 1294827907608063
    WAITING #12: nam = 'db file sequential read' ela = 5674 file #= 15 block #= blocks 60493930 = 1 obj #= tim 64560 = 1294827907614596
    WAITING #12: nam = 'db file sequential read' ela = 9525 file #= 15 block #= blocks 61512488 = 1 obj #= tim 64560 = 1294827907625007
    WAITING #12: nam = 'db file sequential read' ela = 15729 file #= 15 block #= blocks 33549602 = 1 obj #= tim 64560 = 1294827907641538
    WAITING #12: nam = 'db file sequential read' ela = file No. 11510 = 15 block #= blocks 60902458 = 1 obj #= tim 64560 = 1294827907653819
    WAITING #12: nam = 'db file sequential read' ela = 26431 files #= 15 block #= blocks 59841058 = 1 obj #= tim 64560 = 1294827907680940
    WAITING #12: nam = 'db file sequential read' ela = 9196 file #= 15 block #= blocks 33350809 = 1 obj #= tim 64560 = 1294827907690434
    WAITING #12: nam = 'db file sequential read' ela = 7745 file #= 15 block #= blocks 60296291 = 1 obj #= tim 64560 = 1294827907698353
    WAITING #12: nam = 'db file sequential read' ela = 429 file #= 15 block #= blocks 61603177 = 1 obj #= tim 64560 = 1294827907698953
    WAITING #12: nam = 'db file sequential read' ela = 8459 file #= 15 block #= blocks 33351194 = 1 obj #= tim 64560 = 1294827907707695
    WAITING #12: nam = 'db file sequential read' ela = 25998 file #= 15 block #= blocks 49598412 = 1 obj #= tim 64560 = 1294827907733890

    2011-01-12 11:25:07.742
    WAITING #12: nam = 'db file sequential read' ela = 7988 file #= 15 block #= blocks 11357900 = 1 obj #= tim 64560 = 1294827907742683
    WAITING #12: nam = 'db file sequential read' ela = 10066 file #= 15 block #= blocks 61512552 = 1 obj #= tim 64560 = 1294827907753540
    WAITING #12: nam = 'db file sequential read' ela = 8400 file #= 15 block #= blocks 33775858 = 1 obj #= tim 64560 = 1294827907762668
    WAITING #12: nam = 'db file sequential read' ela = 11750 file #= 15 block #= blocks 60636761 = 1 obj #= tim 64560 = 1294827907774667
    WAITING #12: nam = 'db file sequential read' ela = 16933 file #= 15 block #= blocks 20533183 = 1 obj #= tim 64560 = 1294827907791839
    WAITING #12: nam = 'db file sequential read' ela = 8895 file #= 15 block #= blocks 61603241 = 1 obj #= tim 64560 = 1294827907801047
    WAITING #12: nam = 'db file sequential read' ela = file No. 12685 = 15 block #= blocks 33775922 = 1 obj #= tim 64560 = 1294827907813913
    WAITING #12: nam = 'db file sequential read' ela = file No. 12664 = 15 block #= blocks 60493994 = 1 obj #= tim 64560 = 1294827907827379
    WAITING #12: nam = 'db file sequential read' ela = 8271 file #= 15 block #= blocks 19372356 = 1 obj #= tim 64560 = 1294827907835881
    WAITING #12: nam = 'db file sequential read' ela = file No. 10825 = 15 block #= blocks 59338524 = 1 obj #= tim 64560 = 1294827907847439
    WAITING #12: nam = 'db file sequential read' ela = 13086 file #= 15 block #= blocks 49440992 = 1 obj #= tim 64793 = 1294827907862022
    WAITING #12: nam = 'db file sequential read' ela = file No. 16491 = 15 block #= blocks 32853984 = 1 obj #= tim 64793 = 1294827907879282
    WAITING #12: nam = 'db file sequential read' ela = 9349 file #= 15 block #= blocks 60133021 = 1 obj #= tim 64793 = 1294827907888849
    WAITING #12: nam = 'db file sequential read' ela = 5680 files #= 15 block #= blocks 20370585 = 1 obj #= tim 64793 = 1294827907895281
    WAITING #12: nam = 'db file sequential read' ela = 34021 file #= 15 block #= blocks 58183834 = 1 obj #= tim 64793 = 1294827907930014
    WAITING #12: nam = 'db file sequential read' ela = 8574 file #= 15 block #= blocks 32179028 = 1 obj #= tim 64793 = 1294827907938813
    WAITING #12: nam = 'db file sequential read' ela = file No. 10862 = 15 block #= blocks 49402735 = 1 obj #= tim 64793 = 1294827907949821
    WAITING #12: nam = 'db file sequential read' ela = 4501 file #= 15 block #= blocks 11270933 = 1 obj #= tim 64793 = 1294827907954533
    WAITING #12: nam = 'db file sequential read' ela = 9936 file #= 15 block #= blocks 61007523 = 1 obj #= tim 64793 = 1294827907964616
    WAITING #12: nam = 'db file sequential read' ela = 7631 file #= 15 block #= blocks 34399970 = 1 obj #= tim 64793 = 1294827907972457
    WAITING #12: nam = 'db file sequential read' ela = 6162 file #= 15 block #= blocks 60305187 = 1 obj #= tim 64793 = 1294827907978797
    WAITING #12: nam = 'db file sequential read' ela = 8555 file #= 15 block #= blocks 20912586 = 1 obj #= tim 64793 = 1294827907987532
    WAITING #12: nam = 'db file sequential read' ela = 9499 file #= 15 block #= blocks 61007587 = 1 obj #= tim 64793 = 1294827907997296
    WAITING #12: nam = 'db file sequential read' ela = 23690 file #= 15 block #= blocks 19769014 = 1 obj #= tim 64793 = 1294827908024105
    WAITING #12: nam = 'db file sequential read' ela = 7081 file #= 15 block #= blocks 61314072 = 1 obj #= tim 64793 = 1294827908031968
    WAITING #12: nam = 'db file sequential read' ela = 31727 file #= 15 block #= blocks 34026602 = 1 obj #= tim 64793 = 1294827908063914
    WAITING #12: nam = 'db file sequential read' ela = 4932 file #= 15 block #= blocks 60905313 = 1 obj #= tim 64793 = 1294827908069052
    WAITING #12: nam = 'db file sequential read' ela = 6616 file #= 15 block #= blocks 20912650 = 1 obj #= tim 64793 = 1294827908075835
    WAITING #12: nam = 'db file sequential read' ela = 8443 file #= 15 block #= blocks 33781968 = 1 obj #= tim 64793 = 1294827908084594
    WAITING #12: nam = 'db file sequential read' ela = 22291 file #= 15 block #= blocks 60641967 = 1 obj #= tim 64793 = 1294827908107052
    WAITING #12: nam = 'db file sequential read' ela = 6610 file #= 15 block #= blocks 18991774 = 1 obj #= tim 64793 = 1294827908113879
    WAITING #12: nam = 'db file sequential read' ela = 6493 file #= 15 block #= blocks 34622382 = 1 obj #= tim 64793 = 1294827908120535
    WAITING #12: nam = 'db file sequential read' ela = 5028 file #= 15 block #= blocks 20912714 = 1 obj #= tim 64793 = 1294827908125861
    WAITING #12: nam = 'db file sequential read' ela = file No. 11834 = 15 block #= blocks 61679845 = 1 obj #= tim 64793 = 1294827908137858
    WAITING #12: nam = 'db file sequential read' ela = 4261 file #= 15 block #= blocks 34498166 = 1 obj #= tim 64793 = 1294827908142305
    WAITING #12: nam = 'db file sequential read' ela = 19267 file #= 15 block #= blocks 60905377 = 1 obj #= tim 64793 = 1294827908161695
    WAITING #12: nam = 'db file sequential read' ela = file No. 14108 = 15 block #= blocks 19769078 = 1 obj #= tim 64793 = 1294827908176046
    WAITING #12: nam = 'db file sequential read' ela = 4128 file #= 15 block #= blocks 33781465 = 1 obj #= tim 64793 = 1294827908180396
    WAITING #12: nam = 'db file sequential read' ela = 9986 file #= 15 block #= blocks 61007651 = 1 obj #= tim 64793 = 1294827908190535
    WAITING #12: nam = 'db file sequential read' ela = 8907 file #= 15 block #= blocks 20912778 = 1 obj #= tim 64793 = 1294827908199614
    WAITING #12: nam = 'db file sequential read' ela = 12023 file #= 15 block #= blocks 34230838 = 1 obj #= tim 64793 = 1294827908211852
    WAITING #12: nam = 'db file sequential read' ela = 29837 file #= 15 block #= blocks 60905441 = 1 obj #= tim 64793 = 1294827908241853
    WAITING #12: nam = 'db file sequential read' ela = 5989 file #= 15 block #= blocks 60133085 = 1 obj #= tim 64793 = 1294827908248065
    WAITING #12: nam = 'db file sequential read' ela = 74172 file #= 15 block #= blocks 33357369 = 1 obj #= tim 64793 = 1294827908322391
    WAITING #12: nam = 'db file sequential read' ela = 5443 file #= 15 block #= blocks 60498917 = 1 obj #= tim 64793 = 1294827908328064
    WAITING #12: nam = 'db file sequential read' ela = 4645 file #= 15 block #= blocks 20912842 = 1 obj #= tim 64793 = 1294827908332912
    WAITING #12: nam = 'db file sequential read' ela = file No. 13595 = 15 block #= blocks 61679909 = 1 obj #= tim 64793 = 1294827908346618
    WAITING #12: nam = 'db file sequential read' ela = 9120 file #= 15 block #= blocks 58356376 = 1 obj #= tim 64793 = 1294827908355975
    WAITING #12: nam = 'db file sequential read' ela = 3186 file #= 15 block #= blocks 19385867 = 1 obj #= tim 64793 = 1294827908359374
    WAITING #12: nam = 'db file sequential read' ela = 5114 file #= 15 block #= blocks 61589533 = 1 obj #= tim 64793 = 1294827908364630
    WAITING #12: nam = 'db file sequential read' ela = 42263 file #= 15 block #= blocks 33356474 = 1 obj #= tim 64793 = 1294827908407045
    WAITING #12: nam = 'db file sequential read' ela = 10683 file #= 15 block #= blocks 58183898 = 1 obj #= tim 64793 = 1294827908417994
    WAITING #12: nam = 'db file sequential read' ela = file No. 10284 = 15 block #= blocks 20529486 = 1 obj #= tim 64793 = 1294827908429134
    WAITING #12: nam = 'db file sequential read' ela = file No. 12544 = 15 block #= blocks 60498981 = 1 obj #= tim 64793 = 1294827908441945
    WAITING #12: nam = 'db file sequential read' ela = 8311 file #= 15 block #= blocks 33191548 = 1 obj #= tim 64793 = 1294827908451011
    WAITING #12: nam = 'db file sequential read' ela = 4261 file #= 15 block #= blocks 59083610 = 1 obj #= tim 64793 = 1294827908455902
    WAITING #12: nam = 'db file sequential read' ela = 4653 file #= 15 block #= blocks 18991837 = 1 obj #= tim 64793 = 1294827908461264
    WAITING #12: nam = 'db file sequential read' ela = 4905 file #= 15 block #= blocks 34685472 = 1 obj #= tim 64793 = 1294827908466897
    WAITING #12: nam = 'db file sequential read' ela = file No. 12360 = 15 block #= blocks 61775403 = 1 obj #= tim 64793 = 1294827908480080
    WAITING #12: nam = 'db file sequential read' ela = 6956 file #= 15 block #= blocks 58921225 = 1 obj #= tim 64793 = 1294827908487704
    WAITING #12: nam = 'db file sequential read' ela = 6068 file #= 15 block #= blocks 19769142 = 1 obj #= tim 64793 = 1294827908494608
    WAITING #12: nam = 'db file sequential read' ela = 5249 file #= 15 block #= blocks 33781528 = 1 obj #= tim 64793 = 1294827908500666
    WAITING #12: nam = 'db file sequential read' ela = 6013 file #= 15 block #= blocks 60905505 = 1 obj #= tim 64793 = 1294827908507366
    WAITING #12: nam = 'db file sequential read' ela = 3014 file #= 15 block #= blocks 20912970 = 1 obj #= tim 64793 = 1294827908511019
    WAITING #12: nam = 'db file sequential read' ela = 3636 file #= 15 block #= blocks 33781591 = 1 obj #= tim 64793 = 1294827908515425
    WAITING #12: nam = 'db file sequential read' ela = file No. 12226 = 15 block #= blocks 58183962 = 1 obj #= tim 64793 = 1294827908528268
    WAITING #12: nam = 'db file sequential read' ela = 7635 file #= 15 block #= blocks 60499173 = 1 obj #= tim 64793 = 1294827908536613
    WAITING #12: nam = 'db file sequential read' ela = 7364 file #= 15 block #= blocks 11270996 = 1 obj #= tim 64793 = 1294827908544203
    WAITING #12: nam = 'db file sequential read' ela = 5452 file #= 15 block #= blocks 34622446 = 1 obj #= tim 64793 = 1294827908550475
    WAITING #12: nam = 'db file sequential read' ela = 9734 file #= 15 block #= blocks 20913034 = 1 obj #= tim 64793 = 1294827908561029
    WAITING #12: nam = 'db file sequential read' ela = 14077 file #= 15 block #= blocks 61679973 = 1 obj #= tim 64793 = 1294827908575440
    WAITING #12: nam = 'db file sequential read' ela = 9694 file #= 15 block #= blocks 34550681 = 1 obj #= tim 64793 = 1294827908585311
    WAITING #12: nam = 'db file sequential read' ela = 6753 file #= 15 block #= blocks 61007715 = 1 obj #= tim 64793 = 1294827908592228
    WAITING #12: nam = 'db file sequential read' ela = 12577 file #= 15 block #= blocks 19769206 = 1 obj #= tim 64793 = 1294827908604943
    WAITING #12: nam = 'db file sequential read' ela = file No. 609 = 15 block #= blocks 61589534 = 1 obj #= tim 64793 = 1294827908605735
    WAITING #12: nam = 'db file sequential read' ela = 6267 file #= 15 block #= blocks 33356538 = 1 obj #= tim 64793 = 1294827908612148
    WAITING #12: nam = 'db file sequential read' ela = 7876 file #= 15 block #= blocks 58184026 = 1 obj #= tim 64793 = 1294827908620164
    WAITING #12: nam = 'db file sequential read' ela = file No. 14058 = 15 block #= blocks 32767835 = 1 obj #= tim 80883 = 1294827908634546
    WAITING #12: nam = 'db file sequential read' ela = 9798 file #= 15 block #= blocks 58504373 = 1 obj #= tim 80883 = 1294827908644575
    WAITING #12: nam = 'db file sequential read' ela = 11081 file #= 15 block #= blocks 11118811 = 1 obj #= tim 80883 = 1294827908655908
    WAITING #12: nam = 'db file sequential read' ela = 6249 file #= 15 block #= blocks 58087798 = 1 obj #= tim 80883 = 1294827908662451
    WAITING #12: nam = 'db file sequential read' ela = 9513 file #= 15 block #= blocks 33331129 = 1 obj #= tim 80883 = 1294827908672904
    WAITING #12: nam = 'db file sequential read' ela = 4648 file #= 15 block #= blocks 60301818 = 1 obj #= tim 80883 = 1294827908677736
    WAITING #12: nam = 'db file sequential read' ela = 6147 file #= 15 block #= blocks 20523119 = 1 obj #= tim 80883 = 1294827908684075
    WAITING #12: nam = 'db file sequential read' ela = file No. 59531 = 15 block #= blocks 61016570 = 1 obj #= tim 80883 = 1294827908743795

    2011-01-12 11:25:08.752
    WAITING #12: nam = 'db file sequential read' ela = 8787 file #= 15 block #= blocks 33770842 = 1 obj #= tim 80883 = 1294827908752846
    WAITING #12: nam = 'db file sequential read' ela = 9858 file #= 15 block #= blocks 60895354 = 1 obj #= tim 80883 = 1294827908762960
    WAITING #12: nam = 'db file sequential read' ela = 11237 file #= 15 block #= blocks 19369506 = 1 obj #= tim 80883 = 1294827908775138
    WAITING #12: nam = 'db file sequential read' ela = 5838 file #= 15 block #= blocks 34229712 = 1 obj #= tim 80883 = 1294827908782100
    WAITING #12: nam = 'db file sequential read' ela = 6518 file #= 15 block #= blocks 61221772 = 1 obj #= tim 80883 = 1294827908789403
    WAITING #12: nam = 'db file sequential read' ela = 9946 file #= 15 block #= blocks 20523183 = 1 obj #= tim 80883 = 1294827908800089
    WAITING #12: nam = 'db file sequential read' ela = 16699 file #= 15 block #= blocks 61016634 = 1 obj #= tim 80883 = 1294827908817077
    WAITING #12: nam = 'db file sequential read' ela = file No. 15215 = 15 block #= blocks 33770900 = 1 obj #= tim 80883 = 1294827908832934
    WAITING #12: nam = 'db file sequential read' ela = 8403 file #= 15 block #= blocks 60895418 = 1 obj #= tim 80883 = 1294827908842317
    WAITING #12: nam = 'db file sequential read' ela = 8927 file #= 15 block #= blocks 18950791 = 1 obj #= tim 80883 = 1294827908852190
    WAITING #12: nam = 'db file sequential read' ela = 4382 files #= 15 block #= blocks 34493493 = 1 obj #= tim 80883 = 1294827908856821
    WAITING #12: nam = 'db file sequential read' ela = 9356 file #= 15 block #= blocks 61324964 = 1 obj #= tim 80883 = 1294827908866337
    WAITING #12: nam = 'db file sequential read' ela = 10575 file #= 15 block #= blocks 20883018 = 1 obj #= tim 80883 = 1294827908877102
    WAITING #12: nam = 'db file sequential read' ela = 16601 file #= 15 block #= blocks 60502307 = 1 obj #= tim 80883 = 1294827908893926
    WAITING #12: nam = 'db file sequential read' ela = 5236 file #= 15 block #= blocks 33331193 = 1 obj #= tim 80883 = 1294827908899387
    WAITING #12: nam = 'db file sequential read' ela = 9981 file #= 15 block #= blocks 59830076 = 1 obj #= tim 80883 = 1294827908910427
    WAITING #12: nam = 'db file sequential read' ela = 8100 file #= 15 block #= blocks 19767805 = 1 obj #= tim 80883 = 1294827908918751
    WAITING #12: nam = 'db file sequential read' ela = 12492 file #= 15 block #= blocks 67133332 = 1 obj #= tim 80883 = 1294827908931732
    WAITING #12: nam = 'db file sequential read' ela = 5876 file #= 15 block #= blocks 34229775 = 1 obj #= tim 80883 = 1294827908937859
    WAITING #12: nam = 'db file sequential read' ela = 8741 file #= 15 block #= blocks 61408244 = 1 obj #= tim 80883 = 1294827908948439
    WAITING #12: nam = 'db file sequential read' ela = 8477 file #= 15 block #= blocks 20523247 = 1 obj #= tim 80883 = 1294827908957099
    WAITING #12: nam = 'db file sequential read' ela = 7947 file #= 15 block #= blocks 61016698 = 1 obj #= tim 80883 = 1294827908965210
    WAITING #12: nam = 'db file sequential read' ela = 2384 file #= 15 block #= blocks 33331257 = 1 obj #= tim 80883 = 1294827908967773
    WAITING #12: nam = 'db file sequential read' ela = 3585 file #= 15 block #= blocks 59571985 = 1 obj #= tim 80883 = 1294827908971564
    WAITING #12: nam = 'db file sequential read' ela = 7753 file #= 15 block #= blocks 5099571 = 1 obj #= tim 80883 = 1294827908979647
    WAITING #12: nam = 'db file sequential read' ela = 8205 file #= 15 block #= blocks 61408308 = 1 obj #= tim 80883 = 1294827908988200
    WAITING #12: nam = 'db file sequential read' ela = 7745 file #= 15 block #= blocks 34229335 = 1 obj #= tim 80883 = 1294827908996129
    WAITING #12: nam = 'db file sequential read' ela = file No. 10942 = 15 block #= blocks 61325028 = 1 obj #= tim 80883 = 1294827909007244
    WAITING #12: nam = 'db file sequential read' ela = 6247 file #= 15 block #= blocks 20523311 = 1 obj #= tim 80883 = 1294827909013706
    WAITING #12: nam = 'db file sequential read' ela = file No. 16188 = 15 block #= blocks 60777362 = 1 obj #= tim 80883 = 1294827909030088
    WAITING #12: nam = 'db file sequential read' ela = file No. 16642 = 15 block #= blocks 33528224 = 1 obj #= tim 80883 = 1294827909046971
    WAITING #12: nam = 'db file sequential read' ela = file No. 10118 = 15 block #= blocks 60128498 = 1 obj #= tim 80883 = 1294827909057402
    WAITING #12: nam = 'db file sequential read' ela = file No. 10747 = 15 block #= blocks 802317 = 1 obj #= tim 64495 = 1294827909069165
    WAITING #12: nam = 'db file sequential read' ela = 4795 file number = 15 block #= blocks 33079541 = 1 obj #= tim 64560 = 1294827909074367
    WAITING #12: nam = 'db file sequential read' ela = 6822 file #= 15 block #= blocks 20913098 = 1 obj #= tim 64793 = 1294827909081436
    WAITING #12: nam = 'db file sequential read' ela = file No. 10932 = 15 block #= blocks 19369570 = 1 obj #= tim 80883 = 1294827909092607



    --> > AFTER:
    WAITING #23: nam = 'db file sequential read' ela = 16367 file #= 15 block #= blocks 70434065 = 1 obj #= tim 115059 = 1295342220878947
    WAITING #23: nam = 'db file sequential read' ela = 1141 file #= 15 block #= blocks 70434066 = 1 obj #= tim 115059 = 1295342220880549
    WAITING #23: nam = 'db file sequential read' ela = 456 file #= 15 block #= blocks 70434067 = 1 obj #= tim 115059 = 1295342220881615
    WAITING #23: nam = 'db file sequential read' ela = 689 file #= 15 block #= blocks 70434068 = 1 obj #= tim 115059 = 1295342220882617
    WAITING #23: nam = 'db file sequential read' ela = 495 file #= 15 block #= blocks 70434069 = 1 obj #= tim 115059 = 1295342220883482
    WAITING #23: nam = 'db file sequential read' ela = 419 file #= 15 block #= blocks 70434070 = 1 obj #= tim 115059 = 1295342220884195
    WAITING #23: nam = 'db file sequential read' ela = 149 file #= 15 block #= blocks 70434071 = 1 obj #= tim 115059 = 1295342220884629
    WAITING #23: nam = 'db file sequential read' ela = 161 file #= 15 block #= blocks 70434072 = 1 obj #= tim 115059 = 1295342220885085
    WAITING #23: nam = 'db file sequential read' ela = 146 file #= 15 block #= blocks 70434073 = 1 obj #= tim 115059 = 1295342220885533
    WAITING #23: nam = ela 'db file sequential read' = 188 file #= 15 block #= blocks 70434074 = 1 obj #= tim 115059 = 1295342220886026
    WAITING #23: nam = 'db file sequential read' ela = 181 file #= 15 block #= blocks 70434075 = 1 obj #= tim 115059 = 1295342220886498
    WAITING #23: nam = 'db file sequential read' ela = 303 file #= 15 block #= blocks 70434076 = 1 obj #= tim 115059 = 1295342220887082
    WAITING #23: nam = 'db file sequential read' ela = file No. 550 = 15 block #= blocks 70434077 = 1 obj #= tim 115059 = 1295342220887916
    WAITING #23: nam = 'db file sequential read' ela = 163 file #= 15 block #= blocks 70434078 = 1 obj #= tim 115059 = 1295342220888402
    WAITING #23: nam = 'db file sequential read' ela = 200 file #= 15 block #= blocks 70434079 = 1 obj #= tim 115059 = 1295342220888980
    WAITING #23: nam = 'db file sequential read' ela = 134 file #= 15 block #= blocks 70434080 = 1 obj #= tim 115059 = 1295342220889409
    WAITING #23: nam = 'db file sequential read' ela = 157 file #= 15 block #= blocks 70434081 = 1 obj #= tim 115059 = 1295342220889850
    WAITING #23: nam = 'db file sequential read' ela = 5112 file #= 15 block #= blocks 70434540 = 1 obj #= tim 115059 = 1295342220895272
    WAITING #23: nam = 'db file sequential read' ela = 276 file #= 15 block #= blocks 70434082 = 1 obj #= tim 115059 = 1295342220895640

    2011-01-18 10:17:00.898
    WAITING #23: nam = 'db file sequential read' ela = 2936 file #= 15 block #= blocks 70434084 = 1 obj #= tim 115059 = 1295342220898921
    WAITING #23: nam = 'db file sequential read' ela = 1843 file number = 15 block #= blocks 70434085 = 1 obj #= tim 115059 = 1295342220901233
    WAITING #23: nam = 'db file sequential read' ela = 452 file #= 15 block #= blocks 70434086 = 1 obj #= tim 115059 = 1295342220902050
    WAITING #23: nam = 'db file sequential read' ela = 686 file #= 15 block #= blocks 70434087 = 1 obj #= tim 115059 = 1295342220903031
    WAITING #23: nam = 'db file sequential read' ela = 1582 file #= 15 block #= blocks 70434088 = 1 obj #= tim 115059 = 1295342220904933
    WAITING #23: nam = 'db file sequential read' ela = 179 file #= 15 block #= blocks 70434089 = 1 obj #= tim 115059 = 1295342220905544
    WAITING #23: nam = 'db file sequential read' ela = 426 file #= 15 block #= blocks 70434090 = 1 obj #= tim 115059 = 1295342220906303
    WAITING #23: nam = 'db file sequential read' ela = 138 file #= 15 block #= blocks 70434091 = 1 obj #= tim 115059 = 1295342220906723
    WAITING #23: nam = 'db file sequential read' ela = 3004 file #= 15 block #= blocks 70434092 = 1 obj #= tim 115059 = 1295342220910053
    WAITING #23: nam = 'db file sequential read' ela = 331 file #= 15 block #= blocks 70434093 = 1 obj #= tim 115059 = 1295342220910765
    WAITING #23: nam = 'db file sequential read' ela = 148 file #= 15 block #= blocks 70434094 = 1 obj #= tim 115059 = 1295342220911236
    WAITING #23: nam = 'db file sequential read' ela = 296 file #= 15 block #= blocks 70434095 = 1 obj #= tim 115059 = 1295342220911836
    WAITING #23: nam = 'db file sequential read' ela = 441 file #= 15 block #= blocks 70434096 = 1 obj #= tim 115059 = 1295342220912581
    WAITING #23: nam = 'db file sequential read' ela = 157 file #= 15 block #= blocks 70434097 = 1 obj #= tim 115059 = 1295342220913038
    WAITING #23: nam = 'db file sequential read' ela = 281 file #= 15 block #= blocks 70434098 = 1 obj #= tim 115059 = 1295342220913603
    WAITING #23: nam = 'db file sequential read' ela = file No. 150 = 15 block #= blocks 70434099 = 1 obj #= tim 115059 = 1295342220914048
    WAITING #23: nam = 'db file sequential read' ela = 143 file #= 15 block #= blocks 70434100 = 1 obj #= tim 115059 = 1295342220914498
    WAITING #23: nam = 'db file sequential read' ela = 384 file #= 15 block #= blocks 70434101 = 1 obj #= tim 115059 = 1295342220916907
    WAITING #23: nam = 'db file sequential read' ela = file No. 164 = 15 block #= blocks 70434102 = 1 obj #= tim 115059 = 1295342220917458
    WAITING #23: nam = 'db file sequential read' ela = 218 file #= 15 block #= blocks 70434103 = 1 obj #= tim 115059 = 1295342220917962
    WAITING #23: nam = 'db file sequential read' ela = file No. 450 = 15 block #= blocks 70434104 = 1 obj #= tim 115059 = 1295342220918698
    WAITING #23: nam = 'db file sequential read' ela = file No. 164 = 15 block #= blocks 70434105 = 1 obj #= tim 115059 = 1295342220919159
    WAITING #23: nam = 'db file sequential read' ela = 136 file #= 15 block #= blocks 70434106 = 1 obj #= tim 115059 = 1295342220919598
    WAITING #23: nam = 'db file sequential read' ela = 143 file #= 15 block #= blocks 70434107 = 1 obj #= tim 115059 = 1295342220920041
    WAITING #23: nam = 'db file sequential read' ela = 3091 file #= 15 block #= blocks 70434108 = 1 obj #= tim 115059 = 1295342220925409

    user12196647 wrote:
    Hemant, Jonathan - thanks for the comprehensive replies. To summarize:

    It's the 11.1 (11.1.0.7) database on 64-bit Linux. No compression is used for everything, all the blocks are 16 k tablespaces are SAMS created with attributes EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO BIGFILE tablespaces (separate for tables and separate for the index tablespace). I do not have to rebuild the indexes of PK, but abandoned all indexes, and then recreated the KP (but it's okay - reconstruction is still that let down & create, isn't it?).

    Traces were made during the pl/sql loop forall was actually insert. Each pl/sql forall loop inserts 100 lines "at once" (we use fetch bulk collect limit 100), but the loading process inserts a few million records (pl/sql forall loop is closed :)). I stuck that part of traces - wait events for 100 (a set of) 'before' 100 'after' inserts and inserts. Wait for events to another inserts look exacly the same - always blocks 'random' in 'before the index recreate' inserts and inserts almost ordained blocks in "after the index recreate." The objects_ids were certainly indexes.

    I think that the explanation of Hemant is correct. The point is, my structure of the index is of (X, Y, DATE), where X and are 99% repeating at each loading data, values and DATE is increased by one for each data load. Because I'm always insert ordered by PK, for loading a new DATE, I visit each index leaf block, in order, as in the analysis of comprehensive index. Because I'm inserted in each block sheet in every load, I have many index block splits. Which caused my pads of sheets to be physically non-contiguous after awhile. Reconstruction has been my healing...

    You got your answer before I had time to finish a model of your data set - but I think you're description is fairly accurate.
    A few thoughts if:

    WAITING #12: nam = 'db file sequential read' ela = file No. 10747 = 15 block #= blocks 802317 = 1 obj #= tim 64495 = 1294827909069165
    WAITING #12: nam = 'db file sequential read' ela = 4795 file number = 15 block #= blocks 33079541 = 1 obj #= tim 64560 = 1294827909074367
    WAITING #12: nam = 'db file sequential read' ela = 6822 file #= 15 block #= blocks 20913098 = 1 obj #= tim 64793 = 1294827909081436
    WAITING #12: nam = 'db file sequential read' ela = file No. 10932 = 15 block #= blocks 19369570 = 1 obj #= tim 80883 = 1294827909092607

    Unless you missed a bit when your trace file copying, the index with the id of the object 64495 has not subject to drive the way readings which the other clues were. It would be nice to know why. There are two "obvious" possibilities - (a) it has been very well buffered or (b) there is an index where almost all the entries are zero, so it is rarely changed. Because it has the object id lowest of all indexes, it is possible that it is the primary key index (but I don't because I tend to create the primary key of a table before I create any index) and if this is correct your waste of time was not on the primary key index, and perhaps he tends to be very well buffered the nature of popular queries.

    Changes in performance when inserting millions of lines tend to be non-linear as the number of indexes grow.

    As you insert data in the primary key order draw you maximum benefits caching for insertions in the KP index. And since you insert a very large number of lines - the order of 0.5% - 1% of the current lines, in light of your comment 'millions' - you're likely to insert two or three lines in each block of the pharmacokinetics of the index (by the way it must compress on the first two columns)) allowing Oracle to optimize its work in several ways.

    But for the other clues you are probably very randomly jump to insert rows, and this led to two different effects:


      You must keep N times as many blocks in the buffer to get similar read benefits
      each insertion in the index non-PK blocks is likely to be a row insert - which maximise cancel it and redo overhead more undo and redo written
      each insertion in an index block finally requires the block to write on the disc - which means more i/o, which slows down the readings
      as you read blocks (and you have read several of them) you can force the Oracle to write and other index blocks that need to be reviewed to equal.

    It is perfectly possible that almost all of your performance gain comes to drop the three indexes, and only a relatively small fraction come to rebuild the primary key.

    One final thought of block shares. I think that you have found an advantage any readahead (non-Oracle) when the index blocks are classified physically, if you have a trade-off between how many times you rebuild to this advantage and to find a time during which you can afford the resources to rebuild. If you want the best compromise (a) don't forget the compression option - it seems appropriate, (b) consider the benefits of partitioning range date - it seems very appropriate in your case, and (c) by varying the PCTFREE when you rebuild the index you can assign the number of insert cycles before the effects of the splits of block of sheets have a significant impact on the randomness of the IO.

    I have an idea-if I changed the index structure to (DATE, X, Y) then I would always insert in block leaves more right side, I'd have 90-10 splits instead of 50 / 50 splits and leafs would be physically contiguous, so any necessary new buildings - am I right?

    You cannot change the order of index column until you check the use of the index. If the most important and most frequent queries are "select table where colx = X and coly = O and date_col between A and B", you must index this round way. (In fact, you can look at the possibility of using a range partiitoned index organized table for data).

    Concerning
    Jonathan Lewis

  • compress the index

    Hello
    Compressing my indexes improve performance or decrease? When it will use exactly

    Dear user1175505,

    Online documentation of the Oracle;

    +"+
    + Using Compression of Index +.

    + Bitmap indexes are always stored as patented, compressed without the need for user intervention. B-tree indexes, however, can be stored specifically compressed way to allow huge space saving, storing more keys in each index block, which also leads to less i/o and better performance. +

    + Compression key allows you to compress an index B-tree, which reduces the overhead of repeated values storage. In the case of a non-unique index, all indexes on columns can be stored in a compressed format, while in the case of a unique index, at least one index column must be kept not compressed. +

    + In general, the an index keys have two pieces, a piece of group and a unique piece. If the key is not set to have a unique piece, Oracle provides a in the form of a rowid annexed to the pool room. Key compression is a method of breaking the pool room and store it so it can be shared by several unique pieces. The cardinality of the columns selected must be compressed determines the compression ratio that can be achieved. Thus, for example, if a unique index, which consists of five columns providing the uniqueness mainly the last two columns, it is more optimal to choose three columns to be stored compressed. If you choose to compress the four columns, the repetition will have almost disappeared, and the compression ratio will be worse. +

    * + Key compression reduces storage of an index, but it can increase the time processor required to rebuild the key during a scan of the index column values. He faces also certain additional storage overhead, because each prefix entry has an overload of four bytes associated with it. + *

    + Indexes Local versus Global index +.

    + Index B-tree on the partitioned tables can be global or local. With Oracle8i, and earlier versions, Oracle has recommended that global indexes will not be used in data warehouse environments, because a partition DDL statement (for example, ALTER TABLE...) DROP PARTITION) would invalidate the entire index, and the index rebuilding is expensive. Since the Oracle 10 g database, global index can be maintained without Oracle marking them as unusable after the DDL. This improvement makes overall more efficient index for data warehouse environments. +

    + However, index will be more common than the overall index. Global indexes must be used when there is a specific requirement that cannot be met by local indexes (for example, a unique index on a no partitioning key or a requirement of performance). +

    + Bitmap indexes on partitioned tables are always local. +
    +"+

    Ogan

  • ALTER Index Rebuild online

    My database is out 10 gr 2. Sometimes, I pass command ALTER INDEX < index name > REBUILD online on the indexes that are 500 MB in size. It takes about ten minutes to run the command. The database alert log shows no activity for the first six minutes, and DML is allowed on the associated table. At about minute seven journal alerts shows the first of a series of five online redo logs switches. They are each 100 MB.

    During the time that online redo logs, DML execution sessions cannot fill. When the new version of the index was created again online records switching station, the original copy of the index disappears, the ALTER INDEX command ends, and blocking for DML ceases.

    I read that the DML statements are not affected by executing ALTER INDEX REBUILD online, but experience shows that the blocking of the above sessions. Can someone explain to me what is happening in the different stages of the index rebuild? Is there something I can do to eliminate the blocking of the DML statements during the period when redo online record switch?

    Thank you
    Bill

    Bill,

    A useful reference for you:
    http://jonathanlewis.WordPress.com/2009/06/05/online-rebuild/

    Another very useful reference - of many articles:
    http://richardfoote.WordPress.com/category/index-rebuild/

    For what reason you rebuild the index?

    Charles Hooper
    Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
    http://hoopercharles.WordPress.com/
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • Do not adjust despite the advice of the index

    Its Oracle 10g Release 10.2.0.4.0
    Hi all

    I have this query in which there are indexes on the instrument table like this:
    Instrument:
idx 1 : (INSTRUMENT_ID, END_COB_DATE, CLOSE_ACTION_ID, PRODUCT_SUB_TYPE_ID, BEGIN_COB_DATE)
idx 2 : ( INSTRUMENT_ID, INSTRUMENT_VN, END_COB_DATE, CLOSE_ACTION_ID)
idx 3 : (CLOSE_ACTION_ID, END_COB_DATE)
    I tried all possible ways, but none of the indices are used to causing complete this table table scans. I need advice on how can I avoid this FTS, so the query can run fast and use the index on the table of the Instrument:

    query:
    select distinct i.instrument_id,
                i.name,
                case
                  when (mn2.display_name != 'DEBT PRIORITY CLASS' and
                       mn2.display_name is not null) then
                   mn2.display_name
                  else
                   mn1.display_name
                end "DEBT_PRIORITY_CLASS"
  from instrument i, inst_debt id
  left join marsnode mn1 on (id.debt_priority_class_id = mn1.node_id and
                            mn1.close_date is null and
                            mn1.type_id = 58412926883279)
  left join marsnodelink mnl1 on (mn1.node_id = mnl1.node_id and
                                 mnl1.close_date is null and
                                 mnl1.begin_cob_date <=
                                 TO_DATE('27-Oct-2010', 'DD-Mon-YYYY') and
                                 mnl1.end_cob_date >
                                 TO_DATE('27-Oct-2010', 'DD-Mon-YYYY'))
  left join marsnode mn2 on (mnl1.parent_id = mn2.node_id and
                            mn2.close_date is null and
                            mn2.type_id = 58412926883279)
 where i.instrument_id = id.instrument_id
   and i.instrument_vn = id.instrument_vn
   AND i.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
   AND i.close_action_id is null
   AND i.product_sub_type_id = 3
   AND i.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
    It is the execution plan
    --------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)|
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                   |  2026K|   407M|       |   509K (20)|
|   1 |  HASH UNIQUE                    |                   |  2026K|   407M|   879M|   509K (20)|
|*  2 |   HASH JOIN RIGHT OUTER         |                   |  2026K|   407M|       |   426K (23)|
|*  3 |    TABLE ACCESS BY INDEX ROWID  | MARSNODE          |   501 | 23046 |       |   239   (3)|
|*  4 |     INDEX RANGE SCAN            | FKI_38576_TYPE_ID | 10159 |       |       |    34   (6)|
|*  5 |    HASH JOIN RIGHT OUTER        |                   |  2026K|   318M|       |   425K (23)|
|*  6 |     TABLE ACCESS FULL           | MARSNODELINK      |   330 | 15510 |       |  6560  (16)|
|*  7 |     HASH JOIN RIGHT OUTER       |                   |  2026K|   228M|       |   419K (23)|
|*  8 |      TABLE ACCESS BY INDEX ROWID| MARSNODE          |   501 | 23046 |       |   239   (3)|
|*  9 |       INDEX RANGE SCAN          | FKI_38576_TYPE_ID | 10159 |       |       |    34   (6)|
|* 10 |      HASH JOIN                  |                   |  2026K|   139M|    34M|   418K (23)|
|  11 |       TABLE ACCESS FULL         | INST_DEBT         |  1031K|    22M|       |  1665  (30)|
*|* 12 |       TABLE ACCESS FULL         | INSTRUMENT        |  2062K|    96M|       |   413K (23)|*
--------------------------------------------------------------------------------------------------
    predicate info
     2 - access("MNL1"."PARENT_ID"="MN2"."NODE_ID"(+))
 3 - filter("MN2"."CLOSE_DATE"(+) IS NULL)
 4 - access("MN2"."TYPE_ID"(+)=58412926883279)
 5 - access("MN1"."NODE_ID"="MNL1"."NODE_ID"(+))
 6 - filter("MNL1"."CLOSE_DATE"(+) IS NULL AND "MNL1"."END_COB_DATE"(+)>TO_DATE('
            2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MNL1"."BEGIN_COB_DATE"(+)<=TO_DATE('
            2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
 7 - access("ID"."DEBT_PRIORITY_CLASS_ID"="MN1"."NODE_ID"(+))
 8 - filter("MN1"."CLOSE_DATE"(+) IS NULL)
 9 - access("MN1"."TYPE_ID"(+)=58412926883279)
10 - access("I"."INSTRUMENT_ID"="ID"."INSTRUMENT_ID" AND
            "I"."INSTRUMENT_VN"="ID"."INSTRUMENT_VN")
12 - filter("I"."PRODUCT_SUB_TYPE_ID"=3 AND "I"."CLOSE_ACTION_ID" IS NULL AND
            "I"."END_COB_DATE">TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
            "I"."BEGIN_COB_DATE"<=TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    Kind regards
    Aashish

    Aashish S. wrote:

    I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:

    I guess that the last part of the statement above is what you really need reach (i.e. improve the execution time of the query) and the query not using index is what you think as the 'cause' for the real "problem". I will try to answer the real 'problem '. Based on what you've posted, some comments/suggestions
    (1) your plan shows that the query should recover 2026 K lines. Are you sure you want to recover as many files? You can come back here on the "requirement".
    (2) continuous superior point-to-point, you can view the details of how long takes the query to run to the present and how long do you expect to take. Another of the most important details will be how will you measure the runtime of the query. With this large number of records, it is quite possible that more time is spent by simply transferring the results of the query to the 'client' that the actual time taken by server to run the query.
    (3) if what you posted is the order of the columns in the index on the table with INSTRUMENTS, then what evidence do will help you to run the query and how? The order of the columns indicate that none of the clues will be good enough and that seems to be the right choice.
    (4) your section descriptor States that filter the predicate on table to INSTRUMENTS generates 2062 K lines. The number of records exist in the table of the INSTRUMENT? You will need to have a record much more (not to mention other factors like the order of data in the table etc.) in the table to justify the indexed access to pick up these huge number of lines.
    (5) Finally, you can check if the tables and indexes used by the query statistics are up to date.

    I hope this helps.

  • If the INSTR function will not use the INDEX o?

    Hi all


    I have a querry as
        Select * from Tab1 Where Instr(Tab1.Col1,'XX') >0 ;
    Is simple index on column Col1. If we use the index will be used or full table scan will happen in this scenario?

    Please give me explanatory answer because I have doubts


    Dhabas

    Hello

    You must use the index function if you want to avoid the full table scan. Check this box

    SQL> create table tab1(col1 varchar(20))
  2  /

Table created.

SQL> insert into tab1 values ('XXAB')
  2  /

1 row created.

SQL> create index col1_idx on tab1(col1);

Index created.

SQL> explain plan for Select * from Tab1 Where Instr(Tab1.Col1,'XX') >0;

Explained.

SQL> set autotrace on
SQL> Select * from Tab1 Where Instr(Tab1.Col1,'XX') >0;
XXAB

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=5 Card=1 Bytes=12)
   1    0   TABLE ACCESS (FULL) OF 'TAB1' (TABLE) (Cost=5 Card=1 Bytes
          =12)

Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
         32  consistent gets
          0  physical reads
          0  redo size
        234  bytes sent via SQL*Net to client
        280  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL>  create index col1_idx2 on tab1(Instr(Col1,'XX'));

Index created.

SQL> Select * from Tab1 Where Instr(Tab1.Col1,'XX') >0;
XXAB

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=12)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TAB1' (TABLE) (Cost=2 Ca
          rd=1 Bytes=12)

   2    1     INDEX (RANGE SCAN) OF 'COL1_IDX2' (INDEX) (Cost=1 Card=1
          )

Statistics
----------------------------------------------------------
         28  recursive calls
          0  db block gets
         22  consistent gets
          0  physical reads
          0  redo size
        234  bytes sent via SQL*Net to client
        280  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL>

    Thank you
    AJ

  • Several tables can be joined by join the index?

    Hi all

    I know that join index can be performed in a single table. I was wondering can it be happened on more than one table?

    Thanks in advance

    Charlie

    Yes the knuckle of the index may be on a single table. If you see the indicator INDEX_JOIN you can see that you can specify a single tablespec, that means, that it can be on a single table.

Maybe you are looking for

  • Unable to partition Toshiba Stor.E Canvio

    Hi all Just bought a Stor.e Canvio hardrive 3 TB desktop. I use a Mac app, have formatted for Mac OS extended (journaled). I want to put 4 partitions on the disk as its to use for the backup. However, when I try to partition through disk utility, it

  • Satellite A300-MM1 - startup is very slow

    I bought 3 notebooks (Satellite A300-MM1) a month ago, but I noticed that they were all very slow at startup (boot).They took about 6 minutes until I saw the office and sometimes do not work. Satellite A300 MM1 (harman/kardon)Windows Vista Edition Ho

  • Pavilion 15-au505tx

    I would like to know which can support the maximum memory for HP Pavilion 15-au505tx. Referring to the specification, it indicates that the memory that comes with the system, but she did not mention the maximum memeory that the model can support that

  • Windows 8 driver for the Bluetooth device

    I have a HP Envy 4-1070el ultrabook and I installed Windows 8 a few days ago (maybe I'm going to upgrade to Windows 8. 1). I am struggling to find a driver for my Bluetooth device: it should be a Broadcom, because I installed the driver available her

  • XP - D: disk system recovery does not

    I need to do a system restore in XP Home Edition on a Dell computer where my D: drive does not work.  Is there a place on the Web sites where I can access this version of XP and provide my license number and the name and download it online, without g