Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Microsoft destroys TPC-C records!
Norris wrote:
>
> See the Locking differences between Oracle and SQLServer
> http://www.microsoft.com/sql/productinfo/transadvantage.htm
This article is complete and utter crock of b.s. It only takes one college course in database systems to understand that this article is false.
The example of the husband and wife withdrawing money at the same time would never happen in an Oracle database the way that the article describes. If a developer wants better control over their transactions, they need to look no further than the SET TRANSACTION statment or the DBMS_TRANSACTION package.
Also, the reason that Oracle (and other good RDBMS's) does not support READ UNCOMMITTED is that it is a very, VERY BAD IDEA! Implementing READ UNCOMMITTED for transactions other than the current one can only lead to trouble. What happens if a second transaction reads uncommitted data from the first transaction and then the first transaction is rolled back? Is the second transaction immediately rolled back as well, or is it allowed to continue with false data?
The article is full of erroneous statements. It states, "Oracle8i always issues row-level locks." While this may be the default it appears that they have never heard of the LOCK TABLE command available since at least Oracle8. Further, the article states "SQL Server 7.0 provides more flexibility to developers, more accurate data, and better use of system resources than Oracle8i." As I have shown in the preceeding paragraph, READ UNCOMMITED does not provide more accurate data. And the article does not offer one scintilla of proof that SQL Server 7.0 makes "better use of system resources than Oracle8i".
This article just goes to prove that just because it's on the 'Net does not mean that it's gospel.
Just my 3.14159 cents worth!
Brian
-- ======================================== Brian Peasland Raytheons Systems at USGS EROS Data Center These opinions are my own and do not necessarily reflect the opinions of my company! ========================================Received on Wed Apr 05 2000 - 00:00:00 CDT