Now we will discus about can Oracle kick SQL Server's behind? Oracle versus Microsoft SQL Server in the Enterprise
Edition. Oracle expert David throws down the gauntlet to Microsoft
As an Oracle DBA in an organization replete with SQL Server installations, I
find myself receiving comments or questions on a regular basis regarding
differences in the two products. The vast majority of comments I receive fall
into one of two camps.
Answer about Oracle and MS SQL Server race.
The first of these questions or comments usually come out as
"Can you teach me Oracle?" My polite answer is generally "Sure, I'm actually
just about to do a class on that; I'll call you when it's ready." This is a way
of being nice without committing to what the questioner doesn't realize could be
weeks of effort on my part, not to mention theirs. (Of course, I'm not so much
concerned with theirs because their efforts don't generally keep me at the
office later than I need to be.) Sometimes I'll take the extra step of telling
them where they can download a full version of Oracle to install and play with.
But sometimes that would be a bad thing for me to do because it might only
invite a plethora of follow-ups.
The second type of question I get is
something like this: "We're having this issue with SQL Server, and I want to see
how Oracle handles it." Okay, now we're getting somewhere. I can offer some
assistance, but this won't be a request for hours upon hours of my time. It will
be a well-thought-out description of a specific problem, the Oracle answer to
which will guide the questioner down a road that might lead them to a solution
to their SQL Server problem. The questioner continues: "Our SQL Server databases
are getting too big?how does Oracle handle this?" Sigh...I stand corrected.
I'd Like to Help, But...
Maybe my approach has been wrong all along. Maybe I should just write down a
summary of what the likely concerns might be. Then I could hand this list to
each person who comes calling for advice. If the individual is on a crusade for
general Oracle enlightenment, this list will be a somewhat comprehensive?albeit
technically light?spiritual guidebook of sorts. If, on the other hand, the
inquisitor is seeking resolution of a specific and quantifiable concern, this
paper will serve to guide them in the right direction so they can find the
answers they're looking for from their own desk.
But no, that would all take too much time. And as much as I want to help
these sojourners, I don't really care to go too far out of my way for them. That
would set a bad precedent. That would encourage them to come back to me yet
another time with yet another vexation. So let me instead just take a few
minutes to ramble about what I shall call design flaws in SQL Server.
Architectural concerns that cannot be worked around. Axiomatic principles, if
you will, that often do not get raised when diving deep in the technical details
of a database platform decision. Rather, they must be lived with if your
decision has been to use Microsoft's database platform. Features, or lack
thereof, can often be worked around, but a product's basic machinations cannot
be altered easily?certainly not by an end user of closed source software. Oh
sure, there are ways to make the pains not hurt as bad as they might, but they
cannot be overcome. Therein lie many of the differences between the two
platforms, not to mention the source of many ills.
Bear in mind, I'm not working on a system for the florist down the street.
No, Microsoft is making its best attempts to push itself into the Enterprise.
Into Oracle's neighborhood. So that is what I am about to discuss: issues of
concern to enterprise systems managers.