This is absolutely normal when you try to perform a complete recovery from a hot backup, because that is how hot backups work, you will never have the latest changes in your backups.
Your backup includes archivelogs up to sequence 29. The next changes were in log sequence 30, but log sequence 30 became the current redo log at the time your backup was finished, so you do not have any backup of that. This is not a problem, this is how a hot backups work, you will never have backups of the latest log sequence. Obviously, the next hot backup will back up that, but by the end of that backup, another sequence becomes the latest sequence.
If you simply try recover database;, RMAN tries to recover the database to the most current state, and it does not know where to stop (except when you have not only the archivelogs, but the redo logfiles also). Your last log sequence in the backup is 29, RMAN will complain about the next one, because it does not know where to stop.
If you want to avoid the above error, you can explicitly specify RMAN where to stop (perform a point-in-time recovery). For example:
recover database until sequence 30;
This would have had the same result as your recover command, without throwing an error. You can also specify UNTIL SCN and UNTIL TIME.
30 because:
When specifying log sequences, if the last created archived redo log
has sequence n, then specify UNTIL SEQUENCE n+1 so that RMAN will
apply n and then stop.
Or, you can just ignore this error and continue with alter database open resetlogs.
Yes, you need to catalog the backups at their new location.
You should run crosscheck also on the backups, so the entries pointing to the old location become EXPIRED.
Best Answer
From /tmp/trace.sql:
If you're only recreating the controlfile you should be able to perform a complete recovery. i.e. without resetlogs. If you are missing some online redo logs or if they are not complete, then it will be a partial recovery, and RESETLOGS will be required.