It looks like you're new here. Sign in or register to get started.
1. We have about 250000 GL Entries per week (average of 3 years)
2. MS Experts and people from implementing company said the problem is there...
Besides that we tried to optimize indexes (also with mr.Stryk and MS help) , we optimized the code (i m sure here can be a lot of done yet), etc...
Your post is missing so much useful information, you will get only very generic responses.
What version of SQL Server?
What version of NAV executables and objects
32 bit or 64 bit SQL Server
RAM on the SQL Server
All direct connect clients or are you using remote desktop
Navision locks tables when you post to the G/L Entry table - how much posting is going on? Has it been optimized? Any customizations to streamline posting?
I was just working last week on a system where we tried to post a peak of 260,000 GL transactions PER HOUR! But we could only achieve 160,000. And we have nothing even close to the hardware you are planning here.
1. How many files use for DB ? Som of people say 1 per core, some of them say 0,25/core maximally or just ONE totally .
Everyone of tham has some purposes why to do so ... And I just don't know ...
2. Same as Q1 but for TEMP DB
a) Does it worth to separate Non Clustered Indexes to another filegroup (which will reside on separate Raid array) ?
Some of people say yes, som of them say absolutely NO.
b) As Q3 + should I separate some tables with heavy i/o to another filegroup?
c) Or just make one big Raid 10 and put it there in just one filegroup (multiple files)?
4. Is there any simple benchmarkung utility which wil do some i/o tests and will tell me answers to my questions?
Mark Brummel wrote:
The years that NAV and SQL needed massive I/O on the disks are IMHO in the past.
With current technology (NAV & SQL) most of those issues are solved, but the NAV channel and community does not seem to realise that and/or there are still quite a lot of old installations and people that write bad code. I'm affraid the latter will always remain.
TempDB should not be used in a good setup scenario and can be anywhere.
Most important nowadays are memory and network thoughput.
Invest your hardware money on getting on the latest binaries and software redesign.