Showing posts with label Interview Questions. Show all posts
Showing posts with label Interview Questions. Show all posts

Saturday, May 30, 2026

Physical Standby vs Logical Standby vs Snapshot Standby

 For Oracle DBA interviews and real production environments, understanding Physical Standby vs Logical Standby vs Snapshot Standby is critical because interviewers often ask not only the definitions but also why companies choose one over another.


Oracle Data Guard Standby Types – Complete Comparison

FeaturePhysical StandbyLogical StandbySnapshot Standby
Database StructureExact block-by-block copyLogical copy using SQLPhysical standby temporarily converted to RW
Redo Apply MethodRedo Apply (MRP)SQL Apply (LSP)Redo received but not applied
Read OnlyYes (Active Data Guard)YesNo
Read WriteNo (unless activated)YesYes
DR ReadyYesPartialNo
Switchover SupportYesYesNo
Failover SupportYesLimitedNo
Performance ImpactLowestHigherModerate
Most Common in ProductionYesRareRare

1. Physical Standby Database

How It Works Internally

The primary database generates redo logs.

Primary Database
      |
      v
 Archive Logs / Redo Transport
      |
      v
Physical Standby
      |
      v
MRP (Managed Recovery Process)
      |
      v
Apply Redo Blocks

The standby receives redo and applies changes at the block level.

Oracle does not execute SQL.

It simply recreates the exact same database blocks as the primary.


Example

Primary:

INSERT INTO EMP VALUES (101,'SCOTT');
COMMIT;

Redo generated:

Block #123 modified

Standby:

Apply Block #123

No SQL execution occurs.


Read/Write Capability

Standard Physical Standby

Read = Yes
Write = No

Active Data Guard

Read = Yes
Write = No
Real-Time Queries = Yes

Advantages

✔ Exact copy of primary

✔ Fast redo apply

✔ Supports switchover/failover

✔ Simplest architecture

✔ Best DR solution

✔ Minimal administration


Limitations

✖ Cannot modify data

✖ Requires Active Data Guard license for real-time reporting


Real Production Usage

Most companies use:

Primary RAC
      |
      |
Physical Standby

Typical industries:

  • Banking

  • Insurance

  • Healthcare

  • Manufacturing

  • E-Commerce

This is the industry standard DR architecture.


2. Logical Standby Database

How It Works Internally

Instead of applying redo blocks, Oracle converts redo into SQL statements.

Primary
   |
Redo Logs
   |
LogMiner
   |
SQL Apply
   |
Logical Standby

Oracle uses:

LogMiner

to extract SQL from redo logs.


Example

Primary:

INSERT INTO EMP VALUES (101,'SCOTT');
COMMIT;

Redo arrives.

Logical standby converts it to:

INSERT INTO EMP VALUES (101,'SCOTT');

Then executes the SQL.


Internal Flow

Redo
  |
LogMiner
  |
Generate SQL
  |
Execute SQL
  |
Update Standby

Read/Write Capability

Read = Yes
Write = Yes

Users can create additional:

  • Tables

  • Indexes

  • Materialized Views

  • Reporting Objects

without affecting replication.


Advantages

✔ Open read/write

✔ Useful for reporting

✔ Can create local objects

✔ Supports heterogeneous workloads


Limitations

✖ More CPU intensive

✖ SQL Apply slower than Redo Apply

✖ Not all datatypes supported

✖ More administration

✖ Not widely used today


Real Production Usage

Usually for:

  • Reporting databases

  • Data warehouse environments

  • Separate reporting schemas

Example:

Primary OLTP
       |
Logical Standby
       |
BI Reports

3. Snapshot Standby Database

How It Works Internally

Snapshot standby begins as a physical standby.

Physical Standby
       |
Convert
       |
Snapshot Standby

When converted:

  • Redo continues arriving

  • Redo is NOT applied

Oracle stores incoming redo for later use.


Internal Architecture

Primary
   |
Redo Transport
   |
Snapshot Standby
   |
Redo Stored
(Not Applied)

Users can modify data freely.


Example

Developer creates:

DELETE FROM EMP;
COMMIT;

Allowed.

Later:

