Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Recently converted from Proprietary DB to SQL DB
davisj
Member Posts: 38
We recently converted our 2.60f database from proprietary navision (50 GB) to SQL Server 2000. Our end users in areas that are more transaction intensive (for example: Manufacturing-BOM Certification, Inventory-Item Journal Posting & Manufacturing-Releasing Production Orders from Sales Orders) are experiencing slower response times than they were in the proprietary database. The troubling part is that our server's CPU utilization averages out at about 17%.
Does anyone have tips regarding SQL Server setup optimization that might help utilize more of our server resources?
Does anyone have tips regarding SQL Server setup optimization that might help utilize more of our server resources?
0
Comments
There are many tips on this forum. Base is the Performance Troubleshooting Guide from MBS tools CD.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
I spent the best part of a year troubleshooting performance of an SQL database at V3.10a. Navision has got much better at later versions, as with later versions of SQL.
As well as the hardware issues......and the key is going to be memory and disk arms. There are a number of potential issues with the application.
The design of keys and the use of the SIFT technology will need to be looked at for key tables, you may also find that there is an element of table locking going on. This might be relevant as the CPU usage is so light. If there is a large degree of bespoke work, this may need optimising for SQL. Keys, commits and record/table locking.
We migrated from 3.10 to 3.60 very quickly....then ran 3.60 with a 3.70 client. This helped but it wasn't the hoped for panacea. The optimisation of keys and code was probably more crucial.
Best of luck....i know that it can be a long haul.
1) Do you know where I can get the MBS Tools CD to look at the Performance Troubleshooting Guide?
2) I found that our SQL Server instance doesn't have awe enabled (we are 2k3 with 8GB RAM) so I am going to enable this and see if it helps any.