This discussion is archived
8 Replies Latest reply: Jul 13, 2011 12:07 PM by Hussein Sawwan-Oracle RSS

Move Concurrent Manager

874982 Newbie
Currently Being Moderated
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.

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:

Windows 2008
2-Tier environment
HR12

Any help would be greatly appreciated.
  • 1. Re: Move Concurrent Manager
    Hussein Sawwan-Oracle Employee ACE
    Currently Being Moderated
    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.

    Please see (Concurrent Processing - How to move Concurrent Processing Server from one node to another node [ID 373611.1]) for the steps you need to follow. Or, you could run preclone on the application node, copy all the application tier files to the database server, and run postclone on each node then (specify which application components need to run on each node when you clone).

    Thanks,
    Hussein
  • 2. Re: Move Concurrent Manager
    874982 Newbie
    Currently Being Moderated
    Thanks for the quick response Hussin. Only reason we want to move the Concurrent Manager is (and this is maybe where you can shed some light) that the developers are concerned that there could be some data corruption if there's a "hic-up" while the application server is talking to the CM in the middle of a transaction/wok flow.

    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?

    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?

    Thanks again for your help.
  • 3. Re: Move Concurrent Manager
    Hussein Sawwan-Oracle Employee ACE
    Currently Being Moderated
    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.

    As mentioned above, if your CMs performance is good then there is no point in moving the CM to the other node.

    Thanks,
    Hussein
  • 4. Re: Move Concurrent Manager
    874982 Newbie
    Currently Being Moderated
    Thanks for the advice and quick replies!
  • 5. Re: Move Concurrent Manager
    874982 Newbie
    Currently Being Moderated
    UPDATE.. After speaking with the developers, This is my understanding of why we need it on the same server as the DB server based on my discussions with Elton.

    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.

    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?
  • 6. Re: Move Concurrent Manager
    874982 Newbie
    Currently Being Moderated
    Also wanted to ad..

    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.

    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?
  • 7. Re: Move Concurrent Manager
    Hussein Sawwan-Oracle Employee ACE
    Currently Being Moderated
    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.

    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?
    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

    Thanks,
    Hussein
  • 8. Re: Move Concurrent Manager
    Hussein Sawwan-Oracle Employee ACE
    Currently Being Moderated
    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.

    Thanks,
    Hussein

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points