How to migrate BPM 11g server to another BPM 11g server

Question

Hi All,
There is no change on BPM version (BPMN Editor 11.1.1.3.0.6.84 )
just simply a physical migrate, changed application server, DB and server domain/IP
Now we met questions when migrate DB date, there are four schemas DEV_MDS、DEV_SOAINFRA、DEV_ORABAM、DEV_ORASDPM, cannot used including install config settings, could not be used any more, could not be started.
Is there any guide of how to migrate just user data please?
Thanks for any help!
Regards,
Katherine

Answer 1

Migration of environment should really be done through backup tools that ensure a consistent point-in-time view of the data. We recently had a need to use import/export for an environment. I'll post those notes here hopefully save some time if you have to use this approach. But I'll emphasize again that a backup/restore model is the better way to go.
What we did
We took an environment that had a small set of BPM processes and exported the data from the three core schemas.
•     PS2_MDS
•     PS2_SOAINFRA
•     PS2_ORASDPM
We then loaded that data into another domain, started the server, and interacted with the composites that had originally been deployed in another domain.
What we didn’t do
•     Export complex composites. We didn’t have access to things like AIA applications
•     Export large amounts of data
•     Test a broad set of features. We did use Workspace to create roles, view dashboard, and interact with task lists.
What we learned
We believe this confirmed the basic assumption that data can be exported from one BPM/SOA environment, then loaded and run in another environment. However the issues around user privileges, starting queues, etc, highlight the need to test the process in a broader context.
Tools Used
Data Pump
Data Pump is an import/export tool provided by Oracle. A summary of features can be found at:
http://wiki.oracle.com/page/Data+Pump+Export+%28expdp%29+and+Data+Pump+Import%28impdp%29
SQL*Plus
Used to run scripts
Setup
Create Users
The data pump export will include privilege information in the export. And the data pump import will create users in the target database (assuming sufficient privileges for the user running the import). However we found that some roles related to AQ were not granted during the import. To resolve that issue we created scripts to pre-create the schema users and grant required privileges in the target environment.
TODO:
1.     Review the required privileges to see if there are data pump options that would resolve this
2.     Verify that there are no additional privileges needed by applications in the target integration environment.
Create Output Directory
Data Pump needs to have access to the file system from the database.
Make sure that the output directory is writable by the DB process.
From SQL*Plus:
create directory dbexport as '/scratch/ dbexport';
grant read,write on directory dbexport to system;
Export Data For Selected Schemas
The Data Pump tool supports providing a list of schemas to export as part of a single operation. In this test case we exported the following core BPM schemas to a single file. The commands are in the do_exp.sh script.
•     PS2_MDS
•     PS2_SOAINFRA
•     PS2_ORASDPM
TODO:
1.     Verify space required for the target database to ensure that there is sufficient space to export the data.
Import Data into Target Schemas
Data Pump supports mapping schema names and table spaces as part of the import specification. In this case we used the same Oracle instance, so the schemas were mapped to new names. The PS2 prefix was mapped to XYZ.
Note that the OID transform property is required to avoid conflicts with existing object Identifiers.
impdp system/welcome1 DIRECTORY=dbexport DUMPFILE=bpm.dmp transform=oid:n \
REMAP_TABLESPACE=PS2_MDS:XYZ_MDS \
REMAP_TABLESPACE=PS2_SOAINFRA:XYZ_SOAINFRA \
REMAP_TABLESPACE=PS2_IAS_ORASDPM:XYZ_IAS_ORASDPM \
REMAP_SCHEMA=PS2_MDS:XYZ_MDS \
REMAP_SCHEMA=PS2_SOAINFRA:XYZ_SOAINFRA \
REMAP_SCHEMA=PS2_ORASDPM:XYZ_ORASDPM \
TODO:
1.     Check the log for errors. The only errors we saw were related to trying to build stats on empty indexes.
2.     Identify any other schemas being used
3.     Verify if any other transform operators are needed
Post Import
Start Queues
SOA infrastructure makes use of queues in the DB server. While the queue structures were created, they were not started as part of the import. The start_queues.sql script starts the queues.
TODO:
1.     Verify if there are any other queues that need to be started/configured
2.     Verify if there are any other Stream/Queuing configuration tasks needed
Update Data Sources on WLS
Assuming an existing installation of SOA, the datasources need to be updated to use the new schemas.
Start Domain and Verify Logs
It’s important to check the admin and managed server logs for errors related to composite instances and MDS operations.
Verify Composite State
Log into EM and ensure that the state of instances is consistent with the prior state.
Verify Application Roles and Role Mappings
Since the composites are loaded from MDS, there will be no deployment to create application roles. If the environment is using LDAP or DB, then the validation is to check the mappings through Workspace. If the old environment used a file store, then you’d have to crate the role mappings through Workspace.
Verify Workspace Operations on Existing Instances
Verify that task list operations and dashboards are functional.