V$SYS_TIME_MODEL and V$SYSMETRIC_HISTORY come to mind. The GV$ versions are for all the instances in a given database, V$ the individual instances.
Do you have multiple independent databases running or are these PDBs within a single container on each node?
That’s from the database viewpoint keeping track of itself with sampling.
From ps output with the right flags (assuming you have system authority to dump those out) and if your database backend names are reasonably parseable,
you can pipe that to awk or perl (or <fill in latest version of analysis candy tool ?python maybe?>) and sum up the cpu numbers.
All this is much easier when decently close is the desired answer rather than tooling to split hairs for repeated regression runs to figure out what is absolutely best for something.
It seems to me you’re just looking for run-away detection for cpu storms. Time sharing usage control can become arbitrarily complex, but if you’re just looking for storms rather than precision for back billing remember that as you build your watcher. Also remember to subtract the sum of the per instance totals from the total for the box. When everything seems “slow” there is a non-zero possibility that the OS non-database jobs and/or things like backups and routine maintenance are sucking up the juice.
By the way, do your clients run on the database server?
When someone starts asking this question putting some sort of job scheduler in place is usually the result.
Probably someone has something reasonably canned up for various OS releases and Oracle versions and so forth. Some may be free and some may be for sale or come with paid consulting support.
Good luck,
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Krishnaprasad Yadav
Sent: Saturday, March 16, 2024 5:41 AM
To: Oracle L
Subject: High CPU utilization
