# ERP Database Health Check Checklist > Source: https://netray.co/tools/erp-database-health-check-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A quarterly checklist for the database under your ERP: recovery, integrity, performance, capacity, security and operations. ## Category developer ## Audience - ERP administrator - DBA - IT manager ## Tool **Kind:** checklist **Groups:** #### Recovery and backups **Items:** **Text:** Full, differential and log backup schedule matches the agreed recovery point objective **Critical:** true **Text:** Backups are copied to a second location that a server failure cannot take with it **Critical:** true **Text:** A restore to a test server was performed and timed in the last 6 months **Critical:** true Backup job failures send an alert to a monitored mailbox or channel System databases (master, msdb, model) are backed up Backup retention matches the audit and legal retention policy **Text:** Recovery model of each database matches the log backup practice **Critical:** true Backup encryption keys and certificates are stored and recoverable separately #### Integrity and maintenance **Items:** **Text:** Integrity checks (CHECKDB or equivalent) run at least weekly and results are reviewed **Critical:** true Index maintenance is selective by fragmentation and size rather than rebuilding everything Statistics are updated regularly, with extra updates after large loads **Text:** Auto-shrink is off and auto-close is off on the ERP database **Critical:** true Page verification is set to the checksum option Maintenance jobs have an owner and a documented window that avoids month-end close Failed or long-running jobs from the last 30 days were reviewed #### Performance and concurrency **Items:** Top waits and top queries by reads and duration were reviewed for the busy period Blocking and deadlock history was checked and recurring causes logged Long-open transactions were checked and the owning applications identified Parallelism settings (MAXDOP and cost threshold) were reviewed for the hardware Memory is capped so the operating system has room, and no memory pressure is recorded Tempdb has multiple equally sized data files on fast storage Custom reports run against a replica or reporting copy, not the live ERP tables where possible Query tuning changes are logged with before and after timings #### Capacity and storage **Items:** **Text:** Data and log file sizes and growth over the last 12 months are recorded **Critical:** true **Text:** Free space on every volume is above the agreed minimum, with an alert before it runs out **Critical:** true Autogrowth is set in fixed sizes, not tiny percentages Largest tables and the reason for their growth are known (audit logs, attachments, interface staging) Archive or purge rules exist for logs, staging and temporary data Forecast of when storage or licences hit their limits is documented #### Security and access **Items:** **Text:** Server and database patching level is supported and a patch plan exists **Critical:** true **Text:** Accounts with sysadmin or equivalent rights were reviewed and are justified **Critical:** true Service and integration accounts use least privilege and have owners Former employees and consultants have no remaining database logins Direct database access for reports is read-only and logged where possible Connections to the database are encrypted and the ERP vendor requirements are met #### Monitoring and documentation **Items:** **Text:** Alerts exist for failed jobs, low disk space, long blocking and high severity errors **Critical:** true Runbook documents how to restore, fail over and contact the ERP vendor Database inventory lists each ERP database, version, size and owner Changes to database settings are tracked in change control Findings from this review are assigned to named people with dates **Scoring Note:** Count completed items against the total. Any unchecked item marked critical should be fixed or formally accepted by the business owner before the next period close. ## Content **Intro:** Most ERP database outages come from things that were known and not checked: an untested backup, a full disk, a missed integrity run. Use this checklist each quarter to catch them early. **Sections:** #### How to use the checklist **Body:** Work through the groups with the person who administers the database and the person who owns the ERP. Tick an item only when you have seen the evidence, such as a job history screen or a file listing, not when someone says it is probably fine. Items marked critical protect against data loss or outage. Export the result to PDF or Excel, assign owners to the gaps and set dates. Repeat quarterly and before any upgrade or major go-live. #### Why these checks **Body:** Recovery comes first because an untested backup is only a hope. Integrity checks find corruption while it is still in a single page rather than in every backup. Capacity checks prevent the classic Friday-night full disk caused by an interface staging table. Performance and concurrency items focus on repeated causes in ERP workloads, such as long reports, cursor-based integrations and idle open transactions. Security items matter because the ERP database holds payroll, pricing and customer data. #### Scoring and follow-up **Body:** There is no pass mark that fits every plant. A reasonable approach is to require all critical items, then aim for at least 80 percent of the rest. Unchecked critical items should either be fixed within the quarter or have a written risk acceptance from the business owner. Keep the previous checklists, since trends such as growing log tables or increasing restore times tell you more than a single snapshot. #### Common mistakes **Body:** Checking that a backup job succeeded rather than that a restore works is the most frequent error. Others include shrinking files on a schedule, rebuilding all indexes nightly regardless of need, giving the ERP application account sysadmin because it was easier, and ignoring the msdb job history that holds the evidence. Also confirm which team owns the database when it is hosted by a vendor or partner, so tasks do not fall between teams. **Cta:** If you want a second pair of eyes on your ERP database or a monitoring setup that reports on these items, we can help review it. **Faq:** #### How often should an ERP database be health checked? **Answer:** Quarterly is a good baseline, plus before upgrades, migrations or peak seasons. Backup success, disk space and job failures should be monitored daily through alerts rather than waiting for a review. #### Do I need a DBA to use this checklist? **Answer:** An ERP administrator can complete most items with the DBA or hosting provider supplying evidence. The security, recovery model and performance items benefit from DBA review. #### Why is shrinking the database a problem? **Answer:** Shrinking fragments indexes and the file grows again afterwards, wasting I/O. Do it only as a one-off after a large purge, and then rebuild affected indexes. #### What matters most if time is short? **Answer:** Test a restore, confirm integrity checks run, and set alerts on disk space and failed jobs. Those three prevent the most painful and avoidable ERP outages. ## Search terms erp database health check, sql server health check checklist, erp database maintenance checklist, database capacity planning checklist, erp dba checklist, restore test checklist, erp database security review, quarterly database review erp --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json