Oracle Performance on Sun’s “Rock” Processors and Oracle Scalability

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 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?

8 Responses to “Oracle Performance on Sun’s “Rock” Processors and Oracle Scalability”

  1. 1 Noons December 9, 2006 at 1:16 am

    “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.

  2. 2 kevinclosson December 9, 2006 at 2:29 am

    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?

  3. 3 James Foronda December 9, 2006 at 4:32 pm

    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:

  4. 4 kevinclosson December 9, 2006 at 6:21 pm


    Uh, I’m glad you don’t think I’m nuts. Thanks for reading….

  5. 5 James Foronda December 9, 2006 at 9:11 pm

    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.


  6. 6 kevinclosson December 9, 2006 at 9:48 pm


    Oh no… no problem…thanks for reading

  7. 7 Amir Hameed December 10, 2006 at 3:51 am

    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.

  8. 8 kevinclosson December 10, 2006 at 5:10 am


    Right you are. Thanks for reading!

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon. In other words, I work at Amazon, but this is my own opinion.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 747 other subscribers
Oracle ACE Program Status

Click It

website metrics

Fond Memories


All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.

%d bloggers like this: