Oracle OCI & AWS CLI commands

AWS CLI and OCI CLI commands side by side for easier comparison. Below table compares AWS and OCI CLI commands for similar actions across both platforms, helping you easily switch between them or use both in your multi-cloud environment.

AWS CLI Command	OCI CLI Command
Configure AWS CLI: aws configure	Configure OCI CLI: oci setup config
EC2: List Instances: aws ec2 describe-instances	Compute: List Instances: oci compute instance list --compartment-id <compartment_ocid>
EC2: Start an Instance: aws ec2 start-instances --instance-ids <instance_id>	Compute: Create an Instance: oci compute instance launch --compartment-id <compartment_ocid> --availability-domain <availability_domain> --shape <instance_shape> --image-id <image_ocid> --subnet-id <subnet_ocid> --display-name <instance_name>
EC2: Stop an Instance: aws ec2 stop-instances --instance-ids <instance_id>	Compute: Stop an Instance: oci compute instance action --instance-id <instance_ocid> --action STOP
S3: List Buckets: aws s3 ls	Object Storage: List Buckets: oci os bucket list --compartment-id <compartment_ocid>
S3: Upload a File: aws s3 cp <file> s3://<bucket_name>/<file_name>	Object Storage: Upload a File: oci os object put --bucket-name <bucket_name> --name <object_name> --file <local_file_path>
S3: Download a File: aws s3 cp s3://<bucket_name>/<file_name> <file>	Object Storage: Download a File: oci os object get --bucket-name <bucket_name> --name <object_name> --file <local_file_path>
IAM: List Users: aws iam list-users	IAM: List Users: oci iam user list --compartment-id <compartment_ocid>
IAM: Create a User: aws iam create-user --user-name <user_name>	IAM: Create a User: oci iam user create --compartment-id <compartment_ocid> --name <user_name> --description "<description>"
Lambda: List Functions: aws lambda list-functions	Database: List Databases: oci db system list --compartment-id <compartment_ocid>
CloudWatch: List Alarms: aws cloudwatch describe-alarms	Monitoring: List Alarms: oci monitoring alarm list --compartment-id <compartment_ocid>
CloudFormation: Describe Stacks: aws cloudformation describe-stacks	Load Balancer: List Load Balancers: oci lb load-balancer list --compartment-id <compartment_ocid>
RDS: Describe DB Instances: aws rds describe-db-instances	Load Balancer: Create a Load Balancer: oci lb load-balancer create --compartment-id <compartment_ocid> --shape <load_balancer_shape> --subnet-id <subnet_ocid> --display-name <load_balancer_name>
DynamoDB: List Tables: aws dynamodb list-tables	Block Volume: List Volumes: oci bv volume list --compartment-id <compartment_ocid>
Route 53: List Hosted Zones: aws route53 list-hosted-zones	Block Volume: Attach a Volume: oci bv volume attach --volume-id <volume_ocid> --instance-id <instance_ocid> --device <device_name>
SNS: List Topics: aws sns list-topics	Autonomous Database: List Autonomous Databases: oci db autonomous-database list --compartment-id <compartment_ocid>
ECR: List Repositories: aws ecr describe-repositories	Cloud Guard: List Security Problems: oci cloud-guard problem list --compartment-id <compartment_ocid>
Cost Explorer: Get Usage: aws ce get-cost-and-usage --time-period Start=2025-01-01,End=2025-01-31 --granularity DAILY --metrics "AmortizedCost"	Database: Create a Database: oci db system launch --compartment-id <compartment_ocid> --availability-domain <availability_domain> --shape <db_shape> --subnet-id <subnet_ocid> --display-name <db_system_name> --database-edition <database_edition> --admin-password <admin_password>
STS: Get Caller Identity: aws sts get-caller-identity	Compute: List Instances: oci compute instance list --compartment-id <compartment_ocid>
CloudTrail: Lookup Events: aws cloudtrail lookup-events --max-results 10	Compute: Stop an Instance: oci compute instance action --instance-id <instance_ocid> --action STOP
CloudFront: List Distributions: aws cloudfront list-distributions	Object Storage: Upload a File: oci os object put --bucket-name <bucket_name> --name <object_name> --file <local_file_path>

---

Below is a table comparing AWS and OCI commands related to Networking. These commands cover networking services like Virtual Private Cloud (VPC) in AWS and Virtual Cloud Network (VCN) in OCI. This table compares networking-related AWS CLI and OCI CLI commands for similar tasks like managing VPCs/VCNs, subnets, security groups, route tables, VPNs, and more. For both platforms, these commands allow you to configure, manage, and troubleshoot your networking infrastructure effectively.

AWS CLI Command	OCI CLI Command
VPC: Create VPC: aws ec2 create-vpc --cidr-block <cidr_block>	VCN: Create a VCN: oci network vcn create --compartment-id <compartment_ocid> --cidr-block <cidr_block> --display-name <vcn_name>
VPC: List VPCs: aws ec2 describe-vpcs	VCN: List VCNs: oci network vcn list --compartment-id <compartment_ocid>
VPC: Create Subnet: aws ec2 create-subnet --vpc-id <vpc_id> --cidr-block <cidr_block>	VCN: Create a Subnet: oci network subnet create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --cidr-block <cidr_block> --availability-domain <availability_domain> --display-name <subnet_name>
VPC: List Subnets: aws ec2 describe-subnets --filters "Name=vpc-id,Values=<vpc_id>"	VCN: List Subnets: oci network subnet list --compartment-id <compartment_ocid> --vcn-id <vcn_ocid>
VPC: Create Internet Gateway: aws ec2 create-internet-gateway	VCN: Create an Internet Gateway: oci network internet-gateway create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --display-name <ig_name>
VPC: Attach Internet Gateway: aws ec2 attach-internet-gateway --vpc-id <vpc_id> --internet-gateway-id <ig_id>	VCN: Attach an Internet Gateway: oci network vcn attach-internet-gateway --vcn-id <vcn_ocid> --internet-gateway-id <internet_gateway_ocid>
VPC: Create Route Table: aws ec2 create-route-table --vpc-id <vpc_id>	VCN: Create a Route Table: oci network route-table create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --display-name <route_table_name>
VPC: List Route Tables: aws ec2 describe-route-tables --filters "Name=vpc-id,Values=<vpc_id>"	VCN: List Route Tables: oci network route-table list --compartment-id <compartment_ocid> --vcn-id <vcn_ocid>
VPC: Create Route: aws ec2 create-route --route-table-id <route_table_id> --destination-cidr-block <cidr_block> --gateway-id <gateway_id>	VCN: Create a Route in Route Table: oci network route-rule create --route-table-id <route_table_id> --destination <cidr_block> --network-entity-id <gateway_ocid>
VPC: Modify Route Table: aws ec2 replace-route --route-table-id <route_table_id> --destination-cidr-block <cidr_block> --gateway-id <gateway_id>	VCN: Update Route Table: oci network route-rule update --route-table-id <route_table_id> --route-rule-id <route_rule_id> --destination <cidr_block> --network-entity-id <gateway_ocid>
VPC: Delete Subnet: aws ec2 delete-subnet --subnet-id <subnet_id>	VCN: Delete Subnet: oci network subnet delete --subnet-id <subnet_ocid>
VPC: Delete Internet Gateway: aws ec2 delete-internet-gateway --internet-gateway-id <ig_id>	VCN: Delete Internet Gateway: oci network internet-gateway delete --internet-gateway-id <internet_gateway_ocid>
VPC: Create Security Group: aws ec2 create-security-group --group-name <group_name> --description <description> --vpc-id <vpc_id>	VCN: Create a Security List (OCI equivalent of Security Group): oci network security-list create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --display-name <security_list_name>
VPC: List Security Groups: aws ec2 describe-security-groups --filters "Name=vpc-id,Values=<vpc_id>"	VCN: List Security Lists: oci network security-list list --compartment-id <compartment_ocid> --vcn-id <vcn_ocid>
VPC: Create Network ACL: aws ec2 create-network-acl --vpc-id <vpc_id>	VCN: Create a Network Security Group: oci network network-security-group create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --display-name <nsg_name>
VPC: Attach Network ACL: aws ec2 associate-network-acl --network-acl-id <acl_id> --subnet-id <subnet_id>	VCN: Attach a Network Security Group: oci network network-security-group add-vnics --network-security-group-id <nsg_id> --nics <nic_ocid>
VPC: Create VPC Peering: aws ec2 create-vpc-peering-connection --vpc-id <vpc_id> --peer-vpc-id <peer_vpc_id>	VCN: Create VCN Peering: oci network vcn-peering-connection create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --peer-vcn-id <peer_vcn_ocid> --display-name <peering_name>
VPC: Accept VPC Peering: aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id <peering_id>	VCN: Accept VCN Peering: oci network vcn-peering-connection accept --vcn-peering-connection-id <peering_ocid>
VPC: Delete VPC Peering: aws ec2 delete-vpc-peering-connection --vpc-peering-connection-id <peering_id>	VCN: Delete VCN Peering: oci network vcn-peering-connection delete --vcn-peering-connection-id <peering_ocid>
VPC: Create VPN Gateway: aws ec2 create-vpn-gateway --type <vpn_type> --amazon-side-asn <asn>	VCN: Create a VPN Gateway: oci network vpn-gateway create --compartment-id <compartment_ocid> --vcn-id <vcn_ocid> --display-name <vpn_gateway_name>
VPC: Attach VPN Gateway: aws ec2 attach-vpn-gateway --vpc-id <vpc_id> --vpn-gateway-id <vpn_gateway_id>	VCN: Attach a VPN Gateway: oci network vpn-gateway attach --vcn-id <vcn_ocid> --vpn-gateway-id <vpn_gateway_ocid>
VPC: List VPN Gateways: aws ec2 describe-vpn-gateways	VCN: List VPN Gateways: oci network vpn-gateway list --compartment-id <compartment_ocid>

