Saturday, January 12, 2013

Cloning Issue—What If Host Name(s) Are Stored in the Database

This article is a follow-up to the previous article:
As pointed out in that article, there are limitations and issues with cloning—either an application or a database. This article describes one of the issues (see also [23, 4]): when host names are stored in the database tables.


In [1], we have outlined the cloning tasks step by step.  In this article, we will discuss one of the cloning issues:
  • If host name(s) are stored in the database tables
To do cloning (see [3]), we need to duplicate a software installation from a source to a destination.  As described in [1], you can use /etc/hosts file to simplify the cloning task by redirecting host name resolution on Linux. However, if the host name is stored in the database table and not yet listed in the hosts file, your application can still fail.

In the following section, we will describe one use case that showcases this issue.

ADF Task Flow

A user would like to change the host name of a Redhat Linux which hosts SOASuite and WebCenter.  After following the approach as described in [1] using hosts file.  He found out that his workflow still wasn't working correctly.

When he opened a task, the browser tried to connect to:

and he has found that localhost.localdomain still pointed to the previous host.  Now the server doesn't know how to resolve this name and asks browsers to connect to that host.

After some diggings, he has finally identified that there is a setting in the WFTASKDISPLAY table of SOAINFRA schema, which still keeps the previous host name.  Presumably, when a task was deployed, previous host name was stored there and caused the malfunction of his ADF task flow.

To be honest, this is a case reported by another user.  So, I might have described it wrong.  However, it does point out a potential problem—if you have renamed a server and some other servers may not recognize that old name anymore because the old host name is stored in the database.  So, you need to change hosts file on those machines too to redirect the mapping of the old name to the new IP address.


  1. Simplify Cloning by Using Hosts File
  2. ORA-00313: open failed for members of log group 1 of thread 1
  3. Using rsync to Clone Local and Remote Systems
  4. ORA-01031: insufficient privileges
  5. Migrating Oracle B2B from Test to Production (T2P) (Chap 10 of the Book "Getting Started with Oracle SOA B2B Integration: A Hands-On Tutorial")
    • This section provides a real-world scenario to replicate (clone) the test environment to production for Oracle SOA.
    • Oracle Fusion Middleware provides a series of scripts for this task.
  6. Oracle Products: What Patching, Migration, and Upgrade Mean? (Xml and More)
    • For your Oracle production systems, follow official recommendations as shown in this article.

No comments: