{"id":43344,"date":"2014-11-12T08:00:00","date_gmt":"2014-11-12T08:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/nav\/2014\/11\/12\/microsoft-dynamics-nav-faster-than-ever\/"},"modified":"2023-05-31T15:46:06","modified_gmt":"2023-05-31T22:46:06","slug":"microsoft-dynamics-nav-faster-than-ever","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/dynamics-365\/blog\/no-audience\/2014\/11\/12\/microsoft-dynamics-nav-faster-than-ever\/","title":{"rendered":"Microsoft Dynamics NAV: Faster than ever."},"content":{"rendered":"
<\/p>\n
First,\u00a0let me start by saying that\u00a0based on\u00a0the\u00a0evidence so far: It is. Significantly.<\/p>\n
A number of the changes to the Dynamics NAV 2013 architecture contribute to the performance boosts that many of the test have shown. To outline some of the changes:<\/p>\n
\u2026 and more.<\/p>\n
However(!), a few things have surfaced in the course of time that are not as explicitely documented as the changes above, nor as apparent, and might\u00a0have unexpected side effects. I have collected some of the side effects that you might or not be aware of and that might leave you panicking if not certain what you\u2019re facing.<\/p>\n
<\/p>\n
<\/p>\n
Consider the following example. This is just an illustration of the problem, constructed on CRONUS extended database:<\/p>\n
A lot of Inventory transactions are\u00a0posted through\u00a0the Item Journal,\u00a0generating a lot of Post cost to the G\/L Entry. After this, when browsing an item list and opening an Item card, the page opens very slowly.<\/p>\n
After locating the offending query in the\u00a0SQL profiler and running it isolated in Microsoft SQL Server Management Studio with \u2018Include Actual Execution Plan\u2019 option enabled, the plan looks similar to the one shown below:<\/p>\n
\u00a0 \n Each sub-query shows reasonably (small) percentage of cost and no apparent reason for bad execution plan. There are no obvious extreme costs, however there is a Clustered Index Scan here:<\/p>\n Looking at the filter that SQL Server applies, namely it filters on \u201cPost Value Entry to G_L\u201d. \u201cItem_No_\u201d = \u201cItem\u201d.\u201dNo_\u201d:<\/p>\n \u00a0 \n Although SQL Server reports Operator Cost as small, it shows CPU Cost in excess of 2.3 in approx. 1.94 executions. So, it is likely scanning the table twice and unfortunately the table has 4,7 million rows.<\/p>\n Although it is not obvious from the actual SQL Server execution plan that this is a problem, profiling with the SQL Server Profiler reports the query to use more than 5 seconds of CPU, while doing 131.519 reads to fetch 52 rows:<\/p>\n<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n