Pular para o conteúdo principal

ORA-28365: wallet is not open - Oracle Data Guard + Oracle TDE





Problema:


No meu ambiente de testes usando Oracle Data Guard e com algumas tablespaces com TDE me deparei com o seguinte erro:

PR00 (PID:396056): MRP0: Background Media Recovery terminated with error 28365
2024-03-15T03:12:42.419136+00:00
Errors in file /u01/app/oracle/diag/rdbms/thdr/thdr/trace/thdr_pr00_396056.trc:
ORA-28365: wallet is not open
2024-03-15T03:12:43.000571+00:00
Recovery interrupted!
Recovered data files to a consistent state at change 32232590
Stopping change tracking


Solução:


Verifiquei a wallet na base de dados standby e estava fechada.


set lines 300
col name for a15
col wrl_type for a10
col status for a30
select p.con_id, p.name, p.open_mode, ew.wrl_type, ew.wallet_type, ew.status
from v$pdbs p join v$encryption_wallet ew on (ew.con_id = p.con_id)
order by p.con_id;

    CON_ID NAME            OPEN_MODE  WRL_TYPE   WALLET_TYPE          STATUS
---------- --------------- ---------- ---------- -------------------- ------------------------------
         2 PDB$SEED        READ ONLY  FILE       UNKNOWN              CLOSED
         3 THPDB           MOUNTED    FILE       UNKNOWN              CLOSED


SQL> show parameter tde

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
one_step_plugin_for_pdb_with_tde     boolean     FALSE
tde_configuration                    string      KEYSTORE_CONFIGURATION=FILE





Abrir a wallet e o standby voltou a sincronizar:

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY senha$00;
keystore altered.


Voce pode deixar a keystore como auto-login, assim sempre que o banco de dados for reiniciado a wallet vai estar aberta.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/THDR/wallet/tde/' identified by senha$00;
keystore altered.



select p.con_id, p.name, p.open_mode, ew.wrl_type, ew.wallet_type, ew.status
from v$pdbs p join v$encryption_wallet ew on (ew.con_id = p.con_id)
order by p.con_id;
SQL> SQL> SQL> SQL>   2    3
    CON_ID NAME            OPEN_MODE  WRL_TYPE   WALLET_TYPE          STATUS
---------- --------------- ---------- ---------- -------------------- ------------------------------
         2 PDB$SEED        READ ONLY  FILE       AUTOLOGIN            OPEN
         3 THPDB           MOUNTED    FILE       AUTOLOGIN            OPEN


Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G