In my previous blog named “Changing Fusion Middleware Forms and Reports repository database“, I explained how to move a Fusion Middleware Forms and Reports repository from one database to a new database where some other repositories already exist. In this blog, I will explain how to move Fusion Middleware repositories from one database to a brand new database.
The Fusion Middleware repository database migration has been done following the Oracle Fusion Middleware 12.2.1.4 – Administering Oracle Fusion Middleware documentation. The following restrictions applies to this kind of move:
- The service name and SID of the database on the target host must be the same as on the source host.
- The port on the target host must be the same as on the source host.
- The database on the target host must contain the same schemas as on the source host and the schemas must have the same prefix as on the source host.
The Repository Creation Utility (RCU) gives the possibility to create SQL scripts to create the system tables and information plus the Fusion Middleware product repository schemas and tables. We will use this functionality to configure the new database to host the migrated repository.
Using the RCU located in the $ORACLE_HOME/oracle_common/bin directory of the Fusion Middleware product I want to migrate the repository, I will generate the scripts that will create all needed objects in the target database for this database to become a Fusion Middleware repository database. Below are the steps I run to archive this.
I start the RCU and select “Create repository” and “Prepare Scripts for System loads”.
I provide the connection information to the target database.
RCU checks if the target database fulfill the prerequisites.
I choose the same prefix as on the source database and the same list of components.
RCU checks the prerequisites for the components selected.
Once all is validated, I click on the “Generate” button to create the DBA script.
This raises a process to generate the DBA scripts.
Once finalized, the “Completion Summary” screen shows the scripts location and the RCU log file name
Scripts : /tmp/RCU2023-03-13_13-38_739854221/logs/
Run the script “script_systemLoad.sql” on the target database as user having the DBA privileges to create the Fusion Middleware system objects and the product metadata schemas.
Once this is done, the rest of the steps are the same as in my previous blog Changing Fusion Middleware Forms and Reports repository database“. Those are:
Export all Fusion Middleware repository schemas from the source database
Before exporting the schemas, you need to make sure the export will be done in the right character set. In my case, the recommended character set for Fusion Middleware was used: AL32UTF8
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
expdp system/***** schemas=VM40FR_STB,VM40FR_IAU_APPEND,VM40FR_IAU_VIEWER,VM40FR_MDS,VM40FR_WLS,VM40FR_WLS_RUNTIME,VM40FR_IAU,VM40FR_OPSS dumpfile=VM40FR.dpdmp
Import those schemas in the target database
Same as for the database schemas export, the character set has to be correctly set in the NLS_LANG to avoid any character conversion or loose.
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
impdp system/***** file=VM40FR.dpdmp
Reconfigure the Fusion Middleware to use the new repository database
The reconfiguration of the Fusion Middleware Forms & Reports has been done using the chghost.sh tool but this one requires two files. The wallet containing the WebLogic domain administrator password and the mapping file describing the type of changes that the chghost.sh tool will apply. Before running the change host script, make sure no process is running for the Fusion Middleware WebLogic Domain. For example, if the node manager is started as Unix service, make sure to stop it or the change host tool will hang stopping the WebLogic managed servers.
Generate the wallet file for an administrator user named weblogic on my test environments.
$MW_HOME/oracle_common/common/bin/configWallet.sh -walletDir /home/oracle/CHGHOST_TEST weblogic
Create the mapping file. db_host_move.txt in this case.
[ARGUMENTS] [DATABASE_MAPPING]
# You can only change the database host name.
vm07.it.dbi-services.com=vm09.it.dbi-services.com
Finally run the chghost.sh script.
cd /app/oracle/12c/Middleware/oracle_common/bin/
./chghost.sh -chgHostInputFile /home/oracle/CHGHOST_TEST/db_host_move.txt -javaHome /app/oracle/Java/jdk1.8.0_321 -domainLoc /data/config/12c/domains/vm12fr -domainAdminUserName weblogic -walletDir /home/oracle/CHGHOST_TEST -logPriority FINEST -logDir /home/oracle/CHGHOST_TEST/logs
DB_super_user
27.08.2024If the intention is to move/migrate the Fusion Middleware repository database from one host to the other.
why do we have to invoke RCA and re-do the creation the Fusion Middleware system objects and the product metadata schemas.
Instead can't we just perform RMAN restore of the source database into the target cluster and then run the chghost.sh script to update the new host info on the middleware server mapped to the respective database ?
David Diab
30.08.2024Hello,
Both ways are possible to change the FMW Repository database.
In fact the method described in the blog could be applied in all cases, but the full RMAN restore may not be possible if you have other Schemas.
I can absolutely confirm - as mentioned in Oracle documentation - that you can do full RMAN Restore and so you don't have to invoke RCA aso.
For more information, you can contact me directly via LinkedIn (https://www.linkedin.com/in/david-diab-19596045/), I would be more than happy to exchange with you.
Regards,
David