• runal_jagtap (4/17/2013)


    DB movement activity on cluster server...

    What are do's n dont's???

    The Cluster environment is well set & operational..

    So Only Moving DB's to this environment will do???

    What do you mean with "db move", exactly? Migrating a database from another SQL instance to the Cluster ?

    If that's the case, there are several steps you need to take, plus lot of test for your application. These are not exhaustive , but some of them and what I usually do:

    -Backup your database before the move (obvious, but some people don't do it or forget)

    -Restore the database on the SQL failover instance

    -Change compatibility mode (if old database is lower, like SQL2005, for example)

    -Reset logins / SIDs

    -Schedule new backups, for the new database

    -Schedule maintenance plans: ReIndex, Integrity Checks.

    -Leave old one on read only mode. Delete after a week or so

    -Test connectivity, point your app to the new database

    I would also recommend do a small test for your application. Some applications do not do well during a failover. So you may test that. But if the environment is live and you have database there already, that may be difficult to do.

    I also refresh the statistics, but I think that's not needed if you are moving from SQL2005 to SQL2008.

    -- What I usually DO NOT DO --

    -Delete old database after the move

    This is because if there are permissions issues, or a store procedure that does not run, it is easier to troubleshoot and see what's wrong if the old database is still on the other server.

    -De-attach and attach

    Some people also de-attach , move the mdf and ldf files, and attach on new server, I do not recommend that. We loss statistics I believe, and the database is no longer available on old server (see my previous point)