Before registering each Oracle server in ECX, ensure it meets the following requirements.
|Database Versions/Types||Server Types||Operating Systems||Storage Configuration||Storage Systems|
Oracle 11g R2 or 12c   configured as:
Note: Support for Oracle 12c R2 will be available in a future release.
(VMware) [6, 7, 10, 11, 12]
 For Oracle 12c multitenant databases, ECX supports protection and recovery of the container database, including all pluggable databases under it. Granular recovery of specific PDBs can be performed via Instant Disk Restore recovery combined with RMAN.
 Standalone databases protected by ECX can be recovered to the same or another standalone server as well as to a RAC installation. When recovering from standalone to RAC, if the source database uses Automatic Storage Management, then it will be successfully recovered to all nodes in the destination cluster. If the source database uses non-ASM storage, the database will be mounted only on the first node in the destination RAC. Source disks for standalone databases restoring to a virtual RAC environment must be thick provisioned.
RAC databases protected by ECX can be recovered to the same or another RAC installation as well as to a standalone server. In order to recover a RAC database to a standalone server, the destination server must have Grid Infrastructure installed and an ASM instance must be running.
 Oracle DataGuard is not supported.
 Oracle Flex ASM is not supported.
 RAC database recoveries are not server pool-aware. ECX can recover databases to a RAC, but not to specific server pools.
 ECX supports recovering databases from a source physical server to a destination virtual server by provisioning disks as physical RDMs. Similarly, ECX can recover databases from a source virtual server that uses physical RDM to a destination physical server. However, source databases on VMDK virtual disks can only be recovered to another virtual server and not to a physical server.
 ECX does not support VADP-based protection of virtual Oracle servers. Oracle data must reside directly on one of the supported storage systems listed above.
 On AIX LPAR/VIO servers, Oracle data must reside on disks attached to the server using NPIV. Virtual SCSI disks are not supported.
 Linux LVM volumes containing Oracle data must use LVM version 2.02.118 or above. On SLES 11 SP4, this version of LVM may not be available through the official repositories, in which case, databases running on or recovered to SLES 11 SP4 systems must use ASM or non-LVM filesystems only.
 Masking and DevOps recoveries are not supported on virtual servers.
 See System Requirements for supported VMware vSphere versions.
 Oracle servers registered as virtual must have VMware Tools installed and running.
 Oracle 12c multithreaded configurations are not supported.
