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

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Sun, 15 Apr 2018 16:52:45 -0400
Message-ID: <00e301d3d4fb$b51490a0$1f3db1e0$_at_rsiz.com>



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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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_at_gmail.com> 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_at_gmail.com

Mobile: +31 6 14180860

On 10 Apr 2018, at 18:13, Ls Cheng <exriscer_at_gmail.com> 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        

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Apr 15 2018 - 22:52:45 CEST

Original text of this message