Thursday, February 12, 2026

Sudden ORA-12578: TNS:wallet open failed when logging in as SYS

ORA-12578: TNS:wallet open failed when logging in as SYS

This blog post covers a possible cause of a "ORA-12578: TNS:wallet open failed" error when trying to log into your database using

>sqlplus / as sysdba

I have seen this issue a few times with DB 19.x. I noticed the behavior changed with AI DB 26 and is much less likely to happen.

What causes this ?

The most likely reason why you would suddenly see this error code when trying to log in using "sys as sysdba" is a change to the sqlnet.ora file.

When logging in using "sys as sysdba", the sqlnet.ora file used by your environment will be parsed as part of the authentication process. If the sqlnet.ora in your environment has any issues during the parsing, this will cause your login using "sys as sysdba" to fail with the above error.

Fortunately, this does not happen in AI DB 26.

How to test for the sqlnet.ora being the cause

The easiest way to test is by using the TNS_ADMIN environmental variable setting.

The steps I would follow are.

cd to your $ORACLE_HOME/network/admin directory on the server
Execute mkdir to create a new directory named "test"
cd to that new directory "test"
set TNS_ADMIN with "export TNS_ADMIN=$ORACLE_HOME/network/admin/test"
Try logging in using "/ as sysdba"

Since there is no sqlnet.ora file in this new directory, if you can successfully login we have proven that the issue is the sqlnet.ora file.

Now that we have proven it is the sqlnet.ora (or ruled it out sorry I couldn't help), we can look at the causes.

Finding the issue

Now that you have a new directory, $ORACLE_HOME/network//admin/test, we can start working through the possible causes.

Step 1- copy the sqlnet.ora from the default location to this new directory so that we can update it and find the issue without affecting other users. "cp ../*.ora ."

Below is my sqlnet.ora that I am showing different issues with.

# sqlnet3189722425551944721.ora Network Configuration File: /tmp/sqlnet3189722425551944721.ora
# Generated by Oracle configuration tools.

SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
 (DIRECTORY = /opt/oracle/admin/ORCLCDB/wallet1/server_seps)
 )
)

Cause 1 - Wallet file

The first possible cause is that the location of the wallet location is not correct. The same issue will most likely occur if you are setting the encryption_wallet_location in the sqlnet.ora file.

Both of these must be true when looking at the wallet file.

The directory in the sqlnet.ora file MUST exist. If the directory location is incorrect, you will have an issue opening the wallet
There must be a wallet file in that directory. Not only must the directory exist, but there must also be a wallet file within the directory to read.

Cause 2 - Syntax in sqlnet.ora file

When the database parses the sqlnet.ora file, it can be sensitive to any issues within the sqlnet.ora file. Simple issues can cause parsing failures, and cause your login to fail.

Some of the most common issues are:

Hidden characters in the file. This can happen when copying across platforms (windows to Linux for example). If there are any characters in the file that cause parsing to fail, your login will fail.
Missing "(" or ")". This can cause parsing to fail, and your login will also fail.
Starting "(" in the first column. Unfortunately this causes a parsing failure. This can be the most annoying, and difficult to find cause.

Below is an example of a sqlnet.ora file that fails, and you can compare to my sqlnet.ora at the beginning of this blog.

# sqlnet3189722425551944721.ora Network Configuration File: /tmp/sqlnet3189722425551944721.ora
# Generated by Oracle configuration tools.

SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
(DIRECTORY = /opt/oracle/admin/ORCLCDB/wallet/server_seps)
 )
)

Can you spot the difference ?

...

It's the "(" before the word "DIRECTORY". When it is in the first column, parsing fails.

Prevention-

What I tell customers to avoid any issues like this is the following:

