Comparision between AWS RDS PostgreSQL, AWS RDS Oracle, and AWS Aurora PostgreSQL

 Comparison focusing specifically on AWS RDS PostgreSQL, AWS RDS Oracle, and AWS Aurora PostgreSQL. These are all managed services from AWS, but they have key differences in terms of performance, scaling, features, and cost.

Comparison of AWS RDS PostgreSQL vs AWS RDS Oracle vs AWS Aurora PostgreSQL

Category	AWS RDS PostgreSQL	AWS RDS Oracle	AWS Aurora PostgreSQL
Database Engine	PostgreSQL (Open-source)	Oracle (Proprietary)	PostgreSQL-Compatible (based on PostgreSQL)
Licensing	No license cost for core engine, pay-as-you-go	Licensing fees (costly, based on edition)	No separate license fee for PostgreSQL (pay-as-you-go)
Cost	Generally lower (only pay for storage and instances)	Higher due to licensing, compute, and storage	Higher than RDS PostgreSQL, but more cost-efficient than RDS Oracle
Scalability	Horizontal scaling via read replicas; vertical scaling with instance type changes	Horizontal scaling via RAC (Real Application Clusters), vertical scaling	Horizontal scaling via Aurora Replicas (up to 15 replicas); automatic scaling
Performance	Good performance, but may require manual tuning for higher performance	Optimized for large-scale enterprise workloads, heavy transactional performance	Superior performance, up to 2x faster than standard PostgreSQL due to Aurora's distributed storage architecture
Replication	Supports read replicas and cross-region replication	Supports read replicas, Oracle Data Guard (for multi-region)	Supports Aurora Replicas with high availability and fast failover
Availability	Multi-AZ support for high availability	Multi-AZ support; Advanced features like Data Guard for HA	Built-in high availability with 6 copies of data across 3 AZs
Durability	Automated backups, point-in-time recovery (PITR)	Advanced backup, Flashback, RMAN	Automated backups, continuous backups to Amazon S3
Backup & Recovery	Automated backups, snapshots, point-in-time recovery	Flashback, advanced backup with RMAN, point-in-time recovery	Continuous backups, automatic failover, point-in-time recovery
Performance Tuning	Manual tuning required for best performance	Advanced tuning options available (partitioning, indexing)	Automatic storage scaling and optimization; best for read-heavy workloads
Data Models	Relational, JSONB, Full-text search, Geospatial	Relational, OLAP, XML, Advanced partitioning	Relational, JSON, and PostgreSQL features, optimized for high-read workloads
Security	Encryption at rest/in-transit, IAM integration	Encryption, Database Vault, TDE, advanced security features	Encryption at rest/in-transit, IAM roles, VPC peering
Compliance	Suitable for general compliance needs	Strong compliance with HIPAA, PCI DSS, SOX, etc.	Suitable for many enterprise workloads; offers compliance for regulated industries
HA/DR (High Availability/Disaster Recovery)	Multi-AZ support for high availability	Advanced disaster recovery features like Data Guard and RAC	Built-in HA with automatic failover within Aurora; 6 copies of data across 3 AZs
Auto Scaling	Limited to read replicas and instance resizing	Requires manual scaling or RAC	Auto-scaling of storage and compute resources, based on demand
Integration with AWS Services	Easy integration with other AWS services (Lambda, S3, CloudWatch)	Tight integration with Oracle ecosystem	Seamless integration with other AWS services (Lambda, S3, Redshift, etc.)
Maintenance & Patches	Managed service with automatic patching	Managed service with automatic patching, but complex maintenance window	Aurora handles patches with minimal downtime; more automation
Replication Latency	Typically low, but can be higher for cross-region replication	Lower replication latency with RAC and Data Guard	Low replication latency, due to Aurora’s distributed architecture
Use Cases	Good for standard PostgreSQL workloads, moderate to large apps	Best for large enterprise systems needing advanced features like RAC, OLAP, and high compliance	Best for high-performance, read-heavy applications, and large-scale web applications
Migration	Easy to migrate from PostgreSQL or MySQL	More complex migrations due to proprietary nature	Easy migration from PostgreSQL (compatible with RDS PostgreSQL)
Enterprise Features	Limited to standard PostgreSQL features	Enterprise-grade features like partitioning, Flashback, and Real Application Clusters (RAC)	Performance enhancements, seamless failover, automatic scaling, and replication for high availability

Key Differences Summary:

1. Licensing & Cost:

   • RDS PostgreSQL is the most cost-effective, being open-source with no licensing fees.

   • RDS Oracle is significantly more expensive due to licensing fees, especially for enterprise features.

   • Aurora PostgreSQL costs more than RDS PostgreSQL but is designed to be more performant and scalable, especially for large-scale read-heavy workloads.

2. Performance & Scalability:

   • RDS PostgreSQL performs well for most use cases but might require manual optimization for high-demand applications.

   • RDS Oracle offers excellent performance for enterprise systems, especially for large transaction volumes and highly complex queries.

   • Aurora PostgreSQL outperforms standard PostgreSQL (RDS) by up to 2x, with automatic storage scaling, better replication, and high availability.

3. High Availability & Replication:

   • RDS PostgreSQL supports Multi-AZ for high availability and read replicas for scaling, but lacks advanced replication features.

   • RDS Oracle supports high availability with RAC and Data Guard, allowing for greater disaster recovery options.

   • Aurora PostgreSQL offers built-in high availability with automatic failover and replication across multiple availability zones.

4. Use Case Suitability:

   • RDS PostgreSQL is great for startups, developers, and moderate-sized applications that need the flexibility of PostgreSQL without extra complexity.

   • RDS Oracle is a go-to for large enterprises requiring advanced features like OLAP, high compliance, or complex transactional systems.

   • Aurora PostgreSQL shines in performance-critical applications, high-traffic web apps, and cloud-native architectures that need auto-scaling and high availability.

5. Integration & Maintenance:

   • RDS PostgreSQL integrates easily with AWS services and offers simplified management.

   • RDS Oracle also integrates well with AWS but is generally more complex to manage due to Oracle’s feature set and licensing.

   • Aurora PostgreSQL offers tight integration with AWS services and is designed for minimal downtime and maintenance, with automatic patching and scaling.

---

When to Choose Each:

• AWS RDS PostgreSQL: If you need a reliable and cost-effective PostgreSQL option without the complexity of licensing and enterprise features.

• AWS RDS Oracle: If you require enterprise-level features like RAC, OLAP, or high compliance, and are willing to bear the high licensing and management cost.

• AWS Aurora PostgreSQL: If you need high-performance, low-latency replication, auto-scaling, and better availability, especially for read-heavy or mission-critical applications.

Step-by-Step Guide to become AWS DevOps Engineer

 Becoming an AWS DevOps engineer requires a combination of cloud knowledge, DevOps principles, and hands-on experience. Here's a step-by-step guide to help you along the way:

1. Understand the Basics of Cloud Computing & AWS

• Learn Cloud Computing Concepts:

  • Understand the basics of cloud computing: what it is, types (IaaS, PaaS, SaaS), and benefits.

  • Learn about AWS and its services, including EC2, S3, VPC, IAM, RDS, etc.

  • Start with the AWS Free Tier to get hands-on experience with AWS services.

• AWS Certified Cloud Practitioner:

  • This is an entry-level certification that covers AWS Cloud basics, which will give you a solid foundation before diving deeper into more advanced concepts.

  • Resources: AWS Training and Certification (free resources), A Cloud Guru, and AWS's own whitepapers.

2. Learn DevOps Fundamentals

• Understand DevOps Principles:

  • Learn about Continuous Integration (CI), Continuous Delivery (CD), Infrastructure as Code (IaC), automation, monitoring, and feedback loops.

  • Focus on the cultural and organizational aspects of DevOps.

• Learn Version Control:

  • Git is the most widely used version control system. Learn how to use Git and GitHub/GitLab/Bitbucket to manage code.

  • Master the concepts of branches, merges, pull requests, and commits.

3. Get Hands-on with AWS Core Services for DevOps

• Compute and Networking:

  • Learn Amazon EC2, Auto Scaling, and Elastic Load Balancing (ELB) for scaling applications.

  • Familiarize yourself with Amazon VPC, Subnets, NAT Gateways, and Security Groups for networking.

