Running Oracle in less RAM will mean more disk I/O. Since the Disk is 30,000 time slower than RAM the CPUs will spend more time waiting on Disk and less time thinking, but the users are bound to notice a slow down in their querys.
One big change is the number of back ground jobs you wish to run at any one time, with 10 CPUS you should have tuned the application to allow 9 or 10 batch or report jobs at a time, with 4 CPUs it should be tuned to allow only 3 or 4 batch or report jobs at a time. (since the CPUs are faster, you almost make up for fewer of them.
In Oracle Financials you have a Concurrent Manager which shedules background jobs, your application may use some similar schedular
sar -q as a command will give you a trend on how many CPUs the current load thinks it 'needs'. the second column shows you the % of time at least one job was waiting for a CPU to be free, the first column shows the number of jobs waiting on a CPU when that happens.
it is possible to write an app so that it spends time almost idle then bursts into activity all at once that wants many CPUs, my (purchased) Lab database app wants 7 CPUs every 5 minutes but is idle between bursts, very hard to tune
Keeping the CPUs busy implys you are getting the maximum use out of them, which is good, if the load shown by uptime is about 4 and the number of CPUs desired in sar -q is low, you may be ideal. if it is near 6 and the number of CPUs desidered is near 2 then think of adding another CPU board.
It is always a mistake to think that Mhz equals the power of a CPU, that would only be true if every CPU did the same amount of thinking each cycle. so 4 * 1050 need not be near 10 * 450 in CPU power, but even if it was the same amount of power, you need to tune for fewer jobs that complete faster than before
Show us a uptime, a sar -q and a mpstat 5 5 and we can guess better.
I tried to remain child-like, all I acheived was childish.