NEVER change the default sqlnet.ora for all databases. This is the copy that is stored in the $ORACLE_HOME/network/admin directory.
ALWAYS set the WALLET_ROOT parameter in the database. This is interpreted first by the database, and replaces the encryptioin_wallet_location in the sqlnet.ora file.
ALWAYS put the SEPS wallet for Real-time redo with the ZDLRA in the {WALLET_ROOT}/server_seps directory. Even if it is a symbolic link.
ALWAYS use TNS_ADMIN when it is necessary to customize the sqlnet.ora. When backing up using the ZDLRA I recommend customers create a customized sqlnet.ora file and use TNS_ADMIN when executing backup/restore scripts.

This will prevent any issues with the shared sqlnet.ora that may cause unexpected issues with logging in as sys.

SUMMARY:

If you suddenly receive a ORA-12578: TNS:wallet open failed when logging in as SYS the first place to look would be your sqlnet.ora file for any parsing errors.

Tuesday, January 20, 2026

Oracle Database Encryption (TDE)

Oracle TDE (Transparent Data Encryption) is a critical piece of data protection, and online encryption is a great tool you can use to simplify the process of encrypting or rekeying your tablespaces. In this post I will go through the process of

Online encrypting an unencrypted tablespace to TDE
Restarting encrypting a tablespace within a database that crashed during the process
Re-encrypted tablespaces with a stronger encryption key (AES128 --> AES256)
What happens to a standby database when I use encryption and when I rekey.

Throughout this blog post I am will be using queries from my previous blog you can find here.

Environment

First my environment.

Primary DB : ORCLCDB - DB 19.28
Standby DB : ORCLSTBY - DB 19.28
Both databases are using OMF to simplify naming files
Encryption - Using Local wallet file

The parameters that affect encryption are using the default values.

Parmeter
Name                           Value                Default?
------------------------------ -------------------- ----------
tablespace_encryption          MANUAL_ENABLE        TRUE
encrypt_new_tablespaces        CLOUD_ONLY           TRUE

Using these parameters, new tablespaces will not be encrypted unless the DDL explicitly mentions encrypting the tablespace.

NOTE: Since I am using 19c, the default encryption Algorithm used will be AES128. Set _tablespace_encryption_default_algorithm to 'AES256' to change the default.

Encrypting my tablespace

Above is the Encryption clause that you can add to "ALTER TABLESPACE" to manage encrypted tablespaces.

For this post, I will concentrate on ONLINE encryption.

New tablespace

I am going to create a new tablespace in my PDB and I want any new tablespaces to be encrypted.

alter system set encrypt_new_tablespaces=always;
Create tablespace encrypt_test;

Running my query against the database, I can see that it created a tablespace and by default that tablespace was created as AES128.

PDB Name   Tablespace Name Enc.  Enc. alg   Master Key ID             Key ID                              tablespace Encryt key (trunc)
---------- --------------- ----- ---------- ------------------------- ----------------------------------- ------------------------------
CDB$ROOT   SYSAUX          NO               AZTq/iBVq0/Kv5Es4oNsgQI=  94EAFE2055AB4FCABF912CE2836C8102    603EC31649CDC3684FE68D3DB376F6
           SYSTEM          NO               AZTq/iBVq0/Kv5Es4oNsgQI=  94EAFE2055AB4FCABF912CE2836C8102    603EC31649CDC3684FE68D3DB376F6
           TEMP            NO               AZTq/iBVq0/Kv5Es4oNsgQI=  94EAFE2055AB4FCABF912CE2836C8102    603EC31649CDC3684FE68D3DB376F6
           UNDOTBS1        NO               AZTq/iBVq0/Kv5Es4oNsgQI=  94EAFE2055AB4FCABF912CE2836C8102    603EC31649CDC3684FE68D3DB376F6
           USERS           NO               AQAAAAAAAAAAAAAAAAAAAAA=  00000000000000000000000000000000    000000000000000000000000000000
           ENCRYPT_TEST    YES   AES128     AZTq/iBVq0/Kv5Es4oNsgQI=  94EAFE2055AB4FCABF912CE2836C8102    5635777F4E7A6ACA229FEA10369967

NOTE: I did not change the parameter in my standby database and the tablespace in my standby is also encrypted. The DDL sent to the standby from the primary ensured that the standby also encrypts the tablespace.

