Skip to Main Content
  • Questions
  • Exluding ARCHIVE_MESSAGES tbs from weekly backup

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Stefan.

Asked: October 06, 2022 - 5:39 pm UTC

Last updated: October 07, 2022 - 1:51 am UTC

Version: 19c

Viewed 1000+ times

You Asked

Hi Tom,

In an development Server we want to do a Rman Backup weekly which has
the following tablespaces:
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
IAGENT_DATA
ARCHIVE_MESSAGES


I want to exclude the ARCHIVE_MESSAGES Tablespace in the weekly backup which has historical Data to save disk backup space (2TB).

I want a second backup every year with the ARCHIVE_MESSAGES Tablespace only in the backup.


Is this possible?
Or do I get in an upossible Situation when restoring the weekly backup, and afterwards restoring the tablespace ARCHIVE_MESSAGES from the yearly backup.

Thanks Tom.

and Connor said...

By default, if you (say)

- restore files for SYSTEM...etc but not ARCHIVE_MESSAGES from (say) Oct 1
- restore files for ARCHIVE_MESSAGES from (say) June 1

then the database will want archive logs from June 1 onwards to bring all files back into sync, because we need to roll forward all files to a common point in time. That is one option.

Another option is if the ARCHIVE_MESSAGES can be made read only ( I don't know your usage). Once a tablespace is read only, a single backup taken after the point can be used continuously as long as the tablespace is not made read write again.

We do also support tablespace point in time recovery, so you could restore ARCHIVE_MESSAGES from June and *leave* it at the June timeframe whilst the rest of the system is at October. There's a number of restrictions here. See https://docs.oracle.com/en/database/oracle/oracle-database/21/bradv/performing-rman-tspitr.html#GUID-40A9A54A-8742-42D9-AB47-F0B61439A100 for details


Is this answer out of date? If it is, please let us know via a Comment

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database