Expert Oracle Exadata - Parent Directory

CHAPTER 16 UNLEARNING SOME THINGS WE THOUGHT WE KNEW5zruc4v6y32f9 5 51.13 No .00 DECLARE job BINARY_INTEGER :=6dx247rvykr72 1 .10 Yes 100.00 select count(*) from skew3 whe6uutdmqr72smc 2 32.83 Yes 71.85 select /* avgskew3.sql */ avg(7y09dtyuc4dbh 1 2.87 Yes 71.83 select avg(pk_col) from kso.skb6usrg82hwsa3 5 83.81 No .00 call dbms_stats.gather_databasfvx3v0wpvxvwt 1 11.05 Yes 99.99 select count(*) from skew3 whegcq9a53z7szjt 1 .09 Yes 100.00 select count(*) from skew3 whegs35v5t21d9yf 1 8.02 Yes 99.99 select count(*) from skew3 whe13 rows selected.The fsxo.sql script provides the same limiting factors as the offload_percent.sql script, namely aminimum average elapsed time and a minimum average logical I/O. It also optionally allows you to limitthe statements to only those that are offloaded or those that are not offloaded. Please refer to the scriptsfor further details and keep in mind that these techniques can also be applied to the data recorded byAWR for a historical perspective.In the next section we’ll discuss some issues that can complicate your efforts to enable Smart Scans.Things that Can Cripple Smart ScansThere are several common coding “techniques” that either disable Smart Scans completely or causethem to be much less effective than they could be. Some of the techniques are just bad practicesregardless of whether you are on the Exadata platform or not. Others don’t carry as significant a penaltyon non-Exadata platforms, but when run on Exadata they can prevent the storage software from doingall that it could do. We’ve discussed many of these issues throughout this book. Here are a few that youshould keep in mind because of the fundamentally different behavior on the Exadata platform.Functions in WHERE ClausesOracle provides a large set of functions that can be applied directly in SQL statements. As we discussedin Chapter 2, not all of those functions are offloadable. Knowing which functions are not offloadable isimportant because the use of those functions in WHERE clauses disables predicate filtering that mayotherwise provide a massive reduction in the amount of data to be transferred back to the databaselayer. Obviously, custom-written PL/SQL functions fall into the category of “non-offloadable” functionsas well.This issue is somewhat counterintuitive, since we are often doing full table scans anyway with datawarehouse systems. On non-Exadata platforms, applying a function in a WHERE clause of a statement thatis executed via a full table scan does not impose much of a penalty with regard to the amount of datathat must be returned, because the database must already return all blocks from the table to thedatabase server. With Exadata, though, applying a function that can disable predicate filtering canimpose a huge performance penalty. By the way, using custom PL/SQL functions in a WHERE clause isgenerally also a bad idea on non-Exadata platforms, because additional CPU will be required to processPL/SQL for each row, as opposed to the optimized functions, based on C code, provided by Oracle. Note: You can query V$SQLFN_METADATA to see which functions are offloadable.516