Expert Oracle Exadata - Parent Directory

CHAPTER 6 MAKING PCBSthe normal caching mechanism in favor of reading blocks directly in to the user’s Program Global Area(PGA).The In-Memory Parallel Execution feature takes a different approach. It attempts to make use of thebuffer cache for parallel queries. The feature is cluster-aware and is designed to spread the data acrossthe cluster nodes (that is, the RAC database servers). The data blocks are also affinitized to a single node,reducing the amount of communication and data transfers between the nodes. The goal, of course, is tospeed up the parallel query by eliminating disk I/O. This can be a viable technique because manysystems now have very large amounts of memory, which of course can provide a significant speedadvantage over disk operations. There are some downsides to this approach though. The biggestdisadvantage with regard to Exadata is that all the Smart Scan optimizations are disabled by this feature.■ Kevin Says: It is true that In-Memory Parallel Query I/O is buffered in the SGA and remains cached—thus SmartScan is not involved. This would only be a disadvantage if a query executes faster with Smart Scan than with In-Memory Parallel Query. Comparing the processing dynamic of a query serviced by Smart Scan as opposed to In-Memory Parallel Query is a very complex topic—especially when compressed data is involved. In the same waySmart Scan is able to filter vast amounts of deeply-compressed data (specifically HCC), so is In-Memory ParallelQuery. That is, HCC data is filtered in its compressed form regardless of who is doing the filtration. In the case ofSmart Scan, however, the data that sifts through filtration must be decompression and sent to the database gridvia iDB for data-intensive processing (such as join, sort, or aggregate). With In-Memory Parallel Query there is nodata flow over iDB. Furthermore, a table that is accessed frequently by Smart Scan requires the same repetitiousphysical I/O+filtration+decompression (with the exception of results-cached queries) each time it is accessed.With In-Memory Parallel Query the I/O and iDB effort is eliminated and, as we know, memory is faster than bothhard disk and flash. What customers must analyze is whether there are sufficient processor cycles available in thedatabase grid to perform the repetitious filtration and decompression of popular tables. Remember, in the case ofSmart Scan that effort is offloaded to the cells. To cap this train of thought, I’ll simply say there is no absoluteanswer in the comparison between In-Memory Parallel Query and Smart Scan. The variables need to be plugged inby the customer using the knowledge gained from reading this book, Oracle documentation and, perhaps, blogs(smiley face).Note that we haven’t actually seen In-memory Parallel Query in the wild on Exadata, which isprobably good, since many of the optimizations built into Exadata rely on Offloading, which depends ondirect reads. Of course direct reads will not be done if blocks are being accessed in memory on thedatabase servers. On most platforms, memory access would be much faster than direct reads from disk.But with Exadata, eliminating the disk I/O also eliminates a large number of CPUs that could be appliedto filtering and other operations. This means that accessing the buffer cache for parallel execution couldactually be less efficient than allowing the storage servers to participate in the execution of the SQLstatement.A little demonstration is probably in order at this point. It’s worth noting that getting this feature tokick in at all takes quite a bit of effort. Here are the basic steps we had to take in order to get it to work.First we had to find a query that the optimizer estimated would run for longer than the number ofseconds specified by the PARALLEL_MIN_TIME_THRESHOLD parameter (assuming the statement wasn’t165