10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 7 RESOURCE MANAGEMENT Note: In most cases, a single-level I/O resource plan is sufficient. As they do with DBRM, multi-level IORMresource plans increase the complexity of measuring the effectiveness of your allocation scheme.When using multi-level allocation schemes, it’s important to understand that I/O resources allocated but unused bya database, category, or consumer group on level 1 are immediately passed to the next level. For example, if youhave databases A and B allocated 70%/30% on level 1, and database C is allocated 100% at level 2, then ifdatabase A uses only 50% of its allocation, the remaining 20% is passed to database C. Database B cannotcapitalize on I/O resources allocated but unused by database A, because A and B are on the same level. This is asubtle but important distinction of multi-level plans. If you are not careful, you can find yourself unintentionallygiving excess I/O resources to less important databases at lower levels rather than making those resourcesavailable to your higher-priority databases on level 1.Workload OptimizationTo optimize I/O performance, IORM distinguishes between small and large I/O requests. Requests lessthan 128K in size, typically associated with OLTP transactions, are categorized as small (SM) requests.Requests 128K in size or greater, which are generally associated with DW transactions, are categorized aslarge (LG) requests. The distinction between small and large I/O requests is important because thealgorithms used for optimizing low-latency I/O requests (small requests) and high-throughput I/Orequests (large requests) are polar opposites. For OLTP transactions, low latency is most important. Forexample, consider an end user waiting for a quick ZIP code search to populate the screen. To provideoptimized performance for low-latency requests, large I/O requests must be managed in such a way thatthey don’t fully consume the I/O resources of the storage cell. Conversely, DW transactions require highthroughput to maximize performance. To optimize I/O for throughput, the storage cell must servicemany concurrent large I/O requests so that it is fully consumed. By comparing the large (LG) and small(SM) I/O requests in the IORM metrics, you can determine whether your databases lean more toward aDW workload or an OLTP workload. Recently, <strong>Oracle</strong> added a new attribute to IORM, known as theoptimization objective. This attribute determines the optimization mode IORM will use whenmanaging cell disk I/O queues. The optional values for the IORM objective attribute are as follows:low_latency: This setting provides optimization for applications that are extremelysensitive to I/O latency. It provides the lowest possible I/O latencies, bysignificantly limiting disk utilization. In other words, throughput-hungryapplications will be significantly (negatively) impacted by this optimizationobjective.high_throughput: This setting provides the best possible throughput for DWtransactions, by attempting to fully utilize the I/O capacity of the storage cells. It isthe opposite of low_latency and as such, it will significantly (negatively) impactdisk I/O latency.Balanced: This setting attempts to strike a balance between low latency and highthroughput. This is done by limiting disk utilization for large I/O operations to alesser degree than the low_latency objective described above. Use this objective208

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!