Professional Web Applications Themes

One vs many databases - Oracle Server

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 ...

  1. #1

    Default One vs many databases

    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




    John Hunter Guest

  2. #2

    Default Re: One vs many databases

    I never understood why somebody sensible with technical know how,
    would like many databases instead of one.

    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.

    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.

    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
    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 ...

    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" <jthunternbnet.nospam.nb.ca> schrieb im Newsbeitrag
    news:qufR9.3254$Hs3.402088ursa-nb00s0.nbnet.nb.ca...
    > 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
    >
    >
    >
    >

    shridned Guest

  3. #3

    Default Re: One vs many databases

    These are a few of my considerations

    Don't store applications in one database that don't have anything in common:
    a. when upgrading both applications must upgrade at the same time
    b. maintenance for one application (where you really want to close access to
    the db completely) could imply unnecessary downtime for the other
    application
    c. when the database needs to be restored completely (because one
    application ed up the data in a yearly batch or so or block corruptions
    occur and the db runs in noarchivelog mode) the other applications loose
    data too.
    Not that these cirstances occur a lot but...

    Store applications in one database when they share data (tion,
    database links) or are closely related in a way.
    a. makes recovery scenarios easier. If in multiple db's an incomplete
    recovery of one of them implies a restore of other db's too to keep the data
    consistent between applications.
    b. can only be done when all object names in the applications are unique
    (or: this is a chance to make one copy of that table that both applications
    share).
    c. be sure the have solid authorisation setup and procedures in place to
    prevent unwanted access to data of other applications in the db.

    John Hunter <jthunternbnet.nospam.nb.ca> schreef in berichtnieuws
    qufR9.3254$Hs3.402088ursa-nb00s0.nbnet.nb.ca...
    | 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
    |
    |
    |
    |

    Anton Buijs Guest

  4. #4

    Default Re: One vs many databases


    "Karsten Farrell" <kfarrellbelgariad.com> wrote in message
    news:trjR9.1308$Iy4.104463592newssvr17.news.prodi gy.com...
    > John Hunter wrote:
    > > 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
    >
    > IMHO there isn't one - and only one - clear answer to this question.
    > There are a lot of pros and cons - not all of which are technical. Some
    > are simply the way things are in the company and no one is going to set
    > aside a pot of money to fix. I don't think other shops have our
    > requirements ... so what I say is very site-specific ... YMMV.
    >
    > For example, we keep our data warehouse in a separate database because
    > it has vastly different resource requirements (in SGA size, batch
    > reports, inelegant user-defined ad-hoc queries, etc). We also have a
    > bunch of formerly unused NT workstations that were sitting around with
    > nothing to do, but that do quite nicely with "departmental" databases
    > (that is, databases that don't need a lot of data from other databases).
    > Management didn't want to see them idle. We also have some databases
    > that don't need to be backed up ... and ones that we'd have our fingers
    > chopped off if we didn't. Setting up RMAN scripts to back up only the
    > pieces we want of a single, large db might be more difficult than
    > setting up RMAN scripts only for a few small, whole databases.
    >
    > If you have an unlimited budget in your company, then go for the big RAC
    > database on a SAN. Kinda reminds me of all the arguments 30 years ago
    > when we were considering switching from the big iron mainframes to DEC
    > VAXen minicomputers. It was almost a religious war between the folks on
    > the single or multiple side of the fence. Now, our Sun box with a couple
    > dozen CPUs can really handle the database we did decide to make "big."
    >
    IMHO there is one - and only one - clear answer to this question.
    It depends.

    (Sorry, couldn't resist) :-)

    Regards,
    Paul



    Paul Brewer Guest

  5. #5

    Default 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.402088ursa-nb00s0.nbnet.nb.ca"]news:qufR9.-
    > 3254$Hs3.402088ursa-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 [url]http://dbforums.com[/url]
    marist89 Guest

  6. #6

    Default Re: One vs many databases


    "Anton Buijs" <aammbuijsxs4all.nl> wrote
    > These are a few of my considerations
    >
    > Don't store applications in one database that don't have anything in
    common:
    > a. when upgrading both applications must upgrade at the same time
    > b. maintenance for one application (where you really want to close access
    to
    > the db completely) could imply unnecessary downtime for the other
    > application
    > c. when the database needs to be restored completely (because one
    > application ed up the data in a yearly batch or so or block
    corruptions
    > occur and the db runs in noarchivelog mode) the other applications loose
    > data too.
    I'd add one more - if the application has more than one occurrence, each one
    should have a separate database (e.g. if both a division and corporate
    headquarters run independent copies of Oracle Financials).


    J Alex Guest

  7. #7

    Default Re: One vs many databases

    hmmm wrong thread i think


    "Anton Buijs" <aammbuijsxs4all.nl> wrote in message
    news:3e15e1cb$0$49111$e4fe514cnews.xs4all.nl...
    > These are a few of my considerations
    >
    > Don't store applications in one database that don't have anything in
    common:
    > a. when upgrading both applications must upgrade at the same time
    > b. maintenance for one application (where you really want to close access
    to
    > the db completely) could imply unnecessary downtime for the other
    > application
    > c. when the database needs to be restored completely (because one
    > application ed up the data in a yearly batch or so or block
    corruptions
    > occur and the db runs in noarchivelog mode) the other applications loose
    > data too.
    > Not that these cirstances occur a lot but...
    >
    > Store applications in one database when they share data (tion,
    > database links) or are closely related in a way.
    > a. makes recovery scenarios easier. If in multiple db's an incomplete
    > recovery of one of them implies a restore of other db's too to keep the
    data
    > consistent between applications.
    > b. can only be done when all object names in the applications are unique
    > (or: this is a chance to make one copy of that table that both
    applications
    > share).
    > c. be sure the have solid authorisation setup and procedures in place to
    > prevent unwanted access to data of other applications in the db.
    >
    > John Hunter <jthunternbnet.nospam.nb.ca> schreef in berichtnieuws
    > qufR9.3254$Hs3.402088ursa-nb00s0.nbnet.nb.ca...
    > | 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
    > |
    > |
    > |
    > |
    >

    David Sharples Guest

  8. #8

    Default Re: One vs many databases

    what do you think he does all day then?

    "Pablo Sanchez" <pablodev.null> wrote in message
    news:Xns92F8D10C06C20pingottpingottbah209.242.64. 107...
    > marist89 <member15835dbforums.com> wrote in
    > news:2344964.1041630637dbforums.com:
    >
    > >
    > >> 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.
    >
    > I would have to guess that Thomas has been misunderstood because as
    > you point out, it simply makes good common operational sense to house
    > data separately when the business demands it.
    >
    > btw, as near as I can tell, I do _not_ believe that Thomas has been
    > doing any operational work in recent years. *smirk* I'll let Thomas
    > answer that one ... <g>
    > --
    > Pablo Sanchez, High-Performance Database Engineering
    > [url]http://www.hpdbe.com[/url]

    David Sharples Guest

  9. #9

    Default Re: One vs many databases

    There's a limit where "many" is "too much". But if we're talking about a
    handful of systems, it may make sense to house them in separate
    databases. There's no simple answer. The way the original question was
    posted, I don't think any of us know enough about John's systems to use
    "never" or "always" in our replies.

    If the applications are different in their resource requirements, a good
    way to protect one application from the other's work cycle is to
    separate them. Otherwise you'll spend the rest of your life apologizing
    for payroll running slow whenever your accounting dept is reporting on
    the general ledger.

    You can tune some databases for OLTP (say, help desk, PO) and others for
    batch (payroll, accounting).

    Furthermore, if you have a corrupted SYSTEM tablespace, only one of your
    databases needs recovery. It's the difference between any DBA task
    affecting 10% of the company versus affecting the whole company.

    Sometimes I find it much easier to manage a few databases than just one
    (again, there's a number where "a few" is "too much"). Because if you
    have all your systems in one database, a single bad-performing query can
    generate two dozen phone calls. To your extension.

    In a way, DBAs also have to manage people's fears and expectations. The
    best DBAs I know take the time to keep their users (the real owners of
    the databases) appraised of all problems, issues and trends. And this is
    a much easier thing to do if you don't have to broadcast every single
    problem to the whole company.



    shridned wrote:
    > I never understood why somebody sensible with technical know how,
    > would like many databases instead of one.
    >
    > 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.
    >
    > 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.
    >
    > 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
    > 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 ...
    >
    > 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" <jthunternbnet.nospam.nb.ca> schrieb im Newsbeitrag
    > news:qufR9.3254$Hs3.402088ursa-nb00s0.nbnet.nb.ca...
    >
    >>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
    >>
    >>
    >>
    >>
    >
    >
    >
    Wanderley Guest

  10. #10

    Default Re: One vs many databases

    Wanderley wrote:
    > There's a limit where "many" is "too much". But if we're talking about a
    > handful of systems, it may make sense to house them in separate
    > databases. There's no simple answer. The way the original question was
    > posted, I don't think any of us know enough about John's systems to use
    > "never" or "always" in our replies.
    >
    > If the applications are different in their resource requirements, a good
    > way to protect one application from the other's work cycle is to
    > separate them. Otherwise you'll spend the rest of your life apologizing
    > for payroll running slow whenever your accounting dept is reporting on
    > the general ledger.
    >
    > You can tune some databases for OLTP (say, help desk, PO) and others for
    > batch (payroll, accounting).
    >
    > Furthermore, if you have a corrupted SYSTEM tablespace, only one of your
    > databases needs recovery. It's the difference between any DBA task
    > affecting 10% of the company versus affecting the whole company.
    >
    > Sometimes I find it much easier to manage a few databases than just one
    > (again, there's a number where "a few" is "too much"). Because if you
    > have all your systems in one database, a single bad-performing query can
    > generate two dozen phone calls. To your extension.
    >
    > In a way, DBAs also have to manage people's fears and expectations. The
    > best DBAs I know take the time to keep their users (the real owners of
    > the databases) appraised of all problems, issues and trends. And this is
    > a much easier thing to do if you don't have to broadcast every single
    > problem to the whole company.
    >
    > shridned wrote:
    > > I never understood why somebody sensible with technical know how,
    > > would like many databases instead of one.
    > >
    > > 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.
    > >
    > > 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.
    > >
    > > 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
    > > 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 ...
    > >
    > > 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" <jthunternbnet.nospam.nb.ca> schrieb im Newsbeitrag
    > > news:qufR9.3254$Hs3.402088ursa-nb00s0.nbnet.nb.ca...
    > >
    > >>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
    > >>
    > >>
    > >>
    > >>
    > >
    > >
    > >
    I've stayed out of this discussion so far because I'm in favor of the "it
    depends" point-of-view. But one thing that is missing, so far, from this
    discussion is the question of hardware.

    Without knowing how these things are spread out across multiple servers the
    number of applications per database is not easy to recommend one way or the
    other.

    If I assume 10 apps in 10 databases and they are on one machine that has a value
    far different from 10 apps in 10 databases on 10 separate servers.

    To make a recommendation, I think, requires knowing the resource requirements of
    the different apps, their interdependencies, their upgrade cycles, and the
    availability of hardware.

    Daniel Morgan

    DA Morgan Guest

Similar Threads

  1. databases
    By max in forum ASP.NET Web Services
    Replies: 8
    Last Post: October 21st, 05:22 PM
  2. ASP & Databases
    By McKirahan in forum ASP Database
    Replies: 7
    Last Post: April 11th, 08:31 AM
  3. [PHP] Databases
    By Duncan Hill in forum PHP Development
    Replies: 1
    Last Post: September 25th, 09:48 AM
  4. PHP and databases
    By Craig in forum PHP Development
    Replies: 5
    Last Post: August 21st, 07:59 AM
  5. Federated Databases, joins across databases etc
    By Benjamin Stewart in forum IBM DB2
    Replies: 2
    Last Post: August 1st, 03:05 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139