01
No full-time DBA
Someone owns the server, but SQL Server is only part of their job.
SQL Server DBA support
Monthly SQL Server DBA support for companies that run SQL Server.
I help with performance issues, backups, SQL Agent jobs, monitoring, upgrades, restore testing, and planned changes through regular monthly DBA support.
Monthly support
Support usually starts with a small fit check. If the work matches, we agree a monthly rhythm for review, troubleshooting, planned changes, and the priority list.
Best when you want regular senior SQL Server help, not a one-off opinion.
Monthly review
Backups, jobs, monitoring, storage growth, and error logs.
Problem work
Waits, blocking, deadlocks, slow queries, and failed jobs.
Planned changes
Upgrades, patches, migrations, compatibility checks, and rollback planning.
Priority list
What to fix now, what can wait, and what needs more detail.
SQL Server matters, but nobody has enough time to keep checking it properly.
Monthly support fits best when the server is important, the work is recurring, and the next risk should not wait for an incident.
01
Someone owns the server, but SQL Server is only part of their job.
02
The system works, but the notes, version, jobs, or maintenance need a proper look.
03
Problems show up late, or alerts do not say enough to decide what to fix.
04
Backups exist, but nobody is comfortable saying what would happen during recovery.
05
Slow queries, blocking, waits, or failed jobs keep coming back.
06
You need compatibility checks, rollback planning, or a calmer review before the window.
07
Always On, failover, quorum, alerts, or runbooks need checking before they are trusted.
Monthly support often starts with one of these problems: regular DBA work, slow queries, backup/restore issues, upgrade planning or a SQL Server setup or design that needs a proper review.
Companies usually need someone to check the server, explain the risk, and put the work in order.
I help resolve urgent issues, diagnose problems around the servers, and implement or advise on the next steps.
01
After looking at well over a thousand systems, the same patterns repeat: failed jobs, bad releases, backups nobody has restored recently, and servers nobody fully owns.
02
I look at SQL Server symptoms together with storage, Windows, monitoring, deployment, and the operating process around the server.
03
You work directly with the person checking the server, asking for the right logs, explaining the tradeoffs, and putting the next work in order.
Typical work
The exact work changes by server, but the useful pattern is consistent: diagnose the issue, reduce immediate risk, and leave a clear next-step list.
Before a call
You do not need to send logs, exports, credentials, or sensitive system data in the first message. Describe the situation and I will tell you whether I can help.
First message
Company context, SQL Server situation, urgency, and support type.
Fit check
Monthly support, troubleshooting, or a defined review.
Next step
A call or the safe details to share next.
First message
A short description is enough for the first pass. Say what you run, what is happening, and whether you want monthly support or a scoped review.
Fit check
The work may fit monthly DBA support, troubleshooting, or a defined review. If it does not fit, I will say that plainly.
Next step
That may be a call, a scoped review, or the safe details to share next. System access and sensitive data can wait.
Send a short message. I will tell you whether I can help.
Use these if you want examples, technical references, product work, or background before reaching out.

Reference
Microsoft-sourced SQL Server builds, CUs, GDRs, and support dates in one place.

Project work
A local-first password manager project. Useful if you want broader engineering context.

Profile
Role history, enterprise background, and the non-mysterious version of who you are contacting.
Send the SQL Server situation and what you need covered. I will reply with the next sensible step.