Existing tablespaces

Now I am going to take an existing tablespace and encrypt it online.

Prior to performing this operation (even though it is online), I am going to take a backup of the database.

To make this more realistic I am using a tablespace with 4 datafiles that are all around 10 GB per datafile.

Tablespace Name    FILE_ID File Name                      Size
--------------- ---------- ------------------------------ ----------
ENCTEST                 13 o1_mf_enctest_npz8393s_.dbf     14.454 GB
ENCTEST                 14 o1_mf_enctest_npz8gvz0_.dbf      8.589 GB
ENCTEST                 15 o1_mf_enctest_npz8oy0p_.dbf     10.831 GB
ENCTEST                 16 o1_mf_enctest_npz8yr6p_.dbf     12.793 GB

I am going to encrypt this tablespace on the primary database.

SQL> alter tablespace ENCTEST ENCRYPTION ONLINE ENCRYPT;

My session will not come back until the tablespace is encrypted.

Observations

Alert log and encrypting standby database.

When looking at the alert log for the primary and the standby, I can see the changes occurring.

Primary Database Alert log

ORCLPDB1(3):alter tablespace ENCTEST ENCRYPTION ONLINE ENCRYPT
2026-01-20T10:44:14.923114-07:00
ORCLPDB1(3):About to encrypt tablespace ENCTEST (tsn 3/6)
2026-01-20T10:44:15.020101-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T10:48:44.473301-07:00  --> Start Time for Encryption
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf size 1894528
2026-01-20T10:48:44.564605-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf
2026-01-20T10:48:46.584235-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.377754-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.380150-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.388074-07:00

Standby Database Alert log

ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T10:48:44.976604-07:00 ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf size 1894528
2026-01-20T10:48:44.983884-07:00   --> Start Time for Encryption

ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf
2026-01-20T10:48:46.994337-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:06.371051-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.012125-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.088219-07:00

Notice that the conversion of the first datafile on the first node started at

2026-01-20T10:48:44.473301-07:00

And the standby database started converting the first datafile at

2026-01-20T10:48:44.976604-07:00

The difference is milliseconds due to latency.

Observation #1 - With a standby database, the standby database is also immediately encrypting through REDO, and it is encrypting at the same time as the primary.

This was the most interesting item I found when going through the alert log.

After creating a new encrypted copy of a datafile, the process "Zero'ed out" the old datafile prior to deletion.

This was something I had not thought of before.

When migrating to Encrypted datafiles, this ensures that the original datafile (unencrypted) is overwritten and cannot be "undeleted" and read.

ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:06.371051-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.012125-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.088219-07:00

NOTE: This same process occurs when rekeying also.

26ai New feature : `DB_RECOVERY_AUTO_REKEY`

ON, which is the default for the standby, enables the standby to automatically perform an online tablespace rekey operation as part of the standby media recovery process. Be aware that this setting pauses media recovery. If the tablespace is large, then you could observe extended standby apply lag.

OFF, which is the default for the primary, does not perform a tablespace rekey operation. This setting enables an extended standby database to avoid lag time during an online conversion, and is designed for large Oracle Data Guard tablespace deployments. This enables the standby recovery to only record the tablespace key information but not perform the rekey operation inline. In the V$ENCRYPTED_TABLESPACES dynamic view, after the STATUS column value for the corresponding tablespace becomes REKEYING or ENCRYPTING on the standby database, then you can use a standby SQL session to issue an ALTER TABLESPACE ENCRYPTION ONLINE FINISH REKEY|ENCRYPT command to perform the rekey in parallel of media recovery.

Observation #2 - When encrypting/rekeying a tablespaces, the original datafiles are overwritten with zeros to ensure they no longer contain any usable data.

Backing up newly encrypted database

I am now going to perform a new Level 1 backup of the database, and look to see what is being backed up. Below is the output from Block changed tracking showing the blocks being backed up.

    FILE# INCREMENTAL_LEVEL COMPLETION_TIME       BLOCKS DATAFILE_BLOCKS PCT_CHANGED
