Patching in R12.2.5

[satish]

Dear erman,

Hope you are doing good.learned a lot from your blog.

User reported his concurrent request was stuck with inactive nomanager status.when we looked into diagnostics tab,it showed us the below message.All the managers are up and running in administer form

"This request will not be processed because it has been submitted from a patch edition while a patch is being applied."

Need you inputs like what would have happened exactly

Thanks,
sri

[ErmanArslansOracleBlog]

Thanks for the feedback Satish.

Which concurrent program is that? What is the name?

[satish]

Hi Erman,

Thanks for the update.Create Accounting is the program name.The message says it was submitted from patch edition but i dont think that is the case

[ErmanArslansOracleBlog]

1)What happens when the user tries to run this concurrent request again? I mean when the user executes it now, does the user get the same error message?

2)What kind of operations was done in this environment?
applied patches using online patching cycle? any error or weirdness during patching? cutover performed properly?

3)does this issue happen only for this conc program? or for all the conc programs ?

4)when you use check the FNDLIBR processes from backen(OS), what do you see? I mean  are they using the patch fs? (using ps -ef and /proc filesystem you can check the file descriptors that FNDLIBR processes are using.. also check their current environments using /proc fs)

[satish]

Dear Erman,

Thanks for the update.

1)We have verified the file descriptors and we could see they are pointing to RUN file system
2)This is UAT instance
3)User cancelled the request and ran again,then we could see it completed normal

Now the issue is fixed.But we want to take precautions not to come across that error again and also want to understand why do we get that error

Thanks,
satish

[ErmanArslansOracleBlog]

You said : "User cancelled the request and ran again,then we could see it completed normal"
Like I expected...

As you know, we change the filesystem during the cutover phase of online patching.
It seems this concurrent request was started on a very specific point in time (during the cutover)
So I believe this result that you see, is expected but it is a weakness..

What I can tell you about this is the following ->
Ref: Oracle Support

The Online Patching cutover phase should be scheduled for a time when there are few online transactions and batch processing is minimal. You should confirm that critical concurrent requests are not executing during cutover. (consider putting critical scheduled concurrent requests on hold prior as well)

[satish]

Thanks erman.we will follow the suggestions provided