---

Here’s a comparison table of AWS CLI and OCI CLI commands related to backup and restore from snapshots for both AWS and OCI. These commands cover common actions like creating snapshots, listing snapshots, and restoring from them.

AWS CLI Command	OCI CLI Command
EC2: Create Snapshot (Backup an EBS volume): aws ec2 create-snapshot --volume-id <volume_id> --description "<description>"	Block Volume: Create Snapshot (Backup an EBS volume in OCI): oci bv volume-create-backup --volume-id <volume_id> --display-name "<snapshot_name>" --description "<description>"
EC2: Describe Snapshots (List snapshots): aws ec2 describe-snapshots --owner-ids <owner_id>	Block Volume: List Snapshots (List backups of block volumes): oci bv backup list --compartment-id <compartment_ocid>
EC2: Delete Snapshot (Delete a snapshot): aws ec2 delete-snapshot --snapshot-id <snapshot_id>	Block Volume: Delete Snapshot (Delete a backup): oci bv backup delete --backup-id <backup_id>
EC2: Restore from Snapshot (Create volume from snapshot): aws ec2 create-volume --snapshot-id <snapshot_id> --availability-zone <availability_zone>	Block Volume: Restore from Snapshot (Create a new volume from a snapshot): oci bv volume restore --backup-id <backup_id> --availability-domain <availability_domain> --compartment-id <compartment_ocid>
RDS: Create Snapshot (Backup an RDS instance): aws rds create-db-snapshot --db-instance-identifier <db_instance_id> --db-snapshot-identifier <snapshot_name>	Autonomous Database: Create a Backup (Autonomous DB snapshot in OCI): oci db autonomous-database backup create --autonomous-database-id <autonomous_db_ocid> --display-name <backup_name>
RDS: Describe Snapshots (List RDS snapshots): aws rds describe-db-snapshots --db-instance-identifier <db_instance_id>	Autonomous Database: List Backups (List backups of Autonomous Database): oci db autonomous-database backup list --compartment-id <compartment_ocid>
RDS: Delete Snapshot (Delete an RDS snapshot): aws rds delete-db-snapshot --db-snapshot-identifier <snapshot_id>	Autonomous Database: Delete a Backup (Delete Autonomous DB backup): oci db autonomous-database backup delete --autonomous-database-id <autonomous_db_ocid> --backup-id <backup_id>
RDS: Restore from Snapshot (Restore an RDS instance from snapshot): aws rds restore-db-instance-from-db-snapshot --db-instance-identifier <new_db_instance_id> --db-snapshot-identifier <snapshot_id>	Autonomous Database: Restore from Backup (Restore Autonomous DB from backup): oci db autonomous-database restore-from-backup --autonomous-database-id <autonomous_db_ocid> --backup-id <backup_id>

