November 15, 2010 at 8:24 am
We are planning to migrate from SharePoint 2007 to SP 2010, and migrate the SharePoint databases from SQL 2005 to SQL 2008. Ideally we would like to move the SharePoint databases to our SQL 2008 cluster, which currently runs about 40 databases (= user 25 applications and IS admin tools). Obviously, we would like to use the existing SQL 2008 cluster if possible (zero cost). A VM server would be second option and new physical servers our third (and most expensive) option. We use an IpStor SAN for the disks, so regardless which option we choose the storage side will be the same.
Are there any disadvantages to mixing SharePoint databases with non-SharePoint databases? (outside of any performance-related issues) i.e. administrative issues, troubleshooting issues, etc.
How to go about estimating the performance of combining SharePoint with the existing SQL 2008 cluster? (or a VM server) Are there certain performance counters to be primarily concerned with?
I'm currently monitoring (on both servers):
% processor time (total)
% processor time (sqlservr.exe)
avg disk queue length (logs and data drives)
available memory
page faults/sec
buffer cache hit ratio
page life expectancy
full scans/sec
lock requests/sec
Considering that the SharePoint server is a 5+ year old server and the SQL 2008 cluster is about 1 year old, there are significant improvements in the hardware alone. The SharePoint server has 2xCPUs, quad-cores (8 virtual CPUs) and the SQL 2008 cluster has 2xCPUs, quad-core hyperthreaded so 16 virtual CPUs. My assumption for CPU load is that, all things being equal or better on the SQL 2008 cluster, that an average 15% CPU utilization on the old server will translate to maybe half that on the new server. Am I wrong to assume that?
It's difficult to determine what to look at and how accurate the estimations may be. There is no possibility to put this on an identical test system due to the capacity. The risk is that once moved onto the cluster, we may experience performance problems with the other database applications, or with SharePoint, or both. Need to minimize this risk as mush as possible.
Any thoughts/ideas on how to go about this as accurately as possible?
THANKS!
November 15, 2010 at 1:20 pm
i would not install Sharepoint into a shared instance for one reason. the account that is used to install Sharepoint must be given elevated priveldges the the instance. You will also need to define a service account that will "run" sharepoint. It will be called the "Database access account". That account will need to be a admin on any server Sharepoint touches. In a shared farm, i would only do that on a seperate instance so not to interfere with the other DB's....
November 16, 2010 at 12:15 am
good point but the service account issue should not be a problem. we're using the same service account currently on both servers (SharePoint and SQL 2008 cluster) so the end result is the same.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply