Hi All, I have a windows 200 server running navision. 2gb of memory xeon cpu raid 5 The database has been moved onto a SAN. While this has improved the performance tremendously it is still running slow when reports are being run. CPU, Disk and memory tests have been performed and the only area of concern was the read/write times on local drives of the server. It appears as if Navision was writing and reading from a temporary file. Does Navision write to any local temporary files etc before writing to the database? What other area could I be looking at to improve performance? Any assistance would be great. Thanks
We recently moved our DB from a RAID5 Array to a RAID1 Array (thanks to suggestions from others on this list) and the performance difference has been dramatically better.
quote:
Originally posted by oneill3
Hi All, I have a windows 200 server running navision. 2gb of memory xeon cpu raid 5 The database has been moved onto a SAN. While this has improved the performance tremendously it is still running slow when reports are being run. CPU, Disk and memory tests have been performed and the only area of concern was the read/write times on local drives of the server. It appears as if Navision was writing and reading from a temporary file. Does Navision write to any local temporary files etc before writing to the database? What other area could I be looking at to improve performance? Any assistance would be great. Thanks
Which reports?
Oniell3,you really need to get off RAID5, it is just too slow, and there is a high chance of you corrupting the database. SANs can work, (though I really don’t want to recommend them), but you MUST have RAID 1 if you want any chance of speed. PS I have posted a LOT of threads on this topic, just use the search tool.
Hi David, but you never give an answer to the question :“Using a Ram-Disk”
Hi David, Thanks for you reply, and to everyone else who replied. Can you please expand on your comment about SANs and why you don’t recommend them. Why will RAID5 corrupt the database? Currently the database is on the SAN, is it still exposed to corruption? Thanks O’Neill3
We have been been using Navision/SQL2000 on a SAN with RAID 10 for over two years now with no problems. The setup was recommended by Navision and our NSC at the start. Cheers
quote:
Originally posted by oneill3
Hi David, Can you please expand on your comment about SANs and why you don’t recommend them.
Yes david, why?
I would like to know the answer that question also David? Or have you changed your mind since this was posted?
I have been running a solution with 30 countries on SQL2000 and database (2 db’s for timezone maintenance) on SAN with raid 1. I (and my users) have not had any issues with performance. So what should be the problems ?? (I have been told for different types of SAN raid 1 or 10 could actually be the same??)
I said very clearly that SANs can be made to work, but only if the IT department has a good understanding of exactly how Navision Works. How SQl works, and how SANs work.
My issue with SANs, is that I often see that the IT department builds a SAN puts in a nice RAID 10 array for the DB and a nice RAID 1 for the Log file, everything is great. Then later on someone says, “hey we have 146Gig drives in the SAN but we are only using 20Gig off each drive. Lets use the power of the SAN to create more RAID arrays on those drives so we don’t waste disk space”. I saw one like this a couple of weeks back. All that extra space is great, since now they have somewhere to store that huge Exchange database on RAID 5 at zero cost.
And I see this a lot, so I don’t recommend SANs unless the client really knows how to manage them.
Ahh I see. But we can actually say the same about SQL Server vs. the native NAV database!
If you don’t have an IT department who knows how to manage the SQL Server, then sure the native is better…
I have seen it on NAV and SQL. From your point of view, you are the customer, and you would make sure its done properly, but I have seen a lot of cases where the IT department get a SAN for Navision, but the a few months later they read somewhere that they can use all that free disk space for other apps, so they do. Suddenly your Log file is sharing the same spindle as Exchange and Active directory.
The customer I was at a few weeks back were complaining about serious SQL performance issues, and point blank refused to even talk about their hardware, since is was the best. Eventually I extracted from them that they have one SAN with Exchange, File sharing everything on one box. The CFO was complaining that the IT department wanted to buy more hard disks, when there was all this free space on the SAN. SO they just created a partition for Exchange on the same spindle as the Navision log and Database.
But from their point of view, they followed the Microsoft instructions, since the Database and Log file are on different spindles. But no one told them that you cant put OTHER programs on those spindles.
In the NAV case I have seen clients with SANs that know they have to have each database part on a seperate drive, so just go to the SAN and tell it to create (say) 12 10 Gig RAID 1 drive arrarys, these might be spread over 4 driveswith bits all over the place. Or they are spread over a few more drives, and intermingld with other apps. And gerneally these SANs are magic boxes hidden from us, so we cant even see what is really goin on since th IT department dont want to make that information public.
So in the end it doesn’t matter SQL or NAV, in the vast majority of SAN installs I have seen Navision on, the drive configuration was a disaster. And worst of all, I generally find it impossible for IT people to listen or even want to listen that they may have configured the SAN wrong. Their puropes for buying th eSAN was to efficiently use all the disk space they possibly can, and they are not going to let NAV ruin that concept. Oh and its not just NAV, it other SQL apps they have that are also crwaling, but “it not the SAN, we paid $xxx for the SAN, it can’t be the SAN”.
But its not the SAN it self that is the issue, its the configuration. And SANs make it too easy to screw up.