Key Points:

• AWS EC2 primarily uses EBS snapshots for backup and restore of volumes. You can create a volume from a snapshot to restore it.

• AWS RDS provides an option to create and restore database snapshots for RDS instances.

• OCI Block Volume uses volume backups (backups of block volumes) to manage snapshots, and you can restore from backups to a new volume.

• OCI Autonomous Database allows backup creation and restore for Autonomous Databases via backups.

Both AWS and OCI offer similar snapshot and restore functionalities but with slight differences in the specific commands and services they offer for database and block volume backups.

Oracle DGMGRL Swithover & Switchback steps

 To perform a switchover and switchback using Oracle Data Guard with dgmgrl (Data Guard Manager command-line interface), you typically use the following steps. These steps assume you have already configured Oracle Data Guard and are familiar with the concepts of Primary and Standby databases.

1. Switchover from Primary to Standby Database

A switchover is a planned role reversal between the Primary and Standby databases. This process allows the Standby database to become the new Primary and vice versa.

Steps for Switchover:

1. Log in to Data Guard Manager (DGMGRL): Open a command-line terminal on the Primary database machine and log into the Data Guard Manager using dgmgrl.

   dgmgrl
   

2. Connect to the Data Guard Configuration: Connect to your Data Guard configuration.

   DGMGRL> connect sys/password@primary
   

   Replace sys/password with the appropriate credentials and the correct TNS name for your primary database.

3. Check the Data Guard Status: Before proceeding, it's good practice to check the status of the Data Guard configuration.

   DGMGRL> show configuration;
   

   Verify that the configuration is in sync and there are no issues.

4. Perform the Switchover: Execute the switchover command to initiate the role reversal.

   DGMGRL> switchover to standby;
   

   Replace standby with the correct name of the standby database if needed.

   This command will:

   • Automatically stop Redo Apply on the Standby.
   • Start Redo Apply on the new Primary.
   • Synchronize the new Primary with the old Standby.
   • If necessary, restart the Oracle instances to complete the switchover.

   After the switchover completes, the old Primary will be the new Standby, and the old Standby will be the new Primary.

5. Verify the Switchover: Check that the switchover was successful by viewing the configuration status.

   DGMGRL> show configuration;
   

   Ensure that the roles have been reversed correctly.

---

2. Switchback from Standby to Primary Database

Switching back is simply performing a reverse of the original switchover process, where the Primary database becomes the Standby again.

Steps for Switchback:

1. Log in to Data Guard Manager (DGMGRL): Open a terminal on the current Primary (which was previously the Standby) and log into the Data Guard Manager using dgmgrl.

   dgmgrl
   

2. Connect to the Data Guard Configuration: Connect to the Data Guard configuration.

   DGMGRL> connect sys/password@primary
   

3. Check the Data Guard Status: Check the current status to ensure everything is running smoothly.

   DGMGRL> show configuration;
   

4. Perform the Switchback: Execute the switchover command again, but this time switch back to the original Primary (which is now the Standby).

   DGMGRL> switchover to primary;
   

   This command will:

   • Reverse the roles of the Primary and Standby databases once again.
   • Stop Redo Apply on the current Standby and resume it on the new Standby.
   • Synchronize the databases.

5. Verify the Switchback: Check the Data Guard configuration to verify the new roles.

   DGMGRL> show configuration;
   

---

