How to run SQL Server without a DBA

Last updated 29 October 2026 · DB24 Team

Running SQL Server without a DBA works when someone still owns a short list of recurring tasks: backups that can be restored, integrity checks, index and statistics maintenance, updates, monitoring, access and capacity. Most of the routine part can be scheduled and checked automatically. Restores, updates and decisions about risk still need a named person.

Key takeaways

Without a DBA, the tasks remain. Seven areas need an owner on every instance.
Microsoft's own guidance is that you don't have a restore strategy until you test your backups. A green backup job is where the work starts.
Backups, integrity checks, index and statistics maintenance, file growth and alerts can run automatically. Restore tests, installing updates, access decisions and capacity planning need a person.
The work can be done by an IT generalist, a consultant or managed service provider, automation, or a mix.

What has to be done when nobody is a DBA?

Backup and restore. Backups that match the data loss the business accepts. Enterprise and Standard editions use the full recovery model by default (Microsoft), and in that model the transaction log keeps growing until a log backup lets it be truncated (error 9002). Microsoft also says to test restores of every backup type you intend to use. More in When backups fail during a ransomware attack.
Integrity checks. DBCC CHECKDB checks the logical and physical integrity of every object in a database. When it reports errors, Microsoft recommends restoring from the last known good backup, so the check is only as useful as the backups you keep.
Index and statistics maintenance. Microsoft's index guidance says the benefit of rebuilding or reorganising indexes ranges "from vitally important to minuscule", and that updating statistics often gives the same gain at a much lower cost.
Updates and end of support. Microsoft "always recommends" installing the latest cumulative update for your version (servicing models). SQL Server follows the Fixed Lifecycle Policy: SQL Server 2016 left extended support in July 2026, and SQL Server 2017 follows in October 2027.
Monitoring and alerts. SQL Server Agent can raise alerts on events and performance conditions; someone has to define them, receive them and act.
Access. Roles should be granted "the minimum permissions required" (security best practices), and sysadmin membership needs a regular, dated review. Under NIS2 this becomes evidence; see NIS2 and SQL Server.
Capacity. Microsoft advises using "alerts or monitoring programs to monitor file sizes and grow files proactively" rather than relying on autogrow (autogrow guidance).

How often should each SQL Server maintenance task run?

Microsoft publishes no single weekly checklist. Frequency follows from the data loss and downtime the business accepts, and from how each database is used.

SQL Server tasks without a DBA: frequency, consequence and automation
Task	How often	What happens if it is not done	Can it be automated?
Full and differential backups	Set by the data loss the business accepts	The newest usable copy is older than expected, or missing	Yes
Transaction log backups (full recovery model)	Often enough to keep data loss within that limit	The log cannot be truncated and fills its disk (error 9002)	Yes
Restore test	For every backup type you rely on, repeatedly	Nobody knows whether a restore works or how long it takes	Partly
Integrity check (DBCC CHECKDB)	Regularly; Microsoft leaves frequency to the business	Corruption goes unnoticed until it causes data loss or an application failure	Yes
Index maintenance	Where measured benefit justifies the cost	Queries read more pages than needed, or resources are spent for little gain	Yes
Statistics updates	Automatic by default; manual where queries need fresher statistics	The optimizer works from outdated statistics and can choose poor plans	Yes
Cumulative updates	When released; Microsoft recommends the latest	Known fixes, including security fixes, are missing	Partly
End-of-support planning	Well ahead of the lifecycle date	Instances run without security updates	No
Monitoring and alerts	Continuously	Problems surface when users report them	Yes
Access review	On a schedule set by your own policy	Leavers and unused accounts keep their rights	Partly
Capacity and file growth	Continuously	Files grow in small steps at busy times, or a disk fills	Partly

How do you keep track of every instance and version?

Start with a list: every instance, its version and build, its owner and the business system it supports. On each instance, SERVERPROPERTY('ProductVersion') and SERVERPROPERTY('ProductUpdateLevel') return the build and the cumulative update level (Microsoft). Compare them with Microsoft's latest updates and the lifecycle dates. Whoever owns the list should also look for instances missing from it.

Who can do the work: an IT generalist, a consultant or automation?

An IT generalist on your own team knows the business systems and their owners. SQL Server competes with everything else on their list, and the knowledge often sits with one person. If that person leaves, so do the routines, unless they are written down.
A consultant or managed service provider brings depth a generalist rarely has: upgrades, performance problems, high-availability design and incidents. You agree the scope and pay for the time or the service. The provider also becomes part of your supply chain, which matters under NIS2.
Automation runs the same checks on every instance every night and does not depend on who is on holiday. It cannot decide what the business accepts, and it needs someone to receive the alerts.

One workable split: automation for the routine, a named internal owner for decisions, and outside expertise for upgrades and incidents.

What always needs a person?

These steps need someone with the authority to act:

Agree with the business how much data loss and downtime each system can accept.
Restore critical databases on another server, time it, and run DBCC CHECKDB on the result, as Microsoft recommends.
Decide, test and install cumulative updates, and plan upgrades before end of support.
Decide who should have access, and remove what nobody can explain.
Act on alerts and integrity errors, starting from the last known good backup.
Keep an operations manual per database with backup locations and restore times, which Microsoft also recommends.

How DB24 helps

DB24 takes over the routine part of this list on every instance, every night, and shows the rest on one page, so whoever owns SQL Server sees where to act and has a record of what was done:

Backups: DB24 can take full, differential and log backups per instance, retry failed attempts, and run RESTORE VERIFYONLY on each backup it takes; no data is restored. With another backup tool, DB24 still shows backup state per database and alerts on failed, outdated, damaged or size-deviating backups (DB24 Backup).
Maintenance: integrity checks with DBCC CHECKDB, index maintenance based on fragmentation and page density, statistics updates past age and change thresholds, and data and log files grown before they run short. Everything runs inside your maintenance windows, checks disk space first and is logged, and confirmed corruption raises a critical warning at once (maintenance).
Versions and patch status: version, build and patch status per instance, in lifecycle and patching reports kept current against Microsoft's releases.
Access and changes: change tracking of logins, server roles and schema, with an alert when a new login appears or server role membership changes.
One score for the estate: an AiQ score from 0 to 10, re-evaluated nightly, with recommendations ranked by impact, plus daily and monthly briefs.
A DBA on call: DB24+ adds a senior SQL Server DBA during business hours, on top of the product.

DB24 is priced per SQL Server instance. Contact us for a quote.

Installing updates and full restore tests stay with your team; DB24 shows where they are needed and keeps the record.

To see it on your own instances, contact us.

Frequently asked questions

Do we need to hire a DBA?

Not necessarily. With the routine automated, a named internal owner with access to outside expertise can cover a lot. Many instances, demanding high-availability setups or heavy performance work make a full-time DBA easier to justify.

Are SQL Server maintenance plans enough?

They cover a lot. Maintenance plans can back up databases and logs, rebuild indexes, update statistics and run consistency checks, scheduled as SQL Server Agent jobs. Someone still has to choose the settings, read the history and act on failures, on every instance.

What happens if the only person who knows our SQL Server leaves?

The jobs keep running, but nobody is left to notice when one fails or a new database is left out. Start with the instance list and the operations manual, and send alerts to a shared address rather than one person's inbox.

How do we know which SQL Server versions are out of support?

Check each instance's version against Microsoft's lifecycle pages. After extended support ends, security updates require Microsoft's Extended Security Update program, which Microsoft describes as "a last resort paid option" for certain products (ESU FAQ).

How much does DB24 cost?