Tired of SQL Server performance issues and unexpected downtime? Red9 provides Omaha organizations with senior database administrators who make performance problems disappear. Only senior DBAs with 15+ years of experience. No juniors. SQL Server is all we do.
Talk to a senior DBA
A senior DBA reads this (not a sales rep) and replies within one business day. No obligation.
You see the findings and the price before you commit.
By clicking, you agree to our Terms of Use and Privacy Notice.
Prefer to talk? A senior DBA is reachable at 1-877-891-1870
SQL Server consulting in Omaha: the short answer
Red9 provides senior-only SQL Server consulting, performance tuning, managed DBA services, and emergency response to organizations across Omaha and the surrounding metro, including Bellevue, Papillion, La Vista, Elkhorn, Gretna, and Council Bluffs. We have worked one database engine since 2014, and no other. No work starts until the free 145-point health check is done. There are 120+ clients on our roster, from seed-stage startups up to the Fortune 100; Managed Services and Emergency Services clients get a production incident answered inside 15 minutes, and each change is measured on both sides.
Looking for a SQL Server consultant covering Omaha and Council Bluffs? Book your free assessment.
For its size, Omaha carries an unusual concentration of headquarters: a railroad, several insurers, a global construction group, an engineering firm, and decades of card processing. Those databases are judged on reconciliation and reporting.
Several national insurers are headquartered here, alongside regional banks and a payments-processing sector decades old. These estates carry reconciliation and settlement work where a missed batch is a finance problem. One platform arrived with no complete backup regime: case #1 below covers what we did.
A Class I railroad runs its network from downtown Omaha, one of the country's larger truckload carriers is headquartered in the metro, and intermodal traffic moves through constantly. Movement data gets queried by dispatch all day, so tuning happens through online index work.
A university medical center, a second large health system, and a nationally known research hospital give this metro a substantial clinical and laboratory data load. Lab-results tables hide the extreme numbers: modest frequency, enormous read counts, huge CPU time. Case #3 below has the readings.
A global construction group and a major engineering firm both run from Omaha, with irrigation and agricultural technology manufacturers and consumer distribution around them. Project-accounting and order systems fail on something small: a parameter with the wrong type, an index bypassed. Case #2 below is one word of code.
We work with organizations across the metro: Omaha, Bellevue, Papillion, La Vista, Elkhorn, Gretna, and Council Bluffs, out to Fremont, Lincoln, and Sioux City, across western Iowa, and statewide across Nebraska, all over secure remote access. Work is scheduled around your close and reporting calendar on Central time.
Principal-grade input on the architecture, filegroup, or capacity decision an Omaha team is about to lock in. The cheap moment to challenge a design is before the data lands on it.
From $4,995 / 20-hr block (hours do not expire)Senior administrators owning the fundamentals: full, differential and log backups, integrity checks, index and statistics maintenance, agent alerts, and a fail-safe operator who actually exists.
From $395 / moWhoever answers has already worked this failure mode, with a 15-minute response for Managed Services and Emergency Services clients.
From $2,500 / incidentStatements ranked by daily cost, then fixed where the fault sits: an index, a rewrite, a filegroup layout, or a parameter declared with the wrong type.
Version moves, Azure SQL, or AWS RDS, planned around your reporting calendar. SQL Server 2016 runs out of extended support on July 14, 2026, and 2017 the following autumn.
145 read-only checks over configuration, backups, security, and query cost, returned ranked by what each fix returns. The same audit runs on your own instance for nothing.
Recovery that has been performed rather than described. We design and tune clusters and Always On Availability Groups, then use log shipping, replication, or Change Data Capture (CDC) where only the changed rows should move.
Groundwork on the databases your team wants an assistant reading, whether ChatGPT (OpenAI) or Claude (Anthropic), along with the RAG pipelines, vector search, and analytical traffic those tools push at SQL Server. When reporting starts crowding transactions, we move the offload, SSRS and Power BI datasets included, onto Snowflake, Redshift, or the warehouse already in place.
"We have been using Red9 to assist with database maintenance and improvement over many months, and we have been very happy with the service we have received. They have helped with maintaining and improving system performance and with making major changes to improve scalability. Red9 has been proactive with identifying potential issues and fixing those issues before becoming major problems."
"For MSSQL 2012 DB maintenance plans and optimizations, Red9 is again the best SQL Server consultants… And I have worked with many."
"Nice. I saw our load times dropped again after the work you guys did over the weekend."
Four stages, days apart, and the senior DBA who audits your estate is the one who works on it. The ranked plan and its price land before any commitment does.
Which instances the business runs on, what the symptom looks like to whoever raised it, and what shipped in the two weeks before. The last question earns its place every time.
145 checks across instance configuration, whether the backups restore inside your target, where security stands exposed, and what each statement costs per day, ranked by payback. Curious first? Aim the same read-only audit at your own instance at no charge via our self-serve Health Check.
A single session on the report in priority order, with hours and cost against each finding, and nothing left in the small print.
Approved, we work the plan and take readings around every change, so each gain is verifiable in your own tooling. Managed services then hold the estate steady rather than letting it drift.
Three genuine Red9 projects, each tracked from the first review to the closing figure. Every reading came from the client's own instrumentation, on both sides of the work. Names stay out of it by agreement.
The problem. An identity-verification SaaS company had a production estate with no complete backup or maintenance regime, no integrity checks, and no alerting. All 577 of its non-clustered indexes sat mixed into the primary filegroup with the data, which left no control over how either was distributed. On top of that, tier-1 disks on both development and production kept logging the warning that an I/O request had taken longer than 15 seconds.
What we did. Fundamentals first. We deployed a full, differential and log backup plan, index and statistics maintenance, integrity checks, 14 SQL Agent alerts, and a fail-safe operator, and set trace flags 1117, 1118, 2371 and 3226. Then we created a dedicated INDEXES filegroup and migrated all 577 non-clustered indexes into it. Finally we ran disk-latency tests, isolated the poor random 4K figures to SAN multipathing rather than to SQL Server, handed the storage team the evidence, and re-tested after their fix to confirm the disks behaved as tier-1 storage should.
Traced to SAN multipathing, evidenced, and confirmed resolved on retest.
The result. The estate ended the engagement with scheduled full, differential and log backups, integrity checks, maintenance on a schedule, and alerts with somebody on the other end. Separating the indexes gave the client control over placement and growth, and the storage problem stopped being blamed on the database once the multipathing evidence was in front of the right team.
Why the filegroup split matters. With indexes and data sharing the primary filegroup, you cannot place them on different storage, size their growth separately, or rebuild them without touching the data filegroup. Moving 577 non-clustered indexes into their own filegroup restores all three options without touching a single query.
What was deployed (identifiers withheld):
-- Foundations built where none existed -- backups : full + differential + log, scheduled and verified -- integrity : DBCC CHECKDB on schedule -- maintenance: index and statistics jobs -- alerting : 14 SQL Agent alerts + fail-safe operator -- trace flags: 1117, 1118, 2371, 3226 -- filegroup : new INDEXES filegroup; all 577 nonclustered indexes migrated -- storage : RND 4K Q32T16 tests isolated SAN multipathing; retest confirmed fix
The disk finding is the part worth copying: test the storage yourself, in a way the storage team can reproduce, before accepting that the database is at fault.
The problem. A beverage retailer had a session-management MERGE statement running about 2,500 times a day at 5 seconds each, reading roughly 930,015 pages every time. The index it needed already existed. It was simply never being used, because the parameter feeding the filter had been declared as nvarchar while the column it compared against was varchar.
What we did. We changed the parameter declaration from nvarchar(32) to varchar(32). That is the entire fix. With the types matching, the engine stopped converting every row it examined and started seeking on the index that had been sitting there all along.
No new index, no rewrite, no schema change: nvarchar became varchar.
The result. A statement running 2,500 times a day stopped costing 5 seconds and 930,015 reads apiece and started costing a millisecond and 11 pages. This is the cheapest class of fix in SQL Server and one of the easiest to miss, because nothing in the code looks wrong.
What implicit conversion does. When a predicate compares two different datatypes, SQL Server converts one side to the other. If the conversion lands on the column rather than the parameter, every row must be converted before it can be compared, which makes an index seek impossible and forces a scan. The plan looks reasonable; the read count does not.
What we changed (identifiers generalized for privacy):
-- Session MERGE: ~2,500x/day, 5 s per run, ~930,015 reads. -- before: DECLARE @SessionID nvarchar(32) -- column is varchar(32) -- after : DECLARE @SessionID varchar(32); -- rollback: prior declaration retained
Matching the types let the existing index be used: 1 ms and 11 reads instead of 5 seconds and 930,015.
The problem. A healthcare provider group ran a SELECT DISTINCT over accession numbers on its lab-results table roughly 102 times a day. Each execution averaged 6,114.37 ms, burned 39,107.53 ms of processor time, and moved 2,707,891 disk-IO units, and the report's total-reads figure came to about 276.2 million a day. A hundred runs sounds like nothing; a hundred runs of that costs the instance about 66 minutes of CPU across the day.
What we did. We captured the plan and Query Store history, then designed a nonclustered index on the accession number and result timestamp columns so the engine can walk the values in order and skip duplicates instead of sorting a very large intermediate set. Create and rollback scripts went over together.
39 seconds of CPU per execution, gone from the instance.
The result. The query returns in under a millisecond, and its daily read total fell from 276,204,882 to 918. On a lab database that other clinical work shares, removing 39 seconds of processor time per execution is felt well beyond the query itself.
What the review found. The DISTINCT had no supporting index, so the plan scanned the results table and sorted to remove duplicates. On a table of that size the sort is what produced both the 39 seconds of CPU and the 2.7 million IO units per execution.
What we changed (identifiers generalized for privacy):
-- SELECT DISTINCT over lab accession numbers: ~102x/day, 6,114.37 ms avg. CREATE NONCLUSTERED INDEX IX_Red9_Result_AccessionNumber_ResultDTTM ON dbo.[Result] (accessionNumber, resultDttm); -- rollback: DROP INDEX IX_Red9_Result_AccessionNumber_ResultDTTM provided
Ordered index access removed the sort entirely: 0.71 ms per run, 9 disk-IO units, and 918 reads a day.
Those readings were taken on other companies’ servers. Half an hour is enough to tell you where yours stands.
Get a Free SQL Server Assessment ➜Rather talk it through? A senior DBA answers at 1-877-891-1870.
15 years or more behind whoever reads your plans, and the same person from the audit to the fix.
A single engine since 2014, and 10,000+ audited databases behind the judgment.
Duration, reads, and CPU captured around every change, and a plain note where a figure could not be measured.
Managed Services and Emergency Services clients reach a senior DBA within 15 minutes, whatever the hour and whatever the date.
No. Virtually every client of ours works over secure remote access on credentials they control. A senior DBA stays reachable through your whole Omaha workday on Central time, with 24/7/365 emergency cover on top for Managed Services and Emergency Services clients. Access stays under your control throughout: we connect over your VPN or bastion host on least-privilege logins you create and can revoke instantly, with further controls layered above, and each change arrives as a script your engineers read before it runs.
How the three options behave on the day an Omaha production database turns a reporting deadline into an incident.
| Red9 | In-house DBA hire | Generalist IT / MSP | |
|---|---|---|---|
| Seniority | Principal-grade SQL Server people only, 15+ years on average, with nothing junior beneath them. | A single hire owns the discipline, and the head offices in town compete for that person. | Generalist cover, where the database shares a technician with the network. |
| SQL Server focus | SQL Server is all we do. | Split with every other platform the role inherits. | One line item on a long list of supported products. |
| Emergency response | A senior DBA on duty round the clock all year, and a 15-minute response under Managed Services or Emergency Services cover. | Only what one person can cover while awake. | A queue measured in hours, longer at a weekend. |
| Proof | Readings taken around each change, and an honest note when one could not be captured. | Seldom recorded anywhere a board could review. | Summarized in a report rather than measured. |
| Cost model | By project, by month, or by incident, with nothing salaried in the gaps. | A loaded Omaha salary of roughly $110,000 to $135,000, plus benefits and the vacancy first. | Absorbed into a wider invoice with no database line to question. |
| Ramp-up | On your estate within days. | Months of recruiting, then months of learning the systems. | Slow to pick up, and you brief a new person on every ticket. |
Senior SQL Server cover can be in place before the next reporting deadline lands. Get a Free SQL Server Assessment ➜
Founder & Partner
25+ years making SQL Servers faster.
Chief Operating Officer
Chief Revenue Officer
Behind them works a senior-only DBA bench averaging 15+ years, and one named lead stays accountable for your outcome throughout.
We support Omaha-area teams over secure remote access, across the city, Bellevue, Papillion, La Vista, Elkhorn, and Council Bluffs. The same senior DBA answers whether the instance sits downtown, in a west Omaha office park, or on the Iowa side of the river.
Coverage runs across the Omaha metro, Nebraska, and western Iowa. Explore the areas we serve.
Five checks worth making before anyone touches production.
Find out how much of the year they spend inside this engine. The habits behind the worst problems only look obvious to somebody who meets them weekly.
Get the name and the years for whoever holds the credentials, and a commitment that it stays that person.
Ask what they do in week one. Anyone who leads with query tuning on an estate with no verified backups has the order wrong.
Response time and eligibility, in numbers, inside the agreement.
Sometimes the database is innocent. Ask for a case where they proved the fault sat elsewhere and handed over evidence somebody else could reproduce.
| Headquarters | Alpharetta, GA (Atlanta metro) |
|---|---|
| Founded | 2014 |
| Focus | Microsoft SQL Server only |
| Team | Senior-only DBAs, 15+ years average experience |
| Clients | 120+, from startups to the Fortune 100 |
| Databases audited | 10,000+ |
| Rating | 4.9 out of 5, 120+ reviews |
| Emergency response | 15 minutes, 24/7/365, for Managed Services and Emergency Services clients |
| Engagement models | Scoped project, monthly retainer, or per-incident |
| Service area | Omaha, Council Bluffs, and eastern Nebraska, plus nationwide via secure remote access |
Yes. Red9 covers Omaha and the surrounding metro, out through Bellevue, Papillion, La Vista, Elkhorn, Gretna, and across the river to Council Bluffs, with a senior SQL Server consultant on the account. Remote is what nearly all of our clients use, because it puts a principal-grade DBA on the instance while a local visit is still being scheduled. Managed Services and Emergency Services clients hold an emergency response of 15 minutes.
15 minutes, any hour, any day of the year, and a senior DBA answers instead of a ticket queue. This response-time SLA is available to current Managed Services clients and Emergency Services clients. See Emergency Services ➜
The free 145-point health check happens first, which is the difference between a quote and a guess. Managed services and remote DBA then start at $395/mo, a 20-hour senior DBA block is $4,995 with hours that do not expire, and 24/7 emergency response is priced from $2,500 per incident. Against a loaded Omaha DBA salary of $110,000 to $135,000, set out in the comparison above, a month of retainer costs about four percent of a month of that hire. Larger programs are priced once the check is in.
With the things that decide whether a bad day is recoverable. A full, differential, and log backup regime comes first, then integrity checks, then index and statistics maintenance on a schedule, then alerts so somebody hears about a failure before a user reports it. Tuning waits, because a fast server you cannot restore is still a liability. On one estate, described in case #1 above, we did exactly that and added 14 agent alerts plus a fail-safe operator where there had been none at all.
Easily, and it is one of the most expensive small mistakes in SQL Server. When a parameter is declared nvarchar and the column it filters is varchar, the engine converts every row rather than seeking, so a perfectly good index sits unused and the read count explodes. We look for implicit conversions early because the fix is usually one word. Changing a single parameter declaration, in case #2 above, took one statement from 5 seconds to 1 millisecond and its reads from 930,015 to 11.
Very much so, because low frequency hides high cost. A hundred runs a day sounds harmless until each one moves 2.7 million IO units and burns 39 seconds of processor time, which adds up to about 66 CPU-minutes across the day. We index the columns it needs in order, then check the new plan against the old readings. That one, in case #3 above, went from 6,114 ms to 0.71 ms, with daily reads down from 276,204,882 to 918.
Yes. Omaha nonprofits and government agencies get the free 145-point health check on the same terms as any commercial client, and 145 findings come back in risk order with a price attached to each, written to be read in a board meeting or a county budget review. Managed services and remote DBA run from $395/mo. A 20-hour senior block is $4,995 and the hours do not expire.
Which versions and cloud platforms we support, and how an engagement is put together, live on our SQL Server consulting page.
Half an hour is enough to show where your SQL Server is losing speed, uptime, and money, and what each of those takes to put right. The free SQL Server assessment gives you the findings and the figure first, with nothing owed.
Schedule My Call Now ➜Rather talk it through? A senior DBA answers at 1-877-891-1870.
