Kellyn nailed it in very few words earlier in the thread.
Pardon me for writing a few extended thoughts about how you in fact tune for
Regarding indexes, you have to consider the maintenance time on each
transaction as well, IF that takes place at a time you care about.
So even when the CBO chooses an index for a particular query as less costly,
you have to consider time cost to maintain the indexes.
THAT can be quite different for OLTP versus more quiescent data stores. And if
your queries are running on systems that are built and refreshed in windows
where the time is not that important as long as completion takes place without
violating the window, it is *sometimes* possible to dramatically reduce the
queries that happen later by physical sorting or attribute clustering (and/or
zonemaps if you’re on a relevant box), and all that may affect how few rows
make the index versus the table scan the faster, cheaper choice.
Sorted physical data (however you got there) can move the CBO bar for index
versus FTS by improving the cluster factor in favor of indexes. Zonemaps can
prune the candidate blocks (or compression units) for a FTS favoring an FTS.
If you happen to know the superset of columns that will satisfy all your
popular queries per table in a batch rebuild system (or batch new period
partitioned system), then you may discover that scanning the index (and
avoiding the table altogether) is the cheapest thing.
Any silly thumb rule beyond “it depends” that ignores the actual workflow, the
actual queries, and the actual data is a recipe for getting it wrong a lot of
When thumb rules are used (as with, pardon the swear word, “best practices”) to
stifle thinking or preempt proof of concept experimentations, you get what you
Thinking about the overall process and data you have, formulating hypotheses,
and testing those hypotheses also gets you what you deserve. (Science wins.)
And from your insightful questions and answers over the years on this list, I
know you can think very clearly about this yourself, LS. Whether there is a
definitive statement from Oracle or not on this matter doesn’t matter. Oh.
Except you might have to gain freedom to do the proper science over the
argument of someone whose clout exceeds their mental capacity. Finally I think
I see your real problem. Sorry about that.
Again, Amen to what Kevlar wrote. Time is almost always THE goal.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Ls Cheng
Sent: Sunday, April 15, 2018 3:22 PM
To: Frits Hoogland
Cc: Oracle Mailinglist
Subject: Re: Anyone know any WP which explains about FTS vs Index Scan?
He sticked with late 90's theory however he actually pointed me some oracle
11.2 documentation links which talks about reduce I/O, use index when possible,
then I started searching some stuff from Oracle and I cannot find a lot which
says index scan is not always the best (I found the explanation in asktom
only). So I question if Oracle documentation is actually promoting index scans!
I also looked for why FTS is preferable in DWH where massive data need sto be
accessed without much luck neither.
I gave him examples, I explained why CBO is introduced to make decision when
FTS is better etc and I think he started to believe me but because of his ego
he does not want to stop discuss.
On Sat, Apr 14, 2018 at 5:19 PM, Frits Hoogland <frits.hoogland@xxxxxxxxx>
My question would be: why an index range scan MUST be used? What is the reason
for this person to deem it mandatory?
This would also discard unique index access, which is a different access path
than an index range scan.
I question the knowledge of the person if he/she can not see the point of a
full table scan or any other different access path.
Even if the documentation would state that an index must be used, and does not
provide a valid reason for why it shouldn’t be used, I would discard the advise
in the documentation. There are lots of examples where the official
documentation is incorrect, and even experts might be wrong; for something to
be written in a book doesn’t make it the truth.
Mobile: +31 6 14180860
On 10 Apr 2018, at 18:13, Ls Cheng <exriscer@xxxxxxxxx> wrote:
I have a Dinosaur stating we must always use index range scan no matter OLTP or
DWH systems. This guys still lives in the late 90's and Oracle 7 (although he
claims he is 18 years veteran expert from 7 up to 12c), the thing is I cannot
find any Oracle WP or similar in the docs which states Full Table Scan is not
evil except Tom Kyte (asktom). I have even demo-ed him with a very simple two
table join example with FTS and index range effect when a large amount of data
need to be accessed, still he says in Oracle docs states that scattered reads
(FTS) mist be reduced!
Does anyone know any official pointer, in WP form or MOS support note which
talks about FTS vs index scans?