Announcing Globally Distributed Autonomous Database Support for Oracle Database 23ai Enabling Raft Replication

Over the last four years, the Oracle Database Development team has diligently worked to deliver the next long-term support release: Oracle Database 23ai, with a focus on AI and enhancing developer productivity.

Today, we are thrilled to announce support for Oracle Database 23ai on the Oracle Globally Distributed Autonomous Database!. Oracle Database 23ai, in conjunction with the Oracle Globally Distributed Autonomous Database, is a game-changer for enterprises worldwide seeking to build cloud-scale distributed databases with ultra-high scalability, availability, and advanced AI capabilities.

With the latest release, Oracle Globally Distributed Autonomous Database allows customers to select their preferred replication strategy to ensure high availability and disaster recovery. You can choose between the new built-in Raft replication (introduced in 23ai) and Oracle Data Guard (available in releases 19c and 23ai). The service automatically deploys the specified replication topology to the configured systems and enables seamless data replication. If you are used to NoSQL databases and do not expect to know anything about how replication works, Globally Distributed Autonomous Database built-in Raft replication just works.

Key benefits for Raft replication include:

Fast failover with zero data loss: Raft replication is built into Globally Distributed Autonomous Database to provide a consensus-based, high-performance, low-overhead availability solution, with distributed replicas and fast failover with zero data loss, while automatically maintaining the replication factor if shards fail.

Active-Active symmetric configuration: Each node accepts writes and reads for a subset of data facilitating an Active-Active symmetric distributed database architecture that enhances availability, and optimizes resource utilization globally.

Simplified management: Raft replication is integrated and transparent to applications without requiring configuration of Oracle GoldenGate or Oracle Data Guard. Raft replication automatically reconfigures replication in case of shard host failures or when shards are added or removed from the sharded database.

Automatic data distribution: The service handles workload distribution and balancing upon scaling (addition or removal of shards), including planned or unplanned changes in shard availability. 

By supporting Oracle Database release 23ai, Globally Distributed Autonomous Database offers customers enhanced replication options and advanced AI capabilities including Select AI and AI Vector Search. It provides all of the new benefits on top of 23ai including unparalleled flexibility, improved operational efficiency, enhanced performance, simplified scalability, and compliance for modern applications. Stay tuned for more updates and detailed guides on leveraging these new capabilities to maximize your database’s potential.

Source: oracle.com

Continue reading

Disaster Recovery for the Oracle Autonomous JSON Database

Backup-Based Disaster Recovery is a low-cost DR option for databases with higher RTO tolerance.

As Autonomous Data Guard is currently not supported for Autonomous JSON Database workloads, the natural questions is what are the alternatives:

Option 1. The backup-based Disaster Recovery solution is one alternative. Backup-based DR uses database backups to instantiate a peer database at the time of switchover or failover. This enables you to have a lower cost and higher Recovery Time Objective (RTO) disaster recovery option for your Autonomous Database, as compared with Autonomous Data Guard.

Disaster recovery for AJD provides a peer database instance in a different availability domain (or different Exadata if there is only 1 AD in the region) or in a different region around the world. With a peer database, if the primary database becomes unavailable, disaster recovery switches to role of the peer database to primary and begins recreating a new peer database. For backup-based disaster recovery with a cross-region peer, backups are copied to the remote region. 

For local backup-based disaster recovery, existing local backups are utilized. You can edit the automatic backup retention period and the long-term backup schedule. Check that the backup state is “Active” and when last automatic backup went through. Your local peer will be in a different Availability Domain (AD) than the primary database in regions with multiple ADs, or a different Exadata machine in regions with only one AD.

There is no additional cost for local Backup-Based Disaster Recovery! And AJD already takes local backups automatically for you, so there is no additional cost to enable a local backup copy.

Backup-Based Disaster Recovery RTO and RPO numbers are:

Backup-Based Disaster Recovery Configuration	RTO	RPO
Local backup copy	one (1) hour + 1 hour per 5 TB	10 seconds
Cross-region (remote) backup copy	one (1) hour + 1 hour per 5 TB	1 min

