August 7, 2008 at 8:33 am
We have two production servers. We have just purchased a SAN and two new boxes and have restored backup datafiles from the current production environment to the new servers. We hope that the switch to the newer system will give a bit of a performance burst as well as an opportunity to reconfigure and clean up the system before turning it over.
I have two questions.
I am aware that the replicated msdb could cause problems if our (disabled) sql agents are started up on either of the new servers. Should there be any other issues I need to be aware of before we point an application server or two to the new servers for testing? We are looking to prevent cross production data contamination.
A second question. On the SQL Server level, both machines are the same, but on the OS level (Server 2003) , our new servers are patch up to the max but the old servers, being that they are 24 X 7 are missing a huge chunk of patches according to WINAUDIT.exe when we do a compare. Does anyone have knowledge of any gotchas where OS patches have broken applications running or using SQL Server 2005?
Thanks
August 7, 2008 at 8:49 am
Do you have the luxury of renaming the two new machines, and their IP address to the same as the originals? Thats what I've done in the past and had no issues, didn't have to change any application data sources, all jobs in msdb came to life, etc. Made my life a whole lot easier. Of course the two original servers would have to be taken off the wire first. After the switch to the new servers with the original server names and IP, rename the original servers to something else (again, both name and IP) and bring them back up on the wire. Done.
-- You can't be late until you show up.
August 7, 2008 at 9:07 am
That is what we intend to do when we go productional. Turn off the old, turn on the new after renaming the boxes and assigning IP address.
One issue we encountered in another upgrade, is several DDL located in a user's folder were needed (to be registered) and it took a lot to find, which we did quite accidentally) and the exposure caused was a negative reflection on our department.
As for the OS upgrade/patch levels, I omitted an important detail, that our old servers are 32 bits and the new servers are 64 bits.
August 7, 2008 at 9:27 am
Sorry, no experience on 64 bit (I assume that's what you mean), only 32 bit (I assume that's what you mean, also 😀 ). As far as user DLLs, I'm guessing you're running more that SQL on the box. If you're installing other software, you should've gotten the DLLs installed properly. Or are you simply copying user folders to the new server? That'll lead to the issues you had before with them possibly not all being registered. That's trial and error, not an approach that I'd be comfortable with on a production server - but that's just me.....
-- You can't be late until you show up.
August 7, 2008 at 1:35 pm
32/64 bit was what I meant (Don't know what I was thinking).
The four DLLs found on the other conversion went to an encryption package called from SQL Server in one of the procs. For our current conversion, we have already begun pointing test application servers to the new boxes, and once we are happy that it is working as expected, we will release it to our QA group for testing. Only as jobs fail are we bring folders and content over to hook in.
Thanks for your help.
August 7, 2008 at 1:38 pm
Sounds like a good plan. Good luck.
-- You can't be late until you show up.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply