Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SQL Server - High Performance Disk Subsystem
Message
De
22/03/2008 02:57:38
Al Doman (En ligne)
M3 Enterprises Inc.
North Vancouver, Colombie Britannique, Canada
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Client/serveur
Titre:
SQL Server - High Performance Disk Subsystem
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows Server 2003
Divers
Thread ID:
01304529
Message ID:
01304529
Vues:
85
I have a client running SAP Business One 2007 (SBO) on their LAN, with about 15 active workstations. SBO is "nominally" a client/server app, with a .Net 2.0 client running against a SQL Server 2005 backend.

I say "nominally", because according to the top guru at the VAR who put everything together, SBO is architected like a VFP app - queries suck tons of raw data across the wire to workstations, which process them locally, then return updates to the back end as required.

The server is currently a Dell PowerEdge 1800 w/two dual-core Xeons, 4GB RAM and 5x 15K SCSI hard drives on a PERC4/SC controller in a RAID5 array. There is only one logical volume, C:. This server is dedicated to SQL Server, running 32-bit W2K3 R2 and 32-bit SQL Server 2005. At time of purchase it was thought by everyone that this server would be more than adequate to support the user load.

Pretty much from day 1, my client has been experiencing SBO crashes on the workstations, apparently caused by "timeouts" waiting for data from the backend. The VAR is now saying my client needs to upgrade to a high performance disk subsystem. They're recommending:

- 4 disks in RAID10 for Windows and the swap file ( C: )
- 2 disks in RAID1 for SQL Server logs ( D: )
- 4 disks in RAID10 for SQL Server databases ( E: )
- all disks 15K SAS, 73GB on a suitable SAS controller ( e.g. Dell PERC5 or PERC6 )

Also, it's expected my client will switch their software licenses to the 64-bit versions and run those on more RAM (at least 8GB, their current server will take up to 12GB). My client's databases are small, they have 2 active companies (databases) neither of which is over 2.5GB, plus some smaller test databases and snapshots for reporting purposes.

While doing some independent research on this recommendation I found a Dell whitepaper:

http://www.dell.com/downloads/global/power/ps4q07-20070555-Chen.pdf

Their recommendations pretty much mirror the VARs. However, Dell recommends putting the SQL Server tempdb on yet another logical volume with at least a couple more drives. I'm guessing that if this isn't done, tempdb should be located on the random access volume E: along with the SQL databases.

After all this build-up < g > , a couple of questions:

1. Can anyone offer any real-world advice on whether it's worthwhile to break out the SQL Server tempdb to a separate logical volume/separate disks?

2. The VAR is also claiming it's "important" that the server have the latest 1333MHz FSB, which would mean a server replacement as the PE1800 is "only" 800MHz FSB. I find this a little hard to swallow, this fast FSB is very new, it implies that any other sites running SBO on server hardware more than a year or so old are in trouble. Anyone have any insight on whether fast FSB helps SQL Server, particularly in improving effective disk I/O and reducing "average disk queue length"?

It is unusual that a nominally C/S app with relatively small databases and low number of workstations would require such a powerful SQL Server. However, the VAR now admits that SBO is an SMB product with enterprise-class I/O performance requirements.

Any war stories you'd like to share? TIA.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform