Nav supporter's blog

Coffee Break: Simplify Your Customer Service

Jasminka Thunes — Mon, 08 May 2017 10:42:06 GMT

Following up on our previous posts, this is the latest edition of the NAVDiag tool, aimed to inspire and simplify your customer service. The tool is for on-premise installations only, but we hope this can help increase the efficiency of your customer service and free more time and resources for product tasks, like migration to Cloud. New in this edition is the code coverage added to supplement the steps recording function added in last version. The Record Steps action will now start both step recorder and code coverage, and export the output when completed. The idea is to collect all details you might need for troubleshooting a single task, in one click of the button. This is done invoking the built-in code coverage, available as of Dynamics NAV 2016, but you can modify the tool to use the old CodeCoverage free fobs available for 2015 version. We've also added a simple config analysis function that will point out the changes in your service configuration, in relation to default configuration values. User can now also download and mail the log. You have given us some great ideas and suggestions, and these are not forgotten. Please allow us some time to add these, and keep your ideas coming! navdiag1-4

Dynamics NAV Performance Tooling Part 2: Ghostbusters

Jasminka Thunes — Wed, 19 Apr 2017 13:45:10 GMT

After patrolling some of the installations out there, our Ghostbusters team has decided it is about the time to bust the myth of a few ghosts out there, and the first on the list is our SmartSQL Bogeyman. If you have an installation with larger data volume in some areas/tables, then chances are that you might have experienced slower response on one or two of your list- or card type pages. Typically, upon observing this, the savvy engineer will fire up the sql trace to peep behind the scene and there he or she might spot a massive query with higher reads, and sometimes long duration. We call this the SmartSQL query. It is at this point that things become more fuzzy. Complex query, vast query plans and after all - this all used to work well before. Enter Bogeyman. It is easy and tempting to believe that the problem is in these SmartSQL queries, or as popular myth goes 'flowfields on pages'. These queries are large and complex and after all - this whole problem happens with SmartSQL queries only, right? No. It happens on any type of query and happens for a different reason altogether. But it is more prononunced on SmartSQL queries. What is a SmartSQL query? It is a query retrieving all page records, including flowfield records, in one call (or three altogether on a page, to be precise). It consists of a main query (for underlying soruce table) and a joined subquery per flowfield added to the page. It does not matter if you make the flowfield visible or not, as long as it is a part of page metadata, it will be included in data retrieval. Now what is characteristic for these queries is that they don't cache. So if a query plan of the 'main' query or any of joined queries is suboptimal, this inefficiency is amplified. And following this logic, this is the same for NAV Query objects. They too generate JOINs and these queries don't cache. In practice this means that if any of the underlying query plans is inefficient, and the underlying table that it is using is large, your page will take longer time to open. And not because we are using SmartSQL queries, but because the query plan is inefficient and is so whether as a part of SmartSQL query, or as a single, simple query we are traditionally used to. So how to deal with this? Essentially, find a good index. Let me illustrate. The example below shows the process, the details and complexity will vary in different scenarios. To troubleshoot, a sql trace will suffice. It is recommended to troubleshoot this on an isolated environment, to leave out any surrounding noise. Create a standard SQL trace, adding following events: Performance: ShowplanXML and Stored Procedure: StmtCompleted.The first will make sure you know what statement is executed on each sp call and the second will make sure you can see the Query Plan executed for each query sent to the server. Because it is here our Bogeyman is hiding. Run the trace while opening the page, scroll through the completed trace looking for queries with:

High reads, CPU and long duration
Starting (typically) with SELECT TOP (50) ISNULL
Containing one or more OUTER APPLYs (sort of left outer join)

In our example, the query that seems to consume most cpu and time is the following one:

SELECT ISNULL("Sales Invoice Header"."timestamp",@0) AS "timestamp",ISNULL("Sales Invoice Header"."No_",@1) AS "No_",ISNULL("Sales Invoice Header"."Sell-to Customer No_",@1) AS "Sell-to Customer No_", …… , ISNULL("SUB$Amount"."Amount$Sales Invoice Line$SUM$Amount",@4) AS "Amount",ISNULL("SUB$Amount Including VAT"."Amount Including VAT$Sales Invoice Line$SUM$Amount Including VAT",@4) AS "Amount Including VAT" 
FROM " TEST".dbo."CRONUS$Sales Invoice Header" AS "Sales Invoice Header" WITH(READUNCOMMITTED)  
OUTER APPLY (SELECT TOP (1) ISNULL(SUM("Amount$Sales Invoice Line"."Amount"),@4) AS "Amount$Sales Invoice Line$SUM$Amount" 
FROM "TEST".dbo."CRONUS$Sales Invoice Line" AS "Amount$Sales Invoice Line" WITH(READUNCOMMITTED)  
WHERE ("Amount$Sales Invoice Line"."Document No_"="Sales Invoice Header"."No_")) AS "SUB$Amount"  
OUTER APPLY (SELECT TOP (1) ISNULL(SUM("Amount Including VAT$Sales Invoice Line"."Amount Including VAT"),@4) AS "Amount Including VAT$Sales Invoice Line$SUM$Amount Including VAT" 
FROM "TEST".dbo."CRONUS$Sales Invoice Line" AS "Amount Including VAT$Sales Invoice Line" WITH(READUNCOMMITTED)  
WHERE ("Amount Including VAT$Sales Invoice Line"."Document No_"="Sales Invoice Header"."No_")) AS "SUB$Amount Including VAT"  
WHERE (ISNULL("Sales Invoice Header"."No_",@1)>@9) ORDER BY "No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50)

I have shortened the query above and replaced some of it with '......', and also formatted it a bit for easier overview. You will notice 2 occurences of OUTER APPLY, means 2 flowfields on the page. Now let's look at the accompanying query plan. Once you locate the query in the trace, the query plan will be easy to find - it is easily the most complex one and normally found just above the SmartSQL statement. This is the query plan for the example above: It shows 3 Clustered Index Seeks, whereof two have cost of 49 %. There is a whole science behind reading and interpreting these, but to keep it simple - you only need to locate the subplans with much higher cost, or subplans labeled with Clustered Index Scan, that are used on a table you know is large. These two rules will suffice in most cases. Once you locate those, go back to the extracted query and find the matching subqueries. The below matches the first of the two plans:

SELECT TOP (1) ISNULL(SUM("Amount$Sales Invoice Line"."Amount"),@4) AS "Amount$Sales Invoice Line$SUM$Amount" FROM "TEST".dbo."CRONUS$Sales Invoice Line" AS "Amount$Sales Invoice Line" WITH(READUNCOMMITTED) WHERE ("Amount$Sales Invoice Line"."Document No_"="Sales Invoice Header"."No_")) AS "SUB$Amount"

We are retrieving the value of Amount field (SumIndexField) from Sales Invoice Line for Document No. XXX. If we now check the Sales Invoice Line table keys, we see that primary key Document No., Line No. contains Amount field as SumIndexField, but the MaintainSIFTIndex property of the key is disabled, so the SUM of the field is not stored but computed when SQL query is issued. Enabling this property would speed up the opening og the page. Now a word of warning too, this particular example is only to illustrate the troubleshooting process. Depending on the scenario - the best solution might be something else. For this particular example, I would consider for example moving the flowfield to a factbox rather then adding SIFTs to the primary key here, to comply with design best practices. The example here is in other words a bit artificial, real-life examples illustrate this much better but are usually tied to custom solutions and scenarios, so this example will have to do for now. If you have examples you can share with public, feel free to contact me. The main point here is that the problem is essentially in index coverage. Finding the right index will solve this. At this point it is also worth mentioning that some might be tempted to address the issue by disabling SmartSQL queries (option available onpremise). This would be a very bad idea and is abslutely not recommended for the simple reason that it would not solve the underlying problem of the poor query plan, it would only shift the symptoms from opening the page to scrolling the page. Page might then open faster, but will scroll slower. In addition, one would lose the advantage of SmartSQL queries, thus increasing server roundtrips significantly. Which also means that no migration to cloud would perform until the problem is solved. The only good solution is improving the query plan by adding the adequate index. That will make both opening and scrolling the page fast, in all environments. And farewell to Bogeyman.

Hello NAV_Developer

Lars Lohndorf-Larsen — Fri, 17 Feb 2017 07:09:03 GMT

The NAV_Developer blog is coming back into action as a NAV supporter’s place. This will be by and for people who support the Dynamics NAV products in one way or the other. Starting with the newest version of the NAV_Diag tool from the Coffee Break team https://blogs.msdn.microsoft.com/nav_developer/tag/coffeebreaks/ and lists of NAV CU builds for supported versions: https://blogs.msdn.microsoft.com/nav_developer/category/release/ and a new Performance Tooling series: https://blogs.msdn.microsoft.com/nav_developer/category/tooling/ and much more to follow. Welcome back, and we will look forward to providing useful information here and to hear back from you!

Dynamics NAV Performance Tooling, Part 1

Jasminka Thunes — Thu, 16 Feb 2017 07:44:54 GMT

This is the first in the series of posts to help you monitor and understand your system's performance indicators. There are several areas to look into when monitoring your system for performance: hardware, setup and configuration, database maintenance, indexing and queries, business logic. We will leave out the traditional topics of monitoring your hardware performance and will not venture in great details to general sql performance monitoring, as you will find many tools and posts about these topics already available. Rather, we will focus on tools we use in Dynamics NAV daily world, and in this first post we will start with the longest running queries. 'Long running queries' is a script that gives you a 'snapshot' of how tuned your database is for your current usage and volume. Along with other statistical data, query statistics can be retrieved from sql dynamics management views. There are number of ways and tools to retrieve these and what tooling you use is just a matter of personal preference. The query below was created and improved over the time by engineers in Dynamics NAV Support Team, and even though it is a standard SQL tool, it is frequently used by Dynamics NAV support team. To get long running queries, you simply need to run the script from your SQL Server Management Studio and direct output to grid.


use master
go
SELECT TOP 200
st.text,
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1) as statement_text,
execution_count,
case
when execution_count = 0 then null
else total_logical_reads/execution_count
end as avg_logical_reads,
last_logical_reads,
min_logical_reads,
max_logical_reads,
max_elapsed_time,
case
when min_logical_reads = 0 then null
else max_logical_reads / min_logical_reads
end as diff_quota, ph.query_plan,
case when
ph
.query_plan.exist('declare namespace ns="https://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtCursor/ns:CursorPlan/@CursorRequestedType)[1]') = 0
then '' else
ph
.query_plan.value('declare namespace ns="https://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtCursor/ns:CursorPlan/@CursorRequestedType)[1]','nvarchar (max)')
end
FROM sys.dm_exec_query_stats as qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as ph
ORDER BY max_logical_reads DESC

What the output shows is a list of top 500 (a configurable number) of most expensive queries run on your SQL Server, and their execution plans. Statistics apply within SQL uptime - meaning they show top 500 worst queries since SQL Server was last restarted. If you want to 'reset' the cache you can run DBCC FREEPROCCACHE at the end, but keep in mind the short term performance penalty that clearing the cache has, until the cache is built up again. So once you get the output, what does it tell us? To continue, we can sort it by execution count, duration and reads, all in descending order (the original query is sorted by reads only). This can be useful because there is little point with starting with queries that are rarely ever executed on your system. You want to focus on frequently run queries and their execution time & reads. Normally, many of the top queries will turn out to be our regular list- (and occasionally card-) page queries. As an example, a (list-) page query would typically look like this: SELECT TOP (50) ISNULL("Sales Header"."timestamp",@1) AS "timestamp",ISNULL("Sales Header"."Document Type",@2) AS "Document Type",......... ..........OUTER APPLY (SELECT TOP (1) ISNULL(MIN("Completely Shipped$Sales Line"."Completely Shipped"),@7) AS "Completely Shipped$Sales Line$MIN$Completely Shipped" FROM "Demo Database NAV (10-0)".dbo."test,$Sales Line" AS "Completely Shipped$Sales Line" WITH(READUNCOMMITTED) WHERE ("Completely Shipped$Sales Line"."Document Type"="Sales Header"."Document Type" AND "Completely Shipped$Sales Line"."Document No_"="Sales Header"."No_" AND ISNULL("Completely Shipped$Sales Line"."Type",@2)<>@11)) AS "SUB$Completely Shipped" WHERE ("Sales Header"."Document Type"=@0) AND (ISNULL("Sales Header"."Document Type",@2)=@12 AND ISNULL("Sales Header"."No_",@3)>@13 OR ISNULL("Sales Header"."Document Type",@2)>@12) ORDER BY "Document Type" ASC,"No_" ASC OPTION(OPTIMIZE FOR UNKNOWN, FAST 50) It is easily recognisable by SELECT TOP (50) .... and the 'joins' (OUTER APPLY ...) added for each flowfield on the page, provided the page has any. These queries would retrieve the entire record selection and all the flowfields included in one roundtrip (or 3 to be precise), and for that reason they are expected to return a relatively high number of reads (proportional to your data volume). So finding these on the top 500 long queries list is to be expected, and only worth looking into if it is accompanied by long execution time. The avg execution time of these will be somewhat higher then any other avg query (due to data volume they need to retrieve), but overly high values could be worth attention. If you run into one of these, we will show an example of how to deal with this in one of coming posts. Moving along, you will also notice typical server-side queries in this list. For example: SELECT "timestamp","Type","Code","Sales Type","Sales Code" ......FROM "Demo Database NAV (10-0)".dbo."test$Sales Line Discount" WITH(READUNCOMMITTED) WHERE ("Type"=@0 ...... Here, high reads would warrant our attention. High execution count with high execution time alone would not necessarilly imply a poor query. After all, the long execution time could be due to a wait on lock release, for one. So it is when we also observe high reads that we are likely looking into a poor query. This can be further examined by looking at the query plan (the rightmost column of the resulting output). So if you have isolated such a query, with high execution time, reads, and high execution count, you will want to optimize it, typically by adding an appropriate index. If you use this in periodic intervals you can make sure your application is sufficiently indexed for optimal daily usage.

NAV 2013 build overview

Lars Lohndorf-Larsen — Tue, 14 Feb 2017 09:13:19 GMT

Overview of NAV 2013 builds

Cu Number	Release Date	KB Number	Build Number	Download
47	Feb 7. 2017	4011765	47880	Download
46	Jan 6. 2017	3216196	47667	Download
45	Dec 8. 2016	3209075	47432	Download
44	Nov 4. 2016	3202888	47258	N/A
--- n --	----	----	----	----
RTM	Sep 7. 2012	N/A	N/A	Download

If you need a specific build or CU which is not listed here, then please contact support to help you find the exact build you need.

NAV 2013 R2 build overview

Lars Lohndorf-Larsen — Tue, 14 Feb 2017 08:54:47 GMT

Overview of NAV 2013 R2 builds

Cu Number	Release Date	KB Number	Build Number	Download
40	Feb 6. 2017	4011766	47881	Download
39	Jan 6. 2017	3216194	47662	Download
38	Dec 8. 2016	3209074	47442	Download
37	Nov 4. 2016	3202886	47259	N/A
--- n --	----	----	----	----
RTM	Oct 7. 2013	N/A	N/A	Download

If you need a specific build or CU which is not listed here, then please contact support to help you find the exact build you need.

NAV 2015 build overview

Lars Lohndorf-Larsen — Tue, 14 Feb 2017 08:43:18 GMT

Overview of NAV 2015 builds

Cu Number	Release Date	KB Number	Build Number	Download
28	Feb 6. 2017	4011764	47871	Download
27	Jan 1. 2017	3216192	47665	Download
26	Dec 6. 2016	3209073	47438	Download
25	Nov 4. 2016	3202890	47254	N/A
--- n --	----	----	----	----
RTM	Sep 22. 2014	N/A	N/A	Download

If you need a specific build or CU which is not listed here, then please contact support to help you find the exact build you need.

NAV 2017 build overview

Lars Lohndorf-Larsen — Wed, 08 Feb 2017 12:34:55 GMT

Overview of NAV 2017 builds

Cu Number	Release Date	KB Number	Build Number	Download
3	Feb 2. 2017	4011763	15140	Download
2	Jan 27. 2017	3216190	14767	Download
1	Dec 8. 2016	3209071	14199	N/A
RTM		N/A	13682	Download

Coffee Break: NAVDiag

Jasminka Thunes — Fri, 03 Feb 2017 08:57:04 GMT

In the previous two posts, Automation Part 1 and Part 2, we talked about how to easily bring PowerShell into NAV. Based on the applicability and interest shown so far we wanted to continue on the previous thread and address some of the suggestions we received, as well as add some functionality. We called the result NAVDiag. This can be a tool that helps you simplify and speed up the troubleshooting, but above all - we hope this will create engagement around tooling possibilities and inspire for more suggestions. In this edition we have added examples of how to read the license file and read the config file. Exporting license file is done using NAV cmdlet and as running NAV commandlets requires elevated permissions, in order to run NAV cmdlets from this tool your NST account must be an admin account. In general, we are trying to avoid functionalities that require elevated permissions in these examples, as the point is simplicity and the ability to use this on a default configuration without any further installation or modifications needed. But after your feedback we thought this could be useful to have under a caution that running actions that invoke NAV cmdlets will fail unless NST user account has elevated permissions. Another functionality we added is capturing repro steps when troubleshooting using Windows Steps Recorder. This is initiated using client side .net interoperability, so this functionality will not run (nor be present) on a WebClient (see limitations). The same would apply to collecting diagnostic details client side (can be used on Windows client only). Collecting client-side data was one of the questions/suggestions we got and is something that we will come back to soon. For now, we would like to wrap up the functionalities that do not require any changes to default configuration. So here it is: The tool now allows you to collect diagnostics, the same diagnostics we presented in the last post, with added examples of reading the config file, the license file and Steps Recorder. Record Steps action will allow user to record problem steps and save the output. This is basically just a call to the Windows built-in Steps Recorder function, but still useful to have as a part of the tool. Finally, the License File action will read the license file, provided NST account has elevated permissions. There will be more coming up but if you find this useful and have further ideas about how this can be improved and used in your daily tasks, please let us know. NAVDiag1-3

NAV Developer

Lars Lohndorf-Larsen — Fri, 16 Dec 2016 08:23:20 GMT

Is still around. Currently evaluating the need to start posting again around topics of NAV Support / Supportability with content from the NAV product support teams. And welcoming comments about what challenges and tools exist in the world of NAV support!