We run 200 plus users and have through put issues with table locking while processing orders (both sales and purchase orders). Our overall speed has been a headache since day one and we have some inventive solutions to reduce the impact on the online user. A combination of a time sharing function over large posting routines and flagging orders to be posted (batch processing) after normal business hours. We have our MBS Partner looking for any assistance to overcome the mounting problem. We have taken the MBS advise to upgrade and are currently building V3.7. V4.0 was not available in Australia at the time. Our test results on V3.7 show that std Navision still does not cater for the orders of the size we use. Our purchase orders being receives are over 1000 lines and orders of 3000 lines are not uncommon. We are investigating what we can do to reduce system impact of having 3.8 million ILE records. This ILE table at 20gb is the biggest in our system and as it is used by nearly ever function, represents the biggest potential return on our effort to relieve the problem. Date compression of the ILE with a custom table (only available to a select few applications) to hold the detail we would lose is one idea. Any offering of ideas or a solution to this problem would be greatly appreciated. Who else suffers from this problem? I know there are many threads already on similar problems however I am yet to locate one with a solution for our situation. Thanks for your interest. Rob.
What does your server set up look like? We are a smaller implementation than yours, @ 75 users, but our performance was greatly increased by an upgrade to our server. There are many threads on that subject and I just followed the most common recomendations.
The server is a Quad Xeon 2.7GHz with 4G of memory talking to 6 x 73.4G 15Krpm drives in a raid 1e configuration in a SAN connected via fibre. The environment is clustered with the passive server being of slightly less specification than the one described. This hardware has been reviewed by MBS and has their tick of approval. Our 200 remote users access the system via 8 servers running Terminal Services. Speed issues are present even when using a client directly on the main server.
Hello Robert, I guess you are using SQL server! Has your NSC profiled the SQL perfromace to find bottlenecks? Has your NSC looked at optimisation of the SQL, particularly SIFT? Otherwsie you appear to be looking in the right places. Archiving the ILE is a good route and you can even push the archive into a different database.
Jonathon, We have been along all the paths that you suggest. We have had advise that the archiving the ILE may not be a good idea as the Date Compression tools do not cater well for enhancements that have been made in Std upgrades. This can result in loss of access to data. We cannot afford that risk. We are looking at a couple of options and will ask MBS to consider future developments that will cater for our transaction profile and volumes. An NSC in Denmark may have a solution but it involves heavy customisation. I will update anything which enhances our current position. Rob
Robert, What is the specific problem: is it inserting records into the table or reprtoting from the table? We do not yet enjoy this problem but good luck with your NSC.
Jonathan, Sorry about the delay in responding. The problem is not in reporting. It appears to be the architecture of Navision which requires the table to lock. Picture a 3000 line Purchase Receipt being posted and any number of 250 users trying to place Sales Orders or enquire on available stock at the same time. They all must wait while the associated tables are locked during the posting. This can take 10 minutes on a good day. Basically the system stops for the one process. This may also include anyone trying to run a report if it is on the locked table.