If you're like me and many other database professionals, you might not have as much time as you'd like to keep up with the latest trends in hardware development. So when Microsoft recently clarified its database pricing policy for SQL Server running on dualcore servers, it occurred to me that many SQL Server folks might not even know what a dualcore server is. This commentary isn't the proper place to explore all the ins and outs of dualcore technology. A simple Internet search for "dual core CPU" will turn up plenty of information to satisfy the inner geek that lurks within you. But to give you the background you need to keep up with SQL Server pricing, I'll give you a simple explanation of dualcore technology.
Historically, increasing CPU processor power has meant putting more circuits on every chip. The more circuitry that chip makers could pack into a CPU, the faster the CPU could run. But eventually, there's a limit to the number of circuits that will fit on one small piece of silicon. Also, both power consumption and heat creation increase as the number of circuits on a chip increases, which creates a new set of engineering problems. Dualcore chips are essentially two separate processorsspecifically, multiple processingexecution unitson one chip that plugs into one CPU socket on the motherboard. This design lets manufacturers create dualcore chips that run at lower clock speeds, consume less power, and generate less heat than their singlecore cousins.
I'll be honest, I'm not enough of a hardware geek to fully explain the engineering behind why all this makes a difference. But here's what I know: Multiprocessoraware applications such as SQL Server can readily take advantage of dualcore technology. From a database perspective, dualcore processing is conceptually similar to Intel HyperThreading CPU technology. Both dualcore and HyperThreading technology provide the database with what looks like another CPU. But the additional CPU in a HyperThreading solution is simply a logical CPU, not a true CPU. The extra CPU that a dualcore chip provides is a separate, physical device. Although a HyperThreaded CPU can be beneficial in a database environment, it's simply not as good as having a genuine physical processor.
All things considered, dualcore servers offer about the same CPU performance as a singlecore solution that has two processors. But for a variety of reasons, dualcore servers tend to be less expensive. Today, moving from a fourCPU box to an eightCPU box can be expensive. I haven't had a chance to fully study vendor pricing plans for highend dualcore servers, but the manufacturing costs of an 8way server that uses singlecore CPUs are greater than the costs of making a server with four dualcore CPUs. Today, 4x HyperThreaded servers are the standard "commodity box" that many of my customers use. Soon, I expect this standard to be a 4x dualcore server. The costs probably won't be too much more than a singlecore 4x HyperThreaded box, but the performance of the dualcore server with eight "real" processors should be noticeably better.
Now that you know what dualcore technology isand why it's interesting to database folkshere's the skinny on Microsoft's pricing model. Microsoft will charge per CPU socket, not per core. So a fourCPU dualcore server (i.e., eight cores) would require a fourCPU license. This price model is somewhat different from the pricing of other major relational database vendors. IBM charges per CPU for x86based platforms but charges per core for its POWER5based systems. Oracle has come up with the slightly confusing model of treating each core as 75 percent of a CPU and rounding up to the nearest integer. According to the Oracle model, a singleCPU dualcore server would be priced as 2 x .75, or 1.5 CPUs, which rounds up to two CPU licenses. A 4x dualcore box would be priced as 8 x 7.5, or six CPUs. I'll be a bit surprised if Oracle sticks to this pricing model because it gives Microsoft an even greater cost advantage than it currently enjoys.
