Oracle DBA to PostgreSQL

The Oracle DBA’s Guide to Surviving (and Thriving) in AWS RDS PostgreSQL

A practical field guide for experienced Oracle professionals moving from RAC, RMAN, and operating-system control to managed PostgreSQL in the AWS cloud.

Contents

1. The Language of the Cloud
2. You No Longer Own the Metal
3. The Storage Trap
4. Undo vs. MVCC
5. Multi-AZ: Safety vs. Speed
6. The PITR Catch
7. The Connection Crisis
8. The Graviton Opportunity
9. The Craft Remains

1. Introduction: The Language of the Cloud

For those of us who have spent decades in the trenches of Oracle E-Business Suite, managing RAC nodes, reviewing AWR reports, and wrestling with RMAN scripts, moving to PostgreSQL on Amazon RDS can feel like learning a new dialect of a language we already speak fluently.

The grammar remains familiar. We still think about memory, storage, transactions, execution plans, availability, recovery, security, and performance. But the daily rituals have changed.

The most fundamental shift is the AWS Shared Responsibility Model. AWS manages the physical infrastructure and many routine platform tasks, while the customer remains responsible for data, access, schema design, configuration choices, SQL performance, monitoring, and recovery readiness.

In simple terms, your job moves from managing the entire server stack to managing the database service boundary.

The mindset shift: You are no longer the owner of every layer. You are the architect and operator of the layers that directly affect the business.

2. Takeaway 1: You No Longer Own the “Metal” — and That Is a Good Thing

In the on-premises Oracle world, root access and SSH access often felt like a DBA birthright. In Amazon RDS, that boundary is intentionally fixed. AWS manages the underlying host, operating system, database software installation, infrastructure replacement, and many patching and backup activities.

You manage the database-facing layer: schemas, roles, privileges, extensions, parameter groups, option choices, maintenance windows, queries, indexes, statistics, monitoring, and application connectivity.

As a senior architect, I see this as a strategic trade-off. You lose the ability to tune the kernel or inspect every operating-system process, but you gain time to focus on architecture, security, automation, cost, SQL efficiency, and business continuity.

Amazon RDS removes much of the undifferentiated infrastructure work so the DBA can spend more time improving the reliability and value of the data platform.

Success in RDS depends on knowing which controls AWS exposes, which settings require a parameter group, which changes require a reboot, and which parts of the platform are intentionally managed for you.

3. Takeaway 2: The Storage Trap — It Only Goes One Way

Oracle DBAs are accustomed to adding data files, resizing tablespaces, moving segments, reclaiming space, and reorganizing storage. Amazon RDS storage behaves differently: allocated storage can be increased, but it cannot be reduced on the existing DB instance.

If you allocate far more capacity than required, you continue paying for that allocation unless you migrate or restore the database into a differently sized replacement environment.

Production rule: Enable storage autoscaling with a carefully chosen maximum threshold, monitor FreeStorageSpace, and alert well before the database reaches a critical storage condition.

Storage autoscaling is valuable, but it should not replace capacity planning. Unexpected growth can result from table bloat, retained WAL, large temporary operations, failed maintenance, excessive logging, or an application defect.

The experienced DBA’s storage principle is straightforward: start with justified capacity, monitor aggressively, and grow deliberately.

4. Takeaway 3: Rethinking the Architecture — Undo vs. MVCC

This is one of the largest conceptual changes for an Oracle veteran. Oracle maintains older versions of changed data using Undo. PostgreSQL implements Multi-Version Concurrency Control by retaining row versions within the table structure.

When rows are updated or deleted, older row versions can remain as dead tuples until PostgreSQL reclaims or marks that space reusable. This makes VACUUM and autovacuum central to PostgreSQL health.

Poorly tuned autovacuum can lead to table and index bloat, inaccurate optimizer statistics, degraded query performance, and increased storage consumption. In an extreme case, failure to control transaction ID age can create a transaction ID wraparound risk.

Memory starting points — not universal rules

• shared_buffers: Around 25% of RAM is a common initial guideline for a dedicated PostgreSQL host, but the final value must be tested.
• effective_cache_size: Often estimated near 50–75% of RAM as a planner hint; it does not reserve that memory.
• work_mem: Treat with caution because it can be allocated multiple times per query and across many concurrent sessions.
• maintenance_work_mem: Size for maintenance operations while considering concurrent autovacuum workers.

The important lesson is not to copy a memory formula blindly. Build a total memory budget based on instance RAM, connection count, query concurrency, parallelism, maintenance activity, and operating overhead.

In PostgreSQL, autovacuum is not housekeeping. It is part of the core availability and performance architecture.

5. Takeaway 4: Multi-AZ Is Primarily for Availability — Not Automatically for Read Scaling

Oracle DBAs may associate standby databases with both disaster recovery and reporting, especially when Active Data Guard is part of the architecture. In Amazon RDS, high availability and read scaling depend on the deployment type.

RDS Option	Primary Purpose	Readable?	Replication Model
Multi-AZ DB instance deployment	High availability and automatic failover	No — the standby does not serve read traffic	Synchronous
Multi-AZ DB cluster	High availability with two readable standby instances	Yes	Synchronous replication to standbys
Read replica	Read scaling, reporting, and selected recovery patterns	Yes	Asynchronous

A traditional Multi-AZ DB instance deployment usually fails over in approximately 60–120 seconds, depending on database activity and recovery conditions. A Multi-AZ DB cluster is designed for faster failover, which AWS describes as typically under 35 seconds.

Choose the architecture based on recovery objectives, workload characteristics, read requirements, cost, regional strategy, and application retry behavior—not simply because “Multi-AZ” appears in the name.

6. Takeaway 5: The PITR Catch — Recovery Creates a New Instance

Point-in-Time Recovery in Amazon RDS is operationally simple, but it includes an important design reality: the restore creates a new DB instance. It does not rewind the existing production instance in place.

That new instance requires validation and may require the reapplication or verification of infrastructure settings and integrations surrounding the database.

Your recovery runbook should verify:

• DB subnet group and network placement
• VPC security groups and routing
• DB parameter group and required static parameters
• KMS encryption configuration
• IAM database authentication and application roles
• Secrets Manager entries and connection strings
• CloudWatch alarms, log exports, and monitoring settings
• DNS, application endpoints, and failback steps
• Post-restore validation of data, users, extensions, and jobs

A recovery procedure you have never executed is only a document. Test PITR and application reconnection regularly.

A quarterly recovery exercise is a practical starting point for critical systems, but the frequency should be driven by compliance requirements and the business recovery-time and recovery-point objectives.

7. Takeaway 6: The Connection Crisis and the RDS Proxy Option

PostgreSQL uses a process-based connection model, and a large number of active or rapidly created sessions can consume significant memory and CPU. This becomes especially important with microservices, containers, bursty workloads, and AWS Lambda functions.

The first defense is good application-side connection management. Use persistent pools, define sensible timeouts, close abandoned sessions, and avoid setting max_connections to an unnecessarily high value.

Amazon RDS Proxy is strongly worth evaluating for workloads with frequent connection churn or unpredictable spikes. It pools and reuses database connections, helps protect the database from connection storms, and can preserve many application connections during failover events.

Important: RDS Proxy is not a substitute for SQL tuning or sound application pooling. Test for transaction pinning, session state, prepared statements, authentication design, latency, and cost before adopting it.

8. Takeaway 7: Graviton — A High-Value Cost and Performance Opportunity

AWS Graviton-powered RDS instance families use Arm-based processors and are available in several general-purpose and memory-optimized classes, including instance names with a g suffix such as db.m7g and db.r7g.

For many standard PostgreSQL workloads, Graviton can provide attractive price-performance. It should be included in the default evaluation for new deployments, but it should not be selected only from a marketing percentage.

Benchmark your actual workload, verify extension compatibility, compare CPU utilization, query latency, I/O behavior, throughput, and licensing or tooling dependencies, and then make the decision using measured cost per transaction.

Graviton is not a magic switch. It is a strong architectural option that deserves workload-based testing.

9. Conclusion: The Platform Changes, the Craft Remains

The tools change. SIDs become managed instances. RAC architecture becomes an RDS availability design. RMAN scripts become automated backups and snapshots. SSH access disappears. Parameter files become parameter groups. Operating-system troubleshooting becomes service-level observability.

Yet the core discipline of the DBA remains essential. SQL tuning, indexing, statistics, capacity planning, security, monitoring, recovery validation, and calm incident management still determine whether a system is reliable.

The best Oracle DBAs do not become less valuable in a managed database service. They become more focused. Their attention moves away from repetitive infrastructure work and toward engineering decisions that directly affect performance, resilience, security, and cost.

The platform changes; the craft does not.

Are you ready to stop managing servers and start optimizing the data platform that drives your business?

Official References

• Amazon RDS User Guide — Overview
• Managing capacity with RDS storage autoscaling
• Configuring and managing RDS Multi-AZ deployments
• Restoring an RDS DB instance to a specified time
• Amazon RDS Proxy
• Amazon RDS DB instance classes
• PostgreSQL documentation — Routine vacuuming
• PostgreSQL documentation — Resource consumption

© 2026 Punit Kumar. Built as a practical guide for Oracle DBAs transitioning to AWS RDS for PostgreSQL.

Oracle Exadata Smart Scan & Storage Index

Oracle Exadata Smart Scan & Storage Index — What Every DBA Must Know

A practical DBA guide to Smart Scan, Storage Indexes, verification queries, and real-world Exadata tuning.

Oracle Exadata Smart Scan & Storage Index — What Every DBA Must Know

Introduction

You bought Exadata. Management expects magic. Queries are still slow.

Sound familiar?

Exadata is not a "plug it in and queries fly" machine. The hardware is extraordinary, but the performance gains — the ones that justify the price tag — come from two specific features: Smart Scan and Storage Indexes. If these aren't firing, you're running a very expensive conventional Oracle database.

I've worked as an Exadata DMA (Database Machine Administrator) across multiple clients. This article covers what Smart Scan and Storage Index actually are, exactly when they fire (and when they don't), how to verify them in production, and the tuning moves that make the difference.

---

What is Smart Scan?

Smart Scan is Exadata's most important feature. Instead of shipping raw data blocks from storage cells to the database server (the traditional I/O model), Smart Scan pushes SQL processing down to the storage layer.

Traditional Oracle I/O vs Smart Scan

TRADITIONAL MODEL:
┌─────────────────────┐           ┌──────────────────────┐
│   Database Server   │           │   Storage (SAN/NAS)  │
│                     │           │                      │
│  SQL Engine         │◀──blocks──│  Raw data blocks     │
│  (does all work)    │           │  (no intelligence)   │
└─────────────────────┘           └──────────────────────┘
  Network: moves EVERYTHING — even rows that will be filtered out

EXADATA SMART SCAN:
┌─────────────────────┐           ┌──────────────────────┐
│   Database Server   │           │   Exadata Cell       │
│                     │           │                      │
│  SQL Engine         │◀──results─│  Cell Offload Engine │
│  (receives results) │           │  - Applies WHERE      │
│                     │           │  - Projects columns   │
│                     │           │  - Evaluates joins    │
└─────────────────────┘           └──────────────────────┘
  Network: moves ONLY qualifying rows and projected columns

The Exadata cell (storage node) has its own CPU running the Cell Offload Engine. It applies your WHERE clause predicates, column projection, and even join filtering before any data leaves storage. The database server receives results, not raw blocks.

What Smart Scan Offloads

• Row filtering — WHERE salary > 100000 applied at storage, only matching rows returned
• Column projection — SELECT name, dept only returns those two columns, not the full row
• JOIN filtering — Bloom filters pushed to storage for hash joins
• Aggregation — Some GROUP BY and COUNT operations
• Storage Index evaluation — See next section

---

What is a Storage Index?

A Storage Index is an in-memory structure that lives on each Exadata storage cell. It is not a traditional B-tree or bitmap index — it doesn't live in your tablespace, has no segment, and consumes no disk space.

Each storage cell maintains a Storage Index for every 1 MB of data on disk (called a Storage Region). For each region, the Storage Index records:

Storage Region (1 MB of data)
┌────────────────────────────────────────────────┐
│  Column: SALARY                                │
│    MIN value in this region: 45,000            │
│    MAX value in this region: 92,000            │
│  Column: DEPARTMENT_ID                         │
│    MIN value in this region: 10                │
│    MAX value in this region: 80                │
│  Column: HIRE_DATE                             │
│    MIN value in this region: 01-JAN-2010       │
│    MAX value in this region: 31-DEC-2015       │
└────────────────────────────────────────────────┘

When your query has WHERE SALARY > 150000, the cell checks its Storage Index:

• If the region's MAX SALARY is 92,000, the entire 1 MB region is skipped — no I/O at all
• If the region's MAX is 180,000 (could contain matching rows), the region is read

This is pure I/O elimination — the most powerful type of performance gain.

Storage Index Properties

• Automatically maintained — Oracle builds and updates it as data is written and read
• In-memory only — Lives in cell RAM, not persisted to disk (rebuilt after cell restart)
• Per-column, per-region — Each 1 MB storage region has MIN/MAX for up to 8 columns
• Tracks NULLs — Knows if a region has no NULLs (enables further optimization)
• No DBA action required to create — But DBA actions can prevent it from working

---

When Does Smart Scan Fire? (The Conditions)

This is where most DBAs get confused. Smart Scan does not fire on every query. It has strict prerequisites.

Condition 1: Full Table Scan or Full Index Scan

-- Smart Scan CAN fire (full scan)
SELECT * FROM sales WHERE region = 'WEST';

-- Smart Scan CANNOT fire (index lookup, single block I/O)
SELECT * FROM sales WHERE sale_id = 12345;

Smart Scan requires multi-block I/O (db file scattered read or direct path read). Single-block I/O from index lookups bypasses Smart Scan entirely.

Condition 2: Direct Path Read

The scan must use direct path reads (bypassing the buffer cache). This happens automatically when:

• The table is larger than _small_table_threshold (typically ~2% of buffer cache)
• Parallel query is used
• Serial full scans on large tables (11g R2+ auto-decides)

-- Force direct path read for testing
ALTER SESSION SET "_serial_direct_read" = TRUE;

Condition 3: Exadata Storage (Cells Must Serve the Data)

Smart Scan only works for data stored on Exadata cells. Data in:

• ASM diskgroups on non-Exadata storage → No Smart Scan
• Locally-attached disks on non-cell nodes → No Smart Scan
• Exadata Smart Flash Cache → Smart Scan still applies

Condition 4: No Incompatible Operations in the Query

Certain operations prevent Smart Scan offload even on Exadata:

Operation	Smart Scan?	Why
Full table scan	✅ YES	Multi-block direct path
Parallel full scan	✅ YES	Direct path
Full index scan	✅ YES (in some cases)	Multi-block
Index range scan	❌ NO	Single-block I/O
ROWID access	❌ NO	Single-block I/O
Encrypted columns (TDE)	❌ NO	Cell cannot decrypt
Object types / XMLType	❌ NO	Complex types
SELECT FOR UPDATE	❌ NO	Locks prevent offload
Dictionary tables	❌ NO	Small, always cached

---

When Does Storage Index Fire?

Storage Index is even more selective. It fires when:

1. Smart Scan is already active (prerequisite)
2. The WHERE clause predicate is on a column tracked by the Storage Index
3. The predicate allows MIN/MAX elimination (range, equality, IN list)

Predicates That Work with Storage Index

-- These predicates enable Storage Index elimination
WHERE salary > 100000          -- range scan, MIN/MAX comparison
WHERE hire_date < DATE '2015-01-01'  -- date range
WHERE department_id = 50       -- equality (if not in range)
WHERE region IN ('EAST','WEST') -- IN list (checks each value)
WHERE status IS NULL           -- NULL check (if region has no NULLs)

Predicates That DON'T Work with Storage Index

-- Functions defeat Storage Index
WHERE UPPER(last_name) = 'SMITH'    -- function wrapping
WHERE TRUNC(hire_date) = SYSDATE-30 -- function on column
WHERE salary * 1.1 > 100000         -- arithmetic on column

-- LIKE with leading wildcard
WHERE product_name LIKE '%WIDGET%'  -- can't use MIN/MAX

-- Columns not in the Storage Index (tracked up to 8 per region)
WHERE rarely_queried_col = 'X'   -- may not be tracked

Key rule: Never wrap a filterable column in a function if you want Storage Index (or any index) to work.

---

How to Verify Smart Scan is Working

Method 1: V$SQL Statistics

