AutoPatch error: The worker should not have status 'Running' or 'Restarted' at this point

ADOP Patch Session got terminated abnormally due to network issue or patch hung or lost connectivity after that we are facing the error when restart adop patch.

Error:-

AutoPatch error: The worker should not have status 'Running' or 'Restarted' at this point.


Corrective Action:-

In R12.1.x, we need to use adctrl to check worker running or failed.

                 AD Controller Menu
     ---------------------------------------------------

     1.    Show worker status

     2.    Tell worker to restart a failed job

     3.    Tell worker to quit

     4.    Tell manager that a worker failed its job

     5.    Tell manager that a worker acknowledges quit

     6.    Restart a worker on the current machine

     7.    Exit

Select option as below:-

 1.    Show worker status ---> to show worker status

 4.    Tell manager that a worker failed its job 


When applying patch using adpatch , Select option Yes When it prompts for

'Do you wish to Continue with Previous adpatch Session'

In R12.2.x, Use restart and abandon parameters to restart the patch session from where it failed.


$adop phase=apply patches=123456 restart=yes abandon=no 

how to drop XLA_GLT temporary Tables in EBS

As a Oracle DBA we need to reclaim space in database. For this we need to clear all temporary tables in our instance, which was no longer required.Temporary tables used in the GL Transfer process are no longer cleared down once the transfer is complete. This is a change in behavior as these tables were normally dropped for fully processed GL Transfers.

These tables are named XLA_GLT_% where % is the group_id used in the General Ledger Transfer. Run below query to find out those tables.


select table_name, blocks*8192/1024/1024 Size_in_GB from dba_tables
where owner='GL'
and table_name like 'XLA_GLT%'
order by 2 desc ;

To find out Total size of XLA_GLT_% table.

select sum(round(blocks*8192/1024/1024,2)) ||  ' SIZE_IN_MB' from dba_tables
where owner='GL'
and table_name like 'XLA_GLT%';



As mentioned in Oracle (Doc ID 796417.1),Once all the data is transferred to GL without error for each particular group id then the tables can be dropped using the concurrent program: XLADRPGLT - Purge Temporary Journal Import Interface Tables Created By Subledger Accounting.


The behavior before the patch is:

- GL transfer dumps data into a temporary gt table and Journal import processes this data. On successful completion, this gt table is dropped.

The behavior after the patch:

- Table xla_glt_groupid is not dropped, so that table is available for debugging.

To run the concurrent program Purge Temporary Journal Import Interface Tables Created By Subledger Accounting. need to be add 


==> Login to the application with a user that has the System Administrator responsibility.

==>Navigate to Security > Responsibility >Request

==>Query for the ‘GL Concurrent Program Group’ Request Group.

==>Add the program “Purge Temporary Journal Import Interface Tables Created By Subledger Accounting” (Subledger Accounting application) to the above request group.

==>Save.

To run concurrent "Purge Temporary Journal Import Interface Tables Created By Subledger Accounting" follow the below steps.

1)  Switch responsibility General Ledger Super User and go to veiw and then request to run the concurrent program "Purge Temporary Journal Import Interface Tables Created By Subledger Accounting".

Be careful while purging the temporary table because current year financial, data may be use for troubleshot/debugging ,So it should be last year financial year.

2) Select "Primary Ledger" and End date as above and click on submit.

If you are facing the below error in request log. Oracle Strongly recommended to apply the patch 10382869.

Start of log messages from FND_FILE 

+---------------------------------------------------------------------------+ 

04-OCT-2018 11:00:11 - Starting To Purge The XLA_GLT tables 

ORA-01722: invalid number 

+---------------------------------------------------------------------------+ 

End of log messages from FND_FILE 

3) After that check the XLA table size using below sql query and compare it with previous one.

select sum(round(blocks*8192/1024/1024,2)) || as ' SIZE_IN_MB' from dba_tables
where owner='GL' and table_name like 'XLA_GLT%';