Expert Oracle Exadata - Parent Directory

CHAPTER 7 RESOURCE MANAGEMENT50% may be further distributed to the APPS, REPORTS, BATCH, and OTHER_GROUPSconsumer groups within the database. This ensures that I/O resources are availablefor critical applications, and it prevents misbehaving or I/O-intensive processesfrom stealing I/O from higher-priority sessions inside the database.How IORM WorksIORM manages I/O at the storage cell by organizing incoming I/O requests into queues according thedatabase name, category, or consumer group that initiated the request. It then services these queuesaccording to the priority defined for them in the resource plan. IORM only actively manages I/Orequests when needed. When a cell disk is not fully utilized, cellsrv issues I/O requests to itimmediately. But when a disk is heavily utilized, cellsrv instead redirects the I/O requests to theappropriate IORM queues and schedules I/O from there to the cell disk queues according to the policiesdefined in your IORM plans. For example, using our SCRATCH and SNIFF databases from earlier in thischapter, we could define a 75% I/O directive for the SCRATCH database, and a 25% I/O directive for theSNIFF database. When the storage cells have excess capacity available, the I/O queues will be serviced ina first-in-first-out (FIFO) manner. During off-peak hours, the storage cells will provide maximumthroughput to all databases in an even-handed manner. But when the storage cell begins to saturate, theSCRATCH queue will be scheduled 75% of the time, and the SNIFF queue will be scheduled 25% of the time.I/O requests from database background processes are scheduled according to their relative priority tothe foreground processes (client sessions). For example, while the database writer processes (DBWn) aregiven priority equal to that of foreground processes, performance critical I/O requests from backgroundprocesses that maintain control files, and redo log files are given higher priority. Note: IORM only manages I/O for physical disks. I/O requests for objects in the flash cache or on flash-basedgrid disks are not managed by IORM.IORM ArchitectureFigure 7-8 illustrates the architecture of IORM. For each cell disk, cellsrv (Cellserv) maintains an IORMqueue for each consumer group, and each background process (high, medium, and low priority), foreach database accessing the storage cell. By managing the flow of I/O requests between the IORMqueues and the disk queues, cellsrv provides very effective I/O prioritization at the storage cells. I/Orequests sent to the storage cell include tags that identify the database and the consumer group issuingthe request, as well as the type of I/O (redo, control file, and so on). For databases that do not have anIntradatabase resource plan defined, foreground processes are automatically mapped to the consumergroup OTHER_GROUPS. Three separate queues are maintained for background processes so that cellsrvmay prioritize scheduling according to the type of I/O request. For example, redo and control file I/Ooperations are sent to the high-priority queue for background processes. IORM schedules I/O requestsfrom the consumer group queues according to the I/O directives in your IORM Plan.206