Sunday, October 4, 2026

Beyond the Create Button: Architecting Oracle Autonomous Database on Microsoft Azure into a Live Data Pipeline

1. Create blade: pick Transaction Processing:

 




Why OLTP: the app writes small, concurrent rows (customer profiles, orders, sessions). Transaction Processing tunes for high concurrency and short statements; Data Warehouse favors large scans. Pick it first because it cannot be switched in place later.


2. Database configuration in depth, with auto scaling on







SettingValueReasoning
Database version19cLong-term-support release; broadest driver and tool compatibility.
ECPU (base)2Start small; you pay for base ECPUs continuously, so size for the quiet period.
Compute auto scalingOnLets the database burst to roughly 3x base on demand and fall back; you are billed for actual use above base. Covers peaks without a resize event.
Storage1 TB + auto scalingAuto scaling prevents a full-disk stall on growth. Set a budget alert since storage can only grow elastically.
Backup retention60 daysAutomatic backups are managed by Oracle and billed separately from database storage. Older backups are deleted past the window.
Admin credentialsADMINUse a long unique password stored in Key Vault; create named app users and avoid daily ADMIN use.
LicenseLicense includedSwitch to BYOL only if your Oracle agreement allows it.
NetworkingPrivate endpoint on a delegated subnet, NSG attachedNo public access; mTLS optional (see Screen 4).


Equivalent CLI



3. Deployment in progress:


Takeaway: the Azure resource appears fast, but the database lifecycle completes in OCI. Wait for the OCI state to read Available before connecting.


4. OCI console: nanubalu is Available:



Takeaway: every choice from Screen 2 is confirmable here. Buttons across the top (Database actions, Database connection, Performance hub, Manage resource allocation) are the daily-ops entry points. Verify from SQL:


SELECT name, open_mode, database_role FROM v$database;

SELECT * FROM v$version;

SELECT * FROM v$services;     -- HIGH / MEDIUM / LOW / TP / TPURGENT

SELECT value FROM v$parameter WHERE name = 'cpu_count';


5. MongoDB Compass: saved queries on the source


Takeaway: Oracle will hold the transactional and relational side of the same application.

6. Querying movieCollection:





Takeaway: nested arrays (cast, crew, awards) are why a document model suits the catalog while customer demographics stay relational.

7. Data Factory: factory resources:


Takeaway: one pipeline, two datasets: a CSV source in ADLS and an Oracle sink pointing at nanubalu.


8. Source dataset on the bronze layer:



Takeaway: "bronze" signals a raw landing zone; keep it immutable and let the pipeline shape data on the way into Oracle.


9. Pipeline run: Copy data:



Takeaway: add a trigger (schedule or storage event) once the manual run succeeds, and alert on failure in Azure Monitor.


10. Verify in SQL:


begin
  dbms_cloud_repo.install_file(
    repo          => get_repo,
    file_path     => 'tables/demographics.sql',
    branch_name   => 'main',
    stop_on_error => false);
end;
/
select * from demographics;

Query result: fetched 200 rows in 0.238 seconds

CUST_IDLAST_NAMEFIRST_NAMEEMAILAGECOMMUTECREDITEDUCATION
12386074123426LessThanHS
1239220524019High School
12420774417492Bachelors

Takeaway: install the DDL from a Git repo with DBMS_CLOUD_REPO, then prove the load. Add these checks and a masking rule so personal data never reaches lower environments:

SELECT COUNT(*) FROM demographics;                       -- expect 200

SELECT education, ROUND(AVG(credit_balance),0) avg_credit, COUNT(*) n

FROM   demographics GROUP BY education ORDER BY n DESC;


-- Mask email for a read-only analyst role

BEGIN

  DBMS_REDACT.ADD_POLICY(

    object_schema => 'ADMIN', object_name => 'DEMOGRAPHICS',

    column_name   => 'EMAIL', policy_name => 'MASK_EMAIL',

    function_type => DBMS_REDACT.PARTIAL,

    function_parameters => 'VVVVVVVVVVVVVVVVVVVV,VVVVVVVVVVVVVVVVVVVV,*,1,20',

    expression    => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''ADMIN''');

END;

/



Auto scaling: how to prove it works:


-- Current vs base CPU allocation

SELECT name, value FROM v$parameter WHERE name IN ('cpu_count','resource_manager_plan');


-- Peak usage in the last hour from Active Session History

SELECT TRUNC(sample_time,'MI') minute, COUNT(*)/60 avg_active_sessions

FROM   v$active_session_history

WHERE  sample_time > SYSTIMESTAMP - INTERVAL '1' HOUR

GROUP  BY TRUNC(sample_time,'MI') ORDER BY 1;

Watch the Performance hub and the OCI metrics CpuUtilization and StorageUtilization during a load test; alert at 80 percent so you notice sustained scale-up before the bill does.

Architecture at a glance

Control plane is split by design: Azure owns the resource, networking, RBAC, tags and invoice; OCI owns database lifecycle (scale, backup, clone, Data Guard, Performance Hub). Write that into your RACI before go-live.

Sizing and auto-scaling mechanics

TopicWhat to know
ECPU modelECPU is the current billing unit for Autonomous (replacing OCPU). It is a hardware-agnostic compute unit, so do not carry OCPU counts over one-to-one; benchmark.
Compute auto scalingAllows up to 3x the base ECPU. Base is billed continuously; usage above base is billed for the time it is actually used. Size base near your steady p50 and let burst absorb p95 to p99.
Storage auto scalingLets storage grow automatically (up to a multiple of the reserved size) so a load never fails on a full tablespace. It protects availability, not your budget, so add a cost alert.
Memory and IOMemory and IOPS scale with ECPU. Scaling compute online needs no downtime.
Tuning ruleIf the database sits at 2x to 3x for hours every day, raise the base. Burst is for spikes, and sustained use at burst is cheaper as a larger base.
Idle cost controlUse the auto start/stop schedule on non-production copies (it is Disabled on this instance, which suits prod).

Connection services: pick the right consumer group

ServiceUse it forBehavior
TPURGENTTime-critical OLTPHighest priority; parallelism only by hint.
TPDefault app trafficNo automatic parallelism; high concurrency. Use this for the application.
HIGHReports, ETL, adminLargest share of resources, parallel queries, fewer concurrent statements.
MEDIUMMixed jobsBalanced share with limited parallelism.
LOWBackground workLowest priority, highest concurrency, serial execution.


Point the Data Factory sink at HIGH or MEDIUM so bulk loads do not starve the app on TP.
-- Which service is this session using?
SELECT SYS_CONTEXT('USERENV','SERVICE_NAME') svc,
       SYS_CONTEXT('USERENV','SESSION_USER')  usr FROM dual;

-- Who is connected, by service, right now?
SELECT service_name, COUNT(*) sessions
FROM   v$session WHERE type = 'USER' GROUP BY service_name;
Connectivity and transport security:

# python-oracledb, thin mode, TLS, no wallet (mTLS not required)
import oracledb
dsn = ("(description=(retry_count=3)(retry_delay=2)"
       "(address=(protocol=tcps)(port=1521)(host=nanubalu-db.nwf.internal))"
       "(connect_data=(service_name=<your_service>_tp.adb.oraclecloud.com))"
       "(security=(ssl_server_dn_match=yes)))")
pool = oracledb.create_pool(user="APP_USER", password=PW, dsn=dsn,
                            min=2, max=20, increment=2)
ItemGuidance
Access typePrivate endpoint on a delegated subnet; no public IP. Resolve the endpoint through an Azure Private DNS zone and give apps a CNAME, never a hardcoded host.
Ports1522 for mutual TLS (wallet required), 1521 for one-way TLS when mTLS is "Not required" (as on this instance). Allow only the app and integration subnets in the NSG.
mTLSLeave it off only if the network is private and an NSG/ACL restricts sources. If clients are untrusted or cross-network, require mTLS and rotate the wallet on a schedule.
Network ACLAdd an access control list in addition to the NSG: two independent allow-lists beat one.

Resilience: backups are not disaster recovery

CapabilityState on nanubaluExpert note
Automatic backupsOn, 60 daysEnables point-in-time restore inside the window. Billed separately from storage.
Long-term backupsNot scheduledUse for compliance retention beyond 60 days (up to years).
Local standby (Autonomous Data Guard)Backup-based onlyEnable for a faster, near-zero-data-loss failover within the region.
Cross-regionNot enabledEnable a cross-region standby for regional outages; plan DNS failover with a short TTL.
Restore testNot yet doneClone from a backup quarterly and run your validation queries. An untested backup is a hope.

Write the targets down: for example RPO 15 minutes and RTO 1 hour, then choose backup-only, local standby or cross-region standby to meet them, not the other way round.

Performance and tuning like an OCI admin

  • Auto indexing and automatic statistics are on by default in Autonomous; review them, do not fight them.
  • Performance Hub and Real-Time SQL Monitoring for live diagnosis; Operations Insights for capacity trends.
  • Resilient clients: use connection pools with retry in the connect descriptor and configure Application Continuity or Transparent Application Continuity so maintenance and scaling events are invisible to users.
-- Auto indexing: mode and what it did in the last day
SELECT parameter_name, parameter_value
FROM   dba_auto_index_config WHERE parameter_name IN ('AUTO_INDEX_MODE','AUTO_INDEX_SCHEMA');

SELECT DBMS_AUTO_INDEX.REPORT_ACTIVITY(SYSTIMESTAMP-1, SYSTIMESTAMP, 'TEXT') FROM dual;

-- Top SQL by elapsed time per execution
SELECT sql_id, executions, ROUND(elapsed_time/1e6,1) total_s,
       ROUND(elapsed_time/NULLIF(executions,0)/1e3,1) ms_per_exec,
       SUBSTR(sql_text,1,80) txt
FROM   v$sql WHERE executions > 0
ORDER  BY elapsed_time DESC FETCH FIRST 10 ROWS ONLY;

Infrastructure as code

Provision from code so the portal clicks in Screens 1 and 2 are repeatable. Illustrative Terraform (check current azurerm resource and argument names before use):

resource "azurerm_oracle_autonomous_database" "nanubalu" {
  name                             = "nanubalu"
  resource_group_name              = "MovieStream"
  location                         = "eastus"
  subnet_id                        = azurerm_subnet.oradata.id
  virtual_network_id               = azurerm_virtual_network.data.id
  display_name                     = "nanubalu"
  db_workload                      = "OLTP"        # Transaction Processing
  db_version                       = "19c"
  compute_model                    = "ECPU"
  compute_count                    = 2
  auto_scaling_enabled             = true          # compute burst
  auto_scaling_for_storage_enabled = true
  data_storage_size_in_tbs         = 1
  backup_retention_period_in_days  = 60
  license_model                    = "LicenseIncluded"
  mtls_connection_required         = false
  admin_password                   = var.adb_admin_password   # from Key Vault
  tags = { workload = "moviestream", env = "prod", owner = "data-platform" }
}

Hardening the Data Factory pipeline

  • Run the copy through a self-hosted integration runtime in the same VNet so traffic stays on the private endpoint.
  • Make loads idempotent: land in a staging table, then MERGE. Re-running a failed pipeline must not duplicate rows.
  • Tune the copy activity: batch size, parallel copies and the sink service (MEDIUM/HIGH) to match the ECPU you have.
  • Alternative: let the database pull from object storage with DBMS_CLOUD.COPY_DATA, which is often faster for large files.
-- Idempotent upsert from staging
MERGE INTO demographics d
USING demographics_stg s ON (d.cust_id = s.cust_id)
WHEN MATCHED THEN UPDATE SET d.age = s.age, d.credit_balance = s.credit_balance,
                             d.education = s.education
WHEN NOT MATCHED THEN INSERT (cust_id,last_name,first_name,email,age,commute_distance,credit_balance,education)
  VALUES (s.cust_id,s.last_name,s.first_name,s.email,s.age,s.commute_distance,s.credit_balance,s.education);

-- Post-load reconciliation
SELECT (SELECT COUNT(*) FROM demographics_stg) staged,
       (SELECT COUNT(*) FROM demographics)     loaded FROM dual;

FinOps for the architect

  • Cost drivers: base ECPU hours, burst ECPU time, storage, backup storage and (if used) cross-region standby.
  • Tag every resource (workload, env, owner, costcenter) so Azure Cost Management can show Oracle beside AKS and Data Factory.
  • Review the base ECPU monthly using peak-to-base ratios; right-size before buying more.
  • Confirm with both vendors how Marketplace spend counts toward your Azure commitment.

Troubleshooting cheat sheet

SymptomUsual causeFirst check
ORA-12541 / ORA-12170 timeoutNSG, ACL, DNS or wrong portResolve the host from the client subnet; test port 1521 or 1522.
ORA-28759 / wallet errorsmTLS required but no wallet, or expired walletMatch port to the mTLS setting; re-download the wallet.
ORA-01017Wrong or expired password, or the wrong userCheck dba_users.account_status; unlock and reset.
Copy slow or throttledSink on a low-priority service, or base ECPU too smallSwitch to MEDIUM/HIGH; watch Performance Hub for CPU and IO waits.
Unexpected billSustained burst, backup growth or storage auto-scaleCost analysis by tag; compare base to peak ECPU.

Tuesday, September 29, 2026

Oracle Database 19c RU 19.32 on Oracle Linux 10 Using AutoUpgrade

 

Build a fully patched Oracle home, then create a CDB and PDB on it, with one config file and one Java command.

The problem with manual home builds

A patched 19c home traditionally means downloading the base image, OPatch, the Release Update, OJVM, the Data Pump Bundle Patch (DPBP) and a JDK patch, then unzipping, patching in the right order and relinking. Each step risks a typo or version mismatch, and across servers and quarters the environments drift.

AutoUpgrade started as an upgrade tool but now handles patching and provisioning too. Its download and create_home modes resolve the patch set for you, fetch it from My Oracle Support (MOS), and assemble the home.

Read this first: Oracle Linux 10

19c predates Oracle Linux 10, and OS support arrives through Release Updates. Before building, confirm OL10 support for your configuration in Oracle's certification information and the RU 19.32 release notes. Check whether oracle-database-preinstall-19c exists for OL10 and whether the installer needs an override such as CV_ASSUME_DISTID. Use overrides only if the notes say so. Treat the steps below as a template to validate, not a certified recipe.

Prerequisites

Area

Requirement

Memory

8 GB or more recommended, swap per the install guide

Disk

About 40 GB free for staging, the home and the database

Access

MOS account with a support entitlement for 19c patches; outbound HTTPS to Oracle (or a proxy)

Software

Latest autoupgrade.jar and a JDK (Java 8 or later)

OS user

oracle in oinstall and dba

Step 1: Prepare the operating system

# As root

dnf install -y java-17-openjdk unzip libnsl libaio ksh bc binutils \

    glibc-devel libstdc++-devel make sysstat fontconfig policycoreutils

groupadd -g 54321 oinstall

groupadd -g 54322 dba

useradd  -u 54321 -g oinstall -G dba oracle

passwd oracle

If no preinstall package is available, set kernel parameters in /etc/sysctl.d/97-oracle.conf and limits in /etc/security/limits.d/oracle-database-19c.conf:

fs.file-max = 6815744

kernel.sem = 250 32000 100 128

kernel.shmmni = 4096

net.ipv4.ip_local_port_range = 9000 65500

fs.aio-max-nr = 1048576

 

oracle soft nofile 1024

oracle hard nofile 65536

oracle soft nproc  16384

oracle hard nproc  16384

oracle hard memlock unlimited

Apply with sysctl --system. Size shmall and shmmax for your RAM, and for production configure HugePages and disable transparent HugePages.

Directory layout

/u01app/oracle/autoupgradeapp/oracle/stageapp/oracle/product/19.32.0oradata, fraautoupgrade.jar, config, keystore, logsDownloaded gold image and patchesThe new Oracle home (dbhome_1). Name it after the RU.Datafiles and fast recovery areaFigure 2. Separating tooling, staging, homes and data keeps builds clean and lets several RU homes coexist.

mkdir -p /u01/app/oracle/{autoupgrade/{keystore,log},stage,product/19.32.0/dbhome_1}

mkdir -p /u01/oradata /u01/fra

chown -R oracle:oinstall /u01 && chmod -R 775 /u01

Step 2: Install AutoUpgrade

As oracle, place the latest autoupgrade.jar in the autoupgrade folder and check the build. Record the version, because supported parameters and patch keywords depend on it.

cd /u01/app/oracle/autoupgrade

java -jar autoupgrade.jar -version

Step 3: Write the config file

Save as create_home.cfg. Parameter names can differ between AutoUpgrade builds, so check the documentation for yours.

global.global_log_dir=/u01/app/oracle/autoupgrade/log

global.keystore=/u01/app/oracle/autoupgrade/keystore

 

patch1.folder=/u01/app/oracle/stage

patch1.target_version=19

patch1.platform=LINUX.X64

patch1.patch=RU:19.32,OPATCH,OJVM,DPBP,JDK

 

patch1.target_home=/u01/app/oracle/product/19.32.0/dbhome_1

patch1.home_settings.oracle_base=/u01/app/oracle

patch1.home_settings.edition=EE

patch = RU:19.32 + companionsRU:19.32OPATCHOJVMDPBPJDKRelease UpdateMatching OPatchJava in the databaseData Pump fixesJDK in the homeFigure 3. What each item in the patch list contributes. Run -help for the keywords your build supports.

Parameter

Meaning

patch1.folder

Staging area for downloads

patch1.target_version

Release line (19)

patch1.patch

RU plus companion patches

patch1.target_home

Path of the home to create

home_settings.edition

EE or SE2

Step 4: Store MOS credentials

Credentials go in an encrypted keystore, never in the config file.

java -jar autoupgrade.jar -config create_home.cfg -patch -load_password

chmod 700 /u01/app/oracle/autoupgrade/keystore

Step 5: Download

java -jar autoupgrade.jar -config create_home.cfg -patch -mode download

AutoUpgrade resolves each keyword to the right patch for 19.32 and downloads the gold image, OPatch, OJVM, DPBP and JDK patch into the staging folder. Use lsj in the console to list jobs and status -job <n> for detail. In restricted networks, download on a connected host and copy the staging folder across.

Step 6: Create the patched home

java -jar autoupgrade.jar -config create_home.cfg -patch -mode create_home

It unpacks the gold image, updates OPatch, applies the patches in order and validates the result. Run any root scripts it prompts for, then set the environment:

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=$ORACLE_BASE/product/19.32.0/dbhome_1

export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH

Step 7: Verify the home

opatch version

opatch lspatches

opatch lsinventory -detail | more

You should see the 19.32 RU, OJVM, DPBP and JDK patches. Compare patch IDs against the RU 19.32 README on MOS.

Step 8: Create the CDB and PDB

netca -silent -responsefile $ORACLE_HOME/assistants/netca/netca.rsp

 

dbca -silent -createDatabase \

  -templateName General_Purpose.dbc \

  -gdbName CDB1 -sid CDB1 \

  -createAsContainerDatabase true \

  -numberOfPDBs 1 -pdbName PDB1 \

  -characterSet AL32UTF8 -nationalCharacterSet AL16UTF16 \

  -sysPassword '<StrongPassword>' -systemPassword '<StrongPassword>' \

  -pdbAdminPassword '<StrongPassword>' \

  -datafileDestination /u01/oradata \

  -recoveryAreaDestination /u01/fra \

  -storageType FS -memoryMgmtType AUTO_SGA -totalMemory 4096 \

  -emConfiguration NONE

Because the home is already at 19.32, the database starts fully patched, so the long post-install datapatch step mostly disappears. Save the PDB state so it opens after restarts:

ALTER PLUGGABLE DATABASE PDB1 SAVE STATE;

Step 9: Validate

SELECT name, cdb, open_mode, log_mode FROM v$database;

SELECT banner_full FROM v$version;

SHOW PDBS;

 

SELECT con_id, comp_id, comp_name, version, status

FROM   cdb_registry ORDER BY con_id, comp_id;

 

SELECT con_id, COUNT(*) invalid_objects

FROM   cdb_objects WHERE status = 'INVALID'

GROUP  BY con_id;

 

SELECT patch_id, action, status, description

FROM   dba_registry_sqlpatch ORDER BY action_time;

Expected resultOracle Database 19c at 19.32CDB1 open READ WRITE, PDB1 openAll components VALIDNo invalid objectsdba_registry_sqlpatch shows SUCCESSIf objects are invalid: run @?/rdbms/admin/utlrp.sqlIf a patch is missing: run datapatch -verboseFigure 4. What a healthy build looks like.

Post-build checklist

  • Register the database in oratab and set up autostart (systemd or dbstart)
  • Configure RMAN backups and take a first backup
  • Apply hardening: password policy, auditing, network encryption
  • Configure HugePages and tune initialization parameters
  • Commit the config file and AutoUpgrade version to Git

Troubleshooting

Symptom

Likely cause and fix

Download authentication fails

Wrong credentials or no entitlement. Reload with -load_password.

Downloads stall

Proxy or firewall. Check outbound HTTPS.

Unknown keyword or parameter

AutoUpgrade build is older than your syntax. Update and check the docs.

Home creation fails

Read logs in global_log_dir; check disk space and permissions.

OL10 prerequisite warnings

Compare with the certification matrix and RU release notes before overriding.

Invalid objects

Run utlrp.sql and re-check.

Best practices

Build in a lab first and keep the config in Git next to the AutoUpgrade version. Prefer out-of-place patching so the previous home stays available for rollback. Each quarter, change the config line (RU:19.33 and so on) and create a new home directory. The config-driven approach fits Ansible or CI pipelines well.

Conclusion

AutoUpgrade turns home building into a declarative task: describe the target, run download, run create_home, create the CDB and PDB, and validate. On Oracle Linux 10 the extra diligence is confirming certification and prerequisites, but the result is a repeatable, fully patched 19c environment.

Verify OS certification, patch contents and AutoUpgrade parameter syntax against Oracle documentation and MOS notes for your exact build and RU. Test in non-production first.

 

Fusion Claw Decoded: How Oracle Separates AI Thinking from Enterprise Doing

Fusion Claw Decoded: How Oracle Separates AI Thinking from Enterprise Doing

Most enterprise AI so far has assisted people. Oracle Fusion Claw is built to execute. It is a governed runtime that lets Fusion Agentic Applications plan, compute, re-plan, and act on complex work, inside rules the customer defines, and leave an audit trail behind.

The short version

Oracle describes Fusion Claw as a governed agentic execution runtime for Oracle Fusion Agentic Applications. It combines AI reasoning with deterministic enterprise computation so highly complex work can be completed economically at scale. Twenty-five new Claw-powered applications are available now, for finance, HR, supply chain, sales and more, bringing the Agentic Applications portfolio to 75.

The design principle: use AI judgment where judgment is needed, and use efficient deterministic computation for high-volume execution.

 





Where Claw fits

Fusion Cloud Applications are the enterprise system of record: ERP, HCM, SCM, and CX. Fusion Agentic Applications sit on top as a system of outcomes, where people define objectives, authority, and accountability and the applications coordinate the work needed to reach the result. Claw is the execution runtime underneath the newest of those applications. It supports larger-scale and longer-running work, continuous replanning, deterministic execution, and more governed autonomy.

Oracle AI Agent Studio for Fusion Applications anchors the wider ecosystem. Its Agentic Applications Builder and AI Studio Skill capabilities, no-code and pro-code, let organizations create and manage agentic apps from reusable Oracle, partner, and external agents, with built-in observability, ROI measurement, and safety controls.

The core idea: reason first, then compute

Each Claw outcome begins with a frontier model that reasons, plans, learns, and adapts. Claw then executes deterministically, precisely, and at scale. Oracle argues this separation gives customers a potential economic advantage, because expensive AI reasoning is applied only where it is needed.

ObjectiveGoal and envelopeReason and planFrontier modelExecuteDeterministic computeOutcome receiptAudit recordOff target: learn, adapt, re-planLifecycle of a Claw outcome. Purple is AI reasoning, teal is deterministic execution.

Why it matters: many enterprise problems have a clear goal but no fixed recipe, such as reaching a staffing coverage level under labor rules and cost limits. Oracle's Claw apps target work like deep research, computation, simulation, modeling, and continuous re-planning. Launch interviews added that the model can pause for human approval or, if authorized, run fully autonomously, and that AI units are consumed while an LLM plans but not while the platform executes the plan.

Governance: envelope, harness, receipt

Autonomy is only useful if it is trustworthy, so Claw ships with three named governance concepts.

Enterprise Operating EnvelopeGoals, SOPs, policies, decision rights, risk limitsOutcome Trust HarnessApplied to every outcome runIdentityActs as whomCapabilitiesAllowed toolsDataVisible recordsActionsPermitted stepsOutcome ReceiptAuthority, evidence, decisions, resultsRules go in, enforcement wraps every run, and an auditable record comes out.

  • Enterprise Operating Envelope. The organization's objectives, standard operating procedures, policies, constraints, permissions, risk thresholds, decision rights, approval requirements, and escalation boundaries.
  • Outcome Trust Harness. Enforces the envelope on every outcome run by applying governing authority and controls to identity, capabilities, data, and actions.
  • Outcome Receipt. When the outcome completes, it records the authority applied, evidence used, decisions made, actions and transactions executed, and the result.

Customers also choose the automation level per process, from quick assistance to governed full-auto execution within explicitly delegated authority. Launch interviews reported further detail: jobs run in private, isolated workspaces without their own internet access, and the language model cannot directly update Fusion business objects.

The four named applications

Application

Audience

What it does

Ledger

Finance

Improves close readiness by reconciling large volumes of entries, investigating exceptions and anomalies, and applying deterministic computation to financial analysis.

Workforce Staffing

HR

Builds executable staffing plans balancing skills, accreditations, availability, labor rules, and cost, evaluating alternatives and re-planning as conditions change.

Shipping Consolidation

Supply chain

Models consolidation alternatives across timing, capacity, service commitments, and cost, then carries the best supported plan into governed execution when authorized.

Account Territory Growth Plan

Sales

Models and compares territory scenarios, evaluates tradeoffs, and optimizes against capacity and business constraints before taking governed action.

Claw runs on Oracle Cloud Infrastructure and is powered by frontier models including Gemini and OpenAI, with more planned.

The product owner's lens

  • Unit of work. You buy outcomes, not tasks. Define each outcome with a measurable target and explicit constraints.
  • Autonomy ladder. Start with assistance and plan-and-approve. Widen delegated authority only when approvals stop changing the plan.
  • Write the envelope first. Ambiguous SOPs will surface immediately. Treat that as a benefit.
  • Metrics. Track outcome versus target, human intervention rate, time to plan, and consumption cost per outcome.
  • Audit early. Have risk and audit review a sample Outcome Receipt before the first pilot.

The architect's lens

This section is my analysis. Oracle has not published implementation details, so these are questions to ask, not claims about the product.

  • Planner and executor separation limits the blast radius of model error. Ask what validates a plan before execution and what happens on mid-plan failure.
  • Policy as an artifact. If SOP documents are translated into enforceable rules, ask how those rules are reviewed, tested, and versioned.
  • Observability. Can receipts and traces flow to your SIEM and GRC tools, and what are their retention guarantees?
  • Cost control. Are there per-outcome budgets for re-planning loops?
  • Model governance. How do provider or version changes affect repeat runs, and what are the data-handling terms?
  • Untrusted inputs. What protects the planning step when it reads external documents or third-party data?

 

Reference:

https://www.oracle.com/news/announcement/oracle-extends-fusion-agentic-applications-with-introduction-of-fusion-claw-2026-09-29/

 

 


Beyond the Create Button: Architecting Oracle Autonomous Database on Microsoft Azure into a Live Data Pipeline

1. Create blade: pick Transaction Processing:   Why OLTP: the app writes small, concurrent rows (customer profiles, orders, sessions). Trans...