REVEALED: Hungry termites nibbling at Oracle's foundation Oracle's business faces growing competition from niche technologies, but the database goliath's size means it may be blind to the threat posed by a marauding hoard of upstarts that are going after its current and future customers. Although Oracle's customer roster includes many of largest companies in every industry you care …
Which kind of stuffs you unless you are already running on Oracles anointed hardware.
I've always thought EDL and migration tools are one of those ongoing niche areas.
Sure what you're migrating from and to changes, but somehow sooner or later nearly everyone has to do it.
Microsoft SQL server is taking far more business from Oracle than any Open source / niche players...
If you care in the slightest about security then you don't want to be using Oracle. Roughly 1000 known vulnerabilities in Oracle 10G versus 4 in SQL Server 2008....
But ... SQLServer is fucking awful for anything remotely resembling a large database. The optimizer is seriously challenged, randomly losing the plot for no apparent reason and spinning for minutes on end to solve trivial optimizations. It cannot correctly optimize a vast swathe of queries where partitioning is involved, and on it goes. As of SQL2008R2, serious bugs (wrong or no answer) introduced in SQL2005 still exist, and MS shows no inclination to fix them.
MS does not really understand large enterprise requirements, they are a "tick box" supplier of an OK small/medium database engine. Lots of useless trivial functionality half of which doesn't work correctly, while important pieces needed for large database work remain missing.
Personally, I am not Oracle's biggest fan, but SQLServer is IMHO not the answer for large complex database applications - YMMV.
That being said, the pyramid is bigger on the bottom, and SQLServer gets in with that tier because the customers there simply do not know (or at this stage need) better. Same goes for MySQL which is another trivial DBMS.
"SQLServer is fucking awful"
I don't want to be forced to defend mssql but the majority of problems I've had with it have been from badly written queries with stats/indexes missing, and a lack of knowledge of what not to do (which is, keep it simple).
I don't know what you mean by large but I'm currently running a 30 gig db and I've seen it running a 70 gig db, but just fine (well. fine-ish). I realised this is not enterprise size but nor is it trivial.
The optimiser will lose the plot only for a good reason (well, usually...) not at random, and I there are only 2 cases I know of where it will spin for minutes, which is a very obscure bug, and a sql statement with thousands of and/or clauses (which is easy to deal with btw).
I'd very much like to see evidence for your claim that "As of SQL2008R2, serious bugs (wrong or no answer) introduced in SQL2005 still exist...". In fact, I don't believe it.
MSSQL is crap for several reasons but I don't buy any of yours. Evidence, please (exclude bugs on partitioned tables as I have no experience with that).
Firstly, measuring databases in GB (or TB or Exabytes) doesn't really say anything about the complexity of the data model, the cardinality of the tables or the physical complexity - items which are of critical importance when discussing optimization. SQLServer optimizer is severely challenged in a whole host of cases when the table sizes get large. Beyond millions in fact, so dealing with tables with 10's of billions of rows and with a physical layout includes 000's of storage areas is somewhat challenging.
"The optimiser will lose the plot only for a good reason (well, usually...) not at random, and I there are only 2 cases I know of where it will spin for minutes, which is a very obscure bug, and a sql statement with thousands of and/or clauses (which is easy to deal with btw)."
The second is not my case (and I have no idea to which bug you refer, but I am all ears if you think you know what it is because it pisses our customers off bigtime). There are no good reasons for the optimizer to lose the plot, just excuses. My problematic query is relatively trivial with exact indexing support for the predicate. The physical structure is non-trivial, as are the cardinalities involved. It works perfectly mostly, with essentially subsecond optimization time and response time. Other times, 5 CPU minutes are common before execution.
It's not logged to MS partly because it is very hard to find a predictable example, and so far I can only produce it on a production db. I am not going to start constructing 10 billion row data sets with thousands of storage areas for a demonstration. Last time I logged a support the experience was not at all good, despite the point of departure being a known bug. YMMV
"I'd very much like to see evidence for your claim that "As of SQL2008R2, serious bugs (wrong or no answer) introduced in SQL2005 still exist...". In fact, I don't believe it."
Believe what you want. The optimizer has issues passing columns between it's internal loops, particularly when the elements forming the predicate are explicitly cast from one data type to another and involved in projections. There are other cases where the result set is wrong where splitting the query into two with explicit #tmp tables solves the issue.
I get paid to deliver value to my customers, not solve MS's software engineering issues, so I can never be bothered to log these things - when MS pays my fee, I will think about it.
You are describing cases of queries on 10 billion rows on SQL server. Well that's proving the worthiness of SQL Server, how many databases easily handle joins with billions of rows of data. If you are saying that the same query sometimes takes 10x more than it normally takes that sounds odd, but it can be other queries running on the server? Try forcing the good query plan, easy to do.
One of the typical problems you describe is that you have queries which are comparing data between different data types. This is a known performance handicap on any database to my knowledge, data have to be the same type to make the query optimal and can't see why they shouldn't be of the same type, unless the database design is poor. I am not saying that I have answers to your problems or sql server is 100% perfect, maybe I have answers if I could see your queries, but I definitely recommend posting your questions to the Microsoft forums, MVP surf the forums and the support there is really good.
No, I am not saying that at all.
You are correct though, about the overhead of casting (and collations for that matter) while resolving queries. I have fixed a lot of that sort of crap over the years.
In this case it simply gets it wrong and crashes.
I'll give a fuller response tomorrow eve. I have to be up early.
> The second is not my case (and I have no idea to which bug you refer, but I am all ears if you think you know what it is because it pisses our customers off bigtime)
I'm happy to take a look at it if you're in london area, or discuss offline after signing an nda.
However, I can't see why you presume it's the optimiser rather than something else e.g. an inappropriate query plan, which frankly is what it sounds far more like.
Most importantly, run a trace and capture the output. If the aberration happens at least you'll have the beginnings of a diagnosis.
If it is a stale query plan then experiment with dbcc freeproccache and With Recompile, and there are a few other things. It's a nuisance but solvable.
As a last resort, turn off iqp (intra query parallelisation) as this is not reliable. But a last resort only. First resort is get a trace of the troublemaker in action.
> Believe what you want
Am happy to believe you. **IF** you provide the evidence. Cough up.
I am not in London or anywhere near it.
The problem is generating the query plan, not executing it. I am almost certain I wrote that explicitly (without ref. to my original post).
"If it is a stale query plan then experiment with dbcc freeproccache and With Recompile, and there are a few other things. It's a nuisance but solvable."
Oh brilliant, at a sustained 2000 tps you want me to flush the proccache to see if it helps solve 1 specific issue. Righteo! I try and avoid that sort of stuff on live databases.
And in any case, finding the exact predicate combination that exhibits the problem is complete guesswork, and once I allow SQLServer to figure out a plan, it is smart enough to use it again, so the example is then no longer an example.
I have more important things to do at the moment than chase this particular issue.
> Oh brilliant, at a sustained 2000 tps you want me to flush the proccache to see if it helps solve 1 specific issue. Righteo! I try and avoid that sort of stuff on live databases.
yes. I'd be stupid to suggest doing that on a live system, and you'd be stupid to assume I meant it that way. That's why you have a test system, isn't it.
> And in any case, finding the exact predicate combination that exhibits the problem is complete guesswork, and once I allow SQLServer to figure out a plan, it is smart enough to use it again, so the example is then no longer an example.
So run a goddamn trace and catch it in the act. You can run one against a live server, yes? And then you can clear the cache and rerun the query to reveal the same absurd plan generation time, yes? And having made it repeatable you can start to deal with it, yes?
"yes. I'd be stupid to suggest doing that on a live system, and you'd be stupid to assume I meant it that way. That's why you have a test system, isn't it."
Why? People on forums make far far stupider suggestions all the time - and they are serious, oblivious to their own foolishness. And they all seem to have lots of letters in the signatures indicating they are supposed to know something. An embarrassingly large % of all posters on SQL Server forums I have visited are in this category.
That being said, this is El Reg where the intellectual hoi poloi hang out :D
Like I said, I have bigger fish to fry at the moment. This pisses customers off occasionally and they complain, but it's not like the world will end because of it. I will look at it again sometime when it starts to piss me off enough and waste enough of my time.
Obligatory XKCD link. http://xkcd.com/1205/
Boring example to close.
This is not my previous example, just a random one from today.
update T1
set c1 = null
from T1 x,
#TMP y
where x.id=y.id
and x.ptnvalue = y.ptnvalue
-- T1 is partitioned. PKey is (id,ptnvalue)
-- #TMP has pkey (id,ptnvalue)
-- T1 has a cardinality many orders of magnitude greater than #TMP
-- id is a bigint identifier
-- ptnvalue is an int
The optimization returned is exactly as you would predict, clustered index scan on #TMP and clustered index seek on T1 - nested loop inner join blah blah blah doing update stuff.
How hard do you think this optimization should be, I mean this as an abstract question. This is a tediously trivial update statement.
It might seem the complete reliance on statistics that are permanently out of date renders the optimizer incapable of producing a result in any reasonable time frame, but I merely speculate.
It took 13 minutes to return a plan <ctrl-l>.
It took 17 seconds to execute - about what I expected given the cardinality of #TMP
> How hard do you think this optimization should be, I mean this as an abstract question
Probably harder than you think, depending on indexes present, the kinds of indexes, the distribution of data within the table/index, and more, but still, it's fairly straighforward.
Where I would ask questions is your comment about T1 being partitioned, and your prior comment about "thousands of storage areas". If by this you mean thousands of partitions - if this is so in this case, hard to believe, but you implied it - then I'd be very suspicious of that. How many paritions is T1, or do you mean something else?
It shouldn't matter how many partitions there are. In this specific case we are under a thousand for the data and the same for each index, of which there are several. Though none of the indices other than the PKey are involved in SQL example, so that should be completely irrelevant. Each partition contains exactly 1 value of ptnvalue and the id is obviously an ascending bigint identity. The distribution of the key data therefore is as trivial as it can possibly be?
There is no need to be suspicious of anything I might have implemented. There are very sound technical reasons for the physical structure.
@AC 20:27
"Firstly, measuring databases in GB (or TB or Exabytes) doesn't really say anything about the complexity of the data model"
Agreed. In the case of the 70gig db there were some very complex queries, up to 25-way joins, produced in part from an expression language to SQL compiler. Trust me, it was heavy, although MSSQL 2000 handled it amazingly well, enough to be online usable, at least when I'd finished with it. The smaller one I currently work on is simpler in construction but runs some seriously large and complex queries which can be slow enough that they have to be done offline. Most of my job is optimising these. Very hefty too, although in a different way.
> with a physical layout includes 000's of storage areas is somewhat challenging.
-and-
> with thousands of storage areas
Okay, you said it. I'll refer to these in a following post.
"Last time I logged a support the experience was not at all good, despite the point of departure being a known bug. YMMV"
Oh FFS, if it's known give us a pointer to it. Stop making claims, give proof.
"I get paid to deliver value to my customers, not solve MS's software engineering issues, so I can never be bothered to log these things - when MS pays my fee, I will think about it."
Strangely enough, I'm with you here. Bug reporting is mainly a matter of goodwill, and MS burnt mine out a long while ago.
""Last time I logged a support the experience was not at all good, despite the point of departure being a known bug. YMMV"
Oh FFS, if it's known give us a pointer to it. Stop making claims, give proof."
This is a reference to another issue - was my grammar unclear? Very specifically a database that started life as an SQL2000 databse loses the file id pointers when files are added/removed over time and files become inaccessible from the DDL, but are still active. "Known bug, will not fix, call CSS for help." Getting a fix for my case was torturous and eventually involved sending a database to MS on a USB disk for a CSS (?) guy to build a fixit script.
My instance of the issue got fixed eventually, but the number of levels of challenged individuals I had to deal with before I reached someone who could spell or even wanted to address the issue was depressing.
In any case, the last client I had who paid me to log bug reports had an interest, as we were a paid beta site for the supplier, but that was in 1988. No one has offered to pay me to help the "common good" since then.
You totally lose your credibility when you mention Sybase!! Sybase is the slowest database I have ever used, doesn't understand query optimisation and I had extreme performance improvements with it, including the latest version. When I moved a complicated Sybase database to sql server I had x5 more performance and typically x2 on same hardware spec. More Sybase databases to follow.
Never used DB2 so can't say, never come across it and have worked with a dozen big companies. Oracle is is ok but I have seen very weird performance issues which are always blamed on configuration by the experts. How many months do you need to configure oracle properly? MySQL my only experience wasn't very productive, can't be better than oracle though, and not sure if it handles transactions properly. And if I take unsuccessful projects I am aware of, all used oracle, already complaining about performance with few million rows.
SQL Server the most stable predictable and performance database I have used (I am a DBA by profession). 2 billion rows tables joining with 1billion rows tables, 60 million daily updates on databases all done within the hours and never had anything I couldn't explain. Please if you haven't used a database properly or you are not seasoned on database performance don't make strong statements.
All databases are useful but some are more useful than others and it's for people to discover. Certainly the most expensive thing is Developer Time so having the best tool to do the job saves companies money.
"You totally lose your credibility when you mention Sybase!! Sybase is the slowest database I have ever used, doesn't understand query optimisation and I had extreme performance improvements with it"
You just lost your credibility with that sweeping statement. Sadly it leaves me no option but to deduce that your extreme performance improvements with it (cute and at mistype, but I presume you meant the opposite) were down to lack of skill in either writing queries or tuning the database or both. Sybase is (or certainly wasn't) for dummies. You need to understand it and know what you are doing.
I've ran several Sybase ASEs of various versions that have all performed extremely fast. In fact a lot faster than Oracle on same hardware. Also it is extremely robust in its recovery from crashes. There is a reason many financial trading environments were/are using Sybase.
Sure the main thread and single tempdb was a potential bottleneck on the earlier versions.
"SQL Server the most stable predictable and performance database I have used"
Did you know it is based on Sybase?
Apologies for the last typing errors writing on a mobile device. You are saying that you have run your queries on oracle and it was slower than Sybase. I can't comment on that as never tested anything similar. However, can you do a simple test, take some of your most complex Sybase queries, transfer the data on SQL Server and then re-run. Let us know your results here! I have worked in 2 very large migration projects from Sybase to SQL Server so totally qualified to comment. By the way, I started my career as a Sybase developer so no bias.
As for your "You need to understand it and know what you are doing" if you mean having "force plans" on every single SQL statement, no thanks, that's why I have a DBMS so it decides for me what's the best query plan. And when my data distribution changes, I don’t have to re-do the query plan again. But seriously take some of your troublesome Sybase queries and run on SQL Server, even a powerful PC will be ok for your test, trust me.
SQL Server isn't often used for such large deployments and there are plenty of good alternatives to Oracle like Teradata.
Oracle seems to be really buggy, fix one bug and another two are created. If you write all your SQL in Oracle syntax then you probably will have less problems, but some people prefer ANSI syntax for their joins.
Also lets not mention Oracle OLAP, Analysis Services is much better if you like cubes. But then there's a lot of new approaches to such aggregated queries now, Qlikview and so on.
"Microsoft SQL server is taking far more business from Oracle than any Open source / niche players..."
That's because the average human's mental capacity has been falling quite rapidly for the last few generations. Reading and typing require more brain engagement than recognizing colourful objects.
"solve trivial optimizations"
If you need an optimiser, your doing it wrong. Well, if your using MSSQL, your doing it wrong and need that optimiser anyway, but I think you get my point.
So I suppose Oracle doesn't need hints then? that's to optimise how it performs. So while SQL Server's "optimiser" is regarded as crappy by some (you should really use stored procedures for anything complex, they can be compiled), at least with SQL Server you don't have to shove lots of hints into the SQL.
"Oracle has hints",
Logic failure. That Oracle has/needs hints is not relevant to whether SQLServer's optimizer is braindead and why that might be so. Equally irrelevant is whether dbms (x) has a query plan language implementation (the proper way to do it, not the half baked SQLServer idea).
"(you should really use stored procedures for anything complex, they can be compiled)"
Completely irrelevant. SQLServer will still get a whole host of optimizations wrong. You have failed to understand how the optimizer actually works. The issue is in many cases blind reliance on the statistics that it keeps and which are maintained by a "block box" algorithm suitable only for databases of trivial size. The algorithm is not accessible and thus large databases have all sorts of issues. Other issues are caused by partitioning. Some are just plain bugs.
Postgres is a database lacking so many feratures (ever tried to handle LOBs - aka "unstructured data" in Postgres?) for today's tasks I wonder people still think it's an alternative to Oracle. The only real advantage is price - Oracle licensing is really crazy - but Oracle knows how to deliver a database with *real* enterprise features, although you have to pay dearly for each of them. Sure, if you have small databases (and today's small databases may be not so small), buying Oracle is probably overkill, but when you need something to handle very large databases and sensitive data, there's really no match.
Remember - a database is a tool and like any tool if it costs a business more than it saves then the business will try to move to a different tool. Postgres may not be as good as Oracle but the price difference is so huge that for many businesses it is the better choice. (And as a former Oracle DBA, I would trust the support from the open Postgres forums more than I would trust the expensive support from Oracle.)
Even a small current server can easily handle a terabyte database which is bigger than most companies under 500 employees are likely to use and if Postgres uses more disk, memory and/or CPU power for its operation this is a tiny cost compared to the cost of the Oracle licenses which can easily be over ten times the cost of the hardware.
Postgres is already better than earlier Oracle versions that were good enough for business in their day and for non-IT companies using the computer as a tool it is good enough for use today.
> like any tool if it costs a business more than it saves then the business will try to move to a different tool.
I suspect corporate inertia is deceiving many of the big software/appliance vendors. Ever increasing profits even in a recession? I strongly suspect its just taking some time to get other options up and running.
Like Oracle, I suspect MSOffice is going down the that road. Yes it is the most feature-full, but there is a massive group of people in corporations who just need approximate formatting for Word documents and who will never use VLOOKUP.
Once installation is quick and easy and the costs rise due to Office365 subs, the licensing friction is reduced and I suspect a lot of companies will push out LO by default and O365 if you need it. Centralise on Sharepoint and you can probably run scripts against your document store to see if LO is a reasonable alternative for user X.
It will be interesting to see how things develop.
PostgreSQL is useful for the SME sector, and even some medium-to-large companies are well within the range of data where Postgres does work, while lacking the eye-gouging costs of Oracle. I wish there were better options, but on the commercial sector it's just DB2, Sybase, Oracle and um.... that Sybase-clone called SQL Server.
I despise most of the NoSQL stuff because it seems that most of those solutions stem from hatred of SQL instead of rational thinking. It's also the reason why I ran away from MySQL, ever since I found their "transactions are for idiots" musings on their documentation.
So basically if I don't want to do commercial DBs, I'm mostly left with Postgres. So that is what I use for those projects these days. If it is commercial, then I'll see my options between Oracle, DB2, and Sybase. And I pray they aren't a MS shop...
"Really? Sybase is better than SQL Server?"
Well, SQL server was based on early Sybase code. Obviously both have since gone their own way. As I don't do windows servers I can't really comment, but it wouldn't surprise me if SQL server didn't integrate better with the host environment, and ASE on the other hand would be more suitable for larger enterprise applications.
despise most of the NoSQL stuff because it seems that most of those solutions stem from hatred of SQL instead of rational thinking.
I suspect the real problem here is the marketers and large number of vocal project managers and developers (both commercial and freebie open source) who embrace the fad-du-jour, and decide that now they have this awesome hammer, all their problems can be reduced to nails and often rant a lot in an uninformed fashion and the stuff they used to use and how everyone who is still using it must be a total cretin.
This problem is not exclusive to NoSQL (Ruby and node.js spring to mind, I suspect Hadoop may have had a similar phase). The tools themselves are very useful within their limits; hating NoSQL because a bunch of idiots say 'eventual consistency is good enough for everything!' seems a little... misaimed.
Yes, this, mostly:
I despise most of the NoSQL stuff because it seems that most of those solutions stem from hatred of SQL instead of rational thinking
Mostly. Some of it is that rational thinking about structured data is hard, and sometimes its very badly taught - and you do need good teaching on this, the learning curve has steep steps in understanding, not just in the assmilation of facts - and SQL will aways be hard and hateful if you don't have that understanding.
Meanwhile, there's Oracle. I happen to believe that it is a technically-superior product, with a poor interface and appalling documentation. Obviously, Oracle fanbois (or fan-beardy-blokes-with-sandals-and-beer-bellies) are going to splutter at that, but the published docs are only useful for looking up stuff you already know. Finding stuff and explaining concepts? Only despised noobz would want to do that, and the Oracle online community reflects that attitude through and through. 'Unhelpful to outsiders' does not begin to describe them.
You can only do Oracle well - or even acceptably badly - if you've spent a long, long time learning the *exact* jargon and the concepts *in the exact form of words* used by the priesthood before they will even deign to patronise you, let alone engage with your questions and reply with usable information - and every now and again they'll throw curveballs of utterly unfamilar concepts that you've never, ever heard of or had to think about in any other kind of software, even if you've been working on other databases for a decade - and asking for explanations puts you right back in the box marked 'stooopid Nooobz'.
Meanwhile, SQL Server has an upsizing wizard from MS-Access that can get a workable database going from the usual desktop toys and prototypes in about a day - don't laugh, most 'green fields' database projects start with data that's already been sort-of-tabulated in a spreadsheet, or outgrew desktop data tools like Access, and SQL Server will get you started faster than anyone or anything else. They might get you started badly, and sometimes 'easy' means 'too easy to make mistakes you'll regret', but a starts's a start - and their documentation explains as well as curates the necessary information.
Oh, and the product's got a better interface, with tools that do the familiar things - and the unfamiliar ones - in familiar and easy-to-figure-out ways.
Pity it's an inferior product under all the dressing-up, but at least you can get at it. And it's good enough that you can get it working and keep it working. Oracle make it really, really difficult for a medium-sized company to get the knowledge and the tools to implement the advantages that make it a better product that SQL Server - you can't even do Oracle badly unless you're a full-time Oracle incompetent, and they're just as expensive to rent or employ as as a full-time Oracle expert.
...So Oracle's expensive licensing is just the beginning of their cost disadvantage.
As for Postgres? It's a good database engine, but the interface and the tools available to developers show its age. So people are unwilling to work with it.
Sybase.. Can't really comment. Haven't used it for a decade; back then it was a better DBE than SQL-Server, but was falling behind because M$ threw a lot of money at all the other stuff that goes with building, owning and using databases.
MySQL. I'm not quite in the camp that says 'The stupid, it hurts' but it's primarily aimed at people who'd rather not do the hard thinking about structured data. Beyond that, I am skeptical about some of the performance benchmarks and comparative reports about the costs of scaling-up - they are not as independent as I'd like - so its probably best that I offer no comment on that.
I believe you are referring to Postgress handling LOBs via overspill files and being able to do work only with their "heads" at high speed. If that is what you are referring to, it is a blast from the past. It used to do that many years ago. AFAIK it is not the case with the more recent releases - it can work with the data in the whole BLOB, not just its head.
Anyone remember back to the launch of 10g and how every Oracle announcement or press release had the word "grid" in it at least ten times? At the time I thought Larry had started playing a great strategy, that he was going to fight the FOSS database players by leaving the comfy, monolithic server zone and going charging into their playground of software spread across lots of cheap, commodity servers. Some of us were happily predicting the days when we'd be migrating our large database instances off big UNIX boxes and onto Oracle grids on top of scale-out Lintel platforms. But it seems the message never got through to the Oracle salesforce, maybe because they were scared that not being able to play the scale-up card left them open to comparisons with some pretty good FOSS offerings, so instead we got more of the "BIIIIIG, we do BIIIIIG" schpiel in their comfort zone, and RAC became more important than grid. Then Oracle bought Sun and locked themselves into the monolithic World, along with the appliances that really don't want to be grids. Don't get me wrong, we use Oracle as our first choice database and have done for over a decade, but it's not looking like first choice in the long term. IMHO, Larry took several wrong turns somewhere down the line.
"and RAC became more important than grid."
And that highlights Oracle's marketing in action. The two are practically the same thing. RAC sits on top of grid infrastructure. RAC can't really happen without grid, and grid wouldn't be anything without RAC.
What will be the best laugh of all is Larry's current cloud fever. 12c : pluggable databases (hmm...something that Sybase and SQL server have always had...).
Yes amusingly after brief stint in the land of cheap Linux boxen, Larry would now quite like you to buy a large engineered system with 12c and consolidate everything onto that.
This is a poor piece.
unstructured data Unstructured data is noise. What you probably mean is data with no pre-defined schema.
"NoSQL" leader 10Gen, which stewards the development of MongoDB, said it has moved "over 100 companies off RDBMS technologies in the past six months" according to its business development veep (and former Reg scribe) Matt Asay. Oracle's revenue share of the worldwide RDBMS market was 48.3 percent in 2012, according to the soothsayers at Gartner, so we can safely assume a significant proportion of these 100 migrations came at the expense of legacy Oracle systems.
This is a very flawed conclusion. Moving companies from relational does not in any way imply that they are being moved from Oracle. And, giving the known problems with scaling MongoDB who's to say whether some of these companies won't be knocking on Oracle's (or IBM's or Microsoft's) door in the future.
Oracle's strategy obviously isn't to everyone's taste but it's pretty clear: improve the low end MySQL and offer increasingly expensive options to customers who think they need it and ignore the rest. It's great that this provides opportunities for third parties to pick up custom from those who can't or won't pay Oracle's fees.
The times for really big migrations can be pretty big: I think Enterprise DB talks of six months plus as not uncommon. Obviously, any company faced with that kind of investment is going to think long and hard about it and this is what Oracle is banking upon.
or have developed capabilities that while irrelevant to much of the database market
I'm not sure what those would be. Data integrity, performance and reliability should be on everyone's shopping list.
I'm sure Oracle doesn't really give a shit about the low-level stuff going from MyASM to one of the key-value or document storage engines.
At the end of the day, while licences are important, any company that is storing business critical data needs to spend enough money employing DBAs who know how to manage whichever systems they have. Outages, corruption and loss are what really cost.
daisy-chaining of various pricey add-ons such as Oracle Golden Gate to attain the performance of some of the newer, cheaper, or free databases.
Golden Gate is a solution for replicating between dissimilar databases, what does it have to do with "the performance of some of the newer, cheaper, or free databases" ?? If you're on a pure Oracle config, use Data Guard.
About two years ago some Oracle sales people were at my company to present their exa stuff. We use oracle for data warehousing.
I asked about their roadmap for oracle streams (sometimes, you only want to replicate a part, not the entire db) and what alternatives, if any, they have to do oracle-to-oracle replication. They recommended Golden Gate, claiming best TCO.
I can think of a few, very big at the time, software vendors that thought they had the market sewn up. One by one they disappeared and I wonder how many techs under 30 will have heard of them. I''m thinking word processing, spreadsheets, even databases. If they are still alive they know who are they and are probably still wondering where their markets went. Everything has a life cycle so unless the likes of Oracle wake up and test the wind, they too, eventually will go the same way.
Wow only took maybe 20 comments or so before my eyes glazed over at the DBA dick waving mental masturbation fest. DBAs are so in demand because like accountants what they do is so mind numbingly boring to other developers that along with the necessary technical skill creates a high barrier to entry. Always glad to have a good one on my projects and always glad its not me.
There are a lot more skilled competent developers (small subset of total of course) than skilled competent DBAs for a reason. And Its not because one is harder or easier than the other (both are a lot of work) or demand is less (if anything with big data all the rage, more demand for DBA).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