• Storage:

  • Learn Amazon S3 for object storage.

  • Understand Amazon EBS and Amazon EFS for block and file storage.

• Database:

  • Learn Amazon RDS for managed relational databases.

  • Explore Amazon DynamoDB for NoSQL databases.

• Security and Identity:

  • Master IAM (Identity and Access Management) to manage user permissions securely.

  • Learn about AWS KMS (Key Management Service) for managing encryption keys.

• Monitoring and Logging:

  • Understand CloudWatch for monitoring AWS resources.

  • Learn how to use CloudTrail for logging and auditing API activity.

  • Learn about AWS X-Ray for tracing and debugging applications.

4. Learn Infrastructure as Code (IaC)

• AWS CloudFormation:

  • Learn how to automate the creation of AWS resources using CloudFormation.

  • Study how to write and manage CloudFormation templates.

• Terraform:

  • Although not exclusive to AWS, Terraform is widely used for IaC and works across multiple cloud providers.

  • Learn how to create, manage, and provision AWS infrastructure using Terraform.

• Other Tools:

  • Explore AWS CDK (Cloud Development Kit) to define cloud infrastructure using code in languages like Python, TypeScript, and Java.

5. Learn CI/CD Tools & Practices

• Jenkins:

  • Jenkins is a popular tool for automating CI/CD pipelines. Learn how to set up Jenkins servers, create Jenkinsfiles, and integrate with AWS services.

• AWS CodePipeline:

  • AWS provides its own CI/CD service, CodePipeline, which integrates seamlessly with other AWS services like CodeCommit, CodeBuild, and CodeDeploy.

• Docker and Kubernetes:

  • Learn Docker for containerization and understand the principles of building and running containers.

  • Familiarize yourself with Amazon EKS (Elastic Kubernetes Service) to deploy, manage, and scale Kubernetes clusters.

• Other Tools:

  • Get hands-on with other tools like GitLab CI/CD, CircleCI, or Travis CI.

6. Learn Automation and Scripting

• Bash/Shell Scripting:

  • Master the basics of Linux and write automation scripts using Bash or Shell.

• Python/Scripting:

  • Python is widely used for automating tasks and interacting with AWS services using the Boto3 SDK.

• AWS CLI:

  • Learn how to use the AWS Command Line Interface (CLI) for automating tasks and managing AWS resources.

7. Get Familiar with Monitoring & Logging

• AWS CloudWatch:

  • Learn how to monitor and analyze logs and metrics in AWS using CloudWatch.

• ELK Stack (Elasticsearch, Logstash, Kibana):

  • Although this is not AWS-native, it's a widely-used open-source toolset for monitoring and logging.

• AWS X-Ray:

  • Learn to monitor and debug distributed applications running on AWS.

8. Gain Experience with Real-world Projects

• Build a Full DevOps Pipeline:

  • Set up a CI/CD pipeline with GitHub, Jenkins, and AWS (CodePipeline, CodeBuild, CodeDeploy).

• Containerization and Orchestration:

  • Create a Dockerized application and deploy it using Kubernetes on Amazon EKS.

• Infrastructure Automation:

  • Automate the deployment of an entire infrastructure stack with CloudFormation or Terraform.

• Monitoring:

  • Set up monitoring and logging using AWS CloudWatch, CloudTrail, and other tools to ensure system health.

9. Get Certified (Optional but Recommended)

• AWS Certified DevOps Engineer – Professional:

  • This is the most relevant certification for an AWS DevOps engineer. It validates your skills in continuous delivery, automation, monitoring, and security in AWS environments.

  • Preparation: Take online courses, read AWS whitepapers, and review exam guides.

• AWS Certified Solutions Architect – Associate:

  • If you’re new to AWS, this certification can also be helpful as it covers broader AWS concepts.

10. Keep Up with Industry Trends

• Follow AWS Blogs:

  • AWS frequently releases new features, updates, and best practices. Follow the AWS Blog to stay informed.

• Join Communities:

  • Participate in AWS-related forums, Reddit communities, and LinkedIn groups.

  • Attend AWS re:Invent and other conferences to network and stay updated on trends.

