I’m very familiar with the steps that are required to refresh a non-production IFS environment from production in previous versions of IFS, but am not certain if there are any required tasks for refreshing an IFS environment in the Cloud version.
Are there any particular steps required to update the middle-tier for the Cloud version once the database has been cloned? Would I just run the installer.cmd file from the latest delivery that was applied to get the middle-tier re-established or is that step no longer necessary? Normally a reconfiguration in previous versions of IFS would get the needed updates to FND_SETTING_TAB made (or simply update the table directly) but wanted to ask around to see if there’s anything else that needs to be done.
Does the middletier kubernetes clusters need to be shutdown with MTCTL on the management server before the database refresh begins? Yes
Do I need to redeploy the middletier using the latest delivery version of IFSINSTALLER, and if so, are there any specific parameters that need to be provided other than user passwords and the YAML file parameters? if there isn’t delivery difference redeploy middle tire from latest delivery would be sufficient. if you have crystal report, as a parameter adding it is enough. .\installer.cmd --set action=mtinstaller --set ifscore.networkpolicy.crystalhost=10.0.8.86
Yes, we’re using EXPDP and IMPDP to export and import the IFSIAMSYS schema. Keeping the current user passwords in the environment is the reason for this step. If you need the source environment’s user credentials instead, you can ignore this step.
Thank you for taking the time to reply. Here’s what’s been setup thus far:
Created DB links from target instance to source instance (as well as the inverse).
Created database refresh user with grants to CREATE SESSION and CREATE PLUGGABLE DATABASE.
Setup Oracle parameters for DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT.
Unknown steps for before / during the refresh are:
Does the middletier kubernetes clusters need to be shutdown with MTCTL on the management server before the database refresh begins?
Do I need to redeploy the middletier using the latest delivery version of IFSINSTALLER, and if so, are there any specific parameters that need to be provided other than user passwords and the YAML file parameters?
I’m curious about the IFSIAMSYS schema export / import that you mentioned. Is that something that would be accomplished using Oracle EXPDP and IMPDP? I understand this is to make all of the configured user passwords get re-imported, but wanted to make sure that I understood you correctly.
The environments are currently unavailable for remote access (customer is doing some VPN reconfigurations at the moment), but I’ll have the ability to go through the process, presumably the start of the year.
Thanks again, and I’ll reply to this post with lessons learned once I get through it if I don’t hear from anyone
Does the middletier kubernetes clusters need to be shutdown with MTCTL on the management server before the database refresh begins? Yes
Do I need to redeploy the middletier using the latest delivery version of IFSINSTALLER, and if so, are there any specific parameters that need to be provided other than user passwords and the YAML file parameters? if there isn’t delivery difference redeploy middle tire from latest delivery would be sufficient. if you have crystal report, as a parameter adding it is enough. .\installer.cmd --set action=mtinstaller --set ifscore.networkpolicy.crystalhost=10.0.8.86
Yes, we’re using EXPDP and IMPDP to export and import the IFSIAMSYS schema. Keeping the current user passwords in the environment is the reason for this step. If you need the source environment’s user credentials instead, you can ignore this step.
The customer is pivoting to something else for the moment, and the requested database refresh has been postponed. I’ll go ahead and mark your most recent reply as the best answer, very informative / helpful.
Thank you for the replies, and have a prosperous new year!
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.