Expert Oracle Exadata - Parent Directory

CHAPTER 7 RESOURCE MANAGEMENTOver-ProvisioningOver-provisioning refers to the practice of allocating more CPUs to the databases than are actuallyinstalled in the server. This is useful when your server hosts multiple databases with complementingworkload schedules. For example, if all the heavy processing for the SCRATCH database occurs at night,and the SNIFF database is only busy during DAYTIME hours, it wouldn’t make sense to artificially limitthese databases to 8 CPU threads each (8×8). A better CPU allocation scheme might be more on theorder of 12×12. This would allow each database to fully utilize 12 cores during busy periods, while still“reserving” 4 cores for off-peak processing by the other database. DBAs who consolidate multipledatabases onto a single server are aware that their databases don’t use their full CPU allocation(CPU_COUNT) all of the time. Over-provisioning allows unused CPU to be utilized by other databases ratherthan sitting idle. Over-provisioning has become a popular way of managing CPU resources in mixedworkload environments. Obviously, over-provisioning CPU introduces the risk of saturating CPUresources. Keep this in mind if you are considering this technique. Be sure you understand the workloadschedules of each database when determining the most beneficial CPU count for each database.Instance caging limits the number of CPU cores a database may use at any given time, allowingDBAs to allocate CPU to databases based on the needs and priorities of the business. It does this throughthe use of the instance parameter CPU_COUNT. Our preference would have been to allocate CPU based ona percentage of CPU rather the number of cores. This would give the DBA much finer-grained controlover CPU resources and would be especially useful for server environments that support numerousdatabases. But CPU_COUNT is tightly coupled with Oracle’s Cost Based Optimizer (CBO), which uses thenumber of CPUs for its internal costing algorithms. It wouldn’t make sense to allow the DBA to set thepercentage of processing power without matching that with the value the CBO uses for selecting optimalexecution plans. It probably would have been a much more difficult effort to implement such a changeto the optimizer. Be that as it may, instance caging is a powerful new feature that we’ve been waiting for,for a long time and is a major advancement database resource management.I/O Resource ManagerEarlier in this chapter we discussed Oracle’s Database Resource Manager, which manages CPUresources within a database through consumer groups and plan directives. Sessions are assigned toresource groups, and plan directives manage the allocation of resources by assigning values such as CPUpercentage to resource management attributes such as MGMT_P1..8. DBRM, however, is limited tomanaging resources within the database.DBRM manages I/O resources in a somewhat indirect manner by limiting CPU and parallelismavailable to user sessions (through consumer groups). This is because until Exadata came along, Oraclehad no presence at the storage tier. Exadata lifts I/O Resource Management above the database tier andmanages I/O at the storage cell in a very direct way. Databases installed on Exadata send I/O requests tocellsrv on the storage cells using a proprietary protocol known as Intelligent Database protocol (iDB).Using iDB, the database packs additional attributes in every I/O call to the storage cells. This additionalinformation is used in a number of ways. For example, IORM uses the type of file (redo, undo, datafile,control file, and so on) for which the I/O was requested to determine whether caching the blocks in flashcache would be beneficial or not. Three other attributes embedded in the I/O request identify thedatabase, the consumer group, and the consumer group’s category. These three small bits of additionalinformation are invaluable to Oracle’s intelligent storage. Knowing which database is making therequest allows IORM to prioritize I/O requests by database. Categories extend the concept of consumergroups on Exadata platforms. Categories are assigned to consumer groups within the database usingDatabase Resource Manager. Common categories, defined in multiple databases, can then be allocateda shared I/O priority. For example, you may have several databases that map user sessions to an204