Monitoring Oracle Database@Azure
Monitoring Oracle Database@Azure
Article Overview
Monitoring a database that spans two clouds is a genuinely new problem: the Oracle database runs on Exadata operated by Oracle, while everything around it — the application tier, identity, networking — lives in Azure. Watch only one side and you are blind to half of every incident. This guide lays out a layered observability model that gives you a single operational picture without giving up depth on either side: the native Azure Monitor integration that streams Exadata metrics, logs, and events into Azure; diagnostic settings and Log Analytics with the KQL to query them; Oracle Enterprise Manager and OCI Database Management for deep database and SQL insight; and how to bring it together into unified dashboards and alerting. It is written to be practical — the configuration steps, the queries, and the dashboard layouts you actually need.
A note on the dashboard images in this article
The dashboard visuals below are illustrative mockups — hand-drawn representations of the kind of layout and panels you would build, not screenshots of a live tenancy. They are included to show structure and intent; your real dashboards will differ in exact metrics, styling, and values. Treat them as wireframes to build toward, not literal captures.
1.The Two-Cloud Monitoring Problem
Every monitoring strategy for Oracle Database@Azure has to answer one awkward question first: where do you watch from? The database runs on Exadata infrastructure that Oracle operates; the application tier, the network, and the identity layer run in Azure. An incident almost never respects that boundary — a slow checkout is a chain that runs from an Azure app VM, across the network, into the Oracle database, and back. If your monitoring only sees one side of that line, every cross-boundary incident becomes a guessing game.
For a long time the honest answer was "you watch from two places and try to correlate by hand." That changed materially in 2025, when Oracle and Microsoft introduced native Azure Monitor integration for Exadata infrastructure and VM clusters, letting Exadata logs, events, and metrics flow directly into Azure Monitor. For the first time you could build a genuinely unified dashboard combining Azure service telemetry with Oracle database operational data — moving from siloed visibility to a connected, end-to-end view.
An incident does not respect the boundary between Oracle's Exadata and your Azure estate. Your monitoring cannot either — or every cross-cloud problem becomes a game of "which team's dashboard is lying?"
Depth on both sides, one picture
The goal is not to collapse everything into Azure and lose Oracle's native depth, nor to keep two disconnected worlds. It is to have one correlated operational picture and retain the deep, Oracle-native diagnostics when you need to drill into a database or a SQL statement. The layered model in the next section is how you get both at once.
2.A Layered Observability Model
The clean way to think about monitoring this platform is in layers, each answering a different question and served by a different tool. Get the layers straight and every tool has an obvious place; skip the model and you end up with overlapping dashboards that all show slightly different numbers.
| Layer | Answers | Primary tools |
|---|---|---|
| 3 · Correlation | Is the end-to-end service healthy? Where is the problem? | Azure Monitor, Workbooks, Log Analytics, Sentinel, Alerts |
| 2 · Database depth | Why is the database slow — wait, SQL, plan? | Oracle Enterprise Manager, OCI Database Management, Ops Insights |
| 1 · Infrastructure | Are nodes, storage, network, and app VMs healthy? | Azure Arc, Exadata metrics in Azure Monitor, VM metrics |
Watch from the top, drill to the depth
Day to day, you live in Layer 3 — the unified view that tells you whether the service is healthy and, when it is not, roughly where. You drop into Layer 2's Oracle-native depth only when the top layer points you at the database, and into Layer 1 when it points you at infrastructure. Trying to watch all three layers all the time is how monitoring becomes noise; watch the top and let it route you.
3.Native Azure Monitor Integration
The foundation of the whole model is the native integration that lets Exadata observability data reach Azure. Rather than bolting on a third-party collector, Oracle Database@Azure provides a mechanism within Azure to monitor the Exadata Database Service, with Azure responsible for collecting and storing the observability data. Two kinds of data flow: metrics and logs/events.
3.1 Where the metrics show up
Metrics for a provisioned Exadata VM cluster appear directly in the Azure portal under the cluster's Monitoring section — no extra plumbing for the basic set. The path is exactly what an Azure engineer expects:
Azure portal
→ Oracle Exadata Database Service resource blade
→ Oracle Exadata VM Cluster (select an available cluster)
→ Monitoring → Metrics
→ supported metrics for the VM cluster are listed here
# Metrics are published from OCI under these metric namespaces:
# oracle_oci_database
# oci_database
# oci_database_cluster
#
# Caveat: a metric that exists in those OCI namespaces but is NOT in
# the published Exadata@Azure set will not appear in Azure — know the
# supported list, and use OCI-native tooling for anything beyond it.3.2 What flows, and what does not
| Data | Reaches Azure Monitor? |
|---|---|
| Exadata VM cluster metrics (supported set) | Yes — natively in the cluster's Monitoring blade |
| Exadata infrastructure logs and events | Yes — via diagnostic settings (next section) |
| Database logs, Data Guard logs | Yes — via diagnostic settings to Log Analytics |
| OCI metrics outside the published set | No — use OCI Database Management / OEM for these |
| Deep SQL-level diagnostics (AWR/ASH detail) | Not through Azure Monitor — Oracle-native tools own this depth |
⚠️ Native integration is broad, not bottomless
The native path gives you excellent infrastructure and operational coverage in Azure — enough to run day-to-day operations from the Azure side. But it deliberately does not replace Oracle's deep database diagnostics. If you try to do SQL-level tuning from Azure Monitor alone you will hit its edge quickly. Know where the native set ends and the Oracle-native depth begins, and route accordingly — that boundary is a feature of the model, not a gap in it.
4.Diagnostic Settings and Log Routing
Metrics arrive with little setup; logs and events need one deliberate configuration step — diagnostic settings — which is where you tell the platform what to collect and where to send it. This is the single most important piece of monitoring plumbing to get right, because everything in the correlation layer depends on the logs landing somewhere queryable.
4.1 The four supported log categories
Diagnostic settings for Oracle Database@Azure can capture four categories of log, each answering a different operational question:
VM cluster lifecycle logs
Records lifecycle-management operations on the Exadata VM cluster — scaling, patching, and configuration changes. Your audit trail of what changed on the cluster and when.
Database logs
Operational logs from the databases themselves — the day-to-day record of database activity and events surfaced to the platform.
Infrastructure logs
Logs from the underlying Exadata infrastructure — the substrate health and events beneath the databases.
Data Guard logs
Logs from the Data Guard configuration — essential for watching standby health, apply lag, and role transitions on a protected database.
4.2 Three routing destinations
Diagnostic settings can send those logs to any of three destinations, and the right choice depends on what you are doing with the data:
| Destination | Use it for |
|---|---|
| Log Analytics workspace | Interactive analysis and correlation with KQL — the primary destination for observability |
| Event Hub | Streaming logs out to a SIEM or a third-party observability platform in real time |
| Storage Account | Cheap long-term archival and compliance retention of raw logs |
4.3 Configuring it
You can create diagnostic settings in the portal, or as code. Here is the shape with the Azure CLI — sending all four log categories to a Log Analytics workspace.
# Route Exadata VM cluster logs to a Log Analytics workspace.
# Replace the resource IDs with your own; category names must match
# the platform's current supported list.
az monitor diagnostic-settings create \
--name "odaa-to-loganalytics" \
--resource "$EXADATA_VMCLUSTER_RESOURCE_ID" \
--workspace "$LOG_ANALYTICS_WORKSPACE_ID" \
--logs '[
{"category": "VMClusterLifecycleManagement", "enabled": true},
{"category": "DatabaseLogs", "enabled": true},
{"category": "InfrastructureLogs", "enabled": true},
{"category": "DataGuardLogs", "enabled": true}
]'
# Verify it is emitting:
az monitor diagnostic-settings list \
--resource "$EXADATA_VMCLUSTER_RESOURCE_ID" -o tableTurn diagnostic settings on first — logs are not retroactive
The most common regret in cloud monitoring is discovering during an incident that the logs you need were never being collected. Diagnostic settings are not retroactive — they capture from the moment they are enabled forward. Configure them as part of provisioning, before go-live, so that when the first incident comes you already have the history to investigate it. Enabling them afterward only helps the next incident.
5.Querying Logs With KQL
Once the logs land in a Log Analytics workspace, Kusto Query Language (KQL) is how you interrogate them. This is where an Azure-native team feels at home and an Oracle-native team gains a powerful new skill. A handful of query patterns cover most of what you need day to day.
5.1 See what is actually arriving
The first query on any new workspace is a census — what log tables exist and how much is flowing. It confirms your diagnostic settings are working and shows you the shape of the data.
// What Oracle Database@Azure log data has arrived in the last 24h?
search *
| where TimeGenerated > ago(24h)
| where Type startswith "OracleDatabase" or Type contains "Exadata"
| summarize Records = count() by Type
| sort by Records desc5.2 Find errors and warnings across the platform
// Recent error/warning-level entries across Exadata logs, newest first.
// Adjust the table name to your actual ingested log type.
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(6h)
| where Severity in ("ERROR", "CRITICAL", "WARNING")
| project TimeGenerated, Resource, Category, Severity, Message
| sort by TimeGenerated desc
| take 1005.3 Watch Data Guard apply lag
For a database protected by Data Guard, apply lag is one of the most important things to watch — it is your real recovery-point exposure. With Data Guard logs in the workspace, you can trend it and alert on it.
// Trend Data Guard apply lag over the last 12 hours from Data Guard logs.
// Parse the lag value out of the log message per your log format.
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(12h)
| where Category == "DataGuardLogs"
| where Message has "apply lag"
| extend LagSeconds = toint(extract(@"apply lag[:\s]+(\d+)", 1, Message))
| summarize MaxLag = max(LagSeconds), AvgLag = avg(LagSeconds)
by bin(TimeGenerated, 15m)
| render timechart5.4 Correlate a database event with the app tier
The payoff of unified logging: join a database-side event to app-tier telemetry in one query, to see whether a database blip lines up with an application error spike — the correlation that used to take two teams and a bridge call.
// Do database errors line up in time with app-tier VM errors?
let dbErrors =
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(3h) and Severity == "ERROR"
| summarize DbErrors = count() by bin(TimeGenerated, 5m);
let appErrors =
Syslog // app-tier VMs via Azure Monitor Agent
| where TimeGenerated > ago(3h) and SeverityLevel == "err"
| summarize AppErrors = count() by bin(TimeGenerated, 5m);
dbErrors
| join kind=fullouter appErrors on TimeGenerated
| project TimeGenerated, DbErrors, AppErrors
| sort by TimeGenerated asc
| render timechartKQL is the lingua franca of the correlation layer
Every table name and field above depends on how your logs are ingested, so treat these as patterns to adapt rather than copy-paste queries. The important idea is that once Oracle logs and Azure logs share one workspace, KQL becomes the common language that lets you ask questions spanning both worlds — which is the entire point of routing them to the same place.
6.Metrics and Azure Dashboards
Logs tell you what happened; metrics tell you how the system is trending. With Exadata metrics flowing into Azure Monitor, you can chart them alongside app-tier and infrastructure metrics and pin the result to an Azure dashboard — the at-a-glance health view your operations team keeps open.
6.1 An illustrative metrics dashboard
Here is the kind of layout to build — the core database and infrastructure signals in one place. Remember this is a wireframe, not a screenshot.
Design the dashboard around a question, not the available metrics
The temptation is to chart every metric the platform emits, producing a wall of graphs nobody reads. Instead, design each dashboard around a question someone actually asks — "is the service healthy right now?", "is the standby safe?", "are we running out of storage?" — and include only the panels that answer it. A dashboard that answers a question gets watched; a dashboard that shows everything gets ignored.
7.Oracle Enterprise Manager
For the deep database layer, Oracle Enterprise Manager (OEM) remains the tool many Oracle DBAs reach for first, and it works with Oracle Database@Azure just as it does elsewhere. Where Azure Monitor gives you the operational and infrastructure picture, OEM gives you the rich, database-centric one — performance pages, the ADDM findings, SQL monitoring, and the topology views built specifically for Oracle.
7.1 Where OEM fits in the model
OEM sits squarely in Layer 2. You deploy the OEM agent to reach the databases, and it delivers the deep diagnostics — real-time performance, the top activity page, SQL details, and the historical performance analysis — that the native Azure integration deliberately does not try to replicate. For a shop with an existing OEM investment and OEM-fluent DBAs, it is the natural home for database-level monitoring.
| OEM strength | What it gives you |
|---|---|
| Performance Hub / Top Activity | Real-time and historical activity, wait analysis, and drill-down to sessions |
| SQL Monitoring | Live and past execution details for individual statements — the deep tuning view |
| ADDM & advisors | Automatic diagnostic findings ranked by impact, with recommendations |
| Fleet / target views | A database-centric topology across your Oracle estate |
| Incident & metric rules | Oracle-aware alerting on database conditions |
🔧 OEM and Azure Monitor are complements, not competitors
It is tempting to frame this as "OEM versus Azure Monitor" and pick one. That is the wrong frame. They answer different questions at different layers: Azure Monitor owns the unified, cross-cloud operational picture; OEM owns the deep Oracle database diagnostics. The mature setup uses Azure Monitor as the day-to-day watchtower and OEM as the place you go when the watchtower points at the database. Run both, each for what it is best at.
8.OCI Database Management & Ops Insights
Between the broad native Azure integration and the deep OEM view sits a third, Oracle-provided option purpose-built for this platform: OCI Database Management and OCI Ops Insights. Oracle positions these explicitly for Oracle Database@Azure deployments that want granular, real-time database performance monitoring beyond what the basic Azure-side metrics indicate.
8.1 What they add
Database Management
Granular, real-time performance monitoring for the database fleet — a rich fleet overview of top metric utilization, with drill-downs into specific databases for detailed diagnostics and tuning. The deep, real-time database view, delivered as a managed OCI service.
Ops Insights
Longer-horizon analytics — capacity trends, resource forecasting, and SQL performance over time — that help with planning and spotting slow regressions across the fleet rather than firefighting the moment.
8.2 Choosing among the depth tools
With OEM, Database Management, and Ops Insights all offering database depth, the practical question is which to lead with. The honest answer is that it depends on your existing investment and operating model — and the table frames the choice rather than pretending there is one right answer.
| If you... | Lead with |
|---|---|
| Have an established OEM estate and OEM-fluent DBAs | Oracle Enterprise Manager for the deep layer |
| Want a managed, OCI-native service with a multicloud fleet view | OCI Database Management |
| Need capacity forecasting and long-term SQL trend analysis | OCI Ops Insights |
| Want the unified cross-cloud operational picture | Azure Monitor at the correlation layer, feeding from all of the above |
Pick one depth tool to lead, do not run three half-heartedly
Database depth can come from OEM, Database Management, or Ops Insights — but running all three casually means three half-configured tools and alert fatigue. Choose one to be your primary deep-diagnostics home based on your investment and operating model, configure it properly, and let the others fill specific gaps if needed. Depth comes from one tool used well, not three used partially.
9.Azure Arc for the OS Layer
There is a layer the database tools do not see and the infrastructure metrics only partly cover: the operating system on each node. Azure Arc closes that gap. By enabling Azure Arc-enabled server monitoring, you can collect operating-system-level metrics, security events, and compliance status from each VM in the cluster — bringing the OS layer into the same Azure governance and monitoring plane as everything else, while preserving the OCI console for database-specific operations.
| Azure Arc brings in | Why it matters |
|---|---|
| OS-level metrics | CPU, memory, and disk at the operating-system level, beneath the database |
| Security events | OS security signals feeding your unified security monitoring |
| Compliance status | Configuration and compliance posture per node, in Azure governance |
| Unified governance | The nodes appear in the same Azure plane as the rest of the estate |
Arc fills the OS gap without taking over the database
The elegance of the Arc integration is that it adds the OS-level visibility Azure teams expect — and integrates it with unified governance and security monitoring — while leaving the database-specific operations to the OCI console and the Oracle-native tools. It fills a specific gap in the stack rather than trying to be the whole monitoring answer, which is exactly the right scope for it.
10.The Unified Dashboard
Everything so far exists to enable this: one place where an operator sees the health of the whole service, across both clouds, and knows where to look when something is wrong. In Azure this is typically an Azure Monitor Workbook — a composable, query-backed report that pulls metrics and logs from every layer into a single narrative.
10.1 What a unified workbook combines
Microsoft's own guidance for this platform describes building unified monitoring — including security dashboards — with Azure Monitor Workbooks that combine signals from across both platforms. A well-built operations workbook pulls together:
- Service health headline — a single up/degraded/down status derived from the key signals, so the first glance answers "is it fine?"
- Infrastructure metrics — Exadata VM cluster and node health from Azure Monitor, plus OS-level status from Azure Arc.
- Database signals — the key database metrics that reached Azure Monitor, with a link out to OEM or Database Management for depth.
- Data protection — Data Guard apply lag and last backup success, so recovery readiness is always visible.
- App-tier correlation — app VM health and error rates, side by side with the database, in the same time window.
- Active alerts — what is currently firing, with enough context to start triage without leaving the page.
The test of a unified dashboard is simple: can an on-call engineer open it at 3am, know in five seconds whether the service is healthy, and in thirty seconds know which layer to investigate? If yes, it is doing its job.
10.2 A workbook query backing the headline
The service-health headline is usually a small KQL query that rolls several signals into one status. Here is the shape of that idea.
// Roll several signals into a single service-health status for the header.
let window = 15m;
let dbErr =
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(window) and Severity in ("ERROR","CRITICAL")
| count;
let dgLag =
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(window) and Category == "DataGuardLogs"
| extend LagSeconds = toint(extract(@"apply lag[:\s]+(\d+)", 1, Message))
| summarize MaxLag = max(LagSeconds);
dbErr
| extend Errors = Count
| extend MaxLag = toscalar(dgLag)
| extend Status = case(
Errors > 0 or MaxLag > 60, "DEGRADED",
MaxLag > 10, "WATCH",
"HEALTHY")
| project Status, Errors, MaxLagOne dashboard to watch, clear paths to drill
The unified workbook should be the only thing your operations team keeps open. Its job is not to contain every detail — it is to show overall health and route you to the right deep tool fast. Every panel should either answer "is it healthy?" or link to the place that explains why not. Build that, and you have turned a two-cloud monitoring problem into a single pane with clean drill-downs — which is the whole goal.
11.Alerting That Works
Dashboards are for when you are looking; alerts are for when you are not. The aim is to be told about a real problem early, without being buried in noise — a balance most teams get wrong in the noisy direction, then start ignoring the alerts entirely.
11.1 Alert on symptoms that matter, at the right layer
| Alert on | Because |
|---|---|
| Data Guard apply lag over threshold | It is your recovery-point exposure growing — a direct data-loss risk |
| Backup failure / no recent success | A silent backup gap is only discovered during a recovery — too late |
| Storage approaching capacity | Running out of space is an outage you can see coming days ahead |
| Sustained high CPU / session saturation | Distinguishes a real capacity problem from a momentary spike |
| Node or instance down | Availability impact — page immediately |
| Error-log spikes | An early signal of a developing problem before users feel it |
11.2 Route by severity, and keep it actionable
In Azure, alert rules feed Action Groups, which decide who hears about what and how. The discipline that keeps alerting useful is matching severity to channel: page a human for things that need action now, send lower-severity signals to a queue reviewed in hours, and make every alert carry enough context to start triage. An alert that pages someone but tells them nothing actionable is worse than no alert — it trains people to ignore the pager.
# A log-based alert on Data Guard apply lag, routed to an action group.
az monitor scheduled-query create \
--name "odaa-dataguard-lag-high" \
--resource-group "$RG" \
--scopes "$LOG_ANALYTICS_WORKSPACE_ID" \
--condition "count 'Placeholder' > 0" \
--condition-query Placeholder='
OracleDatabaseAzureLogs_CL
| where TimeGenerated > ago(15m) and Category == "DataGuardLogs"
| extend LagSeconds = toint(extract(@"apply lag[:\s]+(\d+)", 1, Message))
| where LagSeconds > 60' \
--description "Data Guard apply lag over 60s in the last 15m" \
--evaluation-frequency 5m --window-size 15m --severity 1 \
--action-groups "$ONCALL_ACTION_GROUP_ID"⚠️ Alert fatigue is a monitoring failure, not a people problem
When a team starts ignoring alerts, the instinct is to blame the team. The real cause is almost always too many low-value alerts. Every alert that fires without needing action erodes trust in every alert that does. Ruthlessly tune out the noise: if an alert has fired ten times and never once required action, it is miscalibrated — fix or delete it. A small set of trusted, actionable alerts beats a hundred that everyone mutes.
12.Monitoring Pitfalls
| Pitfall | Why it bites, and the fix |
|---|---|
| Watching only the Azure side or only the Oracle side | Cross-boundary incidents become guesswork — build the unified correlation layer |
| Enabling diagnostic settings after go-live | Logs are not retroactive — turn them on at provisioning, before the first incident |
| Expecting Azure Monitor to do SQL tuning | The native set is broad, not bottomless — use OEM / Database Management for depth |
| Charting every available metric | Produces dashboards nobody reads — design each around a question |
| Running three depth tools half-configured | Alert fatigue and gaps — pick one deep-diagnostics tool to lead |
| Ignoring the OS layer | Node-level problems stay invisible — bring the OS in with Azure Arc |
| Too many low-value alerts | Erodes trust until all alerts are muted — a small set of actionable alerts |
| Not alerting on Data Guard lag or backup failure | Data-loss and recovery gaps found too late — alert on protection signals explicitly |
| Assuming a metric exists in Azure because it exists in OCI | Only the published set flows — know the boundary, use OCI tools beyond it |
| No owner for the dashboards and alerts | Monitoring rots without maintenance — assign ownership and review on a cadence |
Almost every monitoring failure is one of two things: not collecting what you needed before you needed it, or collecting so much that the signal drowns. Configure early, and curate ruthlessly.
13.Frequently Asked Questions
Can I monitor Oracle Database@Azure entirely from Azure?
For infrastructure and day-to-day operations, largely yes — native integration streams Exadata metrics, logs, and events into Azure Monitor, and Azure Arc adds the OS layer. But deep database and SQL diagnostics still come from Oracle-native tools (OEM, OCI Database Management). Use Azure for the unified picture and Oracle tools for the depth.
What do diagnostic settings actually capture?
Four log categories — VM cluster lifecycle-management logs, database logs, infrastructure logs, and Data Guard logs — which you can route to a Log Analytics workspace for analysis, an Event Hub for streaming to a SIEM, or a Storage Account for archival. Enable them before go-live, because they are not retroactive.
Why do some OCI metrics not appear in Azure?
Only the published Exadata@Azure metric set flows to Azure Monitor. A metric that exists in the OCI namespaces but is not in that published set will not appear in Azure. For anything beyond the supported set, use OCI Database Management or OEM.
Is it OEM or Azure Monitor?
Both, for different layers. Azure Monitor owns the unified, cross-cloud operational picture and is where you watch day to day; OEM owns deep Oracle database diagnostics and is where you drill when the database is the problem. They complement rather than compete.
What is OCI Database Management for?
Granular, real-time database performance monitoring purpose-built for this platform — a fleet overview with drill-down into individual databases for diagnostics and tuning, delivered as a managed OCI service. Ops Insights adds longer-term capacity and SQL-trend analytics.
How do I get OS-level metrics from the database nodes?
Azure Arc-enabled server monitoring collects OS-level metrics, security events, and compliance status from each VM in the cluster, bringing the operating-system layer into Azure's governance and monitoring plane while the OCI console still handles database-specific operations.
What should I alert on first?
The protection and availability signals: Data Guard apply lag, backup failure or no recent success, storage approaching capacity, and node/instance down. These map directly to data-loss and outage risk. Add sustained-CPU and error-spike alerts, and keep the total set small and actionable.
How do I build the single-pane view?
An Azure Monitor Workbook that combines metrics and logs from every layer — infrastructure, database signals, data protection, app-tier correlation, and active alerts — into one report, with links out to the deep tools. It should let an on-call engineer judge service health in seconds and know which layer to investigate.
14.Key Takeaways
The short version
• Monitor both clouds as one. The database is on Oracle's Exadata, the rest is in Azure, and incidents cross that line — build a unified correlation layer or lose half of every investigation.
• Think in three layers. Infrastructure at the base, database-and-SQL depth in the middle, unified correlation and alerting on top — watch from the top and drill down.
• Lean on native integration. Exadata metrics, logs, and events flow into Azure Monitor; configure diagnostic settings early (they are not retroactive) and route logs to Log Analytics.
• KQL is the common language. Once Oracle and Azure logs share a workspace, KQL lets you query and correlate across both worlds — the payoff of unified logging.
• Keep Oracle depth. OEM, OCI Database Management, and Ops Insights own the deep database diagnostics the native set does not replace — pick one to lead and use it well.
• One dashboard, few alerts. Build a single unified workbook that routes you to the right depth, and keep alerts small, actionable, and focused on protection and availability signals.
Monitoring Oracle Database@Azure looks daunting because it spans two clouds, two operating models, and two sets of tools — but the daunting part dissolves once you stop trying to pick a side. The database lives on Oracle's Exadata and the estate lives in Azure, and the job of good monitoring is not to pretend otherwise; it is to build one operational picture on top of both, with clean paths down into whichever depth you need.
Do that and the two-cloud problem becomes an advantage. The native Azure Monitor integration gives you the unified view and the correlation. Diagnostic settings and Log Analytics give you the logs and the KQL to interrogate them. OEM, Database Management, and Ops Insights keep the deep Oracle diagnostics you would never want to lose. Azure Arc fills in the OS layer. And a single well-built workbook, backed by a small set of trusted alerts, turns all of it into something an on-call engineer can actually use at 3am. Layer it, configure it early, curate it ruthlessly — and a database that spans two clouds becomes one you can watch from a single, calm pane of glass.
Monitoring capabilities, native integration features, supported metric and log categories, portal navigation, and tool behaviour reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current supported metrics, log categories, and configuration steps against Oracle and Microsoft documentation before implementing. The dashboard visuals are illustrative mockups, not screenshots of a live system. All code and queries are illustrative, use placeholder names, table names, and values, and must be validated against your own environment and current documentation before use. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft
Comments