9 Replies Latest reply on Sep 8, 2017 1:24 PM by robin.burgess12

    manually increasing the fnd_concurrent_requests_s sequence for cloned systems


      We regularly see an issue on our dev/test EBS R12.2.5 systems, where concurrent requests either fail or have strange-looking log/out files in the first few days after a refresh. I believe this issue is caused by a mismatch between when the database backup used for the refresh was taken, and the NFS snapshot used to refresh the apps tier filesystem. Due to our current business processes, this is not something we can resolve easily, so I am looking at a workaround.


      The simplest approach I can see is to manually advance the fnd_concurrent_requests_s sequence by ~1000 immediately following a refresh, so that the sequence on the dev/test database would definitely be ahead of the request numbers used by the log/out files on the filesystem. I have checked MOS and have not found anything that says whether this is a good/bad idea. I did see an Oracle Communities post which referenced the next_unique_identifier column of the fnd_unique_identifier_control table, but not sure if that would also need to be updated.


      Has anyone had any experience with updating this sequence? Is it a recommended/supported approach (on dev/test)?