Cloning Back - Table Exclusion Best Practice

[Sam Ogden]

Hi All,

We are at a position where we need to request a clone back from Prod into our TEST and DEV instances.

We have only once previously had a clone, and we realised after this that we would of been better place to have excluded some tables.

I was wondering if anyone had any advise on which tables are best to add to the system clone >exclude tables

I need to add the sys_user table to this as we encounted issues with logging in to the instances etc.

Any help on any best practice or tips of tables to exclude will be very useful

Thanks

Sam

[joost2]

Hi Sam

The most important tables are already excluded by default. Make sure that you don't remove any of these system setups as that might cause issues. On our system I've excluded some tables with sensitive data, but in many cases these types of tables are extended so you'll have empty them via script (or you could try using some sort of encryption). Lastly I've also excluded the sys_certificate table and set up data preservers for the certificates, since we have separate SSO certificates for each instance and this way I don't have to back them up.

Most common pitfalls with cloning:

1. Actions on cloned instances affect Prod. Try and avoid this by ensuring all links are relative   or use instance specific system properties that you preserve via a data preserver.

2. Cloned instance is slowed down because of too many pending events. Use scripts to turn of scheduled jobs you don't need on sub-production.

3. Integrations stop working on sub-production. Ensure all integrations are connected to test systems via instance specific system properties. (if you want to limit the number of system properties you can refer to the "instance_name" system property in your scripts).

4. People losing update sets. Set all "in progress" update sets to complete and import them to another instance (or multiple instances just to be sure). You can also export them via xml, but since you can only do one at a time this is very time consuming if you have a lot of update sets. However I would advise every developer to at least back up their own update sets this way.

5. Too many "complete" update sets after clone. You can prevent this by setting update sets on prod to "ignore" after committing them or you can do this via cleanup script.

6. Users complain that they lose test configurations. Generally my advice is that all projects managers should   export their test configurations via XML and re-import it. In some rare cases you can exclude tables and preserve data to make it easier.

7. Cleanup script run too long or don't run at all. This has happened to me a couple of times causing some of the issues I mentioned above. In case they don't run I run them via a background scripts. If they are running too long you might want to prevent users from accessing the instance in case the script is cleaning sensitive data.

8.Data preservers fail. This could happen if you've upgraded your production instance, but not your sub-production instance and the table schemas no longer match. It can also happen the other way around If you've already upgraded your sub_production instance and you're cloning from a lower version production instance.

9. Your Test integrations stop working because you forgot to backup the user accounts you use for your test integrations.

Kind Regards,

Joost