3.1 Overview of Oracle Exadata Deployment Assistant

Use Oracle Exadata Deployment Assistant (OEDA) to specify the system configuration details and drive the system configuration processes.

OEDA provides a graphical user interface to gather your configuration details and create the Oracle Exadata Rack configuration file. The configuration file drives the automated installation and configuration processes for Oracle Exadata Rack.

Note:

For ease of reading, Oracle Exadata Rack is used when information refers to both Oracle Exadata and Oracle Exadata Storage Expansion Rack.

You can also use the OEDA command-line interface (OEDACLI) to perform Oracle Exadata Rack life-cycle management tasks.

You can download the latest version of OEDA from Exadata Database Machine and Exadata Storage Server Supported Versions (My Oracle Support Doc ID KB153930). OEDA is also available on Oracle Technology Network.

In addition to Oracle Exadata Rack, OEDA is also used for Oracle Zero Data Loss Recovery Appliance and Oracle SuperCluster.

Oracle Exadata System Software release 19.1.0 introduced the Web-based interface for OEDA, which replaces the previous Java-based user interface as the graphical user interface for configuring Oracle Exadata Rack.

The following outlines how OEDA is used during the implementation of Oracle Exadata Rack:

• Before your engineered system arrives, do the following:

  1. Work with your network and database administrators to evaluate the current network settings, such as current IP address use and network configuration. OEDA supports IPv6 addresses.

  2. Define the settings for the rack, such as network configuration and backup method.

  3. If you intend to configure LDAP or another SSSD-backed directory on your new Oracle Exadata system, review your directory implementation for potential conflicts with Oracle Exadata operating system users and groups.

     Starting with Oracle Linux 9, the default Name Service Switch (NSS) order for user and group lookups in /etc/nsswitch.conf places SSSD before local files (sss files rather than files sss). If LDAP or another SSSD-backed directory contains a UID or GID that conflicts with a local Exadata account or group, NSS can resolve the directory identity instead of the local Exadata identity.

     Such conflicts can cause dbmsrv service accounts on Oracle Exadata database servers, including dbmsvc, dbmadmin, and dbmmonitor, to use an unexpected identity or group membership. Resulting ownership or access-control failures can prevent Exadata management services from starting or operating correctly.

     Before configuring LDAP/SSSD on a new system, or upgrading an existing system to release 26.2.0, identify UID and GID conflicts between the directory service and local dbmsrv service users and groups. For details about the local dbmsrv service users and groups, including their corresponding UIDs and GIDs, see Overview of the dbmsrv Service.

     If conflicts exist, either change the conflicting directory entries or migrate the local dbmsrv user and group IDs by using /opt/oracle.SupportTools/migrate_ids.sh. See Changing User IDs and Group IDs for dbmsrv for the supported procedure and additional considerations.

     Do not manually change /etc/nsswitch.conf as a workaround because future updates can overwrite that change. The migrate_ids.sh procedure applies only to dbmsrv service users and groups on database servers, including bare-metal servers, KVM hosts, and guests.

     Identity conflicts on Oracle Exadata storage servers are unlikely because the predefined storage server groups use reserved GIDs below 1000 and the predefined user accounts use UIDs from 1000 through 1010. If an LDAP/SSSD identity conflict is identified on a storage server, contact Oracle Support for assistance.

     If you choose to resolve potential conflicts by modifying the conflicting directory entries, make the required directory changes before deploying the engineered system. Otherwise, complete the initial deployment using OEDA, migrate the IDs using migrate_ids.sh, and configure LDAP/SSSD only after the migration succeeds.

  4. Download and install (unzip) the latest version of OEDA from Oracle Technology Network.

  5. If you are using a version of OEDA released in conjunction with Oracle Exadata System Software release 26.1.0 or later, ensure that any system running OEDA programs contains Java Development Kit (JDK) version 17 or later. JDK version 25 (Java 25) is recommended in conjunction with Oracle Exadata System Software release 26.2.0 or later. You can download a supported JDK from https://www.oracle.com/java/technologies/downloads/.

     Before running any OEDA program, check the following to ensure that the required JDK is installed and available:

     • Ensure that the JAVA_HOME environment variable references the intended JDK.

     • Ensure that JAVA_HOME/bin/java is executable.

     • Run java --version and confirm that the output reports the required Java version.

  6. Run the configuration interface on a supported platform.

     See Getting Started with the OEDA Browser-Based User Interface.

  7. Go through every page in OEDA and supply values for all required fields. You cannot advance to the next page if you do not supply all of the required values. You must provide various naming details, networking details (including DNS and NTP servers), and other configuration details.

  8. At the end of the dialogue with OEDA, configuration files are generated on the client. The files are also listed at the bottom of the InstallationTemplate.html file that is generated by OEDA. Depending on your engineered system and configuration, OEDA generates all or some of the following files:

     • databasemachine.xml
     • CustomerName-rackname.xml
     • CustomerName-rackname-preconf_GUID.csv
     • CustomerName-rackname-InstallationTemplate.html
     • CustomerName-rackname-platinum.csv
     • CustomerName-rackname-checkip.sh
     • CustomerName-rackname.zip
     • pkey_GUID.csv and pkey_racknamehostname_GUID.csv — if you enabled InfiniBand partitioning for your virtual environments

     The CustomerName-hostname.zip file contains all the generated files.

  9. Review the InstallationTemplate.html file to check the entire configuration and verify all information was entered correctly.

• Shortly before your engineered system arrives, or is scheduled to be configured, validate the network configuration, as directed by Oracle. See Verifying the Network Configuration Prior to Configuring the Rack.

• After your engineered system arrives, the configuration files are copied to a database server, and the validation and installation is completed.

  See Configuring Oracle Exadata Database Machine Using Oracle Exadata Deployment Assistant.

• Considerations and Requirement for Using OEDA
  Review this information before using Oracle Exadata Deployment Assistant (OEDA).