https://www.dbnexus.co.in/, https://www.youtube.com/@OracleDBAOnlineTraining

DBNexus Training & Consulting, Bhayander, Thane (2026)

16/10/2026

What really stops split brain in Oracle RAC? Voting disks.
Day 4 of 30 Days of Oracle RAC: CSSD heartbeats, the voting disk majority rule, misscount and node eviction.
Next: Day 5 - OCR and OLR.
Enroll in our advanced recorded courses: www.dbnexus.co.in

13/10/2026

Node 2 needs a block that node 1 just changed in memory. Write it to disk and read it back? Too slow.

Day 2 of 30 Days of Oracle RAC: Cache Fusion, memory to memory over the private interconnect, tracked by the Global Resource Directory.

Next: Day 3 - Clusterware. Follow DBNexus so you don't miss it.
Enroll in our advanced recorded courses: www.dbnexus.co.in

12/10/2026

🎯 Oracle DBA Interview Series | Q #18 – EXADATA: "IORM — how do you protect a critical DB in a consolidated rack?"

Twenty databases share one rack, and at noon dev launches a full scan. Most candidates answer with instance caging — which does nothing where the contention happens: the storage cells.

What they're really testing: Do you control I/O at the storage cells, not just CPU in the DB?

A strong answer covers:
✅ Check the current plan on every cell: dcli -g cell_group -l celladmin cellcli -e "LIST IORMPLAN DETAIL"
✅ Objective must not be basic, or plans are not fully enforced: ALTER IORMPLAN objective=auto (default since 21.2)
✅ A share-based dbplan: ALTER IORMPLAN dbplan=((name=prod, share=16), (name=dev, share=1, limit=30), (name=DEFAULT, share=2))
✅ Protect the cache too: flashcachemin guarantees flash cache for PROD, flashcachesize hard-caps a noisy tenant, flashlog=off keeps dev out of Flash Log
✅ ExaCS / ExaCC: no cell login — set IORM shares per database from the OCI console or API

❌ Trap: "I'd use instance caging." CPU_COUNT caps CPU only. A caged dev database can still flood the cells and slow PROD's log writes.

The model answer: IORM sits in cellsrv and decides whose I/O request leaves the queue next. Shares are relative (1–32, higher wins) and only matter under contention — PROD wins when the cells are busy, yet dev still uses the whole rack at 2 AM. limit is different: an absolute cap on flash I/O utilisation that applies even when the rack is idle, so use it sparingly. Directives are matched on DB_UNIQUE_NAME; apply the identical plan to every cell. Inside a CDB, the CDB resource plan splits that database's slice, and IORM enforces it.

War story: PROD's log file sync climbed every month-end while its CPU stayed flat. The cause was a reporting database on the same cells with no IORM plan — so every database had an equal share.

Follow-ups they'll ask next:
• share vs limit? Share = priority under contention; limit = hard ceiling, always on.
• Primary vs standby? role=primary / role=standby directive pairs, so shares follow the role after a switchover.
• How do you prove it works? LIST METRICCURRENT WHERE objectType='IORM_DATABASE' — watch DB_IO_UTIL_* and DB_IO_WT_* per database.

💡 Interview tip: Say shares first, limits last — limits waste idle capacity.

📌 Save this for your next Oracle DBA interview — and try answering out loud before you read the card.

🌐 Live Oracle DBA (26ai) Training, Mock Interviews & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 How would YOU answer this in 60 seconds? Drop your version below.

12/10/2026

Your entire company runs on ONE database server. 3 AM, it crashes. Who fixes it?

Day 1 of 30 Days of Oracle RAC: Real Application Clusters explained in 60 seconds. One database, many servers, zero downtime.

Next: Day 2 - Cache Fusion. Follow DBNexus so you don't miss it.

Enroll in our advanced recorded courses: www.dbnexus.co.in

11/10/2026

🚀 Oracle DBA Learning Series | Day 36 – Oracle Data Guard: Data Guard Broker — DGMGRL Essentials

"The broker is just a GUI convenience — real DBAs manage Data Guard in SQL*Plus." In production that mindset causes more failed switchovers than any network outage. Once the broker is enabled, it owns the configuration.

