SQL Server 2005 SE slow and not using resources

  • I am working with a 4GB database and a series of complex queries in a SQL Server 2005 SE environment.

    Currently SQL server runs on a dedicated virtual machine with Windows Server 2003 R2 Std and 4GB of memory. Analysis services runs on a separate VM and the application runs on a third.

    Using a VM for SQL server was planned as a temporary step in our deployment plan and I now have a physical machine available. The new machine has been configured with Windows Server 2003 R2 Enterprize and sports a dual core CPU with 8GB of memory. As with the current VM, we are still running SQL Server 2005 SE and it is the only application running on the new system.

    I copied my database to the new system, executed one of my more complex views and was rather shocked with the performance. Where the VM configuration completes the query consistently in about 6 minutes, the new system with twice the resources is taking more than an hour.

    I have monitored the system using the task manager and performance monitor. The VM never consumes more than a nominal 50% of the CPU (single core). The new machine never consumes more than a nominal 25% of the available CPU (dual core). Memory usage on the VM climbs to over 2.5GB. on the new machine (with twice the memory) memory use never goes beyond about 850MB. Disk loading isn't an issue on either system.

    I have added the /3GB switch to the VM and /3GB /PAE switches to the new system.

    Obviously I'm missing something. Can anyone point me in the right direction?

    Bob

  • Check the execution plans on both the VM and the physical server and see what is different. This could be a case where the dual-core physical machine is getting a parallelized execution plan that is causing issues. If you have any questions once you look at the execution plans, post the questions here and attach the graphical execution plans to the thread.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply