We are currently running NF under SQL instead of C/Side. Now we’re experiencing performance problems (For example, an import takes 25 minutes under SQL instead of 5 under C/side). The hardware we’re using should be sufficient. Does anyone have an explanation/solution?
Can you upgrade to SQL2000? Performance is generally better. Also, when you say “hardware should be sufficient” are you expecting equal peformance from SQL on the same hardware as C/Side? Generally SQL needs different hardware configuration. For C/Side the speed of the disk drive is very critical. While disk drive speed is important for SQL, CPU speed and memory can be more critical. Equal performance for SQL requires more hardware than C/Side. Jim Hollcraft NCSD, NCSP, MCSE, CNE, MCP, MST aka Skater http://drilldot.com Unauthorized Navision News Edited by - Jim Hollcraft on 2001 Jun 16 16:31:18
We’ve upgraded the hardware to meet the requirements voor NF under SQL7. So that shouldn’t be the problem.
Hi. As Jim pointed out performance under SQL is generally a little slower unless you have a lot of hardware. Since you’ve stated that you upgraded your system to meet the requirements - what requirements are you refering to? As I know it Navision only publishes the mimimum requirements. Please let us know the following information so that we may be able to help. 1. Your hardware type and configuration. 2. How Navision is configured? 3. If the system is being used for anything else - including hosting any other database applications. 4. What your dataport does and how many tables are being updated? Finally, I’d load service pack E as soon as possible since it includes many SQL fixes. Michael
You say you are trying to move from C/SIDE to SQL - have you just used the 2.01B objects in SQL or modified them to include the changes for RECORDLEVELLOCKING?? This could easily be a soruce of such a slowdown. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
quote:
Originally posted by cbradney: You say you are trying to move from C/SIDE to SQL - have you just used the 2.01B objects in SQL or modified them to include the changes for RECORDLEVELLOCKING?? This could easily be a soruce of such a slowdown. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
We’ve upgraded Navision to 2.6D, all necessary modifications should include the changes for RECORDLEVELLOCKING. (is there an easy way to check this, just to be on the safe side…?)
quote:
Originally posted by Theo: is there an easy way to check this, just to be on the safe side…?)
Yes, it’s! You will find a program called FINDLOCK.EXE in the upgrade folder on the Product-CD. You will allso find a PDF-file with instruction. Per.Bay@navigera.com Product Manager www.navigera.com
quote:
Originally posted by mctester: Hi. As Jim pointed out performance under SQL is generally a little slower unless you have a lot of hardware. Since you’ve stated that you upgraded your system to meet the requirements - what requirements are you refering to? As I know it Navision only publishes the mimimum requirements. Please let us know the following information so that we may be able to help. 1. Your hardware type and configuration. 2. How Navision is configured? 3. If the system is being used for anything else - including hosting any other database applications. 4. What your dataport does and how many tables are being updated? Finally, I’d load service pack E as soon as possible since it includes many SQL fixes. Michael
- Your hardware type and configuration. SQL Server: Compaq Proliant 3000,600MHZ, 512MB Memory, WIN NT4,SQL7 sp3. Network: 100MB Switchet Ethernet Client: Compaq Deskpro EN 400MHZ, 64MB memory, Win95 > 2. How Navision is configured? Navision Client 2.60.D NL SQL Navision Financials > 3. If the system is being used for anything else - including > hosting any > other database applications. No. The system is only be used by Navision. Only one client. > 4. What your dataport does and how many tables are being updated? We’ve got several dataports to test a Conversion, fact is that the import under SQL is slower than the samen import under SQL. Hope this info will help you regards Theo
How big is the database now? and what are your cache settings? This could be an issue perhaps Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
If you are using NT4 & finding a lack of performance you should upgrade to Win 2000 for the server, we have seen big improvements especially on a server with those lower specs. By the way when this goes “live” how many concurrent users will there be?
I really doubt you would see performance gains on a low spec 2000 box. 2000 itself takes up enough resources, let alone the SQL on top and then the server and database processing. This server should be quick with NT4 as long as the database isnt gigabytes trying to fit into 512mb ram. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
Hi! Try to change in the OPEN DATABASE window, under Advanced the nettype property from Default to TCP/IP Sockets…maybe this should speed up your performance… Greetz Roland
Hello Theo. Importing in to SQL is typically slower. However, since you mentioned this is only being used by one client I believe the problem lies in tables being used. Are you updating the primary key in multiple tables? Does the table(s) that you are importing into have several SumIndex fields? Have you tried this in 2.60.E? I would recommend that if your system isn’t a dual processor system that you upgrade it and also your RAM to 2 gigs. Michael
As we still dont know the database size I wouldnt be recommending any particular upgrades to hardware. 2.6E might help for some issues, maybe unrelated or unseen at this point. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
quote:
Originally posted by john: If you are using NT4 & finding a lack of performance you should upgrade to Win 2000 for the server, we have seen big improvements especially on a server with those lower specs. By the way when this goes “live” how many concurrent users will there be?
About 50 users
quote:
Originally posted by cbradney: How big is the database now? and what are your cache settings? This could be an issue perhaps Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
database size = 2 gb object cache = 10 mb
quote:
Originally posted by mctester: Hello Theo. Importing in to SQL is typically slower. However, since you mentioned this is only being used by one client I believe the problem lies in tables being used. Are you updating the primary key in multiple tables? Does the table(s) that you are importing into have several SumIndex fields? Have you tried this in 2.60.E? I would recommend that if your system isn’t a dual processor system that you upgrade it and also your RAM to 2 gigs. Michael
All imports are done 1:1 (one set of data into one table), these tables are temporarely so no sumindexfields are present.
You haven’t mentioned the disk layout for the database files. This can be critical. The minimum configuration for this is that your database and log files are split up over different physical disks, as follows: disk 1: Contains NT and its vm swap file. disk 2: Contains the primary data file (i.e PRIMARY file group) for the database. disk 3: (the bigest/fastest) Contains the seconday data file. This is where all the table data is stored. disk 4: Contains the log file(s). (disk 1 and 2 could be the same if necessary) Note this is miniumum. A RAID system is optimal. Dataport imports are primarily INSERT operations of course. That means, as for all modifications, the data is being written to the data file(s) (disk) and the log file(s) (disk). If these share the same disk, performance is reduced. When creating the database you can see the default file layout, which basically follows SQL Server’s data file layout. However, the first data file listed is flagged as the primary data file, where all SQL Server system tables will be placed (thus creating table/indexes and other SQL objects will target this file by making entries in the system tables; that is the schemas not the data itself). The second and subsequent files listed are all flagged as the DEFAULT filegroup and this is where the data for the tables is placed. You can point to the appropriate disks by drive letter for these and the log file(s) in this create database dialog.
To All, thanx for all your reply’s. We’ve chosen the next solution: We will upgrade SQL7 > SQL2000 and NT4 > Win2000. Tests have shown that the performance will improve (not as good as using C/side but acceptable). regards Theo