| 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 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
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.
<FONT face=Arial color=#0000ff
size=2>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
<SPAN
class=734244816-06022001><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 <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="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 <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:
'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. 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
 |
 |