This content has been marked as final. Show 5 replies
I did a webinar on using IORM for consolidation a recording and slides are available at http://www.ioug.org/BestPracticesSolutions/Webinars/Exadata11211/Exadata22212/tabid/305/Default.aspx. It has an example with the syntax used to set it up.
Looking at your proposal, you mention you don't want the dev db to ever create issues for production by consuming resources. So to me it wounds like you want a plan allocating 100% of CPU/IO resources to production at the first level, and then allocating any available resources to development/QA at the second level. Unless you need more granularity, I don't see the need for a category plan, as an inter-database plan should do what you need.
Also keep in mind that your database nodes have a fixed amount of memory, so you'll need to size PGA and SGA targets for both production and development databases so as to have sufficient capacity available.
Hope this helps!
though this is slightly deviating from the topic it may be relevant to a discussion of IORM as a whole. According to Oracle's documentation IORM only kicks in when the IO subsystem is 100% saturated. However if we choose disk objectives like "low-latency" and auto should iorm activate even when the io is not saturated ?
Also apart from IORM, dbrm may be required to ensure other resources specially cpu are not hogged by the dev database ...
Now that limits exist it's possible to do I/O resource management even when utilization is below 100%, though somewhat less flexibly. And as far as CPU limits go it's actually required: I/O policies intra-database imply CPU management too. Between databases though you need to either use limits or old-fashioned instance caging.
The IORM Objective feature is available upwards of 188.8.131.52
Some valid options would be:
low_latency - OLTP
high_throughput - DSS
The following note may be useful during setting up IORM in your scenario:
Configuring Exadata I/O Resource Manager for Common Scenarios (Doc ID 1363188.1)