VERITAS Database Replication Option TM for Oracle

Transcription

1 VERITAS Database Replication Option TM for Oracle Presented at Oracle Open World Los Angeles, CA at 2:00pm Marty Ward Senior Product Manager VERITAS Software Corporation Executive Summary Continuous availability and high performance requirements make it difficult to perform basic maintenance and operational tasks on the Oracle databases driving today s corporate processes. Tasks such as backing up data, extracting data for decision support systems and running operational reports consume processing resources resources that are required to maintain the highest possible performance and availability. One solution to this dilemma is to off-load these tasks to another system, replicating the production database to the secondary system. In this configuration, maintenance and reporting tasks can take place at the DBA s convenience, as these activities have no impact on the production system. But replicating and synchronizing these systems for off-host processing presents a number of challenges. The VERITAS Database Replication Option for Oracle provides a software solution for replicating critical Oracle databases on commodity hardware. The Database Replication Option simplifies and automates the replication and resynching processes, enabling a wide range of off-host processing on the replicated system. This provides enhanced maintenance and operational capabilities without detracting from the availability or performance of production systems. VERITAS Database Replication Oracle Open World 1

2 Overview Oracle databases are behind many of the applications that drive today s businesses. As more and more critical systems rely on core databases, the Database administrators (DBAs) responsible for these systems are pressed to provide ever-higher performance and availability. Whether internal or external, users expect fast response times and continuous availability from today s systems. And problems with these systems can have a significant impact on a company s productivity or profitability. No matter how sophisticated the application, the underlying database still requires basic maintenance. For example, regular backups are critical for protecting against a wide variety of failures. Even performing online backups has a performance impact on the running system. Other maintenance or production tasks include extracting data for decision support systems and performing production reporting. These, too, affect performance. In fact, the increasingly critical nature of these database applications make maintenance operations even more important. Decision support systems, for example, extract valuable corporate information from transactional data. The challenge is performing these operations in a continuous up-time environment. Years ago, companies scheduled system downtime in the early hours of the morning. They used this time to upgrade software, perform backups, and run batch processing against the system, generating production reports or loading new data. In today s global environment, many corporations have no real downtime windows. Global corporations work in so many time zones that when offices are closed in California they are open in Hong Kong. Many companies serve consumers that expect to be able to place an order at any time of the day or night. Without downtime windows, today s database administrators (DBAs) are forced to find ways to perform maintenance and operational tasks while the database is available. The larger the database, the more difficult these tasks become. The following sections describe the specific challenges of some of the most common tasks. Backups Maintaining recoverability of the database requires performing frequent and accurate backups. The simplest backups are performed with the system offline; the backup generates a consistent image of the database. With compressed downtime windows, database vendors started supporting hot or online backups. An online backup, taken when the backup is available and in-use, actually writes a fuzzy backup; the backup does not necessarily represent a consistent database state. To recover from an online backup, the DBA must apply the archived redo logs. This ensures that any outstanding transactions at the time of the backup are either committed or rolled back, and brings the database back to consistency. While online backups are much more practical for high availability databases than cold backups, they do have a few drawbacks: To perform an online backup, the database must be in a BACKUP state. This has implications for the redo logs and rollback segments. Very large databases may see a performance impact. As a result, most sites still try to find a low-usage time of day to run online backups. The backup uses CPU and I/O cycles on the production database system. In a system that is CPU or I/O bound, this will have a significant performance impact. Recovering from these backups entails replaying archived redo logs. This is a slow process, as you need to redo each transaction that occurred in the database from the point of backup to the current time. The more online redo logs, the longer the recovery time. Taking backups more frequently reduces the recovery time in case of an outage, but may affect ongoing performance. VERITAS Database Replication Oracle Open World 2

3 Reporting Running production reports against large databases can have a significant performance impact on the system. DBAs typically schedule regular reports for low-usage times of day, but this can be difficult to arrange as usage increases around-the-clock and as the database itself grows in size. For example, consider the case of a company that uses data processing software for producing tax returns. The IRS requires these companies to have all of the information that an auditor might require stored in flat files. An ERP business application will have a program to extract this information from the database on Oracle. If we estimate that an average system can extract 100 MB per hour, while an average customer may generate three to five gigabytes of data monthly, this would result in hours each month of reporting, during which production performance will slow noticeably. Decision support extracts The data residing in large transactional databases is a valuable source of information about a company s customers, products, operations, etc. Companies implement data warehouses and data marts to leverage this information into business knowledge. But to do so, they need to extract the data from the transactional system. Doing so may involve running queries that perform large table scans. Data extraction operations for the warehouse are resource-intensive. The larger the database, the longer the extraction, and the greater its impact on the system. Replicating Production Databases (or Off-Host Processing) For each of the cases described above, the real problem lies in the effect on the performance of the production system. Each of these problems can be solved by using a secondary system with the same data as the production system. In this paper, we will call processing performed against a secondary system offhost processing. The advantages of off-host processing are immediately apparent: Any performance impact occurs on the secondary system and does not affect production users. The DBA can perform operations at any convenient time of day instead of during limited low-usage hours in the middle of the night. The time constraint is gone if the backup takes longer to complete due to a media problem, or if the DBA wants to stop and re-run a report for any reason, the production system is not affected. With a replicated system, the DBA has a source for other maintenance operations, such as testing software patches or modifications before installing them in production. Users can work with realistic data for testing or training purposes without worrying about corrupting the data. The challenge, of course, is creating and maintaining a replicated system. The best solution will have a minimal performance impact on the production system, and will be easy to manage. If it is too difficult or time-consuming to perform the replication actions, then the usefulness of the replicated system is constrained. Ideally, any replication solution will also be affordable, using commodity hardware for which purchasing and management structures are already in place. There are several possible ways to create replicated data for performing these administrative functions. Some of the existing alternatives are described below. The new VERITAS Database Replication Option for Oracle provides a software solution to this problem that addresses the limitations of other alternatives and leverages the strength of VERITAS expertise in database and file system storage. VERITAS Database Replication Oracle Open World 3

