SyteLine SQL Server Maintenance Guide
SyteLine SQL Server maintenance is the recurring set of database tasks that keep an Infor SyteLine or CloudSuite Industrial environment fast, recoverable, and provably intact: verified backups matched to the recovery model, index and statistics maintenance on high-churn transaction tables, regular integrity checking, and disciplined purging of history. Most SyteLine performance emergencies trace back to one of these being absent rather than to any application defect. This guide sets out what to run, how often, and which SyteLine-specific tables demand more attention than a generic maintenance plan will give them.
Backups and Recovery Model Fundamentals
Decide your acceptable data loss window first, then configure the recovery model to match. If losing a day of transactions is unacceptable - and for most manufacturers it is - run the full recovery model with regular transaction log backups, typically every fifteen to thirty minutes. Sites that run full recovery without log backups are the single most common cause of a transaction log that grows until the drive fills and SyteLine stops accepting transactions. Back up the application database, the associated object and forms databases, and the SQL Server system databases, since a restore missing metadata leaves you with data you cannot present. Verify backups by restoring to a test server on a schedule, not by trusting the job history.
- Match recovery model to your acceptable data loss window, then implement matching log backups
- Run transaction log backups every 15-30 minutes under the full recovery model
- Back up application, object, and forms databases together with SQL system databases
- Prove recoverability by restoring to a test server on a schedule, not by reading job history
Index and Statistics Maintenance on High-Churn Tables
SyteLine transaction tables such as matltran, jobtran, and ledger fragment quickly under continuous insert and update activity, and their statistics go stale long before SQL Server auto-update thresholds trigger on tables with tens of millions of rows. Use a threshold-based maintenance script rather than a blanket weekly rebuild: reorganize at moderate fragmentation, rebuild at high fragmentation, and skip small tables entirely. Update statistics far more frequently than you rebuild indexes, because stale statistics cause bad plans and bad plans cause the slowness users actually feel. Schedule maintenance outside MRP, posting, and month-end windows so it does not compete for the same pages and locks as production work.
- Use fragmentation thresholds to choose reorganize versus rebuild instead of rebuilding everything
- Update statistics on large transaction tables far more often than you rebuild indexes
- Exclude maintenance windows from MRP, posting, and month-end processing schedules
- Skip tables below a few thousand pages, where fragmentation has negligible impact
Integrity Checks and Corruption Detection
Run DBCC CHECKDB on a defined schedule, weekly for most SyteLine environments, and treat a failure as an immediate incident rather than an item for the next maintenance window. Confirm the database page verification option is set to CHECKSUM so torn pages are detected when read rather than silently propagated into every subsequent backup. Configure SQL Server Agent alerts for severity 19 through 25 errors and for error numbers in the 823 to 825 range, which indicate I/O problems that frequently precede detectable corruption. Corruption discovered after it has been present through an entire backup retention cycle is the difference between a routine page restore and reconstructing transaction history by hand.
Purging and Archiving SyteLine History
SyteLine databases grow relentlessly because transaction history, background task history, and event and audit logs accumulate indefinitely unless someone purges them. Establish a documented retention policy with finance, quality, and legal before deleting anything, and be conservative in regulated aerospace and defense environments where contract and traceability requirements can require decades of retention on lot and serial history. Purge low-risk operational data first: background task history, completed job queue detail, and expired session records rarely need more than a year. Archive rather than delete where retention is uncertain, and always run purges in bounded batches so a single large delete cannot fill the transaction log and stop production.
How Netray AI Agents Keep SyteLine Databases Healthy
Netray database agents continuously monitor SyteLine growth rates, fragmentation, statistics age, backup success and restore verification, and integrity check currency, then alert on the gaps that matter instead of producing another dashboard nobody opens. They project when a filegroup will run out of space based on actual growth trend rather than a fixed threshold, and they flag maintenance jobs that are reporting success while silently skipping the largest tables - a failure mode that hides for months. Customers typically eliminate the recurring emergency of a full transaction log or an out-of-space drive entirely within the first quarter. The agents also correlate maintenance activity against user-facing slowness, confirming whether a Monday morning complaint traces to a weekend rebuild that overran its window.
Frequently Asked Questions
How often should I run index maintenance on a SyteLine database?
Use a threshold-based script weekly rather than a blanket rebuild. Reorganize indexes at moderate fragmentation, rebuild at high fragmentation, and skip small tables where fragmentation has negligible effect. Update statistics much more frequently than you rebuild, because stale statistics on tables like matltran and jobtran produce bad execution plans well before auto-update thresholds trigger on tens of millions of rows. Schedule all of it outside MRP and posting windows.
Why does my SyteLine transaction log keep filling up?
Almost always because the database is in the full recovery model with no transaction log backups running, so the log can never truncate and grows until the drive fills. Either implement log backups every fifteen to thirty minutes, which is what most manufacturers need for recoverability, or move to simple recovery if losing a day of transactions is genuinely acceptable. Large unbatched purge deletes are the second common cause.
What SyteLine data is safe to purge?
Background task history, expired session records, and completed queue detail are typically safe beyond a year and provide the largest early wins. Transaction history, lot and serial traceability, and financial detail require a documented retention policy agreed with finance, quality, and legal first. In aerospace and defense environments, contract and traceability requirements can mandate decades of retention, so archive rather than delete whenever retention is uncertain.
Key Takeaways
- 1Backups and Recovery Model Fundamentals: Decide your acceptable data loss window first, then configure the recovery model to match. If losing a day of transactions is unacceptable - and for most manufacturers it is - run the full recovery model with regular transaction log backups, typically every fifteen to thirty minutes.
- 2Index and Statistics Maintenance on High-Churn Tables: SyteLine transaction tables such as matltran, jobtran, and ledger fragment quickly under continuous insert and update activity, and their statistics go stale long before SQL Server auto-update thresholds trigger on tables with tens of millions of rows. Use a threshold-based maintenance script rather than a blanket weekly rebuild: reorganize at moderate fragmentation, rebuild at high fragmentation, and skip small tables entirely.
- 3Integrity Checks and Corruption Detection: Run DBCC CHECKDB on a defined schedule, weekly for most SyteLine environments, and treat a failure as an immediate incident rather than an item for the next maintenance window. Confirm the database page verification option is set to CHECKSUM so torn pages are detected when read rather than silently propagated into every subsequent backup.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
SyteLine Go-Live Readiness Checklist
Thirty expert checks across data, testing, people, technical, and cutover workstreams to tell you whether your SyteLine go-live is actually ready.
Free ToolERP Performance Health Check
A 10-question assessment of screen response, batch runtimes, database maintenance, and monitoring that grades your ERP performance posture.
Free ToolSyteLine Implementation Cost Calculator
Estimate the full first-year cost of an Infor SyteLine implementation, including licensing, services, data migration, and internal effort.
Terms used in this article
Find out whether your SyteLine maintenance jobs are actually working - Netray AI agents verify backups, integrity checks, and index jobs continuously.
Related Resources
SyteLine Performance Troubleshooting: A Systematic Guide
A systematic SyteLine performance troubleshooting guide: isolate the client, IDO Runtime, or SQL Server layer, then fix the tier that is causing slowness.
Infor SyteLineFixing Slow SyteLine Reports
Fix slow SyteLine reports by separating queue time from execution time, reading SSRS execution logs, tuning the dataset query, and scaling task processing.
Infor SyteLineResolving SyteLine Replication Failures
Resolve SyteLine replication failures: understand the queue, triage stuck records, fix linked server and service account issues, and reprocess safely.