Automation in the Oracle ecosystem is a double-edged sword. When systems like Autonomous Recovery Service (ARS) work, they are absolute lifesavers - offloading heavy background lifting, ensuring zero-data-loss protection, and preventing manual human error.
However, when an automated mechanism hits a database restore failure issue, an unhandled corner case, or a misconfigured VCN/policy, it can quietly stall, block recovery pipelines, or trigger subtle background wait event spikes.
Issue 1:
During a database restore from backup, the creation process failed with: the password of TDE wallet cannot be null . The root cause turned out to be a UI/orchestration gap: the console failed to prompt for the TDE wallet password during setup, causing the automated restore job to immediately fail when attempting to open the wallet.
The Root Cause: A Identity Crisis Between Oracle Wallet and AWS KMS
So, what actually went wrong behind the scenes?
As part of an infrastructure modernization effort, we had recently migrated our TDE (Transparent Data Encryption) setup from traditional Oracle Wallets (file-based software key stores) to AWS Customer Managed Keys (CMK) via AWS KMS.
This created a unique hybrid backup history:
Older backups in our chain were encrypted using the legacy Oracle Software Wallet.
Newer backups were encrypted using AWS KMS.
When we triggered the "Create Database from Backup" workflow, the automated provisioning framework ran into a classic edge case. The orchestration engine saw the backup chain, got confused by the transition between two completely different key management mechanisms, and defaulted to looking for a standard Oracle Wallet password.
Because the console interface was designed around AWS KMS integration for current backups, it never prompted for a wallet password. The backend automation expected a password for the older wallet files that the frontend gave us no way to enter—resulting in the dreaded the password of TDE wallet cannot be null error.
The Resolution (And Where Things Stand Today)
Once we isolated the root cause - a mismatch in the control plane automation when handling mixed TDE key stores - it was clear that no amount of parameter tweaking on our side could bypass the missing UI prompt.
Our Immediate Next Steps:
Raised a Severity-1 Service Request (SR) with Oracle Support, detailing the control plane failure during the "Create Database from Backup" workflow.
Worked closely with the Oracle Cloud / Autonomous / AWS Engineering team to replicate the bug.
The Current Status: Oracle Development has officially confirmed this as a control plane orchestration bug. They are currently developing and testing a fix to dynamically expose the TDE Wallet Password field in the console whenever an older backup in the chain requires file-based wallet decryption.
While we await the official patch release from Oracle, this serves as a crucial heads-up for anyone migrating TDE key managers: always test your restore workflows immediately after switching key management providers!
Issue 2: Direct Restore Workflow
Navigation Path:
Database Details Page ➔ More Actions ➔ Restore
⚠️ CRITICAL WARNING for DBAs & Admins
If you are just exploring or testing restore options in the console, do NOT click the "Restore" button on this screen!
Unlike most cloud workflows that present a confirmation prompt or a review screen, clicking Restore immediately kicks off an in-place database restore.
Once triggered:
There is no confirmation modal or secondary prompt asking "Are you sure?"
You lose control immediately—the process cannot be paused or aborted from the console.
Your only option is to sit tight and wait for the restore job to finish.
The silver lining? The in-place restore does complete successfully, and your database will be back up and running smoothly (with downtime depending on your database size). But if you weren't intending to initiate a live recovery, it will definitely give you a momentary heart attack!
Comments
Post a Comment