The Cloud Advisor and Cost Saving Opportunities in OCI

If you have a tenancy in OCI, you probably know that the cost can be controlled and managed in most cases by either shutting down the nodes and the databases when not being used (and this can be even automated) but there is more to that.

The main OCI console page contains the basis information about your tenancy (most right): name, usage, subscription number, used/left credits, etc:

In terms of operational availability, I am usually interested in the Frankfurt region where my main tenancy resides:

Under the health dashboard (worth checking on daily basis) there is an “Analyze costs” button which takes you to the “Cost Management” page. It contains links to 4 different sub-pages:

• Cost Analysis
• Cost and Usage Report
• Budget
• Scheduled Reports

You can choose a period, here is what my usage report looks like for the whole month of May 2023:

As you can observe, the graphics are extremely clear, you can see by day what you have paid for and how much. Just below the Cost Graph, you can see the details for the past days:

Cost and usage reports are CSV files generated daily that show usage data for each resource in your tenancy. The CSV files are stored in an object storage bucket that is accessible using a cross-tenancy policy.

The most interesting part is perhaps viewing the recommendations under “Cost saving opportunities”:

There are 3 types/categories of recommendations (see below) and if you need any security recommendations, just view Cloud Guard.

Under “Global recommendations”, you can disable the Cloud Advisor and modify your recommendation profile to customize the logic that Cloud Advisor uses to make recommendations:

The Cloud Advisor is not just easy to use but also the fastest way to manage, control your tenancy from cost savings point of view.

If you might be wondering why on the Recommendations page, the “Estimated savings” column contains no values: I am using the smallest possible configuration and starting the VMs and the databases only when I need them. I have a pretty small tenancy and using only few services.

If interested in all the details, check the Best practices for optimizing the performance and cost of cloud resources!

Here is how cost optimization works in AWS, GCP and Azure – I am also including below a screenshot from my Azure tenancy:

Oracle Full and Basic Database Management in OCI

In a recent Dynatrace study 56% of 1300 CIOs and IT leaders say traditional monitoring approaches must be replaced with a platform that can provide end-to-end observability across multiclouds. 57% said that multiple monitoring solutions make it hard to optimize performance.

For almost 20 years Oracle databases (and not just Oracle) have been monitored mostly using Oracle Enterprise Manager. Things are changing though. With databases being moved to OCI, there is a new option on the horizon: OCI Database Management.

The two OCI database management options are full management and basic management:

For those used to Oracle Enterprise Manager (including me), I must say that the new tool is very much alike OEM and has almost all the features of OEM – new ones being added all the time.

Let me briefly explain the options of using it and how to configure the databases to be part of the Fleet. That is the equivalent of agents in OEM if that would be an appropriate comparison.

Full management: This option includes all Database Management features at an additional service cost. The full management option is available for the Oracle Database Enterprise Editions and the Oracle Database Standard Edition, however, for the Oracle Database Standard Edition, the full management option does not include Performance Hub features and other features such as Alert Logs and AWR Explorer. For information on Database Management feature availability, see Database Management Feature Support Matrix for Oracle Databases.

Basic management: This option is available for Oracle Cloud Databases at no additional cost.

A good starting point is the Oracle documentation on “How to enable Database Management for Oracle Cloud Databases“.

Next, get acquainted with the “Database Management Feature Support Matrix for Oracle Databases“.

The OCI DB management documentation is pretty well written and highly recommended to read through.

Database Management in OCI is not out of the box – it has to be enabled first. Under “Observability & Management” in the OCI console choose “Database Management”. Then click on “Enable Database Management”:

You have to add the databases one by one. Choose your database type from the 3 options: ExaCS, Bare Metal & VM and Autonomous:

Here is an example for a VM database, here I am adding the container database, not a PDB:

The passwords are not typed directly, for each password you will have to create a password secret:

If you do not have a service policy, you will have to create one in order to access the secret:

You will have to check your work requests in order to confirm that the database was added successfully. An explicit error message is not give, as you can see I managed only on the 4th attempt 🙂

You can see under resources both the log message and the error messages:

Note that Oracle announced recently that OCI Database Management for PDBs is supported on DBCS. Meaning, no need any longer to add the PDBs as external DBs to Database Management.

Have a look at this new option to monitor databases. Like 15-20 years ago people were used to HP OpenView, IBM Tivoli and were skeptical towards OEM, now we might be n a similar situation which in my opinion will be over soon.

Last, here is the pricing as of April 2023:

15 important things DBAs need to know about Oracle Zero Downtime Migration (ZDM)

Utopias are common in fiction, from Plato’s “The Republic” in 370 BCE to the Federation in Star Trek. Does zero downtime exist only in power point presentations? Let us find out.

Business services where companies make money or loose money depending on if the systems are up or down respectively are for example: online transactions, online authorizations, online stores, consumer applications or factory applications

SLA of 99.99% means ~52 minutes downtime a year while 99.999% means < 6 minutes downtime a year:

• International Data Corporation (IDC) estimate: the cost of an 11-hour IT outage is approximately one million dollars. Unplanned application downtime costs the Fortune 1000 from $1.25 billion to $2.5 billion every year, according to an IDC report.

• Gartner report: employees experience at least six hours of unplanned downtime per month.

• Large companies, those that have 2,500 users or more, report even higher losses: up to 16 hours of unplanned downtime per month

Put it simply: downtime equals lost revenue:

Many businesses, such as retail, travel, and banking, no longer have the extended downtime windows for planning upgrades and migrations.

Oracle ZDM follows Oracle Maximum Availability Architecture (MAA) principles and incorporates products such as GoldenGate and Data Guard to ensure High Availability and an online migration workflow that leverages technologies such as the Recovery Manager, Data Pump, and Database Links.

Here are (probably) the most important 15 things every DBA should know about ZDM:

1. Latest version of Zero Downtime Migration (ZDM) 21.4 is available for download! 

2. Oracle ZDM supports the following Oracle database versions: 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, 21c.

3. The source and target databases should be in the same database version. This is valid for physical migrations. For logical, it can be different versions, providing in-flight upgrades.

4. Oracle ZDM supports Oracle databases hosted on Linux operating systems. For logical migrations, ZDM also supports AIX and Solaris as a source.

5. The source database can be a single instance database migrating to a single instance or a RAC database, or it can also be a RAC One Node/RAC database, migrating to a RAC database.

6. Oracle ZDM supports Enterprise & Standard Edition Oracle databases as source databases. Enterprise Edition databases are migrated leveraging Oracle Data Guard; Standard Edition databases are migrated in an offline manner using a backup and restore methodology.

7. Oracle ZDM allows for the source database to be a non-CDB or a container database (CDB) with one or more pluggable databases (PDBs).

8. Starting in 21c, ZDM allows for non-CDB to CDB migration with both its physical and logical migration workflows.

9. ZDM supports on-premises databases to be migrated to:

• Oracle Database Cloud Service Bare Metal
• Oracle Database Cloud Service Virtual Machine
• Exadata Cloud Service, Exadata Cloud at Customer, Exadata On-Premises
• Autonomous Database (Logical Workflow only)

10. ZDM Supports the following backup mediums: OCI Object Storage, Oracle Zero Data Loss Recovery Appliance, NFS Storage.

11. Oracle ZDM binaries must be installed on a separate host which fulfils the following requirements:

• Linux host running on Oracle 7
• 100 GB of free storage space

12. The source database must be in archive log mode and if the source database is on 12c Release 2 and later and Transparent Data Encryption is not enabled you must configure the Transparent Data Encryption (TDE) Wallet.

13. The target database must be created prior to the migration, and the target database version should be the same as the source database version.

14. Ensure that both the source database server and the target database server can access the backup medium (Object Store for DBCS BM/VM and ExaCS, Recovery Appliance or NFS Storage for ExaCC).

15. The following port requirements must be met:

• ZDM Service Node: Port 22 must be open, this port is going to be used for SSH, enabling connectivity between the servicenode and the source database server and the service node and the target database server.
• Source Database Server: Port 1521 must be open and not blocked by a firewall, this port will be used for Oracle NET Services connectivity between the source database server and target database server. This connectivity will enable proper Data Guard Synchronization. Port 443 must be open and not blocked by a firewall, this port will be used to access the Object Store.
• Target Database Server: Port 1521 must be open and not blocked by a firewall, this port will be used for Oracle NET Services connectivity between the source database server and target database server. This connectivity will enable proper Data Guard Synchronization. Port 443 must be open and not blocked by a firewall, this port will be used to access the Object Store.

For more information on Oracle Zero Downtime Migration, check the links at the end of this technical brief on ZDM 21.4 or the complete ZDM guide.

