Sunday, December 1, 2024

 Step-by-Step Guide: Configuring Zero Data Loss Autonomous Recovery Services for Oracle DBCS

Ensuring business continuity and data protection in the cloud has become mission-critical. Oracle’s Zero Data Loss Autonomous Recovery Service (ZDLARS) helps organizations protect their Autonomous Databases and DBCS (Database Cloud Services) with minimal manual effort, near-zero data loss, and automated recovery capabilities.

This blog provides a step-by-step walkthrough to configure Autonomous Recovery Services (ARS) with detailed screenshots and explanations.

Prerequisites

Before you begin:

  • You must have access to an Oracle Cloud Infrastructure (OCI) account.

  • An active DBCS (Oracle Database Cloud Service) instance.

  • Necessary permissions to create and assign IAM policies.

  • A registered private subnet is in the same region as your database.

Step 1: Create A Protection Policy for the ZDLARS

Creating a Protection Policy for Your Database Compartment in OCI

Best Practice: Use Dedicated Compartments

OCI best practices recommend creating separate compartments for different systems to maintain clean governance, improved access control, and better resource organization. This ensures that each environment—whether for dev, test, or production—is logically isolated and easier to manage.

We’ve set up a dedicated compartment to host our two-node RAC Extreme Edition database. With this structure in place, the next step is configuring a Protection Policy for this compartment.

Steps to Create a Protection Policy

  1. Navigate to the Database Backup and Protection Policies Section

    • From the OCI Console, go to Database > Backup & Protection Policies.

  2. Create a New Protection Policy

    • Click Create Protection Policy.

    • Provide a clear and descriptive name (e.g.,om_palane_db Protection Policy).

    • Select the compartment where your RAC database resides.



Step 2 : Create a Recovery Subnet for the database 

Enabling Secure Backups with Recovery Service Subnets in OCI

When it comes to protecting your Oracle Cloud databases, network isolation plays a key role in ensuring secure and efficient backup operations. Oracle Cloud Infrastructure (OCI) addresses this through Recovery Service subnets, which establish a dedicated network path between your databases and the OCI Recovery Service.

Best Practice: Use a Private Subnet for  Immutable Backups

For strong security with immutable backup, OCI requires that your database VCN includes a single, private subnet dedicated exclusively to Recovery Service backups. This subnet should not be shared with other services or applications, helping you maintain a clean and controlled environment for backup traffic.

How to Register a Recovery Service Subnet

The process is streamlined through the OCI Console:

[1]The name of the Recovery subnet is used to identify the subnet 

[2]A compartment to be created, preferably in the network compartment  

[3]Choose the Particular VCN that has been associated with the   database; it should be your database private subnet 

