Oracle FAQ Your Portal to the Oracle Knowledge Grid

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


From: Mohan, Ross <>
Date: Tue, 06 Feb 2001 06:23:06 -0800
Message-ID: <>

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

||  Only with the help of the listers, Steve! Thanks......

> 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-

||  right, but.....maybe they meant PARTITIONED data?

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."

||  I don't know about that. I know if i lose one-tenth of my EMP table, I can still query the other 9/10ths....but you have a specific type of failure in mind?

That's a single point a failure and that's the real problem.

||  Single points of failure are the first places to look for

        weaknesses, yes. There is also of concept of "partial failure"
        or service brownout. (Versus "the-sky-is-falling" catastrophic

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.

||  I honestly do not know, but that type of question is an example of the

        good discourse that goes on on this list. If i do find out ( and I will
        ask ) I will let you know.

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?

||  Nicely put.

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.

||  I agree. Let the search begin! <G>

> the TPC is *independent*.
Yes, and it's flawed and vendors take advantage of this to dupe the unwitting.

|| Name one metric/benchmark that is NOT flawed. You get a free meal
        from me if you do. After you can't do that, name one company
        that would not use a test or competitor's       flaws/shortcomings
        to their advantage. Come on, it's not about some kind of
        dreamy "perfection", it's about doing the best we can.
        I personally believe that quoting the TPC is alot more
        defensible that quoting Oracle Magazine. LOL!!

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.   ;-)

||  Amen, that's why we're all here. Received on Tue Feb 06 2001 - 08:23:06 CST

Original text of this message