Hi Tony,
Correct me if I'm wrong but if auto-login wallet was in use then the status
would say in v$encryption_wallet would be "AUTOLOGIN" and not "OPEN" ?
Did you try to open the wallet manually with a password ? Or restore the
controlfile only and see if the wallet will open when you mount the
database ?
Is the sqlnet.ora correct ? The databases on ODA could have different path
set for TNS_ADMIN, use srvctl getnev database to check that.
Regards,
Sve
On Tue, Jun 27, 2017 at 12:11 PM, De DBA <dedba@xxxxxxxxxx> wrote:
Thanks Rajeev,
Sadly none of those work in my case. I've opened an SR with Oracle, but it
looks that it has them stumped as well... I wonder whether it's some OS
security feature.. SELinux is disabled as far as I am aware, but perhaps
something else lurks out there..
Cheers,
Tony
On 26/06/17 23:12, RajeevGM wrote:
Tony,
Have you :
a) Looked at bug 12927030
(or any updated ones) ?
b) Tried manually configuring
the auto_login on duplicate/
target server ?
c) Checked if MOS note 389958.1
(or an updated one) is relevant
for your case ?
Rajeev
On Jun 26, 2017, at 7:14 AM, De DBA <dedba@xxxxxxxxxx> wrote:
G'day.
I'm in the process of moving databases from our old ODA to a brand new
Exadata, which involves RMAN duplication of TDE encrypted tablespaces. On
the Exadata this initially fails with ORA-28365, even though the wallet is
available and has auto-login enabled. The wallet for each encrypted
database is in the default location (${ORACLE_BASE}/admin/${ORACLE_SID}).
On the ODA this has always worked without a hitch. The (standby) databases
can be shutdown and restarted and the wallet is open when needed. We also
run a refresh process which involves duplicating a TDE encrypted database
in order to mask the data and then use that masked copy as a master for
refreshing the DEV and TEST environments from. The wallet is open when the
recovery phase starts and the process never errors.
Now to the Exadata. In every situation, whether the recovery phase of an
RMAN duplicate or bouncing an existing and working standby database, the
wallet remains closed and first access of encrypted data fails, even though
the auto-login file is present and readable. In the case of RMAN, the
duplication process ends in error. In the case of a standby database,
enabling managed recovery fails. In both cases the reported error is
ORA-28365: wallet is not open
The strange thing is that when I query v$encryption_wallet, it reports the
wallet as open. After that, recovery succeeds, but in the case of RMAN
duplicate only as long as the duplicate was for standby. At no point was
the wallet closed, or a password entered to open it. The .sso file exists
throughout and is never changed. A normal duplicate fails to open because
the database name is not updated in the control file before the duplicate
process fails.
In summary:
- "RMAN duplicate .. for standby" or "alter database recover managed
standby database" after restart:
RMAN-03002: failure of Duplicate Db command at ...
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
...
ORA-28365: wallet is not open
SQL> select * from v$encryption_wallet;
WRL_TYPE WRL__PARAMETER STATUS
======== ================ ======
file /path/to/wallet OPEN
SQL> alter database recover...
--> recovery succeeds.
- "RMAN duplicate ... to <new_sid>
Oracle instance shut down
...
RMAN-03002: failure of Duplicate Db command at ...
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
...
ORA-28365: wallet is not open
SQL> startup mount
...
ORA-01103 Database name <SOURCE_SID> in control file is not <new_sid>
The OS and database versions are the same on the ODA and the Exadata:
OUL 6.9
Oracle Database 11.2.0.4.170418
Any suggestions?
Cheers,
Tony