Good to know: Oracle GoldenGate for Oracle can be used for 183 days to perform migrations into Oracle databases located in Oracle Cloud Infrastructure using Oracle Zero Downtime Migration. This is valid also for migrations to Exadata Cloud@Customer. In 21.4, we can configure section sizes for RMAN and also upgrade TZ on the target during ZDM post steps.

Note finally the new product names: BaseDB (formerly DBCS), and ExaDB-D (formerly ExaCS).

10 OCI tips for end users and administrators

The OCI console interface is changing rather often and new features are being added on monthly basis. Some features are very intuitive and for some one needs to go to the OCI documentation or MOS (links included below).

Although using the OCI console and dashboard on daily basis, there are still few actions being performed sporadically or just only once.

Here are 10 tips on how to manage certainly not so common operations within OCI:

Tip 1. If you need to change the Tenancy Administrator (Doc ID 2869402.1), you need to do the following 2 things (not possible to do it online via the GUI):

– Submit MOS SR using the Customer Support CSI with the following mandatory information:

Cloud Account (Tenancy) Name:
Current Tenancy Admin : <User name and email>
New/Desired Tenancy Admin : <User name and email>
Order Number and/or Subscription ID:

and

– Approval email from VP/CIO contact, the attachment format must be in email/message format (.msg, .EML, .pdf), not a screenshot.

Tip 2. If you need to increase your limits in OCI (Doc ID 2434814.1), the instructions in the MOS note are not very straightforward, here is how to do it:

• Hit the Help button (the question mark) and then choose “Visit the Support Center”:

• Then click on the blue “Create Support Request” button. From “Limit Increase”, select the category and then the resource:

For example, if you select FastConnect, you have the following options:

Tip 3. If you need to change the bandwidth for FastConnect (Doc ID 2922934.1), you need to complete the following steps:

• Log into the OCI console, select Networking and then FastConnect
• Click Edit to update the provisioned bandwidth value
• Select the provisioned bandwidth value
• Click Save Changes

Note that you have 2 options when selecting the provisioned bandwidth:

The Lifecycle state will be updates to Provisioned once saved.

Here are some additional OCI tips which I find interesting and important:

Tip 4. You might want to to find the private IP Addresses consumption of the OCI LoadBalancer (Doc ID 2850625.1)

Tip 5. How to change default DATA_PUMP_DIR to a new directory at PDB level for a OCI DB system (Doc ID 2630666.1)

Tip 6. How to use Data Pump to import from File Systems Storage in OCI DBCS (Doc ID 2511714.1)

Tip 7. How to provide access roles to users in new unified OCI console (Doc ID 2590671.1)

Tip 8. How to add a new SSH key to an existing DB system instance (Doc ID 2687638.1)

Tip 9. How to Import Custom Images to OCI (Doc ID 2330167.1)

Tip 10. How to change the idle timeout for a network Load Balancer (Doc ID 2921943.1)

Last note: It is not supported by Oracle to change the software edition of a database Cloud instance by say recompiling the binaries. You have to recreate the instance from backup of existing instance and choose appropriate software edition. If you need an edition change option with minimum downtime or need to migrate from single instance to RAC, you can use Zero Downtime Migration Utility.

DBA_OPERATOR_ACCESS and SYSDATE_AT_DBTIMEZONE in ADB-S

In a blog post in 2020, entitled SYSDATE and Time Zones in the Autonomous Database, I covered the sysdate/systimestamp issue in ADB-S. Basically, you are allowed to change the database and session timezones in ADB, but this doesn’t change the SYSDATE and SYSTIMESTAMP in the timezones. So, the PL/SQL packages, procedure and functions and in particular all SQL using SYSDATE and SYSTIMESTAMP might not return what you expect.

But now, there is a parameter called SYSDATE_AT_DBTIMEZONE available now on system level. Depending on the value of SYSDATE_AT_DBTIMEZONE, you see either the date and time based on the default Autonomous Database time zone, Coordinated Universal Time ‎(UTC)‎, or based on the time zone that you set in your database.

Here is how it works. Let us first check the database timezone:

The value of SYSDATE_AT_DBTIMEZONE is the default, FALSE:

With the default value of FALSE, I see GMT time:

If I change from FALSE to TRUE, then I see database TZ time:

If you decide to change the TZ, then you must restart the Autonomous Database instance for the change to take effect.

