Oracle
Analysis of software titan Oracle and its efforts in database management, analytics, and middleware. Related subjects include:
- Oracle TimesTen
- (in The Monash Report)Operational and strategic issues for Oracle
- (in Software Memories) Historical notes on Oracle
- Most of what’s written about in this blog
Two kinds of DBMS extensibility
Microsoft took slight exception to my claim that they lack fully general DBMS extensibility. The claim is actually correct, but perhaps it could lead to confusion. And anyhow there’s a distinction here worth drawing, namely:
There are two different kinds of DBMS extensibility.
The first one, which Microsoft has introduced in SQL Server 2005 (but which other vendors have had for many years) is UDTs (User-Defined Types), sometimes in other systems called user-defined functions. These are in essence datatypes that are calculated functions of existing datatypes. You could use a UDT, for example, to make the NULLs in SQL go away, if you hate them. Or you can calculate bond interest according to the industry-standard “360 day year.” Columns of these datatypes can be treated just like other columns — one can use them in joins, one can index on them, the optimizer can be aware of them, etc.
The second one, commonly known by the horrible name of abstract datatypes (ADTs), is found mainly in Oracle, DB2, and previously the Informix/Illustra products. Also, if my memory is accurate, Ingres has a very partial capability along those lines, and PostgresSQL is said to be implementing them too. ADTs offer a way to add totally new datatypes into a relational system, with their own data access methods (e.g., index structures). That’s how a DBMS can incorporate a full-text index, or a geospatial datatype. It can also be a way to more efficiently implement something that would also work as a UDT.
In theory, Oracle et al. expose the capability to users to create ADTs. In practice, you need to be a professional DBMS developer to write them, and they done either by the DBMS vendors themselves, or by specialist DBMS companies. E.g., much geospatial data today is stored in ESRI add-ons to Oracle; ESRI of course offered a speciality geospatial DBMS before ADTs were on the market.
Basically, implementing a general ADT capability is a form of modularity that lets new datatypes be added more easily than if you don’t have it. But it’s not a total requirement for new datatypes. E.g., I was wrong about Microsoft’s native XML implementation; XML is actually managed in the relational system. (More on that in a subsequent post.)
Categories: Actian and Ingres, Data types, IBM and DB2, Microsoft and SQL*Server, Open source, Oracle, Theory and architecture | 3 Comments |
Is Oracle losing its edge?
Over in the Monash Report, I posed the question: Is Oracle losing its edge in DBMS? Here are some of the data points that make me suspect it has. A number of these points also apply to the other large mainstream DBMS vendors; a number, however, do not.
- Oracle lags behind both IBM and Microsoft on native XML. I can’t recall Oracle trailing both those vendors at once on anything as major before.
- I’ve come to believe that memory-centric technology is a really powerful improvement to DBMS. Oracle’s done nothing effective inhouse in this area. Buying TimesTen was a good move, however.
- I’m growing less inclined to excuse the ongoing complexity of Oracle database administration. From the classic Progress DBMS to Solid’s truly zero-DBA system (embed it in telecom equipment without a keyboard or monitor, and it runs for years) to ANTs’ new challenge, there are a whole lot of fairly full-featured RDBMS with a whole lot less knobs and dials. Do they match Oracle’s full functionality? No. But could they handle a lot of the apps which run on Oracle today? In some cases, quite possibly. So why hasn’t Oracle itself come up with a plug-compatible Oracle Lite that truly is lite?
- High-end data warehouse scaling continues to be a problem for Oracle. Yes, the effective upper bound on Oracle database size keeps increasing. But so does the size of the largest data warehouses, and the latter number is definitely greater than the former.
- Microsoft Analysis Services is quite cool. Why hasn’t Oracle done the same thing?
- There are many seemingly major feature advantages that Oracle has failed to exploit. Robust text processing in the DBMS and Virtual Private Database (a cool security feature) are two of the biggest that come to mind. They’ve sold well to customers who were predisposed to want them, but Oracle hasn’t had the stomach to broaden the market for them. Yes, that’s more of a marketing problem than a technical one, but after a decade of squandering your technical advantages, you can find that your people lose the enthusiasm to create more of them. What else has Oracle done in years that is as functionally innovative? Nothing comes to mind.
- The whole apps-vendor-consolidation strategy is often presented along with a huge white flag regarding DBMS market share growth.
- Oracle has never, ever solved its applications product problems. Ditto its BI development problems. Both these fiascos are plausibility arguments for the thesis that the company can NOT reverse bad product philosophy choices, no matter how much market evidence slaps them in the face, and no matter how adaptable the company is in other ways.
- Oracle’s analyst relations have gotten very defensive and insular. To some extent, that happens at most big companies. But I cannot recall a previous time when IBM’s and Microsoft’s DBMS operations were both more accessible than Oracle’s, and I’ve been a DBMS analyst since the industry’s very early days. Often when a company acts this bizarrely, it does so because it has a great deal to hide.
That’s a lot of evidence, even without mentioning threats from the open sourcers and the data warehouse appliance guys. So why am I not wholly convinced yet? Well, reasons include a variety of scalability features, extensibility features that are rivaled only by IBM’s, market share dominance on Linux, and Andy Mendelsohn. That’s a pretty compelling list too. Still, the Oracle colossus is teetering a little bit, and it’s not beyond imagination that some future earthquake could bring it crashing down.
Categories: Oracle, Oracle TimesTen | 1 Comment |
Native XML storage, Part 1 (technology)
IBM’s “Viper” version of DB2 is in open beta test, whatever that means, and Microsoft’s SQL Server 2005, nee Yukon, is in general release. Both have native XML capabilities surpassing Oracle’s – which is interesting in its own right, because it’s rare for either of those vendors to pull ahead of Oracle in an OLTP feature, and almost unprecedented for both to do so at once.
So let’s talk about native XML support, what it is, and who might or should care about it. (Well, the apps part is actually in a separate Part 2 post.) Most of this is based on research that’s several months old, but except for a scarcity of actual user interviews, that shouldn’t matter much.
There are two main non-native ways to put XML into a SQL database such as Oracle – shredding and LOBs (BLOBs or CLOBs – i.e., Binary or Character Large OBjects). Both can perform poorly, for different reasons. Shredding takes XML documents and distributes them among a bunch of tables. So one update in XML can become many updates when shredded, and one lookup in XML can become a complex join from shredded storage. LOB storage obviates those problems, but creates another – even when you’re only looking for part of a document, you have to retrieve and handle the whole thing, and the same goes for updates.
So native storage can be a good thing when you can afford neither the performance hit of shredding, nor of LOB storage, nor of any available hybrid. It also could be good if getting good performance from non-native storage, while possible, would create undue burdens on application development, or if there’s some other reason one or both of the shredding and LOB approaches isn’t viable.
One nice feature is that native-XML storage has almost no downside, at least if you get it from the high-end DBMS vendors. IBM, Oracle, and Microsoft have all worked out ways to have integrated query parsing and query optimization, while letting storage be more or less separate. More precisely, Oracle actually still sticks everything into one data store (hence the lack of native XML support), but allows near-infinite flexibility in how it is accessed. Microsoft has already had separate servers for tabular data, text, and MOLAP, although like Sybase, it doesn’t have general datatype extensibility that it can expose to customers, or exploit itself to provide a great variety of datatypes. IBM has had Oracle-like extensibility all along, although it hasn’t been quite as aggressive at exploiting it; now it’s introduced a separate-server option for XML. Both Microsoft and IBM claim that their administrative tools are slick enough that the DBA has little extra work from their offerings than would be present in a true single-server solution.
So how does the storage actually work? The basic idea is exactly what you’d think. Data is stored in name-value pairs, with pointers connecting parents to children. The secret sauce (and here I have less detail than I’d like) is the extra information that’s stored, either at the nodes directly, or in an overarching index. Obviously, there’s a tradeoff between update and retrieval speed. And equally obviously, I need to learn more of the particulars.
And on that somewhat lame note, let me point you at Part 2 of this post, which discusses whether and how this stuff will actually be used. (Preview: It will, big time – I think.)
Categories: IBM and DB2, Microsoft and SQL*Server, Oracle, Structured documents | 9 Comments |
The end of the single-server DBMS vendor
For all practical purposes, there are no DBMS vendors left advocating single-server strategies. Oracle was the last one, but it just acquired in-memory data management vendor TimesTen, which will be used as a cache in front of high-performance Oracle databases. (It will also continue to be sold for stand-alone uses, especially in the financial trading and defense/intelligence markets.)
IBM’s Viper is a server-and-a-half story, with lots of integration over a dual-server (one relational, one native XML) base. IBM also is moving aggressively in data integration/federation, with Ascential and many other acquisitions. It also sells a broad range of database products itself, including two DB2s, several Informix products, and so on.
Microsoft also has a multi-server strategy. In its case, relational, text, and MOLAP storage are more separate than in Oracle’s or even IBM’s products; again, there’s a thick layer of technology on top integrating them. An eventual move to native XML storage will, one must imagine, be handled in the same way.
Smaller vendors Sybase and Progress also offer multiple DBMS each.
Teradata is a pretty big player with only one DBMS — but it’s specialized for data warehousing. Teradata is the first to tell you you should use something else for your classical transaction processing.
The Grand Unified Integrated Database theory is, so far as I can tell, quite dead. Some people just refuse to admit that fact.
Categories: Database diversity, IBM and DB2, In-memory DBMS, Microsoft and SQL*Server, MOLAP, Oracle, Progress, Apama, and DataDirect, Sybase, Teradata, Theory and architecture | 3 Comments |
Open source DBMS — easier to install?
Lewis Cunningham compared the installation ease of Oracle, PostGRES and MySQL. Despite expecting Oracle to win (uh, why?), he wound up ranking PostGRES first, with Oracle and MySQL tied — and that’s after marking MySQL down (indirectly albeit not directly) for lacking documentation in a beta release.
This just goes to show: The inherent complexity of the high-end products can outweigh users’ greater familiarity with them.
Besides, ever more people — especially cheap recent grads — are familiar with MySQL.
EDIT: Cunningham has a little more to say here.
Technorati Tags: Database, DBMS, DBMS2, MySQL, Oracle, PostGRES
Categories: MySQL, Open source, Oracle | 1 Comment |
Oracle vs. open source DBMS
Mark Rittman had a great thread last November questioning the need for Oracle’s advanced features at most installations.
Pretty similar to what I’ve been saying, but more from a developers’ or DBA’s standpoint than a CIO’s.
Technorati Tags: Database, DBMS, DBMS2, Oracle, MySQL
Categories: Microsoft and SQL*Server, MySQL, Open source, Oracle | Comments Off on Oracle vs. open source DBMS |
Down with database consolidation!
As with all changes in information technology, the move to DBMS2 will largely be one of evolution. But it does have a couple of revolutionary aspects.
Short-term, the biggest change is a renunciation of database and DBMS vendor consolidation. Consolidation never has worked, it never will work, and as data integration technologies keep improving it’s not that important anyway.
IBM and Oracle offer really great, brilliantly complex data warehousing technology. But if you want the most bang for the buck, forget about them, and go instead with a specialty vendor. Depending on the specifics of your situation, Teradata, Netezza, Datallego, WhiteCross, or SAP may offer the best choice, and that list could be even longer.
Similarly, for generic OLTP data management, cheap and/or open source options are getting ever more attractive. Microsoft is a serious contender for applications that previously only Oracle and IBM could handle, while MySQL and maybe Ingres are moving up the food chain right behind.
In many cases, these alternative technologies are lower-cost across the board: Lower purchase price, lower ongoing maintenance fees, and lower administrative costs.
So what, again, is the case for consolidation?
Categories: Actian and Ingres, Analytic technologies, Data warehouse appliances, Database diversity, IBM and DB2, Kognitio, Memory-centric data management, Microsoft and SQL*Server, MOLAP, MySQL, Netezza, Open source, Oracle, SAP AG, Theory and architecture | Comments Off on Down with database consolidation! |