Things to Consider:

• Synchronization: Ensure that the database logs are synchronized before performing any switchover. You can use the show database verbose command to check the synchronization status.

• Redundancy and Backup: Always ensure you have current backups of the databases before performing a switchover or switchback, as these operations can potentially cause downtime.

• Log Archives: If you have the possibility of switching back during the switchover process, verify that all the archive logs have been applied correctly.

• Data Guard Broker: If you're using Data Guard Broker, these operations can be performed automatically without manual intervention using DGMGRL commands.

---

By following these steps, you can successfully perform a switchover and switchback operation with Oracle Data Guard using dgmgrl. Always perform these operations during planned maintenance windows to minimize downtime.

For a comprehensive and official reference on performing switchover and switchback operations in Oracle Data Guard using dgmgrl, I recommend checking Oracle's official documentation:

• Oracle Data Guard Concepts and Administration Guide: This is the most authoritative source for Data Guard operations, including switchover and switchback procedures.

You can find the relevant documentation here: Oracle Data Guard Concepts and Administration

You can specifically refer to the following sections for detailed steps on switchover and switchback:

• Chapter 5: Switchover and Failover Procedures (for steps on switchover and switchback)
• Chapter 10: Data Guard Command-Line Interface (DGMGRL) (for DGMGRL command usage)

Oracle Data Guard Broker, 19c

DR SWITCHOVER 19c DB USING DGMGRL

 Description:

In this blog, we are going to see data guard switch over by using data guard broker DGMGRL.

Data Guard Switchover:

• A database can be in one of two mutually exclusive modes (primary or standby). These roles can be altered at runtime without loss of data or resetting of redo logs. A switchover is a role reversal between the primary database and one of its standby databases. A switchover guarantees no data loss.
• This is typically done for planned maintenance of the primary system.
• During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.
• The transition occurs without having to re-enable either database.

Overall steps:

1. Connect the primary database with DGMGRL Data Guard broker.
2. Switch over primary to standby database.
3. Connect Standby database.
4. Switch over standby to primary.

Step 1: Connect the primary database with the DGMGRL Data Guard broker.

[oratest@oracle admin]$ dgmgrl sys/oracle@orcl

DGMGRL for Linux: Release 19.0.0.0.0 - Production on 
Fri Nov 12 13:19:44 2021 Version 19.9.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.
All rights reserved.Welcome to DGMGRL, type "help" for information.

Connected to "orcl"

Connected as SYSDBA.

Step 2: Switch over primary to the standby database.

DGMGRL> switchover to orcl_stby;
Performing switchover NOW, please wait...

Operation requires a connection to instance "orcl" on database 
"orcl_stby"

Connecting to instance "orcl"...

Connected as SYSDBA.

New primary database "orcl_stby" is opening...

Operation requires start up of instance "orcl" on database "orcl"

Starting instance "orcl"...ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is "orcl_stby"

DGMGRL>

Let's switch back to the original primary. Connect to the 
new primary (orcl_stby) and switchover to the new standby database (orcl).

Step 3: Connect the Standby database.

[oratest@oracle admin]$ dgmgrl sys/oracle@orcl_stby

DGMGRL for Linux: Release 19.0.0.0.0 - Production on 
Fri Nov 12 13:31:56 2021Version 19.9.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. 
All rights reserved.
Welcome to DGMGRL, type "help" for information.

Connected to "orcl_stby"
Connected as SYSDBA.

Step 4: Switch over standby to primary

DGMGRL> switchover to orcl ;

Performing switchover NOW, please wait...

Operation requires a connection to instance "orcl" on 
database "orcl"

Connecting to instance "orcl"...

Connected as SYSDBA.

New primary database "orcl" is opening...

Operation requires start up of instance "orcl" on database 
"orcl_stby"

Starting instance "orcl"...

ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is "orcl"

DGMGRL>

DR Plan Management in OCI Oracle Cloud Infrastructure

 Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery has enhanced DR Plan management to automatically add and remove DR Plan Steps in existing DR Plans whenever DR Protection Groups member resources are changed. Full Stack DR now automatically modifies all DR plans in place, based on the members you add or remove from protection groups, preserving any custom steps you’ve added to plans.

Figure 1: Enhanced plan management requires approving modifications after updating members of protection groups.

As your business systems and application stack evolve, your disaster recovery plans need to remain in lockstep. With this new feature, Full Stack DR makes it easy to manage these ongoing changes.

Maintaining the integrity of your recovery plans is job number one for disaster recovery administrators, and changes to member resources in protection groups have a profound impact on recovery steps in DR Plans. So, we’ve introduced the following simple workflow to help ensure plan integrity whenever protection groups change:

1. Refresh: Refreshing a DR Plan makes it easy to see what has changed by tagging steps that were added or removed.
2. Verify: Verifying a DR Plan commits the changes and activates the plan.

Let’s explore how easy using this new capability is. Adding, removing, or changing member resources in either the primary or standby protection group triggers the plan refresh workflow.

Updating member resources begins the process

Nothing changes about the way you add a member resource. You still choose the resource type and provide the appropriate properties needed to inform Full Stack DR what you need done with the object during a recovery.

Imagine that you want to add two more moving Compute instances to the DR Protection Group in the primary region, which currently contains two virtual machines (VMs) and a single volume group, as shown in figure 2.

Figure 2: The current members of the DR protection group.

After adding the two Compute instances, the protection group looks like Figure 3. It looks exactly like it has always looked after adding or removing member resources – nothing is different here.

Figure 3: Two more Compute instances have been added as members of the protection group.

Exploring the new workflow

Now you can begin to see the changes introduced with the enhanced plan management scheme. The state of all plans in the standby protection group changes to Needs attention (Needs refresh), while the plans in the primary protection group change to Inactive (Needs refresh).

Figure 4: The state of all plans changes to “Needs attention” after updating members of protection groups.

None of the plans can run in this state, so your ability to recover is completely offline until the plan refresh workflow is completed in the standby protection group. You must select each DR Plan and then select the Refresh button, as shown in Figure 5. This selection forces Full Stack DR to inspect the members in both the primary and standby regions and update the plan in the standby protection group.

Figure 5: A Refresh action button appears at the top of all plans in a “Needs attention” state.

The refresh operation tags any plan steps that have been added or removed so you can see all the changes that will be made before the plan is updated permanently in the next step.

Figure 6: Refreshed plans show all plan groups and steps that were changed, added, or removed.

To accept and make changes permanent, select Verify.

Figure 7: A Verify action button appears at the top of all DR Plans that have been refreshed.

The verify operation commits the changes, updates the plan, and removes the tags so everything appears as normal.

Figure 8: Steps have been added after the verify operation is completed.

You must refresh all existing DR Plans contained in the standby protrection group. The resource list page for plans in the Oracle Cloud Console shows the state of all the plans, which can help you track your progress.

Figure 9: Use the plans resource list in the Oracle Cloud Console to track your progress.

When all the plans in the standby protection group are active, you’re ready to go. You still must refresh the DR Plans in the peer region, but you can recover from outages in the primary OCI region at this point in the process. Plans always run from the standby protection group.

Figure 10: Ensure that all DR Plans have been refreshed and verified in the standby region.

Refreshing plans in the primary protection group

The DR Plans in the primary protection group are still in an Inactive (Needs refresh) state and also need refreshing.  However, you can’t modify recovery plans contained in protection groups with the primary role, including refreshing, and verifying. So, you must perform a switchover so that you can refresh the plans in peer region.

Figure 11: Plans must be refreshed in primary DR Protection Group after switchover.

Conclusion

Keeping up with change can be complex, but Full Stack DR has made the job of managing change just a little simpler with this new enhancement. The new DR Plan refresh feature automatically rebuilds plans, while protecting the user-defined steps that you have taken so much time to perfect.

References:

Add Members to a Disaster Recovery Protection Group

Enhanced Disaster Recovery Plan Management with OCI Full Stack Disaster Recovery

Orchestrate Disaster Recovery with a Single Click | Oracle