When you have a local peer and the switchover is not successful, the Oracle Cloud Infrastructure console shows a banner with information about why the switchover was not successful and the Oracle Cloud Infrastructure console shows a failover link in the Role field that you can click to initiate a failover to the local peer. The failover link only shows when the Primary database is unavailable and a peer is available. That is, the Primary database Lifecycle State field shows Unavailable and the local peer is available.

You may have also one additional backup copy, in another region. Here is one I added to the Swiss region:

I also enabled cross region backup replication from Germany to Switzerland. Check the 2 informational boxes below (cost and replication of backups):

By default, automatic backups are created and maintained at the current Primary database and are not replicated to a cross-region peer. Optionally, you can enable replication of the automatic backups to the cross region peer (as I have done above). A cross-region Backup-Based Disaster Recovery peer can be converted to a snapshot standby. This converts the peer to a read-write database for up to two days.

Note that Backup-Based Disaster Recovery is not available with Always Free Autonomous Database.

Option 2. For having a copy of the Autonomous JSON Database in a different region (and not just in another AD), an option to consider is Refreshable Clones.

When you create a refreshable clone for an Autonomous Database instance the system clones the source database to the refreshable clone. After you create a refreshable clone you can refresh the clone with changes from the source database.

As you can see my refreshable clone is in Switzerland (while the source JSON Database is in Germany):

When you disconnect a refreshable clone the refreshable clone is disassociated from the source database. This converts the database from a refreshable clone to a regular database. Following the disconnect operation you are allowed to reconnect the disconnected database to the source database. The reconnect operation is limited to a 24 hour period.

Refreshable clones are billed based on their base ECPU count and any additional ECPU usage if compute auto scaling is enabled; they do not get billed additionally for the ECPUs of the source database. A refreshable clone in a different region than its source database is billed for twice the amount of storage that the source database is billed for.

You can check the main features of refreshable clones but it is most important to know that refreshable clones have a one week refresh age limit. If you do not perform a refresh within a week, then the refreshable clone is no longer refreshable. After a refreshable clone passes the refresh time limit, you can use the instance as a read only database or you can disconnect from the source to make the database a read/write (standard) database.

Note the important limitations on refreshable clones but these are the main ones:

• Always Free Autonomous Databases do not support refreshable clones
• You cannot create a cascading series of refreshable clones
• You cannot backup or restore a refreshable clone

For the Oracle Autonomous JSON Database, note the following when reconnecting to the source database:

• If, after you disconnect the refreshable clone, you promote both the clone and the source to Oracle Autonomous Transaction Processing (workload type Transaction Processing), you can reconnect the database to the source.
• If after you disconnect the refreshable clone, you promote the source database to Oracle Autonomous Transaction Processing (workload type Transaction Processing) and do not promote the disconnected clone, the disconnected clone must also be promoted to Oracle Autonomous Transaction Processing (workload type Transaction Processing) before you perform the reconnect operation.
• If after you disconnect the refreshable clone, you promote the disconnected database to Oracle Autonomous Transaction Processing (workload type Transaction Processing), you can still reconnect to the source but the reconnected database remains in the promoted state.

Option 3. Oracle GoldenGate is another way to replicate your data do another region. You can add a replicat for Autonomous JSON Database. It is even possible to use Oracle GoldenGate to replicate MongoDB to AJD, good for use case of migrating out of MongoDB to Oracle.

Source: juliandontcheff.wordpress.com

Continue reading

Oracle Backup & Recovery Technologies - Year in Review

We are looking forward to another exciting year across our technology portfolio, including Recovery Manager (RMAN), Oracle Secure Backup (OSB), Database Backup Cloud Service (DBBCS), Zero Data Loss Recovery Appliance (ZDLRA), and the new ZDLRA-based OCI service, Oracle Database Zero Data Loss Autonomous Recovery Service (ZRCV). Future blogs will highlight new product offerings, best practices, and commentary on industry trends in the backup and recovery market.

Read More: 1Z0-078: Oracle Database 19c: RAC, ASM, and Grid Infrastructure Administration

In looking ahead, it’s always good to spend a little time looking back at highlights of the previous year, demonstrating our innovation and leadership in Oracle data protection and recovery solutions.

Zero Data Loss Recovery Appliance

