Physical File Placement in Oracle AI Database 26ai

Separate Naming, Storage Management, and Recovery

These components can be combined, but they are not interchangeable. OMF works with supported file systems as well as ASM. An FRA can be located on a file system or in an ASM disk group. A directory convention does not provide redundancy, and a mirrored live file does not supply the history needed to reverse an unwanted database change.

Identify Actual Failure Domains

A failure domain is a collection of resources that can become unavailable because of the same event. Two files on separate physical devices may survive the loss of either device, but both can still depend on one controller or storage enclosure. Protection must be evaluated against the failures the system is intended to tolerate.

Different pathnames do not demonstrate independence. Linux mount points, Windows drive letters, logical volumes, LUNs, and ASM disk groups can share underlying hardware. For example, placing one redo member on drive D: and another on drive E: does not protect against an array outage if both volumes come from that array.

Record the mapping from database destinations to their storage resources. Include important shared dependencies and the protection supplied by the storage platform. For cloud storage, use the service's documented durability and availability characteristics rather than assuming that different volume names imply different failure coverage.

This mapping should also describe backup access. A backup stored elsewhere but reachable only through a failed host, unavailable credential, or missing encryption key may not meet the recovery objective. File placement becomes a recovery design when those dependencies are considered alongside the locations of the database files.

Using ASM and Oracle Managed Files

ASM manages database storage in disk groups. Its failure groups identify disks that share failure characteristics, allowing mirrored copies to be distributed appropriately. Naming a disk group +DATA or +FRA communicates its intended role to administrators, but the name itself supplies no protection.

Normal redundancy generally uses two-way mirroring, while high redundancy generally uses three-way mirroring. External redundancy relies on protection provided by the underlying storage system. The supported configuration, available capacity, and failure-group design determine the practical protection. Adding multiple mirroring layers should be a deliberate decision rather than an automatic assumption that more layers are always better.

OMF reduces the need to invent and maintain individual filenames. You configure suitable creation destinations, and Oracle generates names for managed files. The resulting names may contain identifiers that differ between databases and creation operations. Query the actual database instead of copying numeric ASM filenames from an example.

Destination parameters guide file creation. Changing a default destination does not relocate existing datafiles, control files, or redo members. Moving existing files is a separate administrative operation that must account for the file type and database state.

An Illustrative ASM Layout

This is one possible arrangement, not a minimum hardware specification. Some systems use additional destinations for performance or availability reasons. Others use a different supported design. The important question is whether the arrangement provides the intended protection and can meet the workload and recovery requirements.

Understanding OMF Destination Parameters

The following fragment illustrates creation destinations. It is a planning example, not executable SQL or a complete parameter file. It assumes suitable ASM disk groups already exist and that an appropriate DB_RECOVERY_FILE_DEST_SIZE has been calculated and configured.

DB_CREATE_FILE_DEST         = '+DATA'
DB_CREATE_ONLINE_LOG_DEST_1  = '+DATA'
DB_CREATE_ONLINE_LOG_DEST_2  = '+FRA'
DB_RECOVERY_FILE_DEST       = '+FRA'

For managed control-file and redo creation, DB_CREATE_ONLINE_LOG_DEST_n takes precedence over the fallback data and recovery destinations. If these online-log destinations are absent, setting both the data and recovery destinations can produce copies in both locations under the documented creation rules. Explicit file specifications and CONTROL_FILES also affect the result.

Do not infer the final layout from parameter names alone. After creation, inspect the actual control files and redo members. A disk group called +FRA becomes the recovery-area destination because it is configured for that role, not because Oracle assigns special meaning to its name.

Protect Control Files and Online Redo

Oracle strongly recommends at least two control-file copies on separate storage. This is a protection recommendation: database creation can produce only one copy. For a CDB, the control-file set describes the database as a whole, including its PDBs; each PDB does not have an independent set of ordinary database control files.

Control-file multiplexing improves recoverability, but does not guarantee uninterrupted operation. Losing a configured copy can make the instance inoperable even if another current copy survives. The surviving copy can help repair the configuration and restart without restoring an older control file. Account for this behavior when placing a live copy in a recovery disk group.

Online redo requires a different distinction: members within a group are redundant copies; separate groups are successive parts of the redo cycle. Creating more groups with one member each does not provide the same protection as maintaining multiple members within each group.

Place members according to the failures they should survive. One inaccessible member does not necessarily mean that the redo is lost when another usable member remains. Permanent loss of every copy of required redo is a more serious recovery problem. Placement should reduce that exposure before a failure occurs.

