Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X
Team
Rehost from Prod to QA server: dump/restore the Oracle DB
Oracle expdp: we explored through the options with help in stackoverflow etc, and we probably got a good dump. We copy the dump file to the QA server.
Oracle impdp: we suspect that we need to drop tables before doing the impdp. What do we need to drop? Or can we just do impdp, counting on it to overwrite the old Windchill db contents?
Alternate solution: would RMAN be a good tool to do this?
cheers -- Rick
Solved! Go to Solution.
When I build a new test server, I do the following steps:
You should drop the db user, and cascade; then run the create_user sql script:
Here is the PTC article you need: https://www.ptc.com/en/support/article/CS249705?source=search
drop user <dbuser> cascade;
@create_user.sql
When I build a new test server, I do the following steps:
The creation scripts (step 3 and 5) seem unnecessary to me. Importing the database automatically recreates the user. Drop the user and import the dump file seems to be sufficient.
I think the create user step helps if you are defining permissions ahead of time that are only limited to what is necessary. Our work instructions have always been to drop, create, import, fix packages then run the rehost tool
Works for me every time. Unless PTC messed something up of course 🙂
Team, Thanks for the great answers. All are worthy of being marked 'Accept as Solution'. The moderators want me to choose! Nope, I will leave it un-marked unless everyone thinks there is a best choice.
Personably I like drop cascade; create user; alter user identified by; impdb.
I NEVER have the dB user password the same for multiple Windchill installation.
Why you ask? Because some companies might use the same Oracle server for production and dev.
There’s nothing wrong with that as long as you take precautions to insure they don’t get mixed up.
Different passwords takes care of that.
And even if they use different Oracle servers, someone could still screw it up, so having different passwords is one more gate keeper. Better safe than sorry.
BTW, If @TomU says create isn’t necessary I believe him.
Oh, okay. All good answers but let's accept yours, Ben.