Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

2005 to 2008 R2 Migration Specs Expand / Collapse
Author
Message
Posted Monday, April 29, 2013 11:22 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:58 AM
Points: 97, Visits: 355
So I've been researching this, but can't get a clear how to on this. I just joined a new job and one of my first projects is to migrate a 2005 sql server to 2008. I need to give specs to my infrastructure guy for new environment.

We have an application running on Windows 2003 Box (4 processors, 4GB of ram) with SQL 2005 SP4. We are running on VM Ware with Net App. We need to get to Windows 2008 with SQL Server 2008 R2.

How do I determine Specs for the New Box. For example, how many CPU (and their speed), how much RAM, etc.

Is there a tutorial you guys can point me to?


------------
:)
Post #1447667
Posted Monday, April 29, 2013 2:45 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, July 24, 2014 10:24 AM
Points: 373, Visits: 1,235
There is no tutorial for that, because each application is different. And it is very hard to give a "cook recipe" or one quick answer.

You need to get a baseline of your existing environment. You can use perfmon or DMVs for that. Run it for a few days or a week, so you can get a better understanding of what resources your app uses most , etc.

A few important are:

-CPU usage
-RAM usage
-Disk latency (read and writes)
-Network utilization
-Page life expectancy (SQL instance level)

Just to mention a few.

So if you see that your server barely uses CPU over a one week period or more, you know that buying a powerful CPU won't be the best thing. On the other hand, if you see that your apps use a lot of RAM, you know that putting enough RAM would be critical.

Also, please keep in mind that SQL running on VMware is different than running on a regular an physical server, as VMware manages CPU and RAM for the actual guest. As a matter of fact, getting perfmon from a VMware machine can be misleading, as CPU and RAM are just an abstraction of the real stuff. If that's the case, ask your VMware guy for the virtual machine metrics, like CPU, RAM, disk latency, etc, so you can get an idea of how much workload you have right now on that virtual machine.
Post #1447778
Posted Tuesday, April 30, 2013 3:32 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, June 16, 2014 8:52 AM
Points: 51, Visits: 398
It is very easy to get caught up in trying to come up with a perfect spec, but it is rarely worth the time since you are running a virtual machine where
resources can be added fairly easy. I would not spend weeks of looking at a billion metrics because it is a very complex job to convert all that into a spec
that will basically say 2-4 cores with x amount of RAM.

If I understood you correctly your SQL 2005 is virtual today, just get a couple of reports from your vmware admin where you can see IO/Memory/CPU usage
for that VM. Have a look at past week, past month and so on.

Run the 2005 Performance Dashboard report and have a look at the IO, it will display which databases use the most IO.
The databases that show up in this report with a high % are likely those you have be a little cautious with.
Very very often the performance of the server is used by databases where bad indexing causes high IO % figures, not solved by adding hardware.
Do the same for expensive queries regarding cpu.
(Remember that info above is only since last restart)

Have a look which databases use the most of your buffer mem, you can schedule below code during the day just
and it will tell you which one of your db's are "agressive" on the mem.
SELECT DB_NAME(database_id) AS [Database Name],
COUNT(*) * 8/1024.0 AS [Cached Size (MB)]
FROM sys.dm_os_buffer_descriptors
WHERE database_id > 4 -- system databases
AND database_id <> 32767 -- ResourceDB
GROUP BY DB_NAME(database_id)
ORDER BY [Cached Size (MB)] DESC;

But basically I would spec out a machine that is better than you have today (not more cores, four are "probably" enough, a lot of cores in a vm can be a pain).
Add as much memory you can get a hold of.

Start migrating your databases one by one and monitor your new server. And if your spec doesn't hold upp, adjust it accordingly as you go.
That will probably be easiest way to get started.
Post #1447931
Posted Tuesday, April 30, 2013 7:03 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:58 AM
Points: 97, Visits: 355
Thank you both of you. It's really good information.

I have been reading about running Perfmon data, but then yesterday I figured out that it doesn't really apply here because of VM environment.

I'll post here my process after I'm done with specs. :)


------------
:)
Post #1448003
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse