#Dica - Oracle Linux 7 perdendo o mapeamento dos discos criados via asmlib apos restart do servidor

Essa semana durante um atendimento identifiquei o seguinte cenário: Após a criação dos discos via asmlib em um ambiente com Red Hat 7,5, quando o servidor era reiniciado os discos não eram mais listados.
[root@lamimtst01 ~]# oracleasm listdisks
[root@lamimtst01 ~]#
[root@lamimtst01 ~]#
Porém se realizarmos um scandisk os discos serão escaneados e listados com sucesso.
[root@lamimtst01 ~]#  oracleasmscandisks
bash: oracleasmscandisks: command not found...
[root@lamimtst01 ~]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
Instantiating disk "ASMDISK002"
Instantiating disk "ASMDISK004"
Instantiating disk "ASMDISK001"
Instantiating disk "ASMDISK006"
Instantiating disk "ASMDISK003"
Instantiating disk "ASMDISK008"
Instantiating disk "ASMDISK005"
Instantiating disk "ASMDISK007"
[root@lamimtst01 ~]#  oracleasm listdisks
ASMDISK001
ASMDISK002
ASMDISK003
ASMDISK004
ASMDISK005
ASMDISK006
ASMDISK007
ASMDISK008
Não haviam erros nos logos do oracleasm ou na configuração do mesmo. O problema ocorre devido ao oracleasm estar sendo iniciado pelo servidor, antes do iSCSI storage. Desta forma precisei ajustar a ordem de inicialização.
Para isso, adicionei as 2 linhas abaixo no /usr/lib/systemd/system/oracleasm.service.
Requires=multipathd.service iscsi.service
After=multipathd.service iscsi.service
[root@lamimtst01 ~]# cat /usr/lib/systemd/system/oracleasm.service
[Unit]
Description=Load oracleasm Modules
Requires=multipathd.service iscsi.service
After=multipathd.service iscsi.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/oracleasm.init start_sysctl
ExecStop=/usr/sbin/oracleasm.init stop_sysctl
ExecReload=/usr/sbin/oracleasm.init restart_sysctl

[Install]
WantedBy=multi-user.target
[root@lamimtst01 ~]#
Após ajusta e reiniciar o servidor, os discos foram escaneados normalmente e puderam ser listados pelo oracleasm.
root@lamimtst01 ~]# shutdown -r now
login as: root
root@10.0.0.115's password:
Last login: Mon May  6 09:02:09 2019 from 10.1.0.141
[root@lamimtst01 ~]# oracleasm listdisks
ASMDISK001
ASMDISK002
ASMDISK003
ASMDISK004
ASMDISK005
ASMDISK006
ASMDISK007
ASMDISK008
[root@lamimtst01 ~]#
Por hoje era isso.

#Dica export para diskgroup ASM


Para realizarmos o export dp para ASM devemos seguir as seguintes etapas:
1 – Adicionar um diretório (directory) para destino dos dumpsets a um diskgroup ASM;
— instance ASM
SQL> ALTER DISKGROUP DGDATA ADD DIRECTORY '+DGDATA/backup/';

Diskgroup altered.
Neste momento a estrutura de diretórios é criada automaticamente abaixo do diskgroup ASM. 2 – Criar o diretório no banco de dados; — instance da base de dados
SQL> CREATE DIRECTORY DUMP AS '+DGDATA/backup/';

Diretorio criado.
3 – Criar um diretório para o arquivo de log. O arquivo de log DataPump não pode ser armazenada dentro de ASM; — instance da base de dados
SQL> CREATE DIRECTORY DUMP AS '/orabackup/datapump/log';

Diretorio criado.
4 – Executar o export DataPump; 4.1 – Criar usuário para backup e conceder os privilégios necessários.
SQL> create user backup identified by backup;          

Usuario criado.                                        

SQL> grant read,write on directory DUMP to backup;

Concessao bem-sucedida.                                

SQL> grant read,write on directory DUMP_LOGS to backup;

Concessao bem-sucedida.                                

SQL> grant EXP_FULL_DATABASE, RESOURCE to backup;      

Concessao bem-sucedida.
4.2 – Executar o backup.
[oracle@orcl ~]$ expdp backup/backup SCHEMAS=TESTE DUMPFILE=DUMP:owner_teste.dmp LOGFILE=DUMP_LOGS:owner_teste.log

Export: Release 11.1.0.6.0 - Production on Sunday, 04 September, 2011 10:18:29

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Connected to: Oracle Database 11g Release 11.1.0.6.0 - Production
Iniciando "BACKUP"."SYS_EXPORT_SCHEMA_01":  backup/******** SCHEMAS=TESTE DUMPFILE=DUMP_SETS:owner_teste.dmp LOGFILE=DUMP_LOGS:owner_teste.log
Estimativa em andamento com o metodo BLOCKS...
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimativa total usando o metodo de BLOCKS: 64 KB
Processando o tipo de objeto SCHEMA_EXPORT/USER
Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exportou "TESTE"."TESTE"                             5.117 KB      17 linhas
Tabela-mestre "BACKUP"."SYS_EXPORT_SCHEMA_01" carregada/descarregada com sucesso
******************************************************************************
Conjunto de arquivos de dump para BACKUP.SYS_EXPORT_SCHEMA_01 e:
  +DGDATA/backup/owner_teste.dmp
O job "BACKUP"."SYS_EXPORT_SCHEMA_01" foi concluido com sucesso em 10:20:20
5 – Verificar se o arquivo de backup foi gerado para o diskgroup ASM. — instance ASM
SQL> set lines 200
SQL> col TYPE for a15
SQL> col NAME for a60
SQL> select * from v$ASM_FILE where TYPE='DUMPSET';

GROUP_NUMBER FILE_NUMBER COMPOUND_INDEX INCARNATION BLOCK_SIZE     BLOCKS      BYTES      SPACE TYPE            REDUND STRIPE CREATION_ MODIFICAT R
------------ ----------- -------------- ----------- ---------- ---------- ---------- ---------- --------------- ------ ------ --------- --------- -
           1         265       16777481   760961921       4096         42     172032    1048576 DUMPSET         UNPROT COARSE 04-SEP-11 04-SEP-11 N

SQL> select * from v$asm_alias where file_number=265;

NAME                                                         GROUP_NUMBER FILE_NUMBER FILE_INCARNATION ALIAS_INDEX ALIAS_INCARNATION PARENT_INDEX REFERENCE_INDEX A S
------------------------------------------------------------ ------------ ----------- ---------------- ----------- ----------------- ------------ --------------- - -
owner_teste.dmp                                                         1         265        760961921         371                 1     16777587        33554431 N N
BACKUPSYS_EXPORT_SCHEMA_01_71215_1.265.760961921                        1         265        760961921         477                 1     16777693        33554431 N Y

SQL> exit
Disconnected from Oracle Database 11g Release 11.1.0.6.0 - Production
[oracle@orcl ~]$ asmcmd
ASMCMD> cd DGDADOS/backup/
ASMCMD> ls -lrt
Type     Redund  Striped  Time             Sys  Name
                                           N    owner_teste.dmp => +DGDATA/ORCL11G/DUMPSET/BACKUPSYS_EXPORT_SCHEMA_01_71215_1.265.760961921
ASMCMD>

#Dica - Renomear um ASM disk group



Na dica de hoje, estarei mostrando o processo para renomear um diskgroup. Vale ressaltar que o diskgroup que estarei renomeando ainda não esta sendo utilizado. Caso estivesse em utilização, além de renomear o disk group, seria necessário ajustar os arquivos de banco que estariam contidos nele.

Neste exemplo tenho um disk group chamado RECO e estarei renomeando para DGRECO.


SQL> select NAME,STATE from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
RECO                           MOUNTED
DGDATA                         MOUNTED
Para efetuar o processo de rename é preciso primeiramente desmontar o disk group RECO.
[grid@lamimtst:+ASM ~]$ sqlplus

SQL*Plus: Release 12.1.0.2.0 Production on Fri Apr 12 08:43:14 2019

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter user-name: / as sysasm

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Automatic Storage Management option

SQL> alter diskgroup RECO dismount;
alter diskgroup RECO dismount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15027: active use of diskgroup "RECO" precludes its dismount


SQL> alter diskgroup RECO dismount force;

Diskgroup altered.

SQL> exit
Agora pode ser executado o processo de rename com o usuário grid (utilizado para a instalação do grid). Para isso será usado o comando renamedg, conforme abaixo.
[grid@lamimtst:+ASM ~]$ renamedg dgname=RECO newdgname=DGRECO asm_diskstring='/dev/oracleasm/disks/'

Parsing parameters..
renamedg operation: dgname=RECO newdgname=DGRECO asm_diskstring=/dev/oracleasm/disks/
Executing phase 1
Discovering the group
Checking for hearbeat...
Re-discovering the group
Generating configuration file..
Completed phase 1
Executing phase 2
Completed phase 2
[grid@lamimtst:+ASM ~]$
Apos renomear o DG, basta monta-lo e estará pronto para utilização.
SQL> select NAME,STATE from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
DGRECO                         DISMOUNTED
DGDATA                         MOUNTED

SQL> alter diskgroup DGRECO mount;

Diskgroup altered.

SQL> select NAME,STATE from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
RECO                           MOUNTED
DGDATA                         MOUNTED

SQL>

Lembrando que se você tiver dados no disco (datafiles, redo, controlfile, spfile) você precisará ajustar no banco de dados.

#Dica - erro ao instalar o Oracle Cliente 12.1 no windows 10 64 bits - INS-20802

Durante a instalação de um Oracle Client 32 bits em um windows 10 64 bits estávamos tendo um erro no Oracle Net Configuration - [INS-20802] Oracle Net Configuration Assistant failed.


Este erro ocorre devido a um bug no instalado do Oracle Client 32bits. Para poder corrigir e realizar a instalação, é necessário ajustar o arquivo oraparam.ini que está localizado no diretório install do client.

Edite o arquivo install/orapram.ini e altere a o valor do parametro MSVCREDIST_LOC de vcredist_x64.exe with  para vcredist_x86.exe. Salve o arquivo e execute o instalador novamente.
de: MSVCREDIST_LOC=vcredist_x64.exe
para: MSVCREDIST_LOC=vcredist_x86.exe

Após o ajuste a instalação pode ser realizada com sucesso.


Fonte: Installing 12.1.0.1 or 12.1.0.2 RDBMS/Client NETCA errors with oranjni12.dll: Can't find dependent libraries (Doc ID 1599940.1)

#Dica - Matar sessões inativas no oracle database

Algumas vezes pode ser necessário que você elimine as sessões inativas a mais de um determinado tempo.
É importante sempre definir um tempo de expiração de acordo com a necessidade do seu ambiente. Neste caso estaremos utilizando o valor de 8 horas de inatividade.

O primeiro passo é identificar qual o profile associado ao usuário que vamos querer eliminar as sessões inativas. Para isso basta uma simples consulta na dba_users, conforme abaixo.
SQL> select profile from dba_users where username='LAMIM';

PROFILE
------------------------------
DEFAULT
No exemplo acima, o usuário LAMIM que é o que estaremos configurado para que as suas sessões inativas sejam eliminadas apos 8 horas, está definido como profile default. Vale lembrar que o processo afetara a todos os usuários que estiverem abaixo do profile default. Desta forma, se desejar pode ser criado um profile especifico para o usuário e definido um idle time para cada profile de acordo com a necessidade.

Vamos alterar o idle_time do profile default para 8 horas (480 minutos). Com o usuário sysdba, executar o comando abaixo.
 SQL> show parameter resource_limit; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_limit boolean FALSE SQL> alter system set resource_limit=true; System altered. SQL> show parameter resource_limit; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_limit boolean TRUE SQL> 

SQL> ALTER PROFILE default LIMIT IDLE_TIME  480;

Profile altered.

SQL>
Após definir o IDLE_TIME, vamos ativar o parâmetro resource_limit que por default estará em false e criar a procedure que irá eliminar as sessões inativas.
SQL> CREATE OR REPLACE PROCEDURE proc_kill_inactive_sessions IS
   CURSOR kill_sessions_cur
   IS
      SELECT s.SID, s.serial#
        FROM v$session s
       WHERE s.status = 'SNIPED';

   v_cmd   VARCHAR2 (100);
BEGIN
   FOR kill_sessions_rec IN kill_sessions_cur
  2    3    4    5    6    7    8    9   10   11     LOOP
      v_cmd :=
            'Alter system kill session '''
         || kill_sessions_rec.SID
         || ','
 12   13   14   15   16           || kill_sessions_rec.serial#
         || ''' immediate';

      EXECUTE IMMEDIATE v_cmd;
   END LOOP;
END;
/
 17   18   19   20   21   22
Procedure created.

SQL>
Após criar a procedure, estaremos criando um job para executa-la, com um intervalo de 1 hora.

SQL> DECLARE
  X NUMBER;
  2    3  BEGIN
  SYS.DBMS_JOB.SUBMIT
    ( job       => X
  4    5    6       ,what      => 'proc_kill_inactive_sessions();'
  7       ,next_date => sysdate
  8       ,interval  => 'SYSDATE + 60/1440'
     ,no_parse  => TRUE
    );
  9   10   11    SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
END;
/
 12   13
PL/SQL procedure successfully completed.

SQL>
SQL>
commit;
SQL>
Commit complete.

SQL>
Nossa rotina de eliminação das sessões inativas esta pronta. A cada uma hora o job vai executar a procedure que eliminará as sessões que estão marcadas como SNIPED (de acordo com o IDLE_TIME definido no profile).

#Dica - ORAchk - OS authentication is not enabled so please enter sysdba privileged user name for

O ORAchk é uma excelente ferramenta desenvolvida pela Oracle para validação de database e middleware. Para mais informações sobre a mesma, basta consultar a Doc ID 1268927.2.

Atualmente o ORAchk está na versão 18.4.0 e constantemente é atualizado com novas validações e melhorias.

Durante a execução do ORAchk 18.4.0 em um ambiente Oracle Rac 12c, ao entrar com o usuário de banco (solicitado devido a autenticação de SO não estar habilitada) ocorreu um erro de conexão (ORA-01034).

Para evitar este erro, deve-se especificar após o nome do usuário que possuí permissão sysdba a condição as sysdba.

Neste exemplo é passado o usuário lamim as sysdba.


[root@lamimsrvc01 tmp]# ./orachk


Clusterware stack is running from /orabin01/app/12.1.0.2/grid. Is this the correct Clusterware Home?[y/n][y] y

Checking ssh user equivalency settings on all nodes in cluster for root

Node srvoraprd02 is configured for ssh user equivalency for root user



Searching for running databases . . . . .

.  .
List of running databases registered in OCR

1. cdbprd1
2. None of above

Select databases from list for checking best practices. For multiple databases, select 1 for All or comma separated number like 1,2 etc [1-2][1]. 1
.  .
OS authentication to login as sysdba is not enabled so skipping cdbprd1 for pdb discovery
.  .
.  .  .

Checking Status of Oracle Software Stack - Clusterware, ASM, RDBMS

.  .
OS authentication is not enabled so please enter sysdba privileged user name for cdbprd1:-  lamim
Enter password for lamim@cdbprd1:-

SELECT 1 FROM DUAL
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


OS authentication is not enabled so please enter sysdba privileged user name for cdbprd1:-  lamim as sysdba
Enter password for lamim as sysdba@cdbprd1:-
. . . .
.  .  . . . .  .  .  .  .  .  .  .  .  . . . .  .  .  .  .  .  .  .
-------------------------------------------------------------------------------------------------------
                                                 Oracle Stack Status
-------------------------------------------------------------------------------------------------------
  Host Name       CRS Installed  RDBMS Installed    CRS UP    ASM UP  RDBMS UP    DB Instance Name
-------------------------------------------------------------------------------------------------------
lamimsrvc01                Yes          Yes          Yes      Yes      Yes            cdbprd11
srvoraprd02                Yes          Yes          Yes      Yes      Yes            cdbprd12
-------------------------------------------------------------------------------------------------------



Restaurando e recuperando um backup da Oracle Cloud em outro ambiente

A utilização de ambientes Cloud está cada dia mais comum e com isso as demandas de atividades relacionadas a esta tecnologia também.

O objetivo deste artigo é demostrar o processo de restauração de um backup rman de um ambiente Oracle Database Cloud Service em um novo servidor, seja ele outro ambiente cloud, ou um ambiente on premise.

Nos ambientes Oracle Database Cloud Service, os backups são criptografados através do TDE (Transparent Data Encryption) e por isso o processo de restore em um novo ambiente se difere um pouco do processo tradicional.

É importante sempre realizar um backup do wallet file ewallet.p12, pois sem o mesmo não será possível realizar a restauração.

No cenário abaixo, estaremos restaurando um backup físico de um ambiente Oracle Database Cloud Service na versão 11.2.0.4 (PSU 11.2.0.4.180417) em uma maquina virtual também a versão 11.2.0.4 (PSU 11.2.0.4.180417). É importante que PSU do banco onde o restore estará sendo realizado esteja na versão 11.2.0.4.180417 ou superior devido a necessidade de utilização do TDE.
  • Host1 - srvcpsdb01 - Oracle Database Cloud Service.
  • Host2 - ora11g - Maquina virtual.

O primeiro passo é transferir os arquivos para o servidor onde o restore será realizado. Devemos transferir o backup rman e o wallet file. 
Para localizar o wallet file basta executar a consulta abaixo no ambiente cloud (srvcpsdb01), que a mesma mostrará o caminho onde o mesmo foi gerado.
SQL> set lines 210
SQL> col WRL_PARAMETER for a60
SQL> select * from v$encryption_wallet;

WRL_TYPE             WRL_PARAMETER                                                STATUS
-------------------- ------------------------------------------------------------ ------------------
file                 /u01/app/oracle/admin/cpsprd/tde_wallet                      OPEN

SQL> !
[oracle@srvcpsdb01 ~]$ ls -ltr /u01/app/oracle/admin/cpsprd/tde_wallet*
total 8
-rw-------. 1 oracle oinstall 2845 Feb  6 17:15 ewallet.p12
-rw-------. 1 oracle oinstall 2923 Feb  6 17:15 cwallet.sso
[oracle@srvcpsdb01 ~]$
Como podemos ver acima, o arquivo ewallet.p12 esta no diretório /u01/app/oracle/admin/cpsprd/tde_wallet, basta copia-lo ao servidor onde estaremos restaurando o backup (ora11g).

No servidor ora11g, os backups do rman e do wallet foram copiados para o diretório /u01/orabackup/bkpcps.
Banco=lamimtst-> hostname
ora11g
Banco=lamimtst->
Banco=lamimtst-> pwd
/u01/orabackup/bkpcps
Banco=lamimtst-> ls -ltr
total 3638008
-rw-r----- 1 oracle oinstall      98304 Feb  8 21:10 spf_CPSPRD_152_1_999658386.spf
-rw-r----- 1 oracle oinstall    1179648 Feb  8 21:10 df_CPSPRD_150_1_999658379.dbf
-rw-r----- 1 oracle oinstall 3721166848 Feb  8 21:10 df_CPSPRD_149_1_999657904.dbf
-rw-r----- 1 oracle oinstall    1179648 Feb  8 21:10 cf_CPSPRD_153_1_999658388.ctl
-rw-r----- 1 oracle oinstall    1691648 Feb  8 21:10 arch_CPSPRD_151_1_999658383.arc
-rw-r--r-- 1 oracle oinstall       2845 Feb 10 14:30 ewallet.p12
Banco=lamimtst->
Para configurar a autenticação do wallet seguiremos os passos abaixo:
  • Criar a estrutura de diretório do mesmo e copia-lo. 
Banco=lamimtst-> mkdir -p /u01/app/oracle/admin/cpsprd/tde_wallet
Banco=lamimtst-> cp /u01/orabackup/bkpcps/ewallet.p12 /u01/app/oracle/admin/cpsprd/tde_wallet
Banco=lamimtst-> ls -ltr /u01/app/oracle/admin/cpsprd/tde_wallet/*
-rw-r--r-- 1 oracle oinstall 2845 Feb 10 11:24 /u01/app/oracle/admin/cpsprd/tde_wallet/ewallet.p12
  • Modificar o arquivo sqlnet.ora especificando o caminho do wallet, conforme abaixo.

Banco=lamimtst-> vim $ORACLE_HOME/network/admin/sqlnet.ora
ENCRYPTION_WALLET_LOCATION =
   (SOURCE = (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/admin/cpsprd/tde_wallet)
     )
   )
  • Por último, vamos executar o utilitário orapki para gerar o wallet auto-login.

Banco=lamimtst-> orapki wallet create -wallet /u01/app/oracle/admin/cpsprd/tde_wallet -pwd "senha" -auto_login
Oracle PKI Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Banco=lamimtst->
Concluídas estas etapas já é possível prosseguir normalmente com o restore/recover do ambiente no novo servidor. 
Conectar no rman, setar o dbid e restaurar o spfile.
Banco=lamimtst-> export ORACLE_SID=cpsprd Banco=lamimtst-> rman target / Recovery Manager: Release 11.2.0.4.0 - Production on Sat Feb 9 16:43:07 2019 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database (not started) RMAN> set DBID=2940662000 executing command: SET DBID RMAN> startup nomount; startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initcpsprd.ora' starting Oracle instance without parameter file for retrieval of spfile Oracle instance started Total System Global Area 1068937216 bytes Fixed Size 2260088 bytes Variable Size 281019272 bytes Database Buffers 780140544 bytes Redo Buffers 5517312 bytes RMAN> restore spfile from '/u01/orabackup/bkpcps/spf_CPSPRD_152_1_999658386.spf'; Starting restore at 09-FEB-19 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/orabackup/bkpcps/spf_CPSPRD_152_1_999658386.spf channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete Finished restore at 09-FEB-19 RMAN> 
Restaurar o controlfile e montar a base
RMAN> restore controlfile from '/u01/orabackup/bkpcps/cf_CPSPRD_153_1_999658388.ctl';

Starting restore at 09-FEB-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
output file name=/u02/app/oracle/oradata/cpsprd/control01.ctl
output file name=/u01/app/oracle/oradata/cpsprd/control02.ctl
Finished restore at 09-FEB-19

RMAN> alter database mount;

database mounted
released channel: ORA_DISK_1

RMAN> 
Realizar o restore/recover e abrir a base com open resetlogs.
RMAN> restore database;

Starting restore at 10-FEB-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/app/oracle/oradata/cpsprd/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u02/app/oracle/oradata/cpsprd/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u02/app/oracle/oradata/cpsprd/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u02/app/oracle/oradata/cpsprd/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u02/app/oracle/oradata/cpsprd/eximioti01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u02/app/oracle/oradata/cpsprd/protheus_data01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u02/app/oracle/oradata/cpsprd/protheus_index01.dbf
channel ORA_DISK_1: restoring datafile 00008 to /u02/app/oracle/oradata/cpsprd/protheus_data02.dbf
channel ORA_DISK_1: restoring datafile 00009 to /u02/app/oracle/oradata/cpsprd/protheus_index02.dbf
channel ORA_DISK_1: restoring datafile 00010 to /u02/app/oracle/oradata/cpsprd/protheus_data03.dbf
channel ORA_DISK_1: reading from backup piece /u01/orabackup/bkpcps/df_CPSPRD_149_1_999657904.dbf
channel ORA_DISK_1: piece handle=/u01/orabackup/bkpcps/df_CPSPRD_149_1_999657904.dbf tag=BACKUPDATABASEFULLDIARIO
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:14:05
Finished restore at 10-FEB-19

RMAN> recover database;

Starting recover at 10-FEB-19
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=86
channel ORA_DISK_1: reading from backup piece /u01/orabackup/bkpcps/arch_CPSPRD_151_1_999658383.arc
channel ORA_DISK_1: piece handle=/u01/orabackup/bkpcps/arch_CPSPRD_151_1_999658383.arc tag=BACKUPARCHIVELOGDIARIO
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/u02/cpsprd/cpsprd_1_86_999536648.arc thread=1 sequence=86
unable to find archived log
archived log thread=1 sequence=87
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/10/2019 14:19:36
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 87 and starting SCN of 3705846

RMAN>
RMAN> alter database open resetlogs;

using target database control file instead of recovery catalog

RMAN> exit


Recovery Manager complete.
Banco=lamimtst-> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sun Feb 10 15:04:15 2019

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SQL> select open_mode, database_role from v$database;

OPEN_MODE            DATABASE_ROLE
-------------------- ----------------
READ WRITE           PRIMARY

SQL>
Por hoje era isso. 
:)