web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics AX (Archived) / Data Migration through...
Microsoft Dynamics AX (Archived)

Data Migration through DIXF becomes slower as the data gets filled.

(0) ShareShare
ReportReport
Posted on by Vishnu Prakash 65

Hi,

I have been facing an issue of migration becoming slower and slower as the data gets filled into the table. The versions are AX 2012 R3 and SQL 2016. When i perform the "Copy data to Target" step of DIXF for table CustQuotationTrans then only i feel the issue. For all other tables e.g. SalesQuotationTable, SalesQuotaitonLine and CustQuotationJour, its working very well.

When the table is empty and i start migration then it starts with very good speed of around 200 records per second but after around 100,000 records, it gets 100 records per second and then keeps on decreasing as the table gets filled on. There are around 50,00,000 records which i have to migrate.

I am, already running it in Batch with 8 tasks. So far, i have tried the below steps:

1) Table CustQuotationTrans has total 10 non-unique index. There was not any fragmentation issue on any index but still i rebuilt all indexes in the table but couldn't see any improvement.

2) I have tried disabling all indexes resulting which all index got deleted except Clustered index on RecId on SQL side but still couldn't see any improvement.

3) I made validate property NO on all relations on this table to disable all FKs but no improvement.

4) There is 12 GB memory allocated to this SQL server and 12 GB to another SQL server and still 8 GB free (DEV server: Total 32 GB) so there shouldn't be any memory issue too.

5) I have tried unchecking "Run business logic in Insert and Update" and "Run Business Validation" checkboxes but didn't make difference.

There must be surely something on the table side as the speed is getting deteriorating as the data is getting filled in table. Please suggest me any other solution which you think might work here.

Thanks

Vishnu

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Ajit Profile Picture
    Ajit 8,788 on at

    Cleanup your staging table.

  • Suggested answer
    Vilmos Kintera Profile Picture
    Vilmos Kintera 46,149 on at

    12 GB sounds undersized to me, we are operating with 256 GB RAM within our SQL Server cluster for each instances and sometimes still see Page life expectancy warnings coming from SCOM. You must be having both internal and external memory pressure affecting your overall performance.

    Cleaning up the table certainly helps, but also make sure you do not have fragmented indexes, and keep statistics updated on the table within SQL Server to ensure the query execution plan stays up-to-date for fetching the correct amount of records. You may do online index rebuild with the Enterprise Edition of SQL Server.

  • Vishnu Prakash Profile Picture
    Vishnu Prakash 65 on at

    Thanks Ajit for the answer but it didn't resolve the issue.

  • Vishnu Prakash Profile Picture
    Vishnu Prakash 65 on at

    Thanks Vilmos for the answer. The memory should not be a problem because the same issue persists in TEST server where the memory is around 24 GB for this SQL server AND there is no performance issue with other tables. I have checked the index fragmentation in Staging table too (Already checked in Target table) and there also no issue on fragmentation. Also, the statistics are up todate.

  • Suggested answer
    Vilmos Kintera Profile Picture
    Vilmos Kintera 46,149 on at

    I would still check for any resource hogs just in case to make sure you have no internal/external memory pressure, or I/O bottleneck for the disks.

    Also make sure you have SQL Server set up as per best practices, i.e. by having multiple TempDB data files, separating AX databases' data and log files to separate disk volumes with dedicated IO controller paths, setting the correct Trace Flags for SQL Server, and the usual performance optimizations.

    https://blogs.msdn.microsoft.com/axinthefield/top-10-issues-discovered-from-dynamics-ax-health-check/

    If all of the above are set up correctly, the best would be to collect an AX Trace and SQL Server Profiler data capture to see what is really going on.

    I would still suspect lack of resources, sub-optimal settings for performance, or weak hardware.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the March Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Basit Profile Picture

Basit 1

#1
GL-01081504-0 Profile Picture

GL-01081504-0 1

#1
Roya Profile Picture

Roya 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans