> Well ... OK. So I guess that means not having the functionality at = all is > better? Enlighten me. I'm missing something here. Well, no, some functionality is better than no functionality, of course. = But there are a lot of limitations that make domaining unsuitable for a = number of environments that Sun has been selling it into. I should have = made clear that my point was just was to educate about the limitations, = since Sun is certainly not taking that step with their customers. =20 >=20 > And this is a lot of space? <snip> > > All this for a maximum of 106 processors. > > In comparison, you can put 168 Intel processors >=20 > Silly me! You have me here. I forgot that it is all about=20 > processor count. <snip> > but everything else is crap. And I STILL get stuck in this mode that = the > "everything else" part matters too ... A LOT. "I can't see how going to blades is going to save space." That's what I was addressing. Certainly, there is no comparison, = architecturally, between a large SMP server such as an e15k and a bunch = of individual blade servers. If I ever gave that impression, I = apologize. But, if we're going to be talking about processor and server = density, not to mention heating, power, and cooling, then the e15k is = about the worst offender I've seen outside of the mainframe world. > > From IBM, the same config lists out at $650k in blades >=20 > I see that IBM still sells the multi-CPU servers. Are these intended = for > idiots who don't know any better? Nono, there's a bunch of reasons why you might want multi-cpu servers. = For example, you use Cisco switches, and don't want to use the built-in = blade server ethernet switches. You require a particular kind of fibre = channel card only available on standard servers. Or you need lots of = I/O connectivity - a server with 8 fibre channel connections, for = example. =20 But for the environment he's discussing - dev instances, where there's = going to be regresssion testing, application/load instances, etc., = density becomes important, as well as keeping costs down. Spending $2m = on a single server with limited flexibility, high environmental costs, = high support costs, and poor density for a development environment seems = unsupportable to me. Perhaps an organization with deep pockets might = disagree. > > I realize that money may not be an issue, but if you're building out > > lots of small servers, the logic of using a huge Sun server and > > partitioning it escapes me, I'm afraid. >=20 > I'm afraid my e-mail client malfunctioned, and the part of the=20 > original post > that specified these were to be small servers was lost. Well, he said blade servers, which means a maximum of 4-processor = servers - I qualify a 4-processor server as "small". My point was only = that, if you're already looking at an environment that limits you to = four processor servers, moving to an environment that doesn't really = carve up well at that size seems ill-advised, at best. =20 On the flip side, if he had said, "I need 4 20-processor servers", it = would have been equally ill-advised for me to recommend blade servers - = at that point, an e15k-style server becomes an attractive option. Thanks very much, Matt ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------