Re: Databases in a server box

Sybrand Bakker wrote:
>
> "Sean M" <smckeown_at_earthlink.net> wrote in message
> news:3CD1827E.5A7548B2_at_earthlink.net...
> > Sybrand Bakker wrote:
> > >
> > > There is NO reason why multiple applications can't reside in one
> > > single database. Security won't be compromised if you do so. Multiple
> > > applications of *one single customer* should go into *one database*
> > > especially when it is quite likely redundant data is going to be
> > > maintained in multiple databases. This will increase maintenance
> > > cost.
> >
> > Come now Sybrand, there are plenty of good reasons to run different
> > applications in different databases. Different apps can have vastly
> > different user loads, uptime requirements, backup requirements, testing
> > requirements, disk requirements, cpu/memory requirements, networking
> > requirements, etc. Multiple databases for heterogenous apps can be
> > perfectly reasonable. Same goes with multiple instances on the same
> > host - there are plenty of good reasons to do this (and other good
> > reasons why you shouldn't, but it totally depends on the particular
> > needs of the company).
> >
> > Regards,
> > Sean
>
> In my job I always see the opposite: Oracle databases being used as if they
> were sqlserver apps. One application, one schema, the instance is doing
> *absolutely nothing* and the server is suffocating.

Which is pretty clearly a bad idea. Fine.

> Or how about 6 different Oracle Financials instances (including several
> application servers) on one single *entry level* HP-UX server?

Dunno, could be bad, could be good. Are these test databases? Training databases? Or full-on production databases with high user loads? You see my point - the choice depends on the company's needs.

> Or how about 6 different databases with serveral application servers and
> Netscape server on a 16-cpu Solaris E6500?

Again, it totally depends. We have E6500's running 18 instances for 18 different databases. Guess what? It's OK, and perfectly reasonable because it suits our requirements quite nicely. Why? They're for training classes, so speed, backup/recovery, etc., aren't a priority. So, as you see, it totally depends on the company's needs.

> The databases are vastly overallocated, they absolutely do *zilch* and our
> monitors complain the server is memory-bound (there is 16!G of RAM in that
> system) and CPU-bound!

Sounds like *your* situtation requires a different architecture. But to insinuate that everyone else's needs mirror your own is what I took exception to in your original post.

> Do you still think you should locate about every different app in a
> different database?
> Come on!

Please, Sybrand, re-read what I wrote. I *never* suggested that anyone should locate "about every different app in a different database." That's ridiculous. I merely stated that there can be some perfectly reasonable justifications to do so, contraticting your original statement which said all apps for a single customer should go in one database and that there is "NO" reason to do otherwise. In fact, I distinctly wrote that the decision "totally depends on the particular needs of the company."

Examples:

• RMAN is an app. Should it's catalog be in the same database as production?
• Reporting databases. Should reporting users compete with production OLTP users?
• Testing databases. Should they run with production? If not, should you only have one?
• Training databases. Should every trainee have their own database?
• Should a company's email database be the same as it's CRM reporting database?
• Should a company's online trading database be the same as it's Human Resources database?
• Should a company's support database be the same as it's ERP database?

IT DEPENDS. Regards,
Sean Received on Thu May 02 2002 - 14:49:25 CDT