RE: Anyone know any WP which explains about FTS vs Index Scan?

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <exriscer@xxxxxxxxx>, "'Frits Hoogland'" <frits.hoogland@xxxxxxxxx>
  • Date: Sun, 15 Apr 2018 16:52:45 -0400

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

 

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 
the time.

 

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 
deserve.

 

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.

 

mwf

 

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?

 

Hi

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.

Thanks

 

 


 
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
 

Virus-free.  
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
 www.avast.com 

 

On Sat, Apr 14, 2018 at 5:19 PM, Frits Hoogland <frits.hoogland@xxxxxxxxx> 
wrote:

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.

 


Frits Hoogland

http://fritshoogland.wordpress.com ;<http://fritshoogland.wordpress.com/
frits.hoogland@xxxxxxxxx

Mobile: +31 6 14180860





On 10 Apr 2018, at 18:13, Ls Cheng <exriscer@xxxxxxxxx> wrote:

 

Hi

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?

Cheers

 

 

 

 

Other related posts: