Skip Headers
Oracle® Automatic Storage Management Administrator's Guide
12c Release 1 (12.1)

E41058-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Introducing Oracle ACFS and Oracle ADVM

This chapter describes the components of Oracle Cloud File System (Oracle CloudFS): Oracle Automatic Storage Management Cluster File System (Oracle ACFS) and Oracle ASM Dynamic Volume Manager (Oracle ADVM).

This chapter provides concepts and an overview of Oracle ACFS and Oracle ADVM features with the following topics:

See Also:

Overview of Oracle ACFS

Oracle Automatic Storage Management Cluster File System (Oracle ACFS) is a multi-platform, scalable file system, and storage management technology that extends Oracle Automatic Storage Management (Oracle ASM) functionality to support all customer files. Oracle ACFS supports Oracle Database files and application files, including executables, database data files, database trace files, database alert logs, application reports, BFILEs, and configuration files. Other supported files are video, audio, text, images, engineering drawings, and other general-purpose application file data. Oracle ACFS conforms to POSIX standards for Linux and UNIX, and to Windows standards for Windows.

An Oracle ACFS file system communicates with Oracle ASM and is configured with Oracle ASM storage, as shown in Figure 11-1. Oracle ACFS leverages Oracle ASM functionality that enables:

  • Oracle ACFS dynamic file system resizing

  • Maximized performance through direct access to Oracle ASM disk group storage

  • Balanced distribution of Oracle ACFS across Oracle ASM disk group storage for increased I/O parallelism

  • Data reliability through Oracle ASM mirroring protection mechanisms

Figure 11-1 Oracle Automatic Storage Management Storage Layers

Description of Figure 11-1 follows
Description of "Figure 11-1 Oracle Automatic Storage Management Storage Layers"

Oracle ACFS establishes and maintains communication with the Oracle ASM instance to participate in Oracle ASM state transitions including Oracle ASM instance and disk group status updates and disk group rebalancing. Oracle Automatic Storage Management with Oracle ACFS and Oracle ASM Dynamic Volume Manager (Oracle ADVM) delivers support for all customer data and presents a common set of Oracle storage management tools and services across multiple vendor platforms and operating system environments on both Oracle Restart (standalone) and cluster configurations. For an overview of Oracle ADVM, see "Overview of Oracle ASM Dynamic Volume Manager".

Oracle ACFS is tightly coupled with Oracle Clusterware technology, participating directly in Clusterware cluster membership state transitions and in Oracle Clusterware resource-based high availability (HA) management. In addition, Oracle installation, configuration, verification, and management tools have been updated to support Oracle ACFS.

Oracle ACFS can be accessed and managed using native operating system file system tools and standard application programming interfaces (APIs). Oracle ACFS can also be managed with Oracle ASM Configuration Assistant. In some cases, Oracle ACFS can be accessed using industry standard Network Attached Storage (NAS) File Access Protocols: Network File System (NFS) and Common Internet File System (CIFS). However, CIFS clients on Windows cannot use ACLs when interfacing with Oracle ACFS Linux, Solaris, or AIX servers, but can interface with Oracle ACFS on Windows.

In addition to sharing file data, Oracle ACFS provides additional storage management services including support for the Oracle Grid Infrastructure clusterwide mount registry, dynamic on-line file system resizing, and multiple space-efficient snapshots for each file system. For information about the mount registry, see "About the Oracle ACFS Mount Registry".

Oracle ACFS contributes to the overall Oracle storage management by providing:

  • A general-purpose standalone server and cluster file system solution that is integrated with Oracle ASM and Oracle Clusterware technologies

  • A common set of file system features across multiple vendor platforms and operating systems, offering an alternative to native operating system or third-party file system solutions

  • Standalone and clusterwide shared Oracle Database homes, all Oracle Database files, and application data

  • Uniform, coherent shared file access and clusterwide naming of all customer application files

Oracle ACFS accommodates large storage capacities and large numbers of cluster nodes. It efficiently manages large numbers of file systems, files, and supports both small and large sized files with exabyte-capable file and file system capacities. Oracle ACFS provides optimized fast directory lookup for large directories with millions of files.

Oracle ACFS file systems are generally mounted on all Oracle Cluster Synchronization Services (CSS) cluster members. In the event of a member failure, another cluster member quickly recovers any outstanding metadata transactions on behalf of the failed member. Following recovery, access by other active cluster members and any remote client systems can resume.

The following list provides important information about Oracle ACFS:

  • For all applications, Oracle ACFS performance is best with larger write() sizes, such as 8 K or larger.

  • For best performance, use the Deadline I/O Scheduler for the disks in the disk group on a Linux system.

  • When creating Oracle ACFS file systems on Windows, log on as a Windows domain user. Also, when creating files in an Oracle ACFS file system on Windows, you should be logged in as a Windows domain user to ensure that the files are accessible by all nodes.

    When using a file system across cluster nodes, the best practice is to mount the file system using a domain user, to ensure that the security identifier is the same across cluster nodes. Windows security identifiers, which are used in defining access rights to files and directories, use information which identifies the user. Local users are only known in the context of the local node. Oracle ACFS uses this information during the first file system mount to set the default access rights to the file system.

    Refer to the Oracle Database Installation Guide for the Windows platform for information about Oracle Base permissions when a file system is mounted under Oracle Base.

  • Oracle ACFS does not support any files associated with the management of Oracle ASM, such as files in the Oracle Grid Infrastructure home and in the Oracle ASM diagnostic directory.

  • Oracle ACFS does not support Oracle Cluster Registry (OCR) and voting files.

  • Oracle ACFS functionality requires that the disk group compatibility attributes for ASM and ADVM be set to 11.2 or higher. For information about disk group compatibility, refer to "Disk Group Compatibility".

  • To use an Oracle ACFS file system for an Oracle Database home, the release level must be Oracle 11g Release 2 (11.2) or later.

For information about managing and monitoring Oracle ACFS, refer to Chapter 16, "Managing Oracle ACFS with Command-Line Tools" and Chapter 12, "Using Views to Display Oracle ACFS Information".

Understanding Oracle ACFS Concepts

This section describes concepts for the key Oracle ACFS components and contains the following topics:

About Oracle ACFS

Oracle ACFS is designed as a general-purpose, standalone server and clusterwide file system that delivers support for all customer files. Users and applications can access and manage Oracle ACFS using native operating system file system application programming interfaces (APIs) and command-line interface (CLI) tools. Users can also manage Oracle ACFS with Oracle ASM Configuration Assistant (ASMCA).

Oracle ACFS supports large files with 64-bit file and file system data structure sizes leading to exabyte capable file and file system capacities on 64 bit platforms. Variable extent-based storage allocation and high-performance directories contribute to fast performance and shared disk configurations that provide direct storage paths to Oracle ACFS file data from each cluster member. File system integrity and fast recovery is achieved with Oracle ACFS metadata checksums and journaling. Oracle ACFS is designed as a multi-node, shared file system model that delivers coherent, cached, direct storage paths to Oracle ACFS file data from each cluster member.

Oracle ACFS files systems are typically configured for clusterwide access. File systems, files, and directories are visible and accessible from all cluster members and can be referenced by users and applications using the same path names from any cluster member. This design enables simplified application deployments across cluster members and facilitates both multiple instance cluster applications and high availability (HA) failover of unmodified standalone server applications.

Oracle ACFS presents single system file access semantics across cluster configurations. Applications and users on all cluster members are always presented with the same view of shared Oracle ACFS file data, supported by the Oracle ACFS clusterwide user and metadata cache coherency mechanism.

About the Oracle ACFS Mount Model and Namespace

Oracle ACFS is designed as a hierarchical file system containing files and subdirectories organized into a tree-structured namespace with files at the leaves. The namespace design is a single-file system naming model for both standalone server and cluster configurations. This design enables each cluster member to present shared files to cluster applications using the same path names, simplifying multi-node application and user access, and overall file system administration. The Oracle ACFS mount model also accommodates node local mounts and cluster node subset mounts in cluster configurations to accommodate additional customer requirements.

Oracle ACFS file systems should be Oracle Clusterware managed with Oracle Clusterware resources to ensure they are properly handled during Oracle Grid Infrastructure startup and shutdown. Each Oracle ACFS file system automatically has an Oracle ACFS file system resource, as well as an entry in the Oracle ACFS registry, if one of the following applies:

  • The file system is registered with acfsutil registry

  • The file system is created with srvctl add filesystem

For example, general purpose Oracle ACFS file systems can be automatically mounted or unmounted across the cluster with acfsutil registry or srvctl add filesystem and no further action is required. Alternatively, Oracle ACFS file systems which are used for database-related files must have explicit Oracle Clusterware dependencies on the database, set with SRVCTL or DBCA.

Also, you can use SRVCTL to configure additional advanced functionality, such as hosting members and server pools. root privileges are required when using acfsutil registry or srvctl add filesystem.

You can explicitly use the mount command. However, if the resource has been created, then the file system may be mounted.

With a primary emphasis on the support of application files, Oracle ACFS is not presently supported for use as the root or boot file system for an operating system. Otherwise, an Oracle ACFS file system may be mounted into the native operating system file system namespace using the mount command line tool.

About Oracle ACFS and Database Data Files