[4] The recovery subnet that will be used for the immutable backups (you should have created a subnet in the compartment before this registration here we are registering that subnet as the recovery service subnet.



Step 3: Create the IAM Policies for Autonomous Recovery services 


To enable secure and streamlined management of Autonomous Recovery Services, you need to define the right IAM policies at both the tenancy and compartment levels. These policies grant the necessary permissions to the designated group responsible for managing backup and recovery operations.

Define Policies in the OCI Console

  1. Navigate to Identity & Security > Policies in the OCI Console.

  2. Create a new policy (or edit an existing one) with a clear name like AUTONOMOUS_RECOVERY_SERVICES_POLICY.

  3. Assign the policy at the tenancy level to ensure broad access for service operations.

Example Policy Statements

Here are some recommended statements,

Allow service database to manage recovery-service-family in tenancy

Allow service database to manage tagnamespace in tenancy

Allow service rcs to manage recovery-service-family in tenancy

Allow service rcs to manage virtual-network-family in tenancy

Allow group <your-admin-group> to manage recovery-service-family in tenancy



Step 4: Creating the Protection Policy 

Create the Protection Policy for the backup based on the number of days specified, and the backups will be retained  for the specified number of days

[1]Provide the Name of the Protection Policy

[2]Database compartment

[3] Specify the number of days the backup is to be retained 

Click enable retention lock so no one can go and delete the backups. There are methods to keep the backup for 10 years.  Depending on your requirements, LTR Recovery Service can retain your LTR backups for anywhere between 90 days and 10 years. Will see about the LTR in a separate blog post 



Step 5: Enabling the Autonomous Recovery Section in DBCS


Navigate to the DBCS instance in OCI. Under the Autonomous Recovery section, click Enable. This will protect the database instance under the Oracle-managed recovery service. It starts by preparing the infrastructure for protection with Zero Data Loss.

1. Enable automatic backups. The Checkbox must be checked to enable backup functionality.
  • OCI will automatically perform scheduled backups when enabled according to the chosen configuration.

2. Backup destination: A dropdown field to select where the backups will be stored. To enable the Autonomous Recovery Service, we need to choose  the Autonomous Recovery Service

3. Protection policy: Displays the current policy selected for backup retention and recovery. In this example:
  • _AUTONOMOUS_RECOVERY_SERVICES_PROTECTION_POLICY -- the policy that we had created in the earlier steps, which has a 31-day recovery window 

4. Real-time data protection
  • Select this checkbox to enable real-time redo log backups, ensuring that changes are continuously backed up between scheduled backups,, and with near-zero lag,, the logs will be applied to the backups

5. Deletion options after database termination

Two radio buttons to define what happens to backups after the source database is deleted:

Retain backups according to the protection policy retention period
Backups follow the full policy period (e.g., 31 days).
Retain backups for 72 hours, then delete
Backups are kept for a short period after termination and then removed.

 6. Scheduled time for daily backup (UTC)
  • Dropdown to define the daily backup time window.

 Take the first backup immediately . When this checkbox is selected, OCI initiates the first backup as soon as the configuration is saved. Useful for getting a baseline backup without waiting for the scheduled time.



Step 6:  Check the database with the protection summary 




Wednesday, March 27, 2024

 

🔌 Installing Oracle Integration Cloud (OIC) Connectivity Agent on a Linux Server

Oracle Integration Cloud (OIC) allows seamless integration between on-premise and cloud applications using a Connectivity Agent. In this guide, we walk through installing and starting the OIC Agent on a Linux server.

Prerequisites

Before proceeding, make sure you have:

  • Access to the OIC Agent installer ZIP (e.g. oic_conn_agent_installer_1.zip

  • A supported version of Java JDK (17 or higher)

  • Correct Agent Group and OIC configuration credentials

  • Outbound internet access from the Linux server (for agent registration)

Step 1: Set Up Environment Variables

Navigate to the agent installer directory and configure the required Java environment:

export JAVA_HOME=/oic/jdk-17.0.7

export PATH=$JAVA_HOME/bin:$PATH

Check the Java version

Check the OIC and use the latest compatible Java  version 

Step 2: Unzip and Explore Agent Directory

After placing the oic_conn_agent_installer_1.zip in your working directory, ensure the following files are present:

Download the oic_conn_agent_installer.zip from the OIC console and place it in the server where the agent needs to be installed 

In this case, we are installing the user as Oracle  on the Linux Box  

unzip oic_conn_agent_installer_1.zip

[oracle@omdb1 oic]$ ls

agenthome  connectivityagent.jar  cpi_upgradeutility.jar  InstallerProfile.cfg  jdk-17.0.7  jdk-17.0.7_linux-x64_bin.tar.gz  oic_conn_agent_installer_1.zip  ss

Step 3: Start the Agent Installation

Run the installation command using the connectivity JAR:

[oracle@omdb1 oic]$ java -jar connectivityagent.jar
Proceeding to install a new agent ...
Enter your OIC username : palaneandavar@domainname.ae
Enter password for palaneandavar@domainname.ae:
No Proxy Configuration Detected
Checking for trusted certificates ...
Making call to check OIC Version ...
Making call to check Agent group availability ...
Updating Agent with configuration details ...
Making call to register new agent instance ...
Making call for getting agent app id & keys...
Done with Agent installation & configuration... Starting Agent for message processing.
Agent started successfully...Now available for new messages...

This confirms that the agent has been installed, configured, and started successfully.

Step 4: Run OIC Agent in the Background


[oracle@omdb1 oic]$ nohup java -jar connectivityagent.jar &
[1] 81615
[oracle@omdb1 oic]$ nohup: ignoring input and appending output to ‘nohup.out’


[oracle@omdb1 oic]$ cat nohup.out
Existing Agent installation found... Starting Agent for message processing.
Checking for already running instances of this agent. This might take up to 15 seconds ...
Initializing the credential store ...
Agent started successfully...Now available for new messages...
[oracle@omdb1 oic]$

 Final Notes

  • The connectivity agent bridges on-prem systems (like databases, ERP, etc.) and Oracle Cloud.

  • Ensure the Linux server allows outbound connectivity to OIC endpoints (typically HTTPS on port 443).

  • You can monitor agent status directly from the OIC console under the Agents section.

Integrate your agent with on-premise apps like Oracle EBS, databases, or ERP connectors by configuring them in your OIC instance.


Need help integrating this agent with Oracle EBS /on-prem connectors or setting up high availability? Drop a comment or reach out-- happy to help!


Sunday, February 4, 2024

 

How to Get OCI Region and Instance Metadata from a Linux Server

When working with Oracle Cloud Infrastructure (OCI), there are times when you need to quickly fetch instance-level metadata — like the region, availability domain, shape, and other details — directly from the server. Fortunately, OCI exposes a handy metadata service that makes this easy to access from the command line.

In this post, I’ll show you how to pull just the region using curl, and also explain what other information is available if you query the full metadata endpoint.


Fetching the Region of an OCI Instance

To retrieve the region (like me-dubai-1) of an instance running on OCI, you can use:

curl -s http://169.254.169.254/opc/v1/instance/ | grep '"region":' | awk -F '"' '{print $4}'


[root@<Servername> <foldername>]# curl -s http://169.254.169.254/opc/v1/instance/ |grep region


  "region": "me-dubai-1",

  "regionInfo": {

    "regionIdentifier": "me-dubai-1",

    "regionKey": "DXB"

}

Another method to use is JQ

curl -s http://169.254.169.254/opc/v1/instance/ | jq -r '.region'

To get the complete instance metadata  

You’ll get the entire instance metadata in JSON format. Here’s a trimmed sample of what that might look like:

{
  "availabilityDomain": "",
  "compartmentId": "OCID",
  "displayName": "instance Name",
  "faultDomain": "FAULT-DOMAIN-1",
  "hostname": "Hostname of the Instance ",
  "id": "ocid ..",
  "image": "which version of O/S image had been used,
  "region": "me-dubai-1",
  "regionInfo": {
    "regionIdentifier": "me-dubai-1",
    "regionKey": "DXB"
  },
  "shape": "Type of VM",  like VM standard flexe4
  "state": "Running",
  "timeCreated": ",
  "metadata": {
    "ssh_authorized_keys": "SSH keys associated with the instance "
  }
}

Some key fields 

Field
Description
region
 The region where the instance is running
availability Domain
 Availability Domain (e.g., ME-DUBAI-1-AD-1)
compartment Id      
OCID of the compartment
shape
Instance shape (e.g., VM.Standard.E4.Flex)
display Name
Name of the instance
hostname
Hostname of  the instance
id
OCID of the instance
state
Instance lifecycle state (e.g., Running) 

Formatting JSON Output (Without jq)

If jq isn’t installed, you can still format the JSON nicely using Python:

curl -s http://169.254.169.254/opc/v1/instance/ | python3 -m json.tool

Notes:

The instance metadata service is local and does not require any credentials or internet access. It’s a super handy tool for automation scripts, configuration checks, or logging environment info in multi-region deployments.