Hi Tina,
This looks like a migration of multiple clients in a client by client process. The good thing is that you do not want to keep statistical and historical records.
I have done a client by client migration multiple times and the easiest way is to do it using the DB.Unload/DB.Load (ucybdbun / ucybdbld) to do it. It has the advantage to allow you to do this client by client, when you are ready for a client and also to transport the passwords in the Login, Connection and other objects where an encrypted password may be recorded in the DB.
Just be careful with the following points :
- Client 0000 must be set initially in your empty target DB to reflect your existing settings in the different Automic environment. You need to check and compare the settings in all those environments as they may have some different values. You can try to do a transport of Client 0000 but I would not recommend it as you have the System name recorded in the Client and this can creates a lot of issues i.e.
- Variables like UC_UTILITY_ARCHIVE, REORG, UC_EX_HOSTCHAR, UC_HOSTCHAR_DEFAULT, .... needs also to be compared between the different Automic environment as some values may be different or incompatible sometime.
- Check all your Agent name and settings between the different Automic environment, you may have duplicates over the environments (yes it happen !). And the settings in UC_HOSTCHAR_.... may also differ from one environment to another.
- If you have a lot of Agents and a lot of Clients, it may be interesting to look at the Agent Assignment object (HSTA) to automatically connect Agents and Clients. It avoids a lot of manual modifications in Agent objects if you have a way to select Agents for each Client with multiple criteria.
- If you have a large number of objects in the Clients, remove the versioning from the source Client settings if activated, until the unload/load is ended and validated for the Client. If you reload a Client for any reason, in update mode, the time required for creating the versions of the objects may have a very important impact on the time required for the DB load process. Set the versioning again, at least in the target Client, once load is ok.
- Last but not least, set the ucybdbun.ini file with the option
[TRANSPORT]
all_entities = 1
This allow to transport all values, including default ones, of all fields of object definitions. If you have a different default value between versions or environments, it avoid some issues when using objects in the new environment .... and a lot of headheache to find where it is coming from !
Usually, not a complicated process and very reliable. Just be careful with the settings (system, client, agents, ...) before processing then it is just an unload/load process with the utility programs.
Regards.
Alain
Original Message:
Sent: 06-23-2020 01:25 PM
From: Hart
Subject: Automic System Consolidation
Hello,
I think this has come up before, but wanted to start a new thread.
We are considering consolidating multiple Automic environments globally in to 1 system. The major versions of the environments are on 12 with a few different minor versions (12.2 and 12.3). Our new environment would be built on the latest build available at the time, and high level, i think we could do this with client copy or dbunload/dbload.
For us, we would want to start fresh and we would export any relevant stats and reports from the existing environment and those would not be brought across (we would store these in an external data source for any audit requirements). We are also planning to make the new environment clustered as it will be a much larger workload. Just wondering if anyone has had to do this before and what the experience was.
Thanks!
Tina