Well, I guess the database is expendable since there is no proper backup. So just drop and recreate the database.
OK, seriously there are not many options left. Before you do anything shutdown the database and copy all files which belong to the database somewhere else! Because everything you do can make it worse.
Once you did that you have 2 options:
- Open an Oracle Service Request. With their help try to restore the block with lots of tricks and magic.
- Call the Oracle Consulting Team, they have unpublished/internal tools which might be helpful.
This database is not in archivelog mode so there is no option to restore the block from a backup. If you still have an rman backup of datafile 1 you might be able to restore this file and then open the database with _allow_resetlogs_corruption (Don't use this option on your own!). Because you cannot fully recover the block, you have to tell Oracle that you don't care that the datafile do not have the same SCN. See details here: https://practicalappsdba.wordpress.com/2008/04/01/how-to-recover-and-open-the-database-if-the-archive-log-required-for-recovery-is-missing/
If this is a block which contains standard objects you might be able to extract the block from a healthy database and inject it on this block.
Good luck!
Asking the database to do the impossible.
You changed the TAG, so you created a new initial set of image copies.
As diskspace was becoming increasingly tight, I changed the backup
script to use a different TAG to try and force a new set of backup
images to be create on the new disk. This seemed to work - the new set
of backup images were created okay on the new disk that night.
Lets say this happened on 2016-12-13 (just assuming, based on this):
This has now been failing for the last 6 nights
Next day, the backup script on 2016-12-14 reached this point:
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';
So it wanted to recover the image copies created on 2016-12-13 to an earlier state: SYSDATE-7 = 2016-12-07. That does not work like that. You can not rewind image copies to earlier states. When you try to do something like this, RMAN will look for an earlier image copy, which it can recover (forward, not backward), but there is no earlier image copy with the specified TAG, hence: no copy of datafile 1 found to recover.
So this happened all day until today. Today, this script ran again:
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';
Which means, recover the image copy created on 2016-12-13 to a state: SYSDATE-7 = 2016-12-12. Still won't work.
Tomorrow SYSDATE-7 will mean 2016-12-13, the day the new initial image copies were created. I suspect this will also fail. Lets say, your script starts at the same time every day, 00:00. It started at 2016-12-13 00:00, finished creating the image copies at 2016-12-13 01:00. The next time the script starts (2016-12-20 00:00), SYSDATE-7 will still mean an earlier time: 2016-12-13 00:00.
But the day after tomorrow, when SYSDATE - 7 = 2016-12-14, it will start recovering the image copies.
If you run the above script every day, it will not recover anything on the first 7 days because of SYSDATE-7. It will start recovering on the 8th day.
Or, you could try this right now by running the script with the PREVIEW option. This will not do any recovery, just a preview. This, I suspect, will still print the same errors as in the last 6 days:
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7' preview;
But this should list the image copies that would be recovered, the starting and ending SCN, and the logfile used for recovery:
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-5' preview;
Best Answer
If you change file's permissions during copy operation, tar will throw "file changes as we read it".