oracle
转自Mark Rittman的BLOG
http://www.rittman.net/archives/001130.html
Is Oracle A Legacy Technology?
One of the nice things about working with the Oracle RDBMS, compared to say working with technologies such as AS/400, COBOL or mainframes is that it's generally perceived as a "hot" technology. Salary surveys show Oracle skills as being one of the most in-demand skill sets, the Oracle database is way ahead of the competition in terms of features and use of new technology, and most of the world's top companies use Oracle as their database of choice. But what if in fact we've gone past the peak of Oracle's ascendancy, and it's now a legacy product, with all work in future being mainly about maintaining systems in place, and migrating them to newer, more fashionable systems? A couple of excellent recent articles by Mogens Nørgaard raised this as a possibility, and certainly give you a few things to think over when you consider the Oracle database technology stack.
The first article was at the end of Mogens' chapter in Oracle Insights : Tales Of The Oaktable, where he looks at the key factor that makes Oracle particularly suited to effective tuning - the fact that the database kernel is heavily instrumented (the famous "wait interface"), and because of this, you can obtain precise details about exactly what is slowing down your application. Other databases, such as DB2 and Microsoft SQL Server, don't have this instrumentation (or at least it's not publicly accessible) and therefore it's much more "hit and miss" with those platforms.
A point that Mogens makes mid-way through the article though is that, whilst it's all well and good instrumenting the database, in most cases an application consists of a SAN, operating system, an application server, application code and so on, and if you've only got feedback on how the database is performing, you've only got part of the story. Mogens makes the good point that, whilst Microsoft haven't exposed SQL Server's internals in the same way that Oracle have, in fact they've got a historical chance to instrument the entire application platform, as they own the technology behind Windows Server, IIS, .NET and so on, a point made again by Niall Litchfield in a thread on comp.databases.oracle.server.
Where this goes on to though is that, whilst it's fantastic what Oracle's done with instrumenting the database kernel, what Mogens is actually finding in real life is that, like disk storage and operating systems before it, the database itself is now becoming a commodity, with no-one these days getting fired for buying Microsoft SQL Server, and many organisations looking to open source databases such as mySQL to handle their day-to-day database needs. Whilst this is moving databases as a whole into the legacy category, it particularly hurts Oracle badly as firstly, the Oracle RBDMS is expensive and still to this day requires a level of administrative skill well above SQL Server and mySQL, and secondly, for Oracle, database revenues are still the majority of their total license revenues. According to the article,
"Oracle and DB2 are now legacy databases: very few truly new sales compared to license renewals and add-on sales to existing customers, very few young people coming out of schools wanting badly to learn about them. SQL Server is the safe choice that won't get you fired, and the open source databases such as mySQL will prevail when they can deliver the neccessary (rather few, basic) functionalities that the developers of tomorrow will require (such as handling transactions correctly, have good backup methods, and so on)."
The irony as far as Mogens is concerned, is that "whenever a system or technology reaches a level of perfection (in other words, science is used as a rule) it will be replaced by something more chaotic that looks (and perhaps even is) cheaper", something that happened to mainframes before and, just at the point where it reaches the level of "technical perfection", could possibly be the fate of the Oracle RDBMS itself.
Mogens made the same points again in his column in the Autumn 2004 edition of Oracle Scene, and, thinking about the earlier point about databases in general being made into a commodity, says that this will have the following effect on database professionals:
"So the DBAs are slowly being replaced, outsourced, diverted to other tasks, or being asked to focus on other things, too. That means three things for our database world:
1. The databases will usually run, because nobody is fiddling with parameters and other stuff.
2. No new features will be tested and implemented (after all, 7.3 is still plenty of database technology for most uses).
3. When things finally go wrong, a lot of other complications, due to the lack of daily nursing, fiddling, and caring, will be discovered, making the troubleshooting and restore/recovery process even harder in an even more critical situation.
It means something else, too: For companies specialising in this sort of scenario, with a bunch of techies still around who can stay current with the latest without forgetting the (basics of the) past, there will be lots of work for the next 10 years."
whilst for Oracle in particular, the effects are likely to involve a change in business plan
"...I think it’s fairly safe to say this today:
Oracle and DB2 are legacy databases, you don’t get fired currently from choosing SQL Server, and the open source databases will become the default as soon as they’re good enough, which will happen real soon now, since more and more work takes place outside the database, turning the database into a data dump. The open source databases will do to the database market what Linux is currently busy doing in the O/S market. Oracle gets most of its license profits from the database. If they don’t find additional sources of income (and profit), such as PeopleSoft, they will fail because of the constant attack on their profit sanctuaries (the database licences and Support). Oracle will be bought by IBM or HP if they don’t manage to grow to a comparable size."
So what does this mean for us then, whose careers (presumably) are based around our knowledge of Oracle? Well I think it's safe to say that, whilst I'm in total agreement with Mogens on his assessment of the market (which unfortunately always picks cheapest and simplest above complexity and costly) I'm sure everyone would agree that the Oracle RDBMS isn't going anywhere in the near future. If you spoke to Tom Kyte (or indeed Mogens) you could point to any number of new features that make Oracle more powerful, easier to administer and less costly to run, and no doubt when databases such as SQL Server and mySQL get the features that Oracle currently has, they'll be just as complex to administer.
However, time and time again now I come across situations where the database is considered just part of the underlying platform and all the real activity takes place on the mid-tier and in the application, and if you've going to do that, you might as well use mySQL or Access. Also (and this is particularly pronounced in the BI and OLAP world, and will be more so when Yukon comes out) rival databases are catching up with Oracle in terms of features, and in most cases have a better "out of the box" experience that doesn't scare off curious first-time users of the database.
I think like in any walk of life, it pays to hedge your bets, and if you speak to most advocates of Oracle technology (including many of the Oaktable members) they also have a good understanding of rival RDBMSs, and in some cases recommend them in preference to Oracle. Also, it depends where you are in your career - I'm 36 now and working with Oracle more or less for all of my IT career, and in all probability will continue to work with databases for the rest of my time in the industry. If, however, I was just starting out, I'd probably focus more on Java or .NET application coding, look more at "mid-tier" issues and spend less time on the database, storage and the operating system. Still, having said that, I still come across AS/400-based applications, and consultants who still make a packet looking after these supposed "legacy" systems, and don't have to spend all their time recertifying and getting their heads around concepts such as "grid computing" and "service-orientated architectures", so it could just pay to sit it out and let everyone else fight it out over the next new great thing.