I remember the first time I had to encrypt a tablespace that was already years old, already in production, already full of live data — back before 12c Release 2 changed the rules. The answer at the time was basically “recreate it,” which in practice meant a new tablespace, a move job, a maintenance window, and a lot of coordinating with the app team to make sure nothing broke mid-copy. It worked, but it was the kind of task you scheduled weeks out and hoped nothing else went wrong that weekend.
12c Release 2 fixed a good chunk of what made that process painful. A dedicated SYSKM privilege, the ability to encrypt tablespaces that already exist — online, even, without taking anything offline — automatic encryption for cloud databases, a new initialization parameter to control default behavior, and tighter integration with Oracle Key Vault. None of this is flashy, but if you’ve lived through the “before” version, you’ll appreciate exactly why each of these mattered.
Why SYSKM Had to Exist
Before 12c, if you wanted to manage TDE — open a wallet, rotate a key, whatever — you generally needed SYSDBA. Which meant handing out full administrative control over the entire database just so someone could manage encryption keys. That always bothered me. It’s a classic case of granting way more access than the task actually requires, and auditors notice that kind of thing immediately.
Oracle’s fix was SYSKM — System Key Management, a privilege scoped specifically to encryption work.
What SYSKM Actually Lets You Do
Connect as SYSKM and you can open and close wallets, create keystores, manage TDE master keys, rotate keys, and handle general wallet administration — all without the blast radius that comes with SYSDBA. It’s least privilege done properly: the person managing encryption gets exactly what they need for that job, nothing more.
SYSKM Next to SYSDBA
| SYSDBA | SYSKM |
|---|---|
| Full database administration | Encryption management only |
| Can perform any administrative operation | Limited to key management |
| Higher security risk | Reduced security exposure |
| Intended for DBAs | Intended for encryption administrators |
Oracle also keeps SYSKM credentials in the password file, so remote authentication for key management tasks works securely without needing a broader account.
Encrypting Tablespaces That Already Exist
11g gave us tablespace encryption, but only for tablespaces created fresh — anything already in production was stuck. 12c Release 2 finally removed that restriction, and you’ve now got two paths to get there.
Doing It Offline
This is the more old-school approach: take the tablespace offline, encrypt the datafiles, bring it back online. Straightforward, and it doesn’t need any extra disk space since you’re encrypting the files in place.
The catch is right there in the name — the tablespace is unavailable the whole time, which means real downtime for anything depending on it. And you can’t change the encryption algorithm mid-operation, so pick it correctly going in.
Doing It Online
Online encryption is the one I actually reach for whenever I have the choice. Oracle builds encrypted copies of the datafiles behind the scenes and updates the control file to point at the new files once it’s done — the database stays up and available the entire time.
Downtime is minimal, which makes this the obvious choice for production. The trade-off is disk space — you need enough headroom to hold both the old and new copies of the datafiles during the conversion, and depending on how big the tablespace is, that number can get uncomfortably large if nobody checks beforehand. Ask me how I know.
The Two Approaches, Side by Side
| Feature | Offline Encryption | Online Encryption |
|---|---|---|
| Database Availability | No | Yes |
| Additional Disk Space | No | Yes |
| Production Friendly | Limited | Recommended |
| Encrypt Existing Tablespaces | Yes | Yes |
| Rekey Existing Tablespace | No | Yes |
| Decrypt Existing Tablespace | No | Yes |
Rekeying and Decrypting Without the Drama
Along with initial encryption, 12c Release 2 also lets you rekey or fully decrypt an already-encrypted tablespace, and both happen online — no need to take anything down. If the volume of data is large, you can also run these operations across multiple parallel SQL sessions to speed things up, which is worth doing on anything sizeable rather than waiting on a single-threaded run.
What About SYSTEM, SYSAUX, and UNDO?
SYSTEM and SYSAUX can both be encrypted. UNDO technically can be too, but Oracle actually recommends against it — undo generated against already-encrypted tablespaces is protected automatically anyway, so encrypting UNDO on top of that is mostly redundant effort.
One operational note: encrypting SYSTEM-related tablespaces requires the database to be in MOUNT state, so this isn’t something you slot into a live production window without planning around it.
Temp Tablespaces Play by Different Rules
You can’t take an existing temporary tablespace and convert it to encrypted — that path simply isn’t available. What you can do is create a new encrypted temp tablespace and switch over to it. Small distinction, but it trips people up if they go in assuming temp behaves the same as everything else.
Don’t Forget the Standby
If you’re running Data Guard, any encryption change on the primary needs to be mirrored on the standby — Oracle doesn’t do this for you automatically. To its credit, Oracle does drop a reminder into the alert log to nudge you, but I wouldn’t rely on catching that in the moment. Build it into your change process instead: encryption change on primary, matching change on standby, every time, no exceptions.
Algorithms in Play
| Encryption Type | Default Algorithm |
|---|---|
| Tablespace Encryption | AES128 |
| Column Encryption | AES192 |
Both defaults are fine, but you’re free to specify AES256 wherever your security policy calls for it — I generally do, for anything I’d consider genuinely sensitive.
Cloud Databases Don’t Give You a Choice
On-prem, encryption is your call. In Oracle Cloud, it isn’t — cloud databases enforce tablespace-level encryption by default, full stop. Every new tablespace comes encrypted whether you asked for it or not, which honestly makes compliance conversations a lot easier once you’re in that environment.
ENCRYPT_NEW_TABLESPACES — Controlling the Default
This parameter, new in 12c R2, decides what happens automatically when a new tablespace gets created. Three settings:
CLOUD_ONLY — new tablespaces in Oracle Cloud get encrypted automatically; on-prem, you still need to add the ENCRYPTION clause yourself in the CREATE TABLESPACE statement for anything to happen.
ALWAYS — every new tablespace gets encrypted, cloud or on-prem, no exceptions. If your organization has a strict “everything gets encrypted” policy, this is the setting that actually enforces it instead of relying on everyone remembering to type the clause.
DDL — nothing happens automatically; encryption only occurs when explicitly specified, like:
CREATE TABLESPACE secure_ts
DATAFILE '/u01/oradata/secure01.dbf'
SIZE 1G
ENCRYPTION USING 'AES256'
DEFAULT STORAGE (ENCRYPT);Which setting is “right” really depends on how much you trust your own team’s habits. I’ve moved more than one organization from DDL to ALWAYS after finding a tablespace or two that should have been encrypted and simply wasn’t, because someone forgot the clause on a Friday afternoon.
Oracle Key Vault Ties It Together
TDE handles the encryption. Key Vault handles the keys at scale — instead of every database server holding its own wallet independently, everything centralizes into one repository covering TDE master keys, wallets, Java keystores, credential files, certificates, and SSH keys.
It’s not limited to Oracle Database either — Key Vault can manage keys for other Oracle products and even MySQL, which matters if your environment isn’t purely Oracle top to bottom (and whose is, these days).
Best Practices Worth Carrying Forward
- Use SYSKM for encryption administration — stop handing out SYSDBA for this
- Default to online encryption in production wherever it’s an option
- Schedule offline encryption for a real maintenance window, not a “quick change” on a Tuesday
- Set
ENCRYPT_NEW_TABLESPACES=ALWAYSif your policy actually requires encryption by default - Centralize key management through Oracle Key Vault once you’re past a database or two
- Rotate TDE master keys on a real schedule
- Keep standby databases in sync with every encryption change on the primary
- Fold wallet and encryption status checks into routine health checks, not just incident response
Wrapping Up
The gap between “Oracle supports TDE” and “TDE is actually manageable at scale” is exactly what 12c Release 2 closed. SYSKM gets encryption administration out from under SYSDBA. Online encryption means existing tablespaces don’t require a maintenance window and a prayer. Cloud enforcement and ENCRYPT_NEW_TABLESPACES take the guesswork out of whether new tablespaces are protected. And Key Vault turns key management from “however each server happens to handle it” into something actually governed. None of it is glamorous work, but it’s the difference between encryption being a checkbox and encryption actually holding up under an audit.
