Backing Up Read-Only Tablespaces in Oracle 26ai

Read-only tablespaces still need backups because unchanged data can be lost. A tablespace containing years of historical transactions remains vulnerable to damaged storage, missing datafiles, and corruption even when applications cannot update its contents. Read-only mode reduces changes to protect; a usable backup supplies the replacement data if the original files become unavailable.

In Oracle AI Database 26ai, a practical strategy is to complete the transition to read-only, back up the tablespace, and retain validated copies for as long as they are needed. While the tablespace remains unchanged, repeatedly backing up the same content may be unnecessary. However, backup retention, independent copies, media maintenance, and recovery testing remain part of the DBA's work.

This distinction matters in large databases. Historical data may occupy most of the storage while current transactions modify a much smaller set of tablespaces. Treating the historical portion separately can reduce backup workload without abandoning its protection. The aim is to avoid redundant copying while maintaining a complete recovery plan.

What Read-Only Mode Changes

A tablespace is a logical storage unit whose permanent data is held in one or more datafiles. Making it read-only prevents modifications to its stored data. Queries can continue to read that data when the tablespace is online, while applications continue updating other writable tablespaces.

Read-only and offline describe different properties. Read-only controls whether stored data can change; offline controls availability. You do not need to take an eligible tablespace offline merely to make it read-only. Similarly, returning a tablespace to read-write is a different operation from bringing an offline tablespace online.

Read-only status is useful for settled historical data, but it is not a substitute for backup isolation or an immutable retention policy. The original files still reside on storage that can fail. An administrator can also change the tablespace's status. Design protection around the loss of the original storage, rather than assuming that the absence of application updates guarantees preservation.

Complete the Transition Before Taking the Baseline

Use ALTER TABLESPACE to change the tablespace's write status. In this example, RO_SAMPLE belongs to a pluggable database, or PDB. Run the SQL in that owning PDB with the appropriate privileges:

ALTER TABLESPACE RO_SAMPLE READ ONLY;

SELECT tablespace_name, status
FROM dba_tablespaces
WHERE tablespace_name = 'RO_SAMPLE';

After the operation succeeds, the query should report READ ONLY. The tablespace must be online and eligible for the transition. SYSTEM, an active undo tablespace, and temporary tablespaces cannot be converted this way. The tablespace must also not be in user-managed online backup mode.

The command can wait for relevant existing transactions to finish. Schedule the transition with application activity in mind, and distinguish a command that is still waiting from one that has completed. Oracle describes these prerequisites and transaction behavior in Managing Tablespaces.

Take the baseline after the read-only transition completes. This gives the backup a clear operational meaning: it captures the tablespace after the final writable activity for that period. Record the tablespace, owning PDB, backup location, and date so the retained copy can be identified later.

Back Up the Tablespace with RMAN

Recovery Manager, or RMAN, can back up the datafiles belonging to a read-only tablespace. The following example assumes that RMAN is independently connected to the same PDB that owns RO_SAMPLE, with suitable backup privileges and a configured destination and channels:

BACKUP AS BACKUPSET TABLESPACE RO_SAMPLE
  TAG 'RO_SAMPLE_READ_ONLY' FORCE;

LIST BACKUP OF TABLESPACE RO_SAMPLE;

RESTORE TABLESPACE RO_SAMPLE VALIDATE;

The first command creates a backup set. FORCE bypasses backup optimization for the specified files, making the request for a fresh baseline explicit. The tag helps identify its purpose; it does not prevent the backup from becoming obsolete or being deleted. The listing and validation commands perform different checks, explained below.

Connection scope is essential. An unqualified TABLESPACE RO_SAMPLE in a root RMAN connection refers to a root tablespace. Switching a separate SQL session into a PDB does not change the RMAN connection. Oracle documents these distinctions in the BACKUP command reference.

RMAN also supports image copies where appropriate. Both formats protect datafiles, but they have different physical representations and restore procedures. Choose the format that fits the established recovery strategy. This tablespace-level backup complements the backups of the rest of the database; it does not replace them.

Do not surround this RMAN procedure with BEGIN BACKUP and END BACKUP. Those commands belong to a different, user-managed backup workflow. A direct file copy of read-only datafiles can be useful in a specialized procedure, but RMAN provides backup tracking and validation facilities that should remain central to this lesson's approach.

Understand What RMAN Includes or Skips

RMAN does not automatically exclude every read-only tablespace. Read-only datafiles are eligible for ordinary database backups. What a particular job includes depends on its scope, command options, configuration, and optimization decisions.

For example, the following CDB-root RMAN command explicitly skips read-only datafiles:

BACKUP DATABASE SKIP READONLY;

Use this only within a strategy that already protects the omitted data. It does not establish that a skipped tablespace has a usable backup. A successful job can therefore leave a protection gap if its exclusions are poorly designed.

Backup optimization is a separate policy choice. An administrator can enable it from an appropriate CDB-root RMAN connection:

CONFIGURE BACKUP OPTIMIZATION ON;

This changes persistent configuration. Optimization considers criteria such as file identity, existing backups, device type, and retention requirements. It does not mean that an unchanged file will never be backed up again. For example, SBT recovery-window rules can require a newer backup even when the file contents have not changed. See Oracle's backup optimization and skipping guidance.

Why the Backup Can Remain Useful as Other Files Change

