What is sp_CheckActivity, and why did I create it?

I initially created the first version of this utility many years ago as an alternative to the immensely popular tool developed by Adam Machanic called sp_WhoIsActive. I wanted something that would suit most of my everyday needs for a snapshot type of view of the current activity on a SQL Server instance.

I know what you are thinking: why couldn’t I just use sp_WhoIsActive? 

Well, I have used it for many years and in some cases still do when a special need arises. The main motivator for creating sp_CheckActivity was not for lack of features but…it’s more like there can be too many.

sp_WhoIsActive has always been a great tool and still is. Adam did a fantastic job all those years ago when he gave the SQL Server community a tool like no other at the time. I am sure it is used by many tens (maybe even hundreds) of thousands of users around the world, and that is a testament to just how useful and powerful it is to this day.

However, I found that for my daily work environment it could be a little too intensive on very busy systems. These were 200+ core machines with 4 to 8TB of memory and thousands of users and today’s servers can dwarf even those. What we found was during the peak periods of activity, sp_WhoIsActive could take many minutes to return the results even with mostly default parameters. As such, I needed a way to capture similar data with less overhead and faster results and thus my custom tool was born.

Did it speed up the results? Under low to medium workloads there is little noticeable difference in most cases. However, under more extreme workloads I found it could return results in a fraction of the time such as seconds vs minutes. I purposely didn’t list exact specifications here as workloads vary dramatically and YMMV. Why is this, you may ask?  In a nutshell, it is because sp_CheckActivity simply does not have as wide a range of functionality as sp_WhoIsActive, and in some cases does not dig as deep into the DMV’s that can give us so much information as to what is happening.

What were the design goals?

Before I started to develop the tool, I wrote down what metrics I needed to be reported on for most of my daily activity monitoring needs and started from there. Again, keeping in mind that this was never meant to be a full replacement for Adam’s tool that has so much capability. I was looking for lower overall overhead that still reported on the metrics I most cared about day to day.

An example of this is the ability of sp_WhoIsActive to report wait times by thread. While that is awesome and can certainly be useful, I found in most cases I did not need to go down to that level, and thus did not want the extra overhead it took to get that information.

You will notice sp_CheckActivity has a similar look and feel, if you will, to sp_WhoIsActive. But it was written from scratch to meet my immediate needs, and much of that same data is collected and reported on although not always in the same way. For instance, I report current and historical TempDB usage in GBs instead of pages.

I never intended this tool to be public, but I have received many requests to do so and, well, here we are. And more recently I was asked to add functionality which I agreed to, since it did not add any significant overhead and was able to make the tool even more useful for other folks. The most recent additions (outlined by their parameter names) are listed below.

Note that none of these are run by default and thus do not incur any additional overhead unless specifically invoked.

What is included with the “new functionality”?

@ShowProgress – specifically returns results for any operation in which the % Complete metric is populated in the sys.dm_exec_requests DMV. Using @ShowProgress not only shows the % Complete value, but also how long it has been running and the estimated completion time in hh:mm:ss.  According to the Microsoft documentation these are the types of command in which this information is exposed, so we can take action:

ALTER INDEX REORGANIZE
BACKUP DATABASE
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKTABLE
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
RECOVERY
RESTORE DATABASE
ROLLBACK
TDE ENCRYPTION

@ShowBlocking – this is a simplified but useful option to show any blocking that is occurring with the Lead Blockers separated from the sessions being blocked. This serves me well in the majority of blocking cases I deal with.

@ShowTopProc – normally the results will show the individual statement that is currently running along with the Batch / Procedure / UDF in which it was immediately called from. With this option it will also show the outermost object vs. just the parent object. This can help find the calling chain when you have lots of nested calls.

Summary

If you are already familiar with sp_WhoIsActive, please try sp_CheckActivity on its own terms. Think of it as a general-purpose lighter-weight tool for daily activity monitoring tool rather than a direct replacement. It should fit many environments, but you may may need a specific functionality this may not have and that is fine. No single tool fits every need otherwise we would not be here today.

I would like to hear what features you’d find useful and I would love to hear about them. You can leave a comment in this post, and if you discover a bug or would like to request a feature you can note it on the Issues page in the GitHub repository. However, please keep in mind the original design goals were to be relatively lightweight, so we want to ensure this doesn’t get bloated over time.

I hope many of you find this tool useful.

The post Introducing sp_CheckActivity appeared first on SQL Server Consulting - Straight Path Solutions.

Speaking of issues, we have added a bunch of new issues to check for in sp_CheckSecurity recently. Fabiano Amorim and Andreas Wolter have been doing great work writing about SQL Server security issues, and we have tried to keep up with their findings by including new checks in sp_CheckSecurity. We would HIGHLY recommend updating your copy of that tool if you haven’t done so recently.

We’ve also added checks to our other tools, as well as made some parameter changes. And we added a MATRIX.md file so you can see which checks are in which tools.

For a full list of features, here are the recent Release Notes. Note that the 3-digit numbers relate to the new CheckIDs. Enjoy!

sp_CheckAG

  2026.9.1

•  Formatting changes only.

  2026.10.1

•  New check: 380 Endpoint encryption (Medium), for an endpoint that uses RC4 or no encryption.
•  Fix: the error log temporary tables are widened to avoid truncation errors.

sp_CheckBackup

  2026.9.1

  – New checks:

•  219 Backups not encrypted (Medium, SQL Server 2014 and later)
•  220 Backups written to a local drive (Medium)

  – Both use a single read of the last 7 days of full backups from msdb.

  2026.10.1

• Fix (certificate checks 210 and 212): COLLATE DATABASE_DEFAULT is now applied when building the certificate details text. This fixes “Cannot resolve collation conflict” (Msg 446) when msdb and the install database have different collations, for example on servers hosting SSRS databases.
• Fix: the error log temporary tables (#FailedBackups, #ErrorLog) are widened to avoid truncation errors.

  sp_CheckHealth

  2026.9.1

  – New checks:

•  358 SPN registration failed (High)
•  375 SQLAgentOperatorRole membership (High)
•  378 Always Encrypted column master key on database server (High)
•  633 Default trace disabled (High)

  2026.10.1

•  Result sets: at the default @Mode = 99 it now returns two result sets, instance information followed by problem findings.
•  Header row: the CheckID 0 header row is in the findings set, not the instance information.
•  Other modes: @Mode = 1 returns instance information only, @Mode = 0 returns findings only, and @Mode = 11 is unchanged.

  – Fixes:

•  The error log temporary tables are widened (ProcessInfo nvarchar(255), text nvarchar(max), LogDate datetime2), which fixes Msg 8152 on long log lines.
•  CheckID 720 no longer raises the “Null value is eliminated by an aggregate” warning, because the CASE expressions now have ELSE 0. Results are unchanged.

  sp_CheckSecurity

  2026.9.1

  – New checks (Security):

•    357 NTLM authentication in use (Medium)
•    358 SPN registration failed (High)
•    359 Legacy password hash algorithm (High)
•    360 SQL authentication in use (Medium)
•    361 Guest user has CONNECT permission (Medium)
•    362 Contained database users (Medium)
•    363 Application roles detected (Medium)
•    364 Certificate or asymmetric key mapped login (Medium)
•    365 Server role membership with escalation path (High)
•    366 Custom server role with elevated permissions (High)
•    367 BUILTIN\Administrators exists as a login (Medium)
•    368 ALTER ANY SERVER AUDIT granted to login (High)
•    369 External scripts enabled (Medium)
•    370 ALTER SETTINGS granted to login (High)
•    371 Unsigned assembly with elevated permission set (High)
•    372 Assembly creation permission granted to login (High)
•    373 Trusted assembly registered (High)
•    374 Agent proxy accessible to non-sysadmin (High)
•    375 SQLAgentOperatorRole membership (High)
•    376 Logon trigger (Medium)
•    377 Extended stored procedure registered (Medium)
•    378 Always Encrypted column master key on database server (High)
•    379 SQL Server Audit not capturing security actions (Medium)

  – New checks (other categories):

•    202 Backups without checksum (Medium)
•    219 Backups not encrypted (Medium, SQL Server 2014 and later)
•    220 Backups written to a local drive (Medium)
•    633 Default trace disabled (High)

  – Changed checks:

•  354 is now “Server-level permissions granted to login”. It covers ALTER ANY LOGIN, IMPERSONATE ANY LOGIN, ALTER ANY SERVER ROLE, ALTER ANY CREDENTIAL and ALTER ANY LINKED SERVER.
•  355 was “ALTER ANY LOGIN permissions”. It is now “Orphaned database user with elevated permissions” (High).
•  309 (CLR enabled) is now High. On SQL Server 2017 and later it flags CLR enabled with clr strict security off, even when SSISDB exists. On 2016 and earlier it still excludes servers with SSISDB.
•  Modes: @Mode = 1 is now instance information only, and the new @Mode = 2 returns High-importance items only. Modes 0 and 99 are unchanged in meaning.
•  Output: the Importance column is now numeric (0 to 3) rather than text like “1 – High”. Instance information labels no longer have leading spaces.

  2026.10.1

•  New check: 380 Endpoint encryption (Medium). It flags a database mirroring endpoint using RC4 or no encryption, including mixed AES RC4 settings.
•  Instance information: the current state (Importance 0) of ten settings now appears: 310, 311, 319, 341, 342, 343, 345, 347, 348, 349.
•  Issues: those ten now appear as findings only when enabled, except 310 (remote admin connections), which appears only when disabled. Their importance is unchanged.
•  Registry reads: the Hide Instance, Extended Protection and Force Encryption reads happen once, and the Extended Protection read now uses @no_output.
•  Fix: the error log temporary tables are widened (ProcessInfo nvarchar(255), text nvarchar(max), LogDate datetime2). That avoids “String or binary data would be truncated” on long log lines.

sp_CheckTempdb

  2026.9.1

•  Formatting changes only.

  2026.10.1

•  New check: 743 Large version store (Medium, High at 50% or more). It names the oldest open snapshot transaction when one exists.
•  New parameter: @VersionStorePercent, default 25, with a 1 GB minimum reserved, clamped to 100.

The post Updates for all sp_Check tools – October 2026 appeared first on SQL Server Consulting - Straight Path Solutions.

AI is awesome. It is astounding what it can do, how much it can do, and how correct it can be. It is also equally scary and world-impacting, and we can all feel the ground turning a little fluid under our feet. I don’t have big answers, but I do have some automation-related opinions to share with you right now, and they come down to one idea: use AI to help build your automation, not to be your automation.

AI is non-deterministic

As data people, we should all know what this means. Given the same data and the same prompt, AI can’t be trusted to do the same thing, make the same recommendation, or reach the same analysis twice. Even if it does today, the next model update can change its behavior without you changing anything. Reliable decision making should be based on reliable inputs.

AI is a black box

At the lowest levels, AI is still very much un-auditable. It is a black box according to the people developing it and the people trying to understand it. We can ask it why it did something, but its answer is just more generated text, not a record of what actually happened inside. We can see what it did, but we can’t verify why, and that means it can’t be audited the way a script can.

AI isn’t accountable

In my own experience, and in the many horror stories on LinkedIn, AI still isn’t following the rules we try to set for it. It seems to have short-term memory loss when it comes to guardrails. It can’t be trusted to follow the rules, and even when it does follow them and still gets something wrong, it can’t be held accountable.

AI is so easy to use

For many years, some of the worst SQL Server deployments have been described as someone clicking “next, next, finish” through the installer. Some AI usage is that same issue on jet fuel. It is so easy to hand it your own credentials, let it access the data, show it the schema, and give it the script. And in most cases, it will do an OK job of giving you something that does what you asked, but the problem is the same as next, next, finish: AI is going to implement what you ask for. The less you know, the higher the chance you aren’t asking for the best implementation.

What does all this mean for you and your automation?

The more complex the requirements, the more resilient the solution needs to be, and the more an experienced person needs to be involved in engineering it. AI is a powerful force multiplier. An experienced engineer with a well-designed specification can burn through an implementation at blinding speed. The hardest parts of development are now design and testing. Design means being clear and detailed in what you ask for, with zero ambiguity as the target. Testing means having an environment to test the output in, and people experienced enough to know when the output is wrong, too complex, or was led in the wrong direction.

The size of the project matters too. A simple automation to collect, store, and report on data doesn’t need an entire team of reviewers. However, we are seeing a boom in teams trying to use AI to replace enterprise-level software without the experience to confirm that the output is enterprise-ready for resilience, reliability, and security, among other things. Some are letting AI make major changes on their SQL Servers, which is why we recently had mugs made with “We repair what your AI fixed” on the side. Picture a transaction log filling up a drive. The AI switches the database to SIMPLE recovery, shrinks the log, and reports the problem fixed. It also just broke your log backup chain, and point-in-time recovery is gone until someone notices. The fallout of vibe-coded implementations at enterprise scale shows up again and again in technical groups and in the news.

So how should you use AI in your automation?

I’ve rambled enough. I’m an automation guy, and I love encouraging you to find ways to save time. In this post I want to be clear that AI is a powerful tool, but implementation should be careful and intentional. Here are a few guidelines for how I would start bringing AI into your automated tasks.

One distinction before the list: AI can help you build almost any of these processes. These guidelines are about whether AI should be the process, making a judgment call every time it runs.

Should nots:

1. Don’t use AI where you need deterministic output. Fetching data, sorting or organizing it, building a report with pass/fail counts: you don’t want two different answers from the same data. Let AI help write the script, then let the script produce the output.
2. Don’t use AI for processes that need auditing. AI can’t be held responsible, so don’t ask it to interpret something and then make a change to a production database. It won’t always make the right decision, make the same decision, or follow the rules. And if the scope is narrow enough that AI could never get it wrong, regular old scripting is cheaper anyway.
3. Don’t use AI for things you can’t undo. You don’t want to be up the creek when AI makes an irreversible decision, like reducing backup retention, turning off your restore test job, or running REPAIR_ALLOW_DATA_LOSS on your behalf.

Coulds:

1. Use AI to help with specs and well-designed, well-tested development. Have it poke holes in your spec, generate code against it, and write the tests, then run everything in a lab before it gets anywhere near production.
2. Use AI to interpret Windows, SQL Server, and application error messages during incident response. Make it cite the log entries it’s drawing from so you can check its work.
3. Use AI to triage and route. It can read the tone and urgency of tickets and alerts, suggest who should handle them, and loop in the right people.
4. Use AI to summarize and explain. Turn a 200-finding health check into a top five your manager will actually read, or get a second opinion on an execution plan.

The pattern behind all of the coulds: AI proposes, a person approves, a script executes.

Where I’d draw the lines

Here’s how I’d sort some common DBA tasks. Most land in more than one column, and that’s the point: the script does the work, AI helps build it and make sense of it, and a person owns the decisions that can’t be undone.

Notice that AI never shows up alone in a row that changes production.

Final Thoughts

We’ve all tasted the fruit, and nobody is going back, me included. AI is going to keep getting better, and it’s already a powerful force multiplier for anyone building automation. But it multiplies whatever you bring to it. Bring experience, a clear spec, and a lab to test in, and you’ll build faster than you ever have. Bring next, next, finish, and you’ll also get there faster, just somewhere you didn’t want to go.

Use AI to help design, write, and test your automation. Let the finished, reviewed, version-controlled script do the work. Keep a person on anything that can’t be undone.

I love automation and the time it saves for me, the Straight Path team, and our customers. The less time we spend on things that can be automated, the more time we have for things that can’t be. Used carefully and intentionally, AI gets us there faster. And if your AI has already fixed something, you know where to find us. We have mugs.

The post We Repair What Your AI Fixed: Where AI Belongs in Your Automation appeared first on SQL Server Consulting - Straight Path Solutions.

Most migration issues are not caused by the data. They come from assuming Postgres works the same way as SQL Server.

Case Sensitivity

One thing I learned is that Postgres does not handle object names the same way as SQL Server. If you create an object with quotes, Postgres keeps the exact case. If you leave the quotes off, Postgres converts the name to lowercase. String comparisons are another thing I would check. A lot of SQL Server environments are case insensitive by default. Postgres is usually case sensitive unless you set that up yourself.

I would check table names, column names, schema names, application code, ORM mappings, and anything using quoted identifiers. If possible, I would stick with lowercase object names.

Indexes

Indexes do not always translate the same way when you migrate them over. In SQL Server, the clustered index controls the table order. Postgres stores tables as heaps. Postgres does have a CLUSTER command, but it only rewrites the table once. New rows do not stay in that order.

I would review included columns, filtered indexes versus partial indexes, fill factor, statistics, and query plans. Recreating the same indexes does not mean you will get the same performance.

PostgreSQL Versions

Postgres releases a major version about once a year and supports each version for five years. I have found a lot of companies running older versions, so I would check the version early in the migration. I would look at end-of-life dates, features the application needs, extension support, upgrade paths, and what the cloud provider offers.

As of late 2026, PostgreSQL 13 is already out of community support. PostgreSQL 14 reaches the end of community support in November 2026.

Extensions

In a previous post, I talked about alternatives to SQL Server Agent. A lot of extra Postgres features come from extensions. One thing I learned is that not every extension is available everywhere. I would check whether the cloud provider supports it, whether it needs superuser access, whether it needs extra configuration, and what can be used if it is not something available. Managed Postgres services do not all offer the same extensions.

Managed Versus Self-Managed

Managed and self-managed Postgres are not the same. Managed services usually size some settings for you. Self-managed servers often start with conservative defaults. I would review shared buffers, work memory, maintenance work memory, connection limits, and autovacuum.

I was surprised by how low some of the default memory settings can be. Fresh installs can still have shared_buffers set around 128 MB.

I would also check the number of connections used by the application. Postgres uses a process for each connection. Applications that open hundreds of connections will probably need a connection pooler.

Job Scheduling

Jobs are not SQL Server Agent. For years, people scheduled Postgres jobs with cron. pg_cron makes it easier to schedule SQL inside Postgres, but it is not a full replacement for SQL Server Agent. pg_cron runs SQL, not shell scripts. If the instance is down, the job does not run. 

Other choices include pg_timetable and cloud schedulers. Before cutover, I would list every maintenance job, backup job, ETL job, and monitoring job. I would make sure each job has a replacement and test it before the migration.

Stored Procedures

If the environment uses a lot of stored procedures, I would budget time for them. Postgres has procedures and functions. They are not written like T-SQL. I would review syntax, transactions, error handling, dynamic SQL, temporary tables, and how results come back. Multiple result sets from one procedure are common in SQL Server. They do not move cleanly to Postgres.

Identity Columns and Sequences

SQL Server identities do not always translate directly. Postgres has IDENTITY, SERIAL, and standalone sequences.

Data Types

Some SQL Server data types do not have a direct match in Postgres. I would check money, uniqueidentifier, rowversion, tinyint, bit, datetime types, sql_variant, hierarchyid, and CLR types. Each one needs to be mapped and tested before the migration. Also, rowversion is not a date or time type.

Linked Servers

Linked servers do not exist in Postgres. The usual replacements are postgres_fdw and dblink. I would also check what each linked server is being used for. Replacing the connection does not mean the existing queries will work without changes.

Database Mail

Postgres does not have a direct replacement for Database Mail. If the application or a job depends on it, I would plan a replacement before cutover.

Cross-Database Queries

SQL Server databases on the same instance can query each other. Postgres databases are isolated. A lot of migrations use schemas in one Postgres database instead of creating several databases. I would search the SQL Server code for three-part names before deciding how to set up the Postgres databases and schemas.

Security and Permissions

I would review roles, role inheritance, authentication, service accounts, and search_path settings. Postgres roles belong to the whole cluster. The search_path controls which objects Postgres finds when the schema name is left out.

Collation

Collation needs to be checked before the move. Sorting, unique constraints, and string comparisons may not match what SQL Server was doing. This can change query results even when the data moved correctly.

Temporary Tables

Postgres temporary tables belong to the session. They can also be set to drop when the transaction commits. There is no global temporary table like a SQL Server ##table. I would also check connection pooling. A temporary table created on one connection will not be there if the next statement uses another connection.

Date Functions

GETDATE(), GETUTCDATE(), DATEADD(), DATEDIFF(), and DATEPART() all need Postgres replacements. I would also check how the application handles time zones. Postgres has timestamp with time zone and timestamp without time zone.

Vacuum and Bloat

Postgres keeps old row versions until vacuum cleans them up. Long-running transactions can stop vacuum from removing those rows. This can leave tables and indexes bloated. I would check autovacuum settings, long-running transactions, and tables with a lot of updates or deletes.

Query Hints

A lot of SQL Server hints do not exist in Postgres. NOLOCK, FORCESEEK, and INDEX hints need another approach. NOLOCK is also the wrong way to think about Postgres. Postgres uses MVCC, so readers and writers usually do not block each other.

High Availability

Always On Availability Groups do not translate directly to Postgres. I would review replication, failover, read replicas, backups, and restore tests. Postgres failover often uses streaming replication with other tools or a cloud high-availability service. I would test failover and restores before the migration. I would not assume the cloud service handles everything.

My Thoughts 

Most migration issues are not caused by the data. They come from assuming Postgres works the same way as SQL Server.

These are the things I would check before the move. It is better to find them while you still have time to fix them than after the migration.

The post If You Are Moving to Postgres, Start Here appeared first on SQL Server Consulting - Straight Path Solutions.

With that being said, we at Straight Path pride ourselves on proactivity and helping customers to determine what they might need. So, as you may have guessed by the title, this is a blog post about PostgreSQL and some things I’ve learned about it and why I never want to stop being a beginner.

If you’re new to us, Straight Path is a SQL and Database consulting firm started by our CEO Mike Walsh. We’re now at 22 employees and we have backgrounds in performance tuning, migration work, security, and just general DBA knowledge spread out across our Senior and Support teams. There isn’t much we can’t handle as an organization. Our new CDO, Buck Woody, in the spirit of proactivity has seen the writing on the wall as well and knows that our next logical step was Postgres since it’s getting more popular than ever. DBAs and organizations around the world are turning to Postgres for its customization, its easy licensing, and resource management.

I’ve built my career in Microsoft but my OS of choice for my personal projects is Pop!_OS, which is based on Ubuntu and is part of the Free and Open Source Software (FOSS) project. I learned about Linux and the different operating systems built around it when I was fresh out of high school, through my uncle who had been using Linux almost since its inception. I was amazed that so many humans across the world could come together on a project like this and that Linux was responsible for so many things in our lives. Now it’s on billions of devices and runs critical infrastructure that we depend on. I’m saying all of this to emphasize that it’s my passion for being a beginner that got me into Linux in the first place, and that same passion brought me to being a DBA, and now it’s helping me to learn Postgres.

As the title suggests, I didn’t set out to be a DBA, I originally went to school for programming. That job I mentioned earlier hired me partially for my ability to read code. My boss at the time assumed that if I could read C# then I must have been able to read whatever language the company’s software was written in and that would help me in my support role. He wasn’t totally wrong because that light programming background allowed me to talk with the developers and try to understand what we were building. It helped me make relationships that I still maintain today and that ability to be a beginner let me ask questions. I asked questions about everything because it’s how I soak up information. Asking those questions eventually got me pointed to the DBA team because I wanted to know why something wasn’t working, and development eventually pointed the finger at the DBAs. As we all know, DBA does stand for “Default Blame Accepter”.

I started working closely with them and learning anything and everything I could. Eventually that company was going under and I needed to find new work and I found Straight Path. I wanted to take the DBA knowledge I had to the next level because I wanted to be a beginner somewhere else and before I knew it, I was. I was learning the ropes of SQL Agent, jobs and maintenance plans, users and access, and how to troubleshoot issues. Fast forward 5 years and I’ve grown into my role as a DBA where I maintain a list of my own clients and I assist our Senior team with their clients where I can. I focus on proactive work and maintaining a well performing environment while also looking for opportunities to enhance security. The world is only getting less secure these days, and I started all this by being a beginner at something.  

Here I am now, relearning a lot of those same principles but in a new environment with new challenges and new goals. Postgres is a great tool and even though it can do so much for your environment and your workflows, it may or may not be the right tool for your needs.

Postgres is also considered FOSS, and it’s maintained by a dedicated group of people around the world and provided for free in most cases. That philosophy is also part of what brought me to learning it and wanting to use it, as it was like getting to learn about Linux with my uncle all over again.

So, this is a roundabout way of saying that you shouldn’t ever stop being a beginner at something. I took my passion for learning and started with Windows 98 as a kid, then in my teens learned about Linux, then as an adult I found my career with Microsoft software, and now we’re going back to Linux to build out this Postgres plan. More on that to come!

The post The accidental DBA is learning PostgreSQL (and why you should never stop being a beginner) appeared first on SQL Server Consulting - Straight Path Solutions.

Those couple of events piqued my interest so a few months ago I dipped my toes into the Postgres pool.  I started this adventure looking for ways to apply my 20+ years in SQL Server to Postgres so that I can start to help people who are also new to the platform.  One of the very first things I learned about in SQL Server was backups, so I thought it would be fitting to start there with Postgres.

Most of the readers of this post likely know how SQL Server backups work.  You can create a backup of an individual database with a full backup, a differential backup, and a log backup.  You can then use those backup files to restore the database onto the same server or a different server.

With Postgres, there are two categories of backups: a logical backup, and a physical backup.  The logical backup is essentially an export of one or more objects in the database to a file.  The contents of that file could have anything from the scripts to create the objects to the insert statements to reload the data into a table.  But that is all you can really do with a logical backup – create a copy of something in a database and restore it somewhere else.  Useful for certain tasks, but this cannot be used for other administrative tasks like point in time recovery or building physical standby replicas.

A physical backup is where you would start if you needed to perform a point in time restore of a database.  Comparing this to SQL Server this is where you’d restore a full backup, then maybe a diff backup, and then roll log backups until you get to your desired end time. 

One of the big differences between SQL backups and physical Postgres backups is with SQL Server you backup one database; with a physical Postgres backup, you capture the entire Postgres cluster.  One of the reasons for this is that all the databases on the Postgres cluster share the same Write-Ahead Log (WAL) file. Because all databases share the WAL file, everything on the cluster is needed for Postgres to guarantee a database is transactionally consistent.  If there were objects missing from the cluster, it could cause failures while transactions are being replayed from the WAL file backups.

This was a big difference for me when comparing SQL Server and Postgres. With SQL Server I only need to worry about a couple database files and if there is space on the server, but with Postgres there is so much more to take into consideration when preparing to do a point in time restore of a database. 

Looking forward to learning more about the differences between the two platforms and if there are any similarities.

The post Backup a second… this isn’t a SQL Server post? My journey into PostgreSQL backups appeared first on SQL Server Consulting - Straight Path Solutions.

No client asked us to do this

That’s the first thing I want people to know. Nobody made us. We’ve been doing this since 2011 and we’ve passed plenty of vendor questionnaires without a SOC report. Maybe the desire to do a couple less vendor questionnaires motivated me, but then I learned that we’ll still get them – but I also learned that our managed service provider for IT and MS365 and security will also fill those out for me. So that’s still a win.

When you hire us, you’re handing us the keys to the kingdom. Our DBAs get privileged access to SQL Servers that hold patient records, member accounts, customer orders, payroll (the stuff that keeps your business running and keeps people’s lives in order). We help clients get through audits and security reviews all the time. It felt a little hypocritical to keep asking you to trust our answers when we’d never had anyone outside the company check them and keep watching.

What we actually did

We’re a 22-person company. Hiring a full-time CISO didn’t make sense for our size, and the “buy a compliance platform and click through the checklist” route didn’t give me what I wanted, which was someone who knew our business telling me where we were weak. I don’t want a rubber stamp – this was not a cheap expense – and it is a new ongoing line item – the managed security services and the annual audit we’ll have to keep our SOC2 Type II up once we (hopefully) achieve that in 6 months is an expense. The extra time to do some things, the process, the forced patching reboots. It’s all a cost – but it’s worth it.

So we leaned on Mainstay Technologies, who already run our managed IT and security monitoring. Erin Mealey guided the SOC 2 work start to finish, and internally Evan Corbett (our COO) drove the follow-through while Buck Woody brought a lot of hard-won data security and incident response experience from his roles at Microsoft for the past nearly 20 years.

The work itself was a lot of turning things we already did into things we could prove we do: documenting controls, formalizing policies, running every vendor through the same review, security training with evidence behind it, and testing our response plans. We also pulled our monitoring platform, Skopos, and the software we write into scope, because that’s part of how we serve clients and leaving it out would have made the report look tidier than reality.

I expected more misery than we got. The part I figured would be pure box-checking was the disaster tabletop exercises. It wasn’t. Walking through those scenarios surfaced real risks, and we changed some of our approaches and policies because of them. Turns out we had some homework. I’d rather find that out in a conference room than at 2 a.m. on a client’s server.

What a SOC 2 Type I actually is

SOC 2 is an examination framework from the AICPA. An independent CPA firm looks at a company’s description of its system and its controls against a set of criteria. We were examined against the Security criteria, which is the required baseline for every SOC 2.

A Type I is a snapshot only. It says that on a specific date, our controls were in place and suitably designed to meet those criteria.

I spent years as a firefighter and EMT, so here’s how I think about it. A Type I is the inspector walking the building and confirming the smoke detectors are installed, wired correctly, and in the right rooms. A Type II is the inspector coming back and checking the logs to see that they were tested every month and actually went off when there was smoke, and the folks followed the evacuation plan months later.

What it doesn’t mean

This is the part I care about most, because transparency matters, it’s the whole point behind the Buying DBA Services guide posts I’ve been sharing. Don’t let our “SOC2 Achieved!” woo you into letting your guard down. Even when we hopefully pass our Type II audit.

• It isn’t a certification. There’s no such thing as being “SOC 2 certified,” even though you’ll see vendors say it everywhere. It’s an attestation report from a CPA firm. We’ll try hard not to call it a certification, and if you catch us doing it, tell us.
• It doesn’t prove our controls worked over time. That’s what Type II is for, and we’re not there yet.
• It doesn’t mean nothing bad can happen. No report eliminates risk. Anyone who tells you otherwise is selling something.
• It doesn’t cover your servers. The report is about how Straight Path runs. We don’t host your data in our environment. The security of your SQL Servers is still a shared job, and the report even lists things clients are expected to do on their side (auditors call these complementary user entity controls, apparently). We’ll help you with those, but they’re yours. We think the time is right for you to have a PAM tool, as much as the DBA in me cringes typing it, but that’s your decision and a CUEC suggests it – we can tell you how others have done it but this is up to your security team.
• It doesn’t replace your due diligence. It gives you better evidence to work with. You should still ask us hard questions, ask our competitors hard questions, get to know the team, and decide if we’re the right fit.
• It doesn’t mean we changed who we are. We’re still the same bunch of SQL Server geeks. We just have more evidence behind the promise and more documentation, process and checkboxes for the team to follow behind the scenes.

Why it’s still worth it

The SOC 2 (or ISO27001) journey can absolutely be an expensive paperwork exercise that makes a company look secure without making it more secure. I’ve seen that happen.

What made it worth it for us came from a few places:

We found our unknown unknowns. We already had solid basics in place (MFA, background checks, managed devices, active monitoring, phishing tests, perimeter security, see something say something policies, etc.). The value was in the questions we didn’t know to ask ourselves, and the tabletop drills were the best example. Or pushing the same questions and process on our own vendors was a good takeaway – rigidity up and down.

The team’s defaults changed. I’ve watched people make more secure-by-default decisions without anyone prompting them. This team was already mature and security already mattered here, but now I can see it in how everyday choices get made.

Rules for everyone make life easier. When we were five people, a lot of how we worked lived in my head and a couple of other heads. Having clear policies that apply to everyone, me included, has made things simpler than the early days.

Your vendor reviews get easier. If you’re a credit union, you’re expected to do real due diligence on third-party providers and your examiners will ask about it. If you’re in healthcare, you’re asking vendors how they protect PHI. Now we can hand you independent evidence instead of a well-written questionnaire answer alone.

The monitoring already proved itself once. Before the formal SOC 2 work even started, some activity on my laptop tripped an automated response falsely. My laptop got isolated, my account got locked, and Mainstay’s security team called me. It turned out to be harmless. I was annoyed for about an hour, and then really glad, because that’s exactly what I want to happen when something looks wrong.

Why we’re already in the Type II phase

A Type I tells you we designed things well on one day. That’s a real milestone, but it’s a starting line. The question anyone serious about vendor risk will ask next is “did you keep doing it?” Even “are you going to keep doing it diligently forever?”

Yeah we are –> Our six-month Type II observation period with Linford is now underway or about to be (not officially sure how it works – but it’s next and we are waiting 6 months to have enough of a period to catch us doing something wrong, and move it to 2027 so we can go annual after that.) During that window we have to operate the controls we described, keep the evidence, and then let the auditors test random samples across the whole period. If a control slips, the report will say so, we can’t do anything about it. That’s the point of it.

Why annual audits are in our budget

This wasn’t a one-time project, and we’ve budgeted it that way. After the Type II, we plan to be examined every year.

A few reasons:

1. Reports age. A report that covers a period that ended a year ago tells you less and less every month. Auditors themselves recommend producing them annually so there’s no gap between reporting periods.
2. Your reviews are annual. Most of our regulated clients re-review their vendors every year. We should have something current to hand them.
3. Discipline decays without an outside deadline. I know myself alllllll too well. Good habits hold up a lot better when someone independent is coming back to check. Outside accountability helps. Plus it makes the process the bad guy, not me with all our process and procedures and security.
4. It matches how we already do business. We don’t lock clients into long-term contracts, because we think we should have to earn your business every quarter. It would be a little strange to then ask you to trust a snapshot from years ago.

It’s a line item now, like insurance and training. I’m okay with that.

What this means if you work with us (or are thinking about it)

If you’re a client and your compliance team wants to see the report, reach out to us and we’ll get it to you, you’ll see it on your next vendor questionnaire round if you are one of the many who send the links to them. If you’re evaluating us, ask for it, and ask us anything else too. What we train on, what happens when something goes wrong, what our policies actually say. Those are fair questions, and you should ask them of every vendor who touches your data.

We really care about the data we look after. Behind every row in those tables are people, families, customers, and livelihoods. This report is one piece of evidence that we mean it. The rest we’ll keep earning the same way we always have – earning the next renewal by proving ourselves to be a part of your team, not just another vendor.

Have a SQL Server environment you want an honest conversation about? Let’s talk.

The post We Finished SOC 2 Type I (What this is and isn’t) appeared first on SQL Server Consulting - Straight Path Solutions.

I want to do something a little unorthodox here, I’m going to list a few firms I’d actually consider if we weren’t in the picture (or our Remote DBA services weren’t right for you). These are companies I respect. Some of the founders are friends. We’ve referred work back and forth over the years with a few of the firms.

I’m not ranking them. And I’m deliberately not putting Straight Path on this list.

I also left out the big national and global providers. Those firms generally serve a different part of the market than the specialist shops I’m talking about here. If you’re looking for a large enterprise provider, global teams, or a broader outsourcing relationship, some of them may absolutely belong in your search. That’s just not the comparison I’m making in this article.

Here’s my short list. I may be missing a firm that I know and respect, wasn’t trying to be exhaustive but go with the ones that come to mind right now, and I left the solo DBA shops or solo DBA plus one jr. backup out for this comparison.

Sero Group Joe Webb’s company. Smaller team. Values-first and trust-first. Joe has been in the SQL Server community a long time and runs the firm the way a lot of us wish more companies were run. They take compliance seriously (including going on the SOC 2 journey). We’re finishing up our own SOC 2 process right now with our draft report in hand waiting for the final, so I’ve been talking to Joe a bit about his journey. He does it well, and I trust him and his team even without their SOC 2 report. If you want a high-touch specialist shop, Sero is worth a conversation. Joe is one of my favorite people in the SQL Server community, too.

Procure SQL I know and trust the founder and a bunch of the people on their team. Not the smallest team on this list, but not as large a team as Fortified, SQL Watchmen or us. They lean a little more into the broader data platform side (architecture, integration, reporting, analytics) than pure operational DBA work based on what they put on their site first, but they have excellent DBAs and can absolutely do managed DBA services. If your needs sit closer to the development and data platform side of the house, they’re a strong option.

Dallas DBAs Smaller firm. Generally sits at a lower price point than most of the others on this list. Solid coverage and a practical SQL Server focus. We’ve sent some work to them and they’ve sent work to us. Their model is often a good fit when what you really need is lighter fractional coverage with a good, smaller, mid-level team, or a solid emergency backup.

SQLWatchmen Austin-based. Pure SQL Server focus. Founder-led. US-based team. They’ve been doing remote DBA work for a long time and keep the model relatively simple. Another solid specialist option if you want a focused SQL Server shop.

Fortified Data A bit larger than the others on this list. Multi-platform, and they’ve built a commercial monitoring software/product side (Fortified WISdom) in addition to services that they sell, and they have more of an enterprise-oriented feel than some of the smaller specialist shops here. If you need broader database platform coverage or getting into multi-platform support beyond just SQL Server and PostgreSQL that we cover, or a larger operational model, I’d put them on the list of companies to talk to.

As with any provider (including us), I’d make sure you understand the contract terms, service levels, what’s included, how changes to the relationship work and changes between levels work, and what happens if you eventually need to leave. Check out all of the posts with the buying DBA services tag – you can think of questions to ask any of us and get some thoughts on pricing, fit and what to look for in a firm. Next week, I’ll talk about the question we sometimes hear, “Can our MSP be our DBA team? Should they?” It depends and I’ll talk more about it. Then after that one I’ll be putting all of these posts in this tag into a guide for folks to read and give a few checklists. Subscribe to the newsletter to keep up.

How I’d Think About the Short List

There’s plenty of overlap between these companies and even our own, so don’t treat this as a ranking or assume one sentence captures everything a company does. But if I were starting the conversations today, this is roughly how I’d think about them:

• Want a smaller, high-touch specialist relationship with a smaller bench but good experience and compliance chops and one who also works with financial institutions like we do? Talk to Sero Group.
• Need broader data platform and development capabilities or architecture as a service and some help with PowerBI and Fabric resources directly on the team? Talk to Procure SQL.
• Looking for lighter fractional coverage, more keep the lights on support, or more price sensitivity? Talk to Dallas DBAs.
• Want a focused SQL Server specialist model? Talk to SQLWatchmen.
• Need broader database platforms or a larger operational model? Talk to Fortified Data.

Services change. Teams change. Pricing changes. Talk to them and ask questions rather than treating any of this as final answers.

What About Pricing?

Most of these firms don’t publish full pricing the way we do, so you’ll need to fill out quote requests, maybe talk to them to get current numbers and understand what is actually included. Dallas DBAs has historically been one of the more transparent on that front.

And frankly, don’t compare these companies on the quoted price alone.

Ask what the price buys. Does it include monitoring? Who responds to alerts? What happens after hours? Do you get a named DBA? How much actual DBA time is included? What costs extra? Are projects handled differently? What’s the contract commitment? What happens when you need more or less help? What’s the true SLA?

Two companies can both call something “DBA as a Service” or “Remote DBA” and be selling pretty different relationships.

We’ve written quite a bit about those questions elsewhere (the pricing post, the problems post, the first 90 days post, the FTE vs DBA as a Service post) because I think they matter more than trying to reduce every provider to an hourly rate.

Why Am I Publishing a List of Our Competitors?

Because if you’re seriously considering DBA as a Service, you should probably talk to more than one provider and I’d rather tell you who I respect than pretend we’re the only company capable of doing this work well.

If after looking at these options you still think Straight Path is the best fit, we’re happy to talk. If we aren’t? I get it, talk to those shops, you can’t go wrong.

The goal here is the same goal I’ve tried to keep across this whole series. The bad-fit post. The problems post. The full-time DBA vs DBA as a Service post. The first 90 days post. All of it.

Your SQL Server environment should end up with the right team. Not necessarily always our team.

The post Who Would I Use for DBA as a Service If Straight Path Wasn’t an Option? appeared first on SQL Server Consulting - Straight Path Solutions.

But while the technical expertise is important, it’s the white-glove part that really provides our value. We learn what we can about our client’s environments, how they work, and where they need us to help. In some cases, we are their only data and database professionals. We handle everything from performance to HADR. In other cases, we are the specialists that handle the calls their database professionals make. We’ve added Microsoft Azure Architect services, as well as a Data Architect level of services in an advisement role as well – always with a focus on enablement, not just advising. The real value is caring about what happens at the client, and taking an ownership mentality to help them succeed. We’re extremely proud and very jealous about guarding those systems and providing the highest level of service we can.

As part of that understanding of our customers, we’ve heard loud and clear that many are planning to migrate to PostgreSQL. Its powerful engine, flexible query languages, and extension architecture allows it to do just about anything they need in their data estate. It does not have the same licensing costs (if any) that Microsoft’s platform requires. And it runs on multiple platforms and clouds – both as a bare-metal install and a global level service. Some clients aren’t migrating what they have, they are eyeing PostgreSQL for future projects. Some have third-party solutions that require a PostgreSQL back-end.

In all these cases, we’ve seen the requirements our clients have, and in line with meeting their needs, we’ve started a “Postgres Tiger Team” within the company. These technical professionals are currently training and implementing PostgreSQL solutions on Windows, Linux, Containers and Clouds. We are taking SQL Server tickets and issues we have, and one team member will “break” their PostgreSQL installation and assign a ticket to another team member to fix, just like we would with SQL Server. They are writing blogs, teaching classes, and keeping the rest of the company up to date on PostgreSQL. And they are learning some interesting things along the way. You’ll see some blog posts here shortly about their journey. You’ll understand a little more about who they are, and you’ll get very frank and honest impressions about the good, the bad, the process, the learnings and much more as they take on this extra responsibility in their professional training.

As a company, we’ll keep our focus on Microsoft SQL Server as we add new platforms our customers ask for. SQL Server is an amazing product with fantastic capabilities, and we’re committed to have the best technical support for it. Personally, I think SQL Server has a juggernaut of a path forward into the future. As a former SQL Server Microsoft team member, some of my blood, sweat and tears are in that codebase, and I am very excited about the new features I see coming out.

We hope you enjoy this series, and learn a little something along the way. I’ll be presenting a full one-day, hands-on workshop this Fall at the Live 360 conference. I hope you can join us there.
https://live360events.com/events/orlando-2026/sessions/friday/dpf01-hol-wksp-postgresql.aspx

The post The Straight Path to PostgreSQL appeared first on SQL Server Consulting - Straight Path Solutions.

By Day 90 you should feel less blind and less on your own with SQL Server. Our clients describe it as the ability to sleep at night without worrying about their SQL Servers. You’re onboarding with a vendor, but it shouldn’t feel like it.

This post talks about what a healthy first 90 days should look like and where things commonly get harder than the sales conversation implied so you can be aware of it, look to make your part smoother and call out where it feels off. This is part of our Buying DBA Services series of posts. Whether you buy from us or a friend in the business, we want you to be equipped as you make that selection.

Prefer to watch? I sat down with Evan, our COO and the person who oversees our onboarding process, to talk through what actually happens after a new DBA as a Service client signs, what tends to slow onboarding down, what happens when there’s already a fire, where we’ve gotten onboarding wrong, and what should feel different by Day 90.

Define What Success Looks Like Before You Start

This is something pretty important and it should be part of your kick-off call. Evan got to this in the video and I wanted to add it to the post. Whether you work with us or another provider:

You should tell your DBA provider what success looks like to you.

That sounds obvious, but it’s easy to skip. Your provider may have a perfectly good 90-day onboarding checklist. They may get monitoring installed, review your backups, find configuration problems, check integrity, document the environment, and feel like they knocked the onboarding out of the park.

Meanwhile, you’re wondering why nobody fixed the performance problem that caused you to hire them in the first place.

That’s a failed onboarding, even if every box on the provider’s checklist is green.

Before you start, I’d make sure both sides can answer this question:

“Ninety days from now, what needs to be different for us to consider this relationship a success?”

The answer might be fewer outages. It might be getting your DBA out of the 2 AM alert business. It might be knowing whether your backups can actually be restored. It might be getting a specific performance problem under control. Or it might simply be understanding the risks you don’t know about today.

The provider should have an onboarding process. But your definition of success needs to be part of it.

What happens immediately after signing?

Onboarding with us doesn’t always wait for the official start date.

After signing, a provider typically sends welcome and contact information, schedules a kickoff meeting, provides onboarding documentation and forms for you to use for access. They begin identifying key contacts, and usually start access work as soon as you are ready. In many cases the client can already reach the team for advice or issues, and monitoring or health-check work can begin as soon as usable access exists even if it’s a bit ahead of the “official start date.”

At Straight Path, we like to start each DBA as a Service retainer on the first of a month and we limit ourselves to two to three active onboardings per month, so no one falls behind.

Signing on August 15 for a September 1 start does not automatically mean everyone sits idle until September 1. Many providers (including us) would rather begin solving access and visibility earlier and effectively give the first quarter a little extra runway than spend the first several weeks of the official engagement still blind.

What access does a Remote DBA team need?

A DBA team needs sufficient access to actually perform DBA work. That commonly includes remote connectivity, appropriate SQL Server permissions (SA access is really necessary to truly effectively be your DBA team. We can use a PAM tool and have non-admin and admin accounts, but it’s just necessary to succeed.) Jump-servers need to be setup for many providers, including us, and coordination around MFA/PAM/VPN needs to happen. Firewall internal and external connectivity for monitoring needs to be solid.

Effective working access is one of the biggest variables in onboarding speed.

How customers can make this easier

• Identify who owns VPN and security access before kickoff
• Test credentials before sending them
• Document VPN, MFA, and PAM procedures
• Determine who can grant SQL-level access
• Bring the MSP, network, or security team into the process early when needed
• Know who actually owns administrative access to vendor-managed systems

A real-world pattern worth noting: some organizations discover during onboarding that they do not actually possess the level of SQL Server access they thought they did, especially around vendor-managed applications. We’ve seen this happen at Credit Unions and a couple radiology practices that have “over-protective” vendors. That discovery itself can surface risk.

How us providers can make this easier

• Provide options for shared access and use a SOC/HIPAA/PCI compliant tool that a client can use as an option with logging, MFA and controls already
• Document your needs ahead of time and get that to the clients before a sales decision is made
• Provide a secure portal to share information consistently
• Suggest an access kick off meeting – sort of a pre-kick off kickoff meeting where the access is squared away.
• Ask the provider to test the access first, remind them that onboarding eats into billable hours and we want to use those hours to make a difference.

Days 1–30: Stop being blind

The primary job in the first month is visibility. Visibility for the Remote DBA provider and with their tools, hopefully much more visibility for you and your support teams.

Clients often hire a DBA provider because of a problem that is seen by all and obvious to the business… Performance, migration, upgrade, recurring outages, a recent ransomware, a failed compliance or regulatory exam, capacity, or technical debt. Those matter. But before spending the bulk of the engagement tuning a query, the provider should understand whether the environment is fundamentally recoverable and safe enough to work on. I always call that, “the things that we can’t sleep at night knowing you have wrong.”

Initial work should look for high-risk issues such as missing or broken backups, including the ever-present “rogue backup” we find with sp_CheckBackup, restore/recoverability problems, corruption, missing integrity checks, serious configuration issues, broken maintenance, capacity or storage threats, obvious HA/DR risk, and dangerous preexisting conditions (Yes I mean it’s not normal to get a stack dump and failover every day when change tracking cleans up with the busier afternoon cleanup…)

Two trains on the tracks

Sometimes we have to do what I call “putting two trains on the tracks” in sales and onboarding calls… We have a team for a reason and we can multi-task even for one client.

One train deals with the scary things capable of causing data loss, outages, or serious business risk. The other deals with the reason the client originally called.

A good provider should not refuse to touch the performance problem until a 97-point checklist is complete. It also should not spend 30 hours tuning queries while nobody notices the database has not had a valid backup in six weeks. It’s balancing those that makes a difference. The best tuned database doesn’t matter when Murphy swings by and breaks it all hard because we all agreed to save that “boring” stuff for later.

When should monitoring be installed? Ideally very early, even before the official start date is what we strive for when the access is good and we sign early enough. Installing monitoring is not the same thing as managing the environment, though. Once data starts flowing, someone still has to review it, understand what matters, tune noise, escalate real risk, learn what is normal for this environment, and prevent recurring alerts from becoming “the one we ignore.” That first month we are titrating alerts, negotiating on which errors are really “acceptable”, fixing maintenance, and trying to make the daily checks more green and make your server become a happier, quieter server in our dashboards.

What happens if something dangerous is found immediately? There is no true catch-all answer. Every company has different change-management expectations. Some say “just fix it.” Even then, a good provider will explain what was found, why it matters, and what is about to change. Anything requiring downtime needs an approved plan or window. If something is truly dangerous and the client is not responding, escalation may move from tickets to emails to phone calls to increasingly more direct communication. Part of onboarding is learning how your company makes technical decisions and approves change.

How are priorities decided? A useful model is the one I talked about in the health check blog post last month: Finding → Risk → Priority → Owner → Action. In practice the provider and client has their own priorities, but a provider also is coming at this from being burned a LOT. Corruption, for example, is rare for most folks – but a SQL Server consultancy sees it all the time and gets those phone calls where the answer is “sorry we can’t do anything, you should have called us last week.” The provider may be most concerned about recoverability; the client may be most concerned about the performance issue users feel every afternoon. Both matter. Sometimes work can proceed in parallel. Sometimes available hours or severity mean lower-priority work genuinely has to wait.

How many DBA hours does onboarding consume? It varies substantially. For many engagements it falls in the 5–10 hour range, but access problems, security processes, multiple teams approving the various accounts and VPNs and firewalls, poorly documented VPN/PAM systems, vendors with SA access approving access, and unavailable customer resources can stretch it.

Sometimes the right answer for us is to delay the formal onboarding date rather than burn a client’s paid DBA hours fighting an access problem they are not yet ready to solve.

What should be different by Day 30? Green everywhere is not the test. But the big risks absolutely should be calming down.

By approximately Day 30, monitoring and daily reporting should be flowing, major access issues should largely be resolved, the primary relationship should be established, the scariest findings should be decreasing, backup and recoverability gaps should be understood and being addressed or, frankly, solved where the provider can just fix it, missing maintenance should be improving, and overall stability should be moving in the right direction. A terrible environment may still have plenty of red. It should simply be safer than Day 1.

How disruptive is onboarding to your team? There is some disruption. Someone (or 3 teams) on your side will need to help with access, answer environment questions, and participate in prioritization. We’ll send inventory documents that your team needs to fill out identifying owners and purposes of servers. The better providers keep that load as reasonable as possible, but it is not zero. It does go down with time once we are onboarded. We do a check-in call at least monthly and the more folks impacted by the SQL Servers and who impact it that show up, the better. Though we find it a lot easier with one owner on the client side ultimately responsible for the final answer and direction.

What if a major incident happens in week 3? A provider that has already established access and started the process of learning the environment should be able to respond without starting from zero. The response will still be constrained by the access, change control, and vendor relationships that exist at that moment, but that’s why you hired us – and the DBA life is a fun life with new challenges and problems – a good team is jumping in and helping, but success may not come as quickly as it would have on day 67.

Days 30–60: Stabilize and begin solving the original problem

The second month should start moving forward in a more steady way.

You are still remediating findings, reducing scary risks, cleaning up remaining access issues, tuning alerts, and challenging recurring “acceptable” errors. The support team has stabilized much of the environment, best practices are becoming the norm, the most critical servers are good, the other ones are getting the checks. The Lead DBA is meeting at least monthly and the performance, migrations, upgrades, architecture, technical debt, or projects you brought the DBA as a Service team in for are being addressed and planned.

This is the transition from pure onboarding and discovery toward normal managed DBA work and a DBA relationship.

When does the Lead DBA actually know your environment? There is no magic date. Context begins accumulating immediately through sales notes, kickoff, onboarding data, and early tickets. “Knowing the environment” does not mean memorizing every database name. It means understanding the applications, business priorities, unusual vendor requirements, maintenance windows, decision-makers, recurring issues, known landmines, architecture, what absolutely cannot go down, and what the client is trying to accomplish.

You should not have to reintroduce your company every time you open a ticket and the consistency from the lead DBA being involved and meeting regularly really helps that. And the full team is made aware of what is going on with the clients because we let our team take vacations.

What happens if the plan is clearly undersized once the real backlog is visible? This can happen. At Straight Path we often talk about that risk in sales calls where we have our discussions about managed DBA services pricing. A good provider raises that potential directly instead of waiting for the “Oh crap” moment. Options usually include adjusting the plan, extending the timeline, or accepting that some items will remain lower priority. It should depend on the needs and budget of the client – and that’s why we used to call our service “FlexDBA” – clients can still flex up or down when the needs dictate.

Days 60–90: Heading towards a normal rhythm

By the third month you are learning what the real ongoing relationship looks like. You should have met with your main contact at least a few times towards the end of that 90 days.

Initial firefighting should be declining. There is actual evidence of how many hours the environment consumes, what recurring responsibilities exist, what projects are coming, how much technical debt remains, and whether the current service level is properly sized.

This is the natural point to ask what success looks like three, six, and twelve months out, and whether the service level still makes sense for the next quarter. And at Straight Path that’s what we do – we want to plan for the future with you. “Where do you want to be in a year?” is something we should know by the end of the first quarter and a plan should be formed that helps get there. Titrated to the budget and your competing priorities and the time we need.

What can make the first 90 days go badly

Common failure patterns:

• Access is not ready. Credentials untested, no clear owner, security teams not aligned
• Nobody can approve anything. Risk is found but remediation cannot be authorized
• Prolonged email tennis between provider, MSP, sysadmin, and security. When that happens, stop emailing and get the right people into a meeting
• Fun with Software Vendors. An application vendor complicates ownership and no one is sure where vendor responsibility ends
• Expectations were never set and aligned.
• The client expects the provider to “take everything over tomorrow”. That is fine but we need the access yesterday for that to happen
• The plan is undersized relative to the real backlog. This is a real risk, it’s why often in sales calls when we price per hour – I’ll suggest a lot of clients move to Gold or Diamond the first quarter and give them a one time rollover of all unused hours one quarter – 45 hours with Gold saves the client about $1,500 over 45 hours with Silver and overage.

What you should expect by Day 90

From a healthy DBA as a Service relationship by Day 90:

• The provider understands the environment at a useful level
• Access is established
• Monitoring is producing useful information
• Serious risks are known and being addressed
• Urgent problems are less frequent
• Priorities are understood
• Communication has a workable rhythm
• There is a forward plan
• You know who to call; they know who you are
• The relationship no longer feels new

They should begin to feel like part of your team rather than a vendor or ticket queue. If you’ve ever watched a pet cat or dog go to sleep, you know that deep sigh they do right before they fall asleep? Content, happy, calm? You should be able to do that (for a brief moment, before you wake up and remember we’re only there for your database world. Sorry…)

How transparent should the provider be about remaining risk at Day 90? Very. A useful conversation includes what is improved, what is still outstanding, what is deferred and why, and where residual risk remains. “Everything is fine” is rarely accurate. Honesty and transparency go a long way to a long-term relationship. You should know the risks that still exist and the plan around them.

What this looks like at Straight Path

The expectations above are what any healthy DBA as a Service relationship should produce. How individual providers deliver them varies.

At Straight Path the model includes a named Lead DBA, support from the broader team, structured daily review processes, and deliberate attention to relationship continuity and internal accountability so context does not live in only one person’s head.

This is not the only valid way to deliver the service. It is how we have chosen to do it.

Closing

The first 90 days should not be measured by whether every health-check item has turned green.

Measure whether you are less blind. Measure whether the most dangerous things are becoming less dangerous. Measure whether recurring problems are starting to disappear. Measure whether the DBA team understands what actually matters to your business. And measure whether you are beginning to spend less time worrying about SQL Server and can sleep even just a bit better.

By Day 90 you should not feel like you are still onboarding a vendor. You should feel like you have added a DBA team to your existing team. You should feel confident in the health of your database estate. Otherwise you just onboarded one more thing to worry about.

The post What Should Happen in the First 90 Days of a Remote DBA Relationship appeared first on SQL Server Consulting - Straight Path Solutions.