Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2004

    Unanswered: Question on DB2 9.7 LUW

    Running DB2 9.7 LUW on AIX and Red Hat Linux.

    I am asking for thoughts on architecting this environment going forward.
    Most of my background has been with huge OLTP and EDW databases with mostly a 1 or 2 databases to one instance configuration.
    So this is very different for me.

    Taking a new job I inherited the following:

    Dev - 1 server 9 instances with a total of 32 databases
    QA - 1 server 9 instances with a total of 25 databases
    Prod - 1 server 9 instances with a total of 23 databases

    Thats 27 instances with a total of 90 databases

    Most of these databases, except one in each environment, are small metadata databases with backup in seconds and minutes.

    I am supposed to reduce the number of (virtual) servers we use. Reconfiguring the number of instances and databases per instance is fine.

    Would you consider putting all 90 databases on one server? Ok stupid question but as I said, this type of configuration is totally alien to me.


  2. #2
    Join Date
    May 2010
    Provided Answers: 2
    * You can combine QA and DEV to single server. I prefer to keep PROD on separate server (separate physical server) and do not want to keep DEV or QA on PROD server.

    * If there is no special requirement from applications, it is better to use single instance per environment, single database per instance. More number of instances and more number of databases is going to make memory management and database administration difficult. Check the possibility of reducing number of databases and instances.

  3. #3
    Join Date
    May 2012
    Canberra, Australia
    Provided Answers: 6
    We were running similar configs for Websphere and other bits and pieces for one of the clients when I was at IBM. Multiple instances and multiple databases per instance - I think we reached 13 instances with about six dbs per instance on the lower envs. They went a bit crazy with what they wanted in my opinion but, hey, they were paying for it! It worked ok as it was the same deal, all small metadata dbs.

    "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use hammer.” — IBM maintenance manual, 1975 "

  4. #4
    Join Date
    Aug 2008
    Some other factors:
    1)What are the security requirements? One of the reasons to maintain separate instances is security controls
    2)Scripting all the steps helps - as you can quickly rebuild \ or build new environment
    3)Identifying resource requirements and matching them to the resources presented by the VM and IO subsystem

    As a DBA working with Agile developers - I've noticed a requirement for sandboxing - and the necessity to spin up environments quickly, and segregated

Posting Permissions

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