Creating Storage Snapshots of Oracle 19c/26ai Multitenant Databases on Everpure FlashArray

Purpose

This knowledge base (KB) describes the recommended, supportable procedure for creating crash‑consistent storage snapshots of Oracle multitenant (CDB/PDB) databases on Linux that use traditional filesystems (XFS/ext4) backed by Everpure FlashArray volumes.

It documents the preferred snapshot and clone workflows for Oracle 19c and Oracle Database 26ai CDBs with one or more PDBs, assuming one protection group per CDB and archivelog mode enabled.

For single‑instance non‑CDB databases on filesystems, see Creating Storage Snapshots of Oracle Single‑Instance Databases on Filesystems Using Everpure FlashArray.

A full restore procedure is provided in the companion KB- Restoring Storage Snapshots of Oracle Databases on Filesystem Using Everpure FlashArray.

Scope and Assumptions

Target Audience

Oracle DBAs managing 19c/26ai multitenant CDB/PDB deployments
Storage administrators managing Everpure FlashArray systems
Platform engineers responsible for Linux‑based database stacks

Assumptions

Oracle CDB is running on Linux in ARCHIVELOG mode
Database files (data, redo, FRA, control) live on XFS/ext4 filesystems backed by Everpure FlashArray volumes
All CDB‑related volumes are members of a single FlashArray protection group
SYSDBA access is available from the database host

Out of Scope

Non‑CDB databases
ASM‑based databases
Oracle RAC (including RAC CDBs)

Architecture Overview

CDB Is the Unit of Physical Protection

A FlashArray protection group snapshot always captures complete volumes — meaning it captures all containers whose datafiles reside on those volumes: CDB$ROOT, PDB$SEED, and every user PDB in that CDB. There is no way to physically snapshot "just one PDB" at the storage layer. You cannot restore a single PDB to a different point in time from the same FlashArray CDB snapshot without recovering the entire CDB to that point. This CDB‑wide behavior is the fundamental constraint when combining Oracle multitenant with storage‑level snapshots.

Multitenant-Specific Considerations

PDB State at Snapshot Time

All PDBs should ideally be in READ WRITE mode and not in the middle of a maintenance operation (PDB plug/unplug, ALTER PLUGGABLE DATABASE structural changes) at snapshot time. Before snapping:

-- Verify all PDBs are open READ WRITE
SELECT NAME, OPEN_MODE FROM V$PDBS;

If any PDB is in MOUNTED or RESTRICTED mode, note it — those containers will require additional recovery steps after restore.

CDB-Wide vs Per-PDB Recovery

A FlashArray snapshot gives the same SCN boundary to all PDBs in the CDB. The recovery scope options are:

Recovery need	Method
Full CDB DR (all PDBs)	Restore all volumes from pgroup snapshot, start CDB
Single PDB to snapshot point	Use Oracle PDB Snapshot Carousel* or PDB archive + plugin
Single PDB PITR beyond snapshot	RMAN restore CDB + roll forward with archivelogs + PDB flashback
Dev/test clone of all PDBs	Clone pgroup snapshot to new volumes, attach to test host
Dev/test clone of one PDB	Use Oracle snapshot carousel clone (CREATE PLUGGABLE DATABASE … USING SNAPSHOT)

This means for full tenant-level recovery flexibility, you need both storage snapshots (for coarse-grained DR) and Oracle-native PDB snapshots (for fine-grained, per-tenant point-in-time recovery).

Oracle offers the PDB Snapshot Carousel feature, which maintains a library of per‑PDB snapshots for point‑in‑time recovery and cloning. This feature is only enabled and supported on Oracle Database Enterprise Edition running on engineered systems and specific Oracle cloud/ODA services, but is not available on generic x86 on‑premises deployments.

Protection Group Design

For a 19c and 26ai CDB with multiple PDBs, the recommended FlashArray layout is one protection group per CDB, containing all volumes that hold any part of that CDB:

Volume Purpose	Example Volume Name	Must Be in pgroup?
Datafiles	orcl26-data	Yes
Redo / Archivelogs	orcl26-logs	Yes
Control files (if separate)	orcl26-ctrl	Yes

Never mix different CDBs in the same protection group. If you restore or clone from a pgroup snapshot, all PDBs in that CDB come along — mixing CDBs means you cannot recover them independently.

For multiple CDBs (e.g., prod1-cdb, prod2-cdb), create a separate protection group for each:

purepgroup create pg-orcl26-prod1
purevol add orcl26-p1-data orcl26-p1-logs --pgroup pg-orcl26-prod1

# Optionally create the protection group and add volumes in the same command
purepgroup create --vollist orcl26-p2-data orcl26-p2-logs pg-orcl26-prod2

Snapshot Consistency Models

Crash-Consistent

