Need for Secondary to be up-to-date
|
Ensures that the Secondary is always current.
If the synchronous attribute is set to override, the Secondary is current, except in the case of a network outage.
|
Ensures that the Secondary reflects the state of the Primary at some point in time. However, the Secondary may not be current. The Primary may have committed transactions that have not been written to the Secondary.
|
Requirements for managing latency of data
|
Works best for low volume of writes.
Does not require latency protection (because the Secondary is always current).
|
Could result in data latency on the Secondary. You need to consider whether or not it is acceptable to lose committed transactions if a disaster strikes the Primary, and if so, how many.
VVR enables you to manage latency protection, by specifying how many outstanding writes are acceptable, and what action to take if that limit is exceeded.
|
Characteristics of your network: bandwidth, latency, reliability
|
Works best in high bandwidth/low latency situations. If the network cannot keep up, the application may be impacted.
Network capacity should meet or exceed the write rate of the application at all times.
|
Handles bursts of I/O or congestion on the network by using the SRL. This minimizes impact on application performance from network bandwidth fluctuations.
The average network bandwidth must be adequate for the average write rate of the application. Asynchronous replication does not compensate for a slow network.
|
Requirements for application performance, such as response time.
|
Has potential for greater impact on application performance because the I/O does not complete until the network acknowledgment is received from the Secondary.
|
Minimizes impact on application performance because the I/O completes without waiting for the network acknowledgment from the Secondary.
|