4 Existing Replication Methods Existing replication methods today include: local disk mirroring remote disk volume mirroring replication using database transactions (archived redo logs) Each of these solutions has its own strengths and drawbacks. Local Disk Mirroring Local disk mirroring is a low-level approach to replicating production data. Using this technique, all write I/O instructions are written to multiple, redundant disk volumes. This technique is frequently used to provide high availability; if an initial device fails, then the system can switch to the mirrored device(s) immediately, without significant downtime or loss of data. Database Disk controller Mirrored disk Figure One: Local Disk Mirroring To use a local replicated system for off-host operations (such as backup or reporting), you need to decouple the replicated disks from the primary disks. At this point, you have a stable, frozen database image that is no longer affected by ongoing transactions. From this system, you can then perform backups, reporting, or other off-host processing. Although local disk mirroring works well for providing a failover system, it works less well for off-host processing. The problem with this approach for off-host processing is that at some point you have to resynchronize the replicated copy with the production copy. To do so, you must essentially recopy the production database to the replicated copy, then restart the local disk mirroring. This process is both timeand resource-consuming, and can have a significant impact for large production databases. Remote Disk Volume Mirroring Remote disk mirroring is similar to local disk mirroring, except that the primary and secondary disks may be separated by great distances. VERITAS Database Replication Oracle Open World 4

5 Database LAN or WAN Disk controller Disk controller Remotely mirrored disk Figure Two: Remote Disk Volume Mirroring Again, this approach works well for maintaining a failover system, as the additional physical separation of the disks eliminates another point of failure. Remote disk mirroring can introduce ongoing performance issues on the production server. The extent of this impact depends on the network performance between the primary and secondary sites, and the rate of write operations. A transaction is not completed until the database receives write verification. This approach has the same limitations for off-host processing as local disk mirroring it is difficult and time-consuming to resynchronize the replicated copy after detaching it to perform operations such as backup. Replaying Database Transactions While disk mirroring replicates at the disk I/O level, this method uses a logical approach, replaying each database transaction on the replicated system. The result is a logically identical database, assuming all operations are logged. Production Database Replicated Database Archived Redo Logs Figure Three: Replication through Database Transactions Using this method, you have two complete Oracle instances running. An initial backup from the production system is loaded to the replicated system. The production database runs in ARCHIVELOGMODE, and archives its logs as usual. The replicated database runs in recovery mode, constantly recovering the archive logs written by the production database. VERITAS Database Replication Oracle Open World 5

6 This method works well for maintaining a hot standby server for high availability purposes. But it has serious limitations for off-host processing: You cannot take a backup of a database in recovery mode. To take the backup, you have to put the database in backup mode or take it offline. Either action breaks the link between the systems, and bringing them back into synchronization is difficult. You cannot perform any testing or training on this system without breaking the link. This method has the same essential failings for off-host operations as the first two. You cannot both maintain replication integrity with the primary system and allow full access to the replicated data. Once you take the systems out of synch, the process of resynching the primary and secondary systems is difficult and degrades production performance. The VERITAS Database Replication Option for Oracle With the Database Replication Option for Oracle, VERITAS Software provides another alternative for creating replicated systems for off-host processing. The Database Replication Option provides a solution that meets the requirements for off-host processing systems, including: Limited impact on the production system Simplified management - it is easy to disconnect and resynchronize the systems Use of commodity hardware Most importantly, the VERITAS Database Replication Option answers the essential challenge of providing access to the replicated data and simplifying the process of resynching the data, with limited impact on the performance system. It does this by integrating key technology from the VERITAS Database Edition for Oracle, which includes Storage Checkpoint technology and a cached Quick I/O technology for writing database storage to the VERITAS File System. The Database Replication Option interfaces and integrates with this technology and adds a replication management interface for managing the replication and synchronization involved in off-host processing. The Database Replication Option takes a file-system based approach to managing replication. It tracks the changed file system blocks (using a Block Level Incremental Backup feature) on the production backup and writes them to the replicated system at scheduled intervals. And it allows data updates and changes on the replicated system because a unique Storage Checkpoint technology provides a quick way to back out changed data. These two features are key to the VERITAS replication solution, and as such deserve a bit more explanation. Block Level Incremental Backups (BLIBs) A block-level incremental backup only writes the database blocks that have changed since the last backup. Block level incremental backups are extremely fast, and have a limited impact on the production system. Storage Checkpoints A Storage Checkpoint is a disk- and I/O-efficient technology for taking snapshot images of mounted file systems. It is part of the VERITAS Database Edition for Oracle, and is made possible through integration with the VERITAS File System. A Storage Checkpoint tracks the blocks that have changed in the database since the last checkpoint, creating a persistent, disk-based image. The Edition can then roll back the file system to a previous state by restoring only the changed blocks. VERITAS Database Replication Oracle Open World 6

