Questions:
- What happens if the ICM goes down?
- How will you speed up the patching process?
- How will you handle an error during patching?
- Provide a high-level overview of the cloning process and post-clone manual steps.
- Provide an introduction to AutoConfig. How does AutoConfig know which value from the XML file needs to be put in which file?
- Can you tell me a few tests you will do to troubleshoot self-service login problems? Which profile options and files will you check?
- What could be wrong if you are unable to view concurrent manager log and output files?
- How will you change the location of concurrent manager log and output files?
- If the user is experiencing performance issues, how will you go about finding the cause?
- How will you change the apps password?
- Provide the location of the DBC file and explain its significance and how applications know the name of the DBC file.
- All the other managers will keep working. ICM only takes care of the queue control requests, which means starting up and shutting down other concurrent managers.
- You can merge multiple patches.
- You can create a response file for non-interactive patching.
- You can apply patches with options (nocompiledb, nomaintainmrc, nocompilejsp) and run these once after applying all the patches.
- Look at the log of the failed worker, identify and rectify the error and restart the worker using adctrl utility.
- Run pre-clone on the source (all tiers), duplicate the DB using RMAN (or restore the DB from a hot or cold backup), copy the file systems and then run post-clone on the target (all tiers).
Manual steps (there can be many more):- Change all non-site profile option values (RapidClone only changes site-level profile options).
- Modify workflow and concurrent manager tables.
- Change printers.
- AutoConfig uses a context file to maintain key configuration files. A context file is an XML file in the $APPL_TOP/admin directory and is the centralized repository.
When you run AutoConfig it reads the XML files and creates all the AutoConfig managed configuration files.
For each configuration file maintained by AutoConfig, there exists a template file which determines which values to pick from the XML file. - Check guest user/password in the DBC file, profile option guest user/password, the DB.
- Check whether apache/jserv is up.
- Run IsItWorking, FND_WEB.PING, aoljtest, etc.
- Most likely the FNDFS listener is down. Look at the value of OUTFILE_NODE_NAME and LOGFILE_NODE_NAME in the FND_CONCURRENT_REQUESTS table. Look at the FND_NODES table. Look at the FNDFS_ entry in tnsnames.ora.
- The location of log files is determined by parameter $APPLCSF/$APPLLOG and that of output files by $APPLCSF/$APPLOUT.
- Trace his session (with waits) and use tkprof to analyze the trace file.
- Take a statspack report and analyze it.
- O/s monitoring using top/iostat/sar/vmstat.
- Check for any network bottleneck by using basic tests like ping results.
- Use FNDCPASS to change APPS password.
- Manually modify wdbsvr.app/cgiCMD.dat files.
- Change any DB links pointing from other instances.
- Location: $FND_TOP/secure directory.
- Significance: Points to the DB server amongst other things.
- The application knows the name of the DBC file by using profile option "Applications Database Id."
