ORA-19563 on rman restore

I hit error ORA-19563 during rman restore last week.

I was restoring a database backup from Oracle 11.2 on ASM to a Oracle 11.2 on Filesystem.

Although not the same procedure, MOS RMAN Duplicate Fails With RMAN-06136 ORA-19563 (Doc ID 453123.1) helped me on this issue when it mentioned I could have duplicate filenames.

There was duplicated filenames indeed !

My restore script was:

run {
     set newname for database to '/oradata/%b';
     restore database;
     switch datafile all;
 }

Which means that datafile 55 was overwritten by datafile 56 hence rman error on switch step.

Quick fix:

  • remove datafile 56
  • restore only datafile 55 and 56 using set newname clause but specifying different filename:
run {
         set newname for datafile 55 to '/oradata/svm910t02.dbf';
         set newname for datafile 56 to '/oradata/svm910t03.dbf';
         restore datafile 55;
         restore datafile 56;
 }
  • run original script again which this time will just perform the switch step

How to prevent this from happening again ?

  • Check if you have duplicate filenames before restoring:
select substr ( file_name, instr( file_name, '/', -1)) file_name, count() from dba_data_files group by substr ( file_name,instr( file_name, '/', -1))  having count() > 1
/
  • If yes, run rman restore like this:
run {
         set newname for datafile 56 to '/oradata/svm910t03.dbf';
         set newname for database to '/oradata/%b';
         restore database;
         switch datafile all;
 }

More information can be found at Oracle 11.2 docs here.

Advertisements

Restart from a failed Oracle upgrade

Interesting situation this morning.

I was performing a database upgrade from 11.2 to 12.2 when my VPN crashed.

I realized that I forgot to start the upgrade process using linux screen terminal which means that my upgrade process was lost.

Well, Oracle 12.2 has the ability to resume a failed upgrade process from the failed step automatically !

From the Oracle Docs:

Oracle Database 12c release 2 (12.2) includes a new Resume option for Parallel Upgrade Utility. This option is available for both CDBs and Non-CDBs. You are not required to identify failed or incomplete phases when you rerun or restart the upgrade. When you use the Parallel Upgrade Utility using the resume option (-R), the utility automatically detects phases from the previous upgrade that are not completed successfully. The Parallel Upgrade Utility then reruns or restarts just these phases that did not complete successfully, so that the upgrade is completed. Bypassing steps that already completed successfully reduces the amount of time it takes to rerun the upgrade. 

So I just ran $ORACLE_HOME/bin/dbupgrade -n 4 -R -l $ORACLE_HOME/diagnostics and the upgrade process was restarted.

Cool new feature, right ?

More info about it here.

Data transfer from AWS Oracle RDS to S3

It looks simple, right ? It is but there are a lot to do before you can actually perform the copy.

Prerequisits:

  • Create an IAM policy that gives RDS read/write/list permissions to the S3 bucket
  • Create an IAM role that gives RDS access to the S3 bucket
  • Associate the IAM role to the DB instance
  • Create a new Option Group or associate the S3_INTEGRATION option to an existing one

You can check the details on how to perform theses steps here.

OK, now you can perform the data transfer running, for example, the command below:

SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
       p_bucket_name    =>  'mybucket', 
       p_prefix         =>  '', 
       p_s3_prefix      =>  '', 
       p_directory_name =>  'DATA_PUMP_DIR') 
    AS TASK_ID FROM DUAL; 

It will copy all files on DATA_PUMP_DIR directory to S3 bucket mybucket

This command will provide a task_id that will be useful to monitor the transfer status.

You can rely on AWS RDS Events at the console or the store procedure below to monitor the transfer job.

 SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-<task_id>.log')); 

Example:

Or at the AWS Console:

GUOB TECH DAY / Groundbreakers Tour LATAM 2019

Galera,

Em 2019 ocorrerá a 10ª edição do GUOB Tech Day!

APROVEITE o Voucher de 20% de Desconto: NAO_PERCA_GUOB

Na sua décima edição, o GUOB vem recheado de excelente conteúdo e excelentes speakers!!

📌Contando com 9 salas e 3 Workshops, será o maior evento já realizado pelo GUOB no Brasil!

A minha palestra será sobre Oracle Exadata Cloud at Customer às 13:50h na SALA 1.

📌Quando: 10/08/2019

📌Onde:
Universidade Nove de Julho (UNINOVE) – Campus Vergueiro.
Rua Vergueiro, 235 – Liberdade – São Paulo-SP

📌Quanto?
https://lnkd.in/dbX7v3Q

📌Inscrições:
https://lnkd.in/d9n6Pyd

📌Grade Completa:
https://lnkd.in/dfwRihx

📌Será Filmado ou Transmitido Online?
Não

Participe da 10ª edição do GUOB TECH DAY. Faça sua inscrição ainda hoje, aproveite que o ingresso no segundo lote está com desconto !

-ocmrf is no longer needed

I was patching an Oracle 12.1 Restart with latest bundle patch this week and realized that the -ocmrf option is no longer needed.

This enhancement started with Opatch 12.2.0.1.5 so now you have one more reason to update your Opatch 🙂

Don’t even bother looking for emocmrsp binary … it is no longer there !

So things just got easier ! All you have to do is run:

opatchauto apply <UNZIPPED_PATCH_LOCATION>/<BUG NO> 

Example for 12.1 BP:

export PATH=$PATH:/u01/app/12.1.0.2/grid/OPatch/
opatchauto apply /home/oracle/stage/29176139/29141038

Reference: MOS note 2161861.1, 1591616.1 and readme.html for patch 29176139.

DBA BRASIL 4.0

Está preparado ? Já fez a inscrição aqui ?

Esse ano o DBA BRASIL será realizado dia 04/05 na Faculdade Impacta,
Avenida Rudge, 315 – Barra Funda/SP, à partir das 8:45h.

O evento, como sempre, é gratuito e tem uma grade de conteúdo excelente.

Minha palestra será sobre Disaster Recovery na Oracle Cloud às 13h na sala 113.

Nos vemos lá !

Agradeço, desde já, aos organizadores e patrocinadores do evento.

CRS-2510 on GI Management Repository creation

I was following the steps from MOS note 12.2: How to Create GI Management Repository (Doc ID 2246123.1) and it failed with the error below:

[ 2019-04-02 10:15:05.945 BRT ] Registering database with Oracle Grid Infrastructure
[ 2019-04-02 10:15:06.320 BRT ] PRCR-1006 : Failed to add resource ora.mgmtdb for mgmtdb
PRCR-1071 : Failed to register or update resource ora.mgmtdb
CRS-2510: Resource ‘ora.MGMTLSNR’ used in dependency ‘hard’ does not exist or is not registered.
CRS-2514: Dependency attribute specification ‘hard’ is invalid in resource ‘ora.mgmtdb’
[ 2019-04-02 10:15:11.715 BRT ] DBCA_PROGRESS : DBCA Operation failed.

I could not found an exact match @MOS but to workaround this issue you can run srvctl add mgmtlsnr as grid user before running dbca and after that it will work properly.