---------- ----------------- ----------------- ---------- --------------- -----------

Level 0 backup of datafiles
        13                 1 01-20-26 10:30:00    1793783         1894528       94.68
        14                 1 01-20-26 10:27:31    1081471         1125744       96.07
        15                 1 01-20-26 10:28:43    1368079         1419632       96.37
        16                 1 01-20-26 10:29:32    1573511         1676800       93.84

Level 1 backup of datafiles prior to encryption
        13                 1 01-20-26 10:30:15          1         1894528           0
        14                 1 01-20-26 10:30:15          1         1125744           0
        15                 1 01-20-26 10:30:15          1         1419632           0
        16                 1 01-20-26 10:30:15          1         1676800           0

Level 1 backup of datafiles post encryption
        13                 1 01-20-26 11:12:14          1         1894528           0
        14                 1 01-20-26 11:12:16          1         1125744           0
        15                 1 01-20-26 11:12:15          1         1419632           0
        16                 1 01-20-26 11:12:14          1         1676800           0

What you can see is that as far as RMAN is concerned, since this database is idle, only the header block changed. RMAN did not backup the datafile blocks even though every block changed through the encryption process. Only the user contents of the blocks changed not the metadata about the block.

This is a critical observation.

If you perform a weekly full/daily incremental backup, you will need a new Level 0 backup to ensure the datafiles are encrypted in your backup.
If you utilize the 9i "incremental merge" process, your backup will not be encrypted. If you perform a "switch to copy", your datafiles will not be encrypted. After encrypting, you must restart this strategy with a new full backup.

NOTE: One of the features of the ZDLRA is that it is "encryption aware", and you will not need to perform a new Level 0 backup to ensure you restore encrypted datafiles.

Observation #3 - The database does not recognize the blocks as changed. The block header information, containing SCN information, and other metadata remains untouched.

Datafile/Tablespace information

Original Datafiles

Tablespace Name    FILE_ID File Name                      Size
--------------- ---------- ------------------------------ ----------
ENCTEST                 13 o1_mf_enctest_npz8393s_.dbf     14.454 GB
ENCTEST                 14 o1_mf_enctest_npz8gvz0_.dbf      8.589 GB
ENCTEST                 15 o1_mf_enctest_npz8oy0p_.dbf     10.831 GB
ENCTEST                 16 o1_mf_enctest_npz8yr6p_.dbf     12.793 GB

New Datafiles

Tablespace Name     FILE_ID File Name                      Size
--------------- ---------- ------------------------------ ----------
ENCTEST                 13 o1_mf_enctest_npzhqh0w_.dbf     14.454 GB
ENCTEST                 14 o1_mf_enctest_npzj2gdb_.dbf      8.589 GB
ENCTEST                 15 o1_mf_enctest_npzj9f4k_.dbf     10.831 GB
ENCTEST                 16 o1_mf_enctest_npzjl4dz_.dbf     12.793 GB

Tablespace encryption Status

PDB Name   Tablespace Name Enc.  Enc. alg   Master Key ID             Key ID                              tablespace Encryt key (trunc)
---------- --------------- ----- ---------- ------------------------- ----------------------------------- ------------------------------
ORCLPDB1   SYSAUX          NO               AawCP+ykIE/2v9kPpgqvHOk=  AC023FECA4204FF6BFD90FA60AAF1CE9    0C836501DE2C28286F4DFF45EDB563
           SYSTEM          NO               AawCP+ykIE/2v9kPpgqvHOk=  AC023FECA4204FF6BFD90FA60AAF1CE9    0C836501DE2C28286F4DFF45EDB563
           TEMP            NO               AawCP+ykIE/2v9kPpgqvHOk=  AC023FECA4204FF6BFD90FA60AAF1CE9    0C836501DE2C28286F4DFF45EDB563
           UNDOTBS1        NO               AawCP+ykIE/2v9kPpgqvHOk=  AC023FECA4204FF6BFD90FA60AAF1CE9    0C836501DE2C28286F4DFF45EDB563
           USERS           NO               AQAAAAAAAAAAAAAAAAAAAAA=  00000000000000000000000000000000    000000000000000000000000000000
           ENCTEST         YES   AES128     AawCP+ykIE/2v9kPpgqvHOk=  AC023FECA4204FF6BFD90FA60AAF1CE9    604F0A3F91F73875D0BC9325FA87C3

