Re: Strange behaviour with TDE wallet on Exadata

From: RajeevGM <rprabha01_at_gmail.com>
Date: Mon, 26 Jun 2017 09:12:24 -0400
Message-Id: <12AD6EFD-0C07-4ED8-85AF-2A0E81316861_at_gmail.com>



Tony,

Have you :

  1. Looked at bug 12927030 (or any updated ones) ?
  2. Tried manually configuring the auto_login on duplicate/ target server ?
  3. 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_at_tpg.com.au> 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
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jun 26 2017 - 15:12:24 CEST

Original text of this message