# How to Improve SQL Server Performance for a Slow SyteLine ERP System > Source: https://netray.co/erp-help/syteline-sql-server-performance-tuning > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Most SyteLine performance complaints trace back to a handful of SQL Server issues: stale statistics, missing indexes on high-churn IDO tables, blocking caused by the default isolation level, and IDO Runtime connection pool exhaustion. Working through those systematically, with DMV evidence, resolves the majority of slow system tickets faster than guessing at application-layer causes. ## Kind advanced ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module System Administration / Database Performance ## Query how to improve SQL Server performance for a slow SyteLine ERP system ## Alternate Queries - syteline running slow SQL server tuning - syteline blocking and deadlocks sql server - csi sql server index maintenance recommendations - syteline read committed snapshot isolation performance ## Applies To SyteLine 8.x/9.x and CloudSuite Industrial on SQL Server 2016 and later, on-prem or IaaS-hosted. ## Steps ### Diagnose and fix SQL Server bottlenecks under SyteLine **Items:** Confirm SQL Server statistics are up to date on the busiest tables, order lines, inventory transactions, job routing tables; stale statistics are the most common cause of a query plan suddenly going bad once data volume grows past what the last update reflected. Enable Read Committed Snapshot Isolation, RCSI, on the SyteLine database if not already on; the default read committed isolation level's reader/writer locking behavior is a frequent source of blocking in busy environments, and RCSI removes most of it at the cost of tempdb overhead. Query the missing index and index usage DMVs to find high-impact missing indexes on tables the IDO layer queries heavily, rather than guessing which table is the problem. Check for blocking chains during peak hours using sys.dm_exec_requests and sys.dm_os_waiting_tasks, and identify the head blocker rather than just the longest-waiting session, since fixing the wrong session does nothing. Review the IDO Runtime's connection pool and command timeout settings; an undersized pool causes connection waits that look identical to SQL Server is slow but are actually an application-tier configuration limit. Check tempdb configuration, multiple data files, adequate sizing, since IDO Runtime and APS/MRP batch processes both lean on tempdb for sorts and intermediate work. Schedule index maintenance, rebuild or reorganize based on fragmentation level, and statistics updates during a low-usage window, and confirm the job actually completes rather than assuming it does because it exists. Baseline query performance with Extended Events or Query Store before and after each change, so you can prove which fix actually mattered instead of relying on subjective it feels faster. ## Sections ### RCSI and why SyteLine is sensitive to locking **Body:** SyteLine's IDO layer generates a high volume of short read and write transactions from many concurrent users and integrations, which makes it more sensitive to reader/writer blocking under the default read committed isolation level than a typical low-concurrency application. Enabling Read Committed Snapshot Isolation lets readers see a consistent snapshot instead of waiting on writer locks, one of the highest-leverage single changes for a busy environment, though it increases tempdb load and should be tested under representative volume first. ### Finding the real bottleneck with DMVs instead of guessing **Body:** Dynamic management views are the fastest path to an evidence-based diagnosis: missing index DMVs point at queries that would benefit from an index that does not exist yet, wait statistics show whether the server is CPU-bound, I/O-bound, or blocked, and query stats DMVs surface the specific statements consuming the most cumulative time. Fixing based on DMV evidence, rather than the loudest complaint in the office, avoids spending a maintenance window on a change that does not move the needle. **Code:** SELECT TOP 20 qs.total_worker_time / qs.execution_count AS avg_cpu_time, qs.execution_count, SUBSTRING(st.text, (qs.statement_start_offset/2)+1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) AS statement_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st ORDER BY avg_cpu_time DESC; ### IDO Runtime connection pooling and timeouts **Body:** The IDO Runtime maintains a pool of SQL connections to service concurrent IDO calls, and an undersized pool or an overly aggressive command timeout can present to end users as intermittent slowness or timeout errors that look exactly like a SQL Server problem but are actually an application-tier configuration limit. Review the runtime's connection and timeout settings alongside actual concurrent user counts and adjust incrementally, watching for the point where increasing the pool stops improving throughput, which usually means the real bottleneck has moved back to SQL Server. ### Index and statistics maintenance discipline **Body:** High-churn IDO-backed tables, order lines, inventory transactions, job transactions, fragment and drift out of date faster than reference tables, so a maintenance plan that treats every table identically either wastes time on tables that do not need it or under-maintains the tables that matter most. Segmenting maintenance by table churn rate, and confirming the job actually completes within its window rather than getting silently skipped, keeps the statistics the optimizer relies on accurate. ## Pitfalls - Assuming the ERP is slow is an application problem and never checking SQL Server wait statistics or blocking before making changes. - Leaving the database on the default read committed isolation level in a busy multi-user environment without evaluating RCSI. - Running maintenance plans that silently fail or get skipped due to a shrinking maintenance window as data volume grows. - Adding indexes based on intuition rather than missing-index DMV evidence, which can bloat write-heavy tables without measurably helping the queries that matter. - Undersizing the IDO Runtime connection pool and misdiagnosing the resulting timeouts as a SQL Server capacity problem. - Making several tuning changes at once during one maintenance window, making it impossible to tell which change actually fixed the slowdown. ## Ai Angle ERPray can be pointed at recent Extended Events captures and the IDO Runtime logs together, correlate a spike in user-reported slowness with a specific blocking chain or a query whose plan changed after a data volume threshold, and describe the fix in plain language instead of a DBA manually cross-referencing timestamps across two tools. For a recurring performance ticket, it can also pull up the last time the same symptom occurred and what fixed it, so the same root cause does not get rediagnosed from scratch every quarter. ## Faq ### Will enabling RCSI fix all our SyteLine blocking issues? **Answer:** It fixes reader/writer blocking, the most common kind in SyteLine, but writer/writer blocking, two transactions trying to update the same row, still occurs under RCSI, so test under real concurrency and expect it to reduce blocking significantly rather than eliminate every case. ### How often should statistics be updated on a busy SyteLine database? **Answer:** There is no single universal schedule; the right frequency depends on how fast your high-churn tables' data distribution changes, so start with SQL Server's automatic statistics updates plus a nightly job on the busiest transaction tables and adjust based on whether query plans are still going stale between updates. ### Is more RAM or CPU the fix for a slow SyteLine system? **Answer:** Sometimes, but only after DMV evidence shows the server is genuinely resource-constrained rather than blocked or waiting on a missing index; adding hardware to a blocking problem usually just delays when the symptom reappears as data volume grows. ### Can SyteLine customizations cause SQL Server performance problems? **Answer:** Yes, a poorly written IDO extension or Mongoose script that loops and issues many individual IDO calls instead of a set-based query is a common self-inflicted performance problem, and it shows up in SQL Server as a query pattern rather than a single obviously bad query. ### Where do IDO Runtime connection pool settings live? **Answer:** They are set in the IDO Runtime's configuration on the application server; the exact setting name and location vary by SyteLine version and deployment, IIS-hosted vs Windows service, so confirm the current setting with your Application Studio or server admin documentation for your specific version before changing it. ## Search terms syteline sql server slow, syteline performance tuning, csi sql server blocking, syteline read committed snapshot isolation, syteline index maintenance, syteline ido runtime connection pool, sql server dmv syteline, syteline database performance troubleshooting, syteline statistics update slow query, csi tempdb performance --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json