Re: One vs many databases

Originally posted by Shridned
> I never understood why somebody sensible with technical know how,
> would like many databases instead of one.
>

Lets just assume some sensible people have technical know-how...

Personally, I subscribe to the theory that functionally seperate systems should be kept in seperate databases. First and foremost, having your OLTP systems on different databases than your OLAP systems allows you to tune them differently. Maybe on your OLAP database you need the _complex_view_merging=true in the init.ora and on your OLTP systems you don't.

In addition, your systems may have different backup/recovery requirements. Maybe the business dictates the Datawarehouse is backed up once a month after the data load and the OLTP databases are backed up every 6 hours.

>
>
> I have seen a billing system of a big telecom company
> they made a seperate database for every big table, call the crap
> "distributed databases, this is cool" and it is very good,
> very good in employing 100 dba and up to now produced 1 billion
> euro cost.
>
>

I'll agree, that's not a great idea.

>
> so the answer to this is "someone sensible and knowledgeable " would
> never prefer many databases instead of one.
>
> the only reason for many databases the usage of standard
> software which
> forces you to seperate your databases and use different oracle
> versions.
>

OK, that's another good reason.

>
> but with home made software the best this is to integrate
> everything into
> one big
> db with 9.2 and make some standby databases on different places to
> protect it
>
> sometimes people tell you, if the thing is to big it is difficult
> to manage.
> but this people have no real oracle knowledge , at how much more
> difficult
> is
> it to manage seperate databases instead of one.
>
> for the problems with big data volumes we have today big hardware
> and I used
>

Hey, in a world with unlimited budgets, that's great. However, back here in the real world your budget might dictate you only get $300K to run a database for 1000 users.

>
> a technique to seperate the historical data through
> partitioning into a
> seperate
> partition and used the compress option in 9.2 and sorted it to
> "compress"
> it.
> but logical it stays in the same table and everything is simple
>
> people told me the historical data needs to be in a seperate database
> to keep the working database "fast" but this is also nonsense. If
> you need
> the data keep it in the primary database and organize it well,
> as I did.
> I you don't need it remove it.
>
> Ask this question Thomas Kyte from Oracle and he will tell you
> the same.
> He is one of the few Oracle authorities from which you really
> can learn,
> most people in this area have no real knowledge from modern
> system management. they only want to keep their job and make it as
> difficult as possible, like this people telling you to reorganize
> database,
> indexes ...
>
>

If that's what TK says, then it carries a lot of weight with me. However, this would be the one time I disagree with him.

>
> Also if it is really necessary you can use RAC to use many
> servers for one
> big database, it is still much more simpler than many databases
> because
> logical you have only one, but only if you really need it.
>
> "John Hunter" schrieb im Newsbeitrag
> news:qufR9.3254$Hs3.402088_at_ursa-nb00s0.nbnet.nb.ca"]news:qufR9.-
> 3254$Hs3.402088_at_ursa-nb00s0.nbnet.nb.ca[/url]...
> > Hi Gang,
> > I'm looking at submitting a business case to management that
> will justify
> > changing from our current structure of many oracle databases to
> one big
> > database. We currently run many separate databases (financial,
> sales,
> > purchases etc...) all based on functional areas. These are all
> inhouse
> > written systems. My problem with having all these instances is
> with
> trying
> > to link data together. We need to have realtime data shared
> amonst the
> > systems. Dblinks are quite slow and although materialized views
> have lots
> > to offer they consume a fair amount of overhead.
> > Anyway, I've done some web searches looking for the pros and
> cons of many
> > instances vs. one instance and have yet to find a good
> whitepaper on this
> > subject. I did read through the long (70 or so posts) when
> someone said
> they
> > were going to install 50 instances on one host, but it didn't
> really
> answer
> > the question.
> > Thanks,
> -John

--
Posted via http://dbforums.com