... proves that he has absolutely no clue how the real world works ... and in his own words, even. The worst part is that he seems to be PROUD of his ignorance ...
You have to admire Larry Ellison, the Oracle co-founder and chief executive officer of IT giant Oracle. Well, maybe admire isn't the right word. But you can at least be amused by him. Yesterday, Ellison spent the last hour of the five-hour Sun takeover extravaganza taking questions from the audience, mostly fielding softball …
Come on, not even Larry can believe that huge pile of dung! I suppose the crowd must have been full of Sunshiners and Oraclistas, otherwise someone would have pointed out that RAC was based on Compaq's Alpha clustering software, so even that's not Oracle's "invention".
But the really funny thing he says is when he goes on about "a seamless, integrated stack of hardware and software, just like IBM had in the sixties", because as an Oracle customer, what I hear is "lock-in, lock-in, lock-in", which is not attractive.
"... proves that he has absolutely no clue how the real world works ... and in his own words, even. The worst part is that he seems to be PROUD of his ignorance ..."
Yeah , that'll be why Oracle has become such a niche player in the business systems software market... oh , wait...
Ellison might be arrogant and obnoxious , but he is in no way ignorant.
RAC has multiple nodes online that can accept requests, meaning officially the database never goes down if just one node is offline.
In reality, the spids executing on a RAC node that fails will also fail, which may cause a batch job to fail or end-user application errors. It's still faster than MS SQL cluster failovers, which definitely bring the whole db down and then back up.
I'm personally unconvinced that RAC does much for speed though, without a boatload of application customization. It's not unusual to have one node blocking another, so truly parallel access to a single database over several physical nodes usually isn't achieved. At best, let's agree that it doesn't scale linearly as nodes are added.
Expect more price increases as they march to their $1.5B profit in year one.
Last year Oracle raised prices 19% for their products and 47% on the BEA products.
Expect maintenance costs and software to go thru the roof. The last thing anyone wants to do is give Oracle even more of the IT spend when they are just going to raise prices double digit.
The Sunacle webcast was unbelievably endless and boring. Not a singe bit of real news in more than five hours. If you have nothing to say, overwhelm'em with the size of the event. That seemed to be the tactic.
Hours of we are the best, we are the only ones and a closing remark by The Lord of The Yachts attacking IBM, NetApp, and the whole world. Lies, royal smiles fulll of arrogance and self-sufficiency and more lies (DB2 can't scale... IBM is soooo behind Sunacle... we crushed them with the TPC.C ran on a cluster of T5440s...) LE must think that being a billionare gives you a free pass to invent the world around you.
Alpha Man is getting old and paranoid. His obsession with the IBM of the fifties seems pretty natural.
I'm definitely not a database expert or anything, but I've talked to my share of guys who are database gurus over the years. And, assuming I understood what they told me, Oracle RAC is really Son of Oracle Parallel Server. Back in the day, OPS was notorious for not scaling in anything like a linear way. From what I hear, RAC isn't much better for a transactional database. If it's read only, it might scale reasonably well to a handful of nodes. But for a read/write database, it falls over when you get to four or five nodes. It's not because it doesn't work, but due in large part to the fact that it's really hard to parallelize absolutely everything in a common database. Really smart database design and data placement helps, but you're probably still going to have some locks and contention arising from it. This same problem exists on databases placed on SMP systems too, the difference is that on a SMP system, everything happens much much faster using internal memory (vs. network speeds on RAC). With the use of so much flash memory, the Oracle/Sun box will do a better job, but for a truly transactional database (with reads and writes), it would still have problems scaling linearly.
RAC might make sense for some uses - read only apps or databases that don't need to scale much. But for databases that need to offer full read/write and also need to scale, SMP is a better option. It might even be cheaper when you take into account the effort needed to make a parallel database work for a particular need. And I don't consider TPC-C to be a valid proof point of OLTP scaling and thus not an appropriate proof point of how well or poorly something will work in the real world.
You only want to use RAC for mandatory active active. Customers never save money on a RAC implementation. You spend well over 50% more to have RAC then you lose so much performance that you are better off just using an SMP with failover to a test/dev box.
The financials do not support more than three nodes because of the poor scalability.
Note the link to a PDF on how to do it on Linux.
Java? IBM's been doing Java on multiple platforms for a long time. OS/2 (for the half dozen of us that ran it.) ran Java better than Windows. IBM's Java implementation runs on Z/OS, OS/400, AIX, Linux and Windows. Yeah, IBM does Java. Oh, yeah. Websphere is a Java EE application server.
So Larry, as usual, is full of it.
Well, yes and no. We use RAC for high-end enterprise solutions because we want a trusted and capable bit of software. In those solutions, we use large SMP systems and have fail-over DR, even though it's criminally expensive. We don't expect perfect linear scaling from hardware and software and the business criticallity of the task means there is money to pay for what we deem necessary to get the job done. So we do know RAC doesn't scale linearly, but we don't see that as a massive problem.
In fact, as an Oracle customer, I actually hope that all the recent focus by Larry on flogging the dead horse of Sun doesn't damage Oracle RAC development in the long run, and RAC gets even better. As with many companies that have made themselves self-dependent on a particular product, be it RAC, Microsoft Office or IBM mainframes, it's not that other options aren't there but that it would be painful and costly to break out of the habit. But if Larry does stuff RAC, and if he stuffs it up by crippling it if it's not on Slowaris, then we will call time and move to another software stack, simple as that. We always have at least one hardware vendor pre-tested as an option should the primary vendor start asking silly money or not meet the support requirements, and we always have software options tested so we can walk away from a bad deal. Be it Oracle, SAP, IBM or hp, or even Microsoft, we are careful to keep our options open.
/SP&L, but with fingers crossed that Larry isn't THAT stupid.....
Biting the hand that feeds IT © 1998–2020