Eaxadata and Oracle Database interview question and answer 2026 Part1

Question : when to create non-default block size tablespaces (like 2K, 4K, 16K, or 32K instead of 8K)

You should generally stick to an 8K block size for most databases. Only create non-default block size tablespaces when you need to transport tablespaces between databases of different architectures, to handle extremely large index keys, or to resolve specific concurrency/I/O issues discovered through benchmarking

You should create non-default block size tablespaces (like 2K, 4K, 16K, or 32K instead of 8K) for specific tuning or compatibility needs. Because multiple buffer pools are required, you must explicitly allocate their memory using parameters like DB_16K_CACHE_SIZE in the Oracle Database Reference. 

Creating a non-default block sizetablespace (like 16K or 32K) is ideal for Data Warehouses (DSS) and large LOB/BLOB-heavy objects, while smaller sizes (2K, 4K) serve high-concurrency OLTP systems. The primary advantage is I/O optimization: larger blocks reduce physical reads and index splits for bulk data, whereas smaller blocks prevent lock contention for frequent, small transactions

Common use cases for non-standard block sizes include:

• Transportable Tablespaces: Moving tablespaces between databases that have different default block sizes.
• Large LOB Data: Using a 16K or 32K block size for LOB (Large Object) data can significantly optimize the chunk size and reduce I/O.
• Micro-managing Index Access: Using smaller blocks (e.g., 2K) can prevent row migration on highly volatile OLTP tables with very small rows.
• DSS/Data Warehousing: Using larger block sizes (like 16K or 32K) reduces the number of I/O operations required for large, sequential table scans.

Architectural Cons to Consider

Before implementing non-default blocks, consider these architectural drawbacks:

• Buffer Cache Overhead: Oracle requires separate sub-caches for each non-default block size used (e.g., you must configure a DB_16K_CACHE_SIZE initialization parameter). This restricts memory flexibility.
• Wasted Space: Small tables placed into a 32K tablespace will leave significant unused space in each block, inflating the overall storage footprint.
• Partition Restrictions: All partitions of a partitioned object must reside in tablespaces with the identical block size

 

Best Practice: The Oracle expert consensus is generally to stick to a single 8K block size to avoid wasting SGA memory on multiple buffer caches, unless you have an explicit, proven need to optimize specific read-heavy or LOB-heavy structures.

The Advantages of Non-Default Block Sizes

1. Large Block Sizes (16K, 32K) [1]

• Better for Data Warehouses (DW) and Big Data: Reading large volumes of data (e.g., Full Table Scans) is highly efficient because a single I/O operation fetches more related rows.
• Fewer Index Levels & Splits: Indexes are more compact and require less maintenance, speeding up index range scans.
• Reduced Row Chaining: Rows that exceed the standard 8K size (like LOBs or heavily populated records) are stored in fewer chained blocks, significantly improving I/O performance.
• Improved Compression: Testing by database experts frequently shows that larger blocks (such as 32K) maximize the efficiency of Oracle Advanced Compression, minimizing physical disk waste

2. Small Block Sizes (2K, 4K)

• Reduced Hot-Block Contention: In Online Transaction Processing (OLTP) environments with massive insert/update concurrency, smaller blocks mean fewer concurrent sessions attempting to modify the exact same block.
• Better Memory Efficiency: Small rows in large blocks waste cache memory. Smaller blocks placed into a smaller, appropriately tuned buffer cache ensure you don't load unnecessary data into the RAM.

Critical DBA Considerations

Before implementing non-default tablespaces, be aware of these fundamental database realities:

• Manual Memory Sizing: Each non-default block size requires its own specific buffer cache size in your System Global Area (e.g., you must set DB_16K_CACHE_SIZE).
• Memory Inflexibility: Memory allocated to a non-default cache (like 16K) cannot be dynamically borrowed by the default 8K cache, potentially degrading memory utilization efficiency if not managed properly.
• Universal 8K Recommendation: Unless you have explicitly tested your workload and identified specific bottlenecks that a different size resolves, Oracle experts largely recommend sticking to the 8K default for 99% of deployments

Question : How to migrate oracle database on different platform

Migrating an Oracle database across different platforms—particularly between different Operating Systems (e.g., Windows to Linux) or different "endian" formats (big-endian like AIX to little-endian like x86)—requires specialized techniques because standard physical backups (RMAN) cannot be directly restored across platforms

To use v4 XTTS (Cross Platform Transportable Tablespaces) Perl scripts for Oracle database migrations, you must install the exact same set of scripts on both the source and target systems. These scripts, obtained from My Oracle Support (Doc ID 2471245.1), automate the process of using RMAN incremental backups to minimize downtime during cross-platform or cross-endian migrations

Common Migration Methods

Method	Best For	Typical Use Case
Oracle Data Pump	Small to medium databases	Logical migration; easy to use across any platform and version.
Transportable Tablespaces (TTS)	Large databases	Moving data files physically while metadata is moved logically.
RMAN Cross-Platform Transport	Cross-endian migrations	Converting data files from big-endian (AIX, Solaris) to little-endian (Linux).
Oracle GoldenGate	Near-zero downtime	Synchronizing data in real-time between source and target during the move.

Step-by-Step Migration Guide (Logical/Data Pump)
This is the most flexible and common method for cross-platform moves. 

1. Prepare the Target Environment: Install the same or a higher Oracle Database release on the new platform.

1. Run Pre-migration Checks: Use the Cloud Premigration Advisor Tool (CPAT) to identify compatibility issues.

1. Export Metadata/Data: Use expdp on the source system to create dump files.

1. Transfer Files: Move the dump files to the target server using secure transfer tools (e.g., scp or rsync).

1. Import to Target: Use impdp on the new platform. You can use REMAP_TABLESPACE if paths differ.

Key Advantages

• Minimal Downtime: Allows data files to be moved and converted (even between different endian formats) with only a brief, final read-only cutover phase.

• No Full Reload: Moves physical datafiles directly, avoiding the slow, traditional "Export/Import" process for massive tablespaces.

• Incremental Application: Keeps the target database synced with the source by applying block-level changes over multiple iterations

Core Workflow

"v4 transport tablespace" refers to the Version 4 (v4) Cross-Platform Transportable Tablespace (XTTS) scripts provided by Oracle Support (MOS Note 2471245.1). This method significantly reduces database downtime during migrations by using RMAN incremental backups to copy and convert large datasets while the source database remains online

1. Setup & Environment: Install the v4 XTTS Perl scripts on both the source and target systems, defining connection credentials, backup directories, and ASM locations.

1. Initial Setup: Take an initial RMAN level 0 backup of the source tablespaces and transfer both the datafiles and metadata to the target server.

1. Incremental Backups: While the source database remains online, run periodic incremental backups to capture ongoing data modifications and apply them to the target datafiles.

1. Cutover Window: Place the source tablespaces in READ ONLY mode, take one final incremental backup, apply it to the target, and import the structural metadata using Oracle Data Pump

Requirements & Limitations

• Supported Versions: The source database must be at least version 11.2.0.3 or higher.
• TDE Encrypted Data: Standard XTTS methods cannot be used if the source database uses Transparent Data Encryption (TDE).
• OS Restrictions: Cross-platform transport cannot be used if either the source or the target operating system is Windows.
• Target Limitations: Physical migrations using tablespaces are not applicable if your target is an Autonomous Database, which strictly requires logical migrations.

Core Script Components

The downloaded package typically includes seven scripts, with the following being the most critical:

• xttdriver.pl: The main execution script used to run backup, restore, and conversion commands.
• xtt.properties: The central configuration file where you define system-specific parameters like ORACLE_SID, backup locations, and connection strings.
• xttplan.txt and tsbkupmap.txt: Dynamic metadata files generated during the process that must be copied between systems to synchronize backup and restore operations

Setup Requirements

1. Download and Unzip: Obtain the rman_xttconvert_v4.zip from My Oracle Support and unzip it into the same subdirectory structure on both hosts.
2. Configure xtt.properties:
   • On the Source System: Configure it to point to the source database and set a scratch location for backups.
   • On the Target System: Ensure the configuration reflects the target's ASM or file system paths and connection details.
3. Directory Structure: Create matching temporary and backup directories (e.g., <Backup_location>/XTTS_TEMP) on both sides to handle file transfers

Basic Execution Workflow

• Prepare (Source): Run perl xttdriver.pl -p to take the initial Level 0 backup.
• Restore (Target): Copy the backup and metadata files to the target and run perl xttdriver.pl -r to restore.
• Incremental Roll Forward: Perform incremental backups on the source (-i) and apply them on the target (-r) repeatedly until the final cut-over window.

For detailed step-by-step instructions, refer to the Oracle tutorial on migrating to OCI using V4 XTTS or the official documentation in My Oracle Support Doc ID 2471245.1.

For More Details

https://docs.oracle.com/en/learn/ocidb-xtts/index.html#introduction

Question : -what is split brain in oracle rac

A split-brain in Oracle RAC is a dangerous state where cluster nodes lose communication with each other but continue running. Each node believes it is the sole survivor and attempts to independently write to the shared database, leading to severe data corruption and integrity issues

why Does It Happen?

Split-brain is typically caused by a failure of the private network/interconnect between cluster nodes

The Scenario: In a 3-node cluster (Node A, B, and C), the interconnect cable fails. Nodes A and B can talk to each other but not to Node C. Node C is still physically up but isolated.

The Problem: Node C thinks Nodes A & B are dead. Nodes A & B think Node C is dead. All nodes try to take over resources and write to the shared ASM storage at the same time without synchronization

How Oracle Prevents Data Corruption

Oracle Grid Infrastructure uses specialized mechanisms to immediately detect a split brain and prevent damage. 

• The Voting Disk: Cluster nodes continuously "ping" a shared Voting Disk to declare they are alive. During a split brain, the cluster calculates which subgroup of nodes holds the majority of votes.
• Node Eviction: The subgroup with the majority survives. The minority subgroup (or isolated node) is evicted (forced to shut down or panic) to prevent it from corrupting data

Ensuring Safety: I/O Fencing

Once a node is evicted, Oracle uses I/O Fencing (often called Ocssd, or hardware-level reboot mechanisms) to sever the evicted node's physical access to the shared storage disk. This acts as a guarantee that the dead node cannot physically write any conflicting blocks to the database

How Oracle Prevents Split-Brain

• Quorum & Voting Disks: Oracle uses shared files called Voting Disks to track the status of all nodes in the cluster. When a network split happens, nodes “vote” to determine who is alive.
• Majority Rule: The cluster cohort with the majority of active nodes—or the one that can access the majority of voting disks—wins the right to survive. The minority subgroup loses access to this quorum.
• Node Eviction (Fencing / STONITH): To guarantee that no isolated node continues writing to shared storage, the surviving node forcefully evicts the minority nodes. It achieves this by updating the clusterware to fence off the minority node, killing its cluster processes, or instructing the host hardware to immediately panic/restart (a mechanism often referred to as STONITH—Shoot The Other Node In The Head)
• Best Practices to Prevent Interconnect Failures
  Preventing split-brain boils down to ensuring your private interconnect network remains highly available so the split never gets triggered:
  • Use Redundant Interconnects: Ensure you have multiple, bonded network interface cards (NICs) configured for high availability (HAIP in Oracle Grid Infrastructure) so a single cable or switch failure doesn't isolate the nodes.
  • Dedicated Subnets: Isolate the cluster interconnect traffic on a private, non-routable subnet to avoid congestion or packet drops caused by public or user traffic.
  • Hardware Redundancy: Use physically separate switches for your interconnect links to prevent switch outages from crippling cluster communication

Question : how to stop cell server one by one

Stopping a cell server (commonly seen in Oracle Exadata environments) one by one requires safely taking its disks offline and shutting down services to prevent database corruption

Safely shut down a single cell server by completing the following sequence on the target machine:

1. Check Disk Status: Log in to the cell server and verify the Automatic Storage Management (ASM) mode status to ensure safety.
   cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome
2. Deactivate Grid Disks: Set all grid disks on the cell to inactive. This safely syncs and offloads the data to other active cells.
   cellcli -e alter griddisk all inactive(Note: Wait until the asmdeactivationoutcome changes to Yes for all disks before proceeding. This confirms the storage is safely mirrored).
3. Stop Cell Services: Shut down the active cell software and services.
   cellcli -e alter cell shutdown services all
4. Power Down: Once the services are stopped, you can gracefully halt the server.
   shutdown -h -y now
5. Repeat: Wait for the first server to power down completely before logging into the next cell server and repeating these steps

Question: what is disk_repair_time in exadata and use cases

In Exadata, DISK_REPAIR_TIME is an Oracle ASM disk group attribute that dictates how long ASM will wait for an offline, missing, or unavailable disk to come back online before permanently dropping it and triggering an expensive data rebalance. It acts as a grace period to prevent unnecessary data redistribution

Key Use Cases

• Transient Hardware Glitches: Handles temporary disconnections like a loose SAS cable, a brief switch issue, or a momentary power glitch. Instead of rebuilding the data, ASM waits, then uses Fast Mirror Resync to quickly update only the exact blocks that changed once the disk reconnects.
• Rolling Storage Cell Maintenance: When patching or rebooting a single Exadata Storage Server, all its disks are temporarily taken offline. A properly set DISK_REPAIR_TIME ensures that ASM does not frantically drop the disks and initiate a rebalance, saving immense system I/O and processing

How It Works and Defaults

• Default Value: The default is typically \(3.6\) hours, but it can be adjusted depending on maintenance or hardware replacement SLAs.
• Drop vs. Resync: If the disk is brought back online before the timer expires, ASM syncs only the modified extents. If the timer expires, ASM force-drops the disk and triggers a time-consuming rebalance across the remaining available storage cells

Example: Modifying the Disk Repair Timer

You can check or change this attribute dynamically in SQL using the ALTER DISKGROUP command. For example, to set the repair time to 14 hours on the DATA disk group

SQL> ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '14h';


Question : what to check as compliance and risk assessment like password complexity,
           audit, hardening, deloit audit and tool

To ensure your IT environment is secure and compliant with major enterprise frameworks 
like ISO 27001 or SOC 2 (often scrutinized by auditors like Deloitte), 
you need a structured approach. Your checklist should prioritize

Access & Password Policies: Enforce Multi-Factor Authentication (MFA),
 define least privilege, and mandate complex passwords (12+ characters with mixed types) 
that rotate or are checked against breach databases.
System Hardening: Remove unused ports/services, disable default passwords, 
enforce disk encryption, and apply rigorous patch management.
Audit Logging: Implement tamper-proof, centralized audit trails for privileged actions, 
failed logins, and system changes.
Risk Assessments: Regularly evaluate threats to your assets, categorize them by risk level, 
and document mitigation plans.
Tools: Automate compliance with platforms like Vanta, Hyperproof, 
or Deloitte's Omnia; and test security with Nessus, Wireshark, or Nmap

1. Access Controls & Passwords
Auditors will heavily scrutinize how users authenticate and what they can access
Password Complexity: Policies must mandate strong passwords 
(typically 12+ characters, including numbers, upper/lower case, and special symbols) 
without allowing the reuse of the last 5-10 passwords.
Multi-Factor Authentication (MFA): Mandatory for all critical accounts, especially privileged IT accounts, 
VPNs, and cloud portals.
Privileged Access Management (PAM): Restrict administrative rights. Remove local admin rights 
from standard users and monitor all privileged session activity.
Offboarding: Ensure automated workflows exist to terminate system access instantly 
when an employee departs

2. System & Server Hardening
Hardening shrinks your digital attack surface
Patch Management: Ensure there is an ongoing schedule for patching operating systems, 
third-party software, and firmware.
Disable Unnecessary Services: Turn off non-essential services, protocols 
(e.g., Telnet, unencrypted HTTP), and close unused network ports.
Encryption: Enforce strong encryption for data at rest (e.g., BitLocker, LUKS) and 
in transit (e.g., TLS 1.2 or TLS 1.3).
Configuration Baselines: Use industry-standard benchmarks 
(like the Center for Internet Security (CIS) benchmarks) to configure servers, 
firewalls, and endpoints

3. Auditing & Logging Capabilities
You must be able to prove who did what and when
Log Centralization: Stream logs from servers, firewalls, and applications to a centralized 
SIEM (Security Information and Event Management) tool.
Log Integrity: Protect log files against tampering, deletion, or unauthorized viewing.
Alerting: Set up real-time alerts for suspicious activities, such as multiple failed login attempts,
 unusual access hours, or unauthorized privilege changes

4. Risk Assessments & Compliance
A risk assessment measures your exposure to threats and your readiness for an official audit
Asset Inventory: Maintain an updated list of all your hardware, software, data repositories, 
and cloud workloads.
Threat Identification: Identify threat actors (e.g., ransomware groups, accidental insider threats)
 and map them against known vulnerabilities.
Gap Analysis: Perform pre-audit checks against frameworks like ISO 27001 or 
SOC 2 to find weak controls before a firm like Deloitte assesses them

5. Recommended Tools for Auditing & Compliance
Utilizing the right software stack makes continuous compliance manageable
Governance, Risk, and Compliance (GRC) Platforms: Tools like Vanta, Hyperproof, or
 Drata help automate evidence collection, policy tracking, and risk assessment workflows.
Vulnerability Scanning: Tools like Nessus or Qualys to automatically scan systems 
for known security flaws and unpatched software.
Network Analysis: Use Nmap for mapping network surfaces and Wireshark 
for capturing/inspecting network packets.
Deloitte-Specific Tech: For major global audits, Deloitte uses their proprietary 
Omnia technology for data analysis, agile analytics, and risk evaluation
To determine the most critical next step for your security posture, please tell me:
Are you currently preparing for a specific compliance framework (e.g., SOC 2, HIPAA, GDPR)?
What is the main infrastructure environment you need to assess (e.g., AWS Cloud, on-premises data centers, hybrid)