is high cpu a bad thing I had a heated discussion today with some colleagues about high cpu. 

We db guys are conditioned to believe that high cpu is a bad thing. I think we spend too much time worrying about cpu and not enough worrying about our real nemesis, those d#mn SANS. When did SANs become more important than a companies data? That's another rant for another day. Back to my cpu question. 

I disagree. If the instance is properly tuned and the big three are properly satiated then I don't see anything wrong with a box running at 70%. 

Now, PR has weighed in on our discussion. 

"up to DBA to know what's right for the system, and constant high cpu is probably a bad sign. I'd be concerned with your scenario but better than constant" 

My scenario was a box properly tuned running at 65% with spikes to 90%. You won't hear me say this often but I disagree with Paul on this one. 

So, I'd love to hear from some of the more experienced players here.
It depends (as with all interesting questions).  Much of the disagreement on this point tends to come from people talking past each other because they have different concerns, different assumptions, or different time horizons.

On the one hand, a consistently high CPU load is a problem for most systems because it indicates that you likely have relatively little room for growth before CPU becomes your bottleneck and before your CPU run queue starts growing exponentially.  If my system is constantly running at 65% CPU and I'm adding users and functionality every month or expecting that end-of-month/ end-of-quarter/ some other event is going to periodically cause load to increase 20 or 25%, I'm uncomfortably close to exhausting my available CPU and causing my query response times to soar as everyone ends up queued waiting for CPU.  Since adding CPU to a machine is typically difficult-- unless you're running in a virtual environment, it almost always involves buying a brand new server-- an impending CPU bottleneck is generally particularly concerning.  

On the other hand, a consistently high CPU load indicates that right now you're probably using your resources effectively.  If you're building a data warehouse, you'd ideally be close to maxing out both CPU and available I/O during your nightly loads, for example, balancing the amount of parallelism you use to get the most efficient loads.  If you assume that tomorrow's load is going to be basically identical to today's load, you'd welcome a high CPU load.  After all, it's not like you can bank your unused CPU cycles for a rainy day.  

As with any metric, it's also important to have real benchmarks to compare to.  Unfortunately, lots of shops don't know what their performance profile is when things are running smoothly.  No one calls the DBA to let them know that the system is performing perfectly and under the appropriate amount of load to let her know to capture a baseline.  If you have a real baseline from when the system was performing well under a similar amount of load and that baseline had high CPU consumption, it's safe to assume that your system functions well at relatively high CPU load.  

Without those real baselines, though, many DBAs have developed rules of thumb that (often inaccurately) give them some context for what an average system looks like and will compare that average to the current load.  That sort of intuition is better than nothing when you don't have real data to compare against but it often fails when looking at specific systems.  If you look at the body mass index (BMI) of a population, it's pretty good at determining which populations are under- and over-nourished.  If you look at the BMI of specific individuals, however, the metric is much less useful-- professional athletes will almost all be "overweight" or "obese" when looking at BMI despite being in excellent shape.  A DBA's (or a monitoring tool's) rule of thumb is like the BMI in that it's reasonably accurate for a population but much less accurate for an individual.