Oracle ACFS in Oracle Grid 12c Release 1 (12.1) supports all database files starting with Oracle Database 11g Release 2 (11.2.0.4), except for data files and redo logs in an Oracle Restart (standalone server) configuration. Oracle ACFS can be configured for use with the database particularly to leverage Oracle ACFS snapshots for database testing and development. To support database files, the COMPATIBLE.ADVM attribute must be set to 12.1 or higher for the disk group that contains the Oracle ACFS file system.

Support for database data files on Windows begins with Oracle Grid 12c Release 1 (12.1.0.2). For support of database files on Windows, the COMPATIBLE.ADVM attribute must be set to 12.1.0.2 or higher.

Support for database data files on Oracle Exadata (Linux) begins with Oracle Grid 12c Release 1 (12.1.0.2). However, Oracle ACFS does not currently have the ability to push database operations directly into storage.

Oracle ACFS additionally supports all database files for Oracle Database 10g Release 2 (10.2.0.4 and 10.2.0.5) on Oracle Exadata (Linux) storage only. For database file support with Oracle Database 10g Release 2 (10.2.0.4 and 10.2.0.5) on Oracle Exadata storage, the following conditions must be met:

  • When creating an Oracle Database with DBCA, you must set the REMOTE_LISTENER initialization parameter to your_scan_vip:1521 otherwise DBCA fails during the create process. For information about the REMOTE_LISTENER initialization parameter, refer to Oracle Database Reference.

  • You must modify all the start and stop dependencies of the database instance resources to ensure that the resources start when starting Oracle Clusterware. For information about resource dependencies, refer to Oracle Clusterware Administration and Deployment Guide.

The following list provides important information about using Oracle ACFS with database files:

  • Oracle ACFS support includes all file types supported by Oracle ASM. For a list of file types supported by Oracle ASM, refer to Table 5-1, "File types supported by Oracle ASM".

  • Oracle ACFS does not support data files or redo logs in an Oracle Restart configuration. Oracle ACFS does not support direct I/O in an Oracle Restart configuration.

  • When storing database data files on Oracle ACFS, you must set the FILESYSTEMIO_OPTIONS initialization parameter to setall; other settings are not supported. To achieve optimal performance with database data files, set ASM and ADVM compatibility attributes to 12.1 or higher for the disk group that contains the Oracle ADVM volume intended to hold the data files. For volumes created before 12.1.0.2, set the stripe columns to 1, or set the stripe columns to 8 and the stripe width to 1 MB. Volumes created while running 12.1.0.2 or higher already default to the high performance configuration (stripe columns = 8 and stripe width = 1 MB). For information about creating a volume, refer to "volcreate".

  • To obtain optimal database performance with snapshots, the snapshots must be created after the ADVM compatibility attribute is set to 12.1 or higher.

  • Use a 4 K or larger database block size and tablespace block size with Oracle ACFS for best performance.

  • If a data file is configured to automatically extend, then the size of the increments should be large enough to ensure that the extend operation occurs infrequently. Frequent automatic extends have a negative performance impact.

  • Running a workload in a snapshot reduces resources for the primary workload running on the base files because the storage is shared between the base file system and the snapshots. To run test scenarios in Oracle ACFS snapshots without impacting the primary workload, copy the file system and then run test workloads on snapshots created in the copied file system.

  • Using Oracle ACFS replication or encryption with database files on Oracle ACFS is not supported. For information about other replication options for database files on Oracle ACFS, refer to Oracle Data Guard Concepts and Administration and Oracle GoldenGate documentation. Oracle GoldenGate is an Oracle product sold independently of the Oracle Database. To encrypt database data files on Oracle ACFS, Oracle recommends Oracle Advanced Security. Oracle Advanced Security provides Transparent Data Encryption (TDE) to encrypt data files for entire tablespaces. For information about Transparent Data Encryption (TDE), refer to Oracle Database Advanced Security Guide.

About Oracle ACFS and Oracle Database Homes

You can use an Oracle ACFS file system for an Oracle Database home with Oracle 11g Release 2 (11.2) or later. The file system can be configured as any Oracle Database home, including a shared or non-shared Oracle Database home in Oracle RAC cluster configurations. However, there is no Oracle Clusterware resource support for non-shared (node local) Oracle Database homes.

After the Oracle ACFS file system is created, the Oracle ACFS-based database home mount point location can be selected as the Oracle Database home location by browsing to and then choosing the directory during the Oracle Universal Installer (OUI) Database Software installation.

When installing Oracle Software, there must be a separate Oracle base (ORACLE_BASE) associated with each operating system user. For example, there should be a separate Oracle base for a grid user and a database user.

See Also:

Oracle Database Installation Guide for information about Optimal Flexible Architecture (OFA) recommendations for Oracle base and home directories

You can locate the Oracle Database base (ORACLE_BASE for database) directory and home (ORACLE_HOME for database) directory on an Oracle ACFS file system. The Oracle Database base (ORACLE_BASE for database) directory should not be the Oracle Grid Infrastructure base (ORACLE_BASE for grid) directory or should not be located under the Oracle Grid Infrastructure base directory (ORACLE_BASE for grid).

The Oracle Grid Infrastructure base (ORACLE_BASE for grid) directory and home (ORACLE_HOME for grid) directory cannot be located on the Oracle ACFS file system because the Oracle ACFS file system cannot be created until Oracle Grid Infrastructure is installed.

One or more Oracle Database homes on Oracle ACFS can be created under the same mount point with each home using a separate Oracle ACFS file system.

After the installation of Grid Infrastructure Software and before the installation of the Oracle Database software with Oracle Universal Installer (OUI), you can create an Oracle ACFS file system to be configured for use as an Oracle Database home.

You can also use the Oracle ASM Configuration Assistant (ASMCA) or Oracle ACFS commands to create the file system. For information about using ASMCA, see "Creating an Oracle ACFS File System for Database Use". For information about using Oracle ACFS commands to create a file system, see Chapter 16, "Managing Oracle ACFS with Command-Line Tools".

Note:

When an Oracle ACFS file system contains an Oracle Database home or Oracle Database uses the file system for any file storage, the file system must have an Oracle ACFS file system resource. You must use Server Control Utility (SRVCTL) commands to set up Oracle Database dependencies. For information about SRVCTL, see Oracle Real Application Clusters Administration and Deployment Guide.

In an Oracle Grid Infrastructure clusterware configuration, run srvctl add filesystem to enable a file system to be automounted when an Oracle Database home is installed on the Oracle ACFS file system. That file system does not need to be added to the Oracle ACFS mount registry; if you register the file system a message informs you that it has been registered. The database owner must be specified with the -u option to allow that owner to mount and dismount the file system. Root privilege is required when using srvctl add filesystem to add a file system in Linux environments.

You can use the srvctl start filesystem command to manually mount the Oracle ACFS file system.

Oracle ACFS file systems can be also configured for use as a home for applications. However, Oracle ACFS file systems cannot be used for an Oracle base directory or an Oracle Grid Infrastructure home that contains the software for Oracle Clusterware, Oracle ASM, Oracle ACFS, and Oracle ADVM components.

To reduce contention on an Oracle ACFS file system in an Oracle RAC environment where the Oracle Database home is shared on Oracle ACFS, Oracle Database auditing operating system files should be configured as node specific. For a node-specific setup, you must ensure that the AUDIT_FILE_DEST initialization parameter in the configuration file of each database instance points to a unique location rather than one location for all the database instances.

For example, if you have a database with the Oracle name set to TEST and you want to ensure that the location of AUDIT_FILE_DEST initialization parameter for each database instance, such as TEST1 or TEST2, points to a node specific location for that instance, you can run the following SQL statement:

SQL> ALTER SYSTEM SET AUDIT_FILE_DEST='$ORACLE_BASE/admin/adump/TEST/@' 
     SCOPE=SPFILE SID='*';

In the previous example, @ expands to the ORACLE_SID of each instance. If ORACLE_BASE has been set to /acfsmounts in this example, then that value could have been used in place of the ORACLE_BASE variable.

See Also:

About Oracle ASM Dynamic Volume Manager

The Oracle ASM Dynamic Volume Manager (Oracle ADVM) provides volume management services and a standard disk device driver interface to clients. File systems and other disk-based applications send I/O requests to Oracle ADVM volume devices as they would to other storage devices on a vendor operating system.

For more information about Oracle ADVM, see "Overview of Oracle ASM Dynamic Volume Manager".

About the Oracle ACFS Driver Model

An Oracle ACFS file system is installed as a dynamically loadable vendor operating system (OS) file system driver and tool set that is developed for each supported operating system platform. The driver is implemented as a Virtual File System (VFS) and processes all file and directory operations directed to a specific file system.

Note:

Errors encountered by the drivers are written to the native operating system console and system event loggers. See "Understanding Oracle ACFS I/O Failure Console Messages".

About the Oracle ACFS Mount Registry

The Oracle ACFS mount registry supports Oracle Grid Infrastructure cluster configurations, but does not support Oracle Restart configurations. File systems that are to be mounted persistently (across restarts) can be registered with the Oracle ACFS mount registry. In cluster configurations, registered Oracle ACFS file systems are automatically mounted by the mount registry, similar to a clusterwide mount table. However, in Oracle Restart configurations the automatic mounting of registered Oracle ACFS file systems is not supported. For more information, see "Oracle ACFS and Oracle Restart".