Convert back to Physical Standby

Oracle discards local changes and applies accumulated redo.


Read/Write Capability

Read = Yes
Write = Yes

Fully read/write.


Advantages

✔ Testing environment

✔ Application upgrade testing

✔ Patch validation

✔ Production-like testing


Limitations

✖ Not DR ready

✖ Cannot failover

✖ Redo apply paused

✖ Local changes lost after conversion


Real Production Usage

Common for:

Application Upgrade Testing

Production
      |
Snapshot Standby
      |
Upgrade Testing

Patch Testing

Patch Validation
Before Production Rollout

Which Standby Type Do Companies Prefer?

Enterprise Reality

If you visit 100 companies:

Standby TypeUsage Percentage
Physical Standby~90%
Snapshot Standby~8%
Logical Standby~2%

Why Physical Standby Wins

Because organizations need:

✔ Disaster Recovery

✔ Fast Failover

✔ Data Protection

✔ Simplicity

✔ Low Administration

Physical standby provides all of these.


Licensing Considerations

Physical Standby

Included with Data Guard.


Active Data Guard

Requires additional license.

Provides:

✔ Read-only reporting

✔ Real-time query

✔ Automatic block repair


Logical Standby

Included with Data Guard.


Snapshot Standby

Included with Data Guard.


Interview Answer (2-Minute Version)

Physical Standby is an exact block-level copy of the primary database. Redo is applied using Managed Recovery Process (MRP). It is mainly used for High Availability and Disaster Recovery and is the most widely used standby type in production.

Logical Standby converts redo into SQL statements using LogMiner and applies them through SQL Apply. It supports read-write access and is mainly used for reporting environments, though it is less common due to complexity and datatype limitations.

Snapshot Standby is a temporary read-write version of a physical standby. Redo continues to be received but is not applied until the database is converted back to physical standby. It is commonly used for testing, patch validation, and upgrade rehearsals.

In real enterprise environments, Physical Standby is the preferred and most commonly deployed Data Guard configuration because it provides the best balance of data protection, performance, and operational simplicity.

Oracle DBA Interview Questions & Answers (L2/L3/Senior DBA)

 


1. Patching & Maintenance

Q1. What is Database Patching?

Database patching is the process of applying Oracle-provided fixes to resolve bugs, security vulnerabilities, performance issues, and stability problems without reinstalling the database software.

Real-time Example:
We regularly apply Release Updates (RU) on Oracle 19c every quarter to stay compliant with Oracle Critical Patch Updates (CPU).


Q2. What is an Oracle Patch?

An Oracle patch is a software update released by Oracle to fix:

  • Security vulnerabilities

  • Database bugs

  • RAC issues

  • ASM issues

  • Performance problems


Q3. Why is Patching Important?

Benefits:

  • Security compliance

  • Bug fixes

  • Improved stability

  • Better performance

  • Oracle support certification

Failure to patch may expose systems to known security exploits.


Q4. Types of Oracle Patches

Interim Patch

  • Fixes specific bug

Release Update (RU)

  • Quarterly patch bundle

Release Update Revision (RUR)

  • Additional fixes on RU

OJVM Patch

  • Java VM security fixes

One-Off Patch

  • Single bug fix

Grid Infrastructure Patch

  • RAC/ASM/Clusterware fixes


Q5. What is PSU Patching?

PSU (Patch Set Update) was used in Oracle 11g and 12c.

It contained:

  • Security fixes

  • Selected bug fixes

PSU has now been replaced by RU (Release Updates).


Q6. How to Verify PSU/RU Installed?

SQL

SELECT * FROM dba_registry_sqlpatch;

OPatch

opatch lsinventory

Q7. How to Check OPatch Conflicts?

opatch prereq CheckConflictAgainstOHWithDetail \
-phBaseDir /tmp/patch

Interviewers like this answer because it shows practical experience.


Q8. Have You Applied OEM Patches?

Yes.

OEM patching involves:

  • OMS patch

  • Agent patch

  • Plug-in patch

Commands:

emctl stop oms -all
opatch apply
emctl start oms

Always validate OMS and repository after patching.


Q9. How to Patch if OraInventory is Missing?

Recreate inventory

runInstaller -silent \
-attachHome \
ORACLE_HOME=/u01/app/oracle/product/19c

Verify:

opatch lsinventory

Q10. Why RAC Shows Rolling Patch Status?

Check:

crsctl query crs activeversion

Occurs when:

  • One node patched

  • Remaining nodes not patched

Complete patching on all nodes:

rootcrs.sh -postpatch

Then rolling patch mode disappears.


2. ASM, RAC & Clusterware

Q11. Have You Worked on ASM?

Yes.

Typical architecture:

Disk
 ↓
Failure Group
 ↓
Disk Group
 ↓
ASM Instance
 ↓
Database

Common disk groups:

  • DATA

  • FRA

  • OCR

  • VOTE


Q12. What is Cache Fusion?

Cache Fusion is RAC's mechanism to transfer data blocks directly between instances through the private interconnect.

Instead of:

Disk → Instance

Oracle performs:

Instance A → Interconnect → Instance B

Benefits:

  • Reduced disk IO

  • Faster block access


Q13. What is SCAN Listener?

SCAN = Single Client Access Name

Benefits:

  • Single connection string

  • Load balancing

  • Failover

Example:

myrac-scan.company.com

Usually resolves to 3 IP addresses.


Q14. How to Locate SCAN Listener?

srvctl config scan
srvctl config scan_listener
srvctl status scan_listener

Q15. What is TFA?

Trace File Analyzer

Used for:

  • RAC troubleshooting

  • Log collection

  • Incident diagnostics

Commands:

tfactl status
tfactl diagcollect

Q16. What is AWR?

Automatic Workload Repository

Captures:

  • SQL statistics

  • Wait events

  • IO activity

  • Memory usage

Snapshots taken every hour by default.


3. Backup & Recovery

Q17. What is Recovery Catalog?

Separate schema/database used by RMAN to store:

  • Backup metadata

  • Scripts

  • Recovery history

Benefits:

  • Centralized backup management

  • Longer retention


Q18. Media Recovery vs Crash Recovery

Crash Recovery

Occurs automatically after instance failure.

Uses:

Online Redo Logs

No DBA intervention required.


Media Recovery

Required when datafiles are lost.

Uses:

Backup + Archive Logs

Requires DBA action.


Q19. Restore vs Recover

Restore

Copies backup files back.

Backup → Disk

Recover

Applies redo logs.

Datafiles + Redo

Restore alone is not sufficient.


Q20. Thousands of Archive Log Gaps in Standby

Check gap

SELECT * FROM v$archive_gap;

Solution

  1. Incremental backup from SCN

BACKUP INCREMENTAL FROM SCN;
  1. Transfer backup

  2. Recover standby

This is faster than transferring thousands of logs.


Q21. Prevent Block Corruption in Standby

Enable:

db_block_checking=FULL
db_block_checksum=FULL

RMAN:

BACKUP VALIDATE

Data Guard automatically detects physical corruption during redo apply.


4. Data Guard & Disaster Recovery

Q22. Have You Worked on DR?

Yes.

Experience includes:

  • Physical Standby

  • Switchover

  • Failover

  • DR Drills

  • Active Data Guard


Q23. Logs Not Reaching Standby

Check:

Network

tnsping standby

Archive Destination

SELECT dest_name,status,error
FROM v$archive_dest;

Listener

lsnrctl status

Data Guard Processes

SELECT process,status
FROM v$managed_standby;

Q24. Physical vs Snapshot Standby

Physical Standby

  • Read-only

  • Redo Apply ON

  • DR ready

Snapshot Standby

  • Read/Write

  • Redo Apply OFF

  • Used for testing

Can be converted back later.


5. Performance Tuning

Q25. Important Sections in AWR

Focus on:

Database Time

Top waits

Top SQL

High resource SQL

Load Profile

Transactions/sec

Wait Events

IO bottlenecks

RAC Statistics

Global cache waits

Advisory Section

Memory recommendations


Q26. Oracle Performance Tools

  • AWR

  • ASH

  • ADDM

  • OEM

  • SQL Monitor

  • SQL Tuning Advisor

  • Explain Plan

  • TKPROF


Q27. Why Rebuild Index?

Reasons:

  • Excessive fragmentation

  • High deleted leaf blocks

  • Space reclamation

ALTER INDEX idx_name REBUILD ONLINE;

Do not rebuild routinely without evidence.


Q28. Production Slow During Peak Hours

Step 1

Check database load

SELECT * FROM v$sysmetric;

Step 2

Generate AWR

Step 3

Check Top Wait Events

Examples:

db file sequential read
log file sync
gc buffer busy

Step 4

Check blocking sessions

v$session

Step 5

Check storage latency

iostat -x

Step 6

Tune SQL

Step 7

Increase resources if required

Real Production Example:
A batch job introduced a Cartesian join causing CPU to hit 95%. After creating a composite index and gathering statistics, execution time reduced from 3 hours to 12 minutes.


6. Archive Log Full Scenario

Q29. Archive Destination Full

Immediate Actions

Identify usage:

df -h

Delete obsolete backups:

DELETE OBSOLETE;

Backup archive logs:

BACKUP ARCHIVELOG ALL DELETE INPUT;

Add temporary storage.

Resume database:

ALTER SYSTEM ARCHIVE LOG CURRENT;

Long-Term Prevention

  • FRA monitoring

  • OEM alerts

  • Archive deletion policy

CONFIGURE ARCHIVELOG DELETION POLICY;
  • Increase FRA size

  • Fix Data Guard lag issues


7. Database Administration

Q30. Minimum Parameters for Table Export

expdp system/password \
tables=EMP \
directory=DATA_PUMP_DIR \
dumpfile=emp.dmp \
logfile=emp.log

Required:

  • TABLES

  • DIRECTORY

  • DUMPFILE


Q31. High-Level Cloning Steps

Source

  • Take RMAN backup

Target

  • Restore controlfile

  • Restore datafiles

  • Recover database

Rename

nid

Update

spfile
listener
tnsnames

Open database


Q32. What is Table Partitioning?

Partitioning divides a large table into smaller logical segments.

Types

  • Range

  • List

  • Hash

  • Composite

Benefits

  • Faster queries

  • Faster maintenance

  • Partition pruning

  • Easier archival

Example:

Instead of one 5 TB SALES table:

SALES_2023
SALES_2024
SALES_2025
SALES_2026

Oracle scans only required partitions, significantly improving performance.


Senior DBA Interview Closing Statement

When answering scenario-based questions, use the format:

Problem → Analysis → Action → Result

Example:

Problem: Archive destination reached 100%.

Analysis: FRA full due to standby transport issue.

Action: Cleared obsolete archives, increased FRA temporarily, fixed Data Guard transport.

Result: Database resumed without downtime and preventive monitoring was implemented.

This structure demonstrates production support experience, which is exactly what interviewers look for in Oracle DBA candidates with 8–15+ years of experience.

Common Oracle DBA interview questions


1. General & Project Understanding

Q1. Self Introduction

Sample Answer:

"My name is Shashi Ranjan Singh and I have over 10 years of experience as an Oracle Database Administrator. Currently, I am working as a Lead Cloud Database Engineer managing Oracle RAC, Data Guard, GoldenGate, OEM, RMAN, and ZDLRA environments.

My responsibilities include database administration, performance tuning, disaster recovery management, database upgrades, patching, automation through shell scripting, and cloud migration activities. I also actively participate in database architecture reviews and production issue resolution."


Q2. Explain Your Current Project Architecture

Sample Answer:

"Our production environment consists of Oracle 19c RAC databases hosted on Linux servers. We have a 2-node RAC setup for high availability.

For disaster recovery, we maintain Oracle Data Guard in Maximum Availability mode. Oracle GoldenGate is used for real-time replication to downstream reporting systems.

We use OEM for monitoring, RMAN with ZDLRA for backups, and application servers connect through SCAN listeners."


Q3. What database versions are you working on?

Answer:

  • Oracle 19c (Primary)

  • Oracle 21c (Testing)

  • Experience with 11g, 12c, 18c, and upgrade projects


