index bitmap and separate key

Hi guys,.

If the separate keys is very low (for example 20) and my index finger has more than 12,000 lines, should I consider using a bitmap index instead?

Thank you

OracleGuy777 wrote:
But that say our table was very fragmented, would not--what it means that the bitmap index entries would be to store much more information than necessary? Say so we had a table with only 1000 entries and the first rowid is 1, and the last was 1000000 and then eventually we have 999000 additional entries for each bitmap index entry!

Bitmap indexes are well compressed. So, this usually isn't a problem. An example...

SQL> create table t as select rownum id from dual connect by level <= 1000000;

SQL> execute dbms_stats.gather_table_stats(user,'t')

SQL> select blocks from user_tables where table_name = 'T';

    BLOCKS
----------
      1557

SQL> delete t where id between 500 and 999500;

999001 rows deleted.

SQL> commit;

SQL> create bitmap index i on t (id);

SQL> select distinct_keys, blevel, leaf_blocks from user_indexes where index_name = 'I';

DISTINCT_KEYS     BLEVEL LEAF_BLOCKS
------------- ---------- -----------
          999          1           4

Notice how the index has only 4 blocks of leaves...

So you're saying something like

FEMALE 1 0 0 0 1 1 0 1 0 1 0 1 1 1 1 0 0 1 0 0 0 1

could be stored as

FEMALE 1 0 0 0 1 1 0 1 0 1 for rowid a to j
FEMALE 0 1 1 1 1 0 0 1 0 0 0 1 for rowid k - w

Yes.

HTH
Chris Antognini

Troubleshooting Oracle, Apress 2008 performance
http://top.Antognini.ch

Tags: Database

Similar Questions

Index Bitmap and MV in Standard edition
Salvation of DBA

I have an enterprise edition 10.2.0.3 database which can be transformed into 11.2.0.3 EE. There many Materialized view with activated query rewrite. If I downgrade to the standard edition, what will be the impact? I know the rewrite of the query is a feature of EA and not SE and SEO. It is also the index Bitmap in the database which I think must be re-created as the normal b-tree index.

I know that bitmap is not a feautre of the SE. One advantage that I see that updates will be faster if there is a normal index as DML are slow, if there is a Bitmap index.

What will be the impact on the performance of the database if there is standard edition which does not rewrite of the query and the characteristics of Bitmap?

Thank you

DBA is the hero behind the screen, while developers are heroes on the screen.
user13368428 wrote:
I went through this table before posting my first post. I don't know there are a lot of tables in my EE database that contains bitmap indexes. In the past, I turned on the control over some of them, and they have been used. Also, I have seen queries that are rewritten to use the MV table instead of the base of fact tables.

Yes. Really, I need to test in decommissioning and annexing the request to it. But I wanted to know if anyone has experienced this. What were their experiences do not use Bitmap indexes, function index and Query rewrite.

Your response was very useful.

Thank you.

The Oracle Server Standard edition supports function based indexes (I think since version 8.1.5). Bitmap indexes are not supported and treat B * index of tree as the index of the bitmap to bitmap join operations are also not supported. You can partially determine the impact of not having the second option by editing a hidden at the session level setting (obvious caveat on masked editing settings apply here):
```
ALTER SESSION SET "_B_TREE_BITMAP_PLANS" = FALSE;
```
I'm fairly certain that the Standard Edition supports materialized views - automatic query simply not rewrite for possibly enjoy this feature based on cost.

There may be a few other surprises, here is part 1 of 4 that explores the potentially unexpected differences between Standard Edition and Enterprise Edition (the differences are version and OPTIMIZER_FEATURES_ENABLED load):
http://hoopercharles.WordPress.com/2010/11/21/different-performance-from-Standard-Edition-and-Enterprise-Edition-1/

Good luck to you with the project.

Charles Hooper
http://hoopercharles.WordPress.com/
IT Manager/Oracle DBA
K & M-making Machine, Inc.

Index BITMAP and NOT NULL
Hi all
Is it possible to use the Index BITMAP for a NOT NULL condition?

>

CREATE a BITMAP of INDEX x_ix FOR tab (x);

