Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K 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
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 384 SQL Performance
- 33 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
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Performance Probs [Log inside]
tentacle
Member Posts: 27
Hi,
we have huge performance Problems within our Navision Databases.
E.g. opening an item form may take up to 20 seconds!!
Having a look into the performance monitor I made the following screenshot.
At this moment the requisition worksheet was running over all items to made proposes for purchase.
Does the harddisk queue show that our disks on E: are too slow or is there another problem?
http://i14.tinypic.com/4xm47ko.jpg
we have huge performance Problems within our Navision Databases.
E.g. opening an item form may take up to 20 seconds!!
Having a look into the performance monitor I made the following screenshot.
At this moment the requisition worksheet was running over all items to made proposes for purchase.
Does the harddisk queue show that our disks on E: are too slow or is there another problem?
http://i14.tinypic.com/4xm47ko.jpg
0
Comments
There are kb-artikles by microsoft your partner can use to try and solve the problem.
2) Page splits can be mark of segmented indexes
3) Full scans can be mark of wrong usage of indexes
The data can lead to the solution, but as you know, it is just indicator that something can be wrong...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Yes, they are both on E:.
But E: is a logical partition in our huge SAN so I think this should be ok!?
Recomendation is to have the Logfile on a dedicated RAID1 and data on Raid10.
Make sure the striping is not shared with other apps and that the connection with the san is dedicated and not shared by other servers.
On partnersource there is a special query released by MS to see if THE bug in SQL2005 is happening on your system. This shows the amount of huge reads in the procedure cache.
RAID5 is the worst you can get for performance.
Like Mark said: separate the DB-file and the log-file.
You might also get a specialist to check all.
But first I would check the Item form and remove all flowfields and check what code is launched when opening the form.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
huge SAN is not same as "Optimal storage". Huge SAN can be Huge Problems when used in wrong way... (as everything else). Biggest myth is that newest and expansive hardware is warranty of best performance. Everything without correct setup is just heap of screws, heads, wires, metal and other "hardware".
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Is there any other way to get that "Sql2005-Bug-Test-Script"?
From my experiences it is easier, faster (and even better
Based on the contents of this thread, I would have to disagree with that statement.
Than I will say, that they are not reading this forum regularly... 8)
It is problem, that if you do not know about this possibility, you cannot do anything around it. And if they just sent the problem to MS Support, still it is not warranty, that they will answer correctly (it depends on how the problem was described and on the support engineer). But you can tell them - "Hey, I found something about this and this problem, is it possible, that it is our case too?" (show them direction) - and if they will react correctly, than it is ok.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
To which bug are you referring? http://www.mibuso.com/forum/viewtopic.php?t=13154
It took us a bit of "screaming" at Microsoft before they would even admit this problem existed. Even then it probably accounted for less then 1% of the performance issues at this client.
Performance tuning is a complex issue. Rarely is a single issue the cause of all performance problems. Typically it is the combined impact of several issues.
Working with your MS partner should be a partnership. You both need to understand the resources you each bring to the table. Your partner needs to use the resources available to help resolve your issues. This may involve things like this site or partnering with other partners or Microsoft. You also need to understand that it is unrealistic to expect any one person (or partner) to have the answer to every problem you will encounter.