In today's visual guide, you'll learn:
✅ Enabling the broker: DG_BROKER_START=TRUE + config files on shared storage
✅ CREATE CONFIGURATION ... AS PRIMARY DATABASE IS prod
✅ ADD DATABASE stby ... MAINTAINED AS PHYSICAL, then ENABLE CONFIGURATION
✅ SHOW CONFIGURATION + VALIDATE DATABASE before every role change
✅ 23ai/26ai: VALIDATE DGConnectIdentifier and EDIT ALL MEMBERS
✅ Gotcha: SQL*Plus edits that trigger ORA-16714

🔹 Step 1 – Start the broker. On RAC, place both files in ASM first, then start it on every database:
ALTER SYSTEM SET dg_broker_config_file1='+DATA/PROD/dr1prod.dat' SID='*';
ALTER SYSTEM SET dg_broker_config_file2='+FRA/PROD/dr2prod.dat' SID='*';
ALTER SYSTEM SET dg_broker_start=TRUE SID='*';
Two files exist so the broker always keeps a last-known-good copy.

🔹 Step 2 – Build it in DGMGRL:
CREATE CONFIGURATION dgcfg AS PRIMARY DATABASE IS prod CONNECT IDENTIFIER IS prod;
ADD DATABASE stby AS CONNECT IDENTIFIER IS stby MAINTAINED AS PHYSICAL;
ENABLE CONFIGURATION;
SHOW CONFIGURATION should end with "Configuration Status: SUCCESS".

🔹 Step 3 – Validate before you switch. VALIDATE DATABASE stby; reports "Ready for Switchover: Yes", apply lag, SRL coverage per thread and log-file mismatches. 19c added VALIDATE NETWORK CONFIGURATION FOR ALL and VALIDATE STATIC CONNECT IDENTIFIER FOR ALL. 23ai/26ai adds VALIDATE DGConnectIdentifier, SHOW/EDIT ALL MEMBERS and stricter switchover-readiness checks.

⚠️ Production gotcha: with the broker enabled, never run ALTER SYSTEM SET log_archive_dest_2 by hand. The broker re-applies its own properties and you get ORA-16714 (property inconsistent). Use EDIT DATABASE stby SET PROPERTY LogXptMode='SYNC'; instead.

🎯 Interview Q: Why can't you change DG_BROKER_CONFIG_FILEn while the broker runs?
A: The files are open by the DMON process. Set DG_BROKER_START=FALSE, move the files, then restart the broker.

📌 Save this post for your next Oracle Data Guard interview or production troubleshooting session.

🌐 Live Oracle DBA (26ai) Training & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 Do you still run any Data Guard changes in SQL*Plus once the broker is enabled — or is DGMGRL your single source of truth? Tell me in the comments.

11/10/2026

🎯 Oracle DBA Interview Series | Q #17 – SECURITY: "TDE key rotation — master key vs tablespace key"

"We rotated the TDE key last quarter." Which one? Most candidates don't know there are two.

What they're really testing: Do you understand TDE's two-tier key hierarchy, and what each rotation actually costs?

A strong answer covers:
✅ Two tiers: the master encryption key (MEK) lives in the keystore (wallet / OKV / OCI Vault) and only wraps the tablespace keys. The tablespace key sits in the datafile header and encrypts the blocks.
✅ Rotate the MEK: ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "pwd" WITH BACKUP; — re-wraps keys only, takes seconds, no data rewrite.
✅ Verify: SELECT key_id, activation_time FROM v$encryption_keys ORDER BY activation_time; — the newest row is the active key.
✅ Rotate the tablespace key: ALTER TABLESPACE users ENCRYPTION ONLINE REKEY; — re-encrypts every block; needs about the tablespace size again in free space.
✅ OCI / ExaCS: dbaascli tde rotateMasterKey --dbname ORCL, or "Rotate encryption key" in the console when the key is customer-managed in OCI Vault.

❌ Trap: "Rotating the master key re-encrypts the data." It doesn't. It re-wraps a few small keys — which is why it's online and instant.

