of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: When does Oracle use 'Index Fast Scan'
Correction: the Index Range Scan can be parallelized when it involves
multiple partitions.
- Dave
David Hau wrote:
I assume you're talking about the Fast Full Index Scan. This is used
when
Logical and Physical I/Os.
test it and hint your queries
From: David Hau [EMAIL PROTECTED]
Date: 2004/01/26 Mon PM 10:34:25 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: When does Oracle use 'Index Fast Scan'
Correction: the Index Range Scan can be parallelized
One situation I can think of where a (non-fast) full index scan can be
helpful is when the index contains all the columns needed for the query,
the query requires all the rows of the table, and the query requires the
results to be sorted according to the index. This way, fast full index
scan
This is where the access time of your disks (or SAN) makes a difference.
If your disks have really fast access time, then a random-access
pattern would not cause much performance degradation and so a range scan
would not be slow at all, even though it's traversing the b-tree index
structure
Another situation where index full scans might be handy, would be where hash
joins are disabled and sorted output can be used for fast sort-merge join.
Btw, multiblock reads are available for regular index range and full scan
under some specific conditions as well - I'm talking about readahead
This is where the access time of your disks (or SAN) makes a difference.
If your disks have really fast access time, then a random-access
pattern would not cause much performance degradation and so a range scan
would not be slow at all, even though it's traversing the b-tree index
structure
i found numerous cases(I dont have them in front of me) when fast full scan incurred
far more logical I/Os than an index range scan.
I found this particularly for oltp type get 10 records transactions. However, I forced
an index_ffs once and it increased my logical I/Os by 30% but decreased my
my question pertains to regular 'index full scans' NOT index fast full scans.
any ideas? I rarely ever find this to be an optimal index access method for anything.
From: Tanel Poder [EMAIL PROTECTED]
Date: 2004/01/27 Tue AM 11:19:27 EST
To: Multiple recipients of list ORACLE-L [EMAIL
Yes, and my reply was about regular index full scans, according to your
question.
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 6:59 PM
my question pertains to regular 'index full scans' NOT index fast full
PROTECTED]
Sent by: [EMAIL PROTECTED]
01/27/2004 08:54 AM
Please respond to ORACLE-L
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Re: When does Oracle use 'Index Fast Scan'
This is where the access time of your disks (or SAN) makes a difference
ive found that index_ffs typically incur higher logical I/Os that index range scans.
so its not just access speeds.
From: David Hau [EMAIL PROTECTED]
Date: 2004/01/27 Tue AM 11:54:26 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: When does Oracle use 'Index
An index fast full scan and an index full scan both need to access all
the blocks of an index. The only difference between them is that the
index_ffs accesses the blocks in the order of the blocks (and uses
multiblock read), whereas the index_fs accesses the blocks in the order
of the b tree
i thought an index_fs only read 1 block per i/o? same with an index range
scan because they are using random access?
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 5:29 PM
An index fast full scan and an index full scan
this is so is
because the CBO does not know whether the block is already in the buffer
cache or not. If it's already in the cache, then multiblock read is not
an issue anymore.
The init parameter db_file_multiblock_read_count is what makes the CBO
favor fast full index scan over a non-fast scan
I have found that the vast majority of time that
Oracle chooses this method, my statistics are stale and the query is
sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan
with a FIRST_ROWS hint and this reduced performance.
This is just a full scan of the index
sorry typo. I mean 'Index Full Scan'
- Original Message -
From:
Ryan
To: Multiple recipients of list ORACLE-L
Sent: Monday, January 26, 2004 9:24
PM
Subject: When does Oracle use 'Index Fast
Scan'
I have found that the vast majority of time
I assume you're talking about the Fast Full Index Scan. This is used
when the index contains all the columns necessary to answer the query.
It's faster than a Full Table Scan because indexes are smaller than
entire rows, so a Fast Full Index Scan will scan fewer blocks than a
Full Table Scan
Correction: the Index Range Scan can be parallelized when it involves
multiple partitions.
- Dave
David Hau wrote:
I assume you're talking about the Fast Full Index Scan. This is used
when the index contains all the columns necessary to answer the query.
It's faster than a Full Table Scan
I would check which index is being reported as
unusable, and check the access path for the
query when all indexes are useable.
Since you have a statement level trigger, I suspect
Oracle is producing an execution plan that dictate
the use of index X.
The plan executes, which means the trigger
dropping indexes on tables that
exceed their quota?
I haven't used the index monitoring feature, and a cautious DBA always
makes a small test before widespread deployment, but from what I've been
told, the monitoring feature is pretty low overhead.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL
of index versus table
segments be used as a reliable pointer to problematic table indexing?
No. some people would argue that the size of an index is an indicator of needing a
rebuild, but many of the big time tuners say this is not true, so I take their advice.
Disk space is cheap.
If it can
Add this to what Arup said:
PK enables one to have References established in a schema. (Parent Child
relationships i mean). That cannot be done just by having a unique
and/or
not null constraints set.
You will get ORA-02270: no matching unique or primary key for this
column-list
HTH
GovindanK
Govindan,
You can create FK relationship(Parent-child) by using UNIQUE constraint..
Correct me if I am wrong.
-Original Message-
Sent: Thursday, January 22, 2004 6:37 PM
To: Multiple recipients of list ORACLE-L; Multiple recipients of list
ORACLE-L
Cc: [EMAIL PROTECTED]
Add this to
ORACLE-L [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 12:19 AM
Hello All,
I have a strange problem...
I have a table on which i am doing an update. Its a partition table and
the local index on the column which is being updated is in an unusable
state.
I have a database trigger
Wondering if there is a rule of thumb, quick'n fast but good enough
to be used as an indicator, litmus paper so to speak, of overly indexed
table(s)...
Can, better yet - should, sheer size comparison of index versus table
segments be used as a reliable pointer to problematic table indexing
recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Healty ratio of index segment size vs table segment size?
Wondering if there is a rule of thumb, quick'n fast but good enough
to be used as an indicator, litmus paper so to speak, of overly indexed
table(s)...
Can, better yet - should, sheer
indexes.
for the record, that is one of the best oracle websites out there. Lots of great stuff
on it.
From: Branimir Petrovic [EMAIL PROTECTED]
Date: 2004/01/21 Wed AM 10:39:25 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Healty ratio of index segment size vs table
Thanks for your reply Jonathan..Here is an update..
The update that i sent you yesterday is updating a column on which there
is a local bitmap index. There are also other local bitmsap indexes on
that partitions. Yesterday i made all the local indexes pertaining to
that partition UNUSABLE and we
Hello All,
I have a strange problem...
I have a table on which i am doing an update. Its a partition table and
the local index on the column which is being updated is in an unusable
state.
I have a database trigger at statement level (before update of col_a for
) where i do
recipients of list ORACLE-L
Hello All,
I have a strange problem...
I have a table on which i am doing an update. Its a partition table and
the local index on the column which is being updated is in an unusable
state.
I have a database trigger at statement level (before update of col_a
(I'm resending my yesterday's post because it seems to have got lost)
Dennis,
You can have a unique constraint with a non-unique index. This is documented
and expected behaviour.
Actually, it's fairly easy for Oracle to enforce unique constraint using a a
non-unique index. It just traverses
Jay
That is a good one. The question is: How is the uniqueness constraint
being enforced when the index is nonunique? Offhand I would have assumed
your constraint would have been rejected since the index is nonunique --
nope. Then I would have guessed the index would have been converted
Depends what you want to achieve.
A non-unique index enforcing a unique
constraint allows the constraint to be
deferrable - so you could load some
'nearly unique' data against it and find
the duplicates efficiently.
However, a non-unique index requires
one byte per entry more than
PM
To: Multiple recipients of list ORACLE-L
Depends what you want to achieve.
A non-unique index enforcing a unique
constraint allows the constraint to be
deferrable - so you could load some
'nearly unique' data against it and find
the duplicates efficiently.
However, a non-unique index
Jay,
Remember, both UK and PK are enforced by unique indexes. The important
difference between them is a null value is allowed in UK, not in PK.
In (1), your constraint is specifically named as ct_pk1. Oracle does the for
you:
a) create a unique index ct_pk for you in the default tablespace
All,
Please enlighten this Junior DBA.
Which method is more efficient? When should I go for option (1)?
1)NON-UNIQUE index Vs Unique Constraint
drop table index_test;
create table index_test(c1 number,c2 varchar2(20));
create index i1 on index_test(c1);
alter table index_test add constraint
sorry, the second query uses equality operator..
WHERE UPPER(col1) = 'xyz';
index hint is not helping.
regards,
B S Pradhan
--
On Thu, 08 Jan 2004 zions swordfish wrote :
hi, pradhan,
I don't see any kind of differences with your two queries, but
I suggest you to use
that also uses v$session_longops ...
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
Hi All,
I have the query like:
SELECT *
FROM tab1
WHERE UPPER(col1) 'abc';
Obviously, the function based index i have is not hetting used because of the
ineqality.
When using
SELECT *
FROM tab1
WHERE UPPER(col1) 'abc';
index is getting used.
How can I possibly use index in the 1st case
ts of list ORACLE-L [EMAIL PROTECTED]
Cc:
Hi All,I have the query like:SELECT *FROM tab1WHERE UPPER(col1) 'abc';Obviously, the function based index i have is not hetting used because of the ineqality.When using SELECT *FROM tab1WHERE UPPER(col1) 'abc';index is getting used.How can I possibly
index i have is not hetting used because of
the ineqality.
When using
SELECT *
FROM tab1
WHERE UPPER(col1) 'abc';
index is getting used.
How can I possibly use index in the 1st case.
Thanks and Regards,
B S Pradhan
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author
How about v$session_longops
Cheers
From: Daniel Hanks [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Progress of an index rebuild
Date: Tue, 06 Jan 2004 09:49:25 -0800
Is there any way to check on the progress of an index rebuild
How about v$session_longops
Cheers
From: Daniel Hanks [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Progress of an index rebuild
Date: Tue, 06 Jan 2004 09:49:25 -0800
Is there any way to check on the progress of an index rebuild
Is there any way to check on the progress of an index rebuild? (Oracle 8i). I.e., it
would be nice to get some indicator as to how far an index rebuild has gone, something
like 75% done
As a rough indicator, I've noticed when rebuilding/moving an index to a different
tablespace, Oracle
Have you checked v$session_longops ... ??? regular index builds show up there, so I
guess rebuilds will show up as well ...
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email
Hi!
Check v$session_longops view, it is meant for monitoring this kind of
long-running jobs - but it can be quite inaccurate.
Another way would be to check v$sort_usage during sorting phase of index
recreation and then check the newly created index segments size (it'll be
created as a temporary
Daniel,
Check out V$SESSION_LONGOPS.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-Original Message-
Sent: Tuesday, January 06, 2004 12:49 PM
To: Multiple recipients of list ORACLE-L
Is there any way to check on the progress of an index rebuild? (Oracle 8i). I.e
--- Daniel Hanks [EMAIL PROTECTED] wrote:
Is there any way to check on the progress of an
index rebuild? (Oracle 8i). I.e., it would be nice
to get some indicator as to how far an index rebuild
has gone, something like 75% done
Daniel,
v$session_longops, perhaps?
(at least
I know you can hint a fast full scan. I have run into cases lately where depending on
circumstances Oracle will use an index, but use a sub-optimal type of index scan with
dramatic differences in performances.
This is on 9.2. Any hints for forcing an 'index range scan'. Anything stronger than
, having an opinion is an art !
-Original Message-
Sent: Tuesday, December 30, 2003 8:14 AM
To: Multiple recipients of list ORACLE-L
I know you can hint a fast full scan. I have run into cases lately where depending on
circumstances Oracle will use an index, but use a sub-optimal type
You can have range scan with equality search (=) as well, if your index is
non-unique and there is no unique constraint on column.
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, December 30, 2003 3:24 PM
put in a between clause
) (direct
table access for c1 and c1) then oracle will use FTS with cost based optimization.
So, w/o a hint that is expected.
But why it is not picking the index in my case i donot know.
Also, can optimizer_index_cost_adj help? Its 100 now. Also that affects the whole DB,
so is there any way to set
index, oracle will have to do a range scan on
index ind1 and than table access by rowid.
If CBO thinks that col1='val1' will get a lot of rows then doing FTS may be
cheaper.But with hint, oracle should be able to pick that index.
Sample:
00:48:18 [EMAIL PROTECTED] create table test
Hi All,
Agreed.. and it should behave that way i.e
if (cost of ind1 scan + then based on c1's selection table access for c3) (direct
table access for c1 and c1) then oracle will use FTS with cost based optimization.
So, w/o a hint that is expected.
But why it is not picking the index in my
Subject: Re: Re: Index usage
Hi All,Agreed.. and it should behave that way i.eif
(cost of ind1 scan + then based on c1's selection table access for c3)
(direct table access for c1 and c1) then oracle will use FTS with cost based
optimization.So, w/o a hint that is expected.But why
a hint that is expected.
But why it is not picking the index in my case i donot know.
Also, can optimizer_index_cost_adj help? Its 100 now. Also that affects the whole DB,
so is there any way to set it for this particular query ?
Thanks for all the inputs.
Regards,
B S Pradhan
On Wed, 24
Hi All,
Merry Christmas to all.
I have this interesting problem..
For this query index ind1 on (c1,c2) columns is getting used.
SELECT 'x'
FROM tab ta
WHERE ta.c1='val1';
(gives index ind1 range scan)
But for
SELECT 'x'
FROM tab ta
WHERE ta.c1='val1'
AND ta.c3 = 'val2';
(gives FTS)
index
an index. In fact, an additional index access
would decrease the query performance.
Daniel Fink
bhabani s pradhan wrote:
Hi All,
Merry Christmas to all.
I have this interesting problem..
For this query index ind1 on (c1,c2) columns is getting used.
SELECT 'x'
FROM tab ta
WHERE ta.c1
No.
The index should get used.Thequery result for query 2 is a subset of rows with ta.c1='val1' will get selected. Subset of query 1.
So there is no need for a full table scan.The index can be used in the following way :
1) Use index ind1 to get rows with ta.c1='val1' (which is query 1
The difference is that the first query never has to go to the table
(because you're selecting a constant 'x'). The second query has to go
to the table to filter on c3.
Mike
anu wrote:
No.
The index should get used. The query result for query 2 is a subset of
rows with ta.c1='val1
Hi,
It cound be possible that without Hint, oracle will choose FTS for second SQL,
because with col3 clause, if using index, oracle will have to do a range scan on index
ind1 and than table access by rowid.
If CBO thinks that col1='val1' will get a lot of rows then doing FTS may
I had a similar question a while back. Specifically my question was,
is it faster to join on a numeric-based index or a varchar(2) based index.
After much research, and a discussion with an Oracle PT friend of mine,
the answer was/is: It depends. There is no right answer; your results
will vary
Here are all the details:
Source database 9.2.0.4 (upgrade from 8.1.6.3.4).
Target database 8.1.6.3.4.
View definition: create view my_view as select * from [EMAIL PROTECTED]
Sql: select * from local_table , my_view
where local_table.branch = 1
and my_view.customer = 200 +
Solved.
It was a hash join with the smaller table first but it pulled the whole 1M
records for this.
There was a: where local_table.branch = 1 in the query. I changed it into:
where remote_table.branch = 1 (there is an index on remote_table.branch) and
it came down to 2 seconds.
Thanks all
Yechial,
It's been a couple of years since I worked on tuning queries with db links, but
a couple of issues come to mind:is the correct table being used for the inner
table of the join, is too much data being sent over the network.
-is the correct table being used for the inner table: I remember
.
I will welcome ideas how to make oracle use the index on the remote side.
Yechiel Adar
Mehish
--
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Lewis
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San
One of the column in a new table can be ename - varchar2(20) or hase_code_ename -
number(11) Hash Code generated by JAVA.
We are going to create non-unique index on this column as one frequent query will have
where clause on this column only. Choice is either varchar2(20) or number(11).
1
Yep, I missed this userenv part totally, even though I posted the source
here myself as well.
Gotta get better eyes from somewhere ;)
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 5:10 PM
Tanel,
Raj must be
clod can have facts, having an opinion is an art !
-Original Message-
Sent: Tuesday, November 18, 2003 5:04 PM
To: Multiple recipients of list ORACLE-L
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should
be
in V$OBJECT_USAGE. In connection to that, here is a sweet
are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-Original Message-
Sent: Tuesday, November 18, 2003 5:04 PM
To: Multiple recipients of list ORACLE-L
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should
be
in V$OBJECT_USAGE
Tanel,
Raj must be talking about userenv('SCHEMAID'). Change that to another user's
user_id as seen in dba_users, you should see that user's object usage:
SQL select * from v$object_usage;
no rows selected
SQL select io.name, t.name,
2 decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
not
specify that column will not use that index. That was probably the biggest
pain going from RBO to CBO for us.
So, for your example, joining YOURTABLE to MYTABLE using only N1 and N2 does
not necessarily mean that index IDX2 will be used.
Rich
Rich Jesse System
Hi,
I had sent this some time back but got no answer for version 8.1.7.For table I understand auditing is an option. What about for index? Thank YouA Joshi [EMAIL PROTECTED] wrote:
Hi,
Is there an easy way to find out if a table or anindex is being used. I mean short of going thru all code
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Tuesday, November 18, 2003 11:49 AM
To: Multiple recipients of list ORACLE-L
Hi,
I had sent this some time back but got no answer for version 8.1.7. For
table I understand auditing is an option. What about for index? Thank You
Are you looking to see if statements are using indexes or how often index
blocks are being read?
Daniel Fink
A Joshi wrote:
Hi, I had sent this some time back but got
no answer for version 8.1.7. For table I understand auditing is an option.
What about for index? Thank You
A Joshi [EMAIL
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should be
in V$OBJECT_USAGE. In connection to that, here is a sweet little bug in oracle 9.2.0.4:
SQL select name from v$fixed_table where name='V$OBJECT_USAGE';
no rows selected
Don't tell that to oracle, they might even fix
Looking to see if any statement has accessed the index in say 30 days. So basically : "how often index blocks are being read". So I can decide to drop unused indexes. T
Thanks Daniel for your help.
Daniel Fink [EMAIL PROTECTED] wrote:
Are you looking to see if statements are using inde
or index being accessed
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should be
in V$OBJECT_USAGE. In connection to that, here is a sweet little bug in oracle 9.2.0.4:
SQL select name from v$fixed_table where name='V$OBJECT_USAGE';
no rows selected
Don't tell that to oracle
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Re: ** find whether table or index being accessed
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should
be
in V$OBJECT_USAGE. In connection to that, here is a sweet
table tmp_v$cache
as select owner#, name, kind, partition_name, count(*) sga_cnt, count(*)
* (nv_db_block_size / 1024) sga_kb
from v$cache
group by owner#, name, kind, partition_name;
create index tmp_v$cache_idx
on tmp_v$cache(owner#, name, kind, partition_name, sga_cnt, sga_kb
This is just an idea, so please test it thoroughly (and then test it again!)
Any and all comments (including "Are you brain-dead, Dan?") are welcome.
How about periodically sampling v$bh for index segment headers? This
assumes that any index access reads the header (
Daniel,
it
will work but indexes are present in buffer cache also because of updates. The
only possibility is to store each index in questionin separate tablespace
and monitor the i/o. If number of reads will be equal or little bit
greaterthan thenumber of writes than this is a candidate
Well, 'ALTER INDEX MONITORING USAGE' should do the trick. Results should
be
in V$OBJECT_USAGE. In connection to that, here is a sweet little bug in
oracle 9.2.0.4:
SQL select name from v$fixed_table where name='V$OBJECT_USAGE';
no rows selected
Don't tell that to oracle, they might even
I was too lazy to look for it on asktom.oracle.com, but here's what I read at the site
a while ago (if you search on index usage or something like that you should find Mr.
Kyte's answer). Tom Kyte has the following suggestions:
a) In Oracle 8.0 and earlier - put an index all by itself
Joze,
Excellent Point! I knew there was something wrong about this, I just
could not figure out what it was...
Daniel Fink
Joze Senegacnik wrote:
Daniel,it
will work but indexes are present in buffer cache also because of updates.
The only possibility is to store each index in question
No, differently from table access, index access
doesn't require reading of index segment header. The query reads the root block
directly. Root block address is probably gotten from IND$ table columns file#
and block#+1. The block# represents index segment header location in a datafile,
root
]
cc:
Subject:RE: ** find whether table or index being accessed
I was too lazy to look for it on asktom.oracle.com, but here's what I read at the site a while ago (if you search on index usage or something like that you should find Mr. Kyte's answer). Tom Kyte has the following
I think there's another complication in using buffer cache (x$bh or v$bh). If
the index is scanned in parallel, the blocks are not cached in buffer cache.
To avoid counting buffers created due to index update, maybe we can simply say
where v$bh.status in ('CR','READ').
Yong Huang
--- Tanel
i have got a script from metalink for monitoring indexes .=0D
it works for 8.1.x too . =0D
just try the script that i have mailed to ur personal email address. =0D
=0D
Regards,=0D
Jp.=0D
=0D
A Joshi [EMAIL PROTECTED] wrote:=0D
=0D
Hi, Is there an easy way to find out if a table or an index is=0D
may impact their accuracy, those indexes
that have a very high ratio of logical reads to db block changes you know
are highly used for legitimate index accesses, those closer to a 2-1 ratio
are only being accessed mainly due to dml changes.
A bit of investigation and experimentation and these views
for legitimate index accesses, those closer to a 2-1 ratio
are only being accessed mainly due to dml changes.
A bit of investigation and experimentation and these views can be very
useful.
Cheers
Richard
**
This e-mail
index usages in oracle 8i ,like 9i
v$object_usage?
Thanks
Arvind Kumar
--
http://www.fastmail.fm - One of many happy users:
http://www.fastmail.fm/docs/quotes.html
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: GKatteri
INET: [EMAIL PROTECTED]
Fat City
Hi all,
is there a way to monitor index usages in oracle
8i ,like 9i v$object_usage?
Thanks
Arvind
Kumar
[Sorry, also posted with the wrong subject title - RE: (un)intelligent agent]
Hi all,
Does anyone have an idea why the query is picking a random local bitmap index whose
single column is not used in the query to do a conversion on?
Regards,
Adrian
---
SELECT 1
FROM
Sorry, its late on Friday and need beer...
The bitmap index is partitioned in INV5.
-Original Message-
Sent: 07 November 2003 15:30
To: Multiple recipients of list ORACLE-L
on.
[Sorry, also posted with the wrong subject title - RE: (un)intelligent agent]
Hi all,
Does anyone have
Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing. I suppose if Jonathan (Lewis) can get the optimizer to
do a FTS on an umpteen billion row table to retrieve a single row by its
prime key, one can concoct a scenario of statistics values, aided by init
?
Thanks in advance
-Sami
-Original Message-
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Date: Thu, 06 Nov 2003 07:19:24 -0800
Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing. I suppose if Jonathan (Lewis) can get the optimizer
OK, I can follow that, but why the change between ABC% and AB% ?
Henry
-Original Message-
Wolfgang Breitling
Sent: Thursday, November 06, 2003 10:19 AM
To: Multiple recipients of list ORACLE-L
Actually, it has nothing to do with any of the table or index statistics.
OK, almost nothing
I don't know. I'm just reporting what I found. It was new to me too.
At 09:39 AM 11/6/2003, you wrote:
OK, I can follow that, but why the change between ABC% and AB% ?
Henry
Wolfgang Breitling
Oracle7, 8, 8i, 9i OCP DBA
Centrex Consulting Corporation
http://www.centrexcc.com
--
Please see the
spreadsheet. At least, that's what I would do
to try and understand it .
Jared
Henry Poras [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/06/2003 08:39 AM
Please respond to ORACLE-L
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: RE: Index
1 - 100 of 1371 matches
Mail list logo
