Data Access Redesign in Dynamics NAV
One of the features introduced with Microsoft Dynamics NAV 2013 revolved around the redesign of the data access layer between the Dynamics NAV Service Tier and the SQL Server RDBMS. The intent of this change was to align to the ADO.NET interface in order to support advanced features within SQL Server.
Some of the new features introduced with this change:
1. Reduced Resource Consumption – in earlier version of Microsoft Dynamics NAV, the system would create a connection to the SQL Server for each end-user in the NAV system. In SQL Server this translated to roughly 40 MB of memory consumed per connection. The new version of NAV now uses connection pooling to limit the number of connections to the SQL Server by re-using the same connection by user
2. Caching – The caching of the system was changed and introduced two new types of cache’s – the Global and Private cache. The setting and behavior of the caching can be modified by updating the Data Cache Size setting in the service tier configuration file. Synchronization between multiple service tiers also occurs and can be changed by specifying the interval in the CacheSynchronizationPeriod value in the service tier configuration file.
3. Multiple Active Results Sets (MARS) – MARS was introduced with SQL Server 2005 to alleviate some of the issues that developers had with connection pooling and is the default processing mode for SQL Server data access API’s. This technology allows for more than one pending request under a SQL connection. MARS has also proven to be faster than server-side cursors for many operations within the SQL Server environment.
4. Performance – On top of the other enhancements, performance around the SumIndexFlowTechnology (SIFT) indexes has also been enhanced. COUNT and AVERAGE formula’s in the NAV system now use the SIFT indexes. MIN and MAX formula’s now directly map to SQL Server MIN/MAX functions. Bulk inserts, a technology that saves all inserts until the end of the transaction, has been updated so that RECORDID and VARIANT data types on the table no longer prohibit this functionality. And FlowFields have been enhanced to execute in a single statement instead of a statement for each filtered FlowField and for each record in the table.
The introduction of this new data access layer has also created complexity for some existing customers that have used features in the prior version(s) of NAV but are no longer supported:
1. Login Stored Procedure – the login stored procedure (sp_$ndo$loginproc] allowed for developers to perform predefined functions when a user log’s into the Dynamics NAV environment. This feature still works in the development environment, but does not work for the NAV 2013 R2+ service tier (users in the RoleTailored Client cannot use this feature).
2. Index Hinting – the index hinting capability in prior versions of NAV has been removed – you can no longer specify a specific index to use within the application.
3. Performance Analysis – performance analysis of connections in the environment do not map one-to-one to users as connection pooling is being used. In order to understand a transaction in the system, the user must either be isolated into another environment by themselves for the test to be run (so that SQL Profiler can catch the transaction information), or there is a feature in the new debugger called “Start Full SQL Tracing” which adds additional information to each query that SQL Profiler can then catch – this information can then be saved into a table for further analyses.
With all of these changes, the Dynamics NAV system has seen substantial performance increases from NAV 2009. These technologies have also been refined in the newest version of the product (NAV 2015 as of this posting). If you’re on a version prior to NAV 2013 R2, I highly recommend that you reach out to your partner to see how these “under the hood” changes can really benefit your organization – especially if you are running into any type of performance issue in your environment!