We have had a multitude of blog posts on different topics recently and I wanted to circle back to Maximum Availability Architecture (MAA) specifically. Awhile back, we discussed the various MAA tiers and looked at each from a high level perspective. Taking the next step in that discussion, it would make sense to take a deeper look at each of the tiers including why each might be appropriate to a specific application, the underlying High Availability (HA) and Disaster Recovery (DR) technologies that provide the foundation of each tier as well as some best practices and strategies around the solution. Let’s start our MAA tier blog series with the Bronze MAA tier which provides the foundation for the other tiers!
In some cases such as development, test, or non-critical systems that may run a single instance of the Oracle Database, an extended Recovery Time Objective (RTO) for both planned and unplanned outages may be acceptable as long as recovery is possible within a specified time frame. For example, the acceptable time frame of recovery for an unplanned data corruption event may be an hour or even a few hours of downtime in cases where a human mistake occurs corrupting the underlying data as long as the capability to return data to a previous state that meets the Recovery Point Objective (RPO) in an acceptable time period is available. The HA and DR requirements for the Bronze MAA tier are outlined at a high-level in the chart and table below:
Now that we understand the basic fundamentals of the Bronze Tier and why it might a good fit for specific applications, let’s look at a subset of the key HA technologies and solutions including RMAN, Multitenant, Flashback, and Online Operations that when setup and configured properly will help us meet the objectives above.
Backup and Recovery
In addition to prevention and recovery technologies, every IT organization must implement a complete data backup procedure to respond to multiple failure scenarios. Oracle provides Oracle-aware tools to efficiently backup and restore data, and to recover data up to the time just before a failure occurred. Oracle supports backups to disk, to tape, and to cloud storage. This wide range of backup and recovery options allows users to deploy the best solution for their particular environment. The following sections discuss Oracle’s disk, tape, and cloud backup technologies.
Oracle Recovery Manager (RMAN)
Recovery Manager (RMAN) manages database backup, restore, and recovery processes. RMAN maintains configurable backup and recovery policies and keeps historical records of all database backup and recovery activities. Large databases can include hundreds of files, making backup very challenging without an Oracle-aware solution. Missing even one critical file can render the entire database backup useless, and incomplete backups may go undetected until needed in an emergency. RMAN ensures that all files required to successfully restore and recover a database are included in database backups. During the backup and restore processes, RMAN validates all data to ensure detection of data corruptions so you can address them early in the process. If corrupt blocks are found during a restore operation, RMAN automatically relies on file(s) from a previous backup as necessary for a successful recovery.
Fast Recovery Area
A key component of Oracle Database backup strategy is the Fast Recovery Area (FRA), a location on a file system or ASM disk group for all recovery-related files and activities for an Oracle Database. All the files required to recover a database from media failure can reside in the FRA, including control files, archived logs, data file copies, and RMAN backups. Oracle automatically and intelligently manages space in the FRA ensuring that files are not deleted that are required for local recovery based on retention requirements. A single FRA location may be shared by one or more databases.
Oracle Database Backup Cloud Service
Oracle Database Backup Cloud Service is a low cost offsite storage backup solution for storing backups in the Oracle Cloud. This service securely backs up Oracle Databases that are deployed on-premises or in the Oracle Cloud using RMAN to the cloud. The data is encrypted and securely transmitted over HTTPS/SSL. Backup data is then stored in multiple copies in the cloud for high availability and can be accessed anytime for restore and validation. The encryption keys are kept with the customer. The data can be optionally replicated to another cloud data center for disaster recovery. The backup data can be used to instantiate database instances in the cloud using UI for test/dev or DR purposes.
Zero Data Loss Recovery Appliance
Before moving on to other technologies, I think it is important to mention the option of using the Zero Data Loss Recovery Appliance (ZDLRA) as well within the Bronze MAA tier. ZDLRA is an innovative data protection solution that is completely integrated with RMAN and the Oracle Database. It prevents data loss exposure and dramatically reduces data protection overhead on production servers across the enterprise. The Recovery Appliance easily protects all databases in the data center with a cloud-scale architecture, ensures end-to-end data validation, and fully automates the management of the entire data protection lifecycle for all Oracle Databases via the unified Enterprise Manager Cloud Control interface as shown in the diagram below.
The Recovery Appliance is an optional integrated hardware and software appliance that includes substantial technical innovation that standardizes backup and recovery processes for Oracle Databases across the entire data center. The appliance offers the following unique advantages.
◉ Eliminates or Minimizes Data Loss.
◉ Minimal Impact Backups by offloading reduplication, compression, recovery + merge, and validation to Recovery Appliance.
◉ Database Level Recoverability and Validation.
◉ Cloud-scale and Data Center wide Data Protection for all backups.
Recovery from Logical Corruption: Oracle Flashback Technology
Human errors happen, it is the way of the world. Oracle Database Flashback Technologies provide a unique and rich set of data recovery solutions that enable reversing human errors by selectively and efficiently undoing the effects of a mistake. Before Flashback, it might take minutes to damage a database but hours to recover. With Flashback, the time required to recover from an error depends on the work done since the error occurred. Recovery time does not depend on the database size, a capability unique to the Oracle Database that becomes a necessity as database sizes continue to grow. Flashback supports recovery at all levels including the row, transaction, table, and the entire database.
Flashback is easy to use: the entire database can be recovered with a single short command instead of following a complex procedure. It also provides fine-grained analysis and repair for localized damage, e.g., when the wrong customer order is deleted. In addition, Flashback can repair more widespread damage while still avoiding the need for long periods of downtime, e.g., all of yesterday’s customer orders have been deleted.
For example, when logical corruption is limited to one or a set of tables, Flashback Table allows the administrator to easily recover the affected tables to a specific point-in-time. A query such as:
FLASHBACK TABLE orders, order_items TIMESTAMP time in timestamp format;
This will undo any updates to the orders and order_items tables made after the specified time.
To restore an entire database to a previous point-in-time, the traditional method is to restore the database from a RMAN backup and recover to the point-in-time prior to the error. This can take time proportional to the (ever growing) size of the database resulting in hours or even days of recovery time using traditional methods.
In contrast, Flashback Database, using flashback logs, can quickly restore an entire database to a specific point-in-time without the need for prolonged recovery time. Flashback Database is fast because it restores changed blocks only.
Oracle Multitenant Architecture
As of the Oracle Database 12c release, the concept of multitenant architecture was introduced as part of the Oracle Database allowing for Container-managed database virtualization. This architecture provides in-database virtualization that segregates Oracle data/metadata from user data/metadata by horizontally partitioning the data dictionary. Aggregating pluggable databases (PDBs) in a Container Database (CDB) where these databases can be “managed as one” via common operations, such as backups, patching or upgrades. Though, when appropriate, most of these operations can still be executed at the individual PDB level.
By using self-contained PDBs for each application, the following benefits are gained:
◉ Portability (via pluggability)
◉ Rapid provisioning (via clones)
◉ Consolidation for common operations
◉ PDB upgrades via plug/unplug
Online Data Reorganization and Redefinition
Online data and schema reorganization improves overall database availability and reduces planned downtime by allowing users full access to the database throughout the reorganization process. For example, adding columns with a default value has no effect on database availability or performance. Many data definition language (DDL) maintenance operations allow administrators to specify timeouts on lock waits in order to maintain a highly available environment while performing maintenance operations and schema upgrades. Also, indexes can be created with the INVISIBLE attribute so the Optimizer ignores them although they are still maintained by DML operations. Once an index is ready for production, a simple ALTER INDEX statement will make it visible to the Optimizer.
Online Table Redefinition
As business requirements evolve, the applications and databases supporting the business go through a similar evolution process. Through the strategic use of the DBMS_REDEFINITION package (also available in Oracle Enterprise Manager) – administrators can reduce downtime during database maintenance by allowing changes to a table structure while continuing to support an online production system. Administrators using this API enable end users to access the original table, including insert/update/delete operations, while the maintenance process modifies an interim copy of the table. The interim table is routinely synchronized with the original table and once the maintenance procedures are complete, the administrator performs the final synchronization and activates the newly structured table. Over multiple Oracle Database releases, Online Table Redefinition has evolved including many significant enhancements which can be seen in the table below:
Posts
0 comments:
Post a Comment