The completed transition establishes a read-only state for the tablespace's datafiles. A checkpoint coordinates the writing of relevant modified buffers and records recovery progress. The Database Writer processes write modified blocks from the buffer cache to datafiles as part of normal database operation.

A System Change Number, or SCN, is an internal logical ordering value used for consistency and recovery. It is not simply a wall-clock timestamp. The second diagram uses small illustrative checkpoint SCNs to distinguish the history of the unchanged files from that of the writable files.

In the illustration, RO_SAMPLE stays at checkpoint SCN 73 while writable datafiles advance from 74 to 80. Its older checkpoint does not by itself make the retained backup unusable. Because the read-only contents have not changed, a suitable backup can continue supplying those contents during a later restore.

This does not freeze SYSTEM or the whole database at SCN 73. Other tablespaces continue processing changes, and their backup and redo requirements continue. The control file tracks database structure and file status so recovery can interpret the files in context.

The practical benefit is reduced duplicate work. A later backup job can concentrate on changed data under an appropriate policy while the retained RO_SAMPLE baseline remains part of the recovery plan. The age of that baseline is not, by itself, evidence that its unchanged contents are obsolete.

Distinguish Restoration from Recovery

Restoration puts backed-up file contents back on storage. Recovery applies the changes needed to reach the required consistent state. A suitable backup made after the read-only transition can avoid the need to replay later changes to those unchanged contents. That benefit should not be generalized to every backup or recovery target.

Consider three cases:

• The backup was taken after the transition and the tablespace stayed read-only. Its unchanged contents can remain suitable for a later restore, subject to the database's recovery context.
• The backup predates the transition. It may need redo to incorporate changes made before the tablespace became read-only.
• The tablespace later became writable. The old baseline alone does not contain the subsequent changes, even if the tablespace was made read-only again before the failure.

Point-in-time recovery adds another condition: a later backup is not automatically suitable for an earlier target. Backup selection must account for the requested time, database incarnation, available redo, and metadata. Avoid choosing a backup solely because its tablespace is read-only now.

A missing read-only tablespace makes its data unavailable. It does not justify a universal statement that the entire database can never open. Oracle supports recovery plans that defer selected tablespaces and restore their availability later. The exact procedure depends on the scenario, as described in Performing Complete Database Recovery.

Protect the Backup and the Information Needed to Use It

A backup on the same failed storage as its source cannot provide useful protection from that failure. Retain independent copies with suitable separation from production storage and administration. Review the actual recovery path: where the copy resides, how it will be accessed, and whether the required storage or media service will be available.

Coordinate RMAN retention with external storage lifecycle rules. A storage platform or media manager can expire a backup independently of whether you still need its contents. Conversely, a physically present file may be difficult to select if its repository information has been lost. Document and verify both sides.

Protect the CDB's control file and server parameter file, or SPFILE, as part of the wider strategy. From an appropriate CDB-root RMAN connection, these commands illustrate three separate administrative actions:

SHOW ALL;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

BACKUP CURRENT CONTROLFILE;

SHOW ALL inspects configuration. The CONFIGURE command enables ongoing control-file autobackups; these also include the SPFILE when the instance uses one. The final command explicitly backs up the current control file. These CDB-level actions are separate from the earlier PDB-scoped tablespace backup.

Keep RMAN repository information usable, including the recovery catalog when one is employed. Preserve the encryption keys, passwords, and credentials required by the chosen backup configuration. A correctly retained encrypted backup still cannot be restored without its required decryption material. See Configuring the RMAN Environment.

If recovery reveals a metadata mismatch, investigate the available control files, repository records, and documented recovery options. Recreating the control file is not an automatic response to every read-only status problem.

Verify Recoverability Periodically

Read-only status reduces content changes, but it does not test the backup medium. Use checks that answer distinct questions:

The earlier RESTORE TABLESPACE RO_SAMPLE VALIDATE command lets RMAN choose applicable backups. It does not establish that every historical or secondary copy was examined. Include the copies and recovery targets you actually depend on in your verification schedule. Oracle explains the validation behavior in Validating Database Files and Backups.

Refresh or replace copies when media condition, storage migration, or policy requires it. “No repeated backup of unchanged data” describes a content-level optimization, not permission to ignore the retained copy indefinitely.

Resume Normal Backups When the Tablespace Becomes Writable

To permit changes again, run the following SQL in the PDB that owns RO_SAMPLE, with the tablespace and its datafiles online:

ALTER TABLESPACE RO_SAMPLE READ WRITE;

Once the operation completes, resume the normal backup schedule and applicable redo protection. Review persistent tablespace exclusions: an exclusion based on the tablespace's name may continue to omit it even after its write status changes.

If new data is loaded and the tablespace later returns to read-only, create and validate a new post-transition baseline. Keep older backups when earlier recovery targets still require them. The latest baseline describes the latest settled contents; it does not replace every historical recovery point.

Read-Only Tablespace Backup Guidelines

• Back up the tablespace after its read-only transition completes.
• Reduce redundant copying through a deliberate RMAN strategy, not an assumption that read-only files are automatically omitted.
• Retain usable copies and the metadata, keys, and credentials required to restore them.
• Validate backups and test representative recovery scenarios.
• Resume normal protection when the tablespace becomes read-write.

The key principle is that unchanged data can reuse a suitable backup while the backup itself continues to require protection. The next lesson concludes this module.

Read Only Backups - Quiz

Review why read-only data still needs backups and how backup selection, retention, and recovery conditions affect its protection.

Read Only Backups - Quiz