Re: Oracle question from a Sys. admin, re: Solaris performance

lambu999_at_yahoo.com wrote:
> Joel,
>
> That made an interesting reading, thanks.
>
> "As a simple-minded way of doing things, one instance per customer
and
> throw out a huge amount of expensive hardware is workable, until
things
> screw up. But it really is not the best way to do things, you need
an
> experienced, capable DBA to set things up properly."
>
> Can you please tell us what is the right way? (or am I looking for a
> silver bullet?) Keeping the clients' data in separate tablespaces?
> But, as you said, it may be an issue during upgrades. Please explain
> more.
>
> Thanks.

Well, you may have noticed how the tone of the responses changed once you posted the hardware. When you get to "serious sized" configurations, one hopes you get some experienced DBA to set it up, and many of the rules of thumb for smaller systems get thrown out in order to encompass the different requirements of a service vendor. So, there is no "right way," only reasonable methodologies. Since many of us here have seen way too many unreasonable methodologies (such as, "do it the same way we did it with sql-server" or "just do it this way because the vendor said" [sometimes missing where the vendor said "we can't give too many specifics because user requirements vary so much"]), that we tend to assume certain mistakes. Since you are asking such questions of us and not of your dba, we have to make assumptions from that, too.

I don't know if we are mistaken in assuming someone set up a working instance, then someone else mindlessly copied that 50 times, or if someone said "this generic configuration will work for x number of instances," or if all your instances are tuned for a discrete amount of usage or what.

We also don't know what kind of service agreement you have with the customers, and of course, that rules over all. Some DBA's might establish an instance for each version, then just move customers to another version when they are ready. A major reason for using fewer instances is to be able to throw lots of resources towards a user when no one else needs them. At one time, instance crashes were more common than now, so in the past there may have been more incentive to split customers by instance. You need to know how various recovery options will impact the instance to properly evaluate whether the SLA's require separate instances.

And of course, we don't know anything about your app. So many of us have seen poorly written apps that result from developers thinking in non-oracle specifics (sometimes under the rationalization of "db-independence," sometimes transferring things that should be handled by the database into front-end software, sometimes not understanding the oracle definitions of "database" and "instance"), we tend to just point people at Tom Kyte's books and the concept manuals. Poorly written apps are often poorly administered.

jg

--
@home.com is bogus.
"Moving tip #32:  Do not pack dog and cat in same box" - seen on Budget
rent-a-truck