Persistence Layer Table Switch issue

[Former Member]

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.

Olian

[SudhirT · Accepted solution]

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.

Thanks!

[Former Member · Accepted solution]

Hi Sudhir,

my copy runs over 5 days and is not finished yet. I've checked SM50 and there is no background job running for this copy. I'm afraid when the admin accneled the job it left the system in a incostistent state.

Any other ideas how to resolve this?

Thank you. Olian

[Former Member · Accepted solution]

Guys, any help appreciated.

Thank you. Olian

[former_member334189 · Accepted solution]

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

[Former Member]

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.

Regards,

Madhu.

[arthur_fuscella]

Hi Madhu

I faced the same problem and following the same steps, it worked.

The report RSXMB_ANALYZE_DB is not showing that data are being copied between the tables.

Regards,

Arthur

[former_member4958]

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?

Thanks

Marcos