The model answer: "TDE is a two-tier design. Data is encrypted with a tablespace key; that key is itself encrypted by the master key, held outside the database in the keystore. So 'rotation' means two different operations. SET KEY generates a new MEK, re-wraps the tablespace keys and keeps the old MEKs as history. In united mode each PDB has its own MEK, so I rotate per PDB or use CONTAINER=ALL from the root. Tablespace rekey is the heavy one: ONLINE REKEY builds a re-encrypted copy of each datafile, so I check free space, expect extra redo and standby apply load, and run it in a quiet window."

War story: a team rotated the MEK on the primary and never copied the wallet to the standby. Redo apply stopped with ORA-28374 — at 2 AM, naturally. Rotate, then ship the wallet (or use OKV / OCI Vault).

Follow-ups to expect:
• How often? Per your policy's cryptoperiod — commonly yearly for the MEK.
• Keystore lost? The data is unrecoverable. Back up the wallet separately from RMAN backups.
• Can I delete old master keys? No — old backups and archived logs still need them.

💡 Interview tip: Answer the question with a question — "Which key do you mean?"

📌 Save this for your next Oracle DBA interview — and try answering out loud before you read the card.

🌐 Live Oracle DBA (26ai) Training, Mock Interviews & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 How would YOU answer this in 60 seconds? Drop your version below.

10/10/2026

🎯 Oracle DBA Interview Series | Q #16 – DATA GUARD: "Switchover vs failover — exact steps and what can go wrong"

Most candidates can define both. Few can say what happens to the OLD primary afterwards — and that is exactly where the interviewer is heading.

What they're really testing: planned zero-loss role swap vs emergency role change — and whether you can get the old primary back.

A strong answer covers:
✅ Pre-check first: DGMGRL> VALIDATE DATABASE VERBOSE 'stby'; — ready for switchover, no redo gap
✅ Switchover = planned, zero data loss, roles swap: SWITCHOVER TO 'stby';
✅ Failover = primary is gone, standby takes over: FAILOVER TO 'stby'; (IMMEDIATE only when apply is stuck — you accept data loss)
✅ Bring the old primary back as a standby: REINSTATE DATABASE 'prim'; — only works if Flashback Database was ON
✅ Confirm: SHOW CONFIGURATION; and SELECT database_role, switchover_status FROM v$database; (OCI console actions run the same broker steps)

❌ Trap: "Failover is just a faster switchover." A switchover is reversible and loses nothing; a failover is a one-way door that can lose redo and leaves the old primary unusable until it is reinstated or rebuilt.

Model answer: a switchover is a rehearsed operation. I check transport and apply lag, run VALIDATE DATABASE, then issue SWITCHOVER TO. The broker ships end-of-redo, converts the primary to a standby and opens the new primary; SHOW CONFIGURATION returns SUCCESS. Without the broker it is ALTER DATABASE SWITCHOVER TO stby VERIFY; and then the same command without VERIFY.

A failover is for when the primary cannot be saved in time. FAILOVER TO applies all available redo first; in Maximum Availability with SYNC transport that normally means zero data loss, with ASYNC you lose whatever never arrived.

What goes wrong in production: a redo gap nobody noticed, missing standby redo logs on the old primary, no static listener entry for the broker, services that are not role-based, and Flashback switched off — which turns a five-minute reinstate into a full rebuild.

Follow-ups to expect:
• Reinstate without Flashback? Rebuild it — RMAN DUPLICATE ... FOR STANDBY FROM ACTIVE DATABASE.
• What is FSFO? Fast-Start Failover: an observer triggers the failover automatically and reinstates the old primary.
• How do you prove zero data loss? Protection mode plus transport lag in v$dataguard_stats before the role change.

💡 Interview tip: finish every role-transition answer with what happens to the old primary.

📌 Save this for your next Oracle DBA interview — and try answering out loud before you read the card.

🌐 Live Oracle DBA (26ai) Training, Mock Interviews & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 How would YOU answer this in 60 seconds? Drop your version below.

09/10/2026

🎯 Oracle DBA Interview Series | Q #15 – OCI: "Which IAM policies does a DBA need for Base DB / ExaCS?"