By default, an Oracle ACFS file system that is inserted into the cluster mount registry is automatically mounted on all cluster members, including cluster members that are added after the registry addition. However, the cluster mount registry also accommodates standalone and multi-node (subset of cluster nodes) file system registrations. The mount registry actions for each cluster member mount only registered file systems that have been designated for mounting on that member.

The Oracle ACFS resource actions are designed to automatically mount a file system only one time for each Oracle Grid Infrastructure initialization to avoid potential conflicts with administrative actions to dismount a given file system.

For information about registering an Oracle ACFS file system using the acfsutil command, see "acfsutil registry".

About Oracle ACFS Snapshots

An Oracle ACFS snapshot is an online, read-only or read-write, point in time copy of an Oracle ACFS file system. The snapshot copy is space-efficient and uses Copy-On-Write functionality. Before an Oracle ACFS file extent is modified or deleted, its current value is copied to the snapshot to maintain the point-in-time view of the file system.

Oracle ACFS snapshots are immediately available for use after they are created. The snapshots are created in the .ACFS/snaps/ directory of the file system. They are always online while the file system is mounted. Consequently, an Oracle ACFS snapshot can support the online recovery of files inadvertently modified or deleted from a file system. With up to a total of 1023 read-only, read-write, or combination of read-only and read-write snapshot views supported for each file system, flexible online file recovery solutions spanning multiple views can be employed. An Oracle ACFS snapshot can also be used as the source of a file system backup, as it can be created on demand to deliver a current, consistent, online view of an active file system. For information about the number of snapshots supported, refer to "Oracle ACFS Disk Space Usage".

Oracle ACFS read-write snapshots enable fast creation of an snapshot image that can be both read and written without impacting the state of the Oracle ACFS file system hosting the snapshot images. You can use read-write snapshots for:

  • Testing of new versions of application software on production file data reflected in the read-write snapshot image without modifying the original production file system

  • Running test scenarios on a real data set without modifying the original production file system

To use Oracle ACFS read-write snapshots, the disk group compatibility attribute for ADVM must be set to 11.2.0.3.0 or higher. If you create a read-write snapshot on an existing Oracle ACFS file system from a version earlier than 11.2.0.3.0, then the file system is updated to the 11.2.0.3.0 or higher format. After a file system has been updated to a higher version, an Oracle ACFS file system cannot be reverted to an earlier version, and accordingly cannot be mounted on an earlier Oracle Grid Infrastructure version.

You can create a snapshot from an existing snapshot in the same Oracle ACFS file system. In addition, you can convert a snapshot between read-only and read-write formats. To create from an existing snapshot or convert a snapshot, the disk group compatibility attribute for ADVM must be set to 12.1 or higher. In addition, creation from an existing snapshot is not permitted if there are:

  • Any snapshots present in the file system that were created with the ADVM compatibility set to less than 12.1

  • Any snapshots of the file system that were created after ADVM compatibility was set to 12.1 but while 11.2 snapshots existed

Oracle ACFS snapshot storage is maintained within the file system, eliminating the management of separate storage pools for file systems and snapshots. Oracle ACFS file systems can be dynamically resized to accommodate additional file and snapshot storage requirements.

You cannot modify security or encryption metadata in read-write snapshots except for enabling or disabling security or encryption. No other alteration is permitted on Oracle ACFS security or encryption metadata in a snapshot. If a file was not secured by a security realm in the snapshot, it cannot be realm secured by adding the corresponding file in the active file system to a security realm. If a file was not encrypted in the snapshot, that file cannot be encrypted by encrypting the corresponding file in the active file system.

A new file created in a realm-secured directory in a read-write snapshot inherits the realm security attributes of the parent directory. If the realm protecting the new file has encryption turned on, the file is encrypted with the encryption parameters set in the realm. If the realm protecting the new file has encryption turned off, the file is decrypted. Files and directories in a read-write snapshot cannot be added to or removed from any security realm.

Files in a read-write snapshot can be encrypted, decrypted, or rekeyed if the operation target is a path specified for a file or directory of the read-write snapshot. However, if an encryption, decryption, or rekey operation is specified at the file system level, then the operation does not process files and directories of snapshots in the .ACFS/snaps/ directory.

All Oracle ACFS snapshot operations are serialized clusterwide in the kernel. For example, if a snapshot create operation is initiated at the same time as a snapshot delete operation, then both operations would complete, but they would not run in parallel inside of the kernel. One operation would complete before the other was started.

For information about Oracle ACFS security, refer to "Oracle ACFS Security". For information about Oracle ACFS encryption, refer to "Oracle ACFS Encryption".

Oracle ACFS snapshots are administered with the acfsutil snap commands. For information about the acfsutil snap commands, refer to "acfsutil snap create", "acfsutil snap delete", and "acfsutil snap info".

Note:

The link() and rename() system calls fail if an attempt is made to link or rename a file in the Oracle ACFS file system and a file in any associated read-write snapshot, or vice versa. Any tools which use the link() and rename() system calls, such as ln and mv, also fail in the same scenario.

About Oracle ACFS and Backup and Restore

Oracle ACFS runs on operating system platforms as a native file system technology supporting native operating system file system application programming interfaces (APIs). Consequently, backup applications that access files using the native operating system file system interfaces are able to access and backup Oracle ACFS file systems and other native operating system file systems. Oracle ACFS snapshots can be dynamically created and used to present a consistent, on-line view of an active file system to a backup application.

Backup applications that use interfaces other than the standard operating system interfaces (read or write) are not supported with Oracle ACFS. For example, Windows backup applications that depend upon the presence of reparse points or the Windows Volume Shadow Copy Service (VSS) are not supported.

For information about using common operating system utilities to preserve Extend Attributes for tagging definitions, refer to "Oracle ACFS Tagging".

About Oracle ACFS Integration with Oracle ASM

Oracle ACFS is always configured with Oracle ASM storage and interfaces with Oracle ASM storage through a traditional device file. This device file is presented by Oracle ADVM and is constructed using a dynamic volume file. The Oracle ADVM volume device file is created automatically following the creation of an Oracle ADVM volume. An Oracle ACFS file system is then bound to the Oracle ADVM device file during the file system creation.

After an Oracle ACFS is configured and mounted, the file system inherits the Oracle ASM storage management features associated with an Oracle ADVM volume, including dynamic balanced distribution, mirroring and striping, and dynamic resizing.

The Oracle ACFS driver establishes communication with the Oracle ASM instance to receive Oracle ASM status information including Oracle ASM instance and disk group state transitions. However, I/O does not go through Oracle ASM, but goes directly through the Oracle ADVM proxy instance to the underlying storage.

For information about Oracle ACFS and Oracle ASM operations, see "Oracle ACFS and Dismount or Shutdown Operations".

About Oracle ACFS and External Tables on Windows

To access an external table stored on an Oracle ACFS file system on Windows, the external table must be created with the DISABLE_DIRECTORY_LINK_CHECK access parameter.

See Also:

Understanding Oracle ACFS Administration

This section describes Oracle ACFS administration and contains the following topics:

Oracle ACFS and File Access and Administration Security

Oracle ACFS supports both traditional Unix-style file access control classes (user, group, other) for Linux environments and the Windows Security Model including file access control lists (ACLs) for Windows platforms. Most Oracle ACFS administrative actions are performed by users with either root or Oracle ASM administration privileges for Linux environments and by users with Windows Administrative privileges on Windows platforms. General Oracle ACFS information for file systems can be accessed by any system user.

In support of Oracle ACFS administration, Oracle recommends that the Oracle ASM administrator role is given to a root privileged user, as many common Oracle ACFS file system management tasks including mount, umount, fsck, driver load, and driver unload are root privileged operations. Other privileged Oracle ACFS file system operations that do not require root privileges can be performed by the Oracle ASM administrator. If the Oracle ASM administrator role is not given to a root privileged user, access to Oracle ACFS file systems can be restricted with the norootsuid and nodev mount options.

Additional fine grain access control is provided for Oracle ACFS file systems with the security infrastructure feature. For information about Oracle ACFS security infrastructure, refer to "Oracle ACFS Security". For information about Oracle ACFS encryption, refer to "Oracle ACFS Encryption".

For information about Oracle ASM privileges, see "About Privileges for Oracle ASM". For information about administering Oracle ACFS, refer to Chapter 16, "Managing Oracle ACFS with Command-Line Tools".

Oracle ACFS and Grid Infrastructure Installation

Oracle Grid Infrastructure includes Oracle Clusterware, Oracle ASM, Oracle ACFS, Oracle ADVM, and driver resources software components, which are installed into the Grid Infrastructure home using the Oracle Universal Installation (OUI) tool.

For information about Oracle ACFS and Oracle Clusterware resources, see "Oracle Clusterware Resources and Oracle ACFS Administration".

Oracle ACFS and Grid Infrastructure Configuration

