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