| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> 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
<FONT face=Arial color=#0000ff
size=2>Stanford Linear Acclerator Center
<A
href="mailto:ian_at_slac.stanford.edu">ian_at_slac.stanford.edu
<FONT
face=Arial color=#0000ff size=2>
<FONT face=Tahoma
size=2>-----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 <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 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 <FONT
size=2>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 <FONT
size=2>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 <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 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 <FONT
size=2>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 <FONT
size=2>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
target=_blank
href="http://news.cnet.com/news/0-1003-200-2897140.html?tag=st.ne.ni.metacomm.ni">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, <FONT
size=2>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:
'ORACLE-L_at_fatcity.com'
I have some answers, for the curious: <FONT
size=2><A target=_blank
href="http://www.zdnet.com/eweek/stories/general/0,11011,2623013,00.html">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, <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. <FONT
size=2>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!! <FONT
size=2>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? ;-/ <FONT
size=2>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 SQLServer went down to zero
because the database was down while the Oracle <FONT
size=2>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 <FONT
size=2>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 <FONT
size=2>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 <FONT
size=2>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. <FONT
size=2>IMHO, Steve Orr
 |
 |