After a Grid Infrastructure installation and Oracle Clusterware is operational, you can use Oracle ASM Configuration Assistant (ASMCA) to start the Oracle ASM instance and create Oracle ASM disk groups, Oracle ADVM volumes, and Oracle ACFS file systems. Alternatively, Oracle ASM disk groups and Oracle ADVM volumes can be created using SQL*Plus and ASMCMD command line tools. File systems can be created using operating system command-line tools.

Oracle ACFS file systems are configured with Oracle ADVM based operating system storage devices that are created automatically following the creation of an Oracle ADVM dynamic volume file. After a volume file and its associated volume device file are created, a file system can be created and bound to that operating system storage device. Following creation, an Oracle ACFS file system can be mounted, after which it is accessible to authorized users and applications executing file and file system operations.

Database-related Oracle ACFS file systems need Oracle Clusterware dependencies on the database, which can be created with SRVCTL or DBCA. General purpose Oracle ACFS file systems can be Oracle Clusterware managed with acfsutil registry or srvctl add filesystem.

For an example of the specific actions required to create a file system, see "Basic Steps to Manage Oracle ACFS Systems". For information about managing Oracle ACFS file systems with ASMCA, see "ASMCA GUI Tool for Managing Oracle ACFS and Oracle ADVM".

Oracle Clusterware Resources and Oracle ACFS Administration

Oracle Clusterware resources support Oracle ACFS, Oracle Kernel Services Driver (OKS), Oracle ADVM startup, the Oracle ACFS cluster mount registry, and Oracle ACFS single file system startup, shutdown, and steady-state actions.

The following list summarizes Oracle ACFS resource-based management.

  • The Oracle ACFS, Oracle Kernel Services (OKS), and Oracle ADVM drivers are dynamically loaded when the Oracle ASM instance is started.

    • Oracle ACFS

      This driver processes all Oracle ACFS file and directory operations.

    • Oracle ADVM

      This driver provides block device services for Oracle ADVM volume files that are used by file systems for creating file systems.

    • Oracle Kernel Services Driver (OKS)

      This driver provides portable driver services for memory allocation, synchronization primitives, and distributed locking services to Oracle ACFS and Oracle ADVM.

    The drivers are managed as a single resource set. For additional information, see "Oracle ACFS Drivers Resource Management" and "Oracle ACFS Driver Commands".

  • Oracle ACFS file systems listed in the Oracle ACFS mount registry are automatically mounted during Grid Infrastructure initialization and as new mount registry entries are created.

    The registry resource manages activation of the Oracle ACFS mount registry and supports the mount and dismount actions for Oracle ACFS file systems listed in the Oracle ACFS mount registry.

    For information, see "Oracle ACFS Registry Resource Management".

  • Oracle ACFS file systems are either manually mounted or dismounted using an Oracle ACFS or Oracle Clusterware command-line tool, or automatically mounted or dismounted based on a resource dependency action.

    For example, a file system hosting an Oracle Database home can be named in the dependency list of the associated Oracle Database resource such that issuing a start on the database resource results in mounting the dependent Oracle ACFS hosted database home file system.

    For information, see "Oracle ACFS File System Resource Management".

Oracle ACFS and Dismount or Shutdown Operations

It is important to dismount any active file system configured with an Oracle ADVM volume device file before an Oracle ASM instance is shutdown or a disk group is dismounted. After the file systems are dismounted, all open references to Oracle ASM files are removed and associated disk groups can be dismounted or the instance shut down.

If the Oracle ASM instance or disk group is forcibly shut down or fails while an associated Oracle ACFS is active, the file system is placed into an offline error state. If any file systems are currently mounted on Oracle ADVM volume files, the SHUTDOWN ABORT command should not be used to terminate the Oracle ASM instance without first dismounting those file systems. Otherwise, applications encounter I/O errors and Oracle ACFS user data and metadata being written at the time of the termination may not be flushed to storage before the Oracle ASM storage is fenced. If it is not possible to dismount the file system, then you should run two sync (1) commands to flush cached file system data and metadata to persistent storage before issuing the SHUTDOWN ABORT operation.

Any subsequent attempt to access an offline file system returns an error. Recovering a file system from that state requires dismounting and remounting the Oracle ACFS file system. Dismounting an active file system, even one that is offline, requires stopping all applications using the file system, including any shell references. For example, a previous change directory (cd) into a file system directory. The Linux fuser or lsof commands or Windows handle command list information about processes and open files.

For information about shutting down an Oracle ASM instance, see "Shutting Down an Oracle ASM Instance". For information about dismounting a disk group, see "Mounting and Dismounting Disk Groups".

Oracle ACFS Security

Oracle ACFS security provides realm-based security for Oracle ACFS file systems, enabling you to create realms to specify security policies for users and groups to determine access on file system objects. This security feature provides a finer-grained access control on top of the access control provided by the operating system. Oracle ACFS security can use the encryption feature to protect the contents of realm-secured files stored in Oracle ACFS file systems.

Oracle ACFS security uses realms, rules, rule sets, and command rules to enforce security policies.

  • An Oracle ACFS security realm is a group of files or directories that are secured for access by a user or a group of users. Realms are defined with rule sets which contain groups of rules that apply fine grain access control. Oracle ACFS security realms can also be used as containers to enable encryption.

  • Oracle ACFS security rules are Boolean expressions that evaluate to true or false based on a system parameter on which the rule is based.

  • Oracle ACFS rule sets are collection of rules. Rule sets evaluate to TRUE or FALSE based on the evaluation of the rules a rule set contains.

  • Oracle ACFS command rules are associations of the file system operation to a rule set. For example, the association of a file system create, delete, or rename operation to a rule set. Command rules are associated with an Oracle ACFS realm.

An existing operating system user must be designated as the first Oracle ACFS security administrator and an existing operating system group must be designated as the security administrator admin group. Security administrators must be members of the designated security group. Additional users can be designated as security administrators. An Oracle ACFS security administrator can manage encryption for an Oracle ACFS file system on a per-realm basis. An Oracle ACFS security administrator is authenticated for security operations with a security realm password, not the operating system password of the user.

The first security administrator is created during the initialization of Oracle ACFS security with the acfsutil sec init command which is run by the root user. When the first security administrator is created, the administrator is assigned a password that can be changed by the administrator. Each time a security administrator runs an acfsutil sec command, the administrator is prompted for the security password. The security realm passwords for administrators are stored in a wallet created during the security initialization process. This wallet is located in the Oracle Cluster Registry (OCR).

Auditing and diagnostic data are logged for Oracle ACFS security. The log files include information such as acfsutil commands that have been run, the use of security or system administrator privileges, and run-time failures such as realm check authorization failures.

Auditing events, such as realm creation or encryption enabled, are written to these log files only if auditing is not enabled for on the file system. If auditing is enabled, these events are written into the audit trail. Diagnostic messages related to security and encryption are always written to the sec-hostname_fsid.log file regardless of whether auditing is enabled or not. For information about Oracle ACFS auditing, refer to "Oracle ACFS Auditing".

Logs are written to the following files:

  • mount_point/.Security/realm/logs/sec-hostname_fsid.log

    The directory is created with acfsutil sec prepare command and protected by Oracle ACFS security. Refer to "acfsutil sec prepare".

  • GRID_HOME/log/hostname/acfs/security/acfssec.log

    The messages that are logged to this file are for commands that are not associated with a specific file system, such as acfsutil sec init. The directory is created during installation and is owned by the root user.

When an active log file grows to a pre-defined maximum size (10 MB), the file is automatically moved to log_file_name.bak, the administrator is notified, and logging continues to the regular log file name. When the administrator is notified, the administrator must archive and remove the log_file_name.bak file. If an active log file grows to the maximum size and the log_file_name.bak file exists, logging stops until the backup file is removed. After the backup log file is removed, logging restarts automatically.

Oracle ACFS security protects the following objects from unauthorized accesses:

  • Realm-secured directories and user files

    The directories and files reside on a file system secured by Oracle ACFS security.

  • The Oracle ACFS security directory (mount_point/.Security) and its contents

    The security directory contains the log files in plain-text format and a security metadata backup file in XML format. The log files generated by Oracle ACFS security can only be accessed by valid Oracle ACFS security administrators.

  • Oracle ACFS security objects

    These objects are the security realms, rules, and rule sets used to manage Oracle ACFS security.

Access to files in a security realm of an Oracle ACFS file system must be authorized by both the security realm and the underlying operating system permissions, such as (owner, group, other) permissions on Linux and Access Control Lists (ACLs) on Windows. Each access to a realm-secured file is first checked for security realm authorization. If the access is authorized by the security realm, then access to the files is checked by the underlying operating system access control checks. If both checks pass, access is allowed to the realm-secured file.

Note the following when working with Oracle ACFS security:

  • Oracle ACFS security does not provide any protection for data sent on the network.

  • A copy of a realm-protected file is not realm-protected unless the copy is made in a security realm-protected directory.

    Some applications, such as the vi editor, re-create a file when the file is modified. The modified file is saved as a temporary file, the original file is removed, and temporary file is copied with the original file name as the destination name. This process creates a new file. If the new file is created in a realm-protected directory, the security policies of the realm also apply to the new file. If the new file is not created in a realm-protected directory, then the new file is not realm-protected. If you are planning to copy a realm-protected file, you should ensure that the parent directory is also security realm protected.

    Security policies also apply to any temporary files created in a realm-protected directory.

