1

We have a situation where one of our database approx. 60 GB in size with transactions running every 2-3 mins 24*7 has to be moved, since the server it is on is going to be decommissioned.

Now, we cannot upgrade the above server to a different environment as its application is compatible with that particular env.

Now, we have 3 similar env, where we thought of migrating this database to. But the challenge is all these 3 exiting DB servers are heavily used. They also have process like transactional replication and log shipping set on them as well. Those servers are all on windows 2003 with SQL 2K5 running on them. I know this should have been upgraded , but for now we want to stick is application does not support the upgrade.

Please suggest from you're experience what can be done here? Should we think to migrate that DB on those heavy servers, using some analysis as moving may require additional storage and CPU or RAM. Or will it be better to cancel the decommission and let that DB reside there?

Edit: I am just looking for recommendations on how to calculate/make a process to meet those parameters say, X amount of RAM/CPU/Storage will be needed if I am going with option of moving the database on the heavy loaded servers

  • 1
    I'm not sure there is a question here to answer. You can only be provided with the options you have already outlined yourself, namely a) Keep things as they are and don't decommission the existing server or b) Verify that the alternative server can take the load of a new database and migrate it in, and be prepared to upgrade server components if not. – Molenpad Jul 5 '16 at 15:35
  • @Molenpad, I just edited the question . This may not be that technical of a question related to any issue, but its more of how to make that judgement of what parameters or values can conclude what we need to migrate on those loaded servers? – BeginnerDBA Jul 5 '16 at 16:00
  • Find out the current average I/O, CPU, and memory usage on the existing server while under a heavy load. Do the same for the proposed target server. Now find out what your proposed target server can accommodate. Simple math will tell you if the new server has enough spare capacity. I suggest, however, that you trust your instincts on this one. Moving a heavy load onto an already loaded server is a disaster waiting to happen. – datagod Jul 5 '16 at 16:17
0

A couple of transactions running every 2-3 minutes and a 60GB database is pretty light IMHO and shouldn't add much load to an existing instance unless it's at the edge of it's capacity.

A couple of quick questions to take into account. You are just moving the database not creating a new instance on the "heavily used" machines correct? On the old instance is this the only database?

I would check RAM/CPU usage on each server. Pick the lowest usage instance of the three and compare that to the usage on the old instance. Remember that the CPU/RAM usage for an instance is more than just that for the database (even if it's the only user DB on the instance). Also that SQL is pretty good at managing multiple databases/workloads.

In the end your best bet is going to be to use a development machine, make a copy of the database there and load test. If everything goes well there then move to the lowest use old instance.

If you have the option to add CPU/RAM to the newer servers then that will be a nice safety net. Move the DB and monitor. If it needs more memory add it, more CPU add that.

| improve this answer | |
  • Thanks @Kenneth for the suggestions. Yes I will be just moving a single database on the existing instance. Also on the old instance this is the major DB in use while remaining couple of databases are merely in 100 MB's in size – BeginnerDBA Jul 5 '16 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.