Skip to Content
avatar image
Former Member

Persistence Layer Table Switch issue

Hi Guys,

I have a serious problem in production XI. I scheduled a deletion job and switched on table switch procedure. Content of container 1 started to be duplicated. There was circa 2mil records and this was working fine from the beginning but now the copy is significantly slower. I'm afraid the system will crash before all the items will be copied. Another problem occured, when the basis administrator cancelled the Copy job. It took too long and was slowering down the system, so he thought it will be better to cancel it. He didn't know what this was. So currently the system is trying to copy the container 1 to 2 and I'm not able to delete any messages using reports, because it says the copy job has not been finished yet. And I'm afraid this will not be finished ever if I don't do something.

Is anybody skilled enough on the persistence layer table level to help me solve this?

One more question, I can't find the piece of code, where copy of records from container 1 to 2 takes place and also what settings need to be done after the copy is finished.

Thank you all for all your ideas.


Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Best Answer
    Oct 20, 2008 at 10:31 AM

    Hi Olian,

    It will take some time to move the data but that is for sure. I had same issue and it took around two and half day to finish this activity and also you will not be allowed for any deletion reports during this period.


    I can't find the piece of code,


    You can check in SM50 background jobs there you will find the report being executed for copying from container1 to 2.


    Add comment
    10|10000 characters needed characters exceeded

    • Dear Olian,

      don't worry - cancelling the switch job will not leave your system in inconsistent state. The switch job copies the messages junkwise, where each junk is handled in its own transactional context. I.e. if the copy job is cancelled the work done for the current junk is completely rolled back.

      As the dynamic switch to another table set during runtinme is quite complex ALL other reorganizational tasks (deletion, archiving, update of adapter status,...) are not allowed to run until the switch is complete.

      Because of this the switch MUST be completed once it was started. There is no alternative!

      In case you are running out of disc space (check in DB02) there is one possiblity to make the switch

      complete successfully: by applying OSS note 1056749 you can make the switch to MOVE messages instead of COPYing them.

      Please note that...

      ... option MOVE_INSTEAD_OF_COPY='X' is to be used in case of emergency only; it is NOT intended to by used permanently

      ... moving messages from container 1 to container 2 does NOT mean the space allocated for container 1 is released on DB level immediately; releasing this disc space is highly dependent on the DB system in use; for example shrinking the db files can easily be done for MS SQL from the admin UI and for Oracle there is the BRSPACE tool (see OSS notes 647697, 646681 and 821687).

      Best Regards,

      Harald Keimer

      XI Development Support

      SAP AG, Walldorf

  • avatar image
    Former Member
    Jul 31, 2013 at 03:08 PM

    I ran into similar situation in one of my development PI 7.30 system waited for a week (Contents of container 2 being copied to container 1).

    SAP_BC_XMB_DELETE_100 job failing with below error

    Table container currently being copied; no concurr

    Job cancelled after system exception ERROR_MESSAGE

    I ran RSXMB_TABLE_SWITCH from se38 which copied all messages from container 2 to container 1.



    Add comment
    10|10000 characters needed characters exceeded

    • Hi experts.

      We are facing the same issue here: We started in 12/24/2014 at 1:52PM Job SAP_BC_XMB_TABLE_SWITCH. But is is executing in the same step more than 1 day (Processing client 066).

      We can find the Work Process in SM50 running in background, but not sure if it's doing something:

      Log from Job:

      26.12.2014 02:35:09 Status: Messages copied thus far: 1.072.343

      26.12.2014 02:40:16 Status: Messages copied thus far: 1.073.843

      26.12.2014 02:45:24 Status: Messages copied thus far: 1.075.243

      26.12.2014 02:50:31 Status: Messages copied thus far: 1.076.743

      26.12.2014 02:55:46 Status: Messages copied thus far: 1.078.343

      26.12.2014 03:00:59 Status: Messages copied thus far: 1.079.743

      26.12.2014 03:05:43 Processing client 066

      We are a little bit afraid to cancel this Job, cause we don't know the consequences.

      Could you tell us what should we do to solve this issue? Could we cancel this Job and restart it again?



      switch.png (61.7 kB)