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
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 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
Customer Card Performance
dbabas
Member Posts: 33
Hi all,
I know that this isn't the first post about this and I already read a few posts for the issue. Indeed I know that flow fields are probably the problem but I would like to ask the following questions:
1. How many records considered a big number for the source table of a flow field? I mean which is the threshold that must trigger further investigation?
2. At least in my case, when I open the customer card I am experiencing very slow performance. If this is due to the flow fields like (balance lcy), how can be reasonable after the opening of the form to be able to navigate between records very fast without any problem?
Thanks
I know that this isn't the first post about this and I already read a few posts for the issue. Indeed I know that flow fields are probably the problem but I would like to ask the following questions:
1. How many records considered a big number for the source table of a flow field? I mean which is the threshold that must trigger further investigation?
2. At least in my case, when I open the customer card I am experiencing very slow performance. If this is due to the flow fields like (balance lcy), how can be reasonable after the opening of the form to be able to navigate between records very fast without any problem?
Thanks
0
Comments
2. You could move these flowfields to a separate form which can be called from a menu-button. This way, you can navigate through the records very fast as no (or less) flowfields needs to be calculated.
Not saying they couldn't be your problem, but flowfields are more common to be seen as problems on list forms. Since they must be calculated for every record to be displayed. Including them in a filter can be even worse.
The performance issues with flowfield tends to be more related to the number on the form. Not so much the number of records associated to the calculation. Since the calculation is most likely using the indexed view and those reading substantially fewer records. Unless the field definition has a problem.
1.Create a new Customer card by using the wizard with only 2-3 fields (not flow-fields). This works perfect as it was expected.
2.Add the "Balance (LCY)" field and the time of opening the page vastly increased. And I mean in an unacceptable level (~10 sec).
The strange thing is that there is a delay only when the card opens and not during navigation.
If SQL Server - look and see if your SQL key definition match the NAV key definition used for calculating Balance (LCY).
A "creative" key field order difference can work havoc with performance for example.
Also, has the database been tuned?
http://mibuso.com/blogs/davidmachanick/
Also check the SIFT maintenance has not been disabled on that Key. If SQL needs to sum the base records it can also impact performance with large tables.
I have examined most of these. I keep trying. I noticed that the SQL server's needs to update with SP2 and there are also several updates for the operating system (Windows 2008 R2). Do you think that the update could help?
I would suggest you take Luc's recommendations seriously, especially the first one. And it seems you've already begun that because you're considering upgrading your SQL Server environment to a more stable build (I'm guessing 2008 to 2008 R2?). But in a more general sense, look at the following:
Hardware:
- Whether your database master and log files are on the same logical partition
- the RAID configuration on the disk drives your DB resides on
- Free disk space
- Are there enough resources (CPU and RAM) such that these are not your bottlenecks
Software:
- Ensure the database has low fragmentation to increase page reads
- Maintenance Jobs to keep statistics up to date
- Enough RAM allocated to the SQL Server Instance
There's a whole slew of these things to check out, but start with a small defined list, heed the advice on this board, and hopefully you'll be able to eliminate this problem. All of us come across this performance challenge at some point during an implementation, so take heart that this case isn't unique.
G.R. & Associates, Inc.
Could you give more info on this? We have the tempdb on a partition + de customer db on a partition.
The transaction log should be on a separate dedicated physical array. Not simply a separate partition. A separate partition provides no advantage if it is on the same physical array. This separation is done to address physical limits of mechanical disk and how they impact sequential versus random I/O. BTW - the use of SSD removes this physical limitation and thus the need to separate the various files.
What is the reason for separating the Master DB? This database would likely see little traffic and thus not see much advantage to justify the cost of dedicated disk.
Fair enough. After reading over my post once more, I should've written "Whether your database DATA and log files are on the same logical partition". I didn't intend for it to be understood as "dbo.master".
And yes, having them on same/separate logical partitions but on the same physical disk offers little advantage.
G.R. & Associates, Inc.