Expert Oracle Exadata - Parent Directory

CHAPTER 2 OFFLOADING / SMART SCANIn addition to parallel slaves, direct path reads are possible for non-parallel SQL statements, whenconditions are right. There is a hidden parameter, _SERIAL_DIRECT_READ, which controls this feature.When this parameter is set to its default value (AUTO), Oracle automatically determines whether to usedirect path reads for non-parallel scans. The calculation is based on several factors including the size ofthe object, the size of the buffer cache and how many of the objects blocks are already in the buffercache. There is also a hidden parameter (_SMALL_TABLE_THRESHOLD) which plays a role in determininghow big a table must be before it will be considered for serial direct path reads. The algorithm fordetermining whether to use the direct path read mechanism on non-parallel scans is not published.While the ability to do serial direct path reads has been around for some time, it has only recentlybecome a relatively common occurrence. Oracle Database 11gR2 has a modified version of thecalculations used to determine whether to use direct path reads for non-parallel scans. The newmodifications to the algorithm make the direct path read mechanism much more likely to occur than itwas in previous versions. This was probably done as a result of Exadata’s Smart Scan optimizations andthe desire for them to be triggered whenever possible. The algorithm may be somewhat overly aggressiveon non-Exadata platforms.■ Note: My Oracle Support Note: 793845.1 contains the following statement:There have been changes in 11g in the heuristics to choose between direct path reads or reads through buffercache for serial table scans. In 10g, serial table scans for "large" tables used to go through cache (by default)which is not the case anymore. In 11g, this decision to read via direct path or through cache is based on the sizeof the table, buffer cache size and various other stats. Direct path reads are faster than scattered reads and haveless impact on other processes because they avoid latches.Exadata StorageOf course the data being scanned must be stored on Exadata storage in order for Smart Scans to occur. Itis possible to create ASM disk groups that access non-Exadata storage on Exadata database servers. Andof course it makes sense that any SQL statements accessing objects defined using these non-Exadatadiskgroups will not be eligible for Offloading. While it is unusual, it is also possible to create ASMdiskgroups using a combination of Exadata and non-Exadata storage. This might be done to facilitate amigration via an ASM rebalance, for example. Queries against objects whose segments reside on thesemixed storage diskgroups are also not eligible for Offloading. There is actually an attribute assigned toASM disk groups (cell.smart_scan_capable) that specifies whether a disk group is capable of processingSmart Scans. This attribute must be set to FALSE before non-Exadata storage can be assigned to an ASMdisk group. Here’s a listing showing the process of creating a mixed storage disk group and the effects onqueries against a table with segments stored in that disk group. Note that we are jumping ahead in thisexample, so some of the commands may not make a lot of sense yet. Don’t worry; we’ll cover the detailsin due time. For now we just want you to see that you can access non-Exadata storage, but that it willdisable the Exadata storage-based optimizations.SYS@+ASM> -- Add non-Exadata storageSYS@+ASM> alter diskgroup SMITHERS add failgroup LOCAL disk '/dev/raw/raw5','/dev/raw/raw6';46