RE: 175 Terabyte Objectivity Database

From: MacGregor, Ian A. <ian_at_SLAC.Stanford.EDU>
Date: Tue, 06 Feb 2001 17:57:02 -0800
Message-ID: <F001.002ACF5A.20010206144333@fatcity.com>

No
federated database is not MS market speech. I should add that the purpose of the HPSS is to make everything appear as a single file system for the data on both disk and tapes. So perhaps it isn't as federated as the MS architecture.
<SPAN

class=063112022-06022001>
I also
have nothing to do with maintaining it. I went to Objectivity class, but came to realize I had enough to do with Oracle.
<SPAN

class=063112022-06022001>
<SPAN

class=063112022-06022001>
Ian
MacGregor
<SPAN

class=063112022-06022001>Stanford Linear Accelerator Center
<A

href="mailto:ian_at_slac.stanford.edu">ian_at_slac.stanford.edu
<SPAN

class=063112022-06022001>
<SPAN

class=063112022-06022001>

-----Original Message-----From: Mohan, Ross [mailto:MohanR_at_STARS-SMI.com]Sent: Tuesday, February 06, 2001 11:58 AMTo: Multiple recipients of list ORACLE-LSubject: RE: 175 Terabyte Objectivity Database
 The
 way you use the word "federated" makes me think Stonebraker
 or
 Codd came up with it...does it transcend MS MarketSpeak?

-----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
 The 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.
 There are numerous load balanced data servers which handle parts of the federation.

 Ian MacGregor
 Stanford Linear Acclerator Center <A
 href="mailto:ian_at_slac.stanford.edu">ian_at_slac.stanford.edu

-----Original Message-----From: Mohan, Ross
[mailto:MohanR_at_STARS-SMI.com]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 To: Multiple recipients of list ORACLE-L 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 ian_at_SLAC.Stanford.edu

-----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
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! <A
href="http://news.cnet.com/news/0-1003-200-2897140.html?tag=st.ne.ni.metacomm.ni"
target=_blank>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: <A
href="http://www.zdnet.com/eweek/stories/general/0,11011,2623013,00.html"
target=_blank>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: <A href="http://www.orafaq.com"
target=_blank>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: <A href="http://www.orafaq.com"
target=_blank>http://www.orafaq.com --
Author: MacGregor, Ian A. INET: ian_at_SLAC.Stanford.EDU
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 - 19:57:02 CST