TABLE OF CONTENTS
- •Let's find out why your ERP is slow
- •From Symptom to Source at a Glance
- •1. Is the Problem in the Database?
- •2. Blocking: The Most Common Cause in ERPs
- •3. Month-End and Period Close
- •4. Growing Data and Maintenance
- •5. Hardware and Edition Limits
- •6. Working with the Application Vendor
- •Quick Diagnostic Checklist
- •ERP Database Performance with Aryasoft
- •Frequently Asked Questions
- •Sources
- •Make your ERP fast again
ERP slowness isn’t always caused by the database, but in ERP systems running on SQL Server most slowdowns start in the database layer: blocking transactions, heavy reports running at peak hours, growing tables and missing indexes, undersized hardware or edition limits. To know whether the problem really is in the database, you have to look at measurements, not symptoms. This guide helps you diagnose your ERP users’ “the system is slow” complaints step by step.
The guide is for IT and system administrators at organizations running Microsoft Dynamics, Turkish ERPs such as Logo and Mikro, or any other ERP on SQL Server. It focuses on the database behavior ERPs have in common, not on one product.
Let's find out why your ERP is slow
Aryasoft's senior SQL Server experts examine your ERP database, show the source of the slowdown with evidence and apply the fix while respecting the vendor's support terms.
From Symptom to Source at a Glance
| Symptom | Likely source | First check |
|---|---|---|
| Everyone slows down at once, then it recovers | Blocking: one transaction makes the others wait | Running requests and the blocking chain |
| The system locks up at month-end or period close | Heavy closing jobs and reports running at the same time | Jobs and reports running during the close |
| One report or screen is very slow | An inefficient query, a missing index | The query that screen runs and its execution plan |
| The system got gradually slower over months | Growing tables, unarchived data, stale statistics | Table sizes and the state of maintenance jobs |
| Only certain branches or users are slow | Network latency, a terminal server or client problem | The duration of the same action from different locations |
| It slowed down after an upgrade | An execution plan change, compatibility level | Query Store, release notes |
1. Is the Problem in the Database?
The first job with ERP slowness is to isolate the layer the problem sits in. ERP systems usually have client, application or terminal server, network and database layers. These questions narrow down the source:
- Is the same action also slow when run from somewhere close to the database server, for example a server in the same data center?
- During the slowdown, do the database server’s CPU, disk and memory look different from normal?
- Are there long-running or waiting queries in the database?
If the database shows no waits and no load, the problem is most likely in the network or the application layer. ERP screens that send many small queries are very sensitive to network latency, especially for clients connecting from remote branches.
2. Blocking: The Most Common Cause in ERPs
In ERP systems many users write to the same tables (stock, accounts, invoices) at the same time. When a long transaction holds locks on these tables, the other users wait and the system looks frozen. The query below shows the session that makes others wait but waits on nobody itself, the head of the chain:
SELECT s.session_id,
s.login_name,
s.host_name,
s.program_name,
r.status,
r.wait_type,
DATEDIFF(SECOND, COALESCE(r.start_time, s.last_request_start_time), GETDATE()) AS running_sec,
t.text AS last_statement
FROM sys.dm_exec_sessions AS s
LEFT JOIN sys.dm_exec_requests AS r ON r.session_id = s.session_id
OUTER APPLY sys.dm_exec_sql_text(COALESCE(r.sql_handle,
(SELECT c.most_recent_sql_handle FROM sys.dm_exec_connections AS c
WHERE c.session_id = s.session_id))) AS t
WHERE s.session_id IN (SELECT blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id <> 0)
AND s.session_id NOT IN (SELECT session_id FROM sys.dm_exec_requests WHERE blocking_session_id <> 0);
The host_name and program_name columns show which user and which module the lock-holding transaction comes from. A common case is a session in the “sleeping” state that still holds an open transaction: the user started something but didn’t finish it, and the application didn’t close the transaction.
Warning
Always check what a session is doing before you kill it in an ERP database. An interrupted invoice or stock transaction can hold locks even longer while it rolls back. If you can, contact the user who started it and make the decision with the application owner.
3. Month-End and Period Close
At period close, heavy work such as cost calculation, stock valuation and financial reports runs at the same hours. In one case at a manufacturer, the month-end report locked up the whole system; the session at the head of the chain was identified and killed, and the system was back to normal in 12 minutes. The report was then tuned, and its run time dropped from 4 hours to 19 minutes.
Recommendations for closing periods:
- Schedule heavy reports and batch jobs outside peak hours.
- Move the reporting load to a separate reporting database or a readable replica if you can.
- Make sure statistics and index maintenance have finished before the close.
- Measure the longest closing jobs and put them at the top of the tuning list.
4. Growing Data and Maintenance
ERP databases keep growing over the years: transaction tables, log tables and data from past periods. Data that hasn’t been deleted or archived for years increases the amount of data queries scan and the time maintenance takes.
| Check | Why it matters |
|---|---|
| Largest tables and growth rate | Shows which tables are candidates for archiving or partitioning. |
| Statistics freshness | Stale statistics lead the query optimizer to pick the wrong plan. |
| Index fragmentation and maintenance jobs | Maintenance jobs may have been failing silently. |
| Log file size | In databases without log backups, the log keeps growing. |
| tempdb usage | Heavy reports use tempdb intensively. |
We explain how to set up maintenance jobs in our SQL Server maintenance plans guide.
5. Hardware and Edition Limits
In small and medium-sized businesses, ERPs sometimes run on SQL Server Express. Express limits database size (50 GB in SQL Server 2025), memory and CPU use, and as data grows those limits turn directly into performance problems. Standard edition also has limits on the cores and memory it can use.
On virtual servers, the resources assigned to the virtual machine and the resources SQL Server can actually use may differ. On shared storage, disk latency is a common but overlooked cause of ERP slowness. Going to the virtualization and storage team with measurements such as IOPS, latency and queue length speeds up the fix. For details, see our posts on how many CPUs SQL Server can use and disk storage.
6. Working with the Application Vendor
Changes to an ERP database must be compatible with the application vendor’s support terms:
| Change | What to watch |
|---|---|
| Adding a new index | Usually improves performance noticeably, but vendor updates may drop it or conflict with it. Document the indexes you add and check them after updates. |
| Changing tables or columns | Don’t. It breaks the schema the application expects and puts your support rights at risk. |
| Server and database settings | Settings such as memory, parallelism and tempdb are usually independent of the application; review them alongside the vendor’s recommendations. |
| The query itself | Only the vendor can change a query inside the application. Send the problem query to the vendor with evidence. |
Tip
When you report a performance problem to the vendor, offer concrete evidence instead of “the system is slow”: which screen or report, which query, how many seconds it takes, how many reads it does and its execution plan. Reports that come with evidence get resolved much faster.
Quick Diagnostic Checklist
- Is the slowdown for everyone, or for one screen or location?
- Is there a blocking chain during the slowdown, and which session is at its head?
- Are CPU, disk latency and memory normal on the database server?
- How many reads does the slow screen’s query do, and which indexes does it use?
- Have the maintenance jobs (backups, indexes, statistics) run successfully in recent days?
- Has there been an application update, a SQL Server upgrade or a server change recently?
- Is the system close to the limits of its SQL Server edition (Express, Standard)?
You’ll find the diagnostic flow in detail, with queries, in our SQL Server performance troubleshooting guide.
ERP Database Performance with Aryasoft
Aryasoft works with a senior team specialized in the database layer of ERP systems running on SQL Server. We show the source of the slowdown with measurements, bring emergencies under control and apply a lasting fix that respects the application vendor’s support terms. Service details are on our SQL Server consulting page.
Frequently Asked Questions
Sources
The technical details in this guide were checked against the following official documentation in November 2026.
- Microsoft Learn: Understand and resolve SQL Server blocking problems
- Microsoft Learn: sys.dm_exec_sessions
- Microsoft Learn: Editions and supported features of SQL Server 2025
- Microsoft Learn: Statistics
ERP Database Performance
Make your ERP fast again
Aryasoft shows the source of the slowdown with measurements and applies a lasting fix that respects the vendor’s support terms.