Q4. Individual Contributor or Team?

Answer:

"I work both as an individual contributor and as a team lead. I handle critical production incidents, mentor junior DBAs, review changes, and coordinate with application, infrastructure, and storage teams."


Q5. New Technologies Learning?

Answer:

  • Oracle Database 23ai/26ai

  • OCI Services

  • Kubernetes

  • Terraform

  • Ansible Automation

  • AI-integrated database features


2. Tablespace Monitoring & Storage Management

Q6. How do you monitor tablespaces?

Answer:

Using:

  • OEM Alerts

  • Custom SQL Scripts

  • Shell scripts

  • Email notifications

Example:

SELECT tablespace_name,
ROUND((used_space/tablespace_size)*100,2) USED_PERCENT
FROM dba_tablespace_usage_metrics;

Q7. Why is tablespace monitoring important?

Answer:

To avoid:

  • Application failures

  • ORA-01653

  • ORA-01654

  • Transaction failures

  • Data loading failures


Q8. What happens if tablespace becomes full?

Answer:

Users cannot insert data.

Common errors:

ORA-01653 unable to extend table
ORA-01654 unable to extend index

Application may become unavailable.


Q9. Are tablespaces critical?

Answer:

Yes.

If SYSTEM, SYSAUX, UNDO, TEMP or application tablespaces become full, production applications can stop functioning.


3. Performance Tuning & Troubleshooting

Q10. Application is slow. How do you troubleshoot?

Step 1

Check database health.

top
vmstat
iostat

Step 2

Check sessions.

SELECT sid,serial#,event
FROM v$session;

Step 3

Check blocking sessions.

Step 4

Analyze AWR report.

Step 5

Review SQL consuming high resources.

v$sql

Step 6

Check storage latency.

Step 7

Coordinate with application team.


Q11. What is Query Tuning?

Answer:

Optimizing SQL statements to reduce CPU, memory, and IO consumption while improving response time.


Q12. How do you know query tuning is needed?

Indicators:

  • High elapsed time

  • High buffer gets

  • Full table scans

  • Excessive IO

  • SQL appears in Top SQL section of AWR


Q13. SQL Tuning Steps

  1. Identify SQL

  2. Generate execution plan

EXPLAIN PLAN
  1. Analyze access path

  2. Create/rebuild indexes

  3. Update statistics

EXEC DBMS_STATS.GATHER_SCHEMA_STATS;
  1. Test changes


Q14. Batch Jobs Slow. Which report?

Answer:

AWR Report

If issue is real-time:

  • ASH Report

If root cause analysis:

  • ADDM Report


Q15. What is ADDM?

Answer:

Automatic Database Diagnostic Monitor.

It analyzes AWR snapshots and identifies:

  • SQL bottlenecks

  • CPU issues

  • Memory issues

  • I/O problems

It also provides recommendations.


4. Indexing Concepts

Q16. What is Indexing?

Answer:

Index is a database object that improves data retrieval speed by avoiding full table scans.

Think of it like a book index.


Q17. Types of Indexes Used?

Answer:

  • B-tree Index

  • Bitmap Index

  • Composite Index

  • Unique Index

  • Function-Based Index

  • Reverse Key Index

  • Partitioned Index


Q18. Why Rebuild Index?

Answer:

To:

  • Reduce fragmentation

  • Improve index efficiency

  • Reclaim unused space

Command:

ALTER INDEX index_name REBUILD ONLINE;

5. User & Security Management

Q19. How do you manage security?

Answer:

  • Create users

  • Assign roles

  • Principle of least privilege

  • Password policies

  • Auditing

  • Encryption


Q20. Grant Privileges?

GRANT CREATE SESSION TO user1;

GRANT SELECT,INSERT,UPDATE
ON emp TO user1;

Q21. Secure Data Transfer?

Answer:

  • SCP

  • SFTP

  • Rsync over SSH

  • Oracle Data Pump with encryption

Example:

scp file.dmp server:/backup

Q22. What is Data Masking?

Answer:

Replacing sensitive data with fictitious values.

Example:

Original:

9876543210

Masked:

XXXXXX3210

Used in non-production environments.


6. Upgrade, Cloning & Recovery

Q23. What is Database Upgrade?

Answer:

Moving database from lower version to higher version.

Example:

11g → 19c

Benefits:

  • Security

  • Performance

  • New features


Q24. Upgrade Validation (11g/12c/19c)

Answer:

Pre-upgrade:

preupgrade.jar

Check:

  • Invalid objects

  • Backup availability

  • Tablespace size

  • Compatibility

Post Upgrade:

utlrp.sql

Validate:

SELECT * FROM dba_registry;

Q25. Cloning Requirements

Answer:

  • Source backup

  • Sufficient storage

  • Oracle binaries

  • Network connectivity

  • Password files

  • TNS entries


Q26. Post Restore Steps

  1. Recover database

  2. Open database

ALTER DATABASE OPEN RESETLOGS;
  1. Validate objects

  2. Gather statistics

  3. Enable jobs

  4. Verify applications


7. Shell Scripting & Automation

Q27. Monitor CPU Every 30 Minutes

#!/bin/bash

DATE=$(date)

CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')

echo "$DATE CPU Usage : $CPU" >> /tmp/cpu.log

Cron Entry:

*/30 * * * * /home/oracle/cpu_monitor.sh

8. Oracle Concepts

Q28. What is Seeded SQL?

Answer:

Seeded SQL refers to Oracle-provided SQL statements embedded within Oracle applications such as Oracle EBS.

These SQLs are delivered by Oracle and generally should not be modified directly.

Examples:

  • Concurrent Program SQL

  • Standard Reports SQL

  • Workflow SQL


9. Behavioral & Scenario-Based Questions

Q29. Decision-Making Scenario

Answer:

"During a critical production issue, archive logs were accumulating rapidly due to a Data Guard transport failure, causing the FRA to reach 95% utilization. I quickly analyzed the issue, coordinated with the network team, temporarily increased FRA space, and restored log transport. This prevented database downtime and avoided a production outage."


Q30. Conflict Resolution

Answer:

"I focus on facts and data rather than opinions. When conflicts arise, I gather technical evidence, discuss the issue with stakeholders, evaluate options, and work toward a solution that best supports business objectives while maintaining system stability."


Q31. Why Do You Want to Join Our Company?

Answer:

"Your organization has a strong reputation for innovation, technology leadership, and investment in modern cloud and database technologies. The role aligns closely with my experience in Oracle RAC, Data Guard, GoldenGate, performance tuning, and cloud platforms. I believe I can contribute immediately while also expanding my skills through challenging projects and collaboration with experienced professionals."

Interview Tip for 10+ Years Oracle DBA

For senior-level interviews, always answer in this format:

Concept → Real-Time Example → Action Taken → Result

This demonstrates hands-on production experience and differentiates you from candidates who provide only theoretical answers.

Thursday, April 23, 2026

OEM Runbook (L2/L3) – Oracle Monitoring & Alert Management



📘 OEM Runbook (L2/L3) – Oracle Monitoring & Alert Management

Using Oracle Enterprise Manager 13c


🎯 Objective

To:

  • Monitor database health

  • Detect issues proactively

  • Reduce alert noise

  • Troubleshoot incidents quickly


🧭 1. First Response Playbook (When Alert Comes)

🚨 Step 1: Open Incident Manager

📍 Navigation:

Enterprise → Monitoring → Incidents

Check:

  • Severity (Critical / Warning)

  • Target (DB / Host / Listener)

  • Message (Tablespace / CPU / Lock etc.)


🧠 Step 2: Identify Issue Type

Alert TypeMeaningAction
CPU HighPerformance issueCheck SQL / load
Tablespace FullStorage issueAdd space
Session BlockingLock issueKill blocker
Host DownInfra issueCheck server
Listener DownConnectivity issueRestart

🔍 2. Deep Dive Troubleshooting


⚡ Case 1: Database Performance Issue

Step 1: Open Performance Page

📍

Target → Database → Performance → Top Activity

Check:

  • CPU usage

  • Wait events

  • Active sessions


Step 2: Identify Top SQL

📍

Performance → SQL Monitoring / Top SQL

Action:

  • Find high elapsed time SQL

  • Capture SQL_ID


Step 3: Analyze Execution Plan

SELECT *
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>', NULL, 'ALLSTATS LAST'));

Step 4: Fix

  • Add index

  • Gather stats

  • Apply SQL Profile


🔒 Case 2: Blocking / Locking Issue

Step 1: Check Blocking Sessions

📍

Performance → Blocking Sessions

OR SQL:

SELECT blocking_session, sid, serial#
FROM v$session
WHERE blocking_session IS NOT NULL;

Step 2: Kill Blocking Session

ALTER SYSTEM KILL SESSION 'SID,SERIAL#' IMMEDIATE;

Step 3: Root Cause

  • Application not committing

  • Long transactions


💾 Case 3: Tablespace Full

Step 1: Check Usage

📍

Storage → Tablespaces

Step 2: Add Space

ALTER DATABASE DATAFILE '/path/file.dbf'
RESIZE 10G;

OR

ALTER TABLESPACE users
ADD DATAFILE '/path/file02.dbf' SIZE 5G;

🔥 Case 4: CPU Spike

Step 1: Check Load

📍

Performance → Top Activity

Step 2: Identify Cause

  • High SQL load

  • Batch jobs

  • Parallel queries


Step 3: Action

  • Tune SQL

  • Kill runaway sessions

  • Limit parallelism


🌐 Case 5: Listener / Connectivity Issue

Step 1: Check Listener Status

lsnrctl status

Step 2: Restart Listener

lsnrctl stop
lsnrctl start

🔁 3. Alert Noise Reduction (VERY IMPORTANT)


🔧 Configure Thresholds

📍

Targets → Monitoring → Metric Settings

Best Practice:

  • Warning: 80%

  • Critical: 90%

  • Occurrence: 3


🔁 Configure Incident Rules

📍

Setup → Incidents → Incident Rules

Enable:

  • ✔ Add to existing incident

  • ✔ Event grouping


🔕 Configure Notifications

📍

Setup → Notifications

Rule:

  • Only Critical alerts → Email


⛔ Configure Blackouts

📍

Enterprise → Monitoring → Blackouts

Use During:

  • Patching

  • Maintenance


📊 4. Daily Health Check (L2 Task)


✅ Check 1: Incident Summary

Enterprise → Incidents

✅ Check 2: DB Status

Targets → Databases

✅ Check 3: Tablespace Usage

Storage → Tablespaces

✅ Check 4: Backup Status

Availability → Backup Reports

✅ Check 5: Performance

Performance → Top Activity

🚀 5. L3 Advanced Activities


🔬 AWR / ADDM Analysis

📍

Performance → AWR → Reports

⚙️ SQL Tuning Advisor

📍

Performance → SQL → Tuning Advisor

🧠 ASH Analytics

📍

Performance → ASH Analytics

🔄 Corrective Actions (Auto-Healing)

📍

Metric Settings → Corrective Actions

Example:

lsnrctl start

🎯 6. SLA / Escalation Matrix

SeverityActionSLA
CriticalImmediate fix15 mins
HighInvestigate30 mins
MediumMonitor2 hrs
LowReviewNext day

🧠 7. Interview Questions (L2/L3)


❓ How do you troubleshoot OEM alert?

Answer:

I check Incident Manager, identify alert type, drill into performance metrics, analyze SQL or system issue, and apply corrective action.


❓ How do you reduce alert noise?

Answer:

  • Tune thresholds

  • Configure incident rules

  • Use blackout

  • Filter notifications


❓ What is difference between Event and Incident?

EventIncident
Raw alertGrouped issue

❓ What is your first step in performance issue?

Answer:

Check Top Activity and wait events to identify bottleneck.


🏁 Final Production Mindset

“OEM is not just a monitoring tool…
It is your control tower for the entire database ecosystem.”



Monday, April 13, 2026

The Real Skill That Gets You Hired as a DBA

 Most DBAs prepare for interviews by listing tools.

Oracle. RMAN. Data Guard. OEM.

But in 2026, hiring decisions are not made on tools.

They are made on one question:

“𝐂𝐚𝐧 𝐲𝐨𝐮 𝐡𝐚𝐧𝐝𝐥𝐞 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐰𝐡𝐞𝐧 𝐭𝐡𝐢𝐧𝐠𝐬 𝐠𝐨 𝐰𝐫𝐨𝐧𝐠?”
Here’s what senior hiring managers actually look for.


𝗦𝗶𝗴𝗻𝗮𝗹 1: Problem-Solving Mindset
Strong candidates don’t jump to solutions.
They break problems down.

They can explain:
• what they observed
• how they narrowed it down
• why they chose a specific approach

This shows 𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞𝐝 𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠 𝐮𝐧𝐝𝐞𝐫 𝐩𝐫𝐞𝐬𝐬𝐮𝐫𝐞.

“𝑮𝒐𝒐𝒅 𝑫𝑩𝑨𝒔 𝒇𝒊𝒙 𝒊𝒔𝒔𝒖𝒆𝒔. 𝑮𝒓𝒆𝒂𝒕 𝑫𝑩𝑨𝒔 𝒖𝒏𝒅𝒆𝒓𝒔𝒕𝒂𝒏𝒅 𝒕𝒉𝒆𝒎 𝒇𝒊𝒓𝒔𝒕.”

𝗦𝗶𝗴𝗻𝗮𝗹 2: Production RCA Capability 🔍
Anyone can say “issue resolved.”
Few can explain 𝐰𝐡𝐲 𝐢𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐞𝐝.

What stands out:
• connecting metrics, logs, and events
• identifying root cause vs symptom
• explaining impact and prevention

This is where real experience becomes visible.

“𝑹𝒆𝒔𝒐𝒍𝒖𝒕𝒊𝒐𝒏 𝒄𝒍𝒐𝒔𝒆𝒔 𝒊𝒏𝒄𝒊𝒅𝒆𝒏𝒕𝒔. 𝑹𝑪𝑨 𝒑𝒓𝒆𝒗𝒆𝒏𝒕𝒔 𝒕𝒉𝒆𝒎.”

𝗦𝗶𝗴𝗻𝗮𝗹 3: Backup & DR Confidence
This is non-negotiable.

Hiring managers expect clarity on:
• RMAN strategies
• restore and recovery scenarios
• RPO/RTO discussions

Hesitation here signals 𝐫𝐢𝐬𝐤 𝐢𝐧 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐨𝐰𝐧𝐞𝐫𝐬𝐡𝐢𝐩.

𝗦𝗶𝗴𝗻𝗮𝗹 4: Monitoring & Observability Awareness

Modern DBAs don’t wait for failures.

They understand:
• wait events
• performance metrics
• alert patterns
• system behavior trends

Monitoring reflects 𝐨𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐚𝐥 𝐦𝐚𝐭𝐮𝐫𝐢𝐭𝐲.

“Strong DBAs detect early. Weak DBAs react late.”

𝗦𝗶𝗴𝗻𝗮𝗹 5: Automation & Efficiency Thinking

Manual processes don’t scale.

Strong candidates show:
• scripting ability (Shell/Python)
• automation of routine tasks
• consistency in operations

Automation shows you think beyond the immediate problem.


𝐓𝐡𝐞 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐑𝐞𝐚𝐥𝐢𝐭𝐲

Hiring evaluation typically follows this model:
𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 → 𝐀𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 → 𝐃𝐞𝐜𝐢𝐬𝐢𝐨𝐧-𝐌𝐚𝐤𝐢𝐧𝐠 → 𝐎𝐰𝐧𝐞𝐫𝐬𝐡𝐢𝐩

Most candidates stop at knowledge.
Senior DBAs demonstrate ownership under uncertainty.

𝐊𝐞𝐲 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲𝐬

• Problem-solving matters more than tool knowledge
• RCA capability separates mid-level from senior DBAs
• Backup, DR, and monitoring define production readiness

In 2026, Oracle DBAs are not just administrators.
They are 𝐫𝐞𝐥𝐢𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐥𝐞 𝐟𝐨𝐫 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐜𝐨𝐧𝐭𝐢𝐧𝐮𝐢𝐭𝐲.