Note: Oracle database data and the flash recovery area (FRA) must reside on supported storage systems. ECX can back up archived logs to a supported storage system if they are not already on one.
For more information about Oracle requirements, see Oracle Database Support FAQ.
Oracle Support for VMware Virtual Machines
For Oracle servers running as VMware virtual machines, UUID must be enabled to perform Oracle-based Backup functions. To enable, power off the guest machine through the vSphere client, then select the guest and click Edit Settings. Select Options, then General under the Advanced section. Select Configuration Parameters..., then find the disk.EnableUUID parameter. If set to FALSE, change the value to TRUE. If the parameter is not available, add it by clicking Add Row, set the value to TRUE, then power on the guest.
Oracle support for VMware virtual machines requires Oracle data/logs to be stored on VMDK virtual disks or physical RDMs. Virtual RDM disks are not supported. The VMDKs must reside on a datastore created on LUNs from supported storage systems. Similarly, the physical RDMs must be backed by LUNs from supported storage systems.
For Oracle RAC clustered nodes running prior to vSphere 6.0, virtual machines cannot use a virtual SCSI controller whose SCSI Bus Sharing option is set to None. This is required to ensure that ECX can hot-add shared virtual disks to the cluster nodes. For vSphere 6.0 and above, this requirement does not apply. Instead, if an existing shared SCSI controller is not found on vSphere 6.0 and above, ECX automatically enables the "multi-writer" sharing option for each shared virtual disk.
When performing a database or filesystem restore from an XFS filesystem, the restore process may fail if the "xfsprogs" package version on the destination server is between 3.2.0 and 4.1.9. To resolve the issue, upgrade xfsprogs to version 4.2.0 or above.
- The bash and sudo packages must be installed. Sudo must be version 1.7.6p2 or above. Run
sudo -Vto check the version.
- Python version 2.6.x or 2.7.x must be installed.
- AIX only: If Oracle data resides on IBM Spectrum Accelerate storage, the IBM Storage Host Attachment Kit (also known as IBM XIV Host Attachment Kit) must be installed on the Oracle server.
- RHEL/OEL/CentOS 6.x only: Ensure the util-linux-ng package is up-to-date by running
yum update util-linux-ng. Depending on your version or distribution, the package may be named util-linux.
- RHEL/OEL/CentOS 7.3 and above: A required Perl module, Digest::MD5, is not installed by default. Install the module by running
yum install perl-Digest-MD5.
- Linux only: If Oracle data resides on LVM volumes, ensure the LVM version is 18.104.22.168 or later. Run
lvm versionto check the version and run
yum update lvm2to update the package if necessary.
- Linux only: If Oracle data resides on LVM volumes, the lvm2-lvmetad service must be disabled as it can interfere with ECX's ability to mount and resignature volume group snapshots/clones.
- Run the following commands to stop and disable the service:
systemctl stop lvm2-lvmetad
systemctl disable lvm2-lvmetad
- Additionally, disable lvmetad in the LVM config file. Edit the file /etc/lvm/lvm.conf and set:
use_lvmetad = 0
- The SSH service must be running on port 22 on the server and any firewalls must be configured to allow ECX to connect to the server using SSH. The SFTP subsystem for SSH must also be enabled.
- The server can be registered using a DNS name or IP address. DNS names must be resolvable by ECX.
- When registering Oracle RAC nodes, register each node using its physical IP or name. Do not use a virtual name or Single Client Access Name (SCAN).
- In order to mount clones/copies of Oracle data, ECX automatically maps and unmaps LUNs to the Oracle servers. Each server must be preconfigured to connect to the relevant storage systems at that site.
- For Fibre Channel, the appropriate zoning must be configured beforehand.
- For iSCSI, the Oracle servers must be configured beforehand to discover and log in to the targets on the storage servers.
- The Oracle server must be registered in ECX using an operating system user that exists on the Oracle server (referred to as "ECX agent user" for the rest of this topic).
- During registration you must provide either a password or a private SSH key that ECX will use to log in to the server.
- For password-based authentication ensure the password is correctly configured and that the user can log in without facing any other prompts, such as prompts to reset the password.
- For key-based authentication ensure the public SSH key is placed in the appropriate authorized_keys file for the ECX agent user.
- Typically, the file is located at /home/<username>/.ssh/authorized_keys
- Typically, the .ssh directory and all files under it must have their permissions set to 600.
The ECX agent user must have the following privileges:
- Privileges to run commands as root and other users using sudo. ECX requires this for various tasks such as discovering storage layouts and mounting and unmounting disks.
- The sudoers configuration must allow the ECX agent user to run commands without a password.
- The !requiretty setting must be set.
- The ENV_KEEP setting must allow the ORACLE_HOME and ORACLE_SID environment variables to be retained.
- Privileges to read the Oracle inventory. ECX requires this to discover and collect information about Oracle homes and databases.
- To achieve this, the ECX agent user must belong to the Oracle inventory group, typically named oinstall.
- SYSDBA privileges for database instances. ECX needs to perform database tasks like querying instance details, hot backup, RMAN cataloging, as well as starting/stopping instances during recovery.
- To achieve this, the ECX agent user must belong to the OSDBA operating system group, typically named dba.
- In the case of multiple Oracle homes each with a different OSDBA group, the ECX agent user must belong to each group.
- SYSASM privileges, if Automatic Storage Management (ASM) is installed. ECX needs to perform storage tasks like querying ASM disk information, as well as renaming, mounting, and unmounting diskgroups.
- To achieve this, the ECX agent user must belong to the OSASM operating system group, typically named asmadmin.
- Shell user limits for the ECX agent user must be the same as those for the user that owns the Oracle home, typically named oracle. Refer to Oracle documentation for requirements and instructions on setting shell limits. Run
ulimit -aas both the oracle user and the ECX agent user and ensure their settings are identical.
For examples on creating a new user with the necessary privileges, see Sample Configuration of an ECX Agent User.
ECX discovers Oracle installations and databases by looking through the files /etc/oraInst.loc and /etc/oratab, as well as the list of running Oracle processes. If the files are not present in their default location, the "locate" utility must be installed on the system so that ECX can search for alternate locations of these files.
ECX discovers databases and their storage layouts by connecting to running instances and querying the locations of their datafiles, log files, etc. In order for ECX to correctly discover databases during cataloging and copy operations, databases must be in "MOUNTED," "READ ONLY," or "READ WRITE" mode. ECX cannot discover or protect database instances that are shut down.
Databases must be started using a server parameter file (spfile). ECX does not support copy operations for databases that are started using a text-based parameter file (pfile).
When ECX mounts snapshots/clones of ASM disks, it configures the disks to set the appropriate permissions required to make them discoverable by ASM:
- The disk owner and group are set to the owner of the Grid installation and the OSASM group respectively. These are typically grid and asmadmin. ECX automatically discovers the appropriate owner and group information on each server.
- The disk permissions are set to 660.
Additionally, ECX creates aliases/symbolic links with names that follow a consistent pattern. To ensure that ASM is able to discover the disks mapped by ECX, you must update the ASM_DISKSTRING parameter to add this pattern.
ECX creates udev rules for each disk to set the appropriate ownership and permissions. The udev rules also create symbolic links of the form /dev/ecx-asmdisk/<diskId> that point to the appropriate device under /dev.
To ensure the disks are discoverable by ASM, add the following pattern to your existing ASM_DISKSTRING:
ECX creates a device node (using mknod) of the form /dev/ecx_asm<diskId> that points to the appropriate hdisk under /dev. ECX also sets the appropriate ownership and permissions for this new device.
To ensure that the disks are discoverable by ASM, add the following pattern to your existing ASM_DISKSTRING:
- If the existing value of the ASM_DISKSTRING is empty, you may have to first set it to an appropriate value that matches all existing disks, then append the value above.
- If the existing value of the ASM_DISKSTRING is broad enough to discover all disks (for example,
/dev/*), you may not need to update it.
- Refer to Oracle documentation for details about retrieving and modifying the ASM_DISKSTRING parameter.
The commands below are examples for creating and configuring an operating system user that ECX will use to log in to the Oracle server. The command syntax may vary depending on your operating system type and version.
- Create the user that will be designated as the ECX agent user:
useradd -m ecxagent
- Set a password if using password-based authentication:
- If using key-based authentication, place the public key in /home/ecxagent/.ssh/authorized_keys, or the appropriate file depending on your sshd configuration, and ensure the correct ownership and permissions are set, such as:
chown -R ecxagent:ecxagent /home/ecxagent/.ssh
chmod 700 /home/ecxagent/.ssh
chmod 600 /home/ecxagent/.ssh/authorized_keys
- Add the user to the Oracle installation and OSDBA group:
usermod -a -G oinstall,dba ecxagent
- If ASM is in use, also add the user to the OSASM group:
usermod -a -G asmadmin ecxagent
- Place the following lines at the end of your sudoers configuration file, typically /etc/sudoers. If your existing sudoers file is configured to import configuration from another directory (for example, /etc/sudoers.d), you can also place the lines in a new file in that directory:
ecxagent ALL=(ALL) NOPASSWD:ALL
Catalogic ECX™ 2.7.3
© 2018 Catalogic Software, Inc. | All rights reserved.