I have some answers, for the curious:
http://www.zdnet.com/eweek/stories/general/0,11011,2623013,00.html
It appears that SS can partition data storage among multiple
machines, giving it "blow your doors off" performance.
If a machine goes ( gets dynamited at an Oracle demo, for instance)
the data goes with it.
This would be much in the same way that your data (ALL of it) would
go if you blew up the EMC/Hitachi/StorageWorks array.
Oracle Parallel Server, in contrast, has a single location for
it's data ( read: single point of failure! )
Granted, there are more failure points in a federated architecture,
but there is no such thing as a TOTAL failure ( like "site down" )
since only part of the data needs to be recovered from backup.
But, with Oracle Parallel Server, if your disk farm goes down,
you lose EVERYTHING.
I suppose if i ever need to store a Petabyte or so, I'll do it
on more than one box, for disaster recovery. So, this is the
"way around" the weakness in hardware loss for both SqlServer2K
and Oracle.
And, if I run my PByte database on SS2K, I'll get my answers alot
faster. <nudge nudge>
-----Original Message-----
From: Steve Orr [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 3:53 PM
To: Multiple recipients of list ORACLE-L
Subject: OT RE: Async I/O on Windows - Federated Database Foolishness
What's a federated database????????
We really need to understand this otherwise we'll be duped by Microsoft's
deceptive benchmark claims!!
Comparing the performance of SQLServer in a federated database configuration
to Oracle in a parallel server configuration is useless and misleading but
that's what Microsoft is doing when they tout their TPC-C benchmarks. In a
non-federated database configuration Oracle8 outperforms SQLServer handily.
Do we really want performance without fault tolerance? How well does
SQLServer perform when it's down because of its fragility? ;-/
Microsoft "shattered" the TPC-C record with the "federated database"
architecture but even a self-confessed pro-Microsoft apologist pointed out
that no one in their right mind would actually setup a production OLTP
database that way. The point of the demo at OpenWorld was to highlight the
fragility and impracticality of the federated database architecture as a
real world fault tolerant solution. The demo was quite amusing with smoke
and sound effects. While displaying transaction rates, a node in a running
cluster was "blown up" with predictable results. The transaction rate for
SQLServer went down to zero because the database was down while the Oracle
Parallel Server cluster kept on running. Of course Microsoft does not want
to see its products trashed regardless of the truth so, in an attempt to
prevent Larry from repeating this demo they sought an injunction based on
the fine print of their license agreement which says you can't run benchmark
tests without prior written approval from Microsoft. (Does anyone ever read
license agreements?)
We need a new, more fair benchmark to measure transaction rates AND fault
tolerance of a database cluster. Something like a standard 4 node cluster
and a random blow up of a node. This new benchmark would need to run a
practical, real world application and measure transaction rates before,
during and after the blow up. It would also be nice to measure the linear
scalability of adding new nodes (which is impossible under the federated
database approach without doing a complete reorg). Oh but now I'm dreaming
so it's back to reading the reviews and making decisions based on gut feel.
IMHO,
Steve Orr
-----Original Message-----
Sent: Monday, February 05, 2001 11:42 AM
To: Multiple recipients of list ORACLE-L
Actually, not that it matters from what I can tell, but Oracle is tops if
you consider clustered vs. non-clustered. It seems that Oracle doesn't even
have tests for clustered systems. I wonder what happened to the VLDB tests
in the huge DEC/Compaq Alpha cluster?
As far as SQL (pronounced: "SQueaL") Server "blown the doors off", there are
factors that TPC does not consider. First, is reliability. According to
Oracle Magazine, Jan/Feb 2001, p38, "...a 12-computer configuration from
Microsoft, such as that used in recent TPC-C benchmarks, is estimated to
experience a catastophic failure once every 7.5 days, according to
Microsoft's own estimates." Granted, the quote is from Oramag, but I've
heard the same from other "Industry Sources".
I know of a specific implementation where the NT database servers would dog
and/or crash when approximately 500 concurrent users were attached (note:
"attached" <> "active") to the database. The decision was made to dump NT
for DB serving and go with a major (HP or Sun or IBM) flavor of Unix for
it's scalability and reliability.
Second, when was the last time you needed a 500K TPC-C from only 48 clients?
From a couple thousand, yes, but only 48? And who's gonna buy everyone in
their company a $7500 desktop PC with twin PIII-800s in them for clients?
While those numbers are specific to the top TPC-C Compaq/MS result, that's
how all these companies get their numbers.
I'm not betting my job on TPC-C numbers. The numbers just don't reflect
real-life situations.
And I didn't even touch upon the potential locking problems on SQL Server,
or how it can do dirty reads... :)
Just my $.02. I need to go create some Oracle databases on HP/UX now. ;)
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA
-----Original Message-----
Sent: Monday, February 05, 2001 09:56
To: Multiple recipients of list ORACLE-L
"NT still pants"...LOL!!!
It must be panting alot, It has BLOWN THE DOORS OFF of "Oracle on Unix" in
running SQLServer on NT, as has DB2.
also send the HELP command for other information (like subscribing).
... Thread continues with Ross drivel ad nauseum :-)
Oh Hello Ross :-)
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve Orr
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
