Oracle Apps DBA

By Gowthami | apps-dba.com | Oracle Administration Series A common issue after Oracle Database 19c patching is a Pluggable Database (PDB) opening in RESTRICTED mode due to a datapatch failure. This occurs when datapatch — the tool that applies SQL-based patch changes — fails or is not run after the binary patch is applied. This post explains root causes and step-by-step resolution. Key Insight: After applying Oracle patches (OPatch), you MUST run datapatch to apply the SQL-based portions of the patch to each database. If datapatch fails mid-way, PDBs may open in RESTRICTED mode until the SQL patches are successfully applied. Symptoms -- PDB shows RESTRICTED in open mode SELECT con_id, name, open_mode, restricted FROM v$pdbs; -- Output: -- CON_ID NAME OPEN_MODE RESTRICTED -- 3 PROD READ WRITE YES <-- Problem! -- Alert log shows: -- "PDB PROD is restricted because datapatch has not been run" -- or errors in /oracle/diag/rdbms/db/trace/ datapatch...

Oracle Exadata Cell Disks Explained - From Physical Media to ASM Capacity Oracle Exadata Series Oracle Exadata Cell Disks Explained How physical media becomes CellCLI-managed capacity, then turns into grid disks and ASM space that databases can actually use. Cell disks sit in the middle of the Exadata storage model. They are not the raw drives you pull from the chassis, and they are not the ASM disks your database team sees in SQL. A useful mental model is: physical disk or LUN first, cell disk second, grid disk third, ASM disk and disk group last. Once that layering is clear, Exadata storage tasks become much easier to reason about, especially when you are validating capacity, mapping failures, or planning changes. 4 layers Physical to ASM path 1 object Cell disk per LUN 2 views CellCLI and ASM perspective 3 checks Status, freespace, mapping Article Map The mental model Where cell dis...

Oracle Exadata Storage HA Explained - Failure Domains, Mirroring, and Safe Maintenance Oracle Exadata Series Oracle Exadata Storage HA Explained Failure groups, mirroring, resync, rebalance, and the checks that tell you whether a cell outage is actually safe. Exadata storage high availability is not one feature. It is the combined result of ASM mirroring across cell-based failure groups, Exadata-specific maintenance workflows, short-interruption resync behavior, and enough free mirrored space to keep the system protected when something goes wrong. Once those pieces are separated, storage events become much easier to reason about without overpromising what the platform can tolerate. Cell = failure group Core Exadata HA idea Resync or rebalance Depends on outage type RMF matters Mirror headroom is not optional Plan before shutdown Use deactivation checks first Article Map Failure domains...