Organizing File-System Installations

Plan the Fast Recovery Area as a Managed Resource

The FRA can contain archived redo, flashback logs, RMAN disk backups, and control-file autobackups. It can also contain permanent live files, including current control-file copies and online redo members. These file categories have different lifetimes and different consequences when storage becomes unavailable.

Using the FRA is not a requirement to place every backup or archived log there. Recovery designs may use other disk destinations, media-management systems, or supported remote backup services. An FRA on the same storage system as the datafiles should not be treated as protection against failure of that entire system.

DB_RECOVERY_FILE_DEST_SIZE sets a recovery-area quota. It does not allocate physical disks or guarantee that the underlying storage has the same amount of free space. Monitor both the Oracle-managed quota and the capacity of the file system or ASM disk group that contains it.

Size the area using measured redo generation, backup volume, retention requirements, flashback usage, and operational headroom. Guaranteed restore points can retain flashback logs. Files that remain necessary are not automatically expendable simply because the area is nearly full. Recovery-area management can reclaim eligible files, but it cannot guarantee that space exhaustion will never occur.

Copying an arbitrary file into a directory beneath the FRA does not make it an Oracle-managed recovery file. Preserve the distinction between physical location and Oracle's knowledge of the file. Backup inventory, deletion eligibility, and retention policy require more than a directory listing.

Match Placement to the Workload

Keep the Multitenant File Inventory Accurate

Root, seed, and application PDB datafiles form part of the CDB storage inventory. Use application tablespaces for application segments rather than SYSTEM or SYSAUX. Automatic undo management and appropriate temporary tablespaces replace the old practice of designing a disk checklist around manually managed rollback segments.

PDB undo arrangements depend on undo mode, so a sample containing a single UNDOTBS1 file is not a complete description of every CDB. Generated PDB file paths can also include identifiers. Discover those paths rather than assuming that they always use the PDB name as a directory component.

Oracle's 26ai Upgrade Guide documents a bigfile-default change for SYSTEM, SYSAUX, and user tablespaces. A default for new creation is not evidence that an existing tablespace has been converted. Inspect the actual tablespace type and creation choices. Vector or JSON data likewise does not automatically require a specially named tablespace or disk group.

Verify the Layout with Read-Only Queries

Use these inventory examples from an authorized session in the intended CDB root. Privileges and container visibility affect results. The returned paths describe logical file locations; storage documentation is still needed to establish hardware independence.

Current Control Files and Redo Members

SELECT name FROM v$controlfile;

SELECT group#, type, member, status
FROM v$logfile
ORDER BY group#, member;

Check that the expected copies exist and map to the intended destinations. The member type also helps distinguish online redo from standby redo in configurations that contain both. A filename alone does not establish that a member is healthy or independently protected.

Datafiles and Tempfiles

SELECT con_id, file#, name
FROM v$datafile
ORDER BY con_id, file#;

SELECT con_id, file#, name
FROM v$tempfile
ORDER BY con_id, file#;

Retain the container identifiers in your inventory. They help avoid overlooking files belonging to the seed or another PDB. Review the inventory after database creation, PDB provisioning, and planned file-location changes.

Recovery-Area Usage

SELECT name, space_limit, space_used,
       space_reclaimable, number_of_files
FROM v$recovery_file_dest;

The space columns report bytes. Compare usage with the configured limit and with actual storage capacity. Reclaimable space reflects Oracle's management rules; it is not an instruction to delete arbitrary files manually. Examine growth across representative workload and backup periods.

Tablespace Types

Run this query within the container whose tablespaces you want to inspect:

SELECT tablespace_name, contents, bigfile
FROM dba_tablespaces
ORDER BY tablespace_name;

The results distinguish permanent, temporary, and undo tablespaces and show the actual bigfile setting. They support inventory and planning without changing storage or relocating files.

Turn the Layout into a Maintainable Recovery Plan

Document why each destination exists, which files depend on it, and which failures it can survive. Keep the inventory synchronized with provisioning and storage changes. Include backup locations, access requirements, and the information needed to recover encrypted data. Review restore procedures as part of the design, not only after an outage.

Managed database services may expose capacity, performance, and backup controls while hiding individual physical filenames. Apply the same questions to the controls available: what protection is provided, what must the customer configure, and how is recovery verified? Administrative access and capabilities differ between service models.

A maintainable layout connects naming, measured I/O requirements, documented failure protection, and accessible recovery information. The next lesson examines database states and structure.