If you are reading this, it means that world moves on and somebody somewhere was wrong in predicting the end of it. The ageless Log Buffer Edition presents you yet again some cool blog posts just before the holiday season to top up your excitement. This Log Buffer #300 is as sweet as the holidays...
Yesterday I was asked by a customer for the reason why he had
failed to achieve scale with a state-of-the-art "shared-storage"
cluster. "It's a scale-out to 4 servers, but with a shared disk.
And I got, after tons of work and efforts, 130% throughput,
not even close to the expected 400%" he said.
Well, scale-out cannot be achieved with a shared storage and the word "shared" is the key. Scale-out is done with absolutely nothing shared or a "shared-nothing" architecture. This what makes it linear and unlimited. Any shared resource, creates a tremendous burden on each and every database server in the cluster.
In a previous post, I identified database engine activities such as buffer management, locking, thread locks/semaphores, and recovery tasks - as the main bottleneck in the OLTP …
As described in the prior post, the shared-disk performance
dilemma is simple:
1. If each node stores/processes data in memory, versus disk, it is much faster.
2. Each node must expose the most recent data to the other nodes, so those other nodes are not using old data.
In other words, #1 above says flush data to disk VERY INFREQUENTLY for better performance, while #2 says flush everything to disk IMMEDIATELY for data consistency.
Oracle recognized this dilemma when they built Oracle Parallel Server (OPS), the precursor to Oracle Real Application Cluster (RAC). In order to address the problem, Oracle developed Cache Fusion.
Cache fusion is a peer-based shared cache. Each node works with a certain set of data in its local cache, until another node needs that data. When one node …
Mike Hogan, CEO of ScaleDB spoke at the Boston MySQL User Group in September 2009:
ScaleDB is a storage engine for MySQL that delivers shared-disk clustering. It has been described as the Oracle RAC of MySQL. Using ScaleDB, you can scale your cluster by simply adding nodes, without partitioning your data. Each node has full read/write capability, eliminating the need for slaves, while delivering cluster-level load balancing. ScaleDB is looking for additional beta testers, there is a sign up at http://www.scaledb.com.
Slides are online (and downloadable) at http://www.slideshare.net/Sheeri/scale-db-preso-for-boston-my-sql-meetup-92009
Watch the video online at …[Read more]
Larry Ellison is announcing a major new feature this Wednesday at Open World. For the first time in a while, his keynote is dedicated to the “database” as opposed to the usual high level ERP/Apps/Fusion. Even the title of his keynote is catchy — “Extreme Performance”.
Oracle has been keeping the new feature a secret. Even the 11gR2 beta program had very few participants to prevent information leaking out. It’s, “Something’s coming, but I am not telling what.”
Okay, it worked on me, I’m excited about it. Let’s think what it could be. What single database feature is so major, that Larry himself will announce it during OpenWorld?
What do we …[Read more]
If a MySQL DBA from Pythian goes to Oracle Open World, it would be a shame not to send an Oracle bloke, so there I am — presenting a 90-minute session on the first day of the OOW 08 entitled Under the Hood of Oracle Clusterware.
I gave it during RAC Attack in Chicago and I’m pretty satisfied with how it went, so there should be no significant changes to the presentation. The session is in “User Group Forum,” thanks to RAC SIG and Dan Norris.
When the session was first …[Read more]
Have you ever heard the one about throwing hardware at a software problem? In one of my previous blog posts, I mentioned something along the lines of?well I’ll just cut and paste . . . In my experience, the solution to most problems (the ones the caller refers to as “it’s running slow”) are not rooted in [...]