-- Check Smart Scan stats for a specific SQL
SELECT
    s.sql_id,
    s.sql_text,
    s.executions,
    s.io_cell_offload_eligible_bytes / 1024 / 1024 / 1024 AS offload_eligible_gb,
    s.io_cell_offload_returned_bytes  / 1024 / 1024 / 1024 AS returned_gb,
    ROUND(
        (1 - s.io_cell_offload_returned_bytes /
             NULLIF(s.io_cell_offload_eligible_bytes, 0)) * 100, 2
    ) AS offload_efficiency_pct,
    s.io_interconnect_bytes / 1024 / 1024 AS interconnect_mb
FROM v$sql s
WHERE sql_id = '&your_sql_id'
AND   s.io_cell_offload_eligible_bytes > 0;

What to look for:

• offload_eligible_gb — how much data was eligible for Smart Scan
• returned_gb — how much came back to the DB server
• offload_efficiency_pct — aim for > 90% for analytical queries
• If offload_eligible_bytes = 0 → Smart Scan is NOT firing

Method 2: Session-Level Statistics (For Testing)

-- Enable extended stats collection
ALTER SESSION SET STATISTICS_LEVEL = ALL;
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';

-- Run your query
SELECT COUNT(*) FROM sales WHERE region = 'WEST' AND amount > 10000;

-- Check session stats
SELECT n.name, s.value
FROM   v$mystat s
JOIN   v$statname n ON n.statistic# = s.statistic#
WHERE  n.name IN (
    'cell physical IO bytes eligible for predicate offload',
    'cell physical IO bytes saved by storage index',
    'cell physical IO bytes sent directly to DB node to balance CPU',
    'cell IO uncompressed bytes',
    'cell physical IO interconnect bytes'
)
AND s.value > 0
ORDER BY n.name;

The most important stat: cell physical IO bytes saved by storage index

• If this is > 0, Storage Index is eliminating I/O
• Compare to cell physical IO bytes eligible for predicate offload to see the ratio

Method 3: Execution Plan — Look for These Keywords

EXPLAIN PLAN FOR
SELECT /*+ FULL(s) */ COUNT(*) FROM sales s WHERE region = 'WEST';

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(FORMAT => 'ALL'));

Look for in the Notes section:

NOTE
-----
   - automatic DOP: Computed Degree of Parallelism is 1 because of target master table  
   - cell offloading enabled for this statement           ← Smart Scan IS firing
   - storage index used for this statement                ← Storage Index IS firing

Method 4: AWR — Top Exadata Cell Stats

-- Find top SQL by offload efficiency from AWR
SELECT
    sql_id,
    ROUND(SUM(io_cell_offload_eligible_bytes)/1073741824, 2) AS eligible_gb,
    ROUND(SUM(io_cell_offload_returned_bytes)/1073741824, 2)  AS returned_gb,
    ROUND((1 - SUM(io_cell_offload_returned_bytes)/
               NULLIF(SUM(io_cell_offload_eligible_bytes),0))*100, 1) AS efficiency_pct
FROM dba_hist_sqlstat
WHERE snap_id BETWEEN &begin_snap AND &end_snap
AND   io_cell_offload_eligible_bytes > 0
GROUP BY sql_id
ORDER BY eligible_gb DESC
FETCH FIRST 20 ROWS ONLY;

Method 5: CellCLI on Storage Cell (DMA Access Required)

If you have access to the storage cells via cellcli:

# SSH to a cell node
ssh root@cel01

# Check Smart Scan statistics
cellcli -e "list metriccurrent where name like 'CD_IO%' or name like 'CS_IO%'"

# Key metrics to check:
# CD_IO_BY_R_SM      — bytes read by Smart Scan
# CD_IO_BY_R_SM_INCR — increment (last interval)
# CS_IO_BY_SS        — Smart Scan bytes per second

# Check Storage Index effectiveness
cellcli -e "list metriccurrent where name like 'CS_SINDEX%'"
# CS_SINDEX_SCANS    — number of Storage Index scans
# CS_SINDEX_PASSES   — regions passed (read)
# CS_SINDEX_SKIPPPED — regions skipped (eliminated!) ← this is the money metric

CS_SINDEX_SKIPPED is your proof of Storage Index working. A high ratio of skipped to passed = Storage Index is highly effective.

---

Real-World Tuning Scenarios

Scenario 1: Smart Scan Not Firing — Small Table Issue

Symptom: io_cell_offload_eligible_bytes = 0 for a query on a 50 GB table.

Cause: Table was recently queried and blocks are in the buffer cache. Serial queries on tables whose blocks are cached use buffer cache reads (not direct path), which bypasses Smart Scan.

Fix:

-- Force direct path for this session
ALTER SESSION SET "_serial_direct_read" = TRUE;

-- Or use parallel query (always uses direct path)
SELECT /*+ PARALLEL(t, 4) */ COUNT(*) FROM big_table t WHERE ...;

-- Or flush buffer cache (non-prod only!)
ALTER SYSTEM FLUSH BUFFER_CACHE;

Production approach: For ETL/reporting queries that should always use Smart Scan, use parallel hints or set at session level in the reporting connection.

Scenario 2: Low Offload Efficiency — Functions Killing Storage Index

Symptom: offload_efficiency_pct is only 15% on a query that filters heavily.

Problem Query:

SELECT * FROM orders
WHERE TRUNC(order_date) = TRUNC(SYSDATE) - 30
AND   UPPER(status) = 'COMPLETED';

Why it fails: TRUNC(order_date) and UPPER(status) wrap columns in functions. Cell Offload Engine cannot use Storage Index for these. It reads all blocks and filters at the cell CPU level (still offloaded but no storage index elimination).

Fix:

-- Rewrite to use range predicate on the column directly
SELECT * FROM orders
WHERE order_date >= TRUNC(SYSDATE) - 30
AND   order_date  < TRUNC(SYSDATE) - 29
AND   status = 'COMPLETED';  -- assuming data is stored uppercase

Now Storage Index can eliminate entire 1 MB regions where order_date range doesn't include the target date.

Scenario 3: Storage Index Not Effective — High Cardinality Data That's Not Clustered

Symptom: CS_SINDEX_SKIPPED is near zero even though you have a range predicate.

Cause: Data is randomly distributed across storage. If salary values are randomly scattered across all blocks, every 1 MB region has a MIN near 30,000 and MAX near 500,000. No region can be skipped.

Fix: Reorganize data to be clustered by the filter column.

-- Option 1: Use DBMS_REDEFINITION to reorganize by the most-filtered column
BEGIN
    DBMS_REDEFINITION.START_REDEF_TABLE(
        uname       => 'HR',
        orig_table  => 'EMPLOYEES',
        int_table   => 'EMPLOYEES_INT',
        col_mapping => NULL,
        options_flag => DBMS_REDEFINITION.CONS_USE_ROWID,
        orderby_cols => 'SALARY'   -- ← reorganize by filter column
    );
END;
/

-- Option 2: Create interim table with ORDER BY and exchange partition
CREATE TABLE employees_sorted AS
SELECT * FROM employees ORDER BY salary;

-- Option 3: Use Exadata Hybrid Columnar Compression (HCC) with QUERY LOW
-- HCC inherently sorts during compression, improving Storage Index effectiveness
ALTER TABLE fact_sales MOVE COLUMN STORE COMPRESS FOR QUERY LOW;

Scenario 4: Smart Scan Disabled by TDE

Symptom: Smart Scan stats show eligible bytes but near-zero offload efficiency. Encryption is enabled.

Cause: Transparent Data Encryption (TDE) at the column or tablespace level prevents the cell from reading the data (cells don't have the encryption key). Blocks must be sent to the DB server for decryption first.

Options:

1. Accept the limitation if TDE is a compliance requirement
2. Evaluate Oracle Key Vault + Cell-side decryption (available in newer Exadata software)
3. Use HCC (which compresses before encryption) to reduce data volume even without Smart Scan

Scenario 5: Parallel Query Degrading Performance

Symptom: Parallel query with 16 DOP is slower than serial query. Smart Scan shows high interconnect bytes.

Cause: Parallel slaves are fighting for interconnect bandwidth. Smart Scan sends results back via the interconnect — if you have 16 slaves all streaming data simultaneously, interconnect becomes the bottleneck.

Fix:

-- Check interconnect utilization
SELECT n.name, s.value / 1024 / 1024 AS value_mb
FROM   v$mystat s JOIN v$statname n ON n.statistic# = s.statistic#
WHERE  n.name = 'cell physical IO interconnect bytes';

-- Tune DOP — more is not always better
-- For a 4-cell Exadata, DOP = 4 * num_cores_per_cell is a starting point
-- Use Resource Manager to cap DOP per consumer group

-- Or use STATEMENT_QUEUING to serialize heavy queries
ALTER SESSION SET PARALLEL_DEGREE_POLICY = AUTO;

---

Monitoring Smart Scan in Production — Daily Checks

Quick Health Check Query

-- Run this daily to spot Smart Scan degradation
SELECT
    TO_CHAR(s.begin_interval_time, 'YYYY-MM-DD HH24') AS hour,
    SUM(st.io_cell_offload_eligible_bytes) / 1073741824 AS eligible_gb,
    SUM(st.io_cell_offload_returned_bytes)  / 1073741824 AS returned_gb,
    ROUND(
        (1 - SUM(st.io_cell_offload_returned_bytes) /
             NULLIF(SUM(st.io_cell_offload_eligible_bytes), 0)) * 100, 1
    ) AS offload_pct,
    SUM(st.io_interconnect_bytes) / 1073741824 AS interconnect_gb
FROM
    dba_hist_sqlstat    st,
    dba_hist_snapshot   s
WHERE st.snap_id = s.snap_id
AND   st.dbid    = s.dbid
AND   s.begin_interval_time >= SYSDATE - 1
AND   st.io_cell_offload_eligible_bytes > 0
GROUP BY TO_CHAR(s.begin_interval_time, 'YYYY-MM-DD HH24')
ORDER BY 1 DESC;

A healthy Exadata system should show offload_pct consistently above 85-90% for analytical/reporting workloads.

Alert: When Offload Drops

If offload efficiency drops significantly:

1. Check if new queries hit the system without Smart Scan (index lookups on large tables)
2. Check if TDE was enabled on a tablespace that previously had Smart Scan
3. Check if data distribution changed (new partitions with poorly clustered data)
4. Check cell health — a cell in degraded mode won't offload

-- Find queries with LOW offload efficiency (candidates for tuning)
SELECT
    sql_id,
    SUBSTR(sql_text, 1, 80) AS sql_preview,
    ROUND(io_cell_offload_eligible_bytes / 1073741824, 2) AS eligible_gb,
    ROUND(
        (1 - io_cell_offload_returned_bytes /
             NULLIF(io_cell_offload_eligible_bytes, 0)) * 100, 1
    ) AS offload_pct
FROM v$sql
WHERE io_cell_offload_eligible_bytes > 1073741824  -- > 1 GB eligible
AND   (1 - io_cell_offload_returned_bytes /
           NULLIF(io_cell_offload_eligible_bytes, 0)) < 0.5  -- < 50% efficient
ORDER BY io_cell_offload_eligible_bytes DESC
FETCH FIRST 10 ROWS ONLY;

---

Hybrid Columnar Compression (HCC) — Smart Scan's Best Friend

HCC is the Exadata storage compression format that works hand-in-hand with Smart Scan. Compressed data is still readable by the Cell Offload Engine — in fact, HCC actually makes Smart Scan faster because:

1. Less data to read from disk (compression ratio of 10x-50x for QUERY LOW/HIGH)
2. Storage Index becomes more effective (similar values cluster together in compression units)
3. Interconnect traffic drops proportionally

-- Compress a fact table for reporting (read-mostly)
ALTER TABLE fact_sales MOVE COLUMN STORE COMPRESS FOR QUERY LOW;

-- Compress historical/archive data (rarely read)
ALTER TABLE fact_sales_archive MOVE COLUMN STORE COMPRESS FOR ARCHIVE HIGH;

-- Check compression ratio
SELECT
    table_name,
    compress_for,
    blocks,
    num_rows,
    ROUND(blocks * 8192 / 1024 / 1024, 1) AS actual_mb,
    ROUND(num_rows * avg_row_len / 1024 / 1024, 1) AS raw_mb,
    ROUND(num_rows * avg_row_len / NULLIF(blocks * 8192, 0), 2) AS compression_ratio
FROM dba_tables
WHERE table_name IN ('FACT_SALES', 'FACT_SALES_ARCHIVE')
ORDER BY table_name;

HCC + Smart Scan is the combination that delivers the 10x-100x performance improvements you see in Exadata benchmarks.

---

Common Misconceptions

"More indexes = better Exadata performance"
Wrong. More indexes mean more index lookups, which means single-block I/O, which bypasses Smart Scan. On Exadata, carefully consider whether a full scan with Smart Scan is faster than an index scan. Often it is, especially for queries returning > 5% of a table.

"Smart Scan replaces the need for partitioning"
Partially true. Storage Index provides "soft partitioning" by eliminating storage regions. But formal partitioning is still valuable because it eliminates I/O at a higher level (entire partition pruning) before Smart Scan even runs. Use both.

"Storage Index is the same as an index"
No. A storage index only stores MIN/MAX per region. It can't do precise lookups. It's an elimination mechanism, not a navigation mechanism. Think of it as a bloom filter for I/O regions.

"Exadata Smart Scan works for OLTP"
Generally no. OLTP workloads use index lookups (single-block I/O). Smart Scan targets full scans — OLAP, reporting, analytics, data warehouse, batch ETL. Exadata benefits OLTP through other features like Smart Flash Cache and Infiniband, not Smart Scan.

---

Quick Reference — Smart Scan Troubleshooting Checklist

Is Smart Scan firing at all?
  ├── Check v$sql.io_cell_offload_eligible_bytes > 0
  │     = 0 → Smart Scan NOT firing
  │     ↓
  ├── Is the query doing a full table/index scan?
  │     NO → Use FULL hint or remove the index
  │     ↓
  ├── Is direct path read happening?
  │     Check v$session_event for 'direct path read'
  │     NO → Table may be in buffer cache; try ALTER SESSION SET "_serial_direct_read"=TRUE
  │     ↓
  └── Is data on Exadata cells?
        Check dba_data_files for ASM diskgroup on Exadata cells

Is Smart Scan firing but inefficient?
  ├── offload_efficiency_pct < 50%?
  │     ├── TDE enabled? → Cells can't offload encrypted data
  │     ├── Functions on WHERE columns? → Rewrite predicates
  │     └── Complex data types? → XMLType, objects prevent offload
  │
  └── Storage Index not eliminating regions?
        ├── Check v$mystat for 'cell physical IO bytes saved by storage index'
        ├── Data randomly distributed? → Reorganize table ordered by filter column
        ├── High cardinality random data? → Consider HCC (improves clustering)
        └── Columns not tracked? → Storage Index tracks up to 8 cols per region

---

Summary

Smart Scan and Storage Index are the two pillars of Exadata performance for analytical workloads. Here's the condensed DBA checklist:

To maximize Smart Scan:

• Design queries to use full scans on large tables (avoid unnecessary indexes for analytics)
• Use parallel query for consistently large scans
• Avoid TDE on performance-critical reporting tablespaces where possible
• Avoid functions on WHERE clause columns

To maximize Storage Index:

• Write range predicates directly on columns (no function wrapping)
• Cluster data physically by the most frequently filtered columns
• Use HCC compression — it naturally improves Storage Index effectiveness
• Monitor cell physical IO bytes saved by storage index regularly

To verify everything is working:

• Query v$sql for io_cell_offload_eligible_bytes and efficiency ratios
• Use CellCLI on cells to check CS_SINDEX_SKIPPED ratio
• Run the AWR hourly offload trend query in production monitoring

The DBAs who get the most out of Exadata are the ones who understand why Smart Scan fires — and design their schemas, queries, and data layouts to exploit it. The machine will do the rest.

---

References

• Oracle Exadata Database Machine Administration Guide (MOS)
• Oracle White Paper: "Exadata Smart Scan and Storage Indexes" (Doc ID 1464468.1)
• MOS Note 1348116.1 — Troubleshooting Smart Scan Issues
• MOS Note 1361766.1 — Storage Index Internals
• CellCLI Reference Guide (Oracle Exadata documentation)

---

Oracle OCI Exadata Database Service – The Complete DBA Guide to Architecture, Performance, and High Availability

A practical guide for Oracle DBAs, cloud architects, and database professionals.

By Punit Kumar

Oracle Exadata is not just another database platform — it is an engineered system designed to remove performance bottlenecks and simplify database operations in the cloud.

Introduction

As Oracle Database Administrators, we are expected to deliver high performance, maximum availability, scalability, and security while keeping operational overhead low. Traditional database environments often require significant effort to tune storage, optimize I/O, manage hardware, and maintain high availability.

Oracle addresses these challenges with Oracle Exadata Database Service on Oracle Cloud Infrastructure (OCI). It is a fully managed database platform engineered specifically for Oracle Database workloads.

Oracle OCI Exadata Architecture

Figure 1: Oracle OCI Exadata Database Service Architecture

The architecture consists of five major components:

Client Applications
        ↓
Database Servers
        ↓
RDMA Network
        ↓
Storage Servers
        ↓
Persistent Storage

1. Client Applications

Applications connect to Oracle databases running on Exadata. These may include Oracle E-Business Suite, SAP, banking applications, healthcare systems, CRM platforms, ERP systems, and enterprise data warehouses.

2. Database Servers

Database servers host Oracle Database instances and perform SQL parsing, SQL optimization, transaction processing, PL/SQL execution, memory management, and background process activities.

In Exadata, database servers focus more on database processing while storage servers help reduce unnecessary I/O.

3. Storage Servers

Storage servers are the heart of Exadata. Unlike traditional storage, Exadata storage servers understand Oracle database blocks and can perform intelligent processing close to where the data resides.

• Smart Scan
• Predicate filtering
• Column filtering
• Smart Flash Cache
• Hybrid Columnar Compression

4. RDMA Network

RDMA stands for Remote Direct Memory Access. It provides ultra-low latency communication between database servers and storage servers with minimal CPU involvement.

This improves SQL performance, reduces CPU overhead, and increases overall throughput.

5. Persistent Storage

Persistent storage contains the physical Oracle database files, including datafiles, redo logs, control files, temp files, and archive logs.

Exadata Smart Technologies

Smart Scan

Smart Scan is one of the most powerful Exadata features. Instead of sending all database blocks to the database server, Exadata storage servers filter data at the storage layer and send only the required result set.

SELECT *
FROM customers
WHERE state = 'MD';

In a traditional system, the database server may receive a large amount of data and then filter it. In Exadata, the storage server performs filtering first, which reduces network traffic and improves performance.

Smart Flash Cache

Smart Flash Cache keeps frequently accessed data in flash storage. This improves read performance and reduces physical disk I/O without requiring manual tuning.

Hybrid Columnar Compression

Hybrid Columnar Compression provides high compression ratios and is especially useful for data warehouse, reporting, and historical data workloads.

RDMA Network

The RDMA network provides high-speed, low-latency communication between database and storage servers. This helps Exadata deliver excellent performance for both OLTP and analytical workloads.

High Availability and Disaster Recovery

Oracle RAC

Oracle Real Application Clusters allow multiple database instances to access the same database. If one node fails, other nodes continue serving users.

• High availability
• Load balancing
• Fault tolerance
• Reduced downtime

Oracle Data Guard

Oracle Data Guard protects databases against disaster scenarios by maintaining standby databases. If the primary database fails, the standby database can be activated.

• Physical standby
• Logical standby
• Synchronous or asynchronous replication
• Disaster recovery protection

Online Scaling

OCI Exadata Database Service supports online scaling of compute and storage resources.

Scale Compute

Add or remove database server resources to support changing workloads.

Scale Storage

Add storage capacity without major downtime to meet business growth and data retention needs.

Fully Managed by Oracle

Oracle manages the Exadata infrastructure so DBAs can focus on database administration, performance tuning, SQL optimization, security, and business support.

• Infrastructure management
• Operating system and software maintenance
• Patching and upgrades
• Monitoring and alerting
• Backup and recovery support
• Security and compliance

Security Features

OCI Exadata provides enterprise-grade security features such as:

• Transparent Data Encryption
• Identity and Access Management
• Virtual Cloud Network isolation
• Encryption at rest
• Encryption in transit
• Audit and compliance controls

Backup and Recovery

OCI Exadata supports automatic backups, point-in-time recovery, fast restore, and integration with Oracle Data Guard for stronger recovery protection.

Ideal Use Cases

• Oracle E-Business Suite
• ERP and CRM applications
• Banking and financial systems
• Healthcare platforms
• High-volume OLTP systems
• Data warehousing and analytics
• Database consolidation projects
• Mission-critical Oracle workloads

Key Takeaways for Oracle DBAs

Remember these seven points:

• Exadata is an engineered system optimized for Oracle Database.
• Smart Scan offloads processing to storage servers.
• Smart Flash Cache improves read performance.
• RDMA provides ultra-fast communication between database and storage servers.
• Oracle RAC provides high availability within a site.
• Oracle Data Guard provides disaster recovery across sites.
• OCI Exadata is fully managed, allowing DBAs to focus on database value.

Final Thoughts

Oracle OCI Exadata Database Service represents the next evolution of Oracle Database infrastructure. It combines intelligent storage, high-speed networking, automated cloud management, strong security, and built-in high availability.

For Oracle DBAs, Exadata knowledge is becoming an important cloud skill. Whether supporting Oracle EBS, OLTP systems, data warehouses, or enterprise consolidation, OCI Exadata provides a powerful platform for performance, reliability, and scalability.

About the Author: Punit Kumar is an Oracle DBA and Cloud Database professional with experience in Oracle Database, Oracle E-Business Suite, Exadata, OCI, AWS, high availability, disaster recovery, migrations, automation, and performance tuning.

SEO Keywords: Oracle OCI Exadata, Exadata Architecture, Oracle DBA, Smart Scan, Oracle RAC, Oracle Data Guard, RDMA, Smart Flash Cache, Oracle Cloud Infrastructure.

Oracle EBS Concurrent Manager — Inactive / No Manager: Root Cause, Diagnosis & Fix

📊 Oracle EBS DBA Series

Oracle EBS Concurrent Manager
Inactive / No Manager

Root cause, diagnosis & fix — with SQL scripts, OS commands, and proactive monitoring tips

👤 Oracle EBS DBA Specialist Lead 📅 June 2026 🕐 7 min read 🏭 Database: WCGATDB

---

You submit a concurrent request in Oracle EBS — maybe an AP Invoice Import, a Payee Import, or a custom XX program — and instead of "Pending → Normal", you see the two most dreaded words on the Requests screen:

Request 919988 — XX Payee Import (Providers) Inactive No Manager

This article breaks down exactly what this means, why it happens, and the step-by-step DBA fix to resolve it fast — whether you are on-premise or on AWS.

---

What does "Inactive / No Manager" mean?

Oracle EBS uses the Concurrent Processing (CP) framework to run background jobs. Every request is handled by a Concurrent Manager — specifically by a Work Shift assigned to that manager that is active at the time.

When you see Inactive / No Manager, Oracle is telling you:

• No Concurrent Manager is currently running that is eligible to process this request
• The request matched no active Work Shift, or no manager is up
• The Internal Concurrent Manager (ICM) may itself be down

💡 Tip

Think of the ICM as the "supervisor" and the specific managers (Standard, Payables, etc.) as "workers". If the supervisor is down, no worker gets assigned.

---

Common root causes

#	Root Cause	How to Confirm
1	Internal Concurrent Manager (ICM) is down	Check FNDSM / CM status in sysadmin
2	Standard Manager work shift not covering current time	Query FND_CONCURRENT_QUEUES
3	No work shift defined for custom manager	Check manager config in System Admin
4	Specific program assigned to manager with no active workers	Check manager specialization
5	Database listener or APPS connection issue	Check alert.log, tnsping
6	Adcmctl / OPMN services not started after patching	Run adcmctl.sh status
7	OS-level adop / patching left CM in stopped state	Review recent patch history

---

Step-by-step diagnosis

Step 1 — Check CM status from the front end

• Navigate to: System Administrator › Concurrent › Manager › Administer
• Check that Internal Manager shows Active status
• Check Standard Manager — Actual Processes should be > 0
• Look for any manager showing 0 Actual / 0 Running

Step 2 — Check at the OS level (EBS App tier)

# Source the environment
. /home/applmgr/<CONTEXT_NAME>.env

# Check CM processes
ps -ef | grep FNDLIBR
ps -ef | grep ICM

# Check adcmctl status
adcmctl.sh status apps/<apps_pwd>

Step 3 — Query the database directly

-- Check manager status
SELECT CONCURRENT_QUEUE_NAME,
       MANAGER_TYPE,
       RUNNING_PROCESSES,
       MAX_PROCESSES,
       WORKER_COUNT
FROM   FND_CONCURRENT_QUEUES_VL
WHERE  ENABLED_FLAG = 'Y';

-- Check if ICM is alive
SELECT NODE_NAME, STATUS_CODE
FROM   FND_CP_SERVICES
WHERE  SERVICE_HANDLE = 'FNDCPGSC';

Step 4 — Check work shifts

SELECT Q.CONCURRENT_QUEUE_NAME,
       W.SHIFT_NAME,
       W.FROM_TIME,
       W.TO_TIME,
       W.WORKERS
FROM   FND_CONCURRENT_QUEUES Q,
       FND_CV_SHIFTS_V W
WHERE  Q.CONCURRENT_QUEUE_ID = W.CONCURRENT_QUEUE_ID;

---

The fix — how to resolve it

Fix A — Restart the Concurrent Manager (most common fix)

# Stop all concurrent managers
adcmctl.sh stop apps/<apps_password>

# Wait 30-60 seconds, verify all FNDLIBR processes are gone
ps -ef | grep FNDLIBR | grep -v grep

# Start concurrent managers
adcmctl.sh start apps/<apps_password>

# Verify startup
adcmctl.sh status apps/<apps_password>

⚠️ Warning

Never hard-kill (kill -9) the ICM without a full stop/start cycle. This corrupts the CM state in FND tables and requires manual cleanup.

Fix B — Verify work shifts are configured

• Go to: System Administrator › Concurrent › Manager › Define
• Select the relevant manager (e.g., Standard Manager or your custom XX manager)
• Click Work Shifts button
• Ensure a shift exists that covers the current time (or use "Any" shift = 24x7)
• Set Workers to at least 1 (or match your workload)

Fix C — Deactivate & reactivate from Administer screen

• Navigate to: System Administrator › Concurrent › Manager › Administer
• Select the problematic manager
• Click Deactivate, wait 10 seconds
• Click Activate — this forces the ICM to reassign workers

Fix D — Resubmit the request

Once managers are confirmed Active with processes > 0, resubmit the original request. Oracle EBS does not automatically retry Inactive/No Manager requests — you must resubmit manually.

---

Real-world case: XX Payee Import (Providers)

Request ID 919988 — XX Payee Import (Providers) — was sitting with Phase: Inactive, Status: No Manager in database WCGATDB. Investigation revealed:

• The Standard Manager was up but had 0 Actual Processes due to a stale CM lock
• An adcmctl.sh stop/start resolved the stale lock
• After restart, resubmitting moved the request to: Pending → Normal → Complete ✓

💡 Tip

Always check if this affects only ONE specific program or ALL requests. If all requests are stuck, it is an ICM issue. If only one program, check program specialization rules on that manager.

---

Prevention: proactive monitoring

Check	Method	Frequency
ICM running	ps -ef + FND_CP_SERVICES query	Every 5 min
Manager actual processes = 0	FND_CONCURRENT_QUEUES_VL query	Every 10 min
Requests stuck > 30 min	FND_CONCURRENT_REQUESTS query	Every 15 min
Alert log CM errors	grep FNDLIBR alert.log	Hourly
adcmctl.sh status check	Shell script + email alert	Daily

-- Requests pending > 30 minutes with no manager
SELECT REQUEST_ID,
       CONCURRENT_PROGRAM_NAME,
       PHASE_CODE,
       STATUS_CODE,
       ROUND((SYSDATE - REQUEST_DATE)*1440,1) AS WAIT_MINS
FROM   FND_CONCURRENT_REQUESTS
WHERE  STATUS_CODE = 'I'
AND    PHASE_CODE  = 'I'
AND    (SYSDATE - REQUEST_DATE)*1440 > 30
ORDER  BY REQUEST_DATE;

---

Quick reference card

Symptom	Most likely cause	First action
All requests → No Manager	ICM down	adcmctl.sh stop/start
One program → No Manager	Manager specialization / no shift	Check Define Manager › Work Shifts
After patching → No Manager	CM not restarted post-patch	adcmctl.sh start
Intermittent No Manager	Work shift gap (midnight window)	Add 24x7 "Any" shift
No Manager after failover	CM pointed to wrong node	Check APPL_TOP / opmn.xml

---

Conclusion

The Inactive / No Manager error in Oracle EBS is almost always solvable quickly once you understand the Concurrent Manager architecture. The key steps are:

1. Verify ICM and manager status from the Administer screen and OS
2. Run adcmctl.sh stop/start if CM processes are absent
3. Check work shifts if only specific programs are affected
4. Resubmit the request — it will not auto-retry
5. Add proactive monitoring to catch this before users report it

These day-to-day fixes are what separate a reactive DBA from a proactive one. If you found this useful, share it with your EBS DBA team.

#OracleEBS #ConcurrentManager #EBSDBA #OracleApps #NoManager #OracleDBA #EBSAdmin #Exadata #AWS

Oracle EBS DBA Specialist Lead  |  Database Architect  |  EBS Expert  |  Exadata Specialist

EXADATA Architecture

EXADATA Architecture in simpe explanation

"Exadata is Oracle's engineered system — purpose-built hardware where the database servers and storage are designed together. Normal databases treat storage as a dumb disk. Exadata makes storage smart — each storage cell has its own CPU, so when you run a query, the WHERE clause gets pushed down to the storage layer. Only rows that match come back up. Less data moves, queries run faster. That's called Smart Scan. Everything is wired together over a 40 Gb/s InfiniBand fabric — no bottleneck. It's the go-to platform for large data warehouses, mixed OLTP, and Oracle EBS environments."

Exadata on Oracle Cloud Infrastructure — what OCI Exadata means for on-premises DBAs Pro The forward-looking post. Covers Exadata Cloud Service (ExaCS) and Exadata Cloud@Customer (ExaCC) — what they are, how they differ from on-premises Exadata, what changes for the DBA (patching, monitoring, administration), what stays the same, and whether your on-premises Exadata skills transfer directly. Gives the Oracle EBS DBA a complete picture of where Exadata is headed and how to position their skills.

Oracle Exadata Series — Basics to Pro  ·  Article 10 of 10  ·  punitoracledba.blogspot.com

Exadata on Oracle Cloud Infrastructure — What OCI Exadata Means for On-Premises DBAs

Oracle Exadata  |  ExaCS  |  ExaCC  |  OCI  |  Cloud DBA  |  Skills Transfer  |  9 min read

Exadata — Basics to Pro Series 1. What Is Exadata · 2. Hardware Components · 3. Architecture Deep Dive · 4. Smart Scan, Storage Indexes, HCC · 5. Monitoring · 6. Performance Tuning · 7. Administration · 8. Patching · 9. EBS on Exadata · 10. OCI Exadata

If you have been managing an on-premises Exadata system, at some point your organisation will ask about moving to the cloud — or your manager will forward an Oracle sales deck about Exadata Cloud Service. Your first question is a reasonable one: is this the same Exadata I already know, and does my experience transfer?

The answer to both is yes — with important qualifications. Oracle Exadata on OCI is the same engineered system, the same Smart Scan, the same storage cells, the same HCC, the same cellcli. But the operating model is fundamentally different. Some of what you do today on-premises, Oracle does for you in the cloud. Some of what you do on-premises, you still do in the cloud — but through different tools. And some things are genuinely new.

This article explains the three Exadata deployment options, the practical difference between ExaCS and ExaCC for a working DBA, what changes in your day-to-day role, and where your on-premises skills apply directly.

This is the final article in the Exadata Basics to Pro series. If you have read Articles 1 through 9, you already understand the technology that underpins all three Exadata deployment options. This article focuses on the operational differences — not the technology, which is the same across all three.

The Three Exadata Deployment Options

Oracle now offers Exadata in three commercially distinct delivery models. The underlying technology — the same X10M or X11M hardware, the same Exadata System Software, the same Smart Scan — is identical across all three. What differs is who owns the hardware, where it runs, who manages what, and how you pay.

Deployment	Where It Runs	Who Owns Hardware	Payment Model
On-Premises Exadata	Your data centre	You — capital purchase	Capex — buy hardware upfront, annual support
ExaCC — Exadata Cloud@Customer	Your data centre	Oracle — subscription lease	Opex — monthly subscription per OCPU
ExaCS — Exadata Cloud Service	Oracle's public cloud (OCI regions)	Oracle — fully managed	Opex — hourly or monthly per OCPU

The most important distinction for a DBA is not where the hardware runs — it is who manages what. That operating model split determines your day-to-day responsibilities entirely.

ExaCC — Exadata Cloud@Customer

ExaCC is Oracle's Exadata delivered as a cloud service inside your own data centre. Oracle installs the Exadata rack in your facility, but you consume it as a subscription service. Oracle retains ownership of the hardware and manages it remotely — just as they would in their public cloud — while you run your Oracle databases behind your own firewall.

Why organisations choose ExaCC

• Data sovereignty — the data never leaves your data centre or country, which satisfies regulatory and compliance requirements that prohibit public cloud
• Low latency connectivity — application servers and the database are in the same data centre, no internet round-trip for every database call
• Same OCI cloud services — consumed through the same OCI control plane, same APIs, same tooling as public OCI
• Predictable performance — dedicated hardware, no shared-tenancy performance variability
• Oracle manages the infrastructure — hardware maintenance, cell patching, firmware, switch management all handled by Oracle

What Oracle manages for you on ExaCC

• Physical hardware — servers, storage cells, switches, power, cooling — all Oracle responsibility
• Exadata System Software — cellsrv updates, cell OS patching, EXABP applied on Oracle's schedule
• Database server infrastructure — DBBP applied by Oracle including OS, firmware, ILOM
• Network switch firmware — RoCE switch patching handled by Oracle
• Hardware replacement — predictive failure responses and disk replacement done by Oracle
• OCI control plane — the cloud management layer connecting your ExaCC to OCI services

What you manage as DBA on ExaCC

• Oracle Grid Infrastructure and Oracle Database patching — GI and DB CPU/RU patches are still your responsibility, applied via the OCI console or OPatch
• Database creation, configuration, and lifecycle — create, drop, resize databases via OCI console or API
• User management, tablespace management, backup orchestration
• Application access, performance tuning, query optimisation
• Data Guard configuration and management
• Recovery operations in response to database failures

The key DBA implication of ExaCC: You no longer run patchmgr for cell patches, respond to disk alerts, SSH into storage cells for cellcli commands, or manage hardware events. All of that moves to Oracle. Your DBA scope narrows to the database layer — which is the work that directly impacts your applications.

ExaCS — Exadata Cloud Service on Public OCI

ExaCS is fully managed Exadata deployed in Oracle's public cloud regions. You provision Exadata VM clusters through the OCI console, and Oracle manages all the infrastructure beneath your databases — you never see the physical hardware, the storage cells, or the network switches.

Why organisations choose ExaCS

• Zero hardware responsibility — Oracle manages everything below the database VM
• Elastic scaling — add or remove OCPUs and storage without hardware procurement
• Global availability — deploy in any of Oracle's OCI regions worldwide
• Pay as you use — scale down during off-peak periods to reduce costs
• Access to full OCI service ecosystem — Object Storage, Autonomous Database, Analytics Cloud, AI services
• Multicloud — Exadata X11M is available via Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS

What Oracle manages for you on ExaCS

• Everything Oracle manages for ExaCC, plus:
• The physical data centre — power, cooling, physical security
• Database server OS patching — Oracle patches the underlying VM host OS
• Network infrastructure between your VM cluster and the internet
• Automatic backups to OCI Object Storage if you enable the managed backup service

What you manage as DBA on ExaCS

• GI and Oracle Database patching — GI and DB CPU patches are still your responsibility, applied via OCI console patch scheduling or manually via OPatch
• Database provisioning and configuration via OCI console or API
• VM cluster configuration — number of nodes, OCPU allocation, storage scaling
• User management, schemas, tablespaces, application access
• Performance tuning — the same SQL and AWR skills apply
• Backup strategy — choose between Oracle-managed backups or self-managed RMAN

ExaCS vs ExaCC vs On-Premises — DBA Responsibility Comparison

Responsibility	On-Premises	ExaCC	ExaCS
Physical hardware	You	Oracle	Oracle
Storage cell patching (EXABP)	You — patchmgr	Oracle	Oracle
DB node infrastructure (DBBP)	You — patchmgr	Oracle	Oracle
Network switch patching	You — patchmgr	Oracle	Oracle
Disk replacement / hardware alerts	You — cellcli, SR raise	Oracle	Oracle
Grid Infrastructure patching	You — OPatch	You — OCI console or OPatch	You — OCI console or OPatch
Oracle Database CPU/RU patching	You — OPatch + datapatch	You — OCI console or OPatch	You — OCI console or OPatch
Database creation and lifecycle	You	You — OCI console or API	You — OCI console or API
Performance tuning and SQL	You	You	You
Backup and recovery	You — RMAN	You — RMAN or OCI managed	You — RMAN or OCI managed
Data sovereignty	Your data centre	Your data centre	OCI region — you choose
cellcli access for DBA	Yes — full SSH access to cells	Limited — Oracle manages cells	No — not exposed to DBA

The operating model split in plain language: On-premises Exadata is the most operationally demanding model — you patch the OS, the Exadata storage software, Grid Infrastructure, and the database. ExaCC removes the infrastructure operations burden but preserves your database control. ExaCS removes even more, leaving only database-layer work.

What Changes for the DBA on Cloud Exadata

1. Patching is split — infrastructure vs database

On-premises, you patch everything with patchmgr and OPatch in a specific sequence. On ExaCC and ExaCS, Oracle patches the infrastructure (EXABP, DBBP, switches) on their own schedule — you cannot defer Oracle's infrastructure patch windows beyond a fixed grace period. You remain responsible for GI and Oracle Database patches, which you apply via the OCI console's database patching workflow or manually via OPatch.

This split removes a significant operational burden — but it also removes your control over the infrastructure patch schedule. You cannot delay an Oracle-managed infrastructure patch if it conflicts with your change management calendar.

2. Cell administration moves to Oracle — cellcli is not your tool anymore

On-premises, cellcli and dcli are essential daily tools. On ExaCC, Oracle manages the storage cells — you do not SSH into cells, run cellcli commands, respond to disk alerts, or manage griddisks. On ExaCS, the cells are not even visible to you — they are abstracted behind the VM cluster layer.

The cell metrics and health information that you previously got from cellcli are surfaced through the OCI console and OCI Monitoring service instead. You read the same information, but through a web interface and cloud APIs rather than a command line on the cell.

3. Database provisioning via OCI console or API

Creating a new database on-premises involves srvctl, DBCA, and ASM configuration. On OCI, you provision databases through the OCI console, OCI CLI, or Terraform — Oracle's infrastructure-as-code tool. The underlying database is identical, but the provisioning workflow is cloud-native.

OCI CLI — common database operations on ExaCS or ExaCC

# List VM clusters in your compartment
oci db vm-cluster list \
  --compartment-id <compartment_ocid>

# List databases in a VM cluster
oci db database list \
  --compartment-id <compartment_ocid> \
  --vm-cluster-id <vm_cluster_ocid>

# Create a new database in an existing VM cluster
oci db database create \
  --vm-cluster-id <vm_cluster_ocid> \
  --db-name MYDB \
  --db-unique-name MYDB_UNIQUE \
  --db-version 19.0.0.0 \
  --admin-password <password> \
  --db-workload OLTP

# Get patching status for a VM cluster
oci db vm-cluster get \
  --vm-cluster-id <vm_cluster_ocid> \
  --query 'data.{patchingStatus:"lifecycle-state"}'

4. Backup to OCI Object Storage — not just local RMAN

On OCI, the natural backup destination is OCI Object Storage — Oracle's durable, scalable cloud object store. You can configure Oracle-managed automated backups (Oracle schedules and manages RMAN backups to Object Storage) or self-managed RMAN backups using the RMAN SBT (System Backup to Tape) channel pointing to Object Storage. Your RMAN knowledge applies — the syntax and concepts are the same, only the backup destination changes.

RMAN backup to OCI Object Storage

-- RMAN backup to OCI Object Storage using SBT channel
-- The OCI RMAN library handles the Object Storage connection
RMAN> RUN {
  ALLOCATE CHANNEL ch1 DEVICE TYPE SBT
    PARMS='SBT_LIBRARY=/opt/oracle/oak/lib/libopc.so,
           ENV=(OPC_PFILE=/home/oracle/opc.ora)';
  BACKUP DATABASE PLUS ARCHIVELOG;
  RELEASE CHANNEL ch1;
}

-- Alternatively use the OCI-integrated backup service
-- which handles scheduling automatically

5. Scaling is elastic — not a hardware procurement

On-premises, scaling means hardware procurement, rack space, power planning, and weeks of lead time. On ExaCS, you can add OCPUs to a VM cluster in minutes through the OCI console or API. Storage expansion is similarly online. On ExaCC, scaling within your provisioned rack is straightforward — adding capacity beyond the rack requires a hardware change request to Oracle.

What Stays the Same on Cloud Exadata

This is the section that matters most for positioning your skills. The database technology is identical across all three deployment options. Everything you know about Oracle Database on Exadata transfers directly.

Skill or Task	Transfers Directly?	Notes
Smart Scan, Storage Indexes, HCC	Yes — identical	Same technology, same V$SYSSTAT statistics, same execution plan keywords
SQL tuning and AWR analysis	Yes — identical	AWR reports include the same Exadata-specific sections
RMAN backup and recovery	Yes — same commands	Destination changes to Object Storage but syntax is standard RMAN
Oracle RAC administration	Yes — same srvctl and crsctl	RAC runs on the VM cluster the same way as on-premises
Data Guard configuration	Yes — same concepts	OCI provides a Data Guard console wizard but manual configuration also works
Performance monitoring with V$ views	Yes — identical	Same V$CELL_STATE, V$SYSSTAT cell statistics, same Smart Scan metrics
OPatch and datapatch for DB software	Yes — same commands	GI and DB patching uses the same OPatch process as on-premises
ASM disk group management	Yes — same commands	ASM manages disk groups the same way — V$ASM_DISKGROUP, V$ASM_DISK
ADOP for EBS R12.2 (if applicable)	Yes — identical	EBS on ExaCS or ExaCC uses the same ADOP patching cycle
cellcli commands on ExaCC and ExaCS	Partial / No	ExaCC limits DBA cellcli access. ExaCS does not expose cells to DBA at all.
patchmgr for infrastructure	No on ExaCC/ExaCS	Infrastructure patching is Oracle-managed. Your patchmgr skill applies on-premises only.

New Skills the Cloud Adds to Your Toolkit

Moving to OCI Exadata does not replace your existing skills — it adds new ones on top. The DBA who understands both the on-premises Exadata internals and the OCI operational model is genuinely hard to find and well compensated.

OCI Console and CLI

The OCI console is where you provision databases, manage VM clusters, schedule patches, configure backups, and monitor cloud-level infrastructure. Becoming fluent in the OCI console and the OCI CLI is the most immediately practical new skill for an on-premises DBA moving to OCI.

Terraform for Oracle databases

Oracle provides a Terraform provider for OCI. Many organisations manage their OCI Exadata infrastructure as code — VM clusters, databases, Data Guard associations, and network configuration are all defined in Terraform files and applied through CI/CD pipelines. Basic Terraform literacy is increasingly expected for cloud DBA roles.

OCI Monitoring and Notifications

The cell alerts and cellcli health checks you ran on-premises are replaced by OCI Monitoring alarms and Notifications. You define metric-based alarms in the OCI console — for example, alert when database CPU exceeds 90% for more than 10 minutes — and route notifications to email, PagerDuty, or Slack. The same information is available, accessed through a different paradigm.

OCI Object Storage for backups and data movement

Object Storage is the natural landing zone for backups, data exports, and data imports on OCI. Understanding how RMAN integrates with Object Storage, how Data Pump uses pre-authenticated requests (PARs), and how to manage Object Storage buckets are practical skills that come up in every OCI database engagement.

OCI CLI — common monitoring tasks for cloud DBAs

# Check Exadata infrastructure maintenance history
oci db maintenance-run list \
  --compartment-id <compartment_ocid> \
  --target-resource-id <vm_cluster_ocid>

# List available database patches for a specific DB version
oci db patch list --all \
  --compartment-id <compartment_ocid> \
  --db-version 19.0.0.0 \
  --db-home-id <db_home_ocid>

# Check backup status for a database
oci db backup list \
  --compartment-id <compartment_ocid> \
  --database-id <database_ocid>

# Create an alarm for cell Smart Scan efficiency
# (Done via OCI console Monitoring service or API)
# Metric: oracle_oci_database_exadata_smart_scan_efficiency_percent
# Alarm condition: value < 70
# Notification: email to DBA team

How to Think About Which Option Is Right for Your Organisation

If Your Requirement Is	Consider
Data must stay in your own data centre — regulatory requirement	ExaCC or On-Premises Exadata
Want cloud economics but data sovereignty	ExaCC — subscription in your data centre
Maximum operational simplicity — let Oracle manage infrastructure	ExaCS on public OCI
Need to scale quickly without hardware lead time	ExaCS — elastic OCPU and storage scaling
Application servers must be co-located with database	ExaCC or On-Premises Exadata
Already have Oracle Database licences	Any option — evaluate BYOL pricing for ExaCC and ExaCS carefully
Want access to Autonomous Database on the same platform	ExaCS — Autonomous Database runs on ExaCS infrastructure
Multicloud requirement — run Oracle databases closer to AWS or Azure workloads	Oracle Database@Azure, Oracle Database@Google Cloud, or Oracle Database@AWS — all use Exadata X11M

What This Means for Your Career as an Exadata DBA

The shift to cloud Exadata does not make on-premises Exadata skills obsolete — it makes them more valuable when combined with cloud skills. Here is the reality of the market in 2026.

• On-premises Exadata is not going away. Most large enterprises with Exadata investments will run on-premises systems for years. Organisations with regulatory constraints will run ExaCC in their own data centres indefinitely. The on-premises DBA who understands cellcli, patchmgr, and the storage object model is still in demand.
• Cloud Exadata expertise is additive, not replacement. The DBA who understands both patchmgr rolling upgrades and OCI Terraform provisioning is rare. That combination commands a premium over a DBA who only knows one side.
• Database skills transfer completely. Everything you know about SQL tuning, AWR, Smart Scan, HCC, RAC, Data Guard, RMAN, and ADOP applies directly to cloud Exadata. None of it becomes obsolete. The cloud adds an operational layer on top — it does not replace the database layer underneath.
• The next step is OCI fundamentals. If you want to position yourself for cloud Exadata roles, learn the OCI console, OCI CLI, and basic Terraform. These are the gaps between your current skill set and a cloud DBA role. The Oracle Cloud Database Services certification (1Z0-1093) is a practical starting point.

Practical advice: Set up a free Oracle Cloud account at cloud.oracle.com — Oracle provides Always Free tier resources. Provision an Autonomous Database or a small VM cluster in the Always Free tier and explore the OCI console, OCI CLI, and monitoring. You will immediately recognise the concepts from your on-premises experience — Smart Scan metrics, AWR reports, RMAN backups — through a new interface.

Summary — Three Deployment Options, One Technology

• On-premises Exadata — you own and operate everything. Maximum control, maximum operational responsibility. patchmgr, cellcli, and dcli are daily tools.
• ExaCC (Cloud@Customer) — Oracle manages the infrastructure in your data centre. You manage databases. Data stays on-premises. Oracle handles EXABP, DBBP, hardware alerts, and disk replacement.
• ExaCS (Cloud Service) — fully managed in Oracle's public cloud. You manage databases via OCI console and CLI. Oracle manages everything below the database VM. Elastic scaling, multicloud availability.
• All three use the same Exadata hardware and software — Smart Scan, Storage Indexes, HCC, cellsrv, ASM, RAC. The technology does not change between deployment options.
• On cloud Exadata, your database skills transfer completely. SQL tuning, AWR, RMAN, RAC, Data Guard, OPatch, ADOP — all identical. Infrastructure skills (patchmgr, cellcli) are replaced by OCI operational tools.
• The new skills to add are OCI console, OCI CLI, Terraform, OCI Monitoring, and Object Storage for backups. None of these replace what you know — they extend it.

---

punitoracledba.blogspot.com  ·  Oracle Exadata — Basics to Pro Series  ·  May 2026

Article 10 of 10 — Final article in the Exadata Basics to Pro series Thank you for reading. The full series: Articles 1 through 10 — Oracle Exadata from What Is It to Cloud DBA. Blogger labels: Oracle Exadata · OCI · ExaCS · ExaCC · Cloud DBA · Cloud@Customer · OCI Exadata · Skills