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/

 

 

Migrating Oracle 11.2.0.4 to Oracle Database 19c on OCI with almost no downtime, told from both the architect's and the product manager's chairs

Chapter 1: The Server Nobody Wanted to Touch

Every company has one. In our story it's PROD11, an Oracle 11.2.0.4 single-instance database on Oracle Linux 5.6, running quietly in a rack that predates half the team. It holds orders, billing, and the customer ledger.

The product manager, Priya, opens the meeting with a number rather than a technology: "How many minutes can the business be down?"

The answer from the business was "as close to zero as you can get." That answer decided the whole design.

The architect, Arjun, translated it: "That rules out a plain export/import. We need an online migration: an initial load plus continuous replication, then a short cutover."

The infographic you're looking at shows exactly that shape:

On-prem Oracle 11.2.0.4 → OCI Database Migration Service (DMS) → Oracle Database 19c on OCI

Chapter 2: Requirements Before Architecture

Priya's first artifact was a one-page requirements table. The infographic's Section 1 is the same idea:

Question	Answer
Source	Oracle 11.2.0.4, single instance, Linux
Target	Oracle 19c on OCI (single instance or RAC)
Migration type	Online: initial load + continuous replication
Downtime	Minimal, with a target defined by the business
Connectivity	Private: VPN or FastConnect
Prerequisites	Validate compatibility, objects, data types, privileges, network

She adds a rule for the project: "We don't start migrating until we can prove the source is ready." That rule led to the most valuable week of the project, the pre-flight checks.

Chapter 3: The Architecture in One Breath

Arjun sketches it on a whiteboard, matching Section 2 of the infographic:

1. The source (11.2.0.4) sits on-premises with the application still live.
2. A private network path (VPN or FastConnect) connects it to the OCI VCN.
3. DMS orchestrates everything: connections, pre-migration validation, initial load via Data Pump, continuous replication via Oracle GoldenGate, monitoring, and cutover.
4. The target 19c database is populated, kept in sync, and finally becomes the system of record.

The key insight is that DMS doesn't move data in one motion. It moves it in two phases that overlap: a bulk snapshot, then a stream of changes that catches up with everything that happened during the snapshot.

Chapter 4: Preparation, Where Migrations Are Won

(Workflow Steps 1–2 in the infographic)

Arjun's rule: "Every assumption becomes a query." These are the checks he ran on the source. I've marked which ones I validated against Oracle documentation and which come from working practice.

4.1 Know what you're migrating

sql

-- Exact version

SELECT banner FROM v$version;

 

-- Character sets (must be understood before the load)

SELECT parameter, value

FROM   nls_database_parameters

WHERE  parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

 

-- Size by application schema (adjust the exclusion list to your environment)

SELECT owner, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb

FROM   dba_segments

WHERE  owner NOT IN ('SYS','SYSTEM','OUTLN','DBSNMP','SYSMAN','XDB','CTXSYS',

                     'MDSYS','ORDSYS','WMSYS','EXFSYS','APPQOSSYS')

GROUP  BY owner

ORDER  BY size_gb DESC;

Note that 11.2.0.4 has no ORACLE_MAINTAINED column in DBA_USERS (that arrived in 12c), which is why the schema exclusion list is written out by hand.

4.2 Measure the change rate

This is the number the PM cares about most. The redo rate predicts how hard GoldenGate will work and how long the "catch-up" will take.

sql

SELECT TRUNC(first_time,'HH24')                       AS hour,

       ROUND(SUM(blocks*block_size)/1024/1024/1024,2) AS redo_gb

FROM   v$archived_log

WHERE  first_time > SYSDATE - 7

AND    dest_id = 1

GROUP  BY TRUNC(first_time,'HH24')

ORDER  BY 1;

The dest_id = 1 filter prevents double-counting when multiple archive destinations exist. Look for the busiest hour, not the average. That's your worst case for replication lag.

4.3 Can GoldenGate see the changes at all?

Continuous replication reads the redo logs, so the source must be configured to log enough information. Oracle's DMS documentation lists the requirements for an online-migration source: archive log mode, force logging, ENABLE_GOLDENGATE_REPLICATION=TRUE, and database supplemental logging. Force logging matters because it ensures every change appears in the redo, where the GoldenGate Extract process can find it. oracleoracle

First, check where you stand:

sql

SELECT log_mode, force_logging, supplemental_log_data_min

FROM   v$database;

 

SHOW PARAMETER enable_goldengate_replication

SHOW PARAMETER global_names

SHOW PARAMETER streams_pool_size

The target result is ARCHIVELOG, YES, and YES (or IMPLICIT). If the first is NOARCHIVELOG, you need a short outage window to fix it, which is a good thing to learn in week one and not on cutover night:

sql

-- Only if NOARCHIVELOG (requires a restart!)

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

 

-- Then:

ALTER DATABASE FORCE LOGGING;

ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

These statements match Oracle's DMS source-preparation steps. Two more items from Oracle's GoldenGate prep guidance are worth checking: set STREAMS_POOL_SIZE to at least 2 GB, and if GLOBAL_NAMES is true, change it to false. medium

sql

ALTER SYSTEM SET global_names=FALSE SCOPE=BOTH;

One 11.2-specific warning: for an 11.2 source, Oracle requires you to apply the mandatory 11.2.0.4 RDBMS patches listed in My Oracle Support note 1557031.1. I'm not quoting patch numbers because they change over time. Get the current list from that note. oracle

4.4 The GoldenGate admin user

DMS needs a dedicated replication user. The documented pattern is a GGADMIN user with a set of grants, finished by EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN'). oracle

sql

CREATE USER ggadmin IDENTIFIED BY "<strong_password>"

  DEFAULT TABLESPACE users QUOTA UNLIMITED ON users;

 

GRANT CONNECT, RESOURCE, CREATE SESSION TO ggadmin;

GRANT SELECT_CATALOG_ROLE TO ggadmin;

GRANT ALTER SYSTEM, ALTER USER TO ggadmin;

GRANT DATAPUMP_EXP_FULL_DATABASE, DATAPUMP_IMP_FULL_DATABASE TO ggadmin;

GRANT CREATE DATABASE LINK TO ggadmin;

 

EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN');

A trap Arjun almost fell into: Oracle's published example grant list also includes roles like DV_GOLDENGATE_ADMIN and DV_GOLDENGATE_REDO_ACCESS. Those are Database Vault roles from 12c onward. To my knowledge they don't exist on 11.2.0.4, so I left them out. Confirm before you run the docs' example verbatim:

sql

SELECT role FROM dba_roles WHERE role LIKE 'DV_GOLDENGATE%';

Zero rows on an 11.2.0.4 source is expected. Also compare my grant list against the current DMS documentation for your exact setup, because privilege requirements change between releases.

4.5 Find the landmines: unsupported objects and missing keys

This is where PMs earn their salary, by turning technical risks into a backlog. GoldenGate applies row-level changes, so it needs a way to identify each row uniquely.

sql

-- Tables that Oracle's replication engines cannot capture

SELECT owner, table_name, reason

FROM   dba_streams_unsupported

WHERE  owner NOT IN ('SYS','SYSTEM','OUTLN','DBSNMP','SYSMAN','XDB','CTXSYS',

                     'MDSYS','ORDSYS','WMSYS','EXFSYS','APPQOSSYS')

ORDER  BY owner, table_name;

 

-- Tables with no primary key or unique constraint

SELECT t.owner, t.table_name

FROM   dba_tables t

WHERE  t.owner NOT IN ('SYS','SYSTEM','OUTLN','DBSNMP','SYSMAN','XDB','CTXSYS',

                       'MDSYS','ORDSYS','WMSYS','EXFSYS','APPQOSSYS')

AND    NOT EXISTS (SELECT 1

                   FROM   dba_constraints c

                   WHERE  c.owner = t.owner

                   AND    c.table_name = t.table_name

                   AND    c.constraint_type IN ('P','U'))

ORDER  BY t.owner, t.table_name;

For a table without a key, the options are adding a surrogate key, defining a substitute key in the replication configuration, or accepting the overhead of logging all columns. That's a design decision for the application team, not something to discover at 2 a.m.

The infographic's "Some objects and data types may not be supported" bullet sums this up.

Chapter 5: Pre-Migration Validation

(Workflow Step 3)

DMS has a built-in validation step. It checks configuration, privileges, and compatibility, and it surfaces issues before any data moves. Arjun treats it as a gate, and Priya treats it as a release criterion: no validation, no load.

The target gets its own sanity check:

sql

-- On the 19c target

SELECT name, open_mode FROM v$database;

SELECT banner FROM v$version;

 

SELECT parameter, value

FROM   nls_database_parameters

WHERE  parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

The character sets should match the source. If they don't, that's a conversation to have now.

Chapter 6: The Two Engines: Data Pump, Then GoldenGate

(Workflow Steps 4–5)

The initial load uses Data Pump. The source stays online and available, and the duration depends on data size and network bandwidth, which is exactly why Section 4.1 mattered.

Data Pump captures a consistent point in time. That instant is an SCN, and you can see the same kind of marker on the source:

sql

SELECT current_scn FROM v$database;

Everything before that point arrives with the bulk load. Everything after it is picked up by GoldenGate, which mines the redo and replays the changes on the target. Together they close the gap.

Then comes the phase where the migration feels alive: replication lag shrinks, hovers near zero, and stays there. The infographic's note that "synchronization continues until lag = 0" is the definition of ready. Priya put that metric on the project dashboard, because it answers the business's question ("how close are we?") in a single line.

Chapter 7: The Cutover, Ten Minutes That Took Three Weeks to Prepare

(Workflow Step 6)

Cutover is a choreographed sequence:

1. Stop application writes.
2. Let replication drain until lag reaches zero and the final changes land.
3. Validate the target.
4. Switch the application to the OCI connection string.
5. Keep the source untouched, as your fallback.

Validation is where the "Wait, is it really identical?" question gets answered. Some queries to run on both sides and compare:

sql

-- Object inventory

SELECT owner, object_type, COUNT(*) AS cnt

FROM   dba_objects

WHERE  owner IN ('APP_OWNER')          -- your schemas

GROUP  BY owner, object_type

ORDER  BY 1, 2;

 

-- Invalid objects (expect this to be the same or lower on the target)

SELECT owner, object_type, COUNT(*) AS invalid_cnt

FROM   dba_objects

WHERE  status = 'INVALID'

AND    owner IN ('APP_OWNER')

GROUP  BY owner, object_type;

 

-- Sequences: the values the application will read next

SELECT sequence_owner, sequence_name, last_number

FROM   dba_sequences

WHERE  sequence_owner IN ('APP_OWNER')

ORDER  BY 1, 2;

For row counts, generate the comparison statements instead of hand-writing them:

sql

SELECT 'SELECT ''' || owner || '.' || table_name ||

       ''' AS tbl, COUNT(*) AS cnt FROM ' || owner || '.' || table_name || ';'

FROM   dba_tables

WHERE  owner = 'APP_OWNER';

Run the generated statements on both databases and diff the output. Exact row counts on large tables take time, so decide in advance which tables get full counts and which get sampled checks or checksums. Sequences deserve special attention because they keep advancing on the source after the snapshot. Confirm how your migration handles them and verify the values before the application resumes.

Cutover also needs a decision that goes beyond the technical work: the fallback plan. The infographic warns that "cutover and fallback require careful planning." Replication is one-way (source → target), so once the application writes to 19c, the old database is no longer in sync. Rolling back after that point means data loss unless you've built a reverse path. Priya made the call explicit: a go/no-go checkpoint, agreed with the business, with a defined point of no return.

Chapter 8: After the Migration

(Workflow Step 7)

The migration isn't done when the application connects. It's done when:

• Application and performance tests pass against 19c. The optimizer changed between 11g and 19c, so plan regressions are the most likely surprise.
• Backups are configured (OCI Backup) and a restore has been tested.
• Monitoring is in place, and someone owns the alerts.
• The old environment is retired on a schedule, not left running "just in case."

A quick way to spot regressions is to compare the top SQL by elapsed time before and after:

sql

SELECT * FROM (

  SELECT sql_id, executions,

         ROUND(elapsed_time/1000000,1) AS elapsed_s,

         ROUND(elapsed_time/NULLIF(executions,0)/1000,1) AS ms_per_exec,

         SUBSTR(sql_text,1,80) AS sql_text

  FROM   v$sql

  ORDER  BY elapsed_time DESC

) WHERE ROWNUM <= 20;

Chapter 9: What the Architect and PM Each Took Away

Arjun (architect):

• Online migration shrinks the cutover window, not the effort. The work moves earlier, into preparation.
• Bandwidth sets the pace of the initial load and of replication lag. Measure it before promising dates.
• Unsupported types, missing keys, and DDL activity during the load are where the surprises live. Query for them early.

Priya (product manager):

• The best migration metric is replication lag, because it maps directly to the business's downtime question.
• Treat validation gates as release criteria and the cutover fallback as a product decision.
• Communicate in outcomes ("we're 3 minutes behind and shrinking"), not in tool names.

Both would say the same thing about the infographic's last panel, "Key Considerations": the important points and the limitations are two sides of the same plan. Online migration minimizes the cutover window, and it demands bandwidth, compatibility checks, and cutover planning in return.

 

An OCI Architect's First Walk Through Generative AI

Every enterprise architect eventually gets that request from leadership: "Can we use AI on our data — without shipping it off to some third-party SaaS we don't control?" For me, that request landed on a Tuesday, and it sent me straight into the OCI Console, into a service I'd only skimmed the docs on: OCI Generative AI, tucked under Analytics & AI.

How Generative AI Actually Works

The intro walkthrough boiled the whole service down to three steps, and honestly, it's the cleanest mental model I've seen for explaining LLMs to a room full of database people:

1. Input — you provide text, examples, or instructions in natural language.
2. Analysis — the service processes that input and generates, summarizes, transforms, extracts, or classifies the text.
3. Output — you get a response back in the format you asked for.

Beyond the Pretrained Models: Fine-Tuning

The walkthrough didn't stop at "use what Oracle gives you." It also explained the path to a custom model: pick a pretrained base model, supply your own training file, and let OCI Generative AI fine-tune it for you — but only on dedicated AI clusters that belong exclusively to your tenancy. And fine-tuning is only half the story: once you have a custom model, you still need to create an endpoint and host that model on a dedicated cluster before anything can call it.

OCI Generative AI offers the following pretrained foundational models. Review the key features, regions, on-demand and dedicated AI cluster offerings, deprecation and retirement dates, and benchmarks for the models.

Ref: https://docs.oracle.com/en-us/iaas/Content/generative-ai/pretrained-models.htm

Two Doors: Chat and Embedding

The Playground, I learned, isn't one tool — it's two modes wearing the same UI:

• Chat lets you ask questions and get conversational responses. The chat models hold context across the conversation, so you can ask follow-ups, and you control format, length, and tone.
• Embedding converts text into vector representations — the raw material for semantic search, text classification, and clustering.

A few things I'll be repeating in the design review:

1. **Pretrained models get you started for free** — on-demand, no cluster required — but production fine-tuning and hosting custom models both require dedicated AI clusters scoped to your tenancy.

2. **Watch the lifecycle labels.** The model picker flags deprecated models inline; it's worth building a habit of checking that before locking a model into an application.

3. **Chat and Embedding are two ends of the same pipeline.** Chat is the conversational front door; Embedding is the semantic index underneath it. Most real projects need both.

4. **The console mirrors infrastructure thinking a DBA already has** — clusters, capacity, endpoints, versioning — which makes this a much shorter ramp-up for an OCI architect than the "AI" branding might suggest.