The late breaking news of the day is that by December 31st, Sun engineers will have taped out the next generation mega-multi-core processor called “Rock”. Some is good, so more must be better. This one offers 16 cores. News has been out about Rock for several years. Back in 2004 the project had the code name “Project 30x” because it aimed to out-perform the US-III of the day by a factor of 30. On the humor side, this zdnet.com article about the Sun “Rock” chip throws in a twist. It seems if the processor is not taped out by the end of the year, Sun engineers have to wear ties. I’d hate to see that happen.
What Does This Have To Do With Oracle?
These processors are going to be really, really fast. The first generation will be based on 65nm real estate, but the already planned follow-on 45nm offering will up the ante even more. I recently blogged about Sun CoolThreads “Niagra” performance with Oracle. Fact is that shops currently running Oracle on SPARC hardware of the Ultra Enterprise class can easily migrate over to these new systems—particularly for OLTP. Those are 8 core (90nm) packages. With Rock, I think we can expect performance commensurate with the packaging. That means a single multi-core system based on this technology is, quite honestly, nearly too big.
Datacenters today are scrambling to get their processor utilization up and their power consumption down. And, oh, is Oracle going to charge .25 of a CPU license per core? The bottom line for Rock is that there is a tremendous number of Sun Ultra Enterprise gear out there that will need replacing soon. Maybe some of the replacement-business will help Sun continue their trend as the only vendor seeing server revenue increases. All the other vendors seem to be finding that new purchases are being held back by the continuing effort to chop these already “small” servers into smaller servers with virtualization.
No, Really, What Does This Have To Do With Oracle?
Folks, this is the era of multi-core processors (e.g., the Xeon 53XX Clovertown) that achieve TPC-C results of 50,000+ per core. Remember, the highest result ever attained by the venerable Starfire UE 10000 was roughly 155,000—with 64 CPUs. It won’t be long until you are carving up a single core to support your Oracle database. And I pose that sub-core Oracle database deployments will be the lion’s share of the market too. But even for the “heavy” databases, it wont be long until they too only require just some of the cores that a single socket will offer.
Who Scales Better? Oracle? DB2? MySQL?
Oracle raced to the head of the pack throughout the 1990s by offering the most robust SMP scalability. So let me ask, if your application can be back-ended by Oracle executing within a virtual processor that represents only a portion of a socket, how scalable does the RDBMS kernel really need to be?
Kevin Closson's Blog: Platforms, Databases and Storage 
“So let me ask, if your application can be back-ended by Oracle executing within a virtual processor that represents only a portion of a socket, how scalable does the RDBMS kernel really need to be?”
Pah! I’ll show you 12 concurrent FTS on a multi-GB table as a result of a “coding glitch” and raise you a few more caused by a total lack of QA in application development! Glue that with complete lack of a clue in database design and you got the perfect recipe for a need for as much processing power as one can get.
“Roll on the multi-cored GHz: we’ll make your systems scalable, like it or not!” is the modern catch phrase. And everyone is gobbling it.
I’m almost reminded of the late 70’s attitude that “there is no need to code efficient programs, faster CPUs are here for that, just code in Cobol!” and other blatant disregard for efficiency in the IT sphere.
Those who ignore history are indeed condemned to repeat it.
Well, it is impossible to have enough hardware for poor software and impossible not to have poor software. I think I’m following your point, Noons… thanks as always for the comment…
I do think that a significant percentage of all Oracle databases out there will quite soon function nicely in a fraction of a socket. But I could be completely nuts. Remember, 50,000+ TpmC per core–now, what is next?
I don’t think you’re nuts, Kevin. On the contrary, I’m starting to see cases where your prediction is coming true.
I was trying to do a trackback from my blog to this post but I haven’t figured out yet how to do that in blogspot so here’s a link:
http://jforonda.blogspot.com/2006/12/scaling-out.html
James,
Uh, I’m glad you don’t think I’m nuts. Thanks for reading….
Hey Kevin – I hope I didn’t offend you. The nuts was in reference to your “But I could be completely nuts.” reply to Noons’ comment.
James
James,
Oh no… no problem…thanks for reading
Kevin,
With reference to your statement below:
“OK, remind me again who actually needs to “scale-out” a database to multiple servers?”
I am of the opinion that scale-out is not the only reason why people implenent RAC these days or at least that is not the primary reason that it should be implemented. RAC (if works properly) can help provide high-availability in the form of not only quickly failing over lost connections but can also help (again, if carefully designed) reduce the impact only to a certain percentage of connections that were lost by the failure of a certain node.
Amir,
Right you are. Thanks for reading!