Most candidates say "just give me admin on the tenancy". The interviewer wants least privilege, written as real policy statements.

What they're really testing: do you know the verb + resource-type + compartment model, and can you scope a DBA without handing over the tenancy?

A strong answer covers:
✅ The core policy uses the aggregate resource type: Allow group DBAdmins to manage database-family in compartment Prod
✅ Launching a DB system also touches the network: Allow group DBAdmins to use virtual-network-family in compartment Network
✅ ExaCS split duties — the infra team manages cloud-exadata-infrastructures, DBAs get: Allow group DBAs to use cloud-vmclusters in compartment Prod (plus manage db-homes and databases)
✅ Block destructive actions with a condition: Allow group DBAs to manage databases in compartment Prod where request.permission != 'DATABASE_DELETE'
✅ Read-only for operators and auditors: Allow group DBOps to read database-family in compartment Prod

❌ Trap: "Allow group DBAs to manage all-resources in tenancy". It works, and it tells the interviewer you have never been through a security review.

Four verbs, each including the one before: inspect, read, use, manage. database-family is the aggregate covering db-systems, db-nodes, db-homes, databases, pluggable-databases and db-backups — and on Exadata also cloud-exadata-infrastructures and cloud-vmclusters. One "manage database-family" statement makes a full DBA admin for a compartment; the individual types let you carve that up.

The classic production story: a new DBA has manage database-family, clicks Create DB system and gets an authorization error. LaunchDbSystem also needs VNIC_CREATE, VNIC_ATTACH and SUBNET_ATTACH, and nobody granted "use" on the network compartment.

On ExaCS, creating a DB home or a database needs "use cloud-vmclusters" on top of manage db-homes and manage databases. That lets DBAs own databases while another team owns the rack.

Follow-ups to expect:
• Do policies inherit? Yes — a policy on a compartment applies to all its child compartments.
• Why 404 NotAuthorizedOrNotFound? OCI does not reveal whether the resource is missing or you lack permission. Check the policy first.
• Which permission is dangerous on ExaCS? CLOUD_VM_CLUSTER_UPDATE_SSH_KEY — adding a key gives root on the guest VMs.

💡 Interview tip: say the policy out loud — group, verb, resource-type, compartment.

📌 Save this for your next Oracle DBA interview — and answer out loud before reading the card.

🌐 Live Oracle DBA (26ai) Training, Mock Interviews & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 How would YOU answer this in 60 seconds? Drop your version below.

08/10/2026

🎯 Oracle DBA Interview Series | Q #14 – EXADATA: "Flash Cache vs Flash Log — what problem does each solve?"

Both live on the same flash cards in the storage cell, so most candidates answer "they both make I/O faster". The interviewer wants two different problems.

What they're really testing: can you separate read/write caching from commit-latency protection — and prove each one is working?

A strong answer covers:
✅ Smart Flash Cache = a cache for data blocks on flash in front of the hard disks. Fixes slow random I/O: CellCLI> LIST FLASHCACHE DETAIL
✅ Check the mode, never assume it: CellCLI> LIST CELL ATTRIBUTES flashCacheMode — WriteThrough caches reads only; WriteBack also absorbs writes.
✅ Smart Flash Log = redo is written to disk and flash together; the first to finish acknowledges the write. Fixes log file sync spikes: CellCLI> LIST FLASHLOG DETAIL
✅ Prove it with cell metrics: CellCLI> LIST METRICCURRENT WHERE objectType = 'FLASHLOG' — watch FL_PREVENTED_OUTLIERS.
✅ Protect the critical database with IORM: ALTER IORMPLAN dbplan=((name=prod, flashcache=on, flashlog=on), (name=other, flashcache=off, flashlog=off))

❌ Trap: "Flash Log means the redo logs are stored on flash." They are not. The online redo logs stay in the disk group; Flash Log is a small temporary landing area (512 MB per cell by default).

Flash Cache is about throughput and average latency for data blocks. You can pin a segment with ALTER TABLE sales STORAGE (CELL_FLASH_CACHE KEEP). In WriteBack mode, DBWR writes land on flash first and are flushed to disk later, which is what rescues write-heavy OLTP.