FlashArray protection group snapshots for multitenant CDBs are crash‑consistent by design. The database will perform instance recovery on restore, just as after a power loss.

For per‑PDB application‑consistent recovery and PITR, use Oracle features such as RMAN‑based PDB point‑in‑time recovery (PDB PITR) in combination with storage snapshots, rather than PDB Snapshot Carousel on generic x86 platforms.

Mode	Snapshot Type	Recoverable?	Use Case	Recommend?
ARCHIVELOG	Crash-consistent	Yes (CDB-wide)	DR, dev/test CDB clones	Yes
ARCHIVELOG	App-consistent via RMAN (PDB PITR, etc.)	Yes (CDB/PDB)	PDB-level PITR, compliance	Yes (Oracle-side)

Crash-Consistent Is the FlashArray Default

FlashArray protection group (pgroup) snapshots are crash-consistent: all volumes in the group are snapped atomically at the array level, producing a consistent point-in-time image across all volumes — equivalent to a controlled power cut. Oracle 12.2 and later (including 19c and 26ai) fully supports crash-consistent storage snapshots without requiring hot backup mode, as long as the database is in ARCHIVELOG mode.

When a crash-consistent snapshot is restored or cloned, Oracle performs automatic instance recovery (crash recovery) on startup, rolling forward committed changes from the redo logs and rolling back uncommitted transactions. This is safe and well-tested.

High‑Level Workflow (Multitenant CDB)

Identify all volumes/filesystems used by the CDB (data, redo, FRA, control).
Verify the CDB and all PDBs are in a consistent state (no maintenance operations in progress).
From CDB$ROOT, force a checkpoint and archive log switch to flush changes and bound the recovery point.
Take a protection group snapshot of all CDB volumes on Everpure FlashArray.
Optionally replicate or clone the snapshot for DR or dev/test.
Log the snapshot name, SCN, and timestamp for future recovery.

Procedure: Application-Consistent Snapshot

Oracle PDB Snapshot Carousel

On generic x86 platforms where PDB Snapshot Carousel is not available, application‑consistent, per‑PDB recovery is achieved with RMAN PDB point‑in‑time recovery (PDB PITR), not with storage quiesce of a single PDB. RMAN can recover an individual PDB to an SCN or timestamp without affecting other PDBs in the CDB, assuming appropriate ARCHIVELOG backups are available.

This KB focuses on storage‑level snapshots and how to integrate them into your backup and cloning processes, for multitenant database environments crash-consistent snapshots at the CDB level are the best practice. Oracle‑level RMAN PDB PITR procedures are documented separately.

Procedure: Crash-Consistent

Crash‑Consistent Snapshot with Pre‑Snapshot Coordination

Although crash-consistent snapshots are valid, coordinating the snapshot with Oracle reduces recovery time and eliminates ambiguity about the SCN boundary. The recommended pre-snapshot sequence for a 26ai CDB is:

Step 1: Verify CDB and PDB state:

-- Connect to CDB root as SYSDBA
sqlplus / as sysdba


-- Confirm we are in CDB root
SHOW CON_NAME;  -- CDB$ROOT


-- Check PDB open modes
SELECT NAME, OPEN_MODE FROM V$PDBS;

Step 2: Coordinate database IO:

-- Force a checkpoint to flush dirty buffers to disk
ALTER SYSTEM CHECKPOINT;


-- Switch and archive the current redo log (captures all committed work)
ALTER SYSTEM ARCHIVE LOG CURRENT;


-- Optionally record the SCN for documentation
SELECT CURRENT_SCN, TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS') SNAP_TIME
FROM V$DATABASE;

Step 3: Create FlashArray protection group snapshot:

purepgroup snap --suffix '${ENV}-${DB_NAME}-CRASHCONS-$(date +%F_%H%M%S)-${CHANGE_ID}' pg-orcl26-prod1

Snapshot Naming Convention Recommended format:

<ENV>-<DB_NAME>-CRASHCONS-<YYYY-MM-DD-HHMMSS>-<CHANGE_ID>

Example:

prod-orcl26-CRASHCONS-2026-03-17-142530-chg1234

Recording the SCN and timestamp at snapshot time is critical for PITR recovery using RECOVER DATABASE SNAPSHOT TIME later if needed.

Do not record the snapshot as “complete” until the array reports successful snapshot creation.

Verification

Confirm snapshot is present in the pgroup
Optionally query the database again to ensure it remains open and healthy
Log snapshot name, SCN, timestamp, and log sequence

On FlashArray:

Everpure GUI: Storage → Protection Groups → Snapshots
Everpure CLI:
```
purepgroup list --snap pg-orcl26-prod1
```

Confirm the database state:

SELECT open_mode, log_mode FROM v$database;
SELECT name, open_mode FROM v$pdbs;

Guidance

AWR in 26ai Multitenant

In Oracle 26ai, AWR supports both CDB-level and PDB-level snapshots. By default, CDB-level AWR snapshots are automatic and PDB-level snapshots can be configured independently per PDB. When you create a clone of a CDB from a FlashArray snapshot, the clone will contain its own AWR data present at the time of the snapshot.

To avoid confusion:

Rename the clone CDB immediately after attach (NID utility or ALTER DATABASE RENAME)
Distinguish production vs clone AWR reports using DBID — the clone inherits the source DBID until renamed

TDE and Keystore Considerations

If the keystore is not available or not opened correctly on the clone, encrypted PDB datafiles will not be readable even though the storage snapshot itself is valid.

Dev/Test Clone Workflow

The most common use case for FlashArray snapshots in a multitenant environment is rapid dev/test provisioning. The workflow is:

Step 1: Take a pgroup snapshot on the production array

# Pre-script: coordinate with Oracle
sqlplus / as sysdba <<EOF
ALTER SYSTEM CHECKPOINT;
ALTER SYSTEM ARCHIVE LOG CURRENT;
SELECT CURRENT_SCN FROM V$DATABASE;
EXIT;
EOF


# Take the snapshot
purepgroup snap --suffix ${ENV}-${DB_NAME}-CRASHCONS-$(date +%F_%H%M%S)-${CHANGE_ID} orcl26-prod1-pg


# Confirm
purepgroup list --snap orcl26-prod1-pg --limit 3

Step 2: Clone the snapshot volumes to the test host

# Clone each volume from the snapshot to new volumes for the dev host
purevol copy orcl26-prod1-pg.devclone-20260324.orcl26-p1-data orcl26-dev1-data
purevol copy orcl26-prod1-pg.devclone-20260324.orcl26-p1-logs  orcl26-dev1-logs


# Connect the new volumes to the dev host
purehost connect --vol orcl26-dev1-data devhost01
purehost connect --vol orcl26-dev1-logs  devhost01

Step 3: On the dev host — prepare and open the clone CDB

# Rescan multipath
multipath -r
ls -l /dev/mapper/   # verify new LUNs appear


# Mount filesystems (adjust device names to your multipath aliases)
mount /dev/mapper/orcl26-dev1-data /u02/oradata
mount /dev/mapper/orcl26-dev1-logs  /u03/logs

Then in SQL:

-- Start with a different SID to avoid conflict with production
export ORACLE_SID=orcl26dev
sqlplus / as sysdba


STARTUP MOUNT;
-- Oracle performs crash recovery automatically


-- Rename DB_UNIQUE_NAME to avoid Data Guard / listener conflicts
ALTER SYSTEM SET DB_UNIQUE_NAME='orcl26dev' SCOPE=SPFILE;


ALTER DATABASE OPEN RESETLOGS;


-- Open all PDBs
ALTER PLUGGABLE DATABASE ALL OPEN;


-- Verify
SELECT NAME, OPEN_MODE FROM V$PDBS;

Step 4: Adjust services for each PDB

After opening, update or drop production service names on the clone so they do not conflict with production listeners:

-- Connect into each PDB and update services
ALTER SESSION SET CONTAINER=pdb1;
EXEC DBMS_SERVICE.DELETE_SERVICE('prod_svc');
EXEC DBMS_SERVICE.CREATE_SERVICE('dev_pdb1_svc','dev_pdb1_svc');
EXEC DBMS_SERVICE.START_SERVICE('dev_pdb1_svc');

Snapshot Schedule Recommendations

For a 19c or 26ai CDB hosting multiple production PDBs on FlashArray consider using the following as a starting point; tune snapshot frequency and retention based on your strictest tenant RPO/RTO and compliance requirements.

Policy	Recommended Setting
pgroup snapshot frequency	Every 1–4 hours (based on tenant RPO)
Local snapshot retention	7–14 days
Remote replication (ActiveDR / async)	Replicate pgroup to DR site for off-array copies
SafeMode eradication timer	≥ 24 hours (72 hours recommended)
Oracle PDB Snapshot Carousel	24-hour interval, 7–14 snapshots per critical PDB
Pre-snapshot Oracle script	ALTER SYSTEM CHECKPOINT + ALTER SYSTEM ARCHIVE LOG CURRENT
Snapshot SCN logging	Log SCN + timestamp to a table or external file for PITR reference

Summary of Layered Protection Model

For a well-protected Oracle 19c and 26ai multitenant environment on FlashArray, the recommended model combines three layers:

FlashArray pgroup snapshots — crash-consistent, whole-CDB, array-level protection; primary tool for DR and dev/test cloning
Oracle PDB Snapshot Carousel — Oracle-managed, per-PDB logical snapshots; primary tool for tenant-level PITR and fast PDB cloning without storage involvement
RMAN backups — traditional backup to FRA or tape/cloud; required for long-term retention, offsite copies, and block-level validation