Oracle AI Database@Azure: Why It Matters and When to Use It

Oracle Database@Azure was announced by Oracle and Microsoft in September 2023. The picture shows the regions having oracle database@azure.

 We may wonder that we have option of running Oracle database in Azure VM or we can create interconnect (Fast connect + Express Route) between OCI and Azure and the applications in Azure can access the database in OCI, then what is benefit of choosing Oracle database@Azure model. We are going to discuss in detail in this article.

Oracle AI Database@Azure in simple terms, it is a jointly integrated Oracle and Microsoft offering that allows organizations to deploy Oracle database services inside Microsoft Azure data centers. The underlying database infrastructure remains based on Oracle Cloud Infrastructure technologies, but the infrastructure is physically located in Azure facilities. Applications running on services such as Azure Virtual Machines or Azure Kubernetes Service can therefore access Oracle databases through Azure networking rather than treating the database as a remote workload hosted in another public cloud. Unlike Oracle database in Azure VM where oracle is installed and managed manually in Azure environment, Oracle provides its database cloud services on Oracle infrastructure physically deployed inside Azure data centers and integrated with Azure. Some Important features of this model:

· Oracle database infrastructure is colocated in Azure data centers.
· Networking uses Azure Virtual Network.
· Azure identity and authorization mechanisms participate in service access.
· Database metrics, logs, events, and telemetry can be surfaced within Azure.
· Oracle operates and maintains the underlying Oracle infrastructure.
· Azure portal, APIs, SDKs, and Terraform can be used for many provisioning and management activities.

The above features make Oracle AI Database@Azure fundamentally different from installing Oracle Database software on a standard Azure VM.

In the Interconnect model, the connection between OCI and Azure is created and managed by users. But in the Oracle database@azure, the higher bandwidth connectivity is in-built.

	Oracle Database on Azure VM	Oracle AI Database@Azure	Oracle Database in OCI + Azure Interconnect
Oracle Database Location	Azure VM	On OCI database infrastructure colocated inside Azure datacenters	In an OCI region
Cloud model	Azure IaaS	Oracle DBaaS integrated into Azure	Azure + OCI
Infrastructure owner	Microsoft provides VM infrastructure	Oracle operates OCI database infrastructure inside Azure	Oracle operates OCI infrastructure in OCI
Patching	Customer handles OS/DB patching	Oracle handles infrastructure patching; DB patching varies by service	Oracle handles cloud infrastructure; DB patching varies by OCI service
Network	Native Azure networking	Private Azure-integrated connectivity	Azure ExpressRoute + OCI FastConnect
Latency between Azure app and DB	Azure-local	Very low latency; DB infrastructure colocated in Azure	Low latency, but traffic crosses Azur and OCI private interconnect
Cross-cloud network required	No	No traditional Azure-to-OCI interconnect needed for DB access	Yes
Exadata & Autonomous database	No	Yes	Yes, if using Exadata & Autonomous database in OCI
RAC availability	No	Available	Available with supported OCI database services.
Performance model	Depends on Azure VM + storage sizing	Oracle engineered infrastructure, especially Exadata	Oracle OCI database infrastructure
Billing	Azure compute/storage/network billing and Oracle database licensing separately	Purchased through Azure Marketplace and billing appear in Azure portal.	OCI DB billing + Azure services billing separately
Operational complexity	customer-managed	Lowest of the three for Azure centric Oracle DBaaS	Higher because two clouds, routing, identity and operations must be coordinated
Monitoring	Customer configures monitoring	Native Azure Monitor integration is supported	Requires integration, export & configuration across clouds
Best Fit	Lift-and-shift, Development and Testing, smaller/custom Oracle environments	Mission-critical Oracle workloads closely integrated with Azure	Existing OCI estate or workloads that need OCI services while applications stay in Azure

 Database@Azure becomes much more compelling when requirements have the below.

·       Mission critical Oracle Database: We will get fully managed Oracle hardware sitting right inside Azure data centers, giving us top tier speed and reliability without needing a hybrid setup.

·       Very high DB performance: The co-located hardware delivers low-latency, high-speed performance for demanding, data-heavy applications.

·       Exadata: Oracle database@azure provides Oracle Exadata Database Service to handle massive compute and storage demands effortlessly.

·       RAC: It is an Instance HA option. Oracle RAC distributes workloads across multiple server instances so the app stays online even if a server fails.

·       Data Guard: Oracle Data Guard keeps standby databases synced in real time to protect against outages and data loss.

·       Autonomous Database: Oracle Autonomous Database for handling routine work like provisioning, patching, scaling, and tuning automatically.

·       Oracle AI Database 26ai: The latest database version with AI features enabled which let us run vector searches and AI workloads directly alongside our existing enterprise data.

·       Azure applications + Oracle DB: Azure VMs, microservices on AKS and custom apps connect directly to Oracle databases over private, low-latency links.

·       Microsoft Fabric / AI integration: Integrate our Oracle data straight into Microsoft Fabric and Azure AI services for analytics and reporting.

·       Enterprise Oracle workload: Easily powers critical ERP, financial, and transactional systems right inside an Azure-based setup.

·       Low operational overhead: Oracle takes care of the underlying hardware and infrastructure management, freeing up our internal IT team.

 

 From Multi-Cloud Research to Practice: Optimizing Oracle Workload Placement Across OCI and Azure

Multi-cloud architecture is becoming a practical reality for many enterprises. Organizations are no longer deciding only which cloud provider to use. They are increasingly deciding where a particular workload should run based on business, technical, operational, and financial requirements.

This is especially relevant for organizations using both Oracle Cloud Infrastructure (OCI) and Microsoft Azure.

An Oracle workload may continue to run in OCI while the application tier runs in Azure. In other cases, Oracle AI Database@Azure may provide an opportunity to bring Oracle database services closer to Azure-hosted applications.

This creates an important architecture question: How do we determine the right placement for an Oracle workload across OCI and Azure?

The answer usually involves more than cost alone.

The workload-placement challenge

Consider an enterprise with several Oracle workloads. One database may support applications primarily running in OCI. Another may serve an application tier hosted in Azure. A third may support analytics or AI workloads where most consumers are already in Azure. Although all three use Oracle technology, their optimal placement may be different.

A practical workload-placement decision may need to consider:

• Cost
• Application-to-database latency
• Data location and data gravity
• Migration complexity
• Availability and resilience
• Licensing
• Security and compliance
• Regional requirements
• Existing OCI or Azure dependencies
• Operational integration

The goal is therefore not simply: “Which cloud is cheaper?”

A better question is: Which placement provides the best overall value for this workload while satisfying enterprise requirements?

A practical OCI and Azure scenario

Assume an enterprise has a business-critical application whose application tier runs in Azure while its Oracle database remains in OCI. The current architecture may look like:

Azure Application -> Private Connectivity -> Oracle Database in OCI

This architecture may already work well. The organization may have established OCI networking, backup and recovery processes, monitoring, integrations, and operational expertise. However, as more application components move into Azure, the enterprise may also consider:

Azure Application -> Azure Virtual Network -> Oracle AI Database@Azure

The second architecture may improve proximity between the Azure application and the Oracle database and may align better with Azure-based monitoring, networking, and operational processes. But that does not automatically make it the better choice.

The right answer depends on the workload.

Scenario 1: Retain the workload in OCI

Keeping the database in OCI may make sense when:

• OCI dependencies are significant
• Existing backup and disaster recovery processes are mature
• Current application latency is acceptable
• Migration effort is high
• Moving the database provides limited additional business value

In this case, migration complexity may outweigh the potential benefit of moving the workload.

Scenario 2: Consider Oracle AI Database@Azure

Oracle AI Database@Azure may be worth evaluating when:

• The application tier is already in Azure
• Most data consumers are in Azure
• Application-to-database latency is important
• OCI-specific dependencies are limited
• Azure operational integration is preferred

Here, application proximity and Azure integration may justify the migration effort. The objective is not to prove that OCI or Azure is better. It is to determine which placement is more appropriate for the individual workload.

A practical workload-placement model

Rather than treating every factor as equal, enterprises can separate them into two categories.

Mandatory requirements

Some requirements should act as constraints rather than preferences.

Examples include:

• Approved cloud regions
• Data residency
• Security requirements
• Licensing restrictions
• Minimum availability
• Architecture compatibility

If a candidate placement violates one of these requirements, it should be removed from consideration.

Optimization factors

Once invalid choices are eliminated, the remaining options can be evaluated using factors such as:

Cost: Infrastructure, licensing, network charges, and operational expenses.

Latency: The impact of application and database proximity on performance.

Data gravity: Where the majority of data is generated, consumed, or integrated.

Migration effort: Data movement, testing, downtime, cutover planning, and operational change.

Cloud dependencies: The level of dependency on OCI-native or Azure-native services.

The relative importance of these factors can vary by workload.

A simple decision framework

A practical placement process can follow four steps.

1. Understand the workload

Collect the most important workload characteristics:

• Current placement
• CPU and memory requirements
• Utilization
• Application dependencies
• Data location
• Availability requirements
• Cost
• Migration complexity

2. Identify valid placement options

Remove placements that violate mandatory requirements such as security, licensing, region, availability, or architectural compatibility.

3. Produce an explainable recommendation

A recommendation should explain why a placement is preferred. The explanation makes the decision easier to review across architecture, application, security, and FinOps teams.

Where automation can help

For a small number of workloads, this analysis can be performed manually. At enterprise scale, it becomes much harder. A placement advisor could collect information from both platforms.

From Azure:

• Resource inventory
• Azure Monitor
• Cost information
• Application dependencies

From OCI:

• Resource inventory
• OCI Monitoring
• Cost and usage information
• Oracle database metadata

The information can then be normalized into a common workload view and used to generate recommendations.

Key Factors:
- Application tier runs in Azure
- Latency sensitivity is high
- Azure integration is preferred
- Regional requirements are satisfied

 Main Trade-off:
- Database migration and testing effort

The final decision should still remain with architects and application owners. Automation should support architecture decisions, not replace governance.

This workload-placement problem is related to the broader multi-cloud optimization research we explored through: MC-SPARK: A Policy-Constrained Genetic Algorithm for Multi-Cloud Workload Placement

The research examines multi-cloud placement as an optimization problem involving multiple technical and business factors. This article takes that broader idea and applies it to a practical Oracle and Microsoft Azure architecture scenario. The OCI and Azure examples discussed here are separate practical interpretations and are not part of the original experimental evaluation.

 Multi-cloud should not mean moving workloads between platforms simply because multiple clouds are available. The real value comes from understanding where each workload fits best.

For Oracle customers using OCI and Azure, workload-placement decisions should consider more than infrastructure cost. Application proximity, data gravity, migration effort, security, availability, cloud dependencies, and operational requirements all contribute to the final architecture decision. The objective is not to select one cloud for every workload. It is to make a workload-specific placement decision that provides the best overall business and technical value.

 

 

OCI Enterprise AI Agents

OCI has introduced Enterprise AI Agents in OCI Generative AI as a managed way to build, run, and host agentic applications. Generative AI adoption is moving from simple prompt based experimentation to enterprise ready AI assistants that can answer questions using approved business knowledge. In this article we are going to create a knowledge base using business documents and then create OCI Gen AI agents followed by a chatbot. Here we achieve in getting answers from our own documents, policies, architecture notes, runbooks and internal knowledge. The goal of this article is to show how OCI can be used to build a governed enterprise knowledge assistant without writing application code.

1)     Create OCI Object storage bucket

2)     Upload the documents into Object storage bucket

3)     Create a Knowledge base

4)     Create an Agent

6)     Create a RAG tool

7)     Launch Chat and Query.

The assistant will use a set of documents uploaded into OCI Object Storage. These documents are added to a knowledge base. The knowledge base is then connected to an OCI Generative AI Agent through a RAG tool. When we raise prompt in chat, the agent retrieves relevant information from the knowledge base and generates a response using the selected LLM.

Create OCI Object storage bucket

In OCI Console:

Navigation menu → Storage → Object Storage & Archive Storage → Buckets

Create the bucket with default settings.

Once bucket is created, Upload documents to Object storage. These documents may be PDFs, text files, architecture notes, or other supported file types. The documents stored in the bucket become the source content for the knowledge base.

 

 

Create a Knowledge Base

As the next step create a Knowledge Base, in OCI Console:

Navigation menu → Analytics & AI → Generative AI Agents

A knowledge base is the collection of source data that the agent can use for retrieval. In this article, the knowledge base points to the documents stored in OCI Object Storage. The knowledge base does not answer questions directly. Instead, it provides the searchable enterprise context that the RAG tool can retrieve from when the user asks a question.

In the OCI console, we could see three options that we discussed earlier. As first step, create a Knowledge base and then Agents using that Knowledge base and then initiate Chat.

 

For Knowledge base creation specify the Bucket having the documents.

Either all documents in the bucket can be chosen or any specific documents.

Once documents are chosen click Create button to create the knowledge base.

 

 

The knowledge base creation will take few minutes to complete. We need to be patient. We can’t alter or delete the creation until it completes.

Once Knowledge Base is created move to creating Agent.

Create Agent

An agent is the main reasoning layer. It receives our prompts and decides how to use the available tool and generates the final response. The agent can be guided using routing instructions so that it responds in a specific style and follows enterprise rules.

 

 

To create Agent, specify Name and then Routing instructions. Instructions required to specify how to respond to chat prompts. In this article, we instruct the agent to answer only from the knowledge base, avoid guessing, provide concise responses, and escalate security or production-impacting decisions to a human owner.

In this exercise we choose detail Routing LLM type Llama.

 

After Basic information, the next step is Add RAG tool. A RAG tool allows the agent to search the knowledge base, retrieve relevant content and then use that retrieved content to generate a better answer. This is important because it helps the agent answer based on approved documents instead of relying only on the model’s general knowledge.

We need to specify name and Routing description. The description specifies how the tool should work with documents.

In the Add Tool we go with Default LLM (Llama)

 

The next step is setting up Agent endpoint. An agent endpoint is the access point used to interact with the deployed agent. Once the agent and its tools are configured, the endpoint allows users or applications to send questions to the agent. Guardrails are safety and compliance controls for the AI interaction. They help reduce risk by applying checks such as content moderation, prompt injection protection, and personally identifiable information protection. We will go with default settings for Guardrails.

 

Lets review the inputs and create agent.

Chat

Agent is ready, the next step is initiating chat.

Choose the created Agent and Endpoint.

Submit the prompts in chatbox and observe the chatbox responses.

 Automatically Start or Stop an OCI Compute Instance Using OCI Resource Scheduler

In cloud environments, compute instances are often created for development, testing, learning, troubleshooting, and temporary workloads. These instances may not be required to run all the time. If they continue running when not needed, they can increase unnecessary compute usage.

Oracle Cloud Infrastructure (OCI) provides Resource Scheduler, which helps automatically start and stop supported OCI resources based on a schedule. This can help reduce the cost of compute and database resources by stopping them when they are not required and restarting them when they are needed again.  In this article, we will create an OCI Resource Scheduler schedule to automatically stop a compute instance. We will then validate that the instance state changes based on the configured schedule.

We will use below OCI services in this article :

OCI Compute
OCI Resource Scheduler
IAM Policy

Resource Scheduler creates an automated start/stop scheduling function for supported resources across a tenancy based on the schedules created.

Prerequisites

Before starting this activity, the following items should be available:

OCI tenancy access
Required compartment
Running compute instance
Permission to create Resource Scheduler schedule
Permission for Resource Scheduler to manage the target compute instance

For this article, we will use an existing compute instance and create a schedule to stop it automatically.

Resource Scheduler needs permission to perform actions on the selected resources. If the required policy is not available, schedule creation or execution may fail. The policy requirement depends on the target resource and compartment.

A policy can be created based on the access model used in the tenancy. Below policies are required for resource scheduler.

Allow <Group> to inspect resource-schedule in tenancy

Allow any-user to manage <resource_type (instance, database, and others)> in compartment id <target_compartment_ocid> where all {request.principal.type='resourceschedule',request.principal.id='ocid_of_resourceschedule'}

 Step 1: Review the Compute Instance

First, review the compute instance that will be used for testing.

From the OCI Console, navigate to:

Compute → Instances

Open the target compute instance and confirm that the instance is in Running state.

Example instance name:

private-linux-instance

For our exercise we will configure Resource scheduler to automatically stop this running instance.

Step 2: Open Resource Scheduler

From the OCI Console, navigate to Resource Scheduler.
Governance & Administration -> Resource scheduler

Open the Schedules page and select Create schedule.

Step 3: Create Schedule

Provide a meaningful schedule name.

Example:

stop-compute-instance-schedule

Add a description.

Example:

Automatically stop the demo compute instance for testing Resource Scheduler.

Select the compartment where the schedule should be created.

Step 4: Select Schedule Action

In the schedule action section, choose the action that should be performed.

For this article, select:

Action: Stop
Resource Type: Compute Instance

This tells Resource Scheduler to stop the selected compute instance when the schedule runs.

If the requirement is to start a stopped instance, a separate schedule can be created with the Start action.

Step 5: Select Target Compute Instance

In the target resource section, select the compute instance that should be stopped.

Example target resource:

private-linux-instance

Validate that the correct compartment, region, and resource are selected. You can see Autonomous database in the screenshot. This tenancy autonomous database as well and it can he scheduled through Resource scheduler.

It is important to choose the correct instance because the schedule will perform the selected action on the target resource.

The next step is about Apply Parameters.

That Apply parameters page is mainly used when the scheduled resource/action needs an additional input payload. For Start or Stop an OCI Compute Instance, normally no JSON body is required. Resource Scheduler can start or stop the selected compute instance based on the action and resource selected in the previous steps.

Step 6: Configure Schedule Time

Now configure the schedule time.

For quick validation, select a time a few minutes ahead of the current time.

Example:

Current time: 5:43 PM
Schedule action: Stop
Schedule time: 5:46 PM

This allows us to validate the schedule execution quickly.

Depending on the console options, the schedule can be configured as a one-time schedule or recurring schedule. For a blog validation, a one-time schedule is easier to test and explain.

Step 7: Review and Create Schedule

Review the complete schedule configuration.

Validate the following details:

Schedule name
Action
Target compute instance
Schedule time

After confirming the details, create the schedule. The schedule should appear in the Resource Scheduler schedules list.

Step 8: Wait for Schedule Execution

After the schedule is created, wait until the configured schedule time is reached. Before the schedule execution, the compute instance should still be in:

Running

After the schedule runs, Resource Scheduler should initiate the stop operation.The instance state should change from: Running to Stopping and then Stopped.

Step 9: Validate Compute Instance State

After the scheduled time passes, open the compute instance details page again.

Validate that the instance state changed to:

Stopped

This confirms that Resource Scheduler successfully stopped the compute instance automatically.

Step 10: Review Schedule Status

Open the Resource Scheduler schedule details page and review the work requests page.

This helps confirm that the schedule was executed.

OCI Resource Scheduler provides a simple way to automate start and stop operations for supported resources. This is useful for development, testing, and lab environments where compute instances do not need to run continuously. It helps reduce manual effort and supports basic cost optimization without custom scripts or external automation tools.