One of the more senior salesmen gets up to say that the current situation reminds him of 1990, when Ellison sent all employees an e-mail describing the crisis and the steps that he was taking to resolve it. What was he doing to help Oracle through its present crisis? Ellison is a little shocked at the comparison and starts to talk about some of the things that he’s doing to lower costs, such as using the Internet to move customer support from high-price markets such as Britain and the United States to India. But, he says, this has nothing to do with the economy, it’s what Oracle would be doing anyway, “automating away jobs, saving head count, and improving service.” The whole point of the E-Business Suite is to do more with less: “That’s what we sell it for.” Then he starts to waffle about adding people in development and maybe in sales too but says that Oracle is a tough place to be if you’re a mediocre sales performer. Realizing he’s losing his audience, Ellison stops himself and says what he ought to have earlier: “This is nothing like 1990. We were on the verge of going out of business then. Our performance this Q3 may have been disappointing for us, but it would have been glorious success for almost anyone else.”
A couple of questions later Ellison is asked what Oracle’s greatest challenge is. His answer is interesting: “The biggest challenge was this year’s applications technology transition. It put huge stress on the entire organization. It was like the move from Oracle 6 to Oracle 7. It was Oracle 7 that saved Oracle. The E-Business Suite has been a difficult transition, but we’ve crossed the chasm. 11i wasn’t perfect when it came out, how could it have been? It’s five times more complex than the product it replaced. But we were right to be ambitious. There’s nothing else like it. First we have to persuade ourselves; only then can we convince the rest of the world.”
With that Ellison is done. He leaves the ballroom with the audience still standing and clapping. The effect is clearly calculated. While other Oracle senior executives are accessible and will stay overnight to get drunk and party, the charismatic leader maintains some distance between himself and his troops.
• • •
A couple of days later, it’s time for the official launch of Oracle 9i. After the troubled infancy of the E-Business Suite, Oracle could do with some good publicity, and Ellison is convinced that the advanced technology of 9i, especially Real Application Clusters, will blow the minds of the journalists and analysts who have been invited to Redwood Shores. The main theater in the Oracle conference center is decked out with huge red banners, boldly proclaiming the extraordinary qualities of the new database. A spotlight sweeps over the banners, rock music pulsates, and a giant video screen projects swirling images of speed and power. The audience has been carefully segregated: the press occupies tables to the left and near the front; the analysts are behind them; and to the right are the Oracle employees: some from marketing, but mainly the middle-aged, rather academic-looking guys from the database development group, who are on hand to do one-to-one briefings when the main show is over.
When Ellison sweeps in, he moves quickly into the pitch for 9i that went down well in Las Vegas. He’s trying to get across an idea that he fears cynical journalists and analysts will be naturally resistant to—that 9i is not just an incremental improvement over its predecessor but a breakthrough product with the potential both to transform the economics of corporate computing and to render the rival databases from IBM and Microsoft terminally obsolete. To Ellison, this is not just marketing bombast. He is convinced it’s true. He can hardly contain his excitement. Oracle 9i is the superweapon that will not only win the war but convince the enemy that further resistance is futile. That’s why Ellison calls the database team “the boys from Los Alamos” and why he talks of 9i as “the last database.”
Although 9i has, according to Ellison, at least four hundred “incredibly cool new features,” the one he wants even people who know nothing about databases to understand is RAC. Oracle’s top computer scientists, led by a prickly genius named Roger Bamford, have been working on the technology for more than a decade. Although clustering, in which several computers are linked together to work as one, has been around for some time, there has always been a trade-off between scalability and reliability. As corporate IT departments have tried to add computing power to their applications, they have had to spend months reconfiguring data if their applications were to run at all. Even then, the applications were limited to highly specialized activities such as data warehousing, in which groups of machines laboriously look for patterns in their stock of information. The packaged applications made by the likes of SAP, Oracle, and Siebel do not run on clusters because they are unable to cope with the speed at which data changes with applications of this kind.
The only exception to this rule is clusters of IBM’s ponderous and costly mainframe computers. Customers who needed both speed and scale to run their applications had no choice other than to buy very-high-end sixty-four-processor UNIX computers such as those made by Sun Microsystems, Hewlett-Packard, and IBM. However, not only do these complicated pieces of hardware typically cost upward of $2.5 million, but to get the reliability required for mission-critical applications or to support an e-business platform able to withstand the onslaught of millions of users, you have to buy twice as many machines as you really want—the one you actually need and one to act as a “hot standby” in case the other crashed. And once you fork out for the biggest, fastest, most powerful computer that money could buy, if you want even more performance, tough. You just have to wait for Sun or HP to get around to building something even bigger and more expensive.
Oracle’s RAC is designed to get customers out of this bind by allowing groups of machines to share the same short-term memory or “cache,” allowing them effectively to operate as one computer. With RAC, IT departments can start with just one low-cost computer, if that’s all they need, and then add more boxes without making any configuration changes or rewriting the code in any of their applications, as demand increases. Not only can they scale their operations remarkably cheaply—thirty-two Compaq four-processor boxes cost less than a fifth of a couple of giant Sun E10000s—but with every server added, they increase redundancy and therefore reliability. Oracle’s claim for RAC is that it delivers virtually limitless scalability, absolute fault tolerance, and dramatically lower hardware and operating costs. No wonder Ellison has convinced himself that it is the firm’s most important step forward in database technology since it came up with the world’s first commercial SQL relational database management system a quarter century ago.
Ellison begins the show with a slide outlining Oracle’s original design target for 9i: to improve performance by a factor of five while halving the cost. A further goal was to achieve ten times the reliability. There are, he says, just two ways to get better database performance: use either faster software or faster hardware. Making Oracle 9i the fastest database on a single computer wasn’t the problem. On the TPC-C standard benchmarks it could comfortably handle four times the number of transactions a minute as Microsoft’s SQL Server, while IBM was not prepared to publish any benchmarks for the UNIX/NT version of DB2. Interestingly, Ellison says, when IBM wanted to show how fast its most powerful UNIX computer was, the benchmark was run using Oracle rather than DB2. Ellison jeers, “IBM couldn’t even persuade its own hardware guys across the hall to use DB2, even though it was free!” But hitting the ten-times-improved cost/performance target simply wasn’t possible on a single computer. “Really fast computers are not only very expensive,” says Ellison, “but one high-end computer is also a single point of failure.” So the aim of getting ten times better reliability was also not possible. Why had nobody used clusters? Because the only database that would run real applications was DB2 on mainframes. Pretty much the only application that would run on clusters in a UNIX/NT environment was the benchmarking software used to measure TPC-C performance. So unless you happened to run your business on a benchmarking application, clustering wasn’t likely to be a whole lot of use to you.
The problem, Ellison explains, was one of architecture. The architecture of the DB2 clusters on mainframes is called “shared disk,” which means that any computer in the cluster can get at 100 percent of the data. But the clustering architecture used by “the other” DB2 and SQL Server is known as “shared nothing.” Apart from the benchmarking software, the problem with “shared nothing” is that the only applications it will run are customized “one-offs.” It won’t run the packaged apps that are used in the real world. And, Ellison says, it gets worse. First of all, shared-nothing clusters are very hard to manage. If you need to add computers, all your data has to be repartitioned, a job that might take months. Worst of all, as you add computers, the whole system becomes increasingly unstable. With four computers, each holding 25 percent of your data, the failure of just one will bring down the others. In other words, from a reliability point of view there is not just one single point of failure that might bring down one application but multiple single points of failure.1
Oracle’s achievement, according to Ellison, is to have taken the same shared-disk architecture that works within the tightly controlled, hermetically sealed environment of an IBM mainframe and make it work using clusters of the cheap computing boxes churned out by Compaq or Dell in their millions. It is, he says, true fault tolerance with commodity hardware—one of the holy grails of computing. The result, says Ellison, is not just ten times greater reliability than before but one thousand times, with no need for redundant “hot-standby” computers and no need for expensive twenty-four-hour-a-day human monitoring of the data center. If one computer, or “node,” goes down, it doesn’t matter. The system may slow down a little, but otherwise it carries on as normal.
What comes next is that staple of software presentations: the live demo. Onto the stage comes Mark Jarvis. His job is to run the demo while Ellison plays the role, rather unconvincingly, of the guy who asks the dumb questions. The aim of the demo is to show what happens to two clustered four-node computer systems when one node is brought down. One, represented by a thick blue bar that fluctuates in size according to the number of transactions being processed, is running DB2 with the “shared-nothing” partitioning architecture, while the other, in red, is on Oracle 9i with its “shared-disk” approach. Jarvis claims that the demo is live and hooked up via the Internet to an Oracle data center. At first, both systems chug along at pretty much the same rate. Then Jarvis takes out one of the nodes of the Oracle system. The speed of transaction processing falls by about 20 percent, the red bar reducing slightly in size, but otherwise the system remains stable. He then applies the same treatment to the IBM cluster, which predictably, but nonetheless quite dramatically, can’t take it. Within a minute, because only part of the data is now available to the application, thus rendering both the offline and the online data worthless, the blue bar collapses, indicating that the entire cluster has failed. The press and analysts are trained not to react to this kind of thing, but it’s impressive. They know that the software business has an inglorious history of rigging demonstrations when products are late or can’t do what they’re meant to.
After the demo, Ellison turns to the issue of how Oracle 9i will be priced. Over the last year, Oracle has been pricing its database licenses according to a formula known as “power units,” which measure the overall power of a customer’s computer system and price it accordingly. It’s been unpopular because some customers, upgrading their hardware, have resented paying Oracle more money for the same software and because both DB2 and SQL Server licenses are sold according to the number of processors the database will be running on. By using a different metric from its rivals, Oracle has left itself vulnerable to accusations that it is overcharging. It’s a stick that several of the market research analysts, principally Gartner’s Betsy Burton, have been using to beat Oracle with while claiming, somewhat against the evidence of their own surveys, that it’s been costing Oracle market share. Ellison has decided to return to the processor-licensing model used by IBM and Microsoft. He’s incensed by the suggestion that DB2 works out cheaper than Oracle.
Under the new formula, the price of the enterprise edition of 9i is to be $40,000 per processor against the $20,000 charged by IBM. But whereas Oracle includes “essential” features such as queuing, work flow, and files in the basic price, DB2 customers must pay extra for them. Quoting IBM’s own price list, Ellison says that DB2 turns out to cost 65 percent more than Oracle 9i before you even start to add in the advantages of running on cheaper hardware and lower running costs. And if you want data mining, Ellison claims, IBM will charge you $60,000 per processor compared with Oracle’s $20,000. Although this seems like another well-aimed shot at IBM, it has the unfortunate consequence of turning the main story of the day away from 9i’s fancy technology and into one about pricing policy, one with a pretty negative spin. The headlines next day are predictable: “Oracle Backs Down on Pricing” and “Oracle Cuts Prices to Stem Market Share Slide.” It’s a mystery how a company that spends as much time and money on marketing could have made such an elementary mistake.2
But it gets worse. When Ellison finishes speaking, a local newspaper reporter named Tom McEwen wants a quote from Ellison—or “Captain Midnight,” as he calls him—about a court ruling a few days earlier on whether he could fly his Gulfstream into San Jose Airport late at night. Ellison had claimed that the airport authority was unfairly discriminating against him on account of the weight of his plane rather than its noisiness, and the ruling, by federal judge Jeremy Fogel, was a big win. Still, he’s shocked to be asked about it now. “Oh my God,” he groans, raising his hand to his forehead in a gesture of exasperation.3
Most of the questions that follow are about pricing. Is this a disguised price cut because of the pressure from IBM, and if so, what impact will it have on revenues? The answers are “no” and “none”—it’s just a question of using a comparable metric, and anyway, Oracle is always making its software cheaper and selling more of it as a consequence. An analyst says that in interviews he’s conducted with DBAs (database administrators) about half of them are saying that Microsoft and DB2 are “good enough” and what’s the point of paying extra for Oracle? Ellison responds almost wearily, “With Oracle, you use less hardware and less labor. The economics of the database industry actually have very little to do with the price of the software.”
Only a few questions are about the radical clustering technology, but a couple of them raise interesting issues. Ellison has been keen to get endorsements from rival application vendors for 9i and has succeeded in getting a glowing reference from even SAP. So has Oracle been working with application partners? Ellison seizes on the opportunity to amplify a key point: “Our clusters don’t require us to work with them. They don’t have to change a single line of code. It just works—it’s transparent to the app. The app doesn’t even know it’s running on multiple machines.” One perceptive questioner wants to know what RAC means for Oracle’s close relationship with Sun in terms of the latter’s do-or-die battle with Intel.
The answer is up there on the stage in the form of a rack of Compaq four-processor boxes and in some of the slides that Ellison has shown indicating the price difference between getting sixty-four processors with sixteen Compaq boxes and a sixty-four-processor Sun E10000. Ellison equivocates, “We have a good relationship with both Sun and Intel. But we’ve always hesitated to recommend Intel for mission-critical applications because their server hardware is relatively small and the Microsoft operating system is so fragile. But with RAC none of that matters anymore. You get the performance you need from clustering lots of small servers together, and if a few should fail, no problem, the system keeps running. So RAC makes low-cost Intel servers viable in the data center.4 But Sun has very competitively priced small servers, and they have a great operating system. It’s really about small machines versus big, high-end machines, not Sun versus Intel.” The truth is that Sun is pretty competitive at the low end because it has to be—but it’s
not where it makes its money. If big, fast computers can be replaced with groups of little ones, it’s seriously bad news for Oracle’s old hardware partner, and Ellison knows it.
What Ellison isn’t letting on is that he has decided to throw Oracle’s weight behind Intel’s sixty-four-bit McKinley processor when (and if) it finally debuts next year. Ellison isn’t about to say anything disparaging about Sun in public, but what he’s planning, not to mention what Oracle has already done with RAC, could turn out to be far more damaging to his feisty Valley neighbor than anything so far achieved by their mutual enemy Microsoft.
Softwar Page 35