So, when SYSDATE_AT_DBTIMEZONE is FALSE in a session, calls to SYSDATE and SYSTIMESTAMP return values based on the default Autonomous Database time zone, Coordinated Universal Time ‎(UTC)‎. When SYSDATE_AT_DBTIMEZONE is TRUE in a session, calls to SYSDATE or SYSTIMESTAMP return the date and time based on the database time zone.

In case you need your application to show the database timezone (or a certain TZ) when calling SYSDATE or SYSTIMESTAMP, then change this new parameter to TRUE, set the correct TZ, if needed, and restart!

There is also a new view in ADB-S called DBA_OPERATOR_ACCESS. This view stores information on the actions that OCI cloud operations performs on your Autonomous Database. This view will not show results if Oracle Cloud Infrastructure cloud operations hasn’t performed any actions or run any statements in your Autonomous Database instance.

The DBA_OPERATOR_ACCESS view provides information starting on October 4, 2022, the date this feature was introduced. You cannot see anything done before October 4, 2022.

The view is based on the PDB_SYNC$ table:

The view contains the following 4 columns:

1. SQL_TEXT: SQL text of the statement executed by the operator

2. EVENT_TIMESTAMP: Timestamp of the operator action in UTC

3. REQUEST_ID: Request number related to the reason behind the operator action. This could be a bug number, an SR number, or a change ticket request number that provides information on the reason for the action

4. REASON: Reason for the operator action. This provides context for the reason behind the action and may have a value such as: MITIGATION, DIAGNOSTIC COLLECTION, or CUSTOMER REQUEST

So, the DBA_OPERATOR_ACCESS view provides good and useful information on the top level SQL statements that OCI cloud operations performs.

Viewing cost saving recommendations in OCI

Do not save what is left after spending, but spend what is left after saving – Warren Buffett

Tracking and managing usage and cost in the Cloud in often neglected. Often it is seen as complex and difficult. Here is what we can do in Oracle Cloud Infrastructure. In the most right console screen of OCI, under Account Center, we have now Billing and Cost Management Savings. It shows how many savings have been already implemented and how many are still pending:

Best practices framework for Oracle Cloud Infrastructure describe the possible actions:

• Evaluate the Different Pricing Models
• Implement a Compartment Structure That Fits Your Organization
• Set Up Compartment Quota Policies to Control Resource Usage
• Implement Cost Tracking Tags for Flexible Cost Tracking
• Define Budgets
• Enable Block Volume Performance Auto Tuning
• Implement Object Storage, Object Lifecycle Management
• Leverage Cost Reports
• Track and Optimize Your Spending by Using Cost Analysis
• Implement a Process to Terminate or STOP Unused Resources
• Evaluate What Compute Shape Fits Your Workload
• Become Familiar with Cloud Advisor

If you go under recommendations (under Cloud Advisor), the screen will list all types and you can also filter on a category:

As I have several databases on OCI, both ADB and Database Systems, both Oracle and MySQL, spread among couple of regions, it is rather important for me to manage the cost as I use the databases on daily basis and often do no stop them during the week.

As you can see above, my pending recommendation is about defining lifecycle policy rule which that automatically moves Object Storage data to lower cost tiers when possible. Meaning in practice archive storage.

It is worth going through all recommendation and although some of them are rather obvious, they might not always come to mind to implement.

Viewing Autonomous database usage is straightforward: as you pay only for storage when the database is stopped (charges below are for February):

but for MySQL especially if using HeatWave, the charges are slightly different:

Finally, here are some useful links:

Cloud Advisor Overview

Now available: Oracle Cloud Advisor

10 effective ways to save cost in the cloud: Part 1

10 effective ways to save cost in the cloud: Part 2

Moving Autonomous Databases across regions

With the new OCI regions, we might want to move our databases to a closer location – in my case moving my databases from Frankfurt to Stockholm.

First what comes to mind is to enable Autonomous Data Guard and then switch over. However, you need a paired region – we cannot create a standby database just anywhere:

The list of Autonomous Data Guard Paired Regions shows that for each Source Region, we have 1-4 Paired Regions.

You need to be subscribed to a region before it can appear on the list and use it. And note: once you subscribe, there is no unsubscribe! You will need to apply for a limit increase.

I am told that soon, once a good standing payment history has been established, you will be eligible for unlimited regions. 

Another option is simply to create a clone:

