Replicate your data

Data replication may be the key to improved availability and performance in
today’s internet-dominated industry. Melanie Kacerek of Quest Software explains.

Data replication may be the key to improved availability and performance in today’s internet-dominated industry. Melanie Kacerek of Quest Software explains

Today’s corporations are struggling with the recent explosion of online users taxing e-commerce and ERP environments. The increased number and complexity of enquiries and reports overload the production instance and bring mission-critical systems to a crawl, especially at peak times. Furthermore, increased reliance on these applications to run essential processes makes downtime more expensive than ever. As a means to increase availability and performance in today’s application environments, companies require a redundant, live and up-to-the-minute replica of their production data — the basis for data replication.

Many companies focus their efforts and investment primarily in preparing for catastrophes, such as viruses, hurricanes, floods and power failures. In actuality, most companies experience the majority of their outages as a result of application failures, human error and planned downtime. To achieve true high availability, all outages, both planned and unplanned, must be minimised.

One of the most prevalent solutions to eliminate downtime is through redundancy. Utilising duplicate hardware, businesses can continue to operate even if one computer fails. In this scenario, all computer components need to be redundant, including the networks, the software and the data. Although this solution is easy to promote, it is not easy to implement.The difficult challenge centres on keeping the most volatile and mission-critical aspect of the business redundant — the data. Replicating data as it changes justifies the investment in the duplicate hardware. With current data on the secondary system, its value is maximised.

Replication solutions come in two flavours — hardware and software. The hardware solutions replicate all changes from one system to the other. These solutions can be synchronous, ensuring that every change made on the primary system is simultaneously made on the secondary system. If run in synchronous mode, the secondary system’s data is inaccessible until the moment of need, but when users are switched to that secondary system, it has every last change that was performed on the primary system prior to its failure.

Software replication solutions on the other hand vary greatly. Some solutions replicate synchronously, allowing changes to the primary system only if the same changes can be made to the secondary. Other software replication products perform asynchronously. Within this segment, the solutions vary in terms of completeness, accuracy, performance, latency, and flexibility.

For replicating an Oracle database, three forms of software replication exist. The first solution, called the standby database, is maintained by copying the archive logs from the primary system to the secondary, and then applying the history of changes contained in those logs to the secondary database. This solution is complete, in terms of replicating all types of data and all types of changes that occurred.

For standby database replication, latency is another concern and depends on the log switch frequency on the source system. If the redo logs switch every 15 minutes, then the target database will be at least 15 minutes behind the source database. Once the log is archived, it can be copied and applied to the target. If the source system fails, the target database will lack the database changes recorded in the current redo log and possibly the most recent archive log.

A second form of replication for Oracle databases is a trigger-based solution. This replication supports limited data types, usually excluding long columns and sequences. It is also tricky to manage successfully; requiring extensive knowledge of the applications in order to insure that the replicated data is an accurate representation of the primary database. If the procedure is not managed carefully, the transaction can be flawed.

The third and preferred option for Oracle database replication is log-based replication, which has more extensive support for data types including long columns, long rows, and sequences (data types frequently found in many ERP solutions). A log -based replication solution uses the redo logs as its source of change information about the production database. Oracle writes to the redo logs prior to committing the transaction to disk. Therefore, log-based replication begins reading from the redo logs as soon as a transaction begins to be recorded.

Although disaster preparation is essential to a complete high availability strategy, most system downtime is planned for hardware, software and database maintenance. In order to minimise these outages, database updates and operating system upgrades should not interfere with business. Traditionally, database migrations to new versions required extensive hours of downtime. However, with redundant, independent databases, rolling updates and upgrades can be performed as one system is updated while business operations continue on the other. When the update or upgrade is complete, the replication solution should get the system caught up with the business transactions that occurred during the upgrade. Once the upgraded system contains all of the current data, users can switch to the system to enjoy the benefits of the update without the downtime it required to be performed.

Quest Software

www.quest.com