To use Oracle ACFS security functionality on Linux, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.2 or higher. To use Oracle ACFS security functionality on Windows, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3 or higher. For information about disk group compatibility, refer to "Disk Group Compatibility".

For information about Oracle ACFS security and snapshots, refer to "About Oracle ACFS Snapshots".

Security information for Oracle ACFS file systems is displayed in the V$ASM_ACFS_SECURITY_INFO view. For information about V$ASM_ACFS views, refer to Chapter 12, "Using Views to Display Oracle ACFS Information".

To configure security for Oracle ACFS file systems, you can use the acfsutil sec command-line functions described in "Securing Oracle ACFS File Systems" and "Oracle ACFS Command-Line Tools for Security". Also, you can use ASMCA described in "Managing Security and Encryption for Oracle ACFS with ASMCA".

See Also:

Your operating system-specific (OS) documentation for information about setting up OS users and OS groups

Oracle ACFS Encryption

Oracle ACFS encryption enables you to encrypt data stored on disk (data-at-rest). The encryption feature protects data in an Oracle ACFS file system in encrypted format to prevent unauthorized use of data in the case of data loss or theft. Both encrypted and non-encrypted files can exist in the same Oracle ACFS file system.

Some encryption functionality requires system administrator privileges. This functionality incudes the commands for initiating, setting, and reconfiguring encryption.

System administrators and Oracle ACFS security administrators can initiate encryption operations. Also, unprivileged users can initiate encryption for files they own.

Oracle ACFS encryption provides two type of encryption keys:

  • File Encryption Key

    This is a key for a file and is used to encrypt the data in the file.

  • Volume Encryption Key

    This is a key for a file system and is used to encrypt the file encryption keys.

You must first create the encryption key store, then specify file system-level encryption parameters and identify the directories. No extra steps are required for a user to read encrypted files if the user has the appropriate privileges for accessing the file data.

Oracle ACFS encryption supports both Oracle Cluster Registry (OCR) and Oracle Key Vault as a key store. Both OCR and Oracle Key Vault can be used in the same cluster. However, a single file system uses either OCR or Oracle Key Vault as a key store, but not both. Oracle Key Vault is currently only available with file systems on Linux.

See Also:

Oracle Key Vault Administrator's Guide for information about Oracle Key Vault

If you are using OCR as a key store, you should back up the OCR after creating or updating an encryption key to ensure there is an OCR backup that contains all of the volume encryption keys (VEKs) for the file system.

Oracle ACFS encryption protects data stored on secondary storage against the threat of theft or direct access to the storage medium. Data is never written to secondary storage in plaintext. Even if physical storage is stolen, the data stored cannot be accessed without the encryption keys. The encryption keys are never stored in plaintext. The keys are either obfuscated, or encrypted using a user-supplied password.

An Oracle ACFS security administrator can manage encryption parameters on a per-realm basis. After a file is placed under realm security, file-level encryption operations are not allowed on that file. Even if the realm security allows the file owner or the root user to open the file, file-level encryption operations are blocked. Encryption of realm-protected files is managed entirely by the Oracle ACFS security administrator, who can enable and disable encryption for files at a security realm level.

After a directory has been added to a security realm, all files created in the directory inherit the realm-level encryption parameters, not the directory or file system-level parameters. When a file is removed from its last security realm, the file is encrypted or decrypted to match the file system-level encryption status. The file is not re-encrypted to match file system-level parameters if it has been encrypted with security realm parameters.

A system administrator cannot rekey realm-secured files at the file system or file level. To ensure all realm-secured files are encrypted with the most recent volume encryption key (VEK), you must first remove encryption from all realms, and then re-enable encryption. This action re-encrypts all files with the most recent VEK.

Auditing and diagnostic data are logged for Oracle ACFS encryption. The log files include information such as acfsutil commands that have been run, the use of security or system administrator privileges, and run-time failures. Logs are written to the following files:

  • mount_point/.Security/encryption/logs/encr-hostname_fsid.log

    The directory is created with acfsutil encr set command and protected by Oracle ACFS security if security is enabled. Refer to "acfsutil encr set".

  • GRID_HOME/log/hostname/acfs/security/acfssec.log

    The messages that are logged to this file are for commands that are not associated with a specific file system, such as acfsutil encr init. The directory is created during installation and is owned by the root user.

When an active log file grows to a pre-defined maximum size (10 MB), the file is automatically moved to log_file_name.bak, the administrator is notified, and logging continues to the regular log file name. When the administrator is notified, the administrator must archive and remove the log_file_name.bak file. If an active log file grows to the maximum size and the log_file_name.bak file exists, logging stops until the backup file is removed. After the backup log file is removed, logging restarts automatically.

Note the following when working with Oracle ACFS encryption:

  • A copy of an encrypted file is not encrypted unless the copy of the file is made in an encrypted directory.

    Some applications, such as the vi editor, re-create a file when the file is modified. The modified file is saved as a temporary file, the original file is removed, and temporary file is copied with the original file name as the destination name. This process creates a new file. The new file is not encrypted unless it is created in an encrypted directory. If you are planning to copy an encrypted file, you should ensure that the parent directory is also encrypted.

  • Using encryption with database files on Oracle ACFS is not supported.

To use Oracle ACFS encryption functionality on Linux, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.2 or higher. The disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3 or higher on Linux for the following cases:

  • If encryption is configured for the first time on Oracle ASM 11g Release 2 (11.2.0.3).

  • If encryption parameters must be changed or a new volume encryption key must be created following a software upgrade to Oracle ASM 11g Release 2 (11.2.0.3). For information, see "acfsutil encr set" and "acfsutil encr rekey".

To use Oracle ACFS encryption functionality on Windows, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3 or higher.

For information about disk group compatibility, refer to "Disk Group Compatibility".

For information about Oracle ACFS encryption and snapshots, refer to "About Oracle ACFS Snapshots".

Encryption information for Oracle ACFS file systems is displayed in the V$ASM_ACFS_ENCRYPTION_INFO view. For information about V$ASM_ACFS views, refer to Chapter 12, "Using Views to Display Oracle ACFS Information".

To configure encryption and manage encryptedOracle ACFS file systems, you can use the acfsutil encr command-line functions described in "Encrypting Oracle ACFS File Systems" and "Oracle ACFS Command-Line Tools for Encryption". Also, you can use Oracle ASM Configuration Assistant with encryption features as described in "Managing Security and Encryption for Oracle ACFS with ASMCA".

Oracle ACFS Auditing

Oracle ACFS auditing provides auditing capabilities for Oracle ACFS security and encryption. This auditing framework produces a separate audit trail for each Oracle ACFS file system on each individual node, and enforces separation of duties regarding the management and review of this audit source.

Audit sources are the source of events, such as Oracle ACFS security and Oracle ACFS encryption. Audit trails are the logs where the audit records are written.

This section contains the following topics:

About Oracle ACFS Auditing

Both Oracle ACFS security and encryption are also audit sources, and these sources can be enabled and disabled by an Oracle ACFS audit manager. These sources generate events as a result of the execution of Oracle ACFS security or encryption commands.

The Oracle ACFS security administrator can enable auditing at the realm level so that security violations and authorizations can also be audited as well as enabling auditing on security to audit all the events executed by a security administrator. An Oracle ACFS security source must be enabled before Oracle ACFS realm security auditing can be used.

Setting the realm auditing policy to audit all authorizations and violations for all command rules can cause the audit trail to quickly increase to its maximum size. Administrators should carefully adjust the auditing level to their requirements and be aware that auditing policies generating more verbose auditing output require additional active monitoring and management, such as archiving and purging, of the audit trail and audit trail backup files.

Along with the generation of a file system audit source, Oracle ACFS auditing allows fine-grained auditing policies to be set separately on each realm basis. The Oracle ACFS auditing capability provides the infrastructure for an audit vault collector to import data into Oracle Audit Vault and Database Firewall. The collector is separate from Oracle ACFS and functions as means for Oracle ACFS auditing data to be imported into Audit Vault Server.

The responsibilities for configuration and management of the audit source are separated into the Oracle ACFS audit manager and Oracle ACFS auditor roles. The system administrator has the authority to add and remove users to and from the Oracle ACFS audit manager and Oracle ACFS auditor operating system (OS) groups.

The Oracle ACFS audit managers have access to the contents of audit sources and can read audit data; however, the audit managers cannot modify the audit sources. The set of Oracle ACFS audit managers is the same across a cluster.

The Oracle ACFS auditors are responsible for viewing and analyzing the contents of the audit source, such as indicating to the Oracle ACFS audit managers which records have been analyzed and archived and are safe to purge. The Oracle ACFS auditors should be the only users on the system with access to the contents of the audit source. The Oracle ACFS auditor do not have the required permissions to remove or purge audit records. The set of Oracle ACFS auditors is the same across a cluster.

The audit archiving process renames audit trail log files (.log) to a audit trail backup file (.log.bak) and generates an XML file, which can be imported by Audit Vault Server. Audit Vault Server has only read access to the audit trail directory and functions as an auditor in this case. After the data from the XML file is imported in the Audit Vault Server, the auditor function marks the audit trail backup file as read, and then audit manager can execute a purge to remove audit trail backup files and XML files.

