Hello,
We are planning on moving over 90 Oracle databases from standalone servers into 3 new RACs.
The question is how to make three groups of databases achieving the minimum CPU-I/O usage at any time (probabilistically).
These groups should be composed of databases with complimentary loads in time.
We think maybe we could base the matching around the metric 'Database Time Per Sec' (V$SYSMETRIC_HISTORY), analyzing how it behaves for each db during business hours, outside business hours, in a week, in a month, etc.
According to
https://www.oracle.com/technetwork/database/manageability/db-perf-tuning-ow08-131582.pdf 'Database Time Per Sec' does not include "Background Time Per Sec"
Should we include "Background Time Per Sec" in our analysis?
Thing is the METRIC_UNIT for "Background Time Per Sec" is not a time unit, and it is a little bit confusing ("Active Sessions"), how should we interpret this?
Do you have any suggestion about this?, any other metric (or a calculation of metrics)?
If you know of any step-by-step guide regarding this tasks or capacity management, we'll be very grateful.
Thank you.
I would not worry too much about background time because it is (almost) always a by-product of foreground time (eg, your redo writer is only busy because foregrounds are making changes)
So if you apportion based on foreground sessions you'll most likely be achieving the same for background overheads.
For me, I almost exclusively based my planning on average active sessions, because even if some sessions are CPU intensive and others are I/O intensive, ultimately (given modern disk arrays) those I/O intensive ones will be going heavy on the CPU anyway. So I treat an "active session" as being a "CPU burner", and use that to decide where I want to split my workloads up (either based on total load, or their load at certain times of the day/week/etc).
But I would add this caution - its not *just* about load, unless every application you have has the same requirements in terms of
- uptime
- software version dependencies
- RPO/RTO
- maintenance/patch cycles etc
Make sure you take everything into account in order to come up with a strategy that will best meet all of those business objectives.
And don't forget that (assuming you'll be using pluggable databases) that in a worst case scenario, you can unplug a database from one server and relocate it to another if needs be.