A quick guide to install, configure, deploy, and administer Dynamics NAV with ease
Read more about this book
(For more resources on Microsoft see here.)
In the Classic database server option, SIFT (Sum Index Flow Technology) is used to make the calculation of balances, sums, and so on. In any other database, this is normally done through calculations and could be a time-consuming process if there are thousands of records in the table. The SIFT data is stored in indexes, which are also called secondary keys in the Classic database server option. The balances based on the “secondary keys” are stored in separate indexes in the database. The programmer can define which fields need calculation by defining the SumIndexFields for the keys, as represented in the following screenshot. Therefore, the retrieval time for things such as account balances and such others is minimal, making the application extremely fast:
What gives a boost to SIFT is the ability to filter on the underlying values that make up SIFT balances. This technology is also known as the flow filter technology, which complements the basic SIFT technology in a significant way.
When SIFT was initially implemented on the Microsoft SQL Server database option for Dynamics NAV, it was done by storing these SIFT columns in summarized tables called SIFT tables that were continuously updated through SQL triggers. Thus, the procedure was expensive and took a toll on the performance when a table containing SIFT indexes was updated.
From the Dynamics NAV 5.0 Service Pack 1 version, Microsoft decided to use indexed views in SQL Server instead of SIFT tables. Dynamics NAV creates one SQL indexed view per key, regardless of how many sum indexed fields there are in that key. Having too many SIFT indexes can adversely affect the performance of the application.
Having too many fields in the SIFT indexes is also not advisable.
The MaintainSIFTIndex property of the index in the base table could be used to optimally design the SIFT indexes. If there is the possibility of the base table not growing so rapidly, it is recommended to keep the MaintainSIFTIndex property to No.
For more information about SQL indexed views, we can refer to the Microsoft SQL library.
Maintaining indexes for Microsoft Dynamics NAV has also been seen as a big performance issue. This is one of the major reasons for performance issues in the Dynamics NAV Classic database. The Microsoft SQL Server is clever enough to sort the data without any index, if the dataset being sorted is not huge.
To access these properties of the keys, go to Object Designer, highlight the table in which the key needs to be modified, click on Design to open the list of fields in the table, and go to View | Keys. A window similar to the following screenshot opens, showing the list of keys:
To open the properties of a particular key, highlight the key and then click on View| Properties, as shown in the following screenshot:
These indexes or keys could be used optimally by using the following properties of the keys:
For example, in the following screenshot we see that the, Key Group property is defined as Consol, which is one of the key groups in the database.
Keys can be combined together based on the nature of the use of keys or a particular application area.
To enable or disable a key group, go to File | Database | Information. Click on the Key Group button in the bottom of the Database Information form to open a list of key groups defined in the database.
In Dynamics NAV and also in a SQL Server database, a primary key is a clustered index by default.
There are a few key performance troubleshooting techniques that are effective in identifying the bottlenecks in the performance of the database.
Monthly digest of what's new and exciting from us.
© 2023 Company, Inc. All rights reserved.
Cookie Policy and Privacy Policy
source
