raulrgmx/oci-deal-accelerator
1
0
Fork 0
forked from diegoecab/oci-deal-accelerator
Code Pull Requests Activity
Files
6aea208129d5fcb4e1ba693feba59b9d618924d5
oci-deal-accelerator/kb/diagram/assets/archcenter-refs/phased-migration-to-oracle-dba/_description.md
root b30a4f0d32 Diagram generation: ref-arch-driven procedure + spec validator + KB enrichment 
The diagram path now follows a documented standard procedure (lookup
the closest Oracle Architecture Center reference → confirm components
→ author absolute_layout → spec validator → render → visually verify)
and ships persistent guardrails so layout regressions can't recur.

Persistent procedure changes (apply to all users, all sessions):
- tools/diagram_spec_validator.py — geometry checks (CONTAINER_TOO_THIN,
  CONTAINER_PADDING_VIOLATION, LABEL_OVERFLOW_PARENT) run BEFORE either
  renderer (drawio + PPTX). Catches the subnet-collapse / label-overflow
  bugs that the post-render drawio validator missed.
- tools/oci_diagram_gen.py + tools/oci_pptx_diagram_gen.py — call the
  spec validator before emitting any output. Adds mysql / mysql_heatwave
  type aliases.
- tools/archcenter_pattern_lookup.py — scores against cached page
  descriptions (not just the 1-line summary), supports --queries for
  multi-fragment composition, and applies synonym expansion via
  kb/architecture-center/synonyms.yaml so "LB HA cross AD" matches
  "load balancer high availability availability domain".
- kb/architecture-center/synonyms.yaml — canonical synonym table
  (load balancer, autonomous database, data guard, …) used by the
  lookup scorer.

KB enrichment:
- tools/archcenter_description_fetcher.py + 121 cached _description.md
  under kb/diagram/assets/archcenter-refs/<slug>/. Removes the runtime
  dependency on docs.oracle.com when authoring specs and feeds the
  pattern-lookup scorer.
- 110+ cached .drawio / .svg / .png references for offline reuse,
  plus the OCI Toolkit v24.2 import (kb/diagram/assets/oci-toolkit-drawio).

Documentation:
- docs/skill/output-formats.md — new "Standard diagram-generation
  procedure (MANDATORY)" + geometry rules + the new validator entry.
- SKILL.md option 2 — references the mandatory procedure.
- README.md — describes the spec validator, archcenter_pattern_lookup
  and description fetcher, and updates the KB-health table.

Tooling that backs the procedure (cumulative across recent sessions):
tools/archcenter_case_runner.py, archcenter_batch_driver.py,
archcenter_zip_downloader.py, drawio_visual_validator.py,
drawio_fidelity_eval.py, harvest_drawio_icon.py, import_oci_library.py,
oci_pptx_diagram_gen.py, oci_pptx_render.py, refresh_pptx_icon_index.py.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 21:15:21 -03:00

8.4 KiB
Raw Blame History

Migrate business critical applications to Oracle Database@Azure using a phased strategy

Summary (catalog)

Phased migration to Database@Azure. Leverages OCI networking for DR replication with low-latency, high-bandwidth connectivity. Integrates Autonomous Recovery Service with Data Guard for data protection.

Architecture (fetched from source)

Architecture

This architecture outlines a phased approach for migrating on-premises Oracle Database onto Oracle Exadata Database Service at Oracle Database@Azure with minimal downtime.

To simplify this strategy, we break it down into three key aspects: current state, future state, and migration phases.

This reference architecture has four primary components (marked with blue numbers in diagram).

Number Component Description

1 On-premises primary data center Hosts the database and application as the primary system before migration.

2 On-premises standby data center Maintains a standby system, replicating the on-premises primary database.

3 Azure primary region Runs the application and database on Oracle Database@Azure , becoming the primary system post-migration.

4 Azure standby region A disaster recovery site replicating the primary region using Oracle Data Guard .

Description of the illustration logical-architecture-diagram.png

logical-architecture-diagram-oracle.zip

Current state

In the existing setup, both the primary data center (1) and standby data center (2) are hosted on-premises, supporting application workloads and databases. The primary data center handles all requests, while the standby data center maintains asynchronous replication using Oracle Data Guard . This ensures high availability, with the standby system ready for failover in case of unexpected failures.

Future state

The future architecture mirrors the current setup but is fully hosted in the cloud, spanning two Azure regions: the primary region (3) and the standby region (4). The database is migrated to Oracle Database@Azure Exadata services, with asynchronous replication between the primary and standby databases managed via Oracle Data Guard over the Oracle Cloud Infrastructure (OCI) network.

For secure connectivity between the on-premises data center and Azure , an Azure Firewall is deployed within a secure Virtual WAN (vWAN) Hub in Azure .

Migration phases

The migration follows a two-phase approach to ensure a controlled and reliable transition.

Phase 1 – Transitioning on-premises standby to Azure and switchover

In this phase, the on-premises standby system (2) is migrated to Azure (3). Once completed, the primary (1) and standby (3) roles are swapped, making Azure the new primary region.

  • Establish connectivity between on-premises and Azure using Azure ExpressRoute .

  • Configure Azure secure hub, Azure Firewall, and vWAN for security (if not already in place).

  • Provision Oracle Exadata Cloud Infrastructure in Azure ’s primary region, then:

  • Set up an Oracle Exadata virtual machine (VM) cluster and create the target database.

  • Enable archive logs and forced logging on the primary database (if not already enabled).

  • Configure Oracle Net for listener and TNS names for discovery.

  • Restore from service to set up a standby database in Azure ’s primary region (3).

  • Perform a switchover, making the Azure database (3) the new primary.

  • Migrate applications to the Azure primary region (3) and update DNS routes.

  • Verify the Data Guard configuration and monitor the replication status.

Phase 2 – Establishing standby in Azure and decommissioning on-premises

In this phase, a standby system (4) is set up in Azure , and on-premises resources (1 and 2) are decommissioned.

  • Provision Oracle Exadata Cloud Infrastructure in the standby region (4) with Oracle Database@Azure .

  • Set up an Oracle Exadata VM cluster and create the standby database.

  • Enable Oracle Data Guard to associate the primary region database (3) with the standby database (4).

  • Use OCI networking for high-throughput replication, leveraging local and remote peering within a hub-and-spoke topology between the primary and standby databases.

  • Migrate application workloads to the Azure standby region (4).

  • Stop the synchronization with the on-premises resources and then decommission the on-premises application and database resources from the primary (1) and standby (2) data centers.

The following diagram illustrates this reference architecture.

Description of the illustration physical-architecture-diagram.png

physical-architecture-diagram-oracle.zip

Microsoft Azure provides the following components:

  • Azure Region An Azure region is a geographical area in which one or more physical Azure data centers, called availability zones, reside. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

Azure and OCI regions are localized geographic areas. For Oracle Database@Azure , an Azure region is connected to an OCI region, with availability zones (AZs) in Azure connected to availability domains (ADs) in OCI. Azure and OCI region pairs are selected to minimize distance and latency.

  • Azure Availability Zone Azure availability zones are physically separate locations within an Azure region, designed to ensure high availability and resiliency by providing independent power, cooling, and networking.

  • Azure VNet Microsoft Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure virtual machines (VM), to securely communicate with each other, the internet, and on-premises networks.

  • Azure Delegated Subnet Subnet delegation is Microsoft's ability to inject a managed service, specifically a platform-as-a-service (PaaS) service, directly into your virtual network. This allows you to designate or delegate a subnet to be a home for an external managed service inside of your virtual network, such that external service acts as a virtual network resource, even though it is an external PaaS service.

  • Azure VNIC The services in Azure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during launch and is available during the instance's lifetime.

  • Azure Virtual Network Gateway Azure Virtual Network Gateway establishes secure, cross-premises connectivity between an Azure virtual network and an on-premises network. It allows you to create a hybrid network that spans your data center and Azure.

  • Azure Virtual WAN Microsoft Azure Virtual WAN (VWAN) is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface.

  • Azure Secure Hub An Azure secure hub, also known as a secured virtual hub, is an Azure Virtual WAN hub enhanced with security and routing policies managed by Azure Firewall Manager. It simplifies the creation of hub-and-spoke and transitive network architectures by integrating native security services for traffic governance and protection. This setup automates traffic routing, eliminating the need for user-defined routes (UDRs). Organizations can use a secure hub to filter and secure traffic between virtual networks, branch offices, and the internet, ensuring robust security and streamlined network management.

  • Azure Firewall Manager Azure Firewall Manager is a centralized security management service that simplifies the deployment and configuration of Azure Firewall across multiple regions and subscriptions. It allows for hierarchical policy management, enabling global and local firewall policies to be applied consistently. When integrated with Azure Virtual WAN (vWAN) and a secure hub, Azure Firewall Manager enhances security by automating traffic routing and filtering without the need for user-defined routes (UDRs). This integration ensures that tr

View Git Blame Copy Permalink