Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 175 Terabyte Objectivity Database

RE: 175 Terabyte Objectivity Database

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

way you use the word "federated" makes me think Stonebraker or
Codd came up with it...does it transcend MS MarketSpeak?

  <FONT face="Times New Roman"
  size=2>-----Original Message-----From: MacGregor, Ian A.   [mailto:ian_at_SLAC.Stanford.EDU]Sent: Tuesday, February 06, 2001 1:02   PMTo: Multiple recipients of list ORACLE-LSubject: RE:   175 Terabyte Objectivity Database
  way Objectivity sets up a federated database is  that you have a    master database which records information  about the   federation.   An individual database can be attached or detached   from the federation.   An individual database is comprised of a   database file ,which holds logical structrures termed containers, which in   turn hold the persistent data, termed basic objects.  The data   is stored in a hierarchical file system, HPSS,  with Redwood tape   drives providing the near-line storage.    <FONT face=Arial color=#0000ff
  size=2>There are numerous  load balanced data servers which handle parts   of the federation. 
  <FONT face=Arial color=#0000ff
  size=2>Stanford Linear Acclerator Center   <A
  href="">   <SPAN
  class=734244816-06022001><FONT face=Arial color=#0000ff   size=2>     

    <FONT face=Tahoma
    size=2>-----Original Message-----From: Mohan, Ross     []Sent: Tuesday, February 06, 2001     5:46 AMTo: Multiple recipients of list     ORACLE-LSubject: OT: 175 Terabyte Objectivity     Database
    OOooohhhhh, how COOL!......Objectivity is neither Oracle nor     SS.... is it ( gasp ) "federated" in any     sense?
    Can you tell us more?  This is interesting......     

    -----Original Message----- From:
    MacGregor, Ian A. [<A
    href="mailto:ian_at_SLAC.Stanford.EDU">mailto:ian_at_SLAC.Stanford.EDU]     Sent: Monday, February 05, 2001 8:20 PM <FONT     size=2>To: Multiple recipients of list ORACLE-L <FONT     size=2>Subject: RE: OT - WHAT is a FEDERATED DATABASE ???     We have a 175 terabyte database in Objectivity.  It     houses event data  from  a physics experiments looking at the     decay of B-mesons and their antimatter counterparts, trying to find     out  what's going on with CP violation.     Ian MacGregor Stanford Linear
    Accelerator Center     -----Original Message----- Sent:
    Monday, February 05, 2001 4:56 PM To: Multiple     recipients of list ORACLE-L
    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 <FONT     size=2>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" <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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! <FONT
    size=2><A target=_blank
    href="">     A snippet: "An Oracle spokeswoman
    said the new Oracle 9i database, due in the first <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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:     ''
    I have some answers, for the curious: <FONT     size=2><A target=_blank

    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, <FONT     size=2>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???????? <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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 <FONT     size=2>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, <FONT     size=2>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 <FONT     size=2>so it's back to reading the reviews and making decisions based on gut     feel. IMHO, Steve Orr     

Received on Tue Feb 06 2001 - 14:13:38 CST

Original text of this message