When one wants to make a routing change, such as sending table to a different queue or target, the procedure is to make a copy of the currently active config file, make the change in the route for the table(s) in the copy, and then activate the copy. This is supposed to lock the source tables very briefly and does not require exclusive lock as may be required when the table is activated first time, since only routing changes in this activation called continuing activation. When doing a continuing activation involving routing change, it sometimes fails as following event log entries show:
08/01/07 17:11 Process exited sp_tconf (for o.M2PRD) [pid = 1598922] - exit(1)
event_log (15/60)
08/01/07 17:11 Bad config file: file - config_multi_queue.20070801; Unable to lock "CN"."CN_COMMISSION_LINES_ALL", it is currently involved in a transaction.
08/01/07 17:11 Config compilation completed: datasrc - o.M2PRD; file - config_multi_queue.20070801
08/01/07 17:11 Notice: Object "CN"."CN_COMMISSION_LINES_ALL" locked by user "APPS",session(422),process id(18778),mode=ROW EXCLUSIVE(3),OS user applinx [sp_tconf(osp)/1598922]
08/01/07 17:11 Notice: Object "CN"."CN_COMMISSION_LINES_ALL" locked by user "APPS",session(373),process id(23989),mode=ROW EXCLUSIVE(3),OS user applinx [sp_tconf(osp)/1598922]
Some applications have acquired exclusive locks on tables whose routing needs to change.
Though the routing change only requires a very brief lock, sometimes even that can be a problem. This depends on the application that locks the source table. In that case the activation will fail which hardly takes few seconds or few minutes depending on the # of tables involved. The workaround here is to keep trying to activate again and again so that there may come a time when the table is not locked exclusively by any application and the continuing activation may succeed. If it fails to activate despite repeated attempts, then one needs to find downtime to be able to activate or try to use "live" option in activation. If using "live" option, note that it may require the re-sync on tables that could not be activated in first attempt and the activation process had to make more than one attempt. Also, since "live" activation involves retrying to acquire locks, the activation can keep running for a long time without erroring out. So one needs to be prepared to wait till it finishes for as long as it may take.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center