Oracle Apps concurrent manager and DB Crash
From: Kumar Madduri <ksmadduri_at_gmail.com>
Date: Sun, 4 Oct 2009 09:33:52 -0700
Message-ID: <a2b1e7610910040933n73eb6fa1u643aac4f9c3ffd36_at_mail.gmail.com>
Hi All
Let us database crashed because the node was unresponsive or for some other reason. In Oracle Apps, concurrent manager also crashes . In my understanding, when the database is back up, and you bring up the concurrent manager the jobs that were running at the time of the crash should be able to recover and continue without any data corruption (unless you have custom programs that are commiting parent tables without inserting data in to child tables. Even these should be fine theoritically because fnd_concurrrent_Requests should maintain the status of the jobs and continue from where it left and I have not checked but most Oracle concurrent programs (given by Oracle) would have the logic of checking which tables are updated/deleted/instered an in what order ). So my question is should we not just bring up the concurrent manager after a crash and not have to worry about which programs were running just before the crash and notify users that such and such program was running before the crash..
Since fnd_concurrent_requests maintain the status of the jobs , the concurrent manager should be able to pick up the jobs that were in this table and their statuses and we should be good to go.
Date: Sun, 4 Oct 2009 09:33:52 -0700
Message-ID: <a2b1e7610910040933n73eb6fa1u643aac4f9c3ffd36_at_mail.gmail.com>
Hi All
Let us database crashed because the node was unresponsive or for some other reason. In Oracle Apps, concurrent manager also crashes . In my understanding, when the database is back up, and you bring up the concurrent manager the jobs that were running at the time of the crash should be able to recover and continue without any data corruption (unless you have custom programs that are commiting parent tables without inserting data in to child tables. Even these should be fine theoritically because fnd_concurrrent_Requests should maintain the status of the jobs and continue from where it left and I have not checked but most Oracle concurrent programs (given by Oracle) would have the logic of checking which tables are updated/deleted/instered an in what order ). So my question is should we not just bring up the concurrent manager after a crash and not have to worry about which programs were running just before the crash and notify users that such and such program was running before the crash..
Since fnd_concurrent_requests maintain the status of the jobs , the concurrent manager should be able to pick up the jobs that were in this table and their statuses and we should be good to go.
What is your opinion on this?
Thank you
Kumar
-- http://www.freelists.org/webpage/oracle-lReceived on Sun Oct 04 2009 - 11:33:52 CDT