Post reply

SQL Consolidation

  • April 12, 2012 at 4:15 am

    #267308

    Dear all,

    I'm working on a SQL Server consolidation. There are 2 SQL Server installation (with DR, no HA). One SQL 2000 server and one SQL 2005 server.

    The SQL 2000 has one instance with 35 databases and the SQL 2005 has one instance with 42 databases. More than 100Databases. There are databases for various applications like sharepoint, vcenter, wsus, scan/fax systems, dedicated, own made and discontinued applications. There are databases for dev/test/acc/prod environnements.

    SQL 2000 database size (total): 11,5Gb

    SQL 2005 database size (total): 122Gb

    Total: 133Gb

    Total for Log: 13Gb

    As you see this is more a bin of database than a database server.

    First thing, I will separate the environement: DEV/TEST/ACC/PROD and win 17 databases.

    Still have 64 databases in production.

    There are not big databases but many small and medium databases. They are currently no ressources problem on servers.

    The new DBMS will be SQL 2008 R2. HA and DR will be implemented with geocluster/san replication, but this is not the issue currently.

    I think about only one instance, because I will no create 64 instances (...). But maybe is it better to create group of databses in instances ? Instance for Sharepoint, Instance for VCenter, Instance for own made applications, instances for ... ?

    Could you give me advise on this solution for a non-standard SQL server installation.

    Regards,

  • April 13, 2012 at 5:00 am

    #1473137

    Firstly run upgrade advisor to make sure all of your applications are going to be compatible with SQL 2008r2.

    There are many things to consider when deciding on instances for consolidation, at a high level I would consider the following Security, split mixed mode and windows authentication, consider what server level rights you need to give to different groups of users, business confidence, if you have sensitive date on any instances keep these separate, resources you can restrict memory, cpu usage at instance level so don't put your 'greedy' database on the same instance as something that is business critical. There are many more things that i'm sure others would add...

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply