Re: Exadata CPU Upgrade
From: Karl Arao <karlarao_at_gmail.com>
Date: Sun, 2 Sep 2012 14:27:15 -0500
Message-ID: <CACNsJncJHN55+f0cBj7kAGsqKD8NrQvOyDWQ8hA8P5G9990eyQ_at_mail.gmail.com>
I doubt that you will be able to fit that in a half rack Exadata :) let's say each of the database is coming from the same CPU as the Exadata and only needs 1core for its workload the sum of that will be 60cores / 96cores = 62.5% utilization and that's not accounting any plan change or workload spikes or any allowance for any unforeseen scenarios. And let's say 10 of those databases would peak at 4cores at the same time then you'll eat up all the CPUs. BTW I would recommend instance caging across the board for this kind of consolidated environment.
Proper provisioning is the key thing here, it doesn't mean that if it's Exadata I can fit in 60 databases in it. The capacity planning that you do on non-Exa platform is still pretty much the same on an Exadata platform. Actually there was this one customer when we were doing the planning has a list of 180 databases to be migrated on Exadata (half rack)... guess what, only 36 made it because they ran out of memory. As you add more and more DBs make sure to validate the overall cluster utilization (CPU).. and not all databases should be in Exadata let's say I would favor a QA database (more critical and close to production) over a demo database if you have a long list of DBs to migrate.
Date: Sun, 2 Sep 2012 14:27:15 -0500
Message-ID: <CACNsJncJHN55+f0cBj7kAGsqKD8NrQvOyDWQ8hA8P5G9990eyQ_at_mail.gmail.com>
I doubt that you will be able to fit that in a half rack Exadata :) let's say each of the database is coming from the same CPU as the Exadata and only needs 1core for its workload the sum of that will be 60cores / 96cores = 62.5% utilization and that's not accounting any plan change or workload spikes or any allowance for any unforeseen scenarios. And let's say 10 of those databases would peak at 4cores at the same time then you'll eat up all the CPUs. BTW I would recommend instance caging across the board for this kind of consolidated environment.
Proper provisioning is the key thing here, it doesn't mean that if it's Exadata I can fit in 60 databases in it. The capacity planning that you do on non-Exa platform is still pretty much the same on an Exadata platform. Actually there was this one customer when we were doing the planning has a list of 180 databases to be migrated on Exadata (half rack)... guess what, only 36 made it because they ran out of memory. As you add more and more DBs make sure to validate the overall cluster utilization (CPU).. and not all databases should be in Exadata let's say I would favor a QA database (more critical and close to production) over a demo database if you have a long list of DBs to migrate.
You may also be interested on the following links: cpu - SPECint_rate2006 http://goo.gl/doBI5 cpu core comparison http://goo.gl/M8mVW
-- Karl Arao karlarao.wordpress.com karlarao.tiddlyspot.com twitter.com/karlarao -- http://www.freelists.org/webpage/oracle-lReceived on Sun Sep 02 2012 - 14:27:15 CDT