Hi Al,
>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.

First: Logging/measuring time is in order - I suspect half of the upgrade is not needed.

>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.

See above - get an idea of the MB moved.
>
>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.

4 Gig on 4 cores seems to be the most pressing problem. As second step I'd NEVER create a "one big partition" layout.

>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:

on first try add memory, reducing disk reads.

>- 4 disks in RAID10 for Windows and the swap file ( C: )
This causes one highly raised eyebrow - what is swapped here to need that setup ? Especially Raid10 for a swap file ?
Better image your boot partition and Raid0 the swap file, if necessary at all

>- 2 disks in RAID1 for SQL Server logs ( D: )
As Raid1 does not speed up writing, this only gets you security. Necessary ? Perhaps use 2 disks from Swap file to implement Raid10.

>- 4 disks in RAID10 for SQL Server databases ( E: )
Ok
>- all disks 15K SAS, 73GB on a suitable SAS controller ( e.g. Dell PERC5 or PERC6 )
Here some Dell controllers got a very bad rap on Postgres performance use groups.
Recommend you try reading up first - no links but often enough seen over there.
Issues: bad performance by lousy command rearranging and lying about having written data from the buffer(fsync-issue).
>
>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.

Do that first! Even the 32-Bit larger servers can put more memory to work: while PAE is similar to earlier memory mapping, it is much better than disk swaps.
>
>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.

That should be more useful on write- or transaction-heavy usage. Is SBO that kind of app ?

>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?

see above<g>

>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"?

Here I'd disagree on 2 double cores. The FSB is the thing hampering scalability of the server, true, but with only 4 cores total in use you are barely scratching that border. 4 Core2 cores scale almost linear (there is a reason for quad cores <bg>) On a 4 quattro core layout I'd agree, and when switching to a 2 quattro cores layout I'd also think about selling the whole old server as it is before getting nearly no return for the components replaced. Then higher FSB is easy <g>. Spurce of my opinion: find some data on scalability of MySql and PostgreSQL with different no. of cpu's sporting different nö. of cores between AMD and Intel offering on Tweaker(s?).Net.

>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.

You bet. How about installing a REALLY beefy server and run SBO on the server, controlled by MSTSC ? Factor out most of the physical network from the equation ?

HTH

thomas