Expert Oracle Exadata - Parent Directory

CHAPTER 4 STORAGE INDEXESIncorrect ResultsBy far the biggest issue with Storage Indexes has been that in early releases of the Exadata StorageSoftware there were a handful of bugs regarding incorrect results. That is to say that in certain situations,usage of Storage Indexes could eliminate storage regions from consideration that actually containedrecords of interest. This incorrect elimination could occur due to timing issues with concurrent DMLwhile a Smart Scan was being done using Storage Indexes. These bugs have been addressed in 11.2.0.2and the latest patches on the storage servers. If you run into this issue, disabling Storage Index use viathe hidden parameter, _KCFIS_STORAGEIDX_DISABLED, may be the only option available until the properpatches are applied. This parameter can be set with an alter session command, so that onlyproblematic queries are affected. Of course you should check with Oracle Support before enabling anyhidden parameters.Moving TargetStorage Indexes can be a little frustrating because they don’t always kick in when you expect them to.And without any hints to tell Oracle that you really want a Storage Index to be used, there is little you cando other than try to understand why they are not used in certain circumstances so you can avoid thoseconditions in the future.In early versions of the storage server software, one of the main reasons that Storage Indexes weredisabled was due to implicit data type conversions. Over the years, Oracle has gotten better and better atdoing “smart” data type conversions that don’t have negative performance consequences. For example,if you write a SQL statement with a WHERE clause that compares a date field to a character string, Oraclewill usually apply a to_date function to the character string instead of modifying the date column (whichcould have the unpleasant side effect of disabling an index). Unfortunately, when the Exadata storagesoftware was relatively new, all the nuances had not been worked out, at least to the degree we’re used tofrom the database side. Dates have been particularly persnickety. Here is an example using cellsrv11.2.1.2.6:SYS@EXDB1> select count(*) from kso.skew3 where col3 = '20-OCT-05';COUNT(*)----------0Elapsed: 00:00:14.00SYS@EXDB1> @siNAMEVALUE--------------------------------------------- ---------------cell physical IO bytes saved by storage index 0119