ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

During duplicate command or during normal recovery process of database, if ORA-01547 comes, it would mean that datafile(s) are not consistent after the recovery and need more redo data to be applied to make datafiles consistent. The full error stack could be like the following. 

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below  ORA-01194: file 1 needs more recovery to be consistent  ORA-01110: data file 1: '+DATAC1/operat/system01.dbf'

Along with this error message, it should also return the log sequence number which is currently needed to move forward to apply redo. 

RMAN-00571: ===========================================================  RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============  RMAN-00571: ===========================================================  RMAN-03002: failure of Duplicate Db command at 06/04/2018 12:13:06  RMAN-05501: aborting duplication of target database  RMAN-03015: error occurred in stored script Memory Script  RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 93329 and starting SCN of 3144676379

You can query v$datafile_header to check until what SCN each datafile has been recovered. Fuzzy status means file is not consistent and need recovery 

SQL> select fuzzy,checkpoint_change# from v$datafile_header;    FUZ CHECKPOINT_CHANGE#  --- ------------------  select fuzzy,checkpoint_change# from v$datafile_header;    FUZ CHECKPOINT_CHANGE#  --- ------------------  YES         3144676379  YES         3144676379  YES         3144676379  NO          3144676379  NO          3144676379  NO          3144676379  YES         3144676379  NO          3144676379  NO          3144676379  YES         3144676379  NO          3144676379    FUZ CHECKPOINT_CHANGE#  --- ------------------  NO          3144676379  YES         3144676379  YES         3144676379  NO          3144676379  NO          3144676379  NO          3144676379  YES         3144676379  NO          3144676379  NO          3144676379  NO          3144676379  NO          3144676379    FUZ CHECKPOINT_CHANGE#  --- ------------------  NO          3144676379  NO          3144676379  YES         3144676379  YES         3144676379  YES         3144676379  YES         3144676379  YES         3144676379

In this case, you would need to restore the archived redo log sequence number 93329 from the backup and perform the recovery again. If after applying the archived log sequence 93329 the FUZZY column is still YES, you will need next archived log and keep applying logs until all files are consistent (FUZZY column would show NO for consistent datafiles)