Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re:OT - WHAT is a FEDERATED DATABASE ???

Re:OT - WHAT is a FEDERATED DATABASE ???

From: <dgoulet_at_vicr.com>
Date: Tue, 06 Feb 2001 11:00:00 -0800
Message-ID: <F001.002AC439.20010206093027@fatcity.com>

Steve,

    I've never heard of any ERP vendor that supports a "federated database" as you describe it. PeopleSoft on the other hand keeps telling us that they will support a replicated/distributed database sometime in the future. Now if you understand PeopleTalk that means never.

Dick Goulet

____________________Reply Separator____________________
Author: "Steve Orr" <sorr_at_arzoo.com>
Date:       2/5/2001 4:55 PM

Ross, glad to see you're starting to come up to speed here. :>)

> But for the clustering to work, businesses would have to change software
> and segment the data

The CNet authors obviously got tangled up in their notes and didn't understand what they were writing about. (Not a first.) You don't have to "segment the data" in OPS- that's the "federated database" scene where you place different tables for the same database app on different servers. If you segment an enterprise package like SAP or Oracle ERP then you have 1000's of tables to deal with. Chances are, no matter how "intelligently" you segment your data, just losing any random machine, and its attendant subset of tables, will bring the application to a halt and no more transactions will be possible even though the database is still "up." That's a single point a failure and that's the real problem. And to add a machine to the federated cluster you still have to re-segment the data. I don't believe the good folks at Dell have architected a federated database like Microsoft did for the TPC.

Here's a challenge... Does anyone know of ANY enterprise ERP type package or any other application where the software vendor supports a "federated" architecture? If not then it's likely no one will ever experience the performance seen in the TPC-C benchmarks by Microsoft. If no real world apps support a federated architecture then we may as well just ignore all those benchmarks. And after we throw all those benchmarks out which database engines consistently score the best on the remaining benchmarks?

Here's another challenge... Has anyone ever worked with or even know of anyone who's worked with a federated database? While I wouldn't configure my database exactly like Oracle configures those used for TPC benchmarking, (turning off redo, etc.), in terms of physical design I do believe my databases are at least somewhat similar or recognizably in the same ballpark. I do not believe anyone comes close to configuring SQLServer's physical layout like that used in the Microsoft benchmarks. That's the challenge and until someone can address this challenge we should practically ignore all TPC benchmarks produced from Microsoft's federated database architecture. IMHO.

> the TPC is *independent*.

Yes, and it's flawed and vendors take advantage of this to dupe the unwitting.

BTW, Oracle OPS / EMC doesn't have to be a single point of failure if you implement the SRDF option but I've never done it so what do I know? Well I'll answer that by saying I don't know much but I do try to keep an open minded pursuit of the truth. Sometimes I actually succeed... I think. ;-)

Steve Orr

-----Original Message-----
Sent: Monday, February 05, 2001 3:09 PM
To: Multiple recipients of list ORACLE-L

Very Interesting! It appears Oracle 9i, is, in fact, a Hybrid Federated Database!
http://news.cnet.com/news/0-1003-200-2897140.html?tag=st.ne.ni.metacomm.ni A snippet:
"An Oracle spokeswoman said the new Oracle 9i database, due in the first half of next year, will feature new "clustering" technology that will make the company's databases perform faster and more reliably than before. Clustering allows businesses to harness multiple servers to run a very large database, allowing servers to share work or take over from each other if one fails.
The company's previous clustering technology, called Oracle Parallel Server, allowed businesses to add as many servers, or high-end computers, as they needed. But for the clustering to work, businesses would have to change software and segment the data, a time-consuming effort for database administrators, said Jeremy Burton, Oracle's senior vice president of products and services marketing..."

-----Original Message-----
Sent: Monday, February 05, 2001 5:55 PM
To: 'ORACLE-L_at_fatcity.com'

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-----
Sent: Monday, February 05, 2001 3:53 PM
To: Multiple recipients of list ORACLE-L

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Steve Orr
  INET: sorr_at_arzoo.com

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: ListGuru_at_fatcity.com (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: dgoulet_at_vicr.com

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: ListGuru_at_fatcity.com (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 Tue Feb 06 2001 - 13:00:00 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US