Hi, newbe here to HR12. We currently have a 2-Tier Architecture, with the HR12 database sitting on one server, and the Applications sitting on the other. Presently, the CM sits on the Applications server and the developers have asked if it can be moved to the Database server.Any reason you want to move the CM to the other node?
I've looked at a lot of docs on the subject, but most deal with HR11, RAC environments, add a new node, or just to general ("If you are on R12, just change the context variable in the application context"), with no specific steps on how to do the procedure for our environment:This is not enough as you do not have any application tier files on the database node, so changing the context file and running AutoConfig only are not enough.
They feel that if the Concurrent Manager resided on the database server, and it somehow lost connection with the application server, the CM would continue to run normally and finish the work. Not to mention that they feel there would be better performance, but I'm not sure it's enough to warrant moving the CM to the Database server?Do you have any performance issues? If not, then I would suggest you keep the CM running on the same node.
Your question also brings up the bit I forgot to add to my original question: Does it really matter where the CM resides? What are the pros/cons of having the CM on the db server or the app server?Not really as long as you have sufficient resources on each node. In the initial Oracle Apps 11i installation the best practice was to install the CM on the Database tier but this no longer matter. Please note that if the CM is installed on the database node and you need to patch/upgrade the instance then you have to do it twice (once on each server), but in case the CM is running on the application tier node then this need to be done only once.
We have several programs that use the utl_file to read and write files. These are to drives on the server where the db resides. We also use shell programs to do things like moving (sFTP) files to other servers, like our EDI server. When the concurrent manager launches these shell scripts, they are run on the server where cm resides.You do not have to move the CM for this, just share the directory between the two nodes as mentioned in this thread -- How UTL_FILE works on split configuration
So, as our programs/interfaces work today, we need the shell scripts to run on the same server where utl_file runs. The only other possible solutions I can think of would be to see if our shell programs can use UNC, or copy/ftp the files from one server to another and then run the original shell program, or see if we can "map" a drive from the db server to the apps server. Or possibly mapping to a common drive?
The real problem is with the output from PL/SQL that calls the UTL_FILE database package, this package is owned by the database (user oracle), not the application (user applmgr), so the file is created on the database node that cannot be accessed by the concurrent manager. One solution is to mount the UTL_FILE directories of the db node to the conc node, but it's not something we really want to do.If you do not want to go with this solution then your only option is to move the CM to the database node.
Also, as stated earlier, the developes feel having CM and db nodes on the same server, the conc jobs would not be affected by network connection problems between the db and conc nodes, latency is minimized. Is this really an issue on R12?Not really -- With today's technology and network/server speed this should not be an issue.