Data guard provision in OCI db system in Base Database Service
Oracle Data Guard on OCI Base Database System provides high availability and disaster recovery by creating a synchronized, standby replica of your database, supporting both same-region and cross-region configurations.
It is enabled via the OCI Console under "Data Guard Associations" on the database details page, automating backend configuration like broker setup, log parameters, and network, requiring Enterprise Edition
For Base DB Systems, the managed Data Guard feature supports only a single Data Guard association (one standby database) per primary. Adding a second standby in another region from the Console or API is not supported.Multiple Data Guard associations per primary are not supported for Base DB Systems;
you can have only one standby
if you want to create multiple standby database , you need to create manually by
creating a new DB System in the target region from backups (irestore).
This provides an additional copy but is not a Data Guard standby.
this will not be managed by Data Guard
A cross-region Data Guard association cannot be created between databases of DB systems that belong to VCNs that are not peers . VCN must be peer
Key Aspects of Data Guard on Base Database Service
--------------------------------------------------------------
Provisioning Process: Navigate to the Database Details page, select "Data Guard Associations," click "Enable Data Guard," and create a new peer DB system for the standby.
Configuration Options: Options include Data Guard (physical standby) or Active Data Guard (adds read-only/reporting capability).
Protection Modes: Choices include Maximum Availability, Maximum Performance, or Maximum Protection.
Supported Configurations: Supports single-instance to single-instance, or 2-node RAC to 2-node RAC, including across different regions.
Management: Once created, you can perform switchovers or failovers from the same Data Guard Association menu.
Licensing: Active Data Guard requires a separate license
Please refer below doc
https://docs.oracle.com/en/cloud/paas/base-database/dg-enable/index.html
Prerequisite
1) Ensure Object Storage connectivity for the DB System subnet
- Recommended (private subnets):
- Create a Service Gateway in the same VCN and region.
- Update the subnet’s Route Table to add:
- Destination Type: Service
- Service: All Object Storage Services in <your region>
- Target: Your Service Gateway
- Security List or NSG: Add an egress rule allowing TCP port 443 to Destination Type = Service, Service = All Object Storage Services in <your region>.
- Alternative (public subnets or when using NAT):
- If instances have public IPs: Attach an Internet Gateway and a 0.0.0.0/0 route to the Internet Gateway; ensure egress TCP/443 is allowed in Security Lists/NSGs.
- If instances are private without public IPs: Attach a NAT Gateway and a 0.0.0.0/0 route to the NAT Gateway; ensure egress TCP/443 is allowed. (Object Storage via Service Gateway is still preferred.)
Reference for required networking: docs.oracle.com/en-us/iaas/base-database/doc/vcn-and-subnets.html
After termination of previous/failed standby DB system and it is required to cleanup the existing Data Guard configuration on primary as below
1. Check if any DG association is seen from primary. Following should not show any:
sudo su -
cd /opt/oracle/dcs/bin
./dbcli list-dataguardstatus
>>> Note : if no configuration found go to step 2 without executing ' dbcli delete-dataguardstatus'
# export DEVMODE=true
# dbcli delete-dataguardstatus -i <id_from_above_output>
2. Remove Data Guard Broker Configuration
Connect from dgmgrl to primary and verify the current configuration
if the configuration is present execute
dgmgrl /
show configuration;
remove configuration;
3. Remove dataguard broker related parameters and configuration files from primary :
sqlplus / as sysdba
show parameter dg_broker
alter system set dg_broker_start=false scope=both;
alter system reset dg_broker_config_file1 sid='*';
alter system reset dg_broker_config_file2 sid='*';
show parameter dg_broker
4. Resetting of Archive Destionations
alter system set log_archive_dest_state_2='' scope=both;
On the primary remove any archive destinations that are archiving to
the standby
a) select dest_id,destination,status from v$archive_dest where
target='STANDBY';
Make the destionation_identified above as null by alter.
b) alter system set <destination_identified>='' scope=both;
alter system set log_archive_config='' scope=both;
-- checking destination status and error state
select ds.dest_id id
, ad.status
, ds.database_mode db_mode
, ad.archiver type
, ds.recovery_mode
, ds.protection_mode
, ds.standby_logfile_count "SRLs"
, ds.standby_logfile_active active
, ds.archived_seq#
from v$archive_dest_status ds
, v$archive_dest ad
where ds.dest_id = ad.dest_id
and ad.status != 'INACTIVE'
order by
ds.dest_id;
5.reset below parameters
alter system reset log_archive_config scope=both sid='*';
alter system reset fal_client scope=both sid='*';
alter system reset fal_server scope=both sid='*';
6. tnsnames.ora & /etc/hosts
Remove the enteries that are added into tnsnames.ora and /etc/hosts at the time of configuration of standby
tnsnames.ora should have only 2 entries one with primary_db_unique_name and another with LISTENER_SID
7. check if any standby log file present , drop them and delete manually from asm storage.
col member for a60
set lines 200 pages 200
select GROUP#,MEMBER,TYPE,STATUS from v$logfile where TYPE='STANDBY' order by GROUP#;
--drop all standby log groups only if present
sample command: update group number from above query
---------------------------------------------------------------------------------------
ALTER DATABASE DROP LOGFILE GROUP 7;
