Eaxadata and Oracle Database interview question and answer2026

1) common daily issue in exadata

Common daily issues and monitoring tasks for Oracle Exadata environments generally focus on performance bottlenecks, storage cell health, and resource contention. Key daily areas for investigation include

1. Common Daily Performance & Operational Issues

• Exadata Smart Scan Bypassing: Queries might bypass Cell Smart Scan, causing increased I/O and performance degradation.
• Storage Cell Bottlenecks: Uneven I/O distribution can create "hotspots" on individual storage cells, slowing down the entire system.
• Quarantine Mechanisms: The Exadata quarantine feature may trigger, preventing affected components from causing system disruption, but forcing operations into a suboptimal mode.
• Capacity Issues: Daily checks often reveal high utilization of flash cache, hard disk capacity, or overall storage.
• Workload Imbalance: Inconsistent configurations across storage cells can lead to performance gaps.

2. Daily Monitoring & Troubleshooting Tasks (Daily Checklist)

• Check Exadata Alerts: Monitor storage server alert.log files and review cellcli -e list alerthistory for critical alerts.
• Verify Storage Cell Health: Check Cell Server (CELLSRV) status and review daily metrics for flash disk/hard disk I/O and throughput.
• Review ExaChk Reports: Running exachk is recommended for daily or periodic assessment of system health.
• Monitor I/O Resource Management (IORM): Analyze if IORM objectives (low_latency, balanced, high_throughput) are met.
• Disk Replacement Verification: Ensure that failed disks are being automatically dropped and that rebalancing is in progress

3. Key Diagnostic Tools

• CellCLI: Used to monitor storage server metrics, CELLSRV processes, and alert history.
• AWR (Automatic Workload Repository): Essential for identifying bottlenecks like excessive cell smart table scan waits.
• Exadata Storage Server Metrics: Used to track CPU, hard/flash disk I/O, and throughput

2.issue and Monitor I/O Resource Management (IORM)

I/O Resource Management (IORM) in Oracle Exadata ensures fair sharing or prioritization of storage I/O among multiple databases or workloads by managing storage server resources on a per-cell basis, primarily enabled during I/O contention. Management includes defining objectives (Auto, Balanced, Low Latency, High Throughput) and assigning database shares or limits using CellCLI or OCI console

Key Management & Troubleshooting Tasks

• Enabling/Managing IORM: Use ALTER IORMPLAN in CellCLI to set objective and database plans. On Cloud/VM clusters, you can enable IORM via the OCI console by selecting an objective.
• Setting Objectives:
  • Auto: Dynamically adjusts based on workload.
  • Low Latency: Prioritizes OLTP, limiting flash cache impact by large I/Os.
  • High Throughput: Optimized for large sequential DSS workloads.
• Monitoring Metrics: Use AWR reports and V$ views to check DB_IO_WT_SM_RQ (small I/O wait) and DB_IO_WT_LG_RQ (large I/O wait) to detect bottlenecks.

Troubleshooting & Tuning:

• Check Queue Time: If AWR shows high wait times, adjust IORM plan to increase allocations for struggling databases.
• IORM Advisor: Use the Exadata Management Pack's IORM Advisor for visual analysis of flash I/O consumption.
• Persistent Issues: If high priority apps are lagging, use ALTER IORMPLAN to increase shares or set hard limits for lower priority workloads.

for more detail

Understanding I/O Resource Management (IORM)

3. patching issue in exadata

Exadata patching issues often involve failed patchmgr pre-requisites due to hardware alerts, custom RPM dependencies, or dbnodeupdate.sh errors. Common pitfalls include storage cell connectivity issues, hung upgrades requiring ILOM console intervention, or ASM instances failing to start after compute node reboots

Common Exadata Patching Issues & Solutions

