No announcement yet.

Cloning 6.4.1 PROD to non-PROD

  • Filter
  • Time
  • Show
Clear All
new posts

  • Cloning 6.4.1 PROD to non-PROD

    Here is my scenario:
    * existing 6.4.1 PROD environment, including 2 Load Balanced Web Servers and 2 App Servers configured for SCA
    * existing 6.4.1 TEST environment, including a single combined Web/App node
    * we want to clone the PROD database to the TEST environment, intending to keep the TEST Web/App node essentially intact as is.

    Steps in our process:
    1) clone/refresh entire PROD database to TEST using standard Oracle DB processes (RMAN).
    2) Update SCA-related tables to restore the database to non-SCA default values
    3) Run RCU in TEST to create new MDS Repository schemas (identical prefix ID's to previous TEST DB incarnation)
    4) update "system" and "guest" passwords using to set new authentication credentials

    Issue: WebLogic server process for App tier fails to start

    A) Error from console.log.0 = Caused by: eConnectivityException: JPS-00027: There was an internal error: java.sql.SQLException: ORA-01017: invalid username/password; logon denied
    A-1) Above error is resolved by performing Step #4 above (resetting "system" and "guest" passwords).

    B) New errors (partial listing) from console.log.0 = INFO | 2017/07/20 11:14:12 | <Jul 20, 2017 11:14:12 AM CDT> <Error> <Security> <BEA-090892> <The loading of an OPSS java security policy provider failed due to an exception.
    INFO | 2017/07/20 12:35:11 | WARNING: Could not create credential store instance. Reason eption: JPS-01013: The credential store DN cn=CredentialStore,cn=opssSecurityStore,cn=JPSCont ext,cn=opssRoot is missing in the store; the target DN must be pre-configured.

    Open SR with Oracle Support indicates they have never tested this scenario with WebLogic, and that it may fail no matter what we do.

    Workaround is to blow away the OTM App server configuration and rerun the installer to create a new WebLogic domain and MDS Repository Schemas. I know this will work, but it is not a practical solution for routine clone/refresh tasks.

    Has anyone accomplished a similar procedure successfully?

    Paul S.

    Last edited by pgsteffen; July 28, 2017, 15:21.

  • #2
    Resolution update:

    Because our environment includes storing the WebLogic MDS Repository schemas in the same database as the main OTM schemas, a FULL DATABASE CLONE brings along the source MDS metadata which does not match what the target WebLogic system expects - therefore breaking the MDS component.

    Fixing this issue requires a full cleanup of the OTM_HOME and WLS domains, purging the existing MDS schemas and reinstalling the OTM code stack.

    Oracle's recommended solution is to store the MDS schemas in a database separate from the main OTM schemas.

    WORKAROUND #1: export the MDS metadata prior to the database refresh, then import the "good" metadata back into the cloned database (not tested).
    WORKAROUND #2: export only the required OTM schemas from the source database and import into the target database (this is the process we are using going forward).

    Paul S.
    Last edited by pgsteffen; August 16, 2017, 15:28.