-
Hi Guys, I'm so happy to find this very helpful site,finally i'll get some help in MS NAV 3.7.Actually we are NAV 3.7B on SQL 2000.I have been struggling to maintain few tables in SQL,mainly the TRANS_ SALES ENTRY,TRANSACTION,BIN ENTRY and the most problematic ACTIONS tables,i set a SQL job to...
-
As a starter have you identified the largest tables in the database and used Table optimisation (File, Database, Information, Tables, Optimise) from the Drop Down menu? This will help but follow Erik's advice and share some more information about your system configuration.
-
Dear Narayan, You ask a very very broad question, that noone will be able to answer correctly without futher information. Is your version NAV 5.0 or NAV 5.0 SP1? Are you using the native or SQL Server database? When is the system slow? When posting or when looking up information, and do you only feel...
-
Dear all, Please help me in the below, We have a client for whom we are using the following a) All modules in Navision 5.0 B) Lot & SN tracking Due to aboev we have more enteries in Item Ledger Table and the system is very slow. Please suggest some solution (Per day 100000 ENtries getting added to...
-
Hi Girish, I do not know ....We are running NAV 4 with sp3 .... I run the SIFT key optimizer from Stryk ...I update stats daily..reindex key tables daily and huge ones weekly.. but still the db growth is enormous...We also stopped running the cost batch coz it would take days to complete....One thing...
-
May I ask why your database is so large? I do a lot of work with NAV with Retail clients and in every case I have seen this it was because of one of the following: They weren't using or avoiding SIFT properly. A technical upgrade to 5.01 may drop your database size in half. For a "vanilla"...
-
I agree, splitting up the db is at the rear end of optimizations (first NCI, second SIFT), and only on very large databases (300GB+). In these cases we usually splitt the db AND placed the files on separate disk volumes which in total indeed gave a performance gain (but not giant leaps) due to the "relief"...
-
In a previous life, we split the DB for disk space concerns, rather than performance. We basically sorted by table size and put half in one, and half in another, plus seperate for the non-clustered indexes on the larger tables. From a performance perspective unfortunately it was difficult to measure...
-
Well, as so often ... it depends ... Splitting the DB into multiple files could indeed improve the performance (more CPU Threads, dedicated I/O). To do that, at first it should be assured that thre IS enough CPU capacity to handle the additional threads. Then, the multiple files could be either stored...
-
Just a question to Jorg out of interest. For each region, you've suggested the mdf/ndf files on one disk. Should they have additional spare raid 10 volumes, would there be any gains, in general terms, in splitting some of the 'high use' (whatever they could be defined as size, transaction...