Expert Oracle Exadata - Parent Directory

CHAPTER 16 UNLEARNING SOME THINGS WE THOUGHT WE KNEWThis is an extremely complex topic, and it is difficult to observe the behavior directly. The goal of thefeature is to utilize available CPU resources regardless of whether they are on the database tier or thestorage tier. This behavior was introduced relatively recently, in cellsrv version 11.2.2.3.1 withdatabases running 11.2.0.2 with bundle patch 6 or later. There is a statistic called cell physical IObytes pushed back due to excessive CPU on cell in 11.2.0.2 with BP 6 and later that shows this ishappening. Note that the statistic name may change in a future version to something referring to“balancing CPU usage.” The feature is designed to improve throughput on very busy systems, but it mayalso cause some degree of instability in the performance of certain statements. It is possible to disablethis feature if your cellsrv is erroneously deciding it is too busy to take on additional work; but ingeneral, if you observe this behavior, you are probably getting close to the limits of the system. Addingadditional resources at the storage layer (more storage cells) may be a viable option. Kevin Says: The authors are correct in their description of this new “feature.” However, there is one point Icannot stress enough, and that is that the most compute-intensive work in query processing must occur in thedatabase grid; yet there are significantly fewer processors there than in the storage grid (for example, 1:1.75 in theX2-2 and 1:1.31 in the X2-8 models). In the end, the only thing that matters is whether the users’ experience issatisfactory. However, diagnosing an unsatisfactory user experience may prove difficult when this feature isinvoked. The feature has the propensity to pass as much as 40% of the physical I/O payload to the cells eithercompletely unprocessed or only lightly processed (as in, for example, EHCC projection). So, there are somescenarios I would be particularly concerned about. Allow me to explain.We are no longer living the “good life” of the 1990s, when Unix systems were physically constrained by card slotsfor memory and CPU. We have systems with vast amounts of memory (a rapidly increasing trend) and ample CPU.We are no longer living the “good life” of “ample CPU” bottlenecked by front-side-bus limitations. In short, theindustry is delivering to us huge, fast, balanced systems. The servers in the Exadata Database Machine are noexception. The significant cost of Exadata includes a feature known as in-memory parallel query and otherfeatures that can service users’ needs without touching storage in the cells. I’m referring to features that leanheavily on host-tier resources and, in fact, rely very little on offload processing. If your Exadata system hosts anapplication that exhibits bursts of database-tier, CPU-intensive processing intermixed with use cases that drivecells to processor saturation, I urge close monitoring of this push-back (aka pass-through) feature. Heuristics thatgovern the “when” and “how much” for such a feature are very difficult to get right. If the heuristics are triggeringthis feature, the performance of certain applications may suffer—probably at a time when you really aren’t in themood for dealing with unpredictable system performance. However, as the authors point out, there are metricsavailable, and the feature can be tuned—or even disabled if necessary.With this feature in the mix I know the first thing I’d check should users complain about response time, becausewhen this feature is triggered you should expect your database grid processors to ratchet up to completesaturation. If your normal host CPU utilization level is not 100% when users are happy, then perhaps a little523