• Contribute to Open Source:

  • Contributing to open-source projects related to DevOps can help you learn best practices and gain visibility.

---

Recommended Resources:

• A Cloud Guru / Linux Academy – Offers great hands-on labs and courses tailored for AWS DevOps roles.

• AWS Documentation – AWS’s own documentation is comprehensive and updated regularly.

• Books:

  • “The Phoenix Project” (for DevOps culture)

  • “The DevOps Handbook” (for processes and tools)

  • “Infrastructure as Code” by Kief Morris (for IaC)

Final Thoughts

Becoming an AWS DevOps engineer takes time and dedication. Start by building a strong foundation in AWS and DevOps principles, then get hands-on experience through projects, certifications, and real-world practice. With continuous learning and hands-on experience, you’ll eventually become proficient in automating infrastructure, implementing CI/CD pipelines, and managing scalable, secure applications in the cloud.

Useful AWS DMS Postgres & Oracle SQL Queries

 When working with AWS Database Migration Service (DMS) and migrating between PostgreSQL and Oracle, there are key SQL queries you’ll want to use for monitoring, validating, and troubleshooting. Below is a categorized list of useful SQL queries for both PostgreSQL and Oracle, especially tailored to DMS contexts.

---

🔍 General Categories

1. Schema Comparison

2. Row Count Validation

3. Data Type Check

4. Change Data Capture (CDC) Monitoring

5. Latency and Lag Analysis

6. DMS-specific Tables & Metadata

7. Performance Troubleshooting

---

📘 PostgreSQL Useful Queries

1. List All Tables

SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
  AND table_schema NOT IN ('pg_catalog', 'information_schema');

2. Row Count per Table

SELECT schemaname, relname AS table_name, n_live_tup AS row_count
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

3. Check Table Size

SELECT relname AS table_name,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

4. Check Replication/CDC Lag

If logical replication is enabled:

SELECT pid, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

5. Get Indexes for a Table

SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'your_table';

---

📕 Oracle Useful Queries

1. List All User Tables

SELECT owner, table_name
FROM all_tables
WHERE owner NOT IN ('SYS', 'SYSTEM');

2. Row Count per Table

SELECT owner, table_name, num_rows
FROM all_tables
WHERE owner NOT IN ('SYS', 'SYSTEM');

num_rows is based on stats — use ANALYZE TABLE or DBMS_STATS.GATHER_TABLE_STATS for current counts.

3. Actual Row Count

SELECT COUNT(*) FROM schema_name.table_name;

4. Table Size in MB

SELECT segment_name, segment_type, bytes / (1024*1024) AS size_mb
FROM dba_segments
WHERE segment_type='TABLE' AND owner='YOUR_SCHEMA';

5. Indexes for a Table

SELECT index_name, column_name
FROM all_ind_columns
WHERE table_name = 'YOUR_TABLE';

---

🛠️ DMS Metadata Tables (Query from Target Database)

If DMS is replicating these:

SELECT * FROM awsdms_apply_exceptions;
SELECT * FROM awsdms_heartbeat;

Use these to detect:

• Apply lag

• Last replicated change

• Failed rows or skipped rows

---

✅ Validation Queries

Compare Row Counts (PostgreSQL vs Oracle)

On PostgreSQL:

SELECT COUNT(*) FROM public.my_table;

On Oracle:

SELECT COUNT(*) FROM my_schema.my_table;

You can automate validation using EXCEPT logic or checksum approaches.

---

📈 Monitoring Query Example (DMS Task Monitoring)

Use AWS DMS CloudWatch Logs and ReplicationInstanceMetrics to monitor:

• CDCLatencySource

• CDCLatencyTarget

• FullLoadThroughputRowsSource

• FullLoadThroughputRowsTarget

Blue-Green Deployment for Amazon RDS databases

 

Step-by-Step: Blue-Green Deployment for Amazon RDS

🔹 Use Case

• Safely upgrade schema/engine version.

• Avoid downtime and rollback risks.

• Test changes on an exact replica before promoting.

---

1. Create a Green (Clone) Environment

You have several options depending on your current setup:

Option A: Snapshot and Restore

1. Take a snapshot of your current RDS (Blue).

