How to Rotate and Rekey TDE on Oracle ExaCS with dbaascli

Introduction

We’re living in an AI-driven world. Almost overnight, AI has spread into every industry – and I mean every one. In my view, it hasn’t replaced workers so much as elevated them: with the right data in front of you, you make better decisions, faster.

Oracle has been making serious strides here. But the part people tend to skip over is that none of this works without stable infrastructure underneath it. That’s where Exadata comes in, and it’s why OCI has gained real ground. The platform scales and delivers the performance an AI-driven workload actually demands.

Security is just as critical. Oracle includes Transparent Data Encryption (TDE) at no extra cost, which is what pulled me into the topic of data-at-rest protection in the first place. But encryption alone isn’t the finish line. If a key is ever exposed, your protection is effectively gone. Rotating the TDE master key (the rekey operation) sits squarely in the DBA’s hands, and it’s a responsibility worth taking seriously.

Now, a word of warning before we go further. ExaCS is a different beast. Oracle built a layer of orchestration tooling to take most of the administration burden off your plate, and on both ExaCS and ExaCC that means one thing: you need to master dbaascli. It’s the entry point for nearly everything you’ll do, and TDE key management is no exception.

Rotating and Rekeying TDE on ExaCS

In this blog, I’ll walk you through how to rotate and rekey TDE on ExaCS.

Start by Checking the Password

I always check the wallet password before I do anything else. It takes five seconds, and it saves you from finding out mid-operation that the password on your runbook is stale.

If it accepts the password, carry on; if it doesn’t, stop and sort that out first. Nothing below works without it.

Check the Current TDE Status

Now let’s see how TDE is set up on the database before we change anything.

Three things to look at here. The keystore type is autologin, so the wallet opens by itself when the database starts, and you don’t have to babysit it. The status is open, so it’s usable right now. And the last line says the master keys compared successfully, which means the wallet is consistent. If you don’t see that line, don’t go any further until you know why.

You’ll also spot the deprecation warning. The command still works in 25.2.1.0.0, but Oracle wants you on dbaascli database getDetails now. Might as well start using it before the old one goes away.

Logs for this command live here:

Save the session log path from the output. If something goes wrong later, that’s the first file you’ll open.

Run the Prechecks First

Don’t point the rekey at a cold database. Run it with --executePrereqs first. It walks the same pipeline the real command uses but doesn’t touch a single key, so if there’s a problem you find out on your own terms.

The --rotateMasterKeyOnAllPDBs true flag pulls every PDB into the operation, not just the CDB. In a multitenant environment, that’s almost always what you want. Rotate the CDB alone, and your PDB keys are still sitting there untouched.

What You’re Looking At

People see three jobs marked “Skipping” and assume something broke. Nothing broke.

The two jobs that matter are Plugin_initialization and Perform_dbca_prechecks, and both say ‘Completed’. That’s your green light.

The skipped ones are skipped for good reasons. Standby_blob_extraction and Generate_blob_file only do anything when there’s a Data Guard standby involved, and there isn’t one here. Rotate_tde_master_key is the actual rotation, and it’s skipped because you asked for prechecks only. That’s the flag doing exactly what you told it to do.

Run the Rotation

Prereqs passed, so now we do it for real. Same command, same flags – just drop --executePrereqs. That single omission is the difference between a dry run and a live key rotation, so read your command line twice before you hit Enter.

Put the Two Outputs Side by Side, and There’s Exactly One Difference That Matters:

That’s the rekey. New master key generated and activated across the CDB and every PDB.

Everything else looks the same. The prechecks run again rather than trusting the earlier pass, which is the behavior you want. The standby jobs skip again for the same reason.

Validate the Rekey

dbaascli saying “Completed” is good, but it isn’t evidence. Go into the database and look at the keys yourself. V$ENCRYPTION_KEYS shows you every master key in the wallet with the date each one was created.

You’re looking for a new row with a creation time that matches when you ran the rekey. In my case, that was a fresh entry dated 17 October sitting next to the previous key. Two rows, not one, which is the same point I made above about old keys being kept rather than replaced.

Changing the Keystore Password

The master key is one control. The password protecting the keystore is a different one, and both should be on your yearly list. If the wallet password leaks, a new master key doesn’t save you.

The command is dbaascli tde changePassword. Same as before, run the prechecks first.

I’m Leaving the Failure in

I could have shown you a clean run, but this is the most common way this command bites people, and it makes the case for --executePrereqs better than anything I could write.

DBAAS-60197 means my new password had a character dbaascli won’t take. The rules are narrow. Six to thirty characters, letters and numbers, and only these specials:

This is the clean run of the proper password.

Run it For Real

Prechecks are clean, so run the same command without --executePrereqs.

Same prompting as before, same double password entry. The difference is that this time the new password actually gets written to the wallet.

Then go straight back and check it:

Same command I opened this post with. Use the new password. If it lists the wallet contents, you’re done, and the change stuck. Do this immediately, while you still have the terminal open and the password fresh in your head. Finding out three weeks later that the change didn’t take is a bad afternoon.

Change the SYS Password Too

While you’re in there, change the SYS password as well. My view is these two belong together in the same maintenance window. You’re already down in the credentials; you’ve already got the change approved, and doing them separately means doing the paperwork twice.

Run the prechecks first, same as everything else:

Then run it again without the flag once it passes.

And here’s the part I want to be direct about: do this through dbaascli, not with ALTER USER. It’s tempting to think a SYS password change is simple enough to do in SQL*Plus. On ExaCS it isn’t. The orchestration layer keeps its own record of these credentials, and if you change the password underneath it in SQL, the tooling still thinks the old one is current. Everything looks fine until the next automated operation goes to authenticate and fails, and by then you’ve forgotten you did it.

Wrapping Up

None of this is difficult. That’s really the point. Between dbaascli tde rotateMasterKey, dbaascli tde changePassword and dbaascli database changePassword, you can rotate your master key, your wallet password and your SYS password in a single maintenance window – online, no outage, and with a session log for every step when the auditor comes asking.

The hard part isn’t the commands. It’s remembering to run them. TDE gets set up once on day one, works quietly forever, and quietly stops being a control the moment a key or password goes stale. Encryption you never rotate is encryption you’re trusting on faith.

So put it in the calendar. Once a year, minimum. Run your prechecks, keep the logs, and validate afterwards rather than assuming it worked.

For more information, check out our Oracle Cloud Infrastructure Services, or contact us today, and one of our experts will be in touch.