[AccessD] WAY OT: Brains Trust Q - Slow SQL Server 2005

Darren D darren at activebilling.com.au
Tue Nov 18 18:32:58 CST 2008


Hi Team

Thanks for all the replies

Allocated 3 gig to the VM Session and it made a world of difference.
Strangely when we reverted to 2 GIG the performance did decrease but not to the
point it was at the other day. 

Sadly in the meantime there was a re-boot of the server with MS Updates
installed in the shutdown - So I have no clue what they were or what they did
(If anything) - But the increase in RAM did make a big difference

Bruce and Gustav I'm told that it is a 'real' VM Server not the desktop thing.
Bruce I am interested in the comments about network passthroughs - Do you have
any more information?

It was a business decision to go with SQL server - made above my head and before
my time

Many thanks
 
Darren

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Tuesday, 18 November 2008 11:58 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] WAY OT: Brains Trust Q - Slow SQL Server 2005

First thing I'd look at is the amount of memory you have allocated for your VM.

Running SQL Server on Windows Server, you'll need at least a couple of Gigs of
memory 
dedicated to it.

On 18 Nov 2008 at 11:31, Darren D wrote:

> Hi All
> 
> Please forgive the WAY OT Post but I need access to the Brains trust and I
know
> a lot of you are SQL/VMWare gurus
> 
> As this is a way OT post - feel free to respond to me off line to: darren at
> activebilling dot com dot au
> 
> Moderators feel free to tell me to take it away
> 
>  
> 
> We have a Dell server running Linux as the OS (Running Ubuntu I think)
> 
> On this Linux server we have a VM Session running Windows Server as the OS
> 
> On this VM Session we have our instance of SQL Server 2005 - And it is running
> like a slug.
> 
>  
> 
> For instance - We copied a live and running SQL 2000 dB onto this SQL 2005
setup
> and started running comparisons against each on a large table and the results
> were awful. 
> 
> We started connecting our app to it as well and the results were even worse
> (About 12 minutes to open a relatively simple screen) 
> 
> Whereas the same app connected to the live and running SQL 2000 version runs
as
> expected 
> 
>  
> 
> Can anyone advise if this multi layer OS/VM Setup is the likely culprit for
the
> go slow? 
> 
> Does anyone know of sure fire things to change and even some things to try or
> gotchas?
> 
> Also do we know of any analyser tools that we could test the Linux/VM Session
> config to see if that level is the culprit before we dig into the SQL 2005
> setup?
> 
> And anything else you can recommend
> 
>  
> 
> Many many questions -
> 
>  
> 
> Thanks heaps in advance team - Apologies again for the OT :-)
> 
>  
> 
> DD
> 
>  
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list