Red9

Directions Website

SQL Server Consulting, managed services, and emergency support from expert DBAs.

At Red9, we specialize in SQL Server consulting and management, helping businesses from startups to Fortune 100 companies optimize their data environments. Founded in 2014 in Atlanta, Georgia, our team brings decades of combined experience to ensure your SQL Server runs securely and efficiently. We offer a full range of services: SQL Consulting, Managed SQL Services, Emergency SQL Support, Performance Tuning, Database Migrations, and Upgrades. Our focus is on delivering practical solutions that solve real problems, backed by our reputation as a trusted Microsoft Partner across 44+ industries. At Red9, we don’t just maintain your systems—we enhance them, ensuring your data is secure and your business runs smoothly. Connect with us at Red9 to see how we can help take your SQL Server management to the next level.

10/14/2026

Our senior DBAs take turns on call. A full week, Tuesday to Tuesday, day and night.

One of them came off his latest week with a handful of urgent alerts. Before then, he'd gone months without one.

So where do urgent alerts come from? In his words, two places. A disaster, or a new client.

A new client's servers arrive set up by whoever looked after them last. Until we get the disks the way we want them, our monitoring catches problems early, and some arrive as urgent alerts.

Then things settle. The alerts drop off.

If you're choosing someone to look after your databases, ask what their first month with a new client looks like. A provider who has done this enough times will have a straight answer.

10/12/2026

A water leak took out every server at one of our clients' disaster recovery sites.

A month earlier, we'd run a failover test to those exact servers.

Nobody phoned us about the leak. Our monitoring flagged the servers as unreachable, so we phoned the client.

Their answer: those servers are gone.

Production kept running. The client has three sites, so losing one still left two.

Two things worth checking in your own setup.

Does your DR site get the same alerting as production? A DR test tells you the site worked on test day. After test day, monitoring is the only thing telling you the site still exists.

What else lives at your DR site? Here, the development server sat on the same list of lost servers. Production was fine. The developers had nowhere to work until we built them a new dev server.

If your DR site disappeared tonight, how long until someone noticed?

10/08/2026

A financial client's SQL Server upgrade showed lower CPU usage afterward, with the same instance size.

The move was from SQL Server 2016 to 2025, on a database of up to 4 terabytes. Earlier CPU spikes reached around 40 to 50%. In the later chart, they stayed below 40%.

Before the move, Red9 ran workload replay for a week. Capture the production workload, replay it on the new environment, and compare it call by call. That is how you know before cutover whether performance holds.

This was the second migration we had done for this client. It went smoothly, with a firewall configuration issue to resolve.

Lower CPU on the same instance also means there is now room to reduce the instance size, which is where the licensing cost sits.

Planning a SQL Server upgrade? Message Red9 to discuss the preparation and testing.

10/07/2026

A proposed tuning change for a warehouse application showed promising figures in Red9's report:

Average duration: 4,667 ms to 625 ms.

CPU time: 1,455 ms to 48 ms.

Logical reads: 861,879 to 19,891.

The recommendation included rewriting how a stored procedure filtered and retrieved data.

On our call lase week, the change had not been implemented. It still needed to go through the client's review, testing and release process.

Clear performance reporting should show both the potential improvement and the current stage of the work.

Production results come after rollout and measurement.

10/05/2026

A detail in a query's data type comparison was part of a substantial tuning opportunity.

Daniil described investigating a query with high CPU consumption. One side of a join was non-Unicode, the other Unicode, and SQL Server was converting on every row. The work combined an explicit conversion with an index addition.

The report compares:

Average duration: 23,280 ms to 101 ms.

Logical reads: 3,232,114 to 50.

The daily production savings were still described as expected during the call.

For your own workload, check the data types being compared and the conversions in the ex*****on plan. Validate the results returned by the query alongside its performance.

10/01/2026

The unexpected finding in a server disk space investigation: Microsoft Word logging.

A healthcare client's machine, which hosted a SQL Server Integration Services catalog, was running out of space on its C: drive.

Daniil traced the space consumption to extensive logging enabled under a user account. Between 50 and 70 gigabytes of log files. He reported that things returned to normal after that logging was disabled.

Windows still relied on the affected drive. Fill it and the SQL services stop, and so does Windows.

Include the operating system drive in your capacity monitoring, and investigate which files are growing when free space starts falling.

This case is a useful reminder to check the whole machine when supporting a database environment.

09/30/2026

A tuning report is one stage of improving SQL Server performance.

In a case Daniil described, the client was willing to implement Red9's recommendations. Each change still needed review, testing and a place in the release schedule. Three to six weeks from recommendation to rollout.

The application also ran across roughly 20 customer databases with the same schema, creating scope to evaluate useful changes more widely.

For each recommendation, record who owns the next step, what testing remains, and how the result will be measured after release.

That gives the DBA and application teams a shared view of the work still needed to turn a recommendation into a production improvement.

09/28/2026

The cutover took minutes. Preparing for it took considerably more work.

For a banking client moving from SQL Server 2019 to 2025, Red9 used a distributed availability group to keep the production cutover short.

One limitation needed careful planning: after failover, we could not simply switch back to replicas still running SQL Server 2019. Backups taken on 2025 would not restore onto 2019 either.

Before production moved, we replay-tested workloads from every database against the target version. The application team could see how their workload behaved in the new environment.

We also encountered an access issue after required logins were omitted during an access cleanup. That reinforced the need to agree and test required access before the migration window.

If you are planning an upgrade, make sure your recovery plan answers this:

What happens if we need to return to the old version after new transactions have arrived?

09/24/2026

Query Store can give you a useful starting point.

In one software client's database, the leading query accumulated roughly 675,000 milliseconds of total duration over an hour. The next query was around 75,000.

That difference deserved attention. It did not explain the cause.

A query can lead the chart because it runs frequently, because individual ex*****ons are slow, or because it spends time waiting.

Each calls for a different response.

Before choosing a fix, we look at ex*****on count, average duration, CPU, logical reads, waits, and the ex*****on plan. We also check what the application needs that query to do.

After a change, we measure again over a comparable period.

For teams investigating slow applications, this is a useful habit: use the ranking to focus the investigation, then gather enough evidence to explain the result.

09/23/2026

Some performance improvements come from looking closely at everyday application queries.

Across four queries in a software client's environment, Red9's tuning reports recorded these reductions in logical reads per ex*****on:

• 16,614 to 3
• 34,525 to 3
• 40,279 to 3
• 597,546 to 566

Each report documented an index addition.

Three indexes addressed export-status columns. The fourth supported a product lookup.

Average query duration improved across all four, including one reduction from 749 milliseconds to 26 milliseconds.

The client runs a separate database for each customer, so these findings also create opportunities to investigate elsewhere.

That wider rollout still needs validation. Customer databases can have different data volumes, existing indexes, and write activity, even when the application code is the same.

If your application repeatedly searches for rows awaiting export or processing, those queries are worth reviewing.

Address

11720 Amber Park Drive, STE 160
Alpharetta, GA
30009

Website

https://red9.com/

Alerts

Be the first to know and let us send you an email when Red9 posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Want your business to be the top-listed business in Alpharetta?