You are here: Setup > Oracle Requirements

Oracle Requirements

Review the following requirements and pre-requesities for registering an Oracle provider in ECX.

Registration and Authentication

Each individual Oracle server should be registered as a provider in ECX. Like any other provider, it can registered by name or IP address. Ensure the name is resolvable by ECX.

When registering an Oracle RAC cluster, register each node using its physical IP or name. Do not register a virtual name or SCAN (Single Client Access Name). Ensure the server has the SSH service running and configure any firewalls to allow ECX the ability to connect to the Oracle server through SSH.

ECX can connect to the Oracle server as a local operating system user using a password or an SSH key. To use a password, select or create a credential of type "Local". To use a key, enter a username and select or create an SSH key. See Identities Overview.

When using a key, the username must exist as a local user on the Oracle server. For password-based authentication, the password must be correctly configured for the appropriate user on the Oracle server. For key-based authentication, the public key must be placed in the authorized_keys file for the appropriate user on the Oracle server.

In order to resolve the DNS short names of Oracle hosts and append DNS suffixes, you must run a pre-installed script through an ECX Script policy.

Click Plan tab. On the View pane select Policies , then click New.
Select Script in the System column. The Script policy editor opens.
In the Enter a new command field, enter the following:
sudo /opt/ECX/tools/scripts/update_resolv.py [DNS address to search]
Note: Separate multiple addresses with a space.
For example, sudo /opt/ECX/tools/scripts/update_resolv.py abc.catalogic.us xyz.catalogic.us
Press Enter to add the command to the script policy.
In the Schedule tab, schedule a time to run the policy, or select Start job now to run the job once the policy creation is complete.
Click Finish to save the policy.

Privileges

ECX connects to the Oracle server as the local operating system user specified during registration in order to perform tasks like cataloging, data protection, and data restores. ECX also logs into local database and ASM instances as this user through password-less OS authentication. Therefore, the user must have all the privileges ECX needs to perform its tasks.

ECX requires the following privileges:

Root privileges for the operating system - Required for tasks such as discovering storage information, rescanning iSCSI sessions, and mounting and unmounting disks.
Permissions to read the Oracle inventory - Required to discover and collect information about Oracle homes and databases.
SYSDBA privileges for database instances - Required to perform several database tasks such as querying instance details, starting and ending hot backup mode and performing RMAN cataloging during backups, as well as starting and stopping instances during restore.
SYSASM privileges for ASM instances - Required to perform several storage tasks such as querying ASM disk information as well as renaming, mounting, and unmounting diskgroups during restore.

To ensure that the local user has each of the necessary privileges:

Configure sudo to allow the user to run commands without a password and without a tty.
Add the user to the operating system group that owns the Oracle inventory (typically oinstall).
Add the user to the OSDBA operating system group for each Oracle Home (typically dba).
Add the user to the OSASM operating system group for the Grid Home (typically asmadmin). This step is not required if ASM is not in use on the server.

For example, to create a new operating system user named ecxagent for ECX to log in to the Oracle server and grant it the necessary privileges:

# Create the user

useradd -m ecxagent

# Set a password (if using password-based authentication)

passwd ecxagent

# If using key-based authentication, place the public key in

# /home/ecxagent/.ssh/authorized_keys and set the correct permisions

chown -R ecxagent:ecxagent /home/ecxagent/.ssh

chmod 0700 /home/ecxagent/.ssh

chmod 0600 /home/ecxagent/.ssh/authorized_keys

# Add the user to the necessary groups

usermod -a -G oinstall,dba ecxagent

usermod -a -G asmadmin ecxagent # Only if ASM is in use

# Create the file /etc/sudoers.d/ecxagent with the following contents:

Defaults:ecxagent !requiretty

ecxagent ALL=(ALL) NOPASSWD:ALL

SAN Configuration

In order to mount clones/copies of Oracle data, ECX automatically maps and unmaps LUNs to the Oracle servers. Each Oracle server must be pre-configured to connect to the relevant storage servers at that site. In the case of Fibre Channel, the appropriate zoning configuration must be configured beforehand. In the case of iSCSI, the initiators on the Oracle servers must be configured beforehand to discover and log in to the targets on the storage servers.

ASM Disk Discovery

In order to mount clones/copies of ASM disks, ECX automatically creates udev rules on the Oracle server to change the ownership of the newly mapped disks. The udev rules ensure that the disks are owned by the owner of the Grid Home so that the ASM instance can discover and mount them. They also ensure that for each ASM disk mapped by ECX, a symbolic link of the form /dev/ecx-asmdisk/<diskuuid> is created and points to the parent disk.

Depending on the existing settings of the ASM_DISKSTRING parameter, ASM may not always be able to discover the cloned/copied disks. To ensure that ASM is able to discover the disks mapped by ECX, modify the existing ASM_DISKSTRING parameter and append the following value: /dev/ecx-asmdisk/*.

Note: 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, and then append the value above.

Refer to Oracle documentation for details about retrieving and modifying the ASM_DISKSTRING parameter.

RMAN Considerations

ECX does not manage retention policies for RMAN catalogs or archived log locations including any additional log destinations that may be enabled as part of an ECX copy policy. Only the retention policies specified by the database administrator will apply.