Re: Sorry, but...
Date: Mon, 9 Jan 2012 18:45:30 -0800 (PST)
Message-ID: <733dd4ff-37e9-4a79-908d-13b3e1a9d1f6_at_o12g2000vbd.googlegroups.com>
On Jan 9, 7:35 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> On Sun, 08 Jan 2012 16:18:37 -0800, Noons wrote:
> > This is one of the great fallacies of the shared vs dedicated db server
> > nonsense.
>
> Shared server is unfortunately largely ignored. It is a great option for
> saving resources. I am amazed that many companies are building gigantic
> computers, having 64GB of RAM, rather than try saving some RAM with the
> shared server.
> On the other hand, shared server is not being used very much, which
> usually means it is buggy. I don't have the facts, the company that I
> work for uses only the dedicated server connections, but I think that
> some optimizer bugs and memory leaks should be expected. That is a useful
> technology and is being completely wasted, primarily by marketing.
>
> --http://mgogala.byethost5.com
Mladen,
You guys must have very small requirements if 64GB/RAM is considered "big". :) :) :) :) Some of the big iron at the site in question have 3-4x that much. At a separate site, I have managed SGA's at more than twice that size - and then to have that SGA in a 3-node RAC cluster. (Sun 6900 x 48 dual-core x192GB memory and more than 350TB of storage loading in excess of 1TB/day with thousands of mind-numbing decision support queries run daily. - and this was only one of 4500 database instances in that company.)
If shared servers actually functioned without having an instance in one "partition" affect all of the other "partitions", they might be more acceptable. However, they are not. I have had too many instances where the hardware guys either didn't have a clue or had incorrect information as to how to configure more than one "partition" to have high workload capabilities at a time. I think the DEC GS series came closest to achieving that in a hardware partitioned system. VMware is a joke - in all it's incarnations. I would only trust VMware to house a database server if all they needed was something more than a spreadsheet accessed by only a few people at a time. Oracle supports their version of VM, but only because idiot customers demanded it because some moron wrote something about server consolidation in some trade rag (probably someone from IBM, SUN or HP trying to sell their next generation of hardware) and really had no clue as to what they were doing and created the next "buzzword syndrome" stampede. And then those of us out in the trenches were left to try and "make it work" because the decision was made. Period. And the smart people in the room once again retorted, "Oh no, here we go again..."
BTW, RAC is not new (not even in 2000-2001 when 9i RAC came out.) DEC had "RAC" (shared/cluster database Rdb on VMS Clusters) as early as Rdb/Version 1 and VMS Version 4 (1984-ish) with clustering. In 1990, DEC's "cloud" computing capabilities were responsible for helping to factor Fermat's 9th Number (800+ vax servers on the DEC internal network where internal email showed > than 800 contributors, the white paper guestimated 700). I know some MicroVAX II's (much slower than the MV3100's mentioned in the paper) that were used in the effort.
http://www.std.org/~msm/common/f9paper.ps [note: this is a postscript file requiring a postscript reader/printer - caution: unless you are a math geek, this will make your head spin.] Received on Mon Jan 09 2012 - 20:45:30 CST