We have Exadata V-2 Quarter Rack with 2 db servers and 6 cell servers. We have one production Database 188.8.131.52 with 2 instances and now we have a requirement to create a development database.
Since Development Database would not be so critical as production so we are thinking to create dev db as stand alone database on node 1.
We want to allocate percentage of resources for prod and dev db hence by any time development database would not take full resources and make issue for production db.
We are thinking to allocated 75:25 CPU resources for prod and dev db.
We do not have any Exadata Dev/Test environment so we must create Dev DB in the same environment. I know after creating DEV DB, it will occupy some of the resources and obviously production DB would be getting comparatively less resources than currently it is getting. I will have to compromise on Production DB resources somewhere if I want DEV db in the same environment.
If you have implemented IORM, could you please share your idea on this scenario and if possible please share the category plan to implement it successfully.
Please let me know if any other information is required here.
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.
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.
I am curious is there any particular patchlevel /version we need to be on to enable this ( i.e disk objective was introduced from version ....)
also does that mean we should choose a disk objective ? Currently this is set to the default (blank string ) at all installations I have worked.