Practical database expertise for businesses that depend on SQL Server. From a focused health check to ongoing remote DBA support, DBTECH helps you understand the risks and make the right
improvements.
25+ years of hands-on experience · Based in Sheffield · Remote delivery
SQL Server specialistsAdministration, development and tuning
Established in 2011Independent, consultant-led delivery
Flexible engagementProjects, retainers and MSP partnerships
Services
The right expertise.
Where you need it.
Address an immediate issue, plan your next migration or put dependable database support in place. Each engagement starts with your systems, priorities and business requirements.
Your client relationship.
Our SQL Server expertise.
When a client needs deeper database expertise, DBTECH can work alongside your team. Agree the delivery model, communication and responsibilities before work begins.
Discuss the environment, symptoms and business impact. Agree access requirements and a scope before work starts.
02 / IMPROVE
Work from the evidence
Investigate the cause, explain the options and agree changes. Plan validation and rollback around your operating requirements.
03 / HAND OVER
Leave a clear next step
Document findings and changes, share recommendations and agree any follow-up support your team needs.
About DBTECH
Experienced hands.
A direct conversation.
DBTECH Solutions Ltd was founded by Richard Morrison in November 2011. Richard brings more than 25 years of SQL Server DBA and development experience across public and private sector
environments.
Work directly with a consultant who understands database administration, query performance, data integration and the operational demands behind them.
Richard’s professional experience includes work with Hiscox, the NHS, Pearson, Royal Mail, British Gas, Unilever, Bet365 and Yorcard. These references describe professional
experience, not endorsements or current client relationships.
Understand the environment, find the cause and leave the team with a clear way forward.DBTECH’s approach to consultancy
SQL Server · T-SQL · AlwaysOn · SSIS · SSRS · SSAS · Azure
Contact enquiries
Let’s talk about
your SQL Server.
Tell us what you’re working on, what’s causing concern and the timescale you have in mind. We can then discuss a suitable next step.
Optimising SQL Server performance, one query at a time.
Azure SQL failover: can the application recover too?
By DBTECH Solutions Ltd · 26 October 2026
A database can recover while customers still cannot complete a transaction. Database failover changes which database accepts writes. It does not automatically move the application,
restore user traffic or prove that the business service is back.
Two different failure boundaries
High availability (HA) reduces interruption from failures within a defined design. Disaster recovery (DR) addresses more severe disruption, such as a regional outage. Azure SQL Database can be
configured for both, but the protection depends on the service tier, region and settings you actually use.
Availability Zones are separate groups of datacentres within an Azure region. With zone redundancy enabled on a supported Azure SQL Database configuration, Azure manages the database response to a
zone outage. Requests in progress may be interrupted, so the application still needs to handle transient connection errors and retry safely. It does not need to select Zone 1 or Zone 2 itself.
[1]
A zone outage and a region outage are different events. Zone redundancy within Region A does not, on its own, provide a database in another region.
Regional recovery needs a second path
To recover from a regional outage, configure a geo-secondary in another region, such as Region B, and place the databases in a failover group. Azure replicates changes to the secondary
asynchronously. If a forced failover is required, recent transactions may not yet have reached Region B and could be lost. [2]
The failover group provides a stable read-write connection name. The application should use this failover-group endpoint rather than a server-specific address. The endpoint uses the Domain Name
System (DNS); after the database roles change, Azure updates its resolution to the new primary. [2]
Existing sessions can still break during a failover. The application must reconnect, retry transient failures with suitable backoff, and avoid blindly repeating a business operation when it is
uncertain whether the first attempt committed.
The application needs its own recovery design
In this example, the application runs in Region C, separate from the primary database in Region A and the geo-secondary in Region B. If Region A fails, the application in C may keep running while
Azure promotes the database in B and redirects the failover-group endpoint.
That only restores the database connection path. The application, its identity, network access, secrets and other dependencies must also work in Region C. Users need a route to the application,
and Region C needs enough capacity for the workload. If the application exists only in Region A, moving the database will not bring the complete service back. [3]
Test a business transaction, not just a role change
A planned failover drill lets the primary and secondary synchronise before switching roles. Use it to test the full journey: a user reaches the application, signs in, completes a representative
transaction, and can read the resulting data. Then test the planned return to the original region. [4]
Set recovery targets around the business outcome. The Recovery Time Objective (RTO) is the target time to restore the required service. The Recovery Point Objective (RPO) is the maximum data loss
the business is prepared to accept, expressed as time. Measure when customers can complete the transaction again—not only when the database becomes primary.
At your next recovery review, ask: if Region A became unavailable, could users still complete a transaction—and have you proved it?
DBTECH Solutions Ltd can help review SQL Server and Azure recovery designs and test them against business requirements.
Print