Monday, October 6, 2025

EBS R12.2 + Database 19c — Change Hostname / Domain

 

EBS R12.2 + Database 19c — Change Hostname / Domain

Scope: 

Oracle E‑Business Suite R12.2.x with Database 19c, single‑node or two‑tier (Apps + DB on separate hosts). This step‑by‑step runbook consolidates guidance from Oracle Support Docs 1277556.1 (hostname change for EBS R12) and 759225.1 (change hostname/domain/IP for EBS instances).

Use cases: Hostname change, domain change (FQDN), IP change (with or without hostname change). Works for dev/test/prod; always test on a clone first.

0) High‑Level Plan

  1. Back up & prep

  2. OS change (hostname/domain, /etc/hosts)

  3. Database tier: refresh context → AutoConfig

  4. Apps tier: sync DB host → AutoConfig

  5. FND_NODES cleanup → AutoConfig (Apps)

  6. Restart & validate

  7. Post‑change (scripts, monitoring, integrations)

  8. (Optional) RAC/Data Guard considerations

1) Pre‑Requisites & Backups

  • Confirm current host and domain:

    hostname
hostname -f
hostname -d

  • Note current context files (DB & Apps tiers):

    echo $CONTEXT_FILE

  • Backups (choose as per your policy):

    • DB backup (RMAN or snapshot/AMI)

    • Apps tier file system (FS1/FS2), INST_TOP, and config directories

    • $ORACLE_HOME/network/admin (listener.ora, tnsnames.ora, sqlnet.ora)

    • Both context files (*.xml)

  • Change window: ensure outage window and approvers are aligned.

Tip (EBS R12.2): If DB tier’s $ORACLE_HOME/appsutil is old/missing, refresh it later with admkappsutil.pl from Apps tier (see §3.1).

2) OS‑Level Hostname/Domain/IP Change

  1. Update the system’s hostname and (if applicable) domain/FQDN. Typical on RHEL‑like systems:

    • /etc/hostname → set new hostname

    • /etc/hosts → map IP to new FQDN and short name

  2. Verify name resolution (getent hosts <new-fqdn>).

  3. Reboot or apply changes dynamically (per OS standard).

  4. Re‑check:

    hostname ; hostname -f ; hostname -d

If only the domain changes (same short host): still proceed with the same steps; EBS binds to the FQDN stored in context.

3) Database Tier

3.1 Stop DB and Prepare Appsutil (if needed)

  • Stop DB (srvctl or sqlplus, per your setup):

    srvctl stop database -d <DB_UNIQUE_NAME> -o immediate
# or
sqlplus / as sysdba <<EOF
shutdown immediate;
exit;
EOF

  • (Optional but recommended) Refresh appsutil on DB tier if outdated:

    # On Apps tier (run edition)
perl $AD_TOP/bin/admkappsutil.pl
# Copy appsutil.zip to DB server’s $ORACLE_HOME and unzip there

3.2 Regenerate DB Context File with New Hostname/Domain

cd $ORACLE_HOME/appsutil/bin
perl adbldxml.pl dbname=<DB_SID> contextfile=$CONTEXT_FILE

  • Open the resulting XML and verify:

    • <s_dbhost> = new host

    • <s_domainname> = new domain

    • Network ports (listener) correct

3.3 Run AutoConfig on DB Tier

cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>
./adautocfg.sh

  • This will regenerate listener.ora, tnsnames.ora, sqlnet.ora etc. with the new hostname/FQDN.

  • Validate the listener:

    lsnrctl status

4) Application Tier

4.1 Sync DB Host in Apps Context

  • Ensure the Apps tier context reflects the new DB host/domain:

    • Update s_dbhost, s_domainname, and any DB connect strings if present in Apps context.

4.2 Run AutoConfig on Apps Tier (Run Edition)

cd $ADMIN_SCRIPTS_HOME
./adautocfg.sh contextfile=$CONTEXT_FILE

  • This updates web/forms URLs, DB connect details, and other config to align with the new DB FQDN.

R12.2 note: Run AutoConfig on the run file system. AD utilities propagate to both run/patch contexts as needed.

5) FND_NODES Cleanup & Repopulate

Why: Old node/host entries in EBS can cause concurrent manager and service startup issues after a hostname/domain change.

  1. Connect as APPS:

    sqlplus apps/<apps_password>

  2. Inspect nodes:

    SELECT node_name, support_cp, support_web FROM fnd_nodes;

  3. Clean and repopulate:

    EXEC fnd_conc_clone.setup_clean;