To configure auditing for an Oracle ACFS file system, run the acfsutil audit init command to initialize auditing for Oracle ACFS and then run acfsutil audit enable to enable auditing for Oracle ACFS encryption or security on the specified file system. For information about the acfsutil audit commands, refer to "Oracle ACFS Command-Line Tools for Auditing".

For information about enabling or disabling auditing for specific commands in an Oracle ACFS security realm, refer to the acfsutil sec realm audit enable and acfsutil sec realm audit disable commands described in "Oracle ACFS Command-Line Tools for Security".

For information about views that are relevant to Oracle ACFS auditing, refer to "Views Containing Oracle ACFS Information".

See Also:

Audit Trail File

Audit trail files consist of a set of audit records. Each audit record represents a single event. Audit trail files are located in the mount_point/.Security/audit directory.

Audit trail files generated by Oracle ACFS auditing are meant to be available for the following:

  • Manual review by an Oracle ACFS auditor using text viewing tools

  • Import into Oracle Audit Vault and Database Firewall

  • Third party products that can parse and import the audit sources

The audit trail file consists of audit records. There are several different types of audit records, each of which represent a unique type of event and contain different information relevant to diagnosing the event. The types of events are:

The combination of audit record fields entered in the audit trail file depends on the event type.

Each record is written to the audit trail file as a set of field names and values. Depending on the type of record, the number and type of fields may vary. Fields consist of a name and value pair, in the form field name:value, followed by an end of line character.

The audit record fields that can be present in the audit trail file are described in the following list. The string in parenthesis is the field name that appears in the audit trail log file.

  • Timestamp (Timestamp): The time at which the event occurred, always specified in UTC. The format for the time stamp is: MM/DD/YYYY HH:MM:SS UTC

  • Event Code (Event): A code identifying the type of event. For the list of evaluation result codes, refer to "File Access Events" and "Privilege Use Events".

  • Source (Source): Oracle ACFS

  • User identification (User): The user who triggered the event. On Linux platforms this is a user ID and on Windows this is the user SID.

  • Group identification (Group): The primary group of the user who triggered the event. On Linux platforms this is the ID the primary group of the user and on Windows this is the SID of the primary group of the user.

  • Process identification (Process): The current process ID.

  • Host name (Host): The host which recorded the event.

  • Application name (Application): The application name for the current process.

  • Realm name (Realm): The name of the realm which was violated, or the realm that is authorized and is protecting the file.

  • File name (File): The file name which the user was accessing.

  • Evaluation Result (Evaluation Result): This field contains the information about the result of the command executed. For the list of evaluation result codes, refer to "Evaluation Result Events".

  • File system Id (FileSystem-ID):

  • Message (Message): The message filed has the information about the command executed and its result.

Example 11-1 shows an example of an audit trail file.

Example 11-1 Sample audit trail file

Timestamp: 06/08/12 11:00:37:616 UTC
Event: ACFS_AUDIT_READ_OP
Source: Oracle_ACFS
User: 0
Group: 0
Process: 1234
Host: slc01hug
Application: cat
Realm: MedicalDataRealm
File: f2.txt
Evaluation Result: ACFS_AUDIT_REALM_VIOLATION
FileSystem-ID: 1079529531
Message: Realm authorization failed for file ops READ

Timestamp: 06/08/12 11:00:37:616 UTC
Event: ACFS_AUDIT_WRITE_OP
Source: Oracle_ACFS
User: 102
Group: 102
Process: 4567
Host: slc01hug
Application: vi
Realm: PayrollRealm,SecuredFiles
File: f2.txt
Evaluation Result: ACFS_AUDIT_REALM_AUTH
FileSystem-ID: 1079529531
Message: Realm authorization succeeded for file ops WRITE

Timestamp: 06/08/12 10:42:20:977 UTC
Event: ACFS_SEC_PREPARE
Source: Oracle_ACFS
User: 507867
Group: 8500
Process: 603
Host: slc01hug
Application: acfsutil.bin
Evaluation Result: ACFS_CMD_SUCCESS
FileSystem-ID: 1079529531
Message: acfsutil sec prepare: ACFS-10627: Mount point '/mnt' is now
prepared for security operations.

File Access Events

File access events include both realm authorization and violation records. These events share a similar structure with all events, but have a different event code. The Evaluation Result (Evaluation Result) field can contain either ACFS_AUDIT_REALM_VIOLATION or ACFS_AUDIT_REALM_AUTH.

The possible event code (Event) for file access events include the following:

  • ACFS_AUDIT_APPENDFILE_OP

  • ACFS_AUDIT_CHGRP_OP

  • ACFS_AUDIT_CHMOD_OP

  • ACFS_AUDIT_CHOWN_OP

  • ACFS_AUDIT_CREATEFILE_OP

  • ACFS_AUDIT_DELETEFILE_OP

  • ACFS_AUDIT_EXTEND_OP

  • ACFS_AUDIT_GET_EXTATTR_OP

  • ACFS_AUDIT_LINKFILE_OP

  • ACFS_AUDIT_MKDIR_OP

  • ACFS_AUDIT_MMAPREAD_OP

  • ACFS_AUDIT_MMAPWRITE_OP

  • ACFS_AUDIT_MUTABLE_OP

  • ACFS_AUDIT_OPENFILE_OP

  • ACFS_AUDIT_OVERWRITE_OP

  • ACFS_AUDIT_READ_OP

  • ACFS_AUDIT_READDIR_OP

  • ACFS_AUDIT_RENAME_OP

  • ACFS_AUDIT_RMDIR_OP

  • ACFS_AUDIT_SET_EXTATTR_OP

  • ACFS_AUDIT_SYMLINK_OP

  • ACFS_AUDIT_TRUNCATE_OP

  • ACFS_AUDIT_WRITE_OP

Privilege Use Events

Privilege use events include security commands run by the security administrator or system administrator, and encryption commands run by the system administrator or file owners.

The ACFS_AUDIT_INIT, ACFS_SEC_INIT, and ACFS_ENCR_INIT events are written into the global log that is located in Oracle Grid Infrastructure home.

The possible event code (Event) for privilege use events include the following:

  • ACFS_AUDIT_ARCHIVE

  • ACFS_AUDIT_DISABLE

  • ACFS_AUDIT_ENABLE

  • ACFS_AUDIT_INIT

  • ACFS_AUDIT_PURGE

  • ACFS_AUDIT_READ

  • ACFS_ENCR_FILE_OFF

  • ACFS_ENCR_FILE_ON

  • ACFS_ENCR_FILE_REKEY

  • ACFS_ENCR_FS_OFF

  • ACFS_ENCR_FS_ON

  • ACFS_ENCR_INIT

  • ACFS_ENCR_SET

  • ACFS_ENCR_SET_UNDO

  • ACFS_ENCR_VOL_REKEY

  • ACFS_ENCR_WALLET_STORE

  • ACFS_REALM_AUDIT_DISABLE

  • ACFS_REALM_EDIT_ENCR

  • ACFS_REALM_AUDIT_ENABLE

  • ACFS_SEC_LOAD

  • ACFS_SEC_PREPARE

  • ACFS_SEC_PREPARE_UNDO

  • ACFS_SEC_REALM_ADD

  • ACFS_SEC_REALM_CLONE

  • ACFS_SEC_REALM_CREATE

  • ACFS_SEC_REALM_DELETE

  • ACFS_SEC_REALM_DESTROY

  • ACFS_SEC_RULE_CREATE

  • ACFS_SEC_RULE_DESTROY

  • ACFS_SEC_RULE_EDIT

  • ACFS_SEC_RULESET_CREATE

  • ACFS_SEC_RULESET_DESTROY

  • ACFS_SEC_RULESET_EDIT

  • ACFS_SEC_SAVE

Evaluation Result Events

Evaluation result event codes provide information about the execution status of a command.

The evaluation result event codes can be one of the following:

  • ACFS_AUDIT_REALM_VIOLATION – The user executing the command does not have the proper realm access permission to execute the command.

  • ACFS_AUDIT_REALM_AUTH - Indicates the result of a realm evaluation.

  • ACFS_AUDIT_MGR_PRIV – Audit manager privileges are required, but have not been granted to the user.

  • ACFS_AUDITOR_PRIV – Auditor privileges are required, but have not been granted to the user.

  • ACFS_CMD_SUCCESS - The command has been successful in performing the task.

  • ACFS_CMD_FAILURE - The command has failed in performing the task.

  • ACFS_ENCR_WALLET_AUTH_FAIL – A system administrator provides an incorrect password when opening an encryption wallet.

  • ACFS_INSUFFICIENT_PRIV – Either file owner or system administrator privileges are required, but have not been granted to the user.

  • ACFS_SEC_ADMIN_PRIV – Security administrator privileges are required, but the user is not a security administrator

  • ACFS_SEC_ADMIN_AUTH_FAIL – A valid security administrator fails to authenticate properly using their Oracle ACFS security administration password

  • ACFS_SYS_ADMIN_PRIV – System administrator privileges are required, but have not been granted to the user.

Oracle ACFS Replication

Oracle ACFS replication enables replication of Oracle ACFS file systems across the network to a remote site, providing disaster recovery capability for the file system.

Notes:

  • Oracle ACFS replication functionality supports only one standby file system for each primary file system.

  • Oracle ACFS replication supports eight or fewer nodes mounting the primary file system.

  • The sites hosting the primary and standby file systems must be running the same operating system and must have the same system architecture.

  • The primary and standby sites should be running the same version of the Oracle Grid Infrastructure software. When upgrading the sites, update the standby site first.

  • The primary file system requires internal metadata files that are not visible to user-level commands, such as du or ls. The amount of internal storage for the primary file system is approximately 1 GB for each node. This extra internal storage accounts for the difference in storage usage between primary and standby file systems containing the same user files.

  • Oracle wallets should be used to manage security credentials when configuring the primary and standby file systems.

  • Using replication with database files on Oracle ACFS is not supported.

  • Oracle ACFS replication is not supported with Oracle Restart.

The source Oracle ACFS file system of an Oracle ACFS replication is referred to as a primary file system. The target Oracle ACFS file system of an Oracle ACFS replication is referred to as a standby file system.

A site can host both primary and standby file systems. For example, if there are cluster sites A and B, a primary file system hosted at site A can be replicated to a standby file system at site B. Also, a primary file system hosted at site B can be replicated to a standby file system at site A. However, an Oracle ACFS file system cannot be used as a primary and a standby file system.

Oracle ACFS replication captures file system changes written to disk for a primary file system and records the changes in files called replication logs. These logs are transported to the site hosting the associated standby file system where background processes read the logs and apply the changes recorded in the logs to the standby file system. After the changes recorded in a replication log have been successfully applied to the standby file system, the replication log is deleted from the sites hosting the primary and standby file systems.

It is critical that there is enough disk space available on both sites hosting the primary and the standby file systems to contain the replication logs. If the primary file system runs out of space, applications running on the file system may fail because Oracle ACFS cannot create a new replication log to capture the file system changes made by the application. If the standby file system runs out of space, it cannot accept new replication logs from the primary file system and cannot apply those changes to the standby file system. In addition, replication logs accumulate on the primary file system and consume the available disk space.

If the primary file system has less than 2 GB available free disk space, Oracle ACFS attempts to automatically terminate replication on the primary file system. This action prevents further consumption of disk space for replication operations and frees disk space consumed by any replication logs that remain. The auto-terminate process can prevent the primary file system from running out of space in most cases, but it is still possible that the auto-terminate process does not occur quickly enough. Before reaching the 2 GB limit, Oracle ACFS writes warnings about the free space problem in the Oracle Grid Infrastructure home alert log.

You should prevent both the primary file system and the standby file system from running out of space. If either file system runs out of available storage, you should either expand the file system or remove files from the file system to free up space. If the primary file system runs out of space and you decide to free up space by removing files, you should only remove files that are not being replicated because the removal of a file that is replicated is captured in a replication log. Another option is to delete any Oracle ACFS snapshots. For information about resizing an Oracle ACFS file system, refer to "acfsutil size".

Because replication logs can accumulate when replication is paused, you should resume replication soon after pausing replication. For information on pausing and resuming replication, refer to "acfsutil repl pause" and "acfsutil repl resume".

Before using replication on a file system, ensure that you have checked the following:

  • There is sufficient network bandwidth to support replication between the primary and standby file systems.

  • The configuration of the sites hosting the primary and standby file systems allow the standby file system to keep up with the rate of change on the primary file system.

  • The standby file system has sufficient capacity to manage the replication logs that are sent.

  • There is sufficient storage capacity to hold excess replication logs that might collect on the primary and the standby file systems when the standby file system cannot process replication logs quickly. For example, this situation can occur during network problems or maintenance on the site hosting the standby file system.

  • The primary file system must have a minimum size of 4 GB for each node that is mounting the file system. The standby file system must have a minimum size of 4 GB and should be sized appropriately for the amount of data being replicated and the space necessary for the replication logs sent from the primary file system.

See Also:

For information about tuning the network, refer to the documentation at the MAA link on Oracle Technology Network:

http://www.oracle.com/technetwork/database/features/availability/maa-096107.html

Relevant information on tuning the network can be found in the Data Guard Redo Transport & Network Configuration paper.

Directories and files in an Oracle ACFS file system can be tagged to select the objects that you want to replicate in a file system. For information on tagging, see "Oracle ACFS Tagging".

Before replicating an Oracle ACFS file system, a replication configuration must be established that identifies information such as the site hosting the primary file system, the site hosting the standby file system, the file system to be replicated, mount point of the file system, and a list of tags if desired.

The primary and standby sites must share the same user and group configurations, including all uids and gids in use in the file system. Because the replication daemons run with the credentials of oinstall and the Oracle ASM administration group, the permissions on the mount points must be configured so that the daemons are able to read and traverse the directory mount point in order to access and create files under the .ACFS/repl directory, which is the internal working location for replication logs and associated files.

To use Oracle ACFS replication functionality on Linux, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.2 or higher for the disk groups that contain the primary and standby file systems. To use Oracle ACFS replication functionality on Windows, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3 or higher. To use Oracle ACFS replication functionality on Solaris or AIX, the disk group compatibility attributes for ASM and ADVM must be set to 12.1 or higher. For information about disk group compatibility, refer to "Disk Group Compatibility".

To use Oracle ACFS replication on Solaris Sparc hardware, the system must be running Solaris 10 update 8 or later.

To configure replication and manage replicated Oracle ACFS file systems, use the acfsutil repl command-line functions described in "Replicating Oracle ACFS File Systems" and "Oracle ACFS Command-Line Tools for Replication".

Oracle ACFS Tagging

Oracle ACFS tagging assigns a common naming attribute to a group of files. Oracle ACFS Replication can use this tag to select files with a unique tag name for replication to a different remote cluster site. The tagging option avoids having to replicate an entire Oracle ACFS file system.

Oracle ACFS implements tagging with Extended Attributes. Some editing tools and backup utilities do not retain the Extended Attributes of the original file by default; you must set a specific switch. The following list describes the necessary requirements and switch settings for some common utilities to ensure Oracle ACFS tag names are preserved on the original file.

  • The cp command requires flags to preserve tag names.

    Install the coreutils library (version coreutils-5.97-23.el5_4.1.src.rpm or coreutils-5.97-23.el5_4.2.x86_64.rpm or later) on Linux to install versions of the cp command that supports Extended Attribute preservation with the --preserve=xattr switch and the mv command that supports Extended Attribute preservation without any switches.

    cp does not preserve tag names assigned to symbolic link files.

    The cp switches required to preserve tag names on files and directories are:

    • Linux: --preserve=xattr

    • Solaris: -@

    • AIX: -U

    • Windows: no switch necessary

  • The cpio file transfer utility requires flags to preserve tag names.

    The cpio switches required to preserve tag names on files and directories are:

    • Linux: cpio does not preserve tag names

    • Solaris: -@ is required to preserve or restore tag names for files and directories, but does not preserve tag names for symbolic link files

    • AIX: -U is required to preserve or restore tag names for files and directories, but does not preserve tag names for symbolic link files

    • Windows: not available

  • emacs requires that the backup-by-copying option is set to a non-nil value to preserve tag names on the original file name rather than a backup copy. This option must be added to the .emacs file.

  • The pax file transfer utility requires flags to preserve tag names.

    The pax switches required to preserve tag names on files and directories are:

    • Linux: pax does not preserve tag names

    • Solaris: -@ is required to preserve or restore tag names for files and directories, but does not preserve tag names for symbolic link files

    • AIX: -U is required to preserve or restore tag names for files and directories, but does not preserve tag names for symbolic link files

    • Windows: not available

  • The rsync file transfer utility requires flags to preserve tag names.

    The rsync switches required to preserve tag names on files and directories are:

    • Linux: -X -l are required to preserve tag names for files and directories, but these switches do not preserve tag names for symbolic link files

    • Solaris: rsync does not preserve tag names

    • AIX: not available

    • Windows: not available

  • The tar backup utility can have flags set on the command line to preserve tag names on a file. However, tar does not retain the tag names assigned to symbolic link files.

    The tar backup utility on Windows currently provides no support to retain tag names as no switch exists to save Extended Attributes.

    The tar switches required to preserve tag names on files and directories are:

    • Linux: --xattrs

    • Solaris: -@

    • AIX: -U

    • Windows: tar does not preserve tag names

  • The vim or vi editors require the set bkc=yes option in the .vimrc (Linux) or _vimrc (Windows) file to make a backup copy of a file and overwrite the original. This preserves tag names on the original file.

To use Oracle ACFS tagging functionality on Linux, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.2 or higher. To use Oracle ACFS tagging functionality on Windows, the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3 or higher. To use Oracle ACFS tagging functionality on Solaris or AIX, the disk group compatibility attributes for ASM and ADVM must be set to 12.1 or higher. For information about disk group compatibility, refer to "Disk Group Compatibility".

To configure tagging and manage tagged Oracle ACFS file systems, use the acfsutil tag command-line functions described in "Tagging Oracle ACFS File Systems" and "Oracle ACFS Command-Line Tools for Tagging". For information about Oracle ACFS tagging application programming interfaces (APIs), refer to "Oracle ACFS Tagging Generic Application Programming Interface".