Note that if you are using a clone from a backup, you cannot have the clone in another region, no idea why not! As you can see from the screenshot below, I am not getting a drop down list of regions:

So, let us create the database clone in Stockholm from the current AEG database running in Frankfurt:

Once the database is cloned, you can optionally terminate the copy in Frankfurt. But do not do it before you have verified the new clone as you might get an (unknown) error, something like this:

In case you do not want to deal with support, just create a new database and move the data with Data Pump.

My home region is Germany Central (Frankfurt). So am I able to change now my home region to Sweden Central (Stockholm) instead of Germany Central (Frankfurt)? Alas, this is not possible. Not yet at least.

According to the Metalink document Change Home Region in OCI console (Doc ID 2389905.1), the home region of the tenancy is fixed at creation time and cannot be moved. If you still wish to have the region changed, the only way to get it done would be to re-create the tenancy. That would mean removal of the current tenancy with all its resources and creating a new one.

Having the primary database in one region and a standby database in another is good practice in terms of DR. Even more complex scenarios are available. How about having a sharded Oracle Database spread among OCI, AWS and Azure? Possible but I would avoid such a complexity.

Simple Oracle Document Access (SODA) in the Autonomous JSON Database

“I ordered a soda – caffeine-free, low sodium, no artificial flavors. They brought me a glass of water.” – Robert E. Murray

SODA is a set of NoSQL-style APIs that let you create and store collections of documents in Oracle Database, retrieve them, and query them, without needing to know Structured Query Language (SQL) or how the data in the documents is stored in the database.

Oracle database stores, manages, and indexes JSON documents, and developers can access these via document-oriented APIs in a NoSQL style.

A recent white paper written by Vlad Kamys, Francesc Mas and Sai Penumuru explained how to modernize your applications and increase business resilience and security with JSON on Oracle Database, and new cloud-based Oracle Autonomous JSON Database.

Here are few examples on how to use JSON and SODA in the Oracle Autonomous Database.

From the Tools tab, start “Database Actions”, and then select “SQL”:

The following below are typical SODA commands:

(1) list the collections

(2) create the EMP collection

(5), (6) and (7) insert three JSON documents into the collection

(10) gets all documents where the name is “Francesc”

(11) gets all documents where the salary is greater than 300

(12) gets all documents where the jobs starts with “D”

(13) gets all documents where the jobs contains the string “play”

Here is the output from command extracting all documents where the jobs starts with “D”:

If we do not have a text index on “job”, then we get an ORA-40467:

We can also run standard SQL on the EMP table which gets created as a result of creating the collection:

Here is how to get the output from EMP by using JSON_VALUE:

You can think of SODA as a programming bridge between the NoSQL model and the relational model.

There is also the DBMS_SODA package in the database. You can drop the EMP collection simply with “soda drop emp” but you can also run select DBMS_SODA.DROP_COLLECTION(’emp’) from dual; The function will return 1 when it succeeds and 0 when it fails.

Work with JSON Documents in Autonomous Database provides examples of how Java code opens a SODA collection of cart documents, how to use SQL with a SODA collection, etc.

Finally, there is JSON DB/SODA DB Health-Check Script that is a tool developed by Oracle Support Services. The tool, also known as jsonsodadb_hc, is used to check the environment in which a single SQL statement runs, checking for the current status of JSON DB and SODA DB components, makes recommendations based on current settings and checks if the components are being used.

Session settings and timeouts in OCI

The following question in the Oracle Groundbreakers Developer Community forum made me investigate on how to change the session timeout in the Oracle Cloud console. Have a look, it is still for some reason unanswered:

For those who use Oracle Cloud Infrastructure on daily basis, they know that the default session timeout is 480 minutes although in my case it is an hour – so often after you switch to the OCI tab, you see the following screen:

Here is the way how you can change it to a longer period with 32767 minutes being the maximum allowed.

Step 1: Open the Service User Console

Step 2: Open the Identity Cloud Service Admin Console:

Step 3: From the Dashboard, choose “Settings” and from there “Session Settings”:

Step 4: Set the “Session Duration” to a longer period of time:

Step 5: Saving the settings to the new value: I chose the maximum which is 32767 minutes:

Here are some additional resources:

Administering Oracle Identity Cloud Service

How to Change the Default Session Timeout Value for IDCS (Oracle Identity Cloud Service) in a P6 Cloud Environment (Doc ID 2812372.1)

