Requirements for Oracle Source Hosts and Databases
Delphix Administration / Oracle Environments and Data Sources / Oracle Support and Requirements / Requirements for Oracle Source Hosts and Databases

This topic describes the requirements for Oracle source environments and databases. Virtual databases (VDBs) are created from these source environments

Source Host Requirements

  1. Create an operating system user (delphix_os). This user is easily created by the createDelphixOSUser.sh script (located at the bottom of the page).


    1. Profile and privileges should be the same as the Oracle user (i.e. oracle) on the host. 
      For example, delphix_os should have the same environment variable settings ($PATH, $ORACLE_HOME, etc.), umask, and ulimit settings, as oracle.

      Shortcut: Source the oracle login script from the delphix_os login script.

    2. Group memberships:

      1. The primary OS group of the Delphix Engine software owner account's (i.e. delphix_os) should be the same as the Oracle software owner account (i.e. oracle).  In most cases, this is an OS group named oinstall.  There are lots of cases where the OS group named dba fills this role, so be sure to check the group membership of the Oracle software owner account.

        Oracle Inventory OS group

        The explanation of which OS group is primary on all Oracle software owner accounts is documented in the "Oracle12c Database Installation Guide" in the chapter on "Configuring Users, Groups, and Environments for Oracle Database", which states explicitly that the OS group for the Oracle Inventory oinstall should be primary.  However, please be aware that not all Oracle installations necessarily follow these guidelines.

      2. If the Oracle OSDBA group (typically dba) is not already the primary OS group of the Delphix software owner account (i.e. delphix_os), then it must be set as a secondary group.

        The reason Delphix Engine software owner account (i.e. delphix_os) must have membership in the same OS groups as the Oracle software owner (i.e. oracle), specifically in the OSDBA group, is so that the engine can execute the Oracle RMAN executable, which to do so requires connection to the database instance as SYSDBA.

        OS accounts belonging to the OSDBA group can employ "OS authentication" when connecting to an Oracle database instance by not specifying a username or a password (i.e. rman target /), thus eliminating the need to store or retrieve a SYSDBA password.

        Oracle 12c

        For Oracle 12c and later versions of Oracle databases which provide better role separation, the delphix_os user can also use OSBACKUPDBA as its secondary group. This is typically the backupdba group on the host.  For more information, please refer to the "Oracle12c Database Installation Guide" in the chapter sub-section on "Extended Oracle Database Groups for Job Role Separation".

      3. If the Oracle ASM ownership groups (typically asmadmin and asmdba) exist on the host, they should be assigned to the Delphix Engine software owner account (i.e. delphix_os) as secondary groups.

        Summary

        An excellent "rule of thumb" to follow is that the setup of OS groups for the Delphix Engine software owner account (i.e. delphix_os) should be the same as for the Oracle software owner account (i.e. oracle).

  2. There must be a directory on the source host where the Delphix Engine Toolkit can be installed, for example: /var/opt/delphix/Toolkit.
    1. The delphix_os user and primary OS group (i.e. oinstall) must own the directory.
    2. The directory must have permissions -rwxrwx--- (0770),  but you can also use more permissive settings.

    3. At least 1.6 GB of storage is needed at the time of setting up the environment and at least 500MB of free space is required to allow refreshes and maintenance of the toolkit, especially during upgrades.

  3. The Delphix Engine must be able to make an SSH connection to the source host (typically port 22).


OS Specific Requirements

AIX

None

HP-UX

None

Solaris

On a Solaris host, gtar must be installed. Delphix uses gtar to handle long file names when extracting the toolkit files into the toolkit directory on a Solaris host. The gtar binary should be installed in one of the following directories:

Auto-Discovery Requirements (Highly Recommended)

Delphix can automatically discover your Oracle Homes and Databases by examining the inventory and oratab files, and by examining the listener setup to determine connection information.  Successful autodiscovery requires read access to these and related files.

In most environments, delphix_os group membership is sufficient to perform auto-discovery.

If you have overridden Oracle's group permission structure, you may need to modify privileges to allow auto-discovery.

Unless you have used a custom TNS_ADMIN setting, elevated access to ps (pargs on Solaris) is not required

You can skip autodiscovery and manually add Oracle Homes and Databases.

  1. The ORATAB file must exist (typically in /etc/oratab or /var/opt/oracle/oratab) and be readable by delphix_os.
  2. Read access to either /etc/orainst.loc or /var/opt/oracle/orainst.loc.
  3. Read access to the Oracle inventory file (inventory.xml) identified by the contents of orainst.loc (for example, $INVENTORY_HOME/ContentsXML/inventory.xml).

  4. Permission to run pargs on Solaris hosts and ps on AIX, HP-UX, Linux hosts, as super-user.
    This permission is usually granted via sudo authorization of the commands. See the topic Sudo Privilege Requirements for Oracle Environments for further explanation of this requirement, and Sudo File Configuration Examples for Oracle Environments for examples of file configurations.