Using Replication with Auditing, Encryption, and Security

Audited, encrypted, or security realm-secured file systems can be enabled on an Oracle ACFS file system on which replication has been configured. The replicated standby file system is secured with the same auditing, security, or encryption policies as the primary file system. For this replicated environment, the primary and standby file systems must both be 12.1 or higher installations. For more information about Oracle ACFS replication, refer to "Oracle ACFS Replication".

To ensure successful replication, the standby file system must be a generic file system without auditing, encryption, or security metadata on it. Oracle ACFS does not support using a standby file system that once had security or encryption and then had security or encryption removed. Additional conditions that must be met for Oracle ACFS auditing, encryption, and security are listed in this section.

Note the following about Oracle ACFS audited file systems:

  • Before replicating an audit-enabled file system or auditing a replicated file system, auditing must be initialized on the standby file system.

  • Auditing policies present on the primary file system are replicated to the standby and any policy actions taken on the primary file system are enacted on the standby file system.

  • Two sets of audit trails are present on the standby file system. Trails from primary file system are replicated to the standby file system as ordinary files. File system activity may generate events on the standby file system, which are recorded in the audit trail for the standby file system. Audit trail names help distinguish the two sets of trails because they contain both the host name and FSID.

Note the following about Oracle ACFS encrypted file systems:

  • Encrypted files on the primary file system remain encrypted on the standby file system with the same key and encryption parameters (algorithm and key length).

  • Encryption operations done on the primary file system are replayed on the standby file system - on, off, and rekey.

  • Encryption may be enabled before or after a file system is replicated. In either case, an encryption wallet is transparently created on the standby file system if one does not exist because acfsutil encr init has not been run on the standby file system.

  • A password-protected wallet is not supported on the standby file system. If a PKCS wallet already exists on a site that is to be used as a standby file system, the administrator must use the acfsutil keystore migrate command to transfer all keys to an SSO wallet.

Note the following about Oracle ACFS secured file systems:

  • Standby file systems should be initialized for security before replicating a security enabled file system.

  • The rules, rule sets and realms are replicated to the standby file system and same policies exist on the standby file system. In terms of the policies and protection of files, the standby file system is exactly same.

  • Replication can be enabled on a security enabled file system or security can be enabled on a replicated file system. As part of security preparation, security is also enabled on the standby file system.

  • Having security and replication together on a file system does not require any extra user intervention or additional steps.

  • A different set of security administrators or security administrator groups can be set up on the standby file system.

Oracle ACFS Plugins

The Oracle ACFS plugin functionality enables a user space application to collect just-in-time Oracle ACFS file and Oracle ADVM volume metrics from the operating system environment. Applications can use the Oracle ACFS plug-in infrastructure to create customized solutions that extend the general application file metric interfaces to include detailed Oracle ACFS file system and volume data.

The Oracle ACFS plug-in functionality can be enabled on separate Oracle ACFS file systems mounted on a standalone host or on one or more nodes of an Oracle Grid cluster where the Oracle ACFS file system is mounted. This functionality enables message communication between a node-local plugin enabled Oracle ACFS file system and an associated user space application module using Oracle ACFS plug-in application programming interfaces (APIs).

The plugin message APIs support both polling and posting message delivery models and multiple message payload types.

For information about Oracle ACFS plugin commands, refer to "Oracle ACFS Command-Line Utilities". For information about the Oracle ACFS plug-in application programming interface, refer to "Oracle ACFS Plug-in Generic Application Programming Interface".

High Availability Network File Storage for Oracle Grid Infrastructure

High Availability Network File Storage (NFS) for Oracle Grid Infrastructure provides uninterrupted service of NFS V2/V3/V4 exported paths by exposing NFS exports on Highly Available Virtual IPs (HAVIP) and using Oracle Clusterware agents to ensure that the HAVIPs and NFS exports are always online. While base NFS supports file locking, HANFS does not support NFS file locking.

Notes:

  • This functionality relies on a working NFS server configuration available on the host computer. You must configure the NFS server before attempting to use the Oracle ACFS NFS export functionality.

  • This functionality is not available on Windows.

  • This functionality is not supported in Oracle Restart configurations.

  • The HAVIP cannot be started until at least one file system export resource has been created for it.

To set up High Availability NFS for Oracle Grid Infrastructure, perform the following steps:

  1. Add and register a new HAVIP resource.

    For example:

    # srvctl add havip -id hrexports -address my_havip_name 
    

    In the example, my_havip_name is mapped in the domain name server (DNS) to the VIP address and is used by the client systems when mounting the file system.

    The initial processing of srvctl add havip ensures that:

    • The address being used is static, not dynamic

    • Any DNS names resolve to only one host, not round-robin multiple DNS resolutions

    • The network resource and provided IP address and resolved name are in the same subnet

    • The name is not in use

    SRVCTL creates the appropriate HAVIP name using the id, ensuring it is unique. As a final validation step, SRVCTL ensures that the network resource (if provided) of ora.net#.network exists. After this step, SRVCTL adds a new havip of type ora.havip.type with the name of ora.id.havip. In this example, the name is ora.hrexports.havip.

    Next SRVCTL modifies HAVIP start dependencies, such as active dispersion; sets the stop dependencies; and ensures the description attribute (if provided) is appropriately set.

  2. Create a shared Oracle ACFS file system.

    High Availability NFS for Oracle Grid Infrastructure operates only with Oracle ACFS file systems configured for clusterwide accessibility and does not support Oracle ACFS file systems configured for access on particular subsets of cluster nodes. High Availability NFS is not supported with non-Oracle ACFS file systems.

    For information on creating an Oracle ACFS file system, refer to "Creating an Oracle ACFS File System".

  3. Register the Oracle ACFS file system.

    For example:

    $ srvctl add filesystem -device /dev/asm/d1volume1-295 -volume VOLUME1 \
      -diskgroup HR_DATA -mountpath /oracle/cluster1/acfs1
    

    See Also:

    Oracle Real Application Clusters Administration and Deployment Guide for information about the srvctl add filesystem command
  4. Create an Oracle ACFS file system export resource.

    For example:

    # srvctl add exportfs -id hrexports -path /oracle/cluster1/acfs1 \
      -name hrexport1
    

    After the file system export resource has been created, then you can start the HAVIP created in step 1 to export the file system using the srvctl start havip command.

    The NFS mount option FSID is added to any export options, in the range of one billion or higher to minimize potential collisions with other FSIDs that are set on the server. This FSID option provides for reliable fail over between nodes and allows the usage of snapshot mounting.

    The default mount and export options for configured exports are the defaults for the NFS server.

    Relative paths that are fully-qualified are converted to absolute paths. Relative paths that are not fully-qualified are not accepted as an export path.

    HAVIPs attempts to find the best server to run on based on available file systems and other running HAVIPs, but this dispersion only occurs during CSS membership change events, such as a node joining or leaving the cluster.

    Note:

    It is not recommended to start and stop exports individually; this functionality should be provided through the start and stop operations of HAVIP.

    When HAVIP is not running, exports can exist on different nodes. After the associated HAVIP is started, the exports gather on a single node.

    Clients that are using an export that is stopped while HAVIP is running raise the NFS error estale, and must dismount and remount the file system.

See Also:

Overview of Oracle ASM Dynamic Volume Manager

Oracle ASM Dynamic Volume Manager (Oracle ADVM) provides volume management services and a standard disk device driver interface to clients. File systems and other disk-based applications send I/O requests to Oracle ADVM volume devices as they would to other storage devices on a vendor operating system.

An Oracle ADVM volume device is constructed from an Oracle ASM dynamic volume. One or more Oracle ADVM volume devices may be configured within each Oracle ASM disk group. The Oracle ADVM Driver maps I/O requests against an Oracle ADVM volume device to blocks in a corresponding Oracle ASM dynamic volume and disk set located within an Oracle ASM disk group. An Oracle ADVM volume device exports Oracle ASM volume manager features and ensures that volume mirrors remain consistent in the face of abnormal system shutdowns, Oracle ASM instance failures, or system failures.

Oracle ADVM extends Oracle ASM by providing a disk driver interface to Oracle ASM storage allocated as Oracle ADVM volume files. You can use Oracle ADVM to create virtual disks that contain file systems. These file systems contained on Oracle ADVM volumes are able to support files beyond Oracle Database files, such as executable files, report files, trace files, alert logs, and other application data files. Because Oracle ADVM volumes are actually Oracle ASM files, they require the same administrative privileges as the Oracle ASM files.

Oracle Automatic Storage Management Cluster File System (Oracle ACFS) communicates with Oracle ASM through the Oracle ADVM interface. With the addition of the Oracle ADVM, Oracle ASM becomes a complete storage solution of user data for both database and non-database file needs.

To add a volume to an Oracle ASM disk group, disk group attributes COMPATIBLE.ASM and COMPATIBLE.ADVM must be set to '11.2'.

Note:

Dynamic volumes supersede traditional device partitioning. Each volume is individually named and may be configured for a single file system. Oracle ADVM volumes may be created on demand from Oracle ASM disk group storage and dynamically resized as required. These attributes make Oracle ADVM volumes far more flexible than physical devices and associated partitioning schemes.

The Oracle ADVM functionality includes the following: