You can use Oracle Database Autonomous Recovery Service as the backup destination for Oracle Cloud databases provisioned with the following Oracle Database releases.
Oracle Database Edition and Version | More Information |
---|---|
Oracle Database 19c Release 16 (19.16) or later |
To use the Real-time data protection feature, your database must be provisioned with: Oracle Database 19c Release 18 (19.18) or later |
Oracle Database 21c Release 7 (21.7) or later |
To use the Real-time data protection feature, your database must be provisioned with: Oracle Database 21c Release 8 (21.8) or later |
Oracle Database 23ai |
To use the Real-time data protection feature, your database must be provisioned with: Oracle Database 23ai Release 4 (23.4) or later |
Your COMPATIBLE parameter needs to be set to 19.0.0 or above in order to use the Autonomous Recovery Service. This parameter is typically not updated during the upgrade process, so it is important to ensure that it is set to a high enough value.
Below is the type of mesage you will see if it is not set correctly.
Before implementing the Recovery Service, you first must see what the resource settings are in your tenancy. You want to make sure that the "Space Used for Recovery Window (GB)" and "Protected Database Count" allow for the number of databases, and backup size of the databases you want to utilize the service for.
Below is what you would see for the Recovery Service. This is a screen shot from my free tenancy. In your tenancy you should see what the current limits are. When looking at the root compartment, this will show you the Limits and usage for the whole tenancy.
If you need to increase the limits for your tenancy click on the 3 dots to the right of the limit you want to increase. It will bring up a choice to "Open Support Request". After choosing "Open Support Request" you will see a window that allows you to request a limit increase for your tenancy.
NOTE: There is a second choice when clicking on the 3 dots to "Create Quota Policy Stub". Using the stub displayed you can limit the quota of specific compartments. This can be used to limit the usage for your "dev" compartment for example, ensuring there is space within your limits for production
Policy Statement | Purpose |
---|---|
Allow service database to manage recovery-service-family in tenancy |
Enables the OCI Database Service to access protected databases, protection policies, and Recovery Service subnets within your tenancy. |
Allow service database to manage tagnamespace in tenancy |
Enables the OCI Database Service to access the tag namespace in a tenancy. |
Allow service rcs to manage recovery-service-family in tenancy |
Enables Recovery Service to access and manage protected databases, Recovery Service subnets, and protection policies within your tenancy. |
Allow service rcs to manage virtual-network-family in tenancy |
Enables Recovery Service to access and manage the private subnet in each database VCN within your tenancy. The private subnet defines the network path for backups between a database and Recovery Service. |
Allow group admin to manage recovery-service-family in tenancy |
Enables users in a specified group to access all Recovery Service resources. Users belonging to the specified group can manage protected databases, protection policies, and Recovery Service subnets. |
Policy Statement | Create In | Purpose |
---|---|---|
Allow group '{identity domain}'/'{group name}' to manage recovery-service-policy in compartment {location} |
Compartment that owns the protection policies. | Enables all users in a specified group to create, update, and delete protection policies in Recovery Service. |
Policy Statement | Create In | Purpose |
---|---|---|
Allow Group '{identity domain}'/'{group name}' to manage recovery-service-subnet in compartment {location} |
Compartment that owns the Recovery Service subnets. | Enables all users in a specified group to create, update, and delete Recovery Service subnets. |
Create and assign this policy for Oracle Databases that run in Microsoft Azure environment to access Recovery Service. ORACLEDBATAZURE
indicates the service name for Oracle Database@Azure.
<em> Allow service database to use organizations-assigned-subscription in tenancy where target.subscription.serviceName = 'ORACLEDBATAZURE'</em>
Alternatively, use this policy to assign the permissions for a specific subscription ID linked with Microsoft Azure. SubscriptionId
is the placeholder for the specific service subscription ID.
<em> Allow service database to use organizations-assigned-subscription in tenancy where target.subscription.id = '<<kbd>SubscriptionId</kbd>>'</em>
The Recovery Service uses Private endpoints to control backup traffic between your database and the recovery service. Below is the architecture.
Each Recovery service subnet needs to be created within the VNC where your database resides.
The minimum size of the subnet is /24 (256 IP addresses). You can create a new subnet, or use an preexisting subnet in you database VCN. This subnet must be IPv4.
Security rules (implemented through Security Lists, or Network Security Groups) for the private subnet must include stateful ingress rules to allow destination ports 8005 and 2484.
NOTE: You can use a public subnet, but it is not recommended for security reasons.
This private subnet must be registered as a Recovery Service Subnet.
NOTE: If your VCN restricts network traffic between subnets, ensure to add an egress rule for ports 2484, and 8005 from the database subnet to the Recovery Service subnet that you create.
Under Oracle Database --> Database Backups you need to click on "Recovery Service Subnets" and register the Recovery Service Subnet.
The Recovery Service Subnet that you registered needs to communicate with the Recovery Service. In order to access the service, the routing table for this subnets needs to include "All IAD Services In Oracle Services Network".
When using the Autonomous Recovery Service, you must have your database fully TDE encrypted. For new databases that are born in the cloud, this should already be done. But if you creating a stub database in OCI and migrating a database to an Oracle Database Service from on-premises, or somewhere else, you might not meet all the criteria. For these databases you should verify that you meet the prerequisites for a backing up to the recovery service. I have a blog post you can find here that will outline what to check for with queries to execute.
From a high level you should meet these 3 criteria.
dbaascli tde enableWalletRoot - enable wallet_root spfile parameter for existing database.
<tt> Usage: dbaascli tde enableWalletRoot --dbname <value> [--dbRestart <value>] [--precheckOnly]
Where:
--dbname - Oracle database name.
[--dbRestart - database restart option. Valid values : full|rolling ]
[ --precheckOnly - run the prerequisite checks and report the results. ]
[--resume - to resume the previous operation]
<big><strong> NOTE: In order for this change to take effect you need to have a restart of the database.
The default is a rolling bounce of the database.
</strong></big></tt>
In some cases, OCI users are executing manual operationational backups. These are backups which are run outside the tooling and support a point-in-time recovery (non-KEEP backups).
If you are running any of these types of operational backups, it is critical that you turn them off at this point. Executing operational backups to two different locations can cause issues with both backups.
NOTE: if you are using the tooling for object storage backups, and switch to the Recovery Service, the switchover will be automated by the tooling, and all of the previous backups will remain available.
Check your release version and availablility for the Recovery Service
Check the COMPATIBLE inititialization parameter
1. Open the SR for the database service you are using
- Oracle Cloud Infrastructure -Exadata Cloud Service
Problem type should be Patching issues & Tools --> Cloud Tools
- Oracle Database Cloud Service
Problem type should be DBCS Tools --> Using Cloud Toolset
- Autonomous Database Dedicated
Problem type should be Database Administration --> Backup and Recovery
2. Include the following information when opening up the SR.
Bryan Grenn works as a specialist in the North America Engineered Systems sales organization.The organization’s mission is to provide unparalleled expertise to enhance the customer experience with simple, comprehensive and complete architectural solutions that are tailored to their needs.
Previous Post