Análisis de los resultados

As mentioned previously, HDR can be configured to work in synchronous or asynchronous mode. This does not affect

how

HDR works, just

when

a certain operation occurs.

Conceptually, HDR is simple, elegant, and easy to understand. When database changes occur in a logged database, the changes are recorded in the instance logical logs. HDR takes these logical log records as they are created on the primary and transfers them to a replication buffer on the secondary instance for application there. When properly instantiated, the secondary instance is in a type of permanent roll forward mode as though it was in fast recovery and applying its own logical log records. With HDR, however, it is the primary instance log records being applied.

The transfer and application of logical log records to the secondary can occur either synchronously or asynchronously, thus the

when

component of HDR.

Synchronous mode

This is the most secure mode from a disaster tolerance perspective and is controlled by the DRINTERVAL $ONCONFIG parameter. When set to -1, whenever a logical log record is written to the HDR and logical log buffers, the log entry is sent to the secondary instance and entered into its replication buffer. The transaction is not considered completed (or rolled back) until the primary receives an acknowledgement from the secondary that the records have been received into its replication buffers. This does not mean the changes have been applied or been written to disk by the secondary, just that they have been received and are in stable, protected storage for later application on the

secondary. The net result is that there are no transactions that are uncommitted or partially committed on the secondary when compared to the primary; it is a

logically consistent copy and fully capable of seamlessly replacing the primary instance in the event of failure.

This mode can have a minor impact on application performance depending on the network interconnect and distance between the primary and secondary servers. As just mentioned, from an application perspective, it will not receive a commit or rollback message from the database instance until the transaction change records are received by the secondary. This means transaction speeds can be constrained by network conditions such as speed and distance between the servers. The delay can be measured by the amount of time it takes for a network round trip or how long it takes a packet to get from the primary server to the secondary and back.

Do not think that because network speed will have an impact on HDR the servers have to be placed next to each other. Consider the amount of replication traffic that will occur as well as the speed of the network itself. One of the authors has successfully instantiated an HDR environment over a very slow partial leased line from London to Central Scotland. While network speed was

substantially

less than 1-baseT, the HDR environment worked well because there was not a tremendous amount of data to replicate once the secondary instance was created. With higher transaction volumes, network speed and distance become more critical. Generally speaking, though, with better network speeds the two HDR servers can be almost anywhere in the world and function adequately in synchronous mode.

A commonly asked question with this mode is what happens if the secondary goes away, either due to a network outage or server failure: will the primary’s transaction halt until secondary acknowledgement is received? The answer to this is a qualified

yes

and

no

. The DRTIMEOUT $ONCONFIG parameter

specifies how long either server will wait to hear from the other before declaring a replication failure has occurred. From the primary’s perspective, this time could start based on the transfer of a transaction when busy or just the HDR heartbeat when idle. From the secondary’s perspective, it is measured by the heartbeat. What actually happens is that the servers will attempt to contact each other four times (in case there is a temporary network or server interruption) before declaring a failure. As a result, the number of seconds entered for DRTIMEOUT should be 25% of the total time an administrator feels is appropriate before declaring a failure.

Getting back to the earlier question of what happens to the primary if the secondary is not available, “yes” the transaction will hold until either an acknowledgement is received or DRTIMEOUT x 4 seconds has elapsed, at which point an HDR failure will be declared. Once a failure has been declared, the primary will not wait for the secondary but will process transactions as though

it is not part of an HDR replication pair. What happens when the secondary reconnects is discussed in 3.3, “HDR failure recovery” on page 27.

Asynchronous mode

When DRINTERVAL is set from 0 to any positive integer value, HDR operates in asynchronous mode, transferring transaction information from the primary to the secondary when either of two triggering events occur:

򐂰 The number of seconds specified by DRINTERVAL has passed.

򐂰 The HDR replication buffer becomes full.

Setting DRINTERVAL to 0 is

not

the same as synchronous mode, however. In synchronous mode, each transaction results in a send to the secondary, ensuring transaction-level logical consistency. When DRINTERVAL is set to 0, if more than one transaction completes at the same time, they will be sent as a batch. In addition, the primary does not wait for an acknowledgement from the secondary before committing the transactions back to the application.

The most significant side effect of asynchronous HDR mode is the loss of logical consistency between the instances. A transaction could be marked complete on the primary but not exist on the secondary. The larger the value of

DRINTERVAL, the greater the chances of losing transactional integrity. This could have business implications if a sudden need arises to convert the secondary to standard mode in which it can process transactions. Failure condition determination in asynchronous mode is much like in

synchronous mode. The primary will attempt to communicate with the secondary four times, either through a replication buffer flush or a heartbeat, before

declaring a failure. Likewise, the secondary will use its heartbeat monitor to decide if the primary is still available.

As mentioned earlier, HDR provides the greatest business value when executing in synchronous mode since a complete duplicate is being maintained. For some businesses, though, a very close approximation may be sufficient; a value of 0 or a very low number of seconds may be adequate, particularly since there is no transaction wait impact on the application.

In document EL APRENDIZAJE DEL ASPECTO VERBAL EN LOS TIEMPOS DEL PASADO ESPAÑOL. El pretérito perfecto simple y el imperfecto en estudiantes de ELE en Suecia. (página 107-114)