Activating data in DSO got dump SAPSQL_EMPTY_TABNAME after BW system copy

[Former Member]

Hi all,

We had an issue after system copy.

After a system copy the data in the standard DSOs(all of them) cannot be activated. The DOSs themselves are active, the transformations are active but if one attempts to load data and activate u2013 it does not work. The job terminates with shortdump SAPSQL_EMPTY_TABNAME.

Found the issue is caused by u201Cmore than one versionu201D of the change log.

We tried the Program RSAR_RSTSODS_CHANGELOG_VRS but it didn't work.

We had the solution like this:

After activating the DSO itself(the object) using RSDG_ODSO_ACTIVATE the issue disappears and the data can be activated. Issue also disappears. BUT Drawback: Activating the DSO causes the transformations to deactivate.Then we used the program RSDG_TRFN_ACTIVATE to activate all transformations. And then the issue disappeared.

Want to know what the root cause for this. From some SDN threads, mentioned BDLS job in the post refresh steps are not correctly done during system copy may cause this issue. How did the BDLS run wrongly cause this issue? And what is the exact correct way? We ran BDLS for each source systems inlcuding the target refreshed BW system itself by the default selection - conversion of Client-Dependent and Client-Independent Tables; because we used database copy

for the system refresh.

We also restored all source systems in RSA1 inlcuding the refreshed BW system own in the post-refresh steps.

Thank you very much for your information and suggestion.

Heming

[joaquim_casasbaca-castex]

Hi Hemming, i´m facing the same problem... although after executing report RSDG_ODSO_ACTIVATE and activating again TR and DTP solves the problem the system creates a new change log table. Do you know that this could impact in the normal behaviour of the system ? Normally there is only one change log table for every DSO not two...

Thanks in advance,

Regards

Joaquin Casas Baca-Castex

[former_member184494]

When you get the error - did you check in SM21 to see if there was any error on the database ..?

In many cases - reactivating the object just forces the tables to get created / aligned again ...

Another possible place to check if there is an issue is :

Go to SE14 and then select the Active , New , change log tables of the ODS - if SE14 says that these tables are active in the database - check the indices to see if they are active.

If everything is active - then try analyzing the tables and rerun stats on the same.

If all this fails - then you will have to reactivate the ODS . But 2 change logs for the same ODS seems strange.

[joaquim_casasbaca-castex]

Hi Arun, as you say two change log tables it´s strange. In fact in my opinion it´s not right but the problem is that the second change log table appears after executing std SAP report RSDG_ODSO_ACTIVATE in order to be able to activate the DSO. So the solution provided by SAP it works but i´m not sure if the right one. Besides this the original change log table is full of data while the second one is empty... for new loads which are gonna a be filled  by the activation process ? I suppose the second one... will this have some impact with the data stored in the first one... not in theory but.... i do not feel confortable with the consequences of this report.

And the most important, it seems that the reason why the DSO and the change log table had problems is due to a some problems or missing steps after executing the BDLS after BW system refresh but nobody can confirm this point...

So, i´ve been able to solve the issue but now i have two change log tables for the same DSO.

Anybody has the same situation after executing the above mentioned SAP std report ?

Regards,

Joaquin Casas Baca-Castex

[former_member210724]

Hi,

What about the technical names of the change log tables, are they different?

check this,last post may usefull for you

http://scn.sap.com/thread/258930

Anand.

[joaquim_casasbaca-castex]

Hi, the two change log tables has different names. The problem is that the data it´s stored in the old change log table while the new one remains always empty. When loading from DSO to cube it do not upload any data cause it seems is trying to update the data from the new one which it´s empty.

How can we link again the change log table in order to be able to upload new/changed data from DSO to cube ?

This is the main problem.

Regards

Thanks in advance

Joaquin Casas Baca-Castex