SELECT *.
TAB
WHERE x IS NOT NULL

>

Thank you!
user3646231 wrote:
You say that :) to hope

Here it is:

Your test is a good effort - but it needs a little more.

Your question is "is it possible...". «, not "If Oracle always...» »

Your demonstration showed an example where the choice of plan Oracle has surprised you (and me). Now, you need run the query with index indicator (because if the indexed access path is legal, must be taken an indexed correctly suggested path).

I just ran a similar test (1 line of 100,000), with the following results:
```
SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
SQL_ID  52q6gxkscvg9v, child number 0
-------------------------------------
 select /*+ index(t1(n1)) */ * from t1 where n1 is not null

Plan hash value: 2828957992

----------------------------------------------------------------------
| Id  | Operation                    | Name  | Rows  | Bytes | Cost  |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |       |       |       |  1859 |
|   1 |  TABLE ACCESS BY INDEX ROWID | T1    |     1 |   118 |  1859 |
|   2 |   BITMAP CONVERSION TO ROWIDS|       |       |       |       |
|*  3 |    BITMAP INDEX FULL SCAN    | T1_N1 |       |       |       |
----------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("N1" IS NOT NULL)
```
You will notice that the cost of the query is unreasonable - and without the suspicion my test showed Oracle taking the full analysis at a much lower cost.
If your test has actually demonstrated a bug in the costing, explaining why Oracle does not automatically take a path that seems reasonable.

The above output comes from 11.2.0.3, but I had the same thing with 11.1.0.7

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle

B - Tree and explanation Index Bitmap

Hi gurus
I am trying to absorb the notion of bitmap index and b-tree, but unable to grasp the concept, so far, I have learned the following:
Index B-Tree
Use in the OLTP environment
It is customary for these types of columns where you have more unique value or we can say that high cardinality
It occupies less storage
Using the corresponding model and ranges
By default, Oracle uses tree indexing
Bitmap index
Use in home environment/OLAP data items
It is customary for these types of columns where repeated values exist or we can say that low cardinality, example are male and female
It seems that these points of difference between the two indexes. I really appreciate if someone give me more explanation on these subjects.
Thanks in advance
Concerning
Muzz

I am trying to absorb the concept index bitmap and tree but unable to grasp the concept,

Then the FIRST place to look is the Oracle documentation; specifically the chapter "Index and Index-Organized Tables" chapter of the Concepts doc.

http://docs.Oracle.com/CD/E25054_01/server.1111/e25789/indexiot.htm

3 indices and Index of Tables
This chapter deals with indices, which are schema objects that can speed up access to the lines of the table and organized index of tables, which are tables stored in an index structure.

This chapter contains the following sections:
- Overview of index
- Overview of the Tables organized by Index
This chapter has a lot of basic information on ALL the various types of indexes.

so far, I've learned the following:

Where, exactly, 'have you' who? Most of it is wrong, incomplete or distorted.

Index B-Tree

Use in the OLTP environment

Index B-Tree, by default, are used in all environments.

It is customary for these types of columns where you have more unique value or we can say that high cardinality

They can be used for a cardinality. True - a unique column index is most commonly used for high-cardinality columns. But Oracle may also use an index column, simple or composite, when the data being sought is ENTIRELY contained in one or more indexes, low cardinality.

It occupies less storage

Maybe, maybe not. It is based on the column being indexed, the size of the key values and the cardinality of the key values. For your example "Male and female" there will be only THREE index entries: male, female and null. And each entry is simply a list of ranges of ROWID. This index can be orders of magnitude smaller than the equivalent B-Tree index.

Using the corresponding model and ranges

For the most part correct - although the range queries can be used with the bitmap index which is not a common use.

By default, Oracle uses tree indexing

Fix.

Bitmap index

Use in home environment/OLAP data items

Especially correct - DML on tables with the bitmap index can cause severe performance and throughput problems. The distinction is therefore between environments with medium/high DML on a table compared to the weak or nonexistent DML on a table.

So rather than a distinction between environments (OLAP and warehouse) the distinction is no longer between the TABLES (high/medium DML versus LOW/NO DML). There is nothing wrong at all with the help of the index of the bitmap in an OLAP environment - but these indices should be limited to the tables with low, or no, DML.

