Exadata systems allow greater database consolidation without the complexities of slicing, distributing, and managing workloads across disks and diskgroups, while also providing better bandwidth and space utilization. With all databases sharing the same disks, I/O Resource Management (IORM) is the mechanism used to maintain a predictable level of performance amongst your consolidated databases. With IORM you can guarantee a percentage of I/O operations for each database on your system and also limit them as necessary. Allocations are distributed as a percentage of total available I/O operations per storage cell and all databases processes are regulated by IORM, so when evaluating how best IORM will work for your system you need to consider not only the behavior of your applications foreground user processes but also the background database processes such as the database writers.
Note : – For additional detail about IORM see the Oracle Support Document 13390769.1: “Master Note for Oracle Database Resource Manager”
The Oracle Exadata Plug-in provides a consolidated view of the Exadata Database Machine within Oracle Enterprise Manager. Plug-in Release 22.214.171.124.0 includes a variety of bug fixes and enhancements that allow for an even more powerful interface for Exadata. Enhancements include:
- Fine-grained performance summary for flash and hard disk with side-by-side comparison.
- The Ability to fine tune date ranges for graphs via hard date ranges or via Slider
- New usage statistics to highlight flash cache and Smart Scan efficiency
- Performance utilization for flash and hard disk to identify workload reaching hardware limits.
- IORM wait per database metric.
- Performance comparison between multiple Exadata Cell servers.
If checkpoint writes do not contribute to the total physical writes significantly, check if buffer cache may be undersized which may lead to excessive aging writes.
What are the signs for undersized buffer cache?
If AWR Buffer Pool Advisory (based on v$db_cache_advisory) shows significant savings in reads with size increase, it will most likely reduce aging writes as well, but there is no guarantee.
Check for long latencies in “db file parallel write.”
Increase buffer pool size if needed.
For more information, refer to Configuring and Using the Buffer Cache in Performance Tuning Guide.
Sometime you will see “Free Buffer Waits” as one of TOP 5 waits in your AWR reports. It is a very important metric to monitor and can be mange many diffent ways. Free buffer waits indicate that a database process was not able to find a free buffer into which to perform a read operation. This occurs when the DBWR process can’t write blocks to storage fast enough.
“Free buffer waits” are an indication that the write rate of the I/O system is maxed out or is close to being maxed out. If this statistic appears in the top 5 wait events, then proactive action should be taken to reduce the write rate or increase the I/O capacity of storage. Make sure smart flash cache and smart flash log are configured , assuming the system is running Exadata version 126.96.36.199.1 and GI 188.8.131.52 BP9 (or higher). With latest deployment of Exadata, 512 MB of the Exadata flash is allocated to Smart Flash Logging and this is an insignificant investment for a huge performance benefit. You can also implement compression to reduce the size of data and therefore reduce the number of I/Os that are necessary to run the application