Hello Readers,

Hope you are doing well.

After releasing a few YouTube videos to my channel, I’m back with a new blog post about a recent challenge I encountered while setting up a new Data Guard configuration on Oracle Exadata Cloud Service for a primary database running on DBCS infrastructure.

Although the backup restoration and other Data Guard-specific setup tasks were successfully completed, the redo transport kept failing with the error: “TNS-12650: No common encryption or data integrity algorithm.”

Setup details:

Primary DB ==> Two node RAC DB running on OCI DBCS with version 19.22
Standby DB ==> Two node RAC DB running on OCI ExaCS with version 19.25

From my previous experience with similar issues, I was confident that the problem was related to a DBRU mismatch between the two databases. I began by specifically examining the differences in the SQLNET.ORA files across both environments and discovered significant discrepancies.

The standby site on ExaCS was newly provisioned via the OCI console and came with preconfigured network files, including SQLNET.ORA settings.

Primary site SQLNET.ora

SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA1)
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)
SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS=TRUE
SQLNET.INBOUND_CONNECT_TIMEOUT=180
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/$ORACLE_UNQNAME/tde)))
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8

Standby site SQLNET.ora

HTTPS_SSL_VERSION=1.2
SQLNET.CRYPTO_CHECKSUM_CLIENT=ACCEPTED
SQLNET.CRYPTO_CHECKSUM_SERVER=ACCEPTED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA256,SHA384,SHA512,SHA1)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA384,SHA512)
SQLNET.ENCRYPTION_CLIENT=REQUESTED
SQLNET.ENCRYPTION_SERVER=REQUESTED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
SQLNET.EXPIRE_TIME=10
SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS=TRUE
SQLNET.WALLET_OVERRIDE=FALSE
SSL_CIPHER_SUITES=(SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
SSL_CLIENT_AUTHENTICATION=FALSE
SSL_VERSION=1.2
WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/OACPRODC/wallet_root/tde)))

A few parameters that were definitely worth reviewing included the following:

SQLNET.CRYPTO_CHECKSUM_SERVER ==> to specify the data integrity behavior when a client or another server acting as a client connects to this server.
SQLNET.CRYPTO_CHECKSUM_CLIENT ==> to specify a list of data integrity algorithms that this client or server acting as a client uses.
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER ==> to specify the data integrity algorithms that this server or client to another server uses, in order of intended use.
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT ==> to specify a list of data integrity algorithms that this client or server acting as a client uses.
SQLNET.ENCRYPTION_SERVER ==> specifies the encryption behavior when a client or a server acting as a client connects to this server.
SQLNET.ENCRYPTION_CLIENT ==> to set the encryption behavior when this client or server acting as a client connects to a server.

My first approach was to copy the following parameters from the standby SQLNET.ORA to the primary’s SQLNET.ORA which didn’t help.

SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA256,SHA384,SHA512,SHA1)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA384,SHA512)

Next, I copied the following parameters from the source to the target, referencing guidance from an Oracle Support document. Unfortunately, this didn’t resolve the issue either.

SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED

The only remaining difference was related to the CRYPTO_CHECKSUM_TYPES_SERVER parameter. The original primary site had SHA1 configured for this parameter, but it was removed when I copied the value (SHA256,SHA384,SHA512) from the standby site.

To address this, I updated the parameter on both sites to:

SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA384,SHA512,SHA1)

After updating this setting, I reset the LOG_ARCHIVE_DEST_n location on the primary site to point to the standby site. With this change, the issue was successfully resolved!!!

Final sqlnet.ora had following values on both sites:

SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA256,SHA384,SHA512,SHA1)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA384,SHA512,SHA1)

Let me know for any questions and any further information in comments or LinkedIn.

Regards
Adityanath.