It is customary for these types of columns where repeated values exist or we can say that low cardinality, example are male and female

Yes and no.

Yes - a bitmap index is not really appropriate, if there is NO repeat value.

No - part II (low cardinality). The attribute MAJOR missing from what you have posted is that bitmap indexes are ALMOST always used in conjunction with others (usually a bitmap) index.

If one, or more, high cardinality bitmap index can be used VERY effectively together to identify a set of rows to a query.

See my multiple responses in this thread

https://community.oracle.com/message/10219613?

One of my answers presents, in detail, just how many attributes can be combined using several bitmap on both high columns index and low cardinality.

In a later response, I provide the actual sample code and display the execution plan indicating how Oracle just that.

SQL> set serveroutput on SQL> set autotrace on explain SQL> select rowid from star_fact where 2 (state = 'CA') or (state = 'CO') 3 and (age = 'young') and (marital_status = 'divorced') 4 and (((summer_sport = 'baseball') and (softdrink = 'pepsi')) 5 or ((summer_sport = 'golf') and (beer = 'coors')));

Read the full thread.

Subscription to creative cloud and Acrobat key

Hi all
I work for a small company and have could Creative subscription. Recently, we purchased 2 licenses v12 of Adobe Acrobat pro. When you install Acrobat Pro on laptops, I had to log in or create an adobe account to use. Then I added the licenses to the account of creation, I already setup for us.
The questions is, I'm not able to use creative Cloud on my computer applications and other users use the Acrobat pro that we bought separate licenses for on 2 laptops. They are all related to our account only but are not allowed to connect more than two computers at the same time. What should I do to get everyone working because it is any lawful use of members and separate key purchases. Do I need to have another type of account to keep track of all licenses and the subscription/s that we have?
Please let me know if you need to provide additional information.
Thank you
Brandon

I think that you have to turn off and then install and activate with a different ID

Given that you have activated, you may need to perform a transfer of license

Transfer (sell or give away your software) https://forums.adobe.com/thread/1355892

This is an open forum, not Adobe support... Click below to contact Adobe staff for help

While the forums are open 24/7 you can't contact Adobe support at any time

Chat support: Mon - Fri 05:00-19:00 (US Pacific Time)<=== note="" days="" and="">

Don't forget to stay signed with your Adobe ID before accessing the link below

Creative cloud support (all creative cloud customer service problems)

http://helpx.Adobe.com/x-productkb/global/service-CCM.html

Index BITMAP Advisor Advisor access SQL on the Partition key
I ran SQL and SQL Access Advisor as below he recommends index bitmap on p_key... Given that the cust table is partitioned on the p_key, does make sense to create indexes on p_key?

Not sure if SQL Access Advisor look just in ' where clause conditions/predicates "and the cardinality of such columns and not look at whether the table is partitioned or not. T it?

Is it wise to create BITMAP indexes on the partition key? If so what scenario would be beneficial?
```
SELECT * FROM cust
WHERE 
    'T' = 'T' AND 
    part_key IN 
    (   2, 3, 4 )) AND 
    (   p_key, act_key) IN ( select p_key, act_key from account where act_type = 'PENDING' and p_key in (2,3,4) )
```
user4529833 wrote:
Jonathan, I have exactly one value per partition for the partition key. However, most SQLs use 'IN' as predicate of partitioning pruning so overall stats are always used and they are always a bit bland compared to the partition level stats. Then this led SQL Access advisor recommendations?

Yes, the Counselor also recommended to create Bitmap indexes on act_type... Given this does make sense to have the Bitmap index on the partition key?

I'll post the execution plan as soon as I have access to the system...

The fact that statistics are "a little stale" was not much of a difference.

