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.

Upgrade Oracle E-Business Suite R12.2.13 → R12.2.14

 

Step by Step Guide to Upgrade Oracle E-Business Suite R12.2.13 → R12.2.14

Hello Everyone 👋,

In this blog, I am sharing my Apps DBA approach for upgrading Oracle E-Business Suite (EBS) from R12.2.13 to R12.2.14. This guide is simplified, practical, and includes Oracle Doc IDs, patch references, ETCC steps, and timelines so that both DBAs and Management can follow easily.

---

🔹 Why Upgrade to R12.2.14?

• Latest certified release of Oracle E-Business Suite.

• Enhanced security fixes, stability improvements, and new features.

• Keeps environment aligned with Oracle Support timelines.

• Foundation for future EBS roadmap.

---

📌 Pre-Upgrade Checklist

1. Database Version: Must be 19c (minimum 19.17 or latest RU).

2. Operating System: RHEL 7 or 8 certified.

3. Backups:

   • Take AMI backups (if on AWS EC2).

   • RMAN full DB backup + Apps tier filesystem backup.

4. ETCC Check (Doc ID 1594274.1):

   • Download the latest ETCC.

   • Run on DB + App nodes.

   • Identify and apply missing patches.

---

🔹 Step 1: Apply ETCC Patches

• Download the latest ETCC (Oct 2024 release) from Oracle Support.

• Apply missing Database and Middleware Technology Patches.

• Re-run ETCC until environment is clean.

📖 Reference: Oracle Doc ID 1594274.1

---

🔹 Step 2: Apply Latest AD and TXK Delta Release Update Packs

Before applying the R12.2.14 patch, ensure AD/TXK is up-to-date.

• Apply the following patches:

  • R12.AD.C.Delta.16

  • R12.TXK.C.Delta.16

• These packs include structural changes (e.g., EBS_SYSTEM schema) and upgrade utilities.

📖 Reference: Oracle Doc ID 1617461.1

---

🔹 Step 3: Apply R12.2.14 Upgrade Patch

• Download and apply R12.2.14 Release Update Pack (Patch 35570137).

• Use adop in online mode for minimum downtime.

• Post-Upgrade Steps:

  • Run AutoConfig on all tiers.

  • Compile invalid objects.

  • Validate Concurrent Managers.

📖 Reference: Oracle Doc ID 2484000.1

---

🔹 Step 4: Post-Upgrade Validation

• DBA Validation: Invalid objects, schema compilation, DB logs review.

• Functional Testing:

  • Forms, Reports, Interfaces, and Customizations.

• Testing Cycles:

  • Unit Testing

  • SIT/UAT

  • Regression Testing

---

📊 Suggested Upgrade Timeline (POC/Test Run)

Phase	Task	Duration
Phase 1	AMI + DB Backups	0.5 Day
Phase 2	ETCC Patching	1 Day
Phase 3	Apply AD/TXK Delta 16	1.5 Days
Phase 4	Apply R12.2.14 Patch	2 Days
Phase 5	Post-Upgrade Validation & Handover	1 Day
Total	~6 Days

---

📂 Key Oracle References

• Doc ID 1594274.1 – Using ETCC for DB + Middleware Patching

• Doc ID 1617461.1 – Applying Latest AD and TXK Delta Packs

• Doc ID 2484000.1 – Oracle EBS R12.2.14 Readme

---

🔹 Flowchart – Upgrade Path

Here’s a simple visual flow you can insert into the blog for management clarity:

Start → Backup (AMI + RMAN) → ETCC Patches → AD/TXK Delta 16 → Apply R12.2.14 Patch → Post-Upgrade Validation → Handover

Start → Backup → ETCC → AD/TXK Delta 16 → R12.2.14 Patch → Validation 

---

✅ Conclusion

Upgrading to Oracle EBS R12.2.14 is not just a patching exercise — it’s a strategic move to keep your enterprise system secure, compliant, and future-ready.

My recommendation:

• Always start with a POC in TEST environment.

• Document backups, ETCC results, and validation steps.

• Share timelines with Management before Production cutover.