2. Restore a new DB instance from that snapshot (this becomes Green).

   aws rds create-db-instance \
     --db-instance-identifier green-db \
     --db-snapshot-identifier snapshot-of-blue
   

Option B: Read Replica (for supported engines like MySQL/PostgreSQL)

1. Create a read replica of Blue.

   aws rds create-db-instance-read-replica \
     --db-instance-identifier green-db \
     --source-db-instance-identifier blue-db
   

2. Promote it to a standalone DB instance (optional if testing writes).

   aws rds promote-read-replica \
     --db-instance-identifier green-db
   

---

2. Apply Changes to Green

• Apply schema changes, engine upgrades, or parameter group updates to the Green database.

• Use a test application or staging environment to connect to Green and validate functionality.

---

3. Validate Green

• Run integration and regression tests.

• Monitor performance, query plans, indexes, etc.

• Verify replication (if using a read replica).

• Ensure no application-breaking changes exist.

---

4. Redirect Application to Green

Once Green is validated:

Option A: Update the DB Endpoint

• Update the application/database connection string to point to Green’s endpoint.

• If you’re using Route 53, change the CNAME for the DB hostname.

Option B: Switchover using Route 53

• Use a CNAME (e.g., db.myapp.com) pointing to the current RDS instance.

• Change the CNAME to point to Green DB's endpoint.

---

5. Monitor Green

• Use CloudWatch for RDS metrics (CPU, IOPS, connections).

• Monitor application performance post-switch.

• Optionally keep Blue as backup for rollback.

---

6. Decommission Blue (Optional)

• After confirming stability, delete or snapshot the Blue instance.

  aws rds delete-db-instance \
    --db-instance-identifier blue-db \
    --skip-final-snapshot # or provide --final-db-snapshot-identifier
  

---

🧠 Best Practices

• Enable automated backups on both instances.

• Use parameter groups for environment isolation.

• Use CloudFormation or Terraform for reproducible infrastructure.

AWS RDS Commands

 Here are some commonly used AWS RDS (Relational Database Service) commands using the AWS CLI, along with practical examples for each:

---

🔧 1. Create a New RDS Instance

aws rds create-db-instance \
    --db-instance-identifier mydbinstance \
    --db-instance-class db.t3.micro \
    --engine mysql \
    --master-username admin \
    --master-user-password MySecurePassword123 \
    --allocated-storage 20

📝 Creates a MySQL RDS instance with 20GB of storage.

---

🔍 2. Describe RDS Instances

aws rds describe-db-instances

📝 Lists all your RDS instances and their details.

---

🛑 3. Stop an RDS Instance (only supported for certain instance types)

aws rds stop-db-instance \
    --db-instance-identifier mydbinstance

📝 Stops a running instance to save costs (only for non-multi-AZ).

---

▶️ 4. Start a Stopped RDS Instance

aws rds start-db-instance \
    --db-instance-identifier mydbinstance

📝 Starts an RDS instance previously stopped.

---

🚫 5. Delete an RDS Instance

aws rds delete-db-instance \
    --db-instance-identifier mydbinstance \
    --skip-final-snapshot

📝 Deletes the RDS instance. Use --final-db-snapshot-identifier if you want a backup.

---

💾 6. Create a Snapshot

aws rds create-db-snapshot \
    --db-snapshot-identifier mydbsnapshot \
    --db-instance-identifier mydbinstance

📝 Creates a manual backup (snapshot) of your DB instance.

---

🔁 7. Restore from Snapshot

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier restoredinstance \
    --db-snapshot-identifier mydbsnapshot

📝 Restores a new DB instance from a snapshot.

---

🛡️ 8. Modify DB Instance (e.g., instance class)

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-instance-class db.t3.small \
    --apply-immediately

📝 Changes instance type and applies it immediately.

---

🌐 9. Create a Parameter Group

aws rds create-db-parameter-group \
    --db-parameter-group-name myparamgroup \
    --db-parameter-group-family mysql8.0 \
    --description "My custom params"

📝 Used to customize DB settings, like enabling slow query logs.

---

📄 10. List Snapshots

aws rds describe-db-snapshots

📝 Displays available snapshots you can restore from.

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