IFS Apps 10 database cloning best practices

Hi @Sandaruwan I don’t have a direct answer to you, but I definitely want to watch this topic! 🙂

I have one piece of input for you. If you’re trying to clone an environment that has Aurena Native apps with Grouped Push entities, there is a known issue which requires a post-clone cleanup method to be run - see https://docs.ifs.com/techdocs/21r2/045_administration_aurena/415_aurena_native_apps/095_troubleshooting/50_troubleshooting_group_push/#check-if-the-database-has-been-cloned-for-this-environment

I know that we’re on the lookout for better ways of handling cloning, so I’m following your question!

One way to do it is via the backups you are taking from your PROD environment.

For example, we have “hot” backups that are created every night in PROD so that we can recover in case of disaster. The additional benefit of these backup sets is that RMAN can be used to clone the database from one server to another, and it does not require PROD to be shutdown to do so. Data is from the previous night, of course, but that’s OK.

We had a consultant write Windows BAT files that handle database shutdowns, start-ups, and the RMAN script to pull in the backup sets into our TEST and DEV environments, representing a clone of PROD. The scripts also run some post operations, like setting a banner message and cleaning up whatever needs cleaning up.

This has been effective for us, and as I mentioned, it allows PROD to stay up the whole time. If you have a consultant you trust with the rider Oracle/RMAN knowledge, they should be able to create something for you that you can then run on your own.

Thanks,

Joe Kaufman

Please take into account that in the nonproduction environments you have settings that get overwritten and settings that don’t. For example, the integration users and IFS Connect settings, get duplicated, while Demand Planner Flows and configurations don’t.

If you clone PROD to TEST, make sure the emails out get disabled or monitored. Many times when PROD settings get copied, you sent TEST invoices out to customers, without them knowing you’re testing. 

We’re a cloud customer, the cloning is done by the cloud team, but even with their scripts in hand, there are still things you should be aware of. Before using the cloned environment, validate what you can  (you can’t validate everything) as part of the test script/procedure. 

Definitely things to be aware of, and we are very careful to write integrations and custom objects such that we use #DB_SID# and not just hardcoded values (like “PROD”). All of our App Owner and Info accounts use the same user IDs across all environments.

Still several changes that need to be done post-clone, for sure, and we generally run an MWS reconfigure and also a reconfiguration of Touch Apps in our TEST environment (which is Touch App enabled)..

But once we scripted and documented all that, clones from PROD to DEV and PROD to TEST work well and we we end up with safe environments in which to proceed with development and testing.

Thanks,

Joe Kaufman

Thanks everyone on feedback. I was more or less hoping for some process documentation, checklist and scripts that we can use as template that cover most important things we have to do and consider. I expect some exists at IFS managed cloud team who regularly work on topic or some other projects that already handle cloning very often.