Re: Parallel Query change from smart scan to cell single block access

Hi,
yes, it has been a while ago. My guess was that the runtime system can make similar decisions with respect to the cell flash cache as it can with respect to the buffer cache. For the buffer cache Tanel explains it here: https://tanelpoder.com/2013/05/29/forcing-smart-scans-on-exadata-is-_serial_direct_read-parameter-safe-to-use-in-production/. The point is that in highly dynamic situation blocks that were present when the runtime system made it's decission are no longer cached when they should be scanned. In such a situation I believe that a single blok read is done to fill the gap. Which will delay the scan and increase that likelyhood that more blocks needed would be uncached. This is a very difficult issue and I could never proof it. It could be that I am mistaken. It is also possible that it is not a cell flash cache phenomenon but rather the buffer cache issue. Thanks
Lothar  

----Ursprüngliche Nachricht----
Von : exriscer_at_gmail.com
Datum : 15/06/2022 - 00:26 (MS)
An : oracle-l_at_freelists.org
Betreff : Parallel Query change from smart scan to cell single block access  Hi all         

  I have a strange situation where a very simple query (no join, a single FROM table) sometimes is fast (seconds) and sometimes slow (hours). After digging a bit It seems that one of PQ slave instead of accessing the table using cell smart table scan is accessing by cell single blocks.           

  This is 19.10, has anyone observed or faced such a problem?           

  Thanks         

--

http://www.freelists.org/webpage/oracle-l Received on Wed Jun 15 2022 - 17:24:01 CEST