If two Applications Manager instances need to be merged, it is not possible to do so via sql or via database backend.
Below is recommendation to to merge Applications Manager instances. Please note that this may not cover every situation or environment and thorough testing should be done and performed on a non prod environment first.
Environment
Applications Manager 9.x.x
Resolution
Things to note:
"Old" refers to Applications Manager (AM) instance that is merged from and "new" refers to Applications Manager instance that is merged to.
Full database back up of database schemas is recommended to be taken one or more times during the process so a revert to an earlier time or to back out altogether is possible.
Recommend importing the old database objects into a non Prod environment for testing and for ironing out unforeseen issues.
Agents, Users, and Logins are the main objects that can not be imported/exported via AM's import/export feature
It is assumed that if there are firewalls in place, mainly between old Agent servers and new master, the correct ports are opened up to allow for communication between old agents and new master.
Steps:
Recreate Users on new instance to match the OS users defined in old instance's Standard Remote Agents
Recreate Login objects or any other Login objects required by the old environment. This includes extension Agent logs such as OAE or logins used by Subvars, etc.
Recreate Standard Remote Agents and any other RA or extension Agent.
Recommend doing a thorough review of the old environment's below object types and clean up any objects that are not required, such as old and/or no longer used objects.
Applications Calendars Data Types Environment Variables Jobs Libraries Message Templates Notifications Output Devices Output Groups Output Interfaces Output Scans Process Flows Program Types Queues Reports Substitution Variables Thread Schedules User Groups
Perform multiple AM exports from the old environment to import into the new environment. This should be done in groups to slowly move objects from old to new environment. While there are many ways to do this, it is recommended that performing one export for each of the below object types. For example, one export will contain all the Applications and the next export will contain all the Calendars etc.
For each object type that is prepared to be exported from the old environment, it is recommended to review the new environment for duplicate object names.
Applications Calendars Data Types Environment Variables Libraries Message Templates Notifications Output Devices Output Groups Output Interfaces Output Scans Program Types Queues Reports Substitution Variables Thread Schedules
Save the exporting and importing of Jobs, Process Flows, User Groups for last.
Depending on number of Jobs and Process Flows, you may want to split the Jobs into multiple exports and then also split Process flows into multiple exports as well.
For User Groups, before importing Users Groups from the old environment to the new environment, you may want to take a deeper look into the expected or desired User permissions as you may have multiple User Groups with the same or similar configuration.
When all the above steps have been completed, stop all Agent processes, and edit each old Agent's awenv.ini file, and update the below parameter to the correct value for the new master:
AWCOMM_PORT= Master= Master_Ip_Address=
There may other optional/firewall related parameters in the awenv.ini file that are specific to the old master that needs to be updated to the new master such as:
Masterserverport= RMIServerIP=
Once awenv.ini files are updated, Agents can be restarted.
Again, note that the described steps should be considered a general overview only and it is highly recommend testing this out in a non prod environment first.