Please note that to view the My Oracle Support documents linked in this post you have to register for My Oracle Support first!

I know that this issue is quite special and hopefully most of you guys will never hit it. So here’s what happened …

The bigfile tablespace feature

As you maybe (not) know: RDBMS version 10g Oracle introduces bigfile tablespaces. This feature allows you to have a tablespace size up to 32TB when using a 8k blocks size or up to 128TB for a single tablespace when using 32k blocks. So far so good.

Some useful information

Here’s a cool My Oracle Support note (262472.1) regarding bigfile tablespaces.

The problem we ran into

But some day in one of our databases (in the meantime the database was upgraded to 18c) one of the bigfile tablespaces ran out of space. Additionally to the fact that a full tablespace is never a funny thing: having a bigfile tablespace filled up to the maximum size is a much worse thing.
What you also maybe (not) know: bigfile tablespaces can only have one single datafile. So it’s quite difficult to solve the issue when a bigfile tablespace is full.

Later we noticed that the RMAN backup pieces of this filled up tablespace are not present within the RMAN catalog nor in the database’s controlfile anymore. The good message is … they are still available in the filesystem.

After struggling around with this issue for a while we found a note in My Oracle Support which states that this is a bug in RDBMS 11g and later. Even if the files are available on disk, RMAN doesn’t recognize them anymore.

As stated in MoS note 2407835.1 you can re-catalog these files if they are still available on disk. Despite the fact that the note states that you can use the “catalog start with” clause to re-catalog every valid backup piece within the directory, this clause is not working. The only way to re-catalog the missing pieces is using the “catalog backuppiece” clause for every single file. Maybe you can imagine that it takes some time if you separate your 32TB bigfile tablespace into backup pieces of 256G size.

To sum it up: it’s quite a strange bug but if you know about it, it’s quite easy to fix.

The details about the issue

Following you can see the file we backed up

And below, a snippet of the backup logfile is shown

We checked the datafile within RMAN (tried with or without catalog with the same result)

After that we tried to catalog all the files using ‘catalog start with

After cataloging every file with the glob *20191003* in the directory /zfssa/BACKUP/ORCL01/ the following output appeared on the command line:

Finally we were able to restore file number 8