Oracle Has More Flaws Than SQL Server
jcatcw writes, "Next Generation Security Software Ltd. of Surrey, England, compared bugs in Oracle and SQL Server that were reported and fixed between December 2000 and November 2006. The tally: Oracle had 233; MS SQL had 59. The products compared were Oracle 8, 9, and 10g; SQL Server 7, 2000 and 2005. From the article: '[The head of the survey said,] "The results show that the reputation that Microsoft SQL Server had back in 2002 for relatively poor security is no longer deserved."' Oracle's response: 'Measuring security is a very complex process, and customers must take a number of factors into consideration — including use-case scenarios, default configurations, as well as vulnerability remediation and disclosure policies and practices.'"
what about IBM DB2?
One man, one word.
Reported and fixed means that the company which doesn't fix bugs looks more secure. Not that I'm implying that MS is worse than Oracle on this, mind you. I just wanted to point out that this metric has loads of potential flaws.
See what I've been reading.
...and it was Slammer, you'd have to admit it was kind of a biggie.
Once I was a four stone apology. Now I am two separate gorillas.
All code has bugs. How many of the bugs are important to the users?
Who cares?
Facts are history now plebs have politics for religion on social media.
...but please stop calling it just SQL Server
YES! I'm tired of ceding parts of the English language to Microsoft. How did Microsoft end up owning the word Windows, forcing Lindows and wxWindows to be renamed, when X-Windows has been around so long? If Microsoft can't be bothered with coming up with unique names for its products, don't let them take over common words by dropping the "Microsoft" from the name.
... they are rather quick to quash and fix a discovered security bug. Yes, there's a reason why I used both words. Check out the aftermath of this example at The Daily WTF.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
There is cruft in Oracle that dates back to the mid '80s and it's showing.
.nohup files lurking in (*nix) log directories. I find that astonishing.Huh? What exactly war you talking about? Oracle does not store any files in standard *NIX log directories.
ASM won't be suitable for widespread use for two or three releases, 11xR2 or something. That should have been right on try #1 six or seven years ago.
Oracle needs a through refactoring. They'll either do it under their own steam or the market will do it for them.Well, no not really. There is old code in there, but it is not cruft, but well functioning code. I'm also concerned about Oracle's development practices.What? Can you explain what you mean because I have no idea what you are talking about. Quality is continues to be poor for the first few releases of any new feature. Witness 10g EM; there are
Completly wrong. Thousands of customers are using ASM today and with great success. Please explain what the heck you are talking about.
If you mod me down, I *will* introduce you to my sister!
While Oracle has more flaws it certainly is a much more complex product, so it stands to reason. Besides, Oracle vs. SQL Server is not a fair comparison at all. SQL Server is quite bare.
The "flaws" I've experienced with SQL Server either made my server crash or corrupted my databases to all hell. I've never had an Oracle server (or any other vendor's product) corrupt my tables, thank you very much. I think MS brought this "feature" over from their Jet / Access engine.
If you compare the severity of these flaws, not their category, I think you'll find that SQL Server has many more *unrecoverable* flaws. That's been my experience with every version since 7.0.
Slammer anyone?The slammer worm was released in 2003, and affected a vulnerability that had been patched eight months prior. The last discovered vulnerability for SQL 2000 was in January 2004. A high number of reported bugs and fixes shows that they're executing due diligence, and working to keep their system as secure as possible.heh. You used Oracle and Due Diligence in the same sentence. MSSQL's low number of bugs suggests that Microsoft isn't digging hard into their code, but only waiting for big public flaws.Possibly. There is another possible reason for the low number of discovered flaws, but I don't think you want to hear that one.
...then it stands to reason that you will have a ton of additional bugs.
This argument in no way excuses Oracle for their timely patch cycle (or lack thereof), but may explain the higher number of patches.
I haven't looked at the Sybase/SQL Server family for awhile, but I assume that it still doesn't offer anything like Flashback, LogMiner, richer indexing, direct LGWR connection to DataGuard, resumable transactions, or even basic multiversioning.
Actually, the name of the product is "Microsoft SQL Server". Still a stupid name but it's not just "SQL Server". Lazy techies are responsible for not using the full name, not that I blame them. What I want to know is how Microsoft managed to convince a court that the name of another product of theirs was actually "Windows" and not "Microsoft Windows" (look at the box sometime!) which forced all those other people to change their product names.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Lets face it, a bug report can be anything from a misspelled error message to a gaping sa/root/admin (whatever oracle calls it) compromise.
If that is the case, oracle's mgmt tools heavy reliance not only on java, but *specific* version of java
w/o updates I'm aware of, would explain a lot.
off the top of my head:
Input fields that don't register the first key press, menu item that don't redraw for some reason, refreshes and connection errors that require exit/relaunch.
Other frustrations like that, that aren't oracle's "fault" per se, but don't help the spec/check sheet for bugs.
Didn't RTFA (yet), but are those counted as bugs? I'd like to know.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
You might also want to know how many houses in the area are built like tinderboxes.
The bottom line is of course "Am I more likely to have a security problem while using Database A or while using Database B?" Perhaps some studies ought to be done to determine the relationship between measurable things like number of bugs, time to patch, etc, and various user's perception (or perhaps security pros' perception) of how many security problems were actually had. Then we'd be able to actually assign some semblance of meaning to these currently utterly meaningless studies of "number of bugs". I don't think that even knowing time to patch or severity of potential exploit or such things would really tell anyone much about the bottom line as I have described it, at least not unless some real investigation of the relationship is done first.
And of course this doesn't just apply to databases, but to any sort of software which has any security consequences at all (which winds up being essentially all software).
SIGSEGV caught, terminating
wait... not that kind of sig.
I agree, counting bugs is an oversimplification...
My biggest surprise here is that they only found/or reviewed less than a couple hundred bugs each. Strange, because I am sure that I can find more bugs than that in 4 days work on each product. This research can't be all that deep. I must be missing something???
Any normal QA person would be able to find that many bugs in 10 or 20 days.
An obvious area is geospatial features.
e studies/globexplorer/) - yes, I know about Terraserver but note that Micrsosoft doesn't have to pay for their own licenses.
Oracle has Oracle Spatial. PostgreSQL has PostGIS.
With SQL Server, you need to buy an expensive third party package (like ESRI ArcSDE or MapInfo Spatial) that does not work as well as PostGIS because ESRI doesn't have the hooks they need deep enough into the database to add spatial index types.
The PostgreSQL/PostGIS GIST index types are very well suited to geospatial data. The R-trees that I believe Oracle uses are good as well. Does SQL Server have R-tree indexes?
You can say the same about extension languages - SQL Server's fine if you want to extend it in their dialect of SQL (I hear their C# stored procedures exist but are recommended against) - while with Oracle you have their (very powerful) dialect of SQL and Java - but with PostgreSQL you have Java, Perl, C#, R (a SPSS clone), Ruby, etc.
Other pretty basic SQL Server features end up being hidden in their $40000/CPU versions of their product; so you won't see them in even moderately high volume products like Cisco's switches like postgresql is - or really large databases like GlobeXplorer's (http://postgis.refractions.net/documentation/cas
So basically, yes, it's not hard to defend the claim that even the most expensive SQL Servers with the most expensive third-party-ad-ons are pretty limited compared to PostgreSQL.