Statistics updated after creating indexes

Hello

Version: 11g

Oracle will update statistics after the creation or modification of index?

Thank you.

Yes, when automatic CBO stat collection runs.

I usually deliver a

ALTER INDEX  COMPUTE STATISTICS;

After the index created.

Tags: Database

Similar Questions

Analyze tables after creating indexes

Hi all

I created new clues on the production environment, we must analyze tables after creating indexes. Why and what analysis do?

Thanks for the help.

Select * from V$version;

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE     10.2.0.4.0     Production"
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

There are so many different options and you'll certainly want to tweak your stats based on your system.
The best thing to do is to read about dbms_stats:
http://download.Oracle.com/docs/CD/B19306_01/server.102/b14211/stats.htm#PFGRF30102
http://download.Oracle.com/docs/CD/B19306_01/AppDev.102/b14258/d_stats.htm#CIHEHDFB

Here are a few examples to give you an idea of what they look like and how to perform:

BEGIN
  DBMS_STATS.GATHER_TABLE_STATS(OWNNAME          => 'schema_name',
                                TABNAME          => 'table_name',
                                ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE, --> For really big tables oracle can just do a specific percent
                                METHOD_OPT       => 'for all columns size 1', --> Defines Histograms, size one disables histograms
                                DEGREE           => 12, --> The degree of parallelism so you'll see 12 parallel threads gathering stats
                                CASCADE          => TRUE); --> gather stats on the table's indexes also
END; 

BEGIN
  DBMS_STATS.GATHER_INDEX_STATS(OWNNAME          => 'schema_name',
                                INDNAME          => 'index_name',
                                ESTIMATE_PERCENT => 50,
                                DEGREE           => 4);
END;

You can also do

DBMS_STATS.gather_schema_stats
DBMS_STATS.gather_database_stats

and much more...

I really want to focus on the need to do your homework on them,
read the docs I linked and adjust your statistical parameters to fit your db objects and how they are accessed/used.
Having accurate and meaningful statistics are very important to the performance of the database.

need to reinstall updates after reformat

I have to go to the cumbersome process of reinstall all updates when I reformat the hard drive of my laptop?

Lenovo has created three partitions on the hard drive installed. The smallest drive C contains Windows and software pre-installed. And I was told that the C drive should NOT be resized if not the OneKey recovery no longer work. But we are given the D drive which is MUCH bigger to contain all my personal data.

updates take up a lot of my disk drive of the insignificant C, 19 GB space, which, in the end, let me about 700 MB to work with installing progs more. with do I find n reinstall every single update after reformatting the hard drive or do a system restore point? in this way he doesn't eat any more space in my C drive good?

If not, grateful if you can advice me how to handle this accordingly.

Hello Vanity.sha,

Thanks for your reply. A new installation of any operating system takes about 2-4 GB of space in the partition & after OneKey recovery on system should have been about 75% of free space available. I think there could be some unwanted files & folders on your system, so try to free the C: drive & then try to deploy the update for Vista.

In addition, Microsoft & 3rd-party application has the ability to store the program files on all available disks, you can install these applications depending on the free space.

I hope this helps.

[If this post can help solve your problem, click on the button 'Mark as answer' or 'Useful' at the top of this message.] [Marking a post as answer, or relatively useful, you help others find the answer more quickly.]

--

Why my virus program esetnod 32 guard tell me that my system is not updated after you install the update of all the nessary?

Why my virus program esetnod 32 guard tell me that my system is not updated after you install the update of all the nessary?

I have download all necessary Windows 7 updates, but they are not installed. Can anyone help?

Kind regards

Mitch

Hi Mitchell,

Please uninstall and reinstall the ESET program and check if it solves the problem:

Uninstall or change a program

http://Windows.Microsoft.com/en-us/Windows7/uninstall-or-change-a-program

For further assistance:

ESET knowledge base

http://KB.eset.com/esetkb/index?page=home&locale=en_US&option=None

Please post us with the result.

CREATE INDEXES online is waiting for the TX = 4 mode

Hello
I have a strange blocking problem where an INDEX CREATE LINE is waiting for a transaction that did only inserted a line in the parent table.
Wait is mode TX = 4 (not TM locks) and I currently have it reproduced only on 11.2.0.3 and 11.2.0.4
Easy to replicate the schema SCOTT:
Session 1:
SQL > set time on
14:54:58 SQL > insert into SCOTT. Dept (DEPTNO, dname) values (50, 'test');
1 line of creation.
Session 2;
14:55:24 SQL > create index test on SCOTT. EMP (ename) online;
It's waiting ' enq: TX - line lock conflict ":"
SQL > select sid, chain_signature from v$ wait_chains where blocker_is_valid = 'TRUE '.
SID CHAIN_SIGNATURE
---------- ----------------------------------------------------------------------
603 ' SQL * Net client message' < ='enq: TX - line lock conflict '
While waiting to acquire the lock of transaction in mode 4:
SQL > select * lock gv$ where sid = 603
INST_ID SELECT ADDR KADDR SID TYPE ID1 ID2 LMODE CTIME BLOCK REQUEST
---------- ---------------- ---------------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
1 00000006CDA05EB8 00000006CDA05F10 603 352577 0 4 0 348 2 AE
1 00000006CDA06078 00000006CDA060D0 603 DL 779505 0 3 0 308 2
1 00000006CD9FABE0 00000006CD9FAC38 603 DL 779505 0 3 0 308 2
1 00007F28001F5028 00007F28001F5088 603 779505 0 2 0 308 2 TM
1 00007F28001F5028 00007F28001F5088 603 779510 0 4 0 308 2 TM
1 00000006CD9FA240 00000006CD9FA298 603 779505 0 4 0 308 2 OD
1 00000006B4F26790 00000006B4F26808 589847 711499 6 0 308 2 TX 603
1 00000006CDA0ED68 00000006CDA0EDC0 655377 996169 0 4 308 TX 603 0
I've traced 10046 and 10704:
broadcast message = obj 29231196672 #= 779514 tim = 1447251053634045
ksqgtl * mode TX-000f001e-000ad97c = 4 flags = 0 x 10001 timeout = 21474836 *.
ksqgtl: xcb = 0x6bb322528, ktcdix = 2147483647, topxcb = 0x6bb322528
ktcipt (topxcb) = 0 x 0
ksucti: init logon has of txn DID:
ksqgtl:
ksqlkdid: 0001-003F-0000AFC4
ksudidTrace: ksqgtl
ktcmydid(): 0001-003F-0000AFC4
ksusesdi: 0001-003F-0000AFC3
ksusetxn: 0001-003F-0000AFC4
ksqcmi: TX, f001e, ad97c mode = 4 timeout = 21474836
2015-11-11 15:11:36.566
WAITING #140700792578680: nam ='enq: TX - line lock conflict ' ela 42932082 name = | mode = 1415053316 usn < < 16 | location = sequence 983070 = obj 711036 #= 779514 tim = 1447251096566283
And there is nothing in V$ SESSION leader/block/line current. class obj # is EMP. current sql_id is the CREATE INDEX.
If anyone has an idea on:
-Why creating an index in line must wait for transactions that modified only parent table
-How to continue the investigation
-can or cannot reproduce in other versions
Thanks in advance,
Franck.

I guess you have a constraint foreign key between emp and Dept.

It's expected behaviours: since 11.1 any DML at one end of a referential integrity constraint translates into a mode lock 3 taken at the other end, and your phenomenon resembles a side effect of this.

When you try to create the index online that your session must assume that the other session (holding mode 3 on the emp and dept) may have changed the emp and dept, so it must wait for the session to the commit or rollback.

(I guess that in principle, he could walk the cancellation of the transaction see if EMP had in fact been changed - but maybe who was considered too complicated to be worth the risk to implement)

Concerning

Jonathan Lewis

Updated - I just did a quick check to reproduce the effect on 11.1.0.7

For reference - here are a few notes on modes of locking and how the application has changed over time: https://jonathanlewis.wordpress.com/2010/06/21/locks/

Performance problem of creating index with LOB/CLOB content

Hello

I have a problem with indexing performance with a table containing columns of text
also a clob and a lob column.

Indexing with 20,000 lines takes about 1 hour on 11.2.0.4 with the last batch of patches 12 on
win x 64.

on a 11.2.0.1, the process is done in a few minutes.

So what can I do to find out where is the problem?

I use filter auto and basic lexer.
Operating system is W 2008 R2 SP and latest patches. OS lang is English.
DB is installed with AL32UTF8 and German and English language packs.

also watched and ctx_user_index_errors and pending and there is no error or waiting in lines.
After the index is created, everything works fine. during the creation of index no other user is connected to the database.

so why 11.2.0.1 is so much faster than 11.2.0.4?
some advice for me?

Thank you!

Hello

so I solved all my problems.

So I made two changes:

1. I declared the variable theNotiz2 for recording the output for the raw text of the column NOTIZ (is a clob), add the output to the Out-Clob parameter

2. I used the same variable for the--> this blob field caused an error with line with lob is not locked... so I said a second variable for this and that solved the problem.

normally, I think it should work with 1 variable... but is an acceptable workaround.

Performance now is OK because the procedure, I can set on which the documents I want to do a search or not.

Second thing, but has nothing to do with Oracle: my frontend application makes a ZIP for each insert in a column lob and if the ctxhx does not index the content, the MDC, and before calling the conversion of plain text, so I have to make a decompression of the blob...

so for now, all problems solved. Thank you for your support.

How to create indexes of service according to

Hi all
I already post a thread associated with this thread, but there is little difference in the two threads.
I had a query as below:
Select concept_Un, raw_concept_a, relation_name, concept_b, discovered_relations raw_concept_b, where lower (concept_a) like '% of consumers' and lower (concept_a) like '% confidence % ';

This query taking too long to run and its high rating.
cost and execution time: 1155K and 03:51:11
I changed above query using the Forum gurus, below query is changed:

Select concept_Un, raw_concept_a, relation_name, concept_b, raw_concept_b
of discovered_relations
where regexp_instr (concept_Un, ' (consumer.*confidence) |) ((confidence.*Consumer))', 1, 1, 1, 'i') > 0;
I created indexes for query modified as well:
creating index SIDEV. IDX_reg_instr on SIDEV. DISCOVERED_RELATIONS (REGEXP_INSTR ("CONCEPT_A",'(consumer.*confidence) |)) (confidence.*Consumer))', 1, 1, 1, 'i'));
After that the cost and time to get request reduces to:
After optimization: 40001 and 08:01
Now the question is whenever my request will vary as a condition, this means that search string can be vary to any value.
So I need a basic index as function above is the index which can work for any string in the like operator, now my created index only works very well for the fixed string...
Thank you

Abbas85 wrote:

Hi Chris,

Thank you very much its working well, now, to reduce the cost and duration of execution, I used below queries as you suggest:

create index idx_fulltext on discovered_relations (concept_a) indextype is ctxsys.context;

Select * from discovered_relations

where contains (concept_a, 'Confidence') > 0 and contains (concept_a, 'Consumer') > 0;

Hello

No, you didn't.

The query I used was

Select str

of test_idx

where

contains (str, '% of the CONSUMPTION and CONFIDENCE %') > 0

If you read carefully, you'll notice that I used already found lowercase uppercase searchwords.

This works because the oracle text case insensitiv default you can read documentation:

"By default, all text tokens are converted to uppercase and then indexed. This

results in case-insensitive queries. For example, separate queries for each of

the three words, CAT cat,

"and Cat all return the same documents.

Indexing with Oracle Text

If you have more to use tiny but need to start to read the oracle text docs ;-)

Tutorial to update after effects CC 2015?

When will there be an update after effects CC 2015 tutorial?

Which is just tell you that the file was created with an older version of After Effects. It will always open the file and work very well. You don't have to convert anything; After Effects will do it automatically.

Creating INDEX on a BLOB column in a separate tablespace

Hello

Our database contains 2 storage spaces :
-Tablespace DATA : is reserved to hold the data.
-Tablespace INDX: is reserved to hold the index.

For some reason, that we must create the indexes on columns of type blob and the pending order are:
SQL > CREATE INDEX my_index ON DOC_CONTENTS (doc_content) INDEXTYPE IS CTXSYS. CONTEXT; / / doc_content a blob type.
SQL> index created
Now, all indexes are created in the tablespace for DATA that is not good, they should be created in the tablespace INDX (now is empty)
For this reason, and after a search, I specified the tablespace INDX , which will contain the index, and the used command is:
SQL > CREATE INDEX my_index ON DOC_CONTENTS (doc_content) INDEXTYPE IS CTXSYS. CONTEXT TABLESPACE INDX;
*
ERROR on line 1:
ORA-29850: invalid option for creating domain index
NB: also, when I try to use the same command with varchar column, it works.
SQL > CREATE INDEX my_index ON DOC_CONTENTS (doc_name) TABLESPACE INDX; / / doc_content a type VARCHAR2.
SQL> index created

Do you have an idea on how to create indexes on a blob column in a different tablespace?

This question has nothing to do with the Oracle objects, but is related to Oracle Text, then perhaps that some moderator moves text objects.

To specify a storage space for a ctxsys.context Oracle Text index domain index tables, you must create a storage preference, specify storage spaces in attributes of this preference, then use this preference in settings of creating index. Please see the example below which shows first create domain index tables in the default users tablespace, then the creation of the field tables to be indexed in the example tablespace.

Scott@orcl_11gR2 >-test environment:

Scott@orcl_11gR2 > doc_contents CREATE TABLE

2 (doc_content BLOB)

3.

Table created.

Scott@orcl_11gR2 > INSERT INTO doc_contents VALUES

2 (UTL_RAW. CAST_TO_RAW ("test data"))

3.

1 line of creation.

Scott@orcl_11gR2 >-create domain index tables in default users tablespace:

Scott@orcl_11gR2 > my_index CREATE INDEX

2 doc_contents (doc_content)

3 INDEXTYPE IS CTXSYS. FRAMEWORK

4.

The index is created.

Scott@orcl_11gR2 > SELECT index_name, nom_tablespace

2 FROM user_indexes

3. WHERE index-name LIKE '% MY_INDEX % '.

4.

INDEX_NAME TABLESPACE_NAME

------------------------------ ------------------------------

MY_INDEX

DR.$ MY_INDEX$ X USERS

2 selected lines.

Scott@orcl_11gR2 > SELECT table_name, nom_tablespace

2 FROM user_tables

3 WHERE table_name LIKE '% MY_INDEX % '.

4.

TABLE_NAME, TABLESPACE_NAME

------------------------------ ------------------------------

DR. MY_INDEX$ I HAVE USERS

USERS R DR$ MY_INDEX$

DR.$ MY_INDEX$ N

DR.$ MY_INDEX$ K

4 selected lines.

Scott@orcl_11gR2 >-creating the tables index field in example of tablespace:

Scott@orcl_11gR2 > my_index DROP INDEX

2.

The index is deleted.

Scott@orcl_11gR2 > start

2 ctx_ddl.create_preference ("mystore', 'BASIC_STORAGE'");

3 ctx_ddl.set_attribute ("mystore', 'I_TABLE_CLAUSE',")

4 "tablespace storage example (original 1 K) ');

5 ctx_ddl.set_attribute ("mystore', 'K_TABLE_CLAUSE',")

6 "tablespace storage example (original 1 K) ');

7 ctx_ddl.set_attribute ("mystore', 'R_TABLE_CLAUSE',")

8 ' lob tablespace storage example (original 1 K)

9 (data) store as (storage off in row cache)');

10 ctx_ddl.set_attribute ("mystore', 'N_TABLE_CLAUSE',")

11 "tablespace storage example (original 1 K) ');

12 ctx_ddl.set_attribute ("mystore', 'I_INDEX_CLAUSE',")

13 ' example of tablespace storage (initial 1 K) compress 2 ');

14 ctx_ddl.set_attribute ("mystore', 'P_TABLE_CLAUSE',")

15 "tablespace storage example (original 1 K) ');

16 ctx_ddl.set_attribute ("mystore', 'S_TABLE_CLAUSE',")

17 "tablespace storage example (original 1 K) ');

18 end;

19.

PL/SQL procedure successfully completed.

Scott@orcl_11gR2 > my_index CREATE INDEX

2 doc_contents (doc_content)

3 INDEXTYPE IS CTXSYS. FRAMEWORK

4 PARAMETERS ('STORAGE mystore')

5.

The index is created.

Scott@orcl_11gR2 > SELECT index_name, nom_tablespace

2 FROM user_indexes

3. WHERE index-name LIKE '% MY_INDEX % '.

4.

INDEX_NAME TABLESPACE_NAME

------------------------------ ------------------------------

MY_INDEX

DR.$ MY_INDEX$ X FOR EXAMPLE

2 selected lines.

Scott@orcl_11gR2 > SELECT table_name, nom_tablespace

2 FROM user_tables

3 WHERE table_name LIKE '% MY_INDEX % '.

4.

TABLE_NAME, TABLESPACE_NAME

------------------------------ ------------------------------

DR. MY_INDEX$ I EXAMPLE

DR.$ MY_INDEX$ R EXAMPLE

DR.$ MY_INDEX$ N

DR.$ MY_INDEX$ K

4 selected lines.

Post edited by: BarbaraBoehmer (corrected for error due to the already existing preference)

Create indexes is not replicated
Hi all

I'm able to replicate insert, create table, update, delete but unable to replicate creating index. I can see the index on the source but I'm not on the target

Source 2003 Server 10 gr 2 target 2008 GR 11, 2 11.1.1.1.2 goldengate Server

my setting replicate file looks like this:

REPLICAT REP1
Username ggt_sys PASSWORD ggt_sys
DISCARDFILE c:/goldengate/dirdat/rep1.dsc, append, megabytes 10
By default REPERROR, throw
ASSUMETARGETDEFS
DDL INCLUDE ALL
DEFAULT DDLERROR IGNORES RETRYOP
MAP SAM.*, TARGET SAM.*;

Target error log:

11:24:43 OGG - 01407 Oracle GoldenGate for Oracle, REP1.prm delivery INFO: current schema setting for the [sam] DDL operation.
2012-05-24 11:24:44 OGG - 01407 Oracle GoldenGate for Oracle, REP1.prm delivery INFO: current schema setting for the [sam] DDL operation.
2012-05-24 11:24:44 OGG - 01408 Oracle GoldenGate for Oracle, REP1.prm delivery INFO: restoration of current schema for DDL to [GGT_SYS] operation.
2012-05-24 11:26:27 WARNING OGG - 00869 Oracle GoldenGate for Oracle, REP1.prm delivery: no unique key is defined for the SAMPLE4 table. All viable columns will be used to represent the key, but cannot guarantee the uniqueness. KEYCOLS can be used to set the key.
2012-05-24 11:32:31 OGG - 01407 Oracle GoldenGate for Oracle, REP1.prm delivery INFO: current schema setting for the [sam] DDL operation.
2012-05-24 11:32:32 INFO OGG - 01407 Oracle GoldenGate for Oracle, REP1.prm delivery: current schema setting for the [sam] DDL operation.
2012-05-24 11:32:32 INFO OGG - 01408 Oracle GoldenGate for Oracle, REP1.prm delivery: restoration of current schema for DDL to [GGT_SYS] operation.

report file:

2012-05-24 11:24:43 current schema INFO OGG-01407 setting for DDL operation [SAM].

2012-05-24 11:24:44 current schema INFO OGG-01407 setting for DDL operation [SAM].

2012-05-24 11:24:44 INFO OGG-01408 restore the current schema for DDL to [GGT_SYS] operation.

Resolved generic mapping (SAM.* entry):
SAM CARD. SAMPLE4, SAM OF THE TARGET. SAMPLE4;

2012-05-24 11:26:27 WARNING OGG-00869 No. unique key is defined for the SAMPLE4 table. All viable columns will be used to represent the key, but cannot guarantee the uniqueness. KEYCOLS can be used to set the key.
By using the following in the default mapping, the columns by name:
MOHAMED, SPACE, GEOMETRY, ID, MAP_DISPLAY, FEATURE_TYPE_CODE

Using the following key columns for the table target SAM. SAMPLE4: MOHAMED, THE ID OF THE BOX, MAP_DISPLAY, FEATURE_TYPE_CODE.

2012-05-24 11:32:31 the current schema INFO OGG-01407 setting for DDL operation [SAM].

2012-05-24 11:32:32 current schema INFO OGG-01407 setting for DDL operation [SAM].

2012-05-24 11:32:32 INFO OGG-01408 restore the current schema for DDL to [GGT_SYS] operation.

Thanks in advance...
Add 'REPORT' to your DDLOPTIONS online extract and replicat. Start again and do some tests of the index to create another. Paste the report file to extract and replicat here.

alternative to delete and re-create indexes
Hi all

We use Oracle 11.2.0.2. We have a script where we fall before the full update of a table, the indexes and re-create indexes to improve performance.

Rather than a drop and recreate indexes, I wanted to know if there's another approach better to achieve performance gains.

I thought make unusable index and rebuild later. Would it not be better to drop and re-create the index.

Thanks for your time.
>
I thought make unusable index and rebuild later. Would it not be better to drop and re-create the index.
>
This is exactly the right strategy to use. He does need to get the benefit of the performance, and there is no danger of inadvertently re-create the index with the wrong settings or in the wrong table space.

See understanding when to use unusable index or Invisible in the DBA Guide
http://docs.Oracle.com/CD/E11882_01/server.112/e25494/indexes002.htm#CIHJIDJG
>
Unusable index

An unusable index is ignored by the optimizer, and is not maintained by DML. One of the reasons to make an unusable index are to improve the performance of loading in bulk. (Loads in bulk, go faster if the database is not required to manage the index when inserting rows.) Instead of letting fall the index and later re-creation, requiring you to remember the exact parameters of the CREATE INDEX statement, you can make the index unusable and then rebuild.

waitForUpdates method does not detect updates after reset of the connection

Hello
In my case, I use waitForUpdates() method to detect the VMotions (. i.e. whenever a VMotion arrived I have trying the GET the update using this method). It works perfectly in case of normal use.
But all of a sudden after a reset of VC connection. This waitForUpdates() method makes me not updated.
When the session id gets modified waitForUpdates (propertyCollector, version) would also have a new propertyCollector object (to give you the new collector of property obtained with the new connection object), so even now why it does not return me the updates after the reset of the connection.
Please let me know if I'm doing something wrong in the treatment of this.
Please let me know how to handle the connection reset and collect updates later. Which can affect the waitForupdates in updates outside the collector property object to return.
I even tried with the checkForUpdates method was the same behavior.
Thanks in advance.

Please check if you create the PropertyFilter after reset connection. Good initialization of the filter property should solve your problem.

Thank you

Aditya

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:
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

Section 1 after the index in the output printed in ROBOHELP 8

Hello
In ROBOHELP 8 times printing is complete (standard order, title, table of contents, index of chapters, glossery) it appears a heading 1 empty line after the index.
This isn't a problem with the standard model, but if a style is used where the headers are numbered and highlighted by different coloiurs the loooks line odd. The number is also included in the table of contents as an empty entry.
Is it possible to stop this line of the topic being created?
Concerning
Dave White

If you don't find an answer, please post a link here.

See www.grainge.org for creating tips and RoboHelp

@petergrainge

When creating index table lock?
Hello

My db is oracle10g. My database is OLTP system. I wanted to create the index on one of the table. The table has 200 million recordings.

It locks the whole when table I create index? I think, its impact on the regular operations of the database when creating the index?

Any help is appreciated...
Hello

You have Enterprise Edition? If so, the online option is available.

So you can do:
```
create index my_new_index on my_tab(col1,col2) online;
```
or:
```
alter index my_existing_index rebuild online;
```
If you are not using the online option, then Yes, the table will be locked for updates, all traffic OLTP will serialize buttocks the index maintenance operation.

Hope that helps,

-Mark

Statistics updated after creating indexes

Similar Questions

Maybe you are looking for