COMMIT;

  4. Run AutoConfig again on the Apps tier to repopulate nodes:

    $ADMIN_SCRIPTS_HOME/adautocfg.sh

  5. Verify:

    SELECT node_name FROM fnd_nodes;

6) Restart & Validate

  • Start services (Apps/DB in your standard order):

    # DB up (if not already)
srvctl start database -d <DB_UNIQUE_NAME>

# Apps services
$ADMIN_SCRIPTS_HOME/adstrtal.sh <apps_user>/<apps_password>

  • Validate:

    • Access Login URL using the new hostname/domain

    • Concurrent Manager up & running

    • Workflow Mailer (if used) working

    • Sample report and form open

    • tnsping from Apps to DB shows the new FQDN

Profiles to sanity‑check (AutoConfig manages most, but verify):

  • APPS_FRAMEWORK_AGENT

  • APPS_SERVLET_AGENT

  • APPS_JSP_AGENT

  • ICX: Forms Launcher

7) Post‑Change Tasks

  • Update any custom scripts, integrations, and URLs referencing the old host/domain.

  • Update monitoring (OEM agents/targets, custom health checks, cron jobs).

  • For ETL/reporting servers, refresh connect strings.

8) Special Scenarios

8.1 RAC / Grid Infrastructure

  • If the DB is RAC:

    • Ensure the OS hostname change aligns with cluster naming. Host renames in RAC can be non‑trivial; coordinate with GI/CRS admin.

    • Update/verify srvctl configuration (database, instances, listeners):

      srvctl config database -d <DB_UNIQUE_NAME>
srvctl config listener -l LISTENER
srvctl config scan

    • If node names changed, follow GI procedures for node rename; then run AutoConfig on DB tier for each instance.

8.2 Data Guard / Standby

  • Update LOG_ARCHIVE_DEST_n, FAL_SERVER, FAL_CLIENT, and any tnsnames.ora entries on both primary and standby.

  • If using DG Broker:

    dgmgrl sys@<db_unique_name>
EDIT DATABASE <db_unique_name> SET PROPERTY StaticConnectIdentifier = '... new host ...';

  • Test switchover/connectivity after change.

8.3 Only Domain Change

  • Same steps apply. The critical part is regenerating context and running AutoConfig on both tiers so FQDNs update correctly.

8.4 IP Address Change Only

  • Ensure /etc/hosts and DNS reflect the new IP; AutoConfig will still update local configs. Validate lsnrctl status and client connectivity.

9) Troubleshooting

  • Apps won’t start / node mismatch: Re‑run fnd_conc_clone.setup_clean and AutoConfig on Apps tier; confirm FND_NODES matches the new host.

  • Forms/URL still shows old host: Recheck Apps context for s_webentryhost, s_login_page, and profiles listed above; re‑run AutoConfig.

  • Listener uses old host: Re‑run DB AutoConfig; check $ORACLE_HOME/network/admin files; bounce listener.

  • tnsping fails from Apps to DB: Confirm new tnsnames.ora was propagated; check firewall/security groups for any hostname‑based rules.

  • R12.2 dual FS confusion: Ensure you ran AutoConfig on the run edition. If in doubt, run it again after confirming the correct $CONTEXT_FILE.

10) Rollback (High Level)

  • Revert OS hostname/domain to original.

  • Restore original context files (DB & Apps) from backup.

  • Re‑run AutoConfig on DB tier, then Apps tier.

  • Validate services and URLs.

11) Change Record / Checklist (copy into your tracker)

  • Window approved; stakeholders notified

  • Backups taken (DB, FS, configs)

  • OS hostname/domain/IP changed; DNS/hosts updated

  • DB context regenerated (adbldxml.pl)

  • DB AutoConfig completed (no errors)

  • Apps context updated with new DB host/domain

  • Apps AutoConfig completed (no errors)

  • fnd_conc_clone.setup_clean executed; Apps AutoConfig rerun

  • Services restarted; validation passed

  • Integrations/scripts/monitoring updated

References

  • My Oracle Support Doc ID 1277556.1 – How to change hostname for E‑Business Suite Release 12 (single node)

  • My Oracle Support Doc ID 759225.1 – How to change IP/Hostname/Domain for an EBS instance

This article paraphrases Oracle guidance for operational use. Always consult the official notes for environment‑specific prerequisites and the latest updates.

Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)