Flash Log is about the worst case, not the average. A disk normally acknowledges a redo write quickly through the controller cache, but now and then one write stalls, LGWR waits and every commit waits. Writing to two media at once removes that outlier. That is why FL_DISK_FIRST can exceed FL_FLASH_FIRST while the feature still does its job. And if redo writes skip Flash Log because of the IORM plan, the spikes come back.

Follow-ups to expect:
• Does a flash card failure lose data in WriteBack mode? No — ASM redundancy keeps a mirror on another cell.
• What changed in 20.1? Smart Flash Log Write-Back: flash cache replaces disk as the second target, so throughput improves too.
• On Extreme Flash? Redo already sits on a fast device, so Flash Log is bypassed.

💡 Interview tip: name the wait event each one fixes — db file sequential read vs log file sync.

📌 Save this for your next Oracle DBA interview — and try answering out loud before you read the card.

🌐 Live Oracle DBA (26ai) Training, Mock Interviews & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 How would YOU answer this in 60 seconds? Drop your version below.

06/10/2026

🚀 Oracle DBA Learning Series | Day 34 – Oracle Data Guard: Redo Transport: SYNC vs ASYNC vs FASTSYNC

Most DBAs think SYNC is the price you pay for zero data loss. It isn't. The real switch is AFFIRM vs NOAFFIRM — and that one word is the difference between a 2 ms commit and a 20 ms commit.

In today's visual guide, you'll learn:
✅ SYNC + AFFIRM — commit waits until the standby writes redo to its standby redo log
✅ FASTSYNC (SYNC + NOAFFIRM) — standby acknowledges on receipt in memory, not on disk
✅ ASYNC + NOAFFIRM — LGWR never waits; throughput wins, a small gap is possible
✅ NET_TIMEOUT decides how long a commit can stall when the network dies
✅ 26ai — ASYNC now uses parallel connections for 2x–9x higher redo transport throughput
✅ Gotcha — Maximum Protection requires AFFIRM; FASTSYNC will not satisfy it

Redo transport is two decisions, not one. SYNC vs ASYNC decides whether LGWR waits for the LNS network send. AFFIRM vs NOAFFIRM decides whether the standby's RFS process must write that redo to disk before it acknowledges.

SYNC AFFIRM is the zero-data-loss pair, and it is what Maximum Protection demands:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stby SYNC AFFIRM NET_TIMEOUT=15 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby';

FASTSYNC is simply SYNC NOAFFIRM — the standby acks once redo is in memory, taking standby disk I/O out of your commit path. One line in the Broker:
DGMGRL> EDIT DATABASE stby SET PROPERTY LogXptMode='FASTSYNC';
It is valid for Maximum Availability only; Maximum Protection rejects it.

Measure before you choose. On the primary, the 'SYNC Remote Write' wait event IS your added commit time. And check what is actually running, not what you think you set:
SELECT DEST_ID, TRANSMIT_MODE, AFFIRM, NET_TIMEOUT, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;

Production gotcha: leaving NET_TIMEOUT at its 180-second default means one dead network path can freeze every commit on the primary for three minutes before the destination is failed. MAA guidance is 10–15 seconds.

Interview Q: "Does FASTSYNC still give zero data loss?" A: It guarantees the redo reached the standby's memory, so a primary-only failure is still zero loss — but it does not protect you if the standby itself crashes before that redo hits disk. That is exactly why Maximum Protection insists on AFFIRM.

📌 Save this post for your next Oracle Data Guard interview or production troubleshooting session.

🌐 Live Oracle DBA (26ai) Training & Consulting
www.dbnexus.co.in
📞 +91 81691 58909
🎓 Recorded Courses: https://www.dbnexus.co.in/recorded-courses.html
▶️ YouTube:

💬 In your production setup, did you move from SYNC to FASTSYNC — and what did it actually do to your commit latency?

DBNexus Training & Consulting

16/10/2026

13/10/2026

12/10/2026

12/10/2026

11/10/2026

11/10/2026

10/10/2026

09/10/2026

08/10/2026

06/10/2026

Address

Website

Alerts

Shortcuts

Share

Category

Listing takedown request