Navision from SCSI/CSice to SAN/SQL

amcmwu

Hello

we are planing to change our database from C/Side to SQL and to change from a SCSI HD shelf to a Fibre Channel SAN.
Is there anyone who has already done this?
Now we have aHP Proliant DL380 G5 with Windows 2003 R2, 4 GB Ram, Xeon Quadcore 2,8Ghz and 12
(15K Disks 24 HD as Raid1). The System is okay and the user locks are not so often. Our Database is 12 * 9,5 GB big and
we are working with 120 Users

The new system will be HP BL460c Blade Cluster with 2* Windows 2008 Enterprise and SQL2005, Quad Core 2,33 Ghz,
16GB Ram and the disks are in a HP EVA 8100 San.

If someone knows what the biggest problem will be become the please let me know.

Regards

stryk

Hi!

With 120 concurrent users (CCU) the new box should be sufficient, except for the CPU (maybe). It is suggested to have one physical CPU per 100 CCU, thus in your case you might consider running 2 QuadCores. But actually it depends on the transaction volume the users are processing, so it's not necessarily a "must have"; maybe you could start with 1 Quad and expand if necessary ...

Using a SAN could have lot of advantages, but it needs to be configured properly, especially if the SAN is also used by other applications/services as Exchange, Sharepoint, File Server, etc..
You should have AT LEAST one dedicated physical aggregate for the SQL Server, better two - one for the NAV DB and System DB, and one for the Transaction Log of the NAV DB. But afterall, this should be discussed thoroughly.

If you search MIBUSO for "SQL SAN" you should find plenty of advices.

Regards,
Jörg

amcmwu

Thanks for the reply stryk. I will search for it.

With C/Side and SAN i must say we had a lot of trouble. We try it with the BladeServer and SAN but our Systempartner had to give us a complete new server with SCSI disks and so on. :-k We dont
want to get in this trouble once again. So i will read your book and then we will see what happend.

Regards

fredp1

Hi,

We have a Bladecentre and a DS3400 SAN and its going quite well in testing.
We did find issues with the Nav customisations that we had caused us major performance problems.(Its all being resolved by our partner now)
The db is on Raid 10 LUN and the TLOG is on a raid 1 Lun.

Make sure that you move the tempdb onto a raid 10 LUN too.

We have dedicated the SAN for Nav/SQL. (SQL 2005 x64, Server 2003 x64, 10Gb ram, 12 SAS 300Gb 15K drives)

Regardless if your using SCSI or SAN, keep an eye on the growth of the TLOG as it pointed us to a couple of problems.
1) Backup the TLOG regularly. Depending on your requirments, hourly or at least daily.
2) The application was struggling with some data that was causing the MRP to run for more than 4hrs. The TLOG was growing (extending) adding to the slowness.
3) Make sure that you follow Jorg Stryk recommendations in his SQL Field guide book when setting up SQL. i.e. disable the auto create/update statistics, change the file growth. I found it invaludable.
4) Dedicate the SAN to Nav.
5) Check the antivirus isn't slowing down SQL- you may need to exclude the file extensions of .mdf, ndf, ldf
6) check for TLOG fragmentation (after you have defragged the disks first)

Regards
Fred