I can not comment on what could happen in the future. I would comment that if you are hitting bugs that there be a SR and bug number to reference (bugs do not get fixed unless they are logged with support). I have yet to hit any issues where it was required to disable parallel query to work around a bug. That in itself would just kill performance anyway.

We know that Smart Scan requires Parallel Query to work? Sometimes we want to
disable parallelism for a query, for various reasons (in particular: bugs…:)). Is it possible, that in future releases of Exadata, Smart Scan will also be supported for noparallel queries?

Many thanks in advance!

The Exadata Smart Scan column projection works on all rows in all blocks. The advantage of this is a reduction in data sent back to the database grid.

Many thanks for your answer, now I understand! I would be grateful for answering one more question… :)

Column projection – I assume that this only works if a table row is located in more than 1 oracle block (this means either row chaining or row migration)? If each and every row in a table fits into 1 oracle block, is column projection relevant?

For “normal” smart scans the list of values is known at parse time and is generally small in number. Most people don’t write an IN predicate with 5,000 values for example. With a join, the list of values could be fairly large (compared to writing it by hand) so it is much more efficient to apply this filtering with a bloom filter. Think of it as bulk set based elimination. Do note that a bloom filter can return false positives but no false negatives, so the database still needs to apply this predicate filter as well. The benefit of the bloom filter being applied in the Exadata storage is that it significantly reduces the number of rows returned to the database. This saves on channel bandwidth as well as greatly reducing the work the database has to do for this join operation.

I have a question about smart scan in joins: if smart scan can filter rows, why in joins – after finding REG_IDs corresponding to REGION_NAMEs – doesn’t smart scan do “normal” row filtering, and instead it uses bloom filter???

Many thanks in advance!

Correct. Statements that use parallel execution use Smart Scan, non-PX (serial) statements do not.

As the Technical Overview of Exadata whitepaper states on page 21:

ASM automatically stripes the database data across Exadata disks and cells to ensure a balanced I/O load and optimum performance.

And Best Practices for Migrating to Oracle Exadata Storage Server states on page 7:

Oracle Exadata Storage Server performs best when scanning at least 4MB contiguous chunks. To ensure this occurs at an ASM level, the disk group’s allocation unit size should be set to 4MB.

>First, Smart Scans are performed in Exadata on the data that PQ requests.
>Nothing is really required, it just works. You don’t “tune” for Exadata.

As I understand from your answers so far, To enable smartscan , PQ needs to be enabled at Table/Session/Query level.. else data would be fetched in normal fashion (i.e. all the data would be returned to DB grid ). Correct?

In Technical overview document, Each Exadata Cell is assigned set of disks. How data is distributed accross the Exadata Cells? Is it done thru ASM (1MB per Disk/Lun in the Disk Group)?

TIA.

First, Smart Scans are performed in Exadata on the data that PQ requests. Second Exadata does not execute or parallelize queries, it simply scans and filters data. Exadata is storage software, not database software. It just knows how to apply some operations that the database software tells it (like filtering/restriction).

Nothing is really required, it just works. You don’t “tune” for Exadata.

For this specific query I would guess the following would take place:
- partition elimination (this is not Exadata specific but since this query has a predicate on SALES.SALE_DATE and that is the partition key, then it will eliminate the partitions not required and only scan the 4 quarterly partitions for 2001)
- projection (smart scan will only send the required columns back to the DB grid)
- possible use of bloom filter (depending on the selectivity of the REGION_NAME predicate, a bloom filter may be created from the values for REG_ID and pushed down to Exadata to be used as a Smart Scan filter)

The results, post Smart Scan, will be sent to the DB grid and the joins performed there. So assuming a Bloom/Join filter on REGION.REG_ID, then SALES and REGION would be joined, aggregated, and ordered in the DB grid.

My guess is this query would run a few seconds. Assuming an equal distribution of data across years, 1/10 of 1TB is 100GB. The scan rate is 14GB/s for a 1 rack DB Machine, so the table scan of 100GB of SALES would probably take less than a second and the join would also be quite fast with 64 Harpertown CPU cores doing the that and aggregation.

Regarding 2, aren’t smart-scans are done at exadata layer?

can you tell me how this Query (made up) be parallelized at exadata level. i.e. what operations will be executed at exadata (smart-scans) and what would be at the host(DB-Grid) level?

what’s required to be done at table/session/query level to make performance of this query most optimized on DB machine?

select r.reg_name, p.prod_name, sum(s.rev_amt)
from sales s, region r, product p
where s.reg_id = r.reg_id
and s.prd_id = p.prd_id
and r.region_name in ( ‘ASIA PACIFIC’,'EMEA’ )
and s.sale_date between to_date(‘01/01/2001′, ‘MM/DD/YYYY’)
and to_date(‘12/31/2001′, ‘MM/DD/YYYY’)
group by r.reg_name, p.prod_name
order by 1, 2, 3 desc

Sales table is huge (1TB) with 10 years of sales data and partitioned on sales date ( one partition per quarter ).