Oracle Scratchpad

May 6, 2009

IOUG Day 2

Filed under: Infrastructure,Troubleshooting — Jonathan Lewis @ 5:22 pm GMT May 6,2009

Today’s little gem – while attending the panel session hosted by the oracle RAC SIG and I asked the  question: “what is the most surprising performance problem that you’ve had with RAC ?” – where surprising means something that wouldn’t cause you to say “I should have known that would happen” after you realise what’s happened. 

Barb Lundhild, the RAC product manager, came up with a gem – a client who switched some of their discs to SSD and ran into a bug because the write times were so fast that the messages that were supposed to synchronise the writes couldn’t complete their trip around the interconnect fast enough to keep up. (The bug is now fixed.)

It’s not often that going too fast is the problem.

Footnote: it seems a little ironic that a little finger-trouble resulted in this note being posted before it was finished – another case of a problem caused by something happening too fast.


  1. Hi Jonathan,
    there is a problem with the link in “the oracle RAC SIG”. But i want take this chance to say that with a four nodes RAC we have encountered performance problems due to the fact that in full table scans getting blocks by global cache from remote nodes is sometimes a lot slower than getting them from disks. (a lot of “gc cr multiblock request” wait events) a we have found no hardware o interconnect communication probles.

    Comment by Cristian — May 7, 2009 @ 8:04 am GMT May 7,2009 | Reply

    • Cristian,

      Sorry I missed this note when it was first posted. It would be worth knowing what sort of speeds you are talking about.

      One of the “problems” with increasing numbers of nodes is that you have an increased chance that you have to split a large “read” request into multiple 3-way transfers.

      When you compare this with the extreme case that you can get from a SAN (where SAN readahead pre-caches the next big multiblock read you’re going to ask for) it’s not too surprising that big tablescans can slow down.

      You have to remember that the important comparison should be between “real disk” speed and “shared cache” speed – but SANs often “cheat” on tablescans.

      Comment by Jonathan Lewis — May 28, 2009 @ 10:25 pm GMT May 28,2009 | Reply

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

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

Google+ photo

You are commenting using your Google+ 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.

Powered by