• Failed Pre-requisites: Frequently caused by hardware alerts or misconfigurations. Always run exachk before patching and resolve existing alerts.
• Custom RPM Dependencies: dbnodeupdate.sh may fail if custom packages exist. We recommends removing all custom RPMs before upgrading, avoiding the dangerous -modify_at_prereq flag.
• Compute Node Hang/Boot Issue: If a node hangs during patching, a reboot may be needed, often requiring a rescue if the GRUB prompt hangs.
• ASM/Storage Failure: If ASM fails to start after a patch, check for corrupted storage cells or mismatches between storage cell and compute node versions.
• TNS Errors Post-Patching: ORA-12154 can occur after a Fleet Update, requiring verification of network configuration

Best Practices

• Rolling vs. Non-Rolling: Use rolling patches to maintain availability.
• Use Oracle Knowledge Base & Troubleshooting Guide: Always review the latest Known Issues and follow detailed blogs.
• Pre-checks: Utilize patchmgr with the -precheck option to identify issues.
• Out-of-Place Patching: For Cloud@Customer, leverage out-of-place patching for minimal downtime

4. latest feature in exadata X7–X10M

The Exadata X10M (released 2023) represents a significant generational leap from the X7-X9M series, focusing on extreme consolidation, higher performance, and AI readiness using 4th Gen AMD EPYC processors. It provides up to 3x more cores, 1.5x more memory, and 2.4x higher flash capacity than prior generations

1. Hardware Enhancements (X10M)

• 4th Gen AMD EPYC Processors: Provides significantly higher core counts (96 cores per socket) to enable massive database consolidation on fewer servers.
• PCIe Gen 5 RoCE Networking: Uses dual-port PCIe Gen 5 network interface cards for 2x 100 Gb/sec active-active RoCE network, totaling 200 Gb/sec per server.
• Expanded Memory Capacity: Supports up to 3 TB of DDR5 DRAM per database server, a 50% increase over previous generations.
• Higher Density Storage:
  • High Capacity (HC) Servers: Feature 22 TB hard disk drives (22% increase).
  • Extreme Flash (EF) Servers: Use capacity-optimized 30.72 TB flash drives, increasing raw flash capacity by 2.4x.
• 2U Server Form Factor: New 2U database servers allow better cooling and support for up to 5 client NICs

2. Software Enhancements (System Software 23.1/24ai/25ai)

• Exadata RDMA Memory (XRMEM) Cache: Uses DDR5 DRAM in storage servers to create a shared, ultra-low latency cache, dropping SQL Read latency to less than 17 microseconds.
• AI Vector Search Acceleration (24ai/25ai): Introduces "AI Smart Scan" to offload vector distance computations and Top-K filtering directly to storage servers.
• Exascale Architecture (24ai): A new architecture that decouples storage management from database servers for "thin cloning" of databases and improved storage efficiency.
• Secure RDMA Fabric Isolation: Enables strong isolation for KVM-based virtual machines across the RoCE network.
• Exadata Live Update (24ai): Allows applying OS updates without restarting the database server.
• Smart Scan Enhancements: Improved offloading of columnar compression and decryption/decompression directly to storage, reducing CPU usage on database server

Summary of Advancements (X7 to X10M)

Feature [1, 2, 3, 4, 5]	Exadata X7	Exadata X10M
Processor	Intel Xeon (lower core count)	4th Gen AMD EPYC (96 cores)
Networking	40Gb InfiniBand	100Gb/200Gb RoCE
Storage Type	Flash Cache	XRMEM + Flash + Disk
Disk Capacity	10 TB HDD	22 TB HDD
Read Latency	~250 microseconds	< 17 microseconds

These enhancements result in a much lower Total Cost of Ownership (TCO) compared to older systems, with 5-year TCOs for older X7-2 systems potentially being 72% to 85% higher due to the energy and capacity efficiency of the X10M

For More Details

https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-x10m-ds.pdf

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmso/exadata-database-machine-x7-new-features.html

5.how to troubleshoot Exadata Smart Scan Bypassing

Troubleshooting Exadata Smart Scan bypassing involves ensuring Direct Path Reads are used, checking for unsupported SQL/data types, and monitoring wait events. Key actions include verifying that cell_offload_processing is TRUE, the object is not clustered or using unsupported compression, and using EXPLAIN PLAN to confirm TABLE ACCESS STORAGE FULL




Common Reasons for Smart Scan Bypass

• Access Method: Non-direct path reads (e.g., buffered I/O) prevent smart scans.
• Unsupported Objects: Smart scan does not support Index-Organized Tables (IOTs), clusters, or certain LOB configurations.
• Data Issues: Chained rows or specific encryption types can force passthrough mode.
• Parameter Settings: cell_offload_processing set to FALSE or restricted parallel settings.
• Optimization: Missing _serial_direct_read set to ALWAYS for serial queries

Troubleshooting Steps

1. Check Execution Plan: Confirm the plan shows TABLE ACCESS STORAGE FULL and storage() predicates. If it says TABLE ACCESS FULL (without "STORAGE"), smart scan is not happening.
2. Monitor Wait Events: Look for cell smart table scan passthru wait events, which indicate that the cell is reverting to passing raw blocks.
3. Check Table/Index Attributes: Verify if the table is using advanced compression or is an IOT.
4. Verify Parameter Settings:

SHOW PARAMETER cell_offload_processing;

ALTER SESSION SET "_serial_direct_read"=always;

Examine AWR/Statspack: Review "Cell Smart IO" statistics to compare "Passthru" vs. "Smart" scan sessions.

Analyze SQL Constraints: Check if Materialized Views or Transparent Data Encryption (TDE) are hindering offload.

Identify Bottlenecks: Use diagnostics to check for storage cell CPU saturation (100% usage) that forces passthrough                                                                                                              

For more detail -What to Look For When Monitoring Smart I/O

6 what is difference between exacc and exacs

ExaCS (Exadata Cloud Service) and ExaCC (Exadata Cloud@Customer) both provide Oracle Exadata performance with cloud economics, but differ in location: ExaCS runs in Oracle’s Public Cloud (OCI), while ExaCC runs inside the customer's own data center. ExaCS is best for full cloud adoption, whereas ExaCC is designed for high security, data sovereignty, and strict compliance needs

Key Differences:

• Deployment Location: ExaCS is hosted in Oracle Cloud Infrastructure (OCI) regions. ExaCC hardware is installed physically in the customer’s data center.
• Infrastructure Management: Both are managed by Oracle (hardware and software).
• Best Use Cases:
  • ExaCS: Organizations ready to move all workloads to the public cloud, requiring fast provisioning and scaling.
  • ExaCC: Regulated industries needing data residency, on-premises compliance, or extremely low latency to existing on-prem systems.
• Scaling: ExaCS allows for faster, on-demand scaling compared to the potentially more involved process for ExaCC.
• Network: ExaCS connects via OCI regions, while ExaCC connects to OCI via a Control Plane Server, keeping data behind the customer firewall

7. what is General issues in Oracle Exadata Cloud@Customer (ExaCC)

General issues in Oracle Exadata Cloud@Customer (ExaCC) often revolve around its hybrid nature—combining on-premises hardware with OCI cloud control plane management. Key issues include patching failures, network connectivity problems between the customer data center and OCI, and database lifecycle management errors

Common Technical Issues in ExaCC

• Patching Failures: Updates to VM operating systems or Grid Infrastructure can hang or fail during node patching, often requiring manual intervention via patchmgr logs on the VMs.
• Networking and Connectivity: Misconfiguration of the OCI Services Network, slow connectivity, or incorrect DNS settings can break communication between the ExaCC infrastructure and OCI control plane.
• Database Lifecycle Issues: PDB creation failures (especially when running in parallel), failure to add VMs to a cluster, or issues during database scaling (CPU scaling fails).
• Backup Failures: Failed backups to OCI Object Storage, typically caused by incorrect database configurations or blocked access to the network.
• Data Guard Issues: Failures to update the nodelist after Data Guard operations, or standbys failing to restart after a switchover

Operational and Management Issues

• Limited Access to Hardware: Users lack direct access to storage servers, Dom0, or InfiniBand switches, relying on Oracle support for these components.
• Monitoring Constraints: The Exadata tab in the Performance Hub offers a limited, read-only view of storage servers.
• Restricted Actions: In some versions, changing default password settings for grid or oracle users is not allowed.
• Wait Events/Performance: Suboptimal query performance where queries bypass Smart Scan, often due to storage cells quarantining disks

Specific Known Issues (As of 2025/2026)

• TDE Key Issues: Potential TDE (Transparent Data Encryption) key replication issues in Data Guard scenarios.
• Dbaastools Conflicts: Upgrading dbaastools before patching can cause incompatibilities with the existing image, leading to APEX/SQL console access issues.
• Storage Scaling: Scaling up data or backup storage may fail if the additional storage is less than 10 GB

For More Details

https://docs.oracle.com/en-us/iaas/exadatacloud/doc/ecs-troubleshooting.html

https://docs.oracle.com/en-us/iaas/exadata/doc/ecc-troubleshooting-systems.html

what is different between oracle database from19c to 26ai

The transition from Oracle Database 19c to Oracle AI Database 26ai (released early 2026 as the next long-term support release) represents a shift from a traditional, stable, relational database to an AI-native, integrated data platform

The transition from Oracle Database 19c to Oracle AI Database 26ai (released early 2026 as the next long-term support release) represents a shift from a traditional, stable, relational database to an AI-native, integrated data platform

Key Differences: 19c vs. 26ai

Feature Area [1, 2, 3, 4, 5]	Oracle 19c	Oracle 26ai (AI Database)
Primary Goal	Stability & Performance	AI-Native & Automation
AI Integration	Add-on (OML/Spatial)	Native Vector Search (SQL)
Architecture	Non-CDB/CDB Supported	Multitenant (CDB/PDB) Mandatory
Data Types	Relational, JSON, XML	Enhanced JSON/Relational/Graph/Vector
Management	Manual tuning/indexing	AI-driven tuning/Auto-indexing
Security	Standard robust security	Blockchain Tables, Anti-Tamper
Long-Term Support	Ends 2029-2032	New Long-Term Release

Major Changes and Key Takeaways

• Native AI Vector Search: 26ai allows developers to use SQL to perform semantic searches on vector embeddings, integrating AI into existing queries without needing external vector databases.
• Mandatory Multitenant Architecture: While 19c allows traditional "non-CDB" (non-container) databases, 26ai strictly requires the Container Database (CDB) / Pluggable Database (PDB) architecture. Upgrading from 19c non-CDB will force a migration to a PDB.
• The "AI" in 26ai: Features include intelligent, automatic indexing, faster SQL parsing, and enhanced data analysis capabilities.
• Support and Longevity: 19c remains stable, but 26ai is the next major long-term target for organizations seeking the latest features, security updates, and performance optimizations.
• Simplified Upgrades: Oracle provides "AutoUpgrade" utilities and scheduled, low-downtime options to migrate from 19c to 26ai

how to upgrade oracle 19c to 26ai

Upgrading from Oracle 19c to 26ai is supported directly, primarily using the AutoUpgrade utility, which is mandatory for this version transition. Ensure your 19c database is at a high patch level (e.g., Oct 2025/Jan 2026), install 26ai software in a new home, and run AutoUpgrade in deploy mode to handle pre-checks, upgrades, and non-CDB to PDB conversion

Key Considerations and Prerequisites

• Mandatory Multi-tenant: Oracle 26ai only supports multi-tenant architecture. Non-CDB 19c databases will be converted to Pluggable Databases (PDBs) during the upgrade.
• Method: Use AutoUpgrade (JAR file), as traditional methods like DBUA are not supported for this specific upgrade path.
• Backup: Create a full backup or guaranteed restore point before starting.
Grid Infrastructure: Ensure GI is at 26ai or later