7 The Database Replication Option for Oracle combines these technologies to create a solution for replicated, off-host processing that both allows access to the replicated data and resynchronizes quickly and easily. The Database Replication Option uses block-level incremental backups to replicate data at scheduled intervals between systems, with minimal performance impact on the production system. This solves the problem of replicating production data on the source system. Although this does not achieve the up-to-the-second accuracy required for a hot backup server, replications can be scheduled frequently enough for almost any off-host processing need. It uses Storage Checkpoints on the replicated system to roll the system back to the last synchronization point after any off-host processing makes changes. At this point, another BLIB brings it current with the production system. The Database Replication Option provides predefined commands for managing the replication, including initializing the replicated database, replicating or restoring changes, and maintaining storage checkpoints. The solution is best understood by going through an example. Off-Host Processing with the VERITAS Database Replication Option For the purposes of this example, the production system will be called the primary system, and the replicated system is the secondary system. We are assuming that there is only one replicated system. Both system are running Sun SPARC systems running Sun Solaris or 2.6, and Oracle or 8. No special storage hardware is required; any commodity disks otherwise appropriate for the production system will work. Requirements Primary system storage The primary system s storage and configuration requirements are determined mainly by the database application s requirements, but also include the following: The database must reside on the VERITAS File system (VxFS 3.3), which is part of the Database Edition for Oracle product. Although in general database administrators prefer raw devices instead of file systems for database storage, the VERITAS Database Edition for Oracle includes a Quick I/O feature that makes VERITAS File system storage as fast and reliable as raw partition storage. This configuration is fully supported by Oracle Corporation and is described in more detail in the paper Reducing Downtime and Improving Performance with Oracle-Specific Storage Software The Database Replication Option requires a small percentage of additional storage for tracking changed blocks. A good rule of thumb is to allocate an additional 10% of the amount of storage in the replicated file systems. The Network interface A private network between the two machines guarantees the best performance. Although most synchronization using block level incremental backups will be relatively small, a 100baseT interface provides the best performance. This is particularly useful when you have to move a good deal of data over the network, such as initializing new tablespaces. Secondary system storage The secondary system storage requirements depend on the total size of the replicated data, the amount of anticipated write operations on the secondary system (for off-host processing needs), and the largest individual file size in the data set. The secondary system must have enough storage for a complete second copy of the primary data. VERITAS Database Replication Oracle Open World 7

8 It must have extra space allocated for all write I/O operations that take place on the secondary data, as this data is written to newly allocated blocks instead of replacing original contents. If the secondary system is used solely for backup purposes, then this additional storage is small and should not exceed 10% of the total replicated data size. Setting up the Replicated System After installing and configuring the Database Replication Option on both systems, a DBA uses the orarep_init command to initialize the replicated system. This performs a full backup of the primary database and restores it to the secondary database. Next the DBA schedules regular synchronization between the systems (using the block level incremental replication). During these operations, only the changed data blocks are copied from the primary system and written to the secondary system. Running in this state, the secondary database reflects the primary database as of the last synchronization. Performing Off-Host Processing The Database Replication Option has a unique solution to providing access to the replicated data. When ready to perform off-host processing, the DBA: 1. Performs a storage checkpoint on the secondary system; this records its current replicated state. 2. Performs whatever off-host processing needed, including backups, reporting, testing, training, etc. 3. Uses the Replication Edition to roll back the secondary system to its initial state before the processing (the state represented in step 1). 4. If some time has elapsed, the DBA can replicate changes once more from the production system. Otherwise, the secondary system will be updated on its typical schedule. Summary The VERITAS Database Replication Option for Oracle provides a unique solution to the problem of maintaining high availability and performance by supporting off-host processing for critical maintenance and production operations. The Database Replication Option leverages the combined strengths of the VERITAS Database Edition for Oracle to create a manageable software solution to a difficult problem. Instead of requiring specialized hardware, the VERITAS Solution applies the intelligence in the software, letting you use available commodity storage to support the off-host processing. The VERITAS Database Replication Option improves the manageability, performance and availability of critical applications running on the Oracle database platform. VERITAS Database Replication Oracle Open World 8