Amongst other IT services like desktop and network management, corporate portals, etc., WANs are often used for disaster prevention. Many applications are required to operate across a WAN. If an enterprise is also doing high performance and disaster prevention of SQL database servers, Low WAN quality adds more difficulties to these operations. They can lose connectivity a few times per day and the latencies can vary widely

A replication queue is the ideal device in order to absorb the intermittent WAN outages and varying latency. To provide a smooth recovery operation, a two-way replication scheme is typically used (see figure below). This design allows the replication queues to absorb imperfect WAN problems in both directions.

A replication queue is the ideal device in order to absorb the intermittent WAN outages and varying latency. To provide smooth recovery operation, a two-way replication scheme is typically used (see figure below). This design allows the replication queues to absorb imperfect WAN problems in both directions.

There are a few operating issues:

1. Instant SQL Server fail-over is not possible since it must wait for the replication queue to clear. Typically, this is a manual operation.
2. Similarly, restoring a SQL Server must also wait for the reversed-direction queue to clear before the cluster can resume service,
3. Data corruption in either replication queues, or in any SQL Server will require extended service downtime since rebuilding a dataset across WAN can take a substantially long time if the dataset is larger than 100GB.
4. The primary SQL Server must be throttled to ensure slower transaction processing speed so it will not flood the replication queue.
5. Primary and secondary SQL Server require different maintenance routines since not all database changes are replicated. Some database objects, such as logins, permissions, stored procedures and schema changes are not replicated.

Due to poor WAN quality, DB^x™ cannot directly eliminate these issues. It can, however, improve these operations.

This is called the "Intelligent Switch" configuration. DB^x™ is installed between clients and SQL Servers acting as an automated switch of operations for cases of fail-over and recovery:

1. Automated seamless automatic fail-over. With DB^x™ monitoring of all client traffic, using DB^x™ SDK (Software Development Kit), we can provide seamless primary->secondary switchover by monitoring Q1's state.
2. Automated seamless fail-back, using DB^x™ SDK when restoring the primary SQL.
3. No change in application code. No need to treat stored procedures.
4. When a complete dataset is needed, DB^x™ can reduce service downtime to be less than one minute per incident by using DB^x™ automatic resynchronization tool.
5. Tolerates intermittent WAN outages and long latencies.
6. Simple deployment: single (IP, port) entry.
7. DB^x™ offers a potential to upgrade system by adding load balancing SQL Servers over LAN and WAN for zero-loss continuous protection when network quality improves.