Above, you can see that a newly encrypted datafile copy was created for each datafile member of the tablespace. The size, is exactly the same as the original datafile. You can also see that since I didn't specify a specific algorithm, the tablespace was encrypted as AES128 (the default).

Observation #4 - A new datafile copy is created for each member. You need to make sure that there is enough space for a second copy of largest datafile.

Re-encrypted tablespaces from AES128 to AES256

The next process I am going to go through is common as customers rekey existing tablespaces from AES128 to utilize the AES256 encryption algorithm.

In this example, I am not only going to re-encrypt the tablespaces, I am also going to crash the database in the middle of this process to see how to handle this possibility.

SQL> alter tablespace ENCTEST ENCRYPTION ONLINE USING 'AES256' rekey;

For this example, I monitored the alert log and watched it encrypt the datafiles, as soon as it finished encrypting the first datafile (File# 14), I performed a "Shutdown Abort" on the database.

Primary Alert log

ORCLPDB1(3):About to rekey tablespace ENCTEST (tsn 3/6)
2026-01-20T11:46:45.353069-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf (13) to /home/db19c/oradata/                      ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:51:50.367605-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdoc8_.dbf size 1894528
2026-01-20T11:51:50.415541-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdoc8_.dbf
2026-01-20T11:51:52.481666-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf"
2026-01-20T11:52:25.125992-07:00
Shutting down ORACLE instance (abort) (OS id: 827465)
2026-01-20T11:52:25.158712-07:00
Shutdown is initiated by sqlplus@bgrenn-19-28 (TNS V1-V3).
License high water mark = 12
USER (ospid: 827465): terminating the instance
2026-01-20T11:52:26.213187-07:00
Instance terminated by USER, pid = 827465
2026-01-20T11:52:27.343819-07:00

Standby Alert log

ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:51:51.143252-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdphy_.dbf size 1894528
2026-01-20T11:51:51.150126-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdphy_.dbf
2026-01-20T11:51:53.202013-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T18:52:25.254096+00:00
 rfs (PID:823518): Possible network disconnect with primary database
2026-01-20T18:52:25.258563+00:00
 rfs (PID:823518): while processing B-1209738101.T-1.S-412 BNUM:110516 BCNT:1
2026-01-20T18:52:25.259701+00:00
 rfs (PID:823516): Possible network disconnect with primary database
 rfs (PID:823518): Current process action IDLE, elapsed idle time 0
2026-01-20T18:52:25.266055+00:00
 rfs (PID:823516): while processing B-1209738101.T-1.S-412 BNUM:0 BCNT:0
2026-01-20T18:52:25.267216+00:00
 rfs (PID:823518): RFS client ASYNC ORL SINGLE (PID:823296)
2026-01-20T18:52:25.268790+00:00
 rfs (PID:823516): Current process action IDLE, elapsed idle time 32
 rfs (PID:823516): RFS client GAP MANAGER (PID:822694)
2026-01-20T11:53:04.841560-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T11:53:06.478227-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T11:53:06.486711-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf (14) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:54:47.101862-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmrlhf_.dbf size 1125744
2026-01-20T11:54:47.108829-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmrlhf_.dbf
2026-01-20T11:54:49.120370-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:28.313091-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:37.980759-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:37.989404-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj9kff_.dbf (15) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf

What is most interesting in the alert logs, is that the standby continued to rekey the datafiles for the tablespace. This occurred independently of the primary.

Observation #5 - The primary sends the ALTER DATABASE REKEY command in the redo, and the standby database performs the process independently. even once the primary crashed.

Startup Database after crash

After starting up the primary database I took a look at the encryption status of the tablespace in both the primary and standby.. In the primary it shows as "REKEYING", the standby successfully finished the operation and shows as normal AES256 encrypted

select ts#,
       ENCRYPTIONALG,
       ENCRYPTEDTS,
       status,
       con_id
from v$encrypted_tablespaces;

Primary Database (aborted)

      TS# ENCRYPT ENC STATUS         CON_ID
---------- ------- --- ---------- ----------
         6 AES256  YES REKEYING            3

Standby Database (continued operation)

      TS# ENCRYPT ENC STATUS         CON_ID
---------- ------- --- ---------- ----------
         6 AES256  YES NORMAL              3

Now I am going to look at the datafiles

-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 11:52 o1_mf_enctest_npzhqh0w_.dbf
-rw-r-----+ 1 oracle oracle  9222103040 Jan 20 12:10 o1_mf_enctest_npzj2gdb_.dbf
-rw-r-----+ 1 oracle oracle 11629633536 Jan 20 12:10 o1_mf_enctest_npzj9f4k_.dbf
-rw-r-----+ 1 oracle oracle 13736353792 Jan 20 12:10 o1_mf_enctest_npzjl4dz_.dbf
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 12:10 o1_mf_enctest_npzmdoc8_.dbf

Since I aborted the database, while it was "zeroing out the datafile" there are two copies of the datafile.

At this point since it started the rekey operation, my only choice is to "FINISH" the operation. This is a manual step to restart the process.

alter tablespace ENCTEST ENCRYPTION FINISH rekey;

Observation #6 - Once you start an encryption operation, it must finish. There is no backing out.

Once the rekey operation finished, I again looked at the datafiles. I can see that the original datafile that was in process when I aborted the database is still there. If an online encryption operation is in process during a crash, you might have an orphan file from the process that has to be manually deleted.

-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 11:52 o1_mf_enctest_npzhqh0w_.dbf
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 12:10 o1_mf_enctest_npzmdoc8_.dbf
-rw-r-----+ 1 oracle oracle  9222103040 Jan 20 12:27 o1_mf_enctest_npzopwfg_.dbf
-rw-r-----+ 1 oracle oracle 11629633536 Jan 20 12:30 o1_mf_enctest_npzovdhd_.dbf
-rw-r-----+ 1 oracle oracle 13736353792 Jan 20 12:34 o1_mf_enctest_npzp0zd5_.dbf

Observation #7 - After a crash, there may be cleanup necessary.

rm o1_mf_enctest_npzhqh0w_.dbf

Observation Summary:

Observation #1 - With a standby database, the standby database is also converted through REDO, and it is converted at the same time as the primary.

Observation #2 - When encrypting/rekeying a tablespaces, the original datafiles are overwritten with zeros to ensure they no longer contain any usable data.

Observation #3 - The database does not recognize the blocks as changed. The block headers information, containing SCN information, and other metadata remains untouched.

Observation #4 - A new datafile copy is created for each member. You need to make sure that there is enough space for a second copy of largest datafile.

Observation #5 - The primary sends the ALTER DATABASE REKY command in the redo, and the standby database performs the process independently.

Observation #6 - Once you start an encryption operation, it must finish. There is no backing out.

Observation #7 - After a crash, there may be cleanup necessary.

Tuesday, October 28, 2025

Configuring Cloud Protect

Cloud Protect is a new offering announced at AI World 2025. Cloud Protect allows you to leverage the Oracle Database Zero Data Loss Autonomous Recovery Service for your on-premises Linux x64 databases. Cloud Protect even allows you to enable real-time redo.

You can find a great blog post by Kelly Smith announcing it here, and you can find the detailed documentation here.

I've been testing it out for the past week and I wanted to share everything I learned about using it.

First, there are a few things to understands about Cloud Protect Version 1.

You can only restore the database back to the original host/cluster you configured backups from. All nodes in a RAC cluster can be used for restoration.
Cloud Protect can only be used from non-ExaCC on-premises databases.
You cannot use a dual point-in-time backup strategy. Cloud Protect must be your primary backup location.

Bryan's Oracle Blog

Thursday, February 12, 2026

Sudden ORA-12578: TNS:wallet open failed when logging in as SYS

ORA-12578: TNS:wallet open failed when logging in as SYS

What causes this ?

How to test for the sqlnet.ora being the cause

Finding the issue

Cause 1 - Wallet file

Cause 2 - Syntax in sqlnet.ora file

Prevention-

SUMMARY:

Tuesday, January 20, 2026

Oracle Database Encryption (TDE)

Throughout this blog post I am will be using queries from my previous blog you can find here.

Environment

Encrypting my tablespace

New tablespace

Existing tablespaces

Observations

Alert log and encrypting standby database.

Observation #1 - With a standby database, the standby database is also immediately encrypting through REDO, and it is encrypting at the same time as the primary.

26ai New feature : `DB_RECOVERY_AUTO_REKEY`

Observation #2 - When encrypting/rekeying a tablespaces, the original datafiles are overwritten with zeros to ensure they no longer contain any usable data.

Backing up newly encrypted database

Observation #3 - The database does not recognize the blocks as changed. The block header information, containing SCN information, and other metadata remains untouched.

Datafile/Tablespace information

Re-encrypted tablespaces from AES128 to AES256

Startup Database after crash

Observation #6 - Once you start an encryption operation, it must finish. There is no backing out.

Observation #7 - After a crash, there may be cleanup necessary.

Observation Summary:

Observation #1 - With a standby database, the standby database is also converted through REDO, and it is converted at the same time as the primary.

Observation #3 - The database does not recognize the blocks as changed. The block headers information, containing SCN information, and other metadata remains untouched.

Observation #4 - A new datafile copy is created for each member. You need to make sure that there is enough space for a second copy of largest datafile.

Tuesday, October 28, 2025

Configuring Cloud Protect

Blog Archive

Labels

About Me

Blog Archive

Thursday, February 12, 2026

Sudden ORA-12578: TNS:wallet open failed when logging in as SYS

ORA-12578: TNS:wallet open failed when logging in as SYS

What causes this ?

How to test for the sqlnet.ora being the cause

Finding the issue

Cause 1 - Wallet file

Cause 2 - Syntax in sqlnet.ora file

Prevention-

SUMMARY:

Tuesday, January 20, 2026

Oracle Database Encryption (TDE)

Throughout this blog post I am will be using queries from my previous blog you can find here.

Environment

Encrypting my tablespace

New tablespace

Existing tablespaces

Observations

Alert log and encrypting standby database.

Observation #1 - With a standby database, the standby database is also immediately encrypting through REDO, and it is encrypting at the same time as the primary.

26ai New feature : DB_RECOVERY_AUTO_REKEY

Observation #2 - When encrypting/rekeying a tablespaces, the original datafiles are overwritten with zeros to ensure they no longer contain any usable data.

Backing up newly encrypted database

Observation #3 - The database does not recognize the blocks as changed. The block header information, containing SCN information, and other metadata remains untouched.

Datafile/Tablespace information

Re-encrypted tablespaces from AES128 to AES256

Startup Database after crash

Observation #6 - Once you start an encryption operation, it must finish. There is no backing out.

Observation #7 - After a crash, there may be cleanup necessary.

Observation Summary:

Observation #1 - With a standby database, the standby database is also converted through REDO, and it is converted at the same time as the primary.

Observation #3 - The database does not recognize the blocks as changed. The block headers information, containing SCN information, and other metadata remains untouched.

Observation #4 - A new datafile copy is created for each member. You need to make sure that there is enough space for a second copy of largest datafile.

Tuesday, October 28, 2025

Configuring Cloud Protect

About Me

Blog Archive

26ai New feature : `DB_RECOVERY_AUTO_REKEY`