Source Database Requirements

  1. Source databases must be in ARCHIVELOG mode to ensure that redo logs are archived.  (Mandatory).  Archive logs are required to make SnapSyncs consistent and provisionable.

  2. There must be a database user (delphix_db) created by the createDelphixDBUser.sh script (located at the bottom of the page).

    . This script is part of the HostChecker bundle and grants SELECT privileges on specific system tables for the user. See the topics  Using HostChecker to Validate Oracle Source and Target Environments for more about using the HostChecker bundle.

    Oracle pluggable databases

    For an Oracle pluggable database, there must be one database user (delphix_db) for the pluggable database and one common database user (c##delphix_db) for its container database. The createDelphixDBUser.sh script (located at the bottom of the page) should be run twice to create a CDB user and then a PDB user.

  3. Enable Block Change Tracking (BCT).  (Highly Recommended).  Without BCT, incremental SnapSyncs must scan the entire database.

    BCT is an Enterprise Edition feature.

    Patch Required

    In order to use BCT in versions, 10.2.0.5 and 11.2.0.2 (even for primary databases) Oracle installation should have a patch for Oracle Bug 10170431. Without this fix, BCT might use too much CPU. See MOS 10170431.8

    If an Oracle installation has already been patched or once the patch is applied, use the CLI to update the repository for this installation so that applied patches include Oracle bug number 10170431, this will let SnapSync know that the bug has been fixed. If the repository does not indicate that Oracle bug 10170431 has been addressed, SnapSync will show a warning about this bug for each SnapSync.

    See Updating repository for Oracle applied patches with the Command Line Interface

    See Linking Oracle Physical Standby Databases for restrictions on enabling BCT on Oracle Physical Standby databases.

    Enter this command to enable BCT:

    alter database enable block change tracking using file '<user specified file>';

    The "USING FILE user_specified_file" clause defines the location of the change tracking file on the OS. This can be omitted by enabling OMF (Oracle-Managed Files).


  4. Enable FORCE LOGGING.  (Highly Recommended). This prevents NOLOGGING operations on Source Databases. Oracle requires FORCE LOGGING for proper management of standby databases. 

    Enter this command to enable FORCE LOGGING:

    SQL> ALTER DATABASE force logging;

    If you do not enable FORCE LOGGING and NOLOGGING operations take place, you will get a Fault from the Delphix Engine. If you must use NOLOGGING to meet specific performance criteria, take a new snapshot of the source database after doing the NOLOGGING operations to bring the dSource up-to-date before provisioning VDBs. To avoid repeated Faults, you can disable "Diagnose Nologging" on your dSource.

  5. If the online redo log files are located on RAW or ASM devices, then the Delphix Engine LogSync feature can operate in Archive Only mode only. See the topics Advanced Data Management Settings for Oracle dSources and Linking Oracle Physical Standby Databases for more information.

Additional requirements for RAC Sources

Masked Provisioning is not supported on Oracle RAC.


If the source host is a node in a RAC cluster, Delphix will attempt to use all nodes and crsctl for it's operations.  

  1. delphix_os must exist on all nodes in the cluster.
  2. Access to olsnodes is needed.
  3. delphix_os must have the same configuration on all nodes in the cluster, including profile, ulimits, user id, group membership, etc.
  4. The Delphix Toolkit must be installed in the same directory on each of the nodes in the source cluster

  5. delphix_os must have execute permission on crsctl and srvctl on each node in the cluster.

    Example: This shows that the group dba has read/write/execute permission on the database resources

    $ crsctl get hostname
node2
 
  6. All data files and archive logs must be located on storage shared by all of the cluster nodes. Each node in the cluster must be able to access archive logs from all other nodes. The database control file must also reside on shared storage accessible from all cluster nodes. This is an Oracle Best Practice, and a requirement for Delphix.

Troubleshooting Add Environment

LDAP/NIS User

If the delphix_os user is a LDAP/NIS user, it must be a member of the dba and oinstall groups in /etc/groups locally in order for Oracle commands to run properly.

  1. Read access to $ORACLE_HOME and all underlying files and directories.
  2. The delphix_os user must have read and execute permissions on each directory in the path leading to the toolkit directory. For example, when the toolkit is stored in /var/opt/delphix/Toolkit, the permissions on /var, /var/opt, and /var/opt/delphix should allow read and execute for ‘others’ (for example, -rwxr-xr-x).

Troubleshoot Source Linking

For each Oracle Home which you will use with dSources, the delphix_os user should have:
  1. Execute permission for the programs in $ORACLE_HOME/bin.
  2. The $ORACLE_HOME/bin/oracle executable must have the  SETUID and SETGID flags set. Permissions on the oracle binary must be -rwsr-s–x (06751) but you can also use more permissive settings.

If symlinks are configured (multiple symlinks pointing to the same physical ORACLE_HOME ), Delphix must be configured with the same $ORACLE_HOME path as was used when starting the instance. Failure to do so will result in RMAN throwing "ORA-27101: shared memory realm does not exist" errors.

Ensure the PermitUserEnvironment configuration parameter = "yes" in the sshd_config file

ExaCC Support

Delphix does not support Oracle Database Exadata Cloud at Customer (ExaCC).

Scripts

createDelphixOSUser.sh