The fact that Oracle has probably used statistics at the level of the tables is likely to be the underlying issue. Is the partitioned table list or you have rigged it with partitioning range: If you faked list partitioning using partitioning of the range which MAY have contributed to the issue (but it's an assumption that I have not tested).

Unofficially, the optimizer has said something like:

+ "There are 25 possible values for pkey, there are 4 possible values for act_type, there seems to be 100 different combinations - so your query will pick up X lines. 80% of these lines will be packed in Y blocks and 20% of them will be scattered through the Z blocks if we have two bitmap index, and we will have to do sequential reading of the db file SSS. If we do an analysis through the affected partitions, we do MMM db file scattered reads. What are those cheaper. » +

You know how false it's - if you know that you need not the pkey index. You also know what is the efficiency of the column act_type is in the identification of data, so you can decide whether or not an index on act_key may be useful.

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK

"The premature temptation to theories of shape on the lack of data is the scourge of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "the Valley of fear."

Indexes and foreign keys
Hi, we have a RAC Oracle 10 g 2 EE on SLES10.

I have tables with 300.000.000 of records. These paintings clues because it access it takes very very slow. I check what he need an index for each foreign key. I have a lot of tables and I'm looking for some tools or SQL or similar phrases that tell me, tables for each foreign key index. For example, I need to know what a lot of index left complete me the process and that it.

Table A
ID (PK)
B1_ID
B2_ID
C_ID
D_ID
...
...

(B1_ID, B2_ID) FK TO TABLE_B
(C_ID) FK IN TABLE C
(D_ID) FK TO TABLE_D

I create the index in table A, table B, but I don't have the index for the table C and table.

I have a lot of tables, with several foreign keys.
How can I find out what indexes that I need to create?

Thank you very much.
You can also refer to http://blog.go-faster.co.uk/2007/10/tm-locking-checking-for-missing-indexes.html

HTH
Anand

Index and foreign key referring to itself
Hello!

I'm working on an application that uses a basket stored in a database. The shopping cart uses two tables:
BASKET: Contains the common information for a shopping cart: the user is logged in etc.
-Primary key: CART_ID

CART_ROW: A line in the shopping cart, for example a new product to buy.
-Primary key: ROW_ID
-Foreign key: CART_ROW. References CART_ID CART. CART_ID

On the code lines in the basket are taken by cart, as is modeled by the foreign key. There is a relationship, that we use in the code, but which is not modelled by a foreign key in the database. A line can be dependent on another line, which makes the other row a parent.
CART_ROW has a PARENT_ID column that refers to CART_ROW. ROW_ID.
Would you add a foreign key to PARENT_ID? Or are there issues to consider when it is a foreign key to the same table?

Some time ago, we added the index, both ROW_ID PARENT_ID. The index on PARENT_ID could have harmful, since there is no foreign key?

Best regards!
user9005175 wrote:
Hello!

I'm working on an application that uses a basket stored in a database. The shopping cart uses two tables:
BASKET: Contains the common information for a shopping cart: the user is logged in etc.
-Primary key: CART_ID

CART_ROW: A line in the shopping cart, for example a new product to buy.
-Primary key: ROW_ID
-Foreign key: CART_ROW. References CART_ID CART. CART_ID

On the code lines in the basket are taken by cart, as is modeled by the foreign key. There is a relationship, that we use in the code, but which is not modelled by a foreign key in the database. A line can be dependent on another line, which makes the other row a parent.
CART_ROW has a PARENT_ID column that refers to CART_ROW. ROW_ID.
Would you add a foreign key to PARENT_ID? Or are there issues to consider when it is a foreign key to the same table?

I suggest to add the foreign key, it will not harm performance (except during an insert when there is validation of the foreign key). But it would avoid users to insert bad data / corrupted by code or directly on loggin in the database.

Some time ago, we added the index, both ROW_ID PARENT_ID. The index on PARENT_ID could have harmful, since there is no foreign key?

Index on parent_id would be dangerous if you do not use index after it is created (i.e. There is no application that can make use of this index).
And if you decide to have a foreign key parent_id then I suggest to have too many indexes on parent_id because it would be at least useful when you delete a record in this table.

Best regards!

Index bitmap for FKs on fact tables
Hi all

We have a database of DWH (Star Dimesions and the tables schema) running with OBIEE 11 g (11.1.1.1.6) on the oracle 11 g (11.2.0.1) database. I read in one of the best practical paper, creating index Bitmap on the Fks of all fact tables will help performance.

I created indexes for the less than 2500 separate keys, but we have 2 dimesions tables where there are great number of records (size 14 g and 10 g). Can I go ahead and create indexes of bitmap for 2 tables establishments (mainly account_key and customer_keys are the columns)?

Worried about creating index bitmap for large tables where they could affect the ETL process.

Ref: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-dw-best-practies-11g11-2008-09-132076.pdf (page 20)

Help, please.

Thank you and best regards,
Anand.
>
I created indexes for the less than 2500 separate keys, but we have 2 dimesions tables where there are great number of records (size 14 g and 10 g). Can I go ahead and create indexes of bitmap for 2 tables as well
. . .
Worried about creating index bitmap for large tables where they could affect the ETL process.
>
You put the cart before the horse!

Don't create index unless you have a reason documented for them.

Why did you choose the index bitmap for cardinality less than 2500? Perhaps based on a long-standing myth, but discredited on the cardinality?

See also Richard Foote two articles where he explodes the myths about bitmap indexes and considerations of cardinality
http://richardfoote.WordPress.com/2010/02/18/myth-bitmap-indexes-with-high-distinct-columns-blow-out/
http://richardfoote.WordPress.com/2010/03/03/1196/

Re your concern about the tables with the 'large' number of records and affecting ETL.

You are right to be concerned about these issues, but you need to document your particular situation taking into account the architecture.

The fact tables and dimension tables can have a large number of records. If using the bitmap index is indicated, then the most records are most effective, they will be.

ETL is affected because the DML (INSERT, UPDATE, DELETE) operations on the tables with bitmap indexes can have serious performance because of the involved serialization issues. Updated single bitmap of a column value (e.g., am ' to 'F' gender) requires that the two index bitmap blocks must be blocked until the update is complete. An index of stored bitmap ranges ROWID (rowid min - max rowid) that can span many, many files. The "range" of ROWID is locked in order to change a value.

To change: 'follow her' rowid beach so that a row is locked and ID should be removed from the range by turning off the bit. Change to the 'F', the rowid id range 'F' must be found, locked and the bit set that corresponds to this rowid. No another row with ROWID in the range cannot be changed, because it is a transaction in the series. If the range includes 1000 lines and they all need changed it takes 1000 series.

For anything other that a very small number of documents the bitmap index would be deleted and rebuilt after the ETL operations. That is why the data warehouse designs try to minimize update and implement insertions and deletions using partitioning when possible; Adding a new day by adding a new partition.

There is also a big difference between a bitmap index and a bitmap join index. The white paper you quoted does not really indicate what type are used or recommended.

Learn more about the difference - see Using Bitmap indexes in data warehouses in the doc of Data Warehousing
http://docs.Oracle.com/CD/B28359_01/server.111/b28313/indexes.htm

How to associate an index with a foreign key constraint
I understand how to associate a primary key constraint or a Unique key constraint index...
Yet I don't see how to associate the index of a foreign key constraint. Is this possible?

Thank you
Bob Larsen
Hi Bob,

In Data Modeler, physical model for Oracle primary and unique keys dialog boxes offer an Index field using, which is used to generate the 'using_index_clause' in the DDL for primary and Unique key constraints.
However the Oracle Database DDL does not have the "using_index_clause" for Foreign Key constraints, thus Data Modeler does not provide this feature for foreign keys.

So, you will need to create a separate Index that uses the same columns as the foreign key (using the index page of the table properties dialog box in the relational model).

David

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

type of index on a primary key
HI.i want to know the type of index that is automatically created by oracle on primary key and foreign key. Please rpely as soon as possible.
Hello

This means that it is a B * Tree rather than the Bitmap index.

Mike

Can I have separate keys of singing for BlackBerry PlayBook?

Hi all

I have Blackberry signature keys, but in an article that I heard that it is separate keys required for the Blackberry Playbook of signature development applications is it true?

If not can I use same signature keys for this tablet also?

in fact, I have a Playbook with me, that's why I ask you and I want to convert my Blackberry Playbook app android app please check below link for FYI.

https://bdsc.webapps.BlackBerry.com/Android/BPAA/user-identification

Kiran.

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

I give glory for each answer

HI Kiran_b,

you are right that the application device playbook and BlackBerry have different signing keys.
You cannot use blackberry sign button for Playbook.
In fact in the blackberry device you must sign the playbook and .cod files you must sign the .bar file.

--------------------------------------------------------------------
Please mark as resolved messages if you found a solution.
Feel free to press the Bravo thank the user who has helped you.

Windows 7 - separate keys?

I have a laptop that came with Windows 7 preinstalled, and it was installed at the factory, so it is activated with the key by the manufacturer. It also has a product key different on the certificate of Authenticity on the back. Is it legal to use this key (a separate key) to install a second installation of the same version of Windows 7? Thank you.

No, the key on the bottom is for this laptop only. "Key to manufacturing" is the key installed at the factory and also used by the recovery partition (if you have one) on your hard drive.

The key on the bottom should be used with recovery media or download the ISO used to make an installation DVD.

Even if the second installation is on the same computer (separate partition), create a computer 'Dual Boot' is still not legal.

J W Stuart: http://www.pagestart.com

table partitioned and unique keys

I really don't understand why Oracle does not apply in some cases, unique keys.
Let's say I have a table

create table t (t_type not null, t_key not null, id not null, not null value)

list partition (t_type)

(

type1 partition values ('ppp1"),

rest of partition (default) values

) as

Select "ppp" | rownum, rownum, rownum, rownum of double connect by rownum < = 100;

And following changes in the indices for unique keys

-1

create index idx_1 on t (t_key, id);

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

ALTER table drop constraint t_uk drop index;

-2

create index idx_1 on t (t_key, id, t_type);

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

ALTER table drop constraint t_uk drop index;

-3

create index idx_1 on t (t_key, id, t_type) local;

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

Drop index idx_1;

-4

create an index only idx_1 on t (t_key, id);

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

Drop index idx_1;

-5

create an index only idx_1 on t (t_key, id, t_type);

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

Drop index idx_1;

-6

create an index only idx_1 on t (t_key, id, t_type) local;

ALTER table t add constraint t_uk unique (t_key) using index idx_1;

Drop index idx_1;

-7

create index idx_1 on t (t_key, t_type, id) local;

ALTER table t add t_uk unique constraint (t_key, t_type) using index idx_1;

ALTER table drop constraint t_uk drop index;

-8

create an index only idx_1 on t (t_key, t_type, id) local;

ALTER table t add t_uk unique constraint (t_key, t_type) using index idx_1;

Drop index idx_1;

I got the set of questions:
1. first and second cases were performed with success while 4th and 5th failed.
The only difference is that the overall index in 4th and 5th cases are unique.
It is unclear why ' ORA-14196: specified index cannot be used to apply the constraint. ' has occurred.
2. in the third case index is similar to that in second place with the only difference that it is local.
Still, it is not clear why it failed with ORA-14196.
3 and the last question why ORA-14196 arose in 8 cases, while the 7th, it didn't.
The only difference is the local index in 8 cases is unique.
Thank you

Hi Alex

(1) index 4 and 5 cannot be used to police the unique constraint as a unique index must have the same list of column under duress. Index 4, to establish in a non-unique index or to remove the column id of the index. To index 5, you will need to make a non-unique index or remove the columns id and index t_type.

(2) 3 index cannot be used to the unique constraint of police that it is a local index and is not partitioned column (t_type) in both the definition of index/constraint. If allowed, this would require Oracle having to visit each partition to ensure that any new value of t_key is truly unique, that would not scale. Include the t_type column in the constraint and the index to both t_type and t_key as of the columns (so move the id column 3rd position) and it would be successful.

(Index 3) 8 fails for the same reason as in 1). It's a unique index with a different column from the constraint list. Remove the id column of the index or to make it a non-unique index and it will be successful.

In summary, a unique index MUST have the same list of column than the constraint and a local index MUST have the partitioning columns in both the definition of index/constraint.

See you soon

Richard Foote

http://richardfoote.WordPress.com/

index bitmap and separate key

Similar Questions

3 indices and Index of Tables

Maybe you are looking for