We are using CA Clarity 13.0.1, Oracle 220.127.116.11, Linux Redhat 5.5. I have to restore the UAT environment with prod db. Please provide the steps for successful db refresh
Its pretty easy to copy a PROD to a UAT - as you realise just copying the database does this.
The things to look out for are whether you reference the application in any of the "code" on the database though ; for example in any GEL scripts that might XOG data into the system, make sure that they are not pointing to PROD from the UAT system* ; that sort of thing. If your PROD niku database password is different that the one you had in your 'old' UAT one then you need to do a little NSA work (or properties.xml) as well, but generally the NSA-config should not need changing.
(* - not as though I forgot to do this once )
You can take an export dump from CA PPM (ensure to have cold database back) so that your sequence are in sync and when you restore ensure PPM services are turned down.
Ask Tom "How To FULL DB EXPORT/IMPORT"
Hope this will help you.
In addition to what the others have said, if you have any jobs that run on a schedule and act on the data, make sure to pause any that would cause issues. We have a job that runs weekly that emails reminders to users who have not submitted their timesheets. It gets confusing when they get an email from the Test system after they DID in fact submit their timesheets. Not that I have forgotten to turn those off before or anything.
A couple more items:
1) If you have email enabled in the target environment, turn it off, or dummy out the email addresses. Nothing annoys a VP faster than irreverent emails.
2) depending on your corporate policy, you may not be allowed to have Production data in a lower environment. if that is the case, prepare a few scripts that you can run to change data that you should not have.
3) disable the users or change their passwords so that your production users cannot access the target environment. I had a user about 7 years ago spend 3 days entering project updates. Unfortunately, they did it to the wrong environment! They were not happy.
Good points, I found this query awhile back on the boards to clear out email info and run it whenever we refresh for this exact reason. On top of stopping the job, this is double safe:
update niku.cmn_sec_users set SMS_EMAIL_ADDRESS = '', EMAIL_ADDRESS = '';
update niku.srm_resources set SMS_EMAIL = '', EMAIL = '';
We also have a different UI theme that just changes the background color (to bright red) to make sure its very obvious you're on the Test environment
I too, change the theme for the lower environments. Except for the training environment. This allows me to create training material that looks identical to prod.
Before import the file dump, drop all sequence in UAT DB. Because the oracle import will not overwrite the sequences.
You should not really import a schema over the top of another even if you dropped the sequences first. If you want to reuse the same username/schema, then first drop the existing one entirely and recreate the user. Else you may end up with mismatched content that will later break (e.g. custom object tables that already exist from the old environment, when you go to create them from the refreshed system that did not previously have a reference to it, it will then fail trying to do it - as just one immediate/simple example but not the only problem by far).
Thanks All for
Retrieving data ...