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)