Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: OT RE: Async I/O on Windows - WHAT is a FEDERATED DATABASE

RE: OT RE: Async I/O on Windows - WHAT is a FEDERATED DATABASE

From: Mohan, Ross <>
Date: Mon, 05 Feb 2001 15:15:59 -0800
Message-ID: <>

I have some answers, for the curious:,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 []
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.

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             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:
Author: Steve Orr

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: (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).
Received on Mon Feb 05 2001 - 17:15:59 CST

Original text of this message