August 3, 2009 at 11:21 am
Hello,
I am trying to setup MS SQL Server 2005 SP3 on a Windows 2003 32-bit OS. This server has 16GB of memory. I am running OS with /PAE flag. I also configured SQL Server with AWE. I am not sure why it takes 80% more time to restore the same database that I can restore on a SQL Server that only has 4GB RAM. Also, during and after restoring the database system becomes sluggish. Every thing is slow to response from opening up "Task Mananger" to trying to browse to files. When I look at the Task Manager, the memory usage is about 600MB.
I have set AWE check box, minimum and maximum memory for the SQL Server.
I have SQL Database engine running under "Local System" account but "Lock pages in Memory" is running as Administrator.
Does anyone know what I need to do to make SQL 2005 work with memory available?
Thanks,
fanzi
August 3, 2009 at 12:11 pm
I would think your restore times have more to do with I/O than with memory. Are the disks you are restoring to the same as the other server with 4 gbs. Same RAID types? Use windows perf mon to check your average disk queue length. If it is waiting there it sounds like i/o is your bottleneck.
Mike McNeer
August 3, 2009 at 12:15 pm
Yep, restores are all about the I/O, and possibly network if you are restoring across a network.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
August 12, 2009 at 7:27 pm
Yep you guys are right. I found there is something strange going on. I have a HP blade server connected to EVA 8000 SAN drive. Looks like there is some issue there. I am using windows 2003 server 32-bit and SQL 2005 32-bit.
When I use blade server that has 64-bit 2008 server with SQL 2005 32-bit, restore to SAN LUN works perfectly.
Any suggestions why 32-bit version will have I/O issue with SAN.
Thanks,
August 13, 2009 at 6:34 am
The problem is most likely nothing to do with 32-bit or 64-bit, but wher your data is within the SAN. Each of your servers will have its data located at different places within the SAN.
It is worth talking to your SAN administrator so they can to some monitoring while you run your problem erstore. This may show some IO hotspots within the SAN that they can deal with.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply