Getting ANS1463E (RC5801) Unexpected error in cryptography library on RMAN CROSSCHECK

jcosu86

ADSM.ORG Member
Joined
Jul 16, 2015
Messages
42
Reaction score
0
Points
0
Hello all. We are running TDP for Oracle 7.1 in an AIX 7 environment. Our Oracle version is 12.2. Recently we are getting an "ANS1463E (RC5801) Unexpected error in cryptography library" error on our CROSSCHECK part of the nightly backup. This is happening on 3 of our 6 servers (all the same configuration). Every server has at least 2 databases running on it (same version, same Oracle home) 1 consistently gets the error, the other does not. They all use the same TDP configuration. Has anyone seen this error before? If so, did you fix it?
 
The complete error returned is:

PSDRPC returns significant error 1013.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of delete command on ORA_SBT_TAPE_1 channel at 11/19/2018 09:40:28
ORA-27191: sbtinfo2 returned error
Additional information: 3651
ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
ANS1463E (RC5801) Unexpected error in cryptography library.
 
Are there any error message in the dsierror.log ?

It should be in /usr/tivoli/tsm/client/oracle/bin64 .
If its not there, look in the dsm.sys for the option ERRORLOGNAME and see where its pointing to and the name of the file. FYI: The TDP use the the TSM API to communicate with the TSM Server.

Good Luck,
Sias
 
This is the only thing in there of any note.

11/19/18 09:40:28 ANS1467E ICC routine ICC_SetValue(ICC_FIPS_APPROVED_MODE) returned: majRC = 2, minRC = 2, desc = 'Invalid data value: icclib.c:989'.
11/19/18 09:40:28 ANS1463E Unexpected error in cryptography library.
11/19/18 09:40:28 ANS1463E Unexpected error in cryptography library.
 
There isn't much online aboutr icclib.c:989. We did recently apply an Oracle Security patch, but the other database on the server that shares all these TDP libraries is operating fine.
 
As a test.
In the dsm.sys file for the TSM API, add the following -
ENCRYPTIONType DES56

Since there is a change in the dsm.sys file, be sure to stop/restart the dsmsched daemon so that the new update in the dsm.sys will be read.

I encounter a similar issue years ago.
The funny part, we do not encrypt the Oracle data.
It just over ride the default of ENCRYPTIONType AES128 .
What's strange in the dsm.sys we do not even have "include.encrypt" for the Oracle data.

Not sure what version of the TSM API that you are using with the TDP Oracle 7.1.
May want to upgrade the TSM API to the same levels as the TDPO.

If we are not able to upgrade the TSM API.
Open a PMR with IBM Support on the possibility of a bug.

Good Luck,
Sias
 
They were installed together, so I imagine that they are at the same level. I'll try the setting (I've seen this on line). I didn't realize you have to stop and restart the daemon for it to take affect, so thanks.
 
If the TSM API was installed at the same time as the TDPO.
They should be the same levels.
Just to be sure. Do suggest that you run lslpp -L tivoli.tsm.* to confirm the the levels.

When there are any changes to the dsm.opt and/or dsm.sys.
The dsmsched daemon need to be stop and restarted.
When I upgrade the TSM B/A, and API Client. I stop/restart the dsmsched daemon.

Good Luck,
Sias
 
I found that the TSM CLIENT 64 - Backup/Archive Java GUI & Web Client is 7.1.1.3
The IBM Tivoli Storage Manager for Databases - Oracle on AIX is 7.1.0.0

Should that be right?
 
The TDPO communicate with the TSM Server via the TSM API and not with the TSM Backup/Archive client.
We are interested in the TSM API version.

Re-run the lslpp -L tivoli.tsm.* and look for the TSM API.

Did we added ENCRYPTIONType DES56 in the dsm.sys file for the TSM API?
If the results are still the same. Did we update the dsm.sys for the TSM B/A Client rather than the one for the TSM API?

Good Luck,
Sias
 
Fileset Level State Type Description (Uninstaller)
----------------------------------------------------------------------------
tivoli.tsm.client.api.64bit 7.1.1.3 C F TSM Client - 64bit Application Programming Interface
tivoli.tsm.client.ba.64bit.base 7.1.1.3 C F TSM Client 64 - Backup/Archive Base Files
tivoli.tsm.client.ba.64bit.common 7.1.1.3 C F TSM Client 64 - Backup/Archive Common Files
tivoli.tsm.client.ba.64bit.image 7.1.1.3 C F TSM Client 64 - IMAGE Backup Client
tivoli.tsm.client.ba.64bit.web 7.1.1.3 C F TSM Client 64 - Backup/Archive Java GUI & WEB Client
tivoli.tsm.client.oracle.aix.64bit 7.1.0.0 C F IBM Tivoli Storage Manager for Databases - Oracle on AIX
tivoli.tsm.client.oracle.tools.aix.64bit 7.1.0.0 C F IBM Tivoli Storage Manager for Databases - Oracle Tools on AIX
tivoli.tsm.loc.client.oracle.aix.64bit.ela 7.1.0.0 C F IBM Tivoli Storage Manager for Databases - Oracle E-Lic

I did add the ENCRYPTIONType DES56 to our dsm.sys file and restarted the daemon. Ran a backup and got the same error.

Interestingly enough, it appears to happen to oracle installations after they have been patched with the most recent PSU. But again, not all of the patched installations.
 
Just to be sure that we updated the dsm.sys file for the TSM API and not for the TSM B/A Client.

In the directory /usr/tivoli/tsm/client/oracle/bin64 look for a file called tdpo.opt .

In the tdpo.opt , look for the parameter dsmi_orc_config it should be pointing to the dsm.opt file.
The default path, /usr/tivoli/tsm/client/oracle/bin64/.
Once in the dir, look for the dsm.sys file.
The add ENCRYPTIONType DES56 .

If we did update the correct dsm.sys file.
I would call IBM support.

Good Luck,
Sias
 
Back
Top