Note that there are other setting besides session session: user settings, default settings and partner settings.

You can try also the Console Settings (thanks to Simo Vilmunen) but there I am getting a show stopper:

SQL Trace and X-ADG in the Oracle Autonomous Database

Two very different in nature but equality useful features are now available in the Oracle Autonomous Database:

1. SQL Tracing in Autonomous Database
2. Cross-Region Autonomous Data Guard in ADB-S

Here is how to enable and use them:

SQL Trace in ADB:

You need first a standard bucket as SQL tracing files are only supported with buckets created in the standard storage tier. Also, create a token (you can have at most 2 tokens) and do not use your OCI password when creating the credentials.

Next, you have to create a credential for your Cloud Object Storage account. Note the full username below – do not simply use the one with what you login to the console.

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'JULIANDON_CREDENTIAL',
    username => 'oracleidentitycloudservice/juliandon@yahoo.com', 
    password => 'generated_token'
);
END;
/

PL/SQL procedure successfully completed.

Afterwards, set the init.ora parameters DEFAULT_LOGGING_BUCKET to specify the Cloud Object Storage URL for a bucket for SQL trace files:

SET DEFINE OFF;
ALTER DATABASE PROPERTY SET 
   DEFAULT_LOGGING_BUCKET = 'https://objectstorage.eu-frankfurt-1.oraclecloud.com/n/juliandon/b/adbkofa/o/';

Database altered.

Next, specify the credentials to access the Cloud Object Storage. Note that although I am doing this as the ADMIN user, I still have to prefix the credential with ADMIN. Otherwise, you get an error message.

ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'ADMIN.JULIANDON_CREDENTIAL';

Database altered.

Before we can enable SQL trace, we configure the database to save SQL Trace files:

exec DBMS_SESSION.SET_IDENTIFIER('sqltrace_jd');

PL/SQL procedure successfully completed.

exec DBMS_APPLICATION_INFO.SET_MODULE('module_jmd', null);

PL/SQL procedure successfully completed.

ALTER SESSION SET SQL_TRACE = TRUE;

After running the SQLs, disable SQL tracing so that the collected data for the session is written to a table in your session and to a trace file in the bucket you configured when you set up SQL trace.

ALTER SESSION SET SQL_TRACE = FALSE;
ALTER DATABASE PROPERTY SET DEFAULT_LOGGING_BUCKET = '';

The SQL Trace facility writes the trace data collected in the session to Cloud Object Store in the following format:

default_logging_bucket/sqltrace/clientID/moduleName/sqltrace_numID1_numID2.trc

When you enable SQL Tracing, the same trace information that is saved to the trace file on Cloud Object Store is available in the SESSION_CLOUD_TRACE view in the session where the tracing was enabled.

SELECT trace FROM SESSION_CLOUD_TRACE ORDER BY row_number;

After you close the session, the data is no longer available in SESSION_CLOUD_TRACE.

DESC SESSION_CLOUD_TRACE

Name       Null? Type
---------- ----- ------------------------------
ROW_NUMBER       NUMBER
TRACE            VARCHAR2(32767)

Check Connor McDonald’s blog entitled SQL trace on your cloud database.

Cross-Region Autonomous Data Guard in ADB-S

Autonomous Data Guard provides a standby database instance in a different availability domain in the same region or in a standby database instance in different region.

If you create the standby database in the current/local region and if the primary instance becomes unavailable – the Autonomous Database automatically switches the role of the standby database to primary and begins recreating a new standby database.

ADB currently supports up to 2 standby databases – a local one in the same-region and an additional one which is remote – called cross-region.

So, with the new cross-region standby database, you can perform a manual failover to the standby database if the current region goes down.

A detailed blog by Nilay Panchal entitled Cross-Region Autonomous Data Guard – Your complete Autonomous Database disaster recovery solution! covers in detail how to create the remote standby database and how to manually switch over.

Note that each region has one or a few nearby paired regions in which a remote standby may be created. As you can see from the screenshot above my tenancy in Frankfurt is subscribed to 3 remote regions in which I can create a remote standby.

It is important to know that ADB-S does not allow us access to the standby databases but after a switchover or failover, the database wallet downloaded in the primary database region can be used in the remote region.

It is extremely simple to manually switchover to the other region – in my case from Frankfurt to Zurich, just with a click of a button:

Simple and elegant!