Expert Oracle Exadata - Parent Directory

CHAPTER 16 UNLEARNING SOME THINGS WE THOUGHT WE KNEWinto the two main categories we’ve already described. In fact, most systems display characteristics ofboth.Combining long-running, throughput-sensitive queries with fast, latency-sensitive statementsdefinitely introduces some additional issues that must be dealt with. One of the main issues in systemsof this type is how to deal with indexes.To Index or Not to Index?One of the biggest debates we’ve had during Exadata implementations is whether to drop indexes or not.Access paths that use indexes are generally not able to take advantage of Exadata-specific optimizations.We say generally, because offloading can occur in cases where the optimizer chooses to execute a FastFull Scan on an index, but this is not the most common usage pattern for indexes. The more commonpattern is to use them for retrieving relatively few records from a table using an Index Range Scan, andthis operation is not currently offloadable. Generally speaking, we want to use index range scans onselective predicates, but since Exadata is so effective at scanning disk, in many cases the index-basedaccess paths are no longer faster than the scan-based access operations. It’s really a case of getting ourbearings all over again with respect to when we want to use indexes and when we would expect a fullscan to perform better.One of the things we commonly heard when Exadata was first starting to appear at customer siteswas that indexes were no longer necessary and that they should be dropped. For pure data warehouseworkloads, this may actually be pretty good advice. However, we rarely see anything pure. Most systemshave a mix of access patterns, with one set of statements hoping for low latency and another set hopingfor high throughput. In these cases, dropping all indexes just will not work. This is why we saved thisdiscussion for this section. The problem with mixed workloads, where it is necessary to keep indexes forspecific sets of statements, is that the optimizer is not as well equipped to choose between using andignoring them as one might hope. We’ll discuss the optimizer’s limitations next. Kevin Says: I know the origin of the mistaken notion that indexes are not necessary with Exadata. You see,Oracle Database enjoyed majority market share of the world-wide data warehousing market (as per industryanalysts) before Exadata came to market. The methodology required to coerce Oracle Database into deliveringadequate performance in the pre-Exadata era required an immense amount of “index trickery.” Oracle’scompetition (most notably Netezza [now IBM] and Greenplum [now EMC]) focused their marketing message on this“Achilles heel.” However, this over-indexing phenomenon (with all the associated complexities) was never anOracle database weakness per se. Before the original release of Exadata in 2008, customers did not have therichness of systems technology available for configuring a high-bandwidth, balanced DW/BI system. Imbalanceand low bandwidth drove the need to avoid doing physical I/O. The only way to avoid physical I/O in that era was tofall into the “index death-spiral,” as it became known in certain cliques within Oracle. While Exadata certainlyaddresses the I/O bottlenecks, there remains one all-encompassing truth: It is always faster not to do somethingthan to do something fast. To that end, Exadata administrators need to remember that some of the tools theircompany has paid for include on-disk indexing technology. Always use the right tools for the job at hand.529