Marking its 8th year in commercial availability, Recovery Appliance continues to evolve unique database protection capabilities beyond general-purpose backup solutions. These capabilities are centered around: Resilient Recovery, Infrastructure Efficiency and especially visible with customers today: Effectively Defending and Recovering from Ransomware. To that end, the appliance protects transactions in real-time, validates backups for database recoverability, and optimizes backups for fast recovery. These capabilities are a necessity in the face of ransomware attacks which can occur at any time and spread to any number of systems. Recovering all affected systems quickly and to a transactionally-consistent safe point is crucial for data availability and data quality – these are fundamental tenets for which Recovery Appliance was designed, as shown below.

Recovery Appliance End-to-End Ransomware Protection

 

In the latest RA 21.1 software release, new capabilities were introduced to defend against malicious access and tampering.

First, role-based users allow finer-grained provisioning for system access, helping tighten overall security controls in your backup infrastructure:

◉ Named administrator user limited to day-to-day activities via documented management API and Enterprise Manager

◉ Monitor user with read-only / reporting access

◉ Quorum administrator approval to gain system/root privileges. 

Second, new immutability settings prevent the deletion of backups by any internal or external user within a pre-defined retention period. Backups continue to be preserved under the original retention period even if an administrator reduces the setting in an attempt to force the system to purge older backups.

Given the critical nature and impact of ransomware attacks, these capabilities were purposefully designed to meet requirements outlined in SEC 17a-4(f), a key data governance regulation in the banking industry – see the product assessment report for more details on the regulation and relevant capabilities offered by the appliance.

With respect to Recovery Appliance management capabilities, Oracle Enterprise Manager 13.5 was enhanced to support the aforementioned role-based user model and immutability controls, in addition to TLS network encryption, backup & recovery high availability between appliances, and compatibility with REST-enabled management products:

◉ Named Users Management (Administrator, Monitoring User, VPC User)

◉ Administrator API Execution History Monitoring

◉ Immutable (Compliance) Backups

◉ Configuration and Backup to TLS-enabled Appliance

◉ End-to-End Replication Configuration & Management for High Availability

◉ New REST APIs for Common Administrator Operations

Zero Data Loss Autonomous Recovery Service

At CloudWorld 2022, we announced the Oracle Database Zero Data Loss Autonomous Recovery Service. This new fully managed Oracle Cloud Infrastructure (OCI) service is based on Zero Data Loss Recovery Appliance technology and delivers protection capabilities for Oracle Database services running on OCI. The Recovery Service helps organizations meet the business-critical need to reduce ransomware risk, financial requirements for improved operational efficiency, and user expectations for cloud service simplicity.

Zero Data Loss Autonomous Recovery Service Architecture Overview

Oracle Database Backup Service

The Database Backup Cloud Module now supports the use of OCI Object Storage Locked Retention Rules for compliance and ransomware protection. This Retention Rule prevents any deletion or modification of objects in a designated bucket for a pre-defined period of time.

These retention controls were also assessed to meet SEC 17a-4(f), a key regulation for financial services customers – for more information, see the product assessment report.

Oracle Secure Backup

Oracle Secure Backup (OSB) protects file systems as well as Oracle and MySQL Databases to disk, tape and Cloud storage on-premises, in the Cloud, and for hybrid environments. As Cloud deployments become ubiquitous, the product team has been focusing on OCI data protection use cases, including backup of block volumes, VMs, and Oracle Home directories of Exadata Database Service databases. In fact, there are hundreds of customers today protecting their OCI Compute Instances and File Systems with OSB:

◉ 300 Tenancies (Customers)

◉ 6,500 Clients (5000 Linux, 1500 Windows)

◉ 6,500 Full Backups per week

◉ 39,000 Incremental Backups per week

◉ 10 PB stored in OCI Object Storage

◉ 10 Restores per month

OSB recently became available on the OCI Marketplace for fast and easy deployment into an OCI tenancy. In just a few clicks, an OSB Domain Admin Server is set up and ready to use. The deployment includes Ansible PlayBooks to automate the installation of OSB